Mobile IP Working Group Karim El-Malki, Ericsson INTERNET-DRAFT Hesham Soliman, Ericsson Expires: April 2001 November, 2000 Fast Handoffs in MIPv6 Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This draft describes a method to achieve Fast Handoffs in Mobile IPv6. Fast Handoffs are required in Mobile IPv6 in order to limit the period of service disruption experienced by a wireless Mobile Node when moving between access routers. This requirement becomes even more important when supporting real-time services. Fast Handoffs involve anticipating the movement of MNs and sending multiple copies of the traffic to potential Mobile Node movement locations. Both flat and Hierarchical Mobile IPv6 models are considered. The Hierarchical MIPv6 mobility Management model in [1] already offers improvements to Mobile IP handoffs by providing a local Mobility Anchor Point (MAP) functionality. Some additions are made to the operation of this existing Hierarchical model to achieve Fast Handoffs. El-Malki and Soliman [Page 1] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 TABLE OF CONTENTS 1. Introduction.........................................2 2. Fast Handoffs........................................4 2.1 Initiating Fast Handoffs through the "previous" AR...5 3. Fast Handoffs in Hierarchical MIPv6..................7 3.1 Fast Handoffs in a flat MIPv6 architecture...........7 4. Handling Ping Pong in Fast Handoffs..................8 5. Extensions for Fast Handoffs.........................9 5.1 Extensions to MIPv6..................................9 5.2 Extensions to Neighbour Discovery....................10 6. Fast Handoffs and DAD................................10 7. Acknowledgements......................................11 8. References............................................11 9. Addresses.............................................12 1. Introduction Fast Handoffs anticipate the movement of wireless Mobile Nodes (MNs) by utilizing simultaneous bindings in order to send multiple copies of the traffic to potential Mobile Node movement locations. In this way, Fast Handoffs coupled to layer 2 mobility can help in achieving seamless handoffs between Access Routers (ARs) by eliminating the delay period required to perform a Registration following a Mobile IP handoff. An alternative method to perform improved handoffs, namely Smooth Handoffs, is described in [2]. The method for Fast Handoff addresses the need to support services having strict delay bounds (i.e. real-time) which in certain cases may be hard to support if traffic has to be forwarded between ARs using Smooth Handoffs. Also, in the non-realtime case it may be possible that the new AR receives buffered traffic from the previous AR (smooth handoff)and traffic from the CN contemporarily which could cause some out-of- order and delayed packets to be delivered to the MN. In some cases this may affect the performance of higher level protocols (i.e. TCP). This same situation will not arise using Fast Handoffs. This draft considers both the normal Mobile IPv6 model [2] and the hierarchical Mobile IPv6 model [1]. These are shown in Figure 1 where the Access Points (APs) or Radio Access Networks (RANs) are used to provide a MN with wireless L2 access. Simultaneous bindings are described in this draft and may be achieved by setting a new, "B" flag in the BU sent by the MN to a MAP. In this way, the MAP will add a new binding for the MN without removing the existing entry. El-Malki and Soliman [Page 2] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 Hence packets arriving to the MAP will be tunnelled to both addresses in its Binding Cache. _________ __________ | | | | | HA |--------| (MAP) |________ |_________| |_________| \ / | \ \ \ ... ... ... \ \ ______/_ _\______ | | | | | | | AR2/MAP| | AR1/MAP| | |________| |________| | ____|___ ____|___ ____|___ | | | | | | |AP/RAN 2| |AP/RAN 1| |AP/RAN 3| |________| |________| |________| | ____|___ | | CN | MN | |________| Figure 1: Flat (HA only) and Hierarchical (HA and MAP) MIPv6 model The method to anticipate MN movement by interacting with the wireless L2 is described later in this draft. The Hierarchical Mobile IPv6 scheme introduced in [1] allows a Mobile Node to perform registrations locally with a MAP in order to reduce the number of signalling messages to the home network and CNs. This achieves a reduction in the signalling delay when a Mobile Node moves between ARs and therefore improves the performance of such handoffs. This draft describes Fast Handoffs in Hierarchical Mobile IPv6 (HMIPv6) as well as a flat network architecture. When considering a MIPv6 handoff, two different cases can be considered depending on the network architecture: - The previous and new AR are physically connected - The previous and new AR are connected via N other nodes or networks The first case can be considered a subset of the more generic case (second). Hence the solution proposed will be addressing the generic (second) case. El-Malki and Soliman [Page 3] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 2. Fast Handoffs overview Fast Handoffs address the need to achieve seamless Mobile IP Handoffs when the MN moves between ARs. This is done by "bicasting" traffic to the "previous" AR and "new" AR while the MN is moving between them. The anticipation of the MN's movement is achieved by tight coupling with Layer 2 functionality which is dependent on the type of access technology used. The coupling between L2 and L3 technologies may occur in the network nodes or the MNs, or both, depending on the access technology. "Bicasting" is achieved through simultaneous bindings, where the MN activates the "B" flag in the MAP registration. When a MAP Registration has the "B" flag set, the receiving MAP, which has an existing binding for the MN, will add the relevant new binding for the MN but will also maintain any existing binding it had for the MN. Two different handoff scenarios are considered in this draft: - A MN having to do a handoff between two different ARs with which it can be simultaneously data-connected (eg. Two different access technologies). In this case it may not be essential to request simultaneous bindings. The MN may simply continue using both COAs (on the old and new link) as specified in [2]. A MN can ensure that packets will be arriving at the _new_ interface after receiving a BAck from its HA/MAP/CNs. This can be achieved by requesting a BAck from these nodes. However, since the processing of BUs is not mandated in [1], the MN may need to keep the old interface live for a short period of time to ensure no more packets are addressed to it. - A MN having to do a handoff between two access routers with which it can not be simultaneously data-connected. This is the more common case where_Fast_Handoffs can be used to achieve seamless mobility. When the MN has multiple active bindings with a MAP, it may or may not receive multiple copies of the same traffic directed to it. The use of simultaneous bindings does not necessarily mean that the MN is receiving packets contemporarily from multiple sources. This depends on the characteristics of the access (L2) technology. The "bicasting" of packets, combined with the anticipation of the new COA is used to and speed up handoffs by sending a copy of the data to the AR which the MN is moving to. Until the MN actually completes the L2 handoff to the new AR, the data "copy" reaching this AR may be discarded. In this way the total handoff delay is limited to the time needed to perform the L2 handoff. Thus, Fast Handoffs coupled to the L2 access potentially result in loss-less IP-layer mobility. As described in chapter 2.1, depending on the L2 characteristics, it is also possible for an MN to initiate a Fast Handoff through the "previous" AR without having direct access to the "new" AR. El-Malki and Soliman [Page 4] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 2.1 Initiating Fast Handoffs through the "previous" AR In the case in which the wireless L2 technology allows the MN to be data-connected to multiple wireless access points simultaneously, the MN may solicit advertisements from ARs before completing a handoff. In this case "bicasting" may not be necessary. Some existing wireless L2 technologies and their implementations do not allow a MN to be data-connected to multiple wireless access points simultaneously. Thus, in order to perform a Fast Handoff it is necessary for some form of interworking between layers 2 and 3. It should be noted that the method by which an AR determines when a MN has initiated a L2 handoff is outside the scope of this draft and may involve interaction with L2 messaging. Also, the interaction between L2 and L3 should allow the Mobile Node to perform a L2 handoff only after having performed the L3 Fast Handoff described in this draft. That is, the L2 handoff may be performed after the MN's Registration with the "new" AR which produces a simultaneous binding at the MAP. This Registration may be transmitted more than once to reduce the probability that it is lost due to errors on the wireless link. Alternatively, the MN may choose to send a BU to the MAP with the_A flag set. A Fast Handoff in this case requires the MN to receive "new" router advertisements through the "old" wireless access points, and to perform a registration with the "new" AR through the "old" wireless access point. Two ways of performing this follow. I. Inter-AR Solicitation This solution assumes that the AR with which the MN is currently registered is aware of the IP address of the "new" AR which the MN is moving to. The method by which the current AR is informed of this may depend on interaction with L2 and is outside the scope of this draft. In some wireless networks, an AR may not be closely coupled to the radio link layer protocols. In these scenarios the initiation of the handoff my need to be done by the MN. Based on L2 indications, the MN may solicit the router for a special advertisement that includes the "new" subnet prefix(es). To indicate the need for such special advertisement, the solicitation message would need to include a new option showing an identifier for the "new" AP. This identifier may then be mapped in the AR to a neighbouring or the current subnet. Hence the appropriate information can be communicated to the MN. Once the current AR is aware of the address of the AR which the MN El-Malki and Soliman [Page 5] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 will move to, it will solicit the "new" AR for a router advertisemnt. The "new" AR will reply to the current AR by sending it a router advertisement with appropriate extensions. The current AR will then send the anticipated prefixes for the "new" subnet to the MN's unicast address. As a consequence, the MN, being eager to perform new bindings, will send a BU to the MAP to request that packets addressed to it be bicasted to both the "old" and "new" addresses. It should be noted that problems may arise if the current AR and the "new" AR are not sharing the same link. In this scenario, sending a router solicitation to the "new" AR would mean that the solicitation and advertisement messages need to be routed beyond the subnet scope. This scenario is not allowed in [5] to avoid ARP-like attacks in IPv4. However, it may be possible for the old AR to send a solicitation message to the new AR if the following conditions are met: - The source and destination addresses in the message are of site- local or global scope. - The AR MUST NOT add its link layer address in the solicitation message. - The solicitation message and the router advertisement both contain sufficient authentication and authorisation information for both routers. This can be achieved by having one common secret shared between a cluster of ARs within a domain. Such secret can be used to process AH which can be added to the solicitation/advertisement messages. Added security can be established by setting up a permanent tunnell between the two ARs. If all the above conditions are met it should be possible for router solicitations/advertisemnts to be routed beyond the subnet scope. II. Piggy-backing Advertisements on L2 messaging Let us take Figure 1 as an example, where a MN initiates an L2 handoff from AP/RAN1 to AP/RAN2 (Note that it may not be the MN which takes decisions on handoffs). It is assumed that when an L2 handoff is initiated, AP/RAN1 and AP/RAN2 perform L2 messaging procedures to negotiate the L2 handoff. Since the MN is not attached to AP/RAN2 yet, AR2 is unaware of the IP address of the MN and cannot send an advertisement to it. Therefore it is necessary for the L2 procedures to interwork with Mobile IP. Once a L2 handoff is initiated, such that AP/RAN2 and AP/RAN1 are in communication, it is possible for AP/RAN2 to solicit an advertisement from AR2 and transfer it to AP/RAN1. Once this is received by the MN, the MN can send a BU to the MAP using an AR2 COA even though the MN has no data-connection to AP/RAN2 yet. El-Malki and Soliman [Page 6] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 The precise definition of such L2 procedures is outside the scope of Mobile IP. 3. Fast Handoffs in HMIPv6 HMIPv6 is described in [1]. Fast IP Handoffs can be achieved in a very simple and efficient manner. When the MN receives a router Advertisement including a MAP option, as specified in [1], it should perform actions according to the following movement detection mechanisms. In a Hierarchical Mobile IP network such as the one described in this draft, the MN MUST be: - "Eager" to perform new bindings - "Lazy" in releasing existing bindings The above means that the MN will perform bindings with any "new" MAP advertised by the AR (Eager). The method by which the MN determines whether the MAP is a "new" MAP is described in [1]. However the MN should not release existing bindings until it no longer receives its MAP option or the lifetime of its existing binding expires (Lazy). If the MN has at least one existing binding with a MAP, additional simultaneous regional registrations will be performed requesting a short lifetime. This is done in order to limit the lifetime of bindings which the MN only needs temporarily and therefore limit bandwidth usage. This is the case when the MN is moving between ARs and uses Fast Handoffs to achieve near loss-less IP mobility. The lifetime of additional "auxiliary" bindings needed for Fast Handoffs is thus limited. It should be noted that the method described above is applicable to hierarchical and flat architectures. As described in [1], a MAP can exist on any level in the hierarchy, including ARs. Hence, a bicasting request can also be sent to a MAP located in the AR, in the case where no MAPs are located higher in the hierarchy. 3.1 Fast Handoffs in a flat MIPv6 architecture A flat MIPv6 architecture is one that does not use a static mobility management based hierarchy. In the context of [1], this would mean that no MAP functionality is deployed beyond the on-link AR. In this case the same concepts described above would still apply if the MAP function is used in the AR. El-Malki and Soliman [Page 7] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 _________ _________ | | | | | HA |--------|Internet |________ |_________| |_________| \ / | \ \ \ ... ... ... \ \ ______/_ _\______ | | | | | | | MAP1 | | MAP2 | | |________| |________| | ____|___ ____|___ ____|___ | | | | | | |AP/RAN 2| |AP/RAN 1| |AP/RAN 3| |________| |________| |________| | ____|___ | | CN | MN | |________| Figure 1: Flat mobility management architecture In this scenario a dynamic hierarchy can be established without changing any of the concepts mentioned above. The handoff is anticipated by sending the "new" link's prefixes to the MN before L2 handoff takes place. The MN would then send a new BU to its "old" MAP, located in the "old" AR, and request that all packets addressed to it be bicasted to its current address and the new COA. In this manner the "old" MAP/AR serves as an anchor point for the MN while it is connected to the new AR/MAP. This architecture is well suited to an AR serving large coverage areas where IP mobility may not occur very frequently. For other mobility scenarios where handoffs are frequent, a hierarchical mobility management scheme as [1] is more efficient and flexible. 4. Handling ping pong in Fast Handoffs Ping Pong is a term used mainly in cellular networks to describe the repetetive rapid movement of a mobile terminal between two APs for a short period of time. While this phenomenon may be transparent to the IP layer if both APs belong to the same coverage area of an AR, it is certainly an important issue to address if the APs are associated with two different ARs. To successfully avoid the negative impacts of ping pong, it is important to avoid sending BUs every time the MN attaches to a new AR. In addition it is important to avoid packet routing defficiences El-Malki and Soliman [Page 8] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 which may result in packets dropped for the duration of the ping pong. Fast Handoffs can handle this phenomenon by issuing a bicast request through the "old" AR and before the MN moves to the "new" AR. This will ensure that the MN will continue receiving packets addressed to it irrespective of its current AR. Hence the packet losses due to IP mobility can be reduced to zero. Since the MN will have an entry in its Binding Update List (BUL) indicating that a BU was sent with a bicasting request, the MN will not need to resend BUs whenever a new router advertisement is received from one of the ARs it is moving in between. 5. Extensions for Fast Handoffs 5.1 Extensions to MIPv6 To allow bicasting from the MAP to take place, a new flag,_B_, is added to the BU message. Upon reception of a BU message with the _B_ flag set, a MAP SHOULD bicast all incoming packets addressed to the MN to its current COA as well as the new COA in the BU requesting the bicast. The new BU message is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|R|D|M|B|Res| Prefix Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Options... +-+-+-+-+-+-+-+-+-+-+-+- Description of extensions to the BU option: B If set, it indicates a request for bicasting all traffic received for the MN to its current address as well as the new address in the BU. Res 2 bit reserved field El-Malki and Soliman [Page 9] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 5.2 Extensions to Neighbour Discovery 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A|R|P| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Modified fields P Indicates that the prefix included is the anticipated one on the new subnet. The prefix advertised MUST NOT be treated as an on link prefix. Res 4-bit reserved field. 6. Fast Handoffs and DAD Duplicate Address Detection (DAD) was defined in [4] to avoid address duplication on links when stateless address autoconfiguration is used. The use of DAD to verify the uniqueness of a statelessly configured IPv6 address may add delays to a MIPv6 handoff. The probability of an interface identifier duplication on the same subnet can be considered very low, however it can not be ignored. In this draft certain precautions are proposed to minimise the effects of a duplicate address occurrence. In an HMIPv6 network as described in [1], a MN can register with one or more MAPs while moving within one or more MAP domains. Since a MAP domain is likely to include more than one router, when receiving a BU from the MN a MAP can check if other nodes within its domain are using the same interface identifier or address. If address duplication is detected, a MAP MUST reject the BU with the approriate fault code. El-Malki and Soliman [Page 10] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 If a duplication of the interface identifier is found, a MAP MAY accept the BU and include a new code in the BAck to warn the MN from choosing this interface identifier value. As a result a MN may change the interface identifier immediately or before moving to a new subnet. This method guarantees that no address duplication will take place between addresses registered in the MAP. It should be noted that a MAP higher in the hierarchy may provide better address "coverage" to allow the MN to predict address duplication earlier. In the case of a flat architecture as decribed in chapter 3.1 a MAP will not be able to know other MN addresses outside its subnet. Since the MN may not register with the "new" MAP until it moves to the new subnet, or it may simply not register for a long time, there is little benefit in using the approach mentioned above. Hence, to avoid delays due to DAD in a flat mobility management architecture, a MN may choose to continue sending and receiving traffic using its newly formed COA while performing DAD on the new subnet. In the case where a duplication exists, the MN MUST follow the rules in [4]. This issue is not specific to this proposal and may also be addressed in future revisions of [2]. 7. References [1] H. Soliman, C. Castellucia, K. El Malki and L. Bellier "Hierarchical Mobile IPv6 and Fast Handoffs", draft-ietf-mobileip-hmipv6-00.txt (work in progress), September 2000 [2] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-12.txt, February 2000. [3] K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv4". (work in progress) [4] S. Thomson and T. Narten "IPv6 Stateless Address Autoconfiguration". RFC 2462. [5] T. Narten, E. Nordmark and W. Simpson " Neighbour Discovery for IP version 6 ". RFC 2461 8. Acknowledgements The authors would like to thank Claude Castellucia (INRIA) for his helpful contribution to this draft. In particular, his valuable contributions for DAD handling. Erik Nordmark provided very useful El-Malki and Soliman [Page 11] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 comments on handling of inter-AR solicitation as well as DAD handling. The authors would also like to thank the following members of the working group (in alphabetical order) for their comments and the interesting discussions on this draft: Gopal Dommety (Cisco), Dave Johnson (Rice University), Conny Larsson (Ericsson), Mohan Parthasarathy (Sun), Basavaraj Patil (Nokia), Charles Perkins (Nokia), Mattias Pettersson (Ericsson), Carl Williams (Sun)and Alper Yegin (Sun). 9. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola M/S M8-540 6000 Connection Drive 1501 West Shure Drive Irving, TX 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com Fax : +1 972-894-5349 Questions about this memo can be directed to: Karim El Malki Ericsson Radio Systems AB Access Networks Research SE-164 80 Stockholm SWEDEN Phone: +46 8 7573561 Fax: +46 8 7575720 E-mail: Karim.El-Malki@era.ericsson.se Hesham Soliman Ericsson Australia 61 Rigall St., Broadmeadows Melbourne, Victoria 3047 AUSTRALIA Phone: +61 3 93012049 Fax: +61 3 93014280 E-mail: Hesham.Soliman@ericsson.com.au El-Malki and Soliman [Page 12] INTERNET-DRAFT Fast Handoffs in MIPv6 November 2000 El-Malki and Soliman [Page 13]