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.txtThe 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 notyou 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 forpost-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 adviceprovided by the document's editors that this matter has been discussedwith Mobile IPv6 folk and that there are no serious issues ofincompatibility anticipated. I expect a note to this effect from Marcelo Bagnulo summarizing the outcomes of this discussion to be posted to theSHIM6 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 atthis time.