Subject: [Mip6] FW: MIPv6-SHIM6 interaction

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 4 Apr 2006 11:00:04 -0700

FYI.

the following describes how MIP6 and shim6 could
work together. please don't respond to this mail.
any discussion should happen on the shim6 mailing 
list.

Vijay
 
> ---------- Forwarded message ----------
> From: marcelo bagnulo braun <[email-masked]>
> Date: Apr 3, 2006 11:23 PM
> Subject: MIPv6-SHIM6 interaction (was Re: SHIM6 Working Group Last
> Call on draft-ietf-shim6-proto-04.txt
> To: shim6-wg <[email-masked]>
> 
> 
> Hi all,
> 
> In the SHIM6 wg meeting in Dallas, some people pointed out 
> that we need
> to verify that SHIM and MIPv6 worked together in a reasonable way
> without interfering with each other. In order to verify that, 
> the first
> thing to do is to identify the scenarios where they are likely to
> interoperate i.e. where there seems to make more sense to run MIP and
> shim togeether. After discussing this point with several people
> including Erik, Hesham, Vijay and Dave, the scenarios and use cases
> described below for a joint MIPv6-Shim6 operation have been 
> identified.
> 
> (Note that this is merely my understanding of the topic, so 
> only i have
> the responsibility for any mistake here)
> 
> In general terms, it is my understanding that MIP and SHIM interact
> properly in the the identified valuable scenarios, while some details
> may require some additional thought, especially in the last scenario.
> 
> 1)- Multihomed home network. In this case, the Home Network 
> of a mobile
> node is multihomed. This basically means that the home network has
> multiple prefixes/ISPs available, resulting in the MN having multiple
> HoAs, one per available prefix. In this case, it seems reasonable to
> expect that the MN can benefit from the multihoming features 
> when it is
> roaming. So, this basically means that the MIPv6 protocol is used to
> support mobility of the MN when it is away from home and the Shim6
> protocol is used to provide multihoming support to all the 
> nodes in the
> multihomed site, in particular to the MN. In other words, 
> each protocol
> is used for its original purpose. This use case MUST work properly,
> since it is just the natural conjunction of both technologies. In this
> case, shim6 is layered above MIPv6 and below IPSec. So when a 
> packet is
> coming from the application layer, it is firstly processed by IPSec,
> then by the SHIM and finally by the MIPv6. MIPv6 spec has some wording
> about how IPSec is processing, stating basically that IPSec is above
> MIPv6, which is architecturally coherent with this stack layout
> considered here. Probably some additional consideration are required,
> since the SHIM will lay between IPSec and MIPv6, but it is expected
> that the interaction can work properly. In this case, the available
> HoAs can form a HBA set so that a given communication can 
> move from one
> HoA to another.
> Overall, the mapping would be like this: the application 
> sends a packet
> using the ULID pair (probably including a HoA). The packet is then
> processed by the shim layer, which it may map the ULID to an
> alternative pair if a outage has occurred. The alternative address,
> will also be a HoA. then, the packet is passed to the MIPv6 layer,
> which will perform the HoA CoA mapping (BT or RO modes)
> 
> 2)- HA-MN tunnel fault tolerance. Consider the case where the HA has
> multiple addresses, whether because multiple prefixes are available or
> multiple interfaces. In addition, the MN may also have multiple
> addresses, because the visited network is multihomed and/or 
> because the
> MN has multiple interfaces. In this case, the shim is used to provide
> additional fault tolerance to the tunnel path, the shim is used in the
> tunnel interface. In this case, the shim is associated to the tunnel
> interface and not to the IP interface that is running MIPv6. In this
> case, Shim is located below IPSec layer of the tunnel interface. Again
> the interaction in this case is architecturally clean. It may be
> possible to provide support for this case without using the shim.
> However, even in this case, it may make sense to reuse some 
> of the shim
> mechanisms like the failure detection and path exploration mechanisms
> in an alternative MIPv6 based solution. So, this case MAY be supported
> but other configurations that rely only in MIP may result more
> attractive to provide the required features, reusing existing shim6
> mechanisms
> 
> 3)- Shim6 based RO. This case is similar to the first scenario, only
> that CoAs are also presented to the shim. So in case of a failure, the
> shim may select a CoA as an alternative locator rather than a 
> HoA. If a
> CoA is selected, then the outgoing packet needs not to be processed by
> the MIPv6 layer (no BCE is available) and the result is a shim6 based
> RO mode, where packet flows directly between the MN and the CN. While
> it seems to us that this is workable, at this point it is not clear to
> us how valuable is this configuration.
> 
> El 23/03/2006, a las 17:29, Geoff Huston escribió:
> 
> > Folks,
> >
> >         This note starts the WG Last Call for comments on
> >         draft-ietf-shim6-proto-04.txt, "Level 3 multi-homing shim
> >         protocol".
> >
> >         It can be found at:
> >
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-shim6-proto-04.txt
> >
> >         The document is intended to be submitted by the 
> Working Group
> >         to the IESG for publication as a Proposed Standard.
> >
> >         Please review the document carefully, and send your feedback
> > to the
> >         SHIM6 list.  Please also indicate in your response 
> whether or
> > not
> >         you believe that this document is ready to go to the IESG.
> >
> >         This Last Call will end on Friday 14 Apr 2006 at 0800 AEST
> >         (UTC+10).
> >
> >         Thanks,
> >
> >
> >               Geoff & Kurtis
> >
> > ----------------------------------------------------------
> >
> > Additional comments to this Last Call:
> >
> > o The three week period for the WG Last Call is to allow some leeway
> > for
> >   post-IETF recovery!
> >
> > o We also note that we have an outstanding topic of 
> compatibility with
> >   Mobile IPv6 and SHIM6 as discussed in the Working Group 
> meeting this
> >   week. This last call has been generated on the basis of 
> verbal advice
> >   provided by the document's editors that this matter has been
> > discussed
> >   with Mobile IPv6 folk and that there are no serious issues of
> >   incompatibility anticipated. I expect a note to this effect from
> > Marcelo
> >   Bagnulo summarizing the outcomes of this discussion to be 
> posted to
> > the
> >   SHIM6 WG during this Last Call period.
> >
> > o We have consulted with the technical advisors to this 
> Working Group
> > and
> >   they have indicated that are happy for us to proceed with 
> this last
> > call at
> >   this time.
> >
> >
> >
> 
_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6