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

Re: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt



Hi Brian,

El 21/10/2004, a las 0:21, Brian E Carpenter escribió:

My minor substantive comments are below.
Some editorial comments were sent direct to the author.

> 4.2 Multi-Homing: Mobility
...
> The aspect of MIPv6 which appears to present issues in the context of
> multi-homing is the return routeability mechanism. In MIPv6 identity
> validity is periodically tested by return routeability of the
> identity address. This regular use of a distinguished locator as the
> identity token cannot support return reachability in the multi-homing
> context in the event of extended path failure of the path that is
> associated with the identity locator.


This question isn't really relevant to multi6,

Well, lots of people claim that there is a close relation between multihoming and mobility, since both problmes require changing the locators and keep the identifier.
Since there is an available solution for mobility, it seems quite natural to explore if such solution is suitable for multihoming.
The problem with the available solution for mobility is that the security mechanism used in mip is inherently incompatible with the multihoming requirements, since it is based on reaching the identifier.


so imho it is relevant to multihoming the explanation why the approach used for mobility is not suitable for multihoming.

regards, marcelo

 but isn't it therefore
also the case that if the home agent becomes unreachable for more than
7 minutes, regular MIP6 also breaks for the same reason and the mobile
node loses connectivity?

> 5.3.3 Layering Identity
...
> An alternative approach is to use a distinct protocol element placed
> between the transport and internet layers of the protocol stack. The
> advantage of this approach is that it would offer a consistent form
> of mapping between identities and locators for all forms of transport
> protocols. However this protocol element would not be explicitly
> aware of sessions and would either have to discover the appropriate
> identity / locator mapping for all identity-addressed packets passed
> from the transport protocol later, irrespective of whether such a
> mapping exists and whether this is part of a session context, or have
> an additional mechanism of signaling to determine when such a mapping
> is to be discovered and applied. At this level there is also no
> explicit knowledge of when identity / locator mapping state is no
> longer required, as there is no explicit signaling of when all flows
> to and from a particular destination has stopped and resources
> consumed in supporting state can be released.


But there is knowledge, even with UDP, when a socket is closed (in
the worst case because the process that opened it goes away). I think
that because of some sort of layering religion, we tend to neglect
the fact that socket state exists and gets explicitly deleted, and
this should be exploited as the trigger for deleting id/loc
mapping state.

    Brian





------------------------------------------
Please note that my former email address
mbagnulo@ing.uc3m.es is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------