[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: About draft-arifumi-lin6-multihome-api-00.txt (was Re: Call forpresentations)



Hi, marcelo.
Sorry for I coundn't reply to you soon.
Now I'm working for the coming Networld+Interop 2003.:)

On 25 Jun 2003 18:25:41 +0200
marcelo bagnulo <marcelo@it.uc3m.es> wrote:

> On Tue, 2003-06-24 at 09:47, Arifumi Matsumoto wrote:
> [...]
> 
> > 
> > Your understanding about LIN6 is absolutely correct.
> > In LIN6, the locator part of an IPv6 address isn't visible
> > to upper layers. This makes it possible to continue
> > existing sessions even when an LIN6 node moves and
> > its address is changed.
> > In this model, however, upper layers cannot make any
> > controls on outgoing packets' address and route.
> 
> Ok. i think we a different idea about this. IMHO, addresses and routes
> are IP layer issues, above layers should not be aware of the route used
> and they should not select it. For above layers, IP addresses are plain
> identifiers of nodes.

First of all, LIN6 originally does not show multiple
addresses to an application layer.

Most of applications do not need such information, but we
believe some kinds of applications need such information.
That's why we extended API of LIN6.

For instance, in the current IPv4 Internet, most of
applications rely a DNS resolving mechanism on a library
provided by a system though, MTAs such as sendmail do
resolve DNS by themselves in order to utilize multiple
destinations.

>  This
> > model, we think, doesn't benefit from multihoming.
> > 
> I do not see what you mean. If the ip layer preserves the established
> sessions using a mechanism such as LIN6 or whatever, i would say that
> the host is benefiting from multi-homing.

I mean LIN6 doesn't fully benefit from multi-homing. In LIN6
IP address addition and deletion is the only information used
for mobility and multi-homing. When a link between the two end-
points gets in trouble each node cannot detect it. The connection
will be lost in a short time even both or either of the two end-
points is multi-homed.
I believe this kind of trouble has to be detected in transport
or upper layer.

> So we make it possible to make an special socket through
> > which multiple locators are visible to upper layers
> > (application layer). This special socket are implemented
> > so that it can co-exist with normal sockets.
> > For such a socket, LIN6 is used for address resolution,
> > notification and registration. LIN6 layer acquires
> > target node's addresses, registers locators to its
> > Mapping Agents and notifies address change to the
> > corresponding nodes and also to upper layers.
> > 
> > > An additional question is about address discovery. I mean how do the end
> > > nodes find out what addresses are available at the other end? There is a
> > > mapping agent mentioned, but where is this mapping agent located? which
> > > addresses does it announce? all the available addresses or just the ones
> > > that are reachable at the moment? if the latter, how does it find out
> > > whether an address is reachable or not?
> > 
> > These issues are mentioned in LIN6's draft below.
> > http://www.lin6.net/draft/draft-teraoka-ipng-lin6-01.txt 
> > Briefly speaking, you can get the MA's address by a kind
> > of DNS address-to-name translations. By making a query
> > ,where an mobile node is, to the MA, a corresponding node
> > can get all the addresses the mobile node has even if some
> > of the addresses aren't reachable from the corresponding
> > node.
> > 
> So in the multi-homing scenario, where would those MAs should be?

An MA can co-exist in an MN itself, when the MN does not
move and is multi-homed.

We are also thinking the cases where multiple MAs are
distributed for a sigle MN, each MA is multi-homed, and an
MN moves with being multi-homed. In any case, LIN6 works
pretty well.


Thanks.

-- 
Arifumi Matsumoto (arifumi@kuis.kyoto-u.ac.jp)