Internet Engineering Task Force MIPv6 Handover Design Team INTERNET DRAFT 20 November 2000 Fast Handovers for Mobile IPv6 draft-perkins-mobileip-handover-00.txt Charles E. Perkins Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. 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 to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document identifies (OR BETTER: specifies) protocol enhancements that enable mobile nodes to more quickly become connected at new points of attachment to the Internet. These protocol enhancements are intended to minimize the time during which the mobile node is unable to send or receive IPv6 packets (i.e., the handover latency). Mobile IPv6 is considered to be the base protocol, but Mobile IPv6 does not mandate any mechanism which gives assurances about minimizing the handover latency. The protocol enhancements in this document should be considered as protocol enhancements to Mobile IPv6. Perkins, editor Expires 20 May 2001 [Page i] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 Contents Status of This Memo i Abstract i 1. Introduction and Overview 1 2. Requirements 2 3. Scope of the Solution 2 4. Terminology 3 5. Interaction between Layer 2 and Layer 3 5 5.1. Anticipate Mobile Node Movement . . . . . . . . . . . . . 5 5.2. Indication of layer 2 handover completion . . . . . . . . 5 5.3. User Data Processing at layer 2 . . . . . . . . . . . . . 6 5.4. Carrying layer 2 parameters . . . . . . . . . . . . . . . 6 6. Binding Updates in Mobile IPv6 6 7. Interactions with Localized Bindings 7 8. Routing to Multiple Care-of Addresses 8 9. Network-Controlled vs_Mobile-Controlled Handover 8 9.1. Mobile-controlled Handovers . . . . . . . . . . . . . . . 9 9.2. Network-Controlled Handovers . . . . . . . . . . . . . . 10 10. Tunnel Extension 11 11. Handover Features 11 12. Handover Between Two Operator Domains 11 13. Ping-Pong Effect 12 14. Obtaining a new CoA 13 15. Latency of DAD 14 16. Handover Scenarios 14 16.1. Mobile Node sends PD with Link Connectivity to New Access Router . . . . . . . . . . . . . . . . . . . . . . . . 15 Perkins, editor Expires 20 May 2001 [Page ii] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 16.2. New Access Router sends PD with Link Connectivity to Mobile Node . . . . . . . . . . . . . . . . . . . . . . . . . 15 16.3. Mobile Node sends PD with Link Connectivity to Previous Access Router . . . . . . . . . . . . . . . . . . . . . . . . 16 16.4. Previous Access Router sends PD with Link Connectivity to Mobile Node . . . . . . . . . . . . . . . . . . . . . 18 17. Message flows 19 18. Message Extension and Option Formats 19 19. Security Considerations 20 20. Acknowledgements 20 21. References 20 A. Application signaling 21 B. Context Transfer 21 Addresses 23 1. Introduction and Overview Mobile IPv6 already offers a handover procedure, which is recognized to have sufficient in certain circumstances that makes it unsuitable for real-time applications. It is the purpose of this draft to define a solution that reduces handover latency, so that Mobile IPv6 is a better candidate for handling mobility for mobile nodes hosting real-time applications. Additional signaling procedures and optimizations are proposed to be used in addition to the basic handover procedure specified in Mobile IPv6. Note that the fast handover techniques are not limited for use with only real-time applications, and might offer substantial benefits for many other kinds of communications. There are a number of standard and proposed protocols involved with establishing link connectivity for IPv6 networks, and each of them has to be carefully considered to determine the possible effects of each smooth handover technique proposal. For instance, IPv6 Duplicate Address Detection inserts a timeout before link operations can begin. The effect of this has to be studied and perhaps counteracted as part of any reasonable fast handover proposal. This draft has several sections that are far from complete. In particular, design consensus has not been reached for most of the material that belongs in sections 17, 18 Perkins, editor Expires 20 May 2001 [Page 1] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 Section 16.4 needs more work, which could not be finished in the time before the Internet Draft deadline. Many issues remain unresolved. 2. Requirements The main requirement for this solution is to reduce or eliminate any handover latency when a mobile node moves from one care-of address to another care-of address. This is valuable, because when a mobile node experiences loss of connection for any appreciable duration of time, it can adversely affect the operation of applications which have real-time response characteristics. The solution selected MUST be compatible with Mobile IPv6. Secondary or Non-goals include: - Context transfers - Protection against loss of packets - Minimizing signaling for delivery of binding updates These goals may be considered during the development of the fast handover protocol specification, but tradeoffs will be made to favor fast handovers. If two proposals are otherwise equal, the selection process SHOULD prefer the proposal that offers benefits for the above secondary items. The handover solution should work whether or not the serving domain operates using a hierarchical mobility agent model in MIPv6. However, if hierarchical mobility agents are available, the handover solution should work well with the protocols needed to maintain routing through the agent hierarchy (see section 7). The time taken for allocation of a new care-of address at the new access router is an important consideration in fast handover. Both stateful and stateless address allocation methods add considerable latency in the overall procedure. The Fast Handover procedure solution should reduce the latency involved in the allocation of a new CoA. The handover solution should not depend on the specifics of any air-interface or layer two (L2) technologies (but, see section 5). Triggers from L2 can be incorporated into the solution space. The solution MAY allow for later extensions to account for layer two specific features. Perkins, editor Expires 20 May 2001 [Page 2] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 3. Scope of the Solution We will consider just the packet routing aspect of the problem and not focus (initially) on transfering any context related information that a mobile node may have at its previous point of attachment (but see appendix B). Multiple scenarios need to be considered. The solution is required to enable improved handovers in the following scenarios: a). Intra-technology handover (same administrative domain) b). Intra-technology handover (between administrative domains) c). Inter-technology handover (same administrative domain) d). Inter-technology handover (between administrative domains) The handover solution should also be specified to work whether the mobile node is in idle or in active mode. The handover solution should not introduce any changes to the current MIPv6 model. No new network elements should be required, but the solution may specify new features that would be needed at access routers. 4. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. This document uses terms defined in Mobile IPv6 [2], Neighbor Discovery [3], and Stateless Address Autoconfiguration [4]. In addition, this document uses the following terms: Access Router the router offering connectivity to the mobile node at some point of attachment to the Internet. Active Mode a mode in which a mobile node is fully enabled to send or receive packets. Context Transfer the operation of transferring the value of state variables, which had been established at the previous access router, to the new access router Perkins, editor Expires 20 May 2001 [Page 3] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 Current Access Router the router offering connectivity to the mobile node at its current point of attachment to the Internet. In this document, the current access router is usually the point of departure for the mobile node as it makes its way towards the new access router. Fast Handover a handover operation that minimizes or eliminates latency for establishing new communications paths to the mobile node at the new access router Handover Latency Handover latency is the time difference between when a mobile node is last able to send and/or receive a packet to/from a correspondent node by way of the previous access router, until when the mobile node is able to send and/or receive a packet to/from a correspondent node, by way of the new access router. Idle Mode a mode in which a mobile node has to perform additional procedures before it is fully enabled for sending or receiving packets. Typically a mobile node enters idle mode to save battery power or air interface bandwidth. New Access Router the router offering connectivity to the mobile node at a new point of attachment to the Internet. Predictive handover Predictive handover is initiated through the source access router. Handover latency can be reduced by using predictive handover procedure, since the predictive handover procedure can set up the new access router for the handover before the handover actually occurs. Previous Access Router the router offering connectivity to the mobile node at its previous point of attachment to the Internet. Reactive handover Reactive handover is initiated through the new access router. Serving Domain the administrative network domain which contains the access router serving the mobile node. Perkins, editor Expires 20 May 2001 [Page 4] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 Smooth Handover a handover operation that minimizes data loss during the time that the mobile node is establishing its link to the new access point Seamless Handover a handover that is both fast and smooth Note that, in the definition for Fast Handover, it is not specified what the maximum allowable delay value should be. For the purposes of seamless handovers for two-way voice (telephony) applications, the value should be minimized. Current discussion indicates that making any precise measurement for the delay value is difficult, so no allowable maximum value will be specified in this document. Note further that the handover latency is the time from the last layer-3 connectivity between the mobile node and its previous access router, to the time when the layer-3 connectivity to the new access router has been established. Thus, it is possible for some handover operations to cause zero latency. Negative values are not considered useful for discussion in this document. This Internet Draft is intended to become a standards track document after completion of sections 17 and 18. 5. Interaction between Layer 2 and Layer 3 Although the handover procedure is developed at layer 3, it is important to see the interaction between layer 2 and layer 3 to better understand and implement the procedure. This section lists some of the layer 2 interactions. We should also point out that Layer 3 is where Mobile IP works. 5.1. Anticipate Mobile Node Movement If layer 2 has the link evaluation capability, when it sees link degradation it MAY send an trigger to layer 3 for handover. Layer 2 may also provide prioritized possible new candidates in the handover initiation request. 5.2. Indication of layer 2 handover completion The indication of layer 2 handover completion is desired by layer 3 at new access router and mobile node, so they can start layer 2 processing of IP packets. The source access router may also need the Perkins, editor Expires 20 May 2001 [Page 5] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 layer 2 handover completion indication to release layer 2 resources associated with the mobile node. 5.3. User Data Processing at layer 2 Real-time applications are expected to benefit from the fast handover procedure. Such applications often do not require acknowledgement of layer 2 packet delivery. In that case, there may be no need to resend unacknowledged layer 2 packets from new access router. 5.4. Carrying layer 2 parameters Some of the layer 2 attributes which were set on the source link between mobile node and access router may need to be transferred and set at the new link. Layer 3 handover signaling between the old and new access router can be used to carry these layer 2 parameters. For this purpose, an envelope field for layer 2 parameters might be helpful in the layer 3 message. 6. Binding Updates in Mobile IPv6 In Mobile IPv6, a mobile node informs correspondent nodes and mobility agents about its new care-of address by using a Binding Update Destination Option. A correspondent node receiving the Binding Update will begin to use Routing Headers to deliver data to the mobile node. Mobility Agents receiving the Binding Update with the 'H' bit set will begin to tunnel packets to the care-of address given by the mobile node in the option. However, aside from this use as suggested above, the mobile node can send a Binding Update that is not so closely related to the abovementioned use with its home agent. Between the time when the mobile node moves from the old to the new access router and when it sends a Binding Update to its correspondent nodes, the forward link packets which are in flight go to the previous access router. These packets will be lost unless they are handled and redirected to the new care-of address. If the mobile node sends a Binding Update to its previous access router, the access router subsequently tunnels packets sent to the previous care-of address to the mobile node at its new care-of address, acting as a home agent for the previous care-of address. This is expected to be a transitional phenomenon, and the binding between the care-of addresses typically has a short lifetime. See [2] for details. It is also noteworthy that most link establishment protocols are, naturally, concerned with the mobile node's care-of address, with Perkins, editor Expires 20 May 2001 [Page 6] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 hardly any consideration given to the mobile node's home address. For this reason, it is reasonable to design smooth handovers that identify the mobile node by its care-of address, if any IPv6 address is to be used for that purpose. However, it is not easy to see how any other kind of identifier could be used to identify the mobile node without introducing non-local operations, or else additional state at the access routers. For mobile-controlled handovers (see section 9.1), any additional handover features may be associated to this Binding Update, since it may be the first opportunity that the mobile node has to communicate such requests to its previous access router. Furthermore, just as with the Binding Update, handover request messages are likely to require authentication data, so that the previous router can make sure that the handover request has indeed been issued by the intended mobile node. 7. Interactions with Localized Bindings Seamless handover has to do with enabling the mobile node to move from one point of attachment to another within a serving domain. Localized Binding has to do with limiting any signaling needed for distributing Mobile IPv6 Binding Updates to interested parties elsewhere in the network. Seamless handovers have to do with managing delivery of packets to a new access router instead of the previous access router. Localized Binding has to do with localized techniques for associating a care-of address with the mobile node's home address, along with some relevant timing information. The timing considerations that are relevant to seamless handovers are not closely related to the timing information associated to the binding between the home address and the care-of address, although the latter SHOULD provide an upper bound on how long the mobile node can have use of its care-of addresses. Several techniques which have been recently proposed may have interactions with seamless handovers. Bicasting (or, "IP diversity") refers to the process of duplicating packets and sending them to the mobile node at both its previous and new points of attachment. This is semantically allowed by IP because it does not guarantee packet uniqueness, and higher level protocols are assumed to eliminate duplicates whenever that is important for the application. Anchor chaining refers to creating a chain of access routers, all of which cooperate to forward a packet to the mobile node as it moves from one access router to the next, even though the packet is initially delivered to an access router that the mobile node was attached to at some point in the perhaps distant past. The previous access routers notionally form the links in the chain, which is Perkins, editor Expires 20 May 2001 [Page 7] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 anchored by some access router which supports the concept, and is known to the home agent or some nearer router as the latest effective care-of address for the mobile node. Lastly, and as exemplified by the anchor chaining approach, the path taken towards the home agent by Binding Update (for the mobile node's home address, not its care-of address) may be affected by the way seamless handovers are carried out. It could be that the Binding Update could conceivable be forwarded by either the new access router, or the previous access router, towards the home agent or a regional mobility-aware agent. 8. Routing to Multiple Care-of Addresses Several solutions have been proposed that can route packets to more than one care-of address. One solution, mentioned previously, is known as "bicasting" or "IP diversity". Bicasting means to send the same IPv6 packet to more than one access router. If the mobile node is able to receive the packet at one or both of the access routers, but there has not yet been time for the routing infrastructure to settle on a particular route to the mobile node, then this method can eliminate some guesswork about which actual care-of address should receive the packet. The bicast request can be done as an extension to the BU. If the MN has an entry in its Binding Update List (BUL) indicating that a BU was sent with a bicasting request, the MN may not need to resend BUs whenever a new router advertisement is received from one of the ARs it is moving in between. Another approach, known as "neighborhood routing", allows a packet to be sent to several possible care-of addresses, which are provided by the mobile node as simultaneous care-of addresses, and delivered in a modified binding update to its correspondent nodes and home agent. When the packet arrives at one of the specified care-of addresses, then the access router determines whether to deliver the packet to the mobile node directly, or whether instead to relay the packet to the next care-of address. To facilitate this process, all potential care-of addresses are included in the data packets. 9. Network-Controlled vs_Mobile-Controlled Handover Generally, handovers are considered to fall into one of two classifications: - Network-Controlled, whereby some entity in the serving domain directs the establishment of a new link between the mobile node at some point of attachment determined by the network elements Perkins, editor Expires 20 May 2001 [Page 8] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 - Mobile-Controlled, whereby the mobile node is responsible for determining its new point of attachment and carries out the necessary protocol for making the determination as well as establishing the link at the new attachment point. Designs for IPv6 network-controlled handover have various interactions with Stateless Address Autoconfiguration, Neighbor Discovery, and any other protocols relevant to link establishment. Features of these protocols of the most particular interest include Duplicate Address Detection, Neighbor Unreachability Detection, and Router Advertisement and Solicitation. In all cases, however, authentication of the mobile node is crucial. Mechanisms that trigger the network-controlled handover have to be safe against bogus nodes masquerading as the mobile node for which the network is providing a controlled handover. When the mobile node provides the signal that causes the network elements to finalize (or commit) the results of the handover, that finalizing signal also has to be authenticated in order to avoid losing handover state. When wireless links are used, it is often required that the mobile node report or keep track of the relative signal strength from multiple network entities. While the mechanisms for making such reports is beyond the scope of this document, it is still worthwhile to keep in mind that such measurements can provide a good basis for determining when a handover is likely to be beneficial. 9.1. Mobile-controlled Handovers There is no sharp dividing line between network-controlled and mobile-controlled handovers. For instance, the network may initiate a mobile controlled handover by providing precise information to the mobile node about how and when to carry out the handover operations. The choice of handover strategy also depends on characteristics of the physical medium and MAC layer protocols. For instance, if the mobile can receive packets from multiple access routers at the same time, then it is easier to design a mobile-controlled handover operation that can avoid packet losses. "Make-before-break" schemes are likely to depend on the viability of receiving packets over multiple communications links during the handover. 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 "next" 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 Perkins, editor Expires 20 May 2001 [Page 9] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 then be mapped in the AR to a neighbouring or the current subnet. Hence the appropriate information can be communicated to the MN. If the AP identifier is mapped to the existing subnet, the AR will send an advertisement containing the current set of prefixes, implying that no L3 handoff is needed. On the other hand, if the AP is mapped to the "next" subnet, the appropriate set of prefixes will be sent with the necessary extensions shown below. 9.2. Network-Controlled Handovers If, on the other hand, the mobile node has to completely relinquish access from one communications channel before it can have access to a new one (say, from a new access router), then it is more difficult for the mobile node to avoid packet losses and delays without assistance from network entities. If the network delivers information about the new point of attachment to the mobile node before the previous point of attachment is deallocated, then the mobile node can proceed to establish its new link. In some circumstances, this still requires a noticeable delay while the mobile retunes its physical network interface electronics. In some cases, the access routers, possibly along with other mobility-aware support points away from the periphery of the network, may be able to take actions independently of the mobile node in order to reduce the signaling load over the wireless links. This would allow a mobile node to benefit from much faster establishment of connection state at the new access router, because the handover state would be available right away without having to wait for the completion of a request message to be sent to the previous access router. If the handoff intiation is done by the access routers, then the AR needs to get the relevant L2 indication regarding the MN's movement. When the L2 indication is received, the AR will need to determine if the MN is moving within its subnet or to a new one (whether L3 handoff is taking place or not). If L3 handoff is taking place, the AR should send the set of prefixes relevant to the "next subnet. For the previous access router to be able to provide subnet prefix information to the mobile node, it has to be able to determine the information. This can be done by manual configuration, or alternatively by another protocol related to router advertisement and solicitation. If there is time for the mobile node or the previous access router to solicit the information after a layer-2 trigger for handover is received, then additional steps can be taken at that time, reducing Perkins, editor Expires 20 May 2001 [Page 10] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 the need for automatic protocols between the access routers or static configuration. 10. Tunnel Extension When a mobile node moves to a new access router, it is possible that a routing path or tunnel should be established between the old and the new access router for the purpose of relaying packets still in flight towards the previous care-of address. This tunnel can help achieve a smooth handover by avoiding dropped packets. The tunnel can be established either by direct action of the mobile node, as with Mobile IPv6, as mentioned in section 6. It may also be established by any of several techniques associated with network-controlled handovers. 11. Handover Features There are many kinds of features that may be associated with handovers. Some of them MAY be described in a later revision this document. However, as a general rule, a feature should only be considered for inclusion along with a Binding Update if it satisfies two properties: - It is associated with operation of the mobile node at the network layer. An example might be packet marking for diff-serv. - It has time-critical performance requirements. Any feature that can be satisfied after the mobile node has established its new care-of address should be handled separately, in order to avoid delaying the other features that have more stringent requirements. Note that inclusion of a handover feature with a Binding Update makes the implicit assumption that the mobile node actively requests handover for that feature. For considerations about network-controlled handovers, see section 9. 12. Handover Between Two Operator Domains The users may need to roam between two operator domains. These operators may have roaming agreements with each other. Even though the roaming agreements are valid, the new domain may need to check the identity of the user before it provides service. Hence the new domain may need to contact the old domain via AAA server etc. Perkins, editor Expires 20 May 2001 [Page 11] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 These procedures take an significant amount of time, and that could adversely affect mobile's real-time applications. It is proposed that in situations like this the mobile is first allowed into the new domain without any authentication, to avoid disruption of service. Once the mobile is allowed in, the new domain may decide to authenticate the mobile via AAA. If it determines that this mobile is a legitimate user the service continues, if not the service is terminated. 13. Ping-Pong Effect A mobile node might conceivably keep performing handovers in a rapid manner between two adjacent access points. This effect is commonly known as the ping-pong effect or thrashing in cellular systems. Cellular systems have various layer 2 mechanisms in place to deal with the ping-pong effect. 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. What are the considerations and issues for a layer 3 handover when a mobile node gets into a ping-pong scenario? One possibility is to let layer 2 deal with it and not do anything special at layer 3. The problem at layer 3 is that a mobile node may believe that it is about to perform a handover and initiate handover signaling as it moves from the previous access router to the new access router. However as soon as the mobile node performs a handover and is attached to the new access router, either the mobile node or the network again initiates a handover back to the previous access router. This may cause the mobile node to lose packets from CNs and the HA and also introduces unnecessary signaling in the network. Layer 2 schemes for dealing with the ping-pong effect may work when both the access points are of the same technology. Ping-pong between two access points of different technologies cannot be solved at layer 2, and should be handled by layer-3 Fast Handover scheme. One solution is to have the mobile node maintain a history of the access routers that it is visiting. If the mobile node realizes that it is doing a many rapid handovers between the same two access routers, it should stabilize its connectivity at one of the access routers. 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 deficiences which may result in packets dropped for the duration of the ping pong. Bicasting (see section 7) is intended to be a solution to this problem. To be able to handle this phenomenon, the MN may issue a Perkins, editor Expires 20 May 2001 [Page 12] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 bicast request through the "old" AR and before the MN moves to the "new" AR. In this case the old AR will act as an anchor point for the MN and forward packets to both COAs. 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. This type of dynamic hierarchy is best suited to routers serving large coverage areas, where IP mobility may not occur very frequently. For other mobility scenarios where handoffs are frequent, it may be more beneficial to place the anchor point on a topologically higher level resulting in a more static hierarchy. However, in either architecture (flat or hierarchical) bicasting from an anchor point can be achieved using the same extensions. 14. Obtaining a new CoA One of the factors contributing to the latency during handoff is the latency to obtain the CoA in the new subnet. CoA in the new subnet can be obtained by stateful or stateless mechanisms. Optimizations to reduce the latency involved in this process should be considered. The procedure to obtain an CoA involves creating an interface address (stateless mechanism) or obtaining an interface address in the case of a stateful mechanism, and verifing that the address is unique. The Duplicate Address Detection algorithm is performed on all addresses, independent of whether they are obtained via stateless or stateful autoconfiguration. It is possible that a site/access medium believes that the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled. Although it is possible for creating unique address most of the time, with out mechanisms having to execute prodecures such as DAD, the fast handoffs mechanisms should not be based on the premise that it is possible to create such unique addresses. If mechanisms such as DAD are latency intensive optimizations/alternatives such be considered. There are several problems of obtaining a CoA while the mobile is not in the subnet to perform its own DAD. If this is assumed the following need to be solved in a practical way. If the Mobile performs it own DAD, the following issues arise: - How does the node know the prefix of the AR? - How is the neighbor solicitation messages sent to the new subnet? Perkins, editor Expires 20 May 2001 [Page 13] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 - How are the Neighbor Advertisements relayed to the Mobile? - What happens if the mobile moves in the middle of the DAD? Alternatively the new AR could perform DAD and act as a proxy for the mobile node before it moves to the new link. 15. Latency of DAD In order to perform Duplicate Address Detection, the node sends to Neighbor Solicitation a configured number of times and after the last Neighbour Solication is sent a configured about of has to elapse prior to assuming the unique ness of the address. This involves considerable latency. Possible solutions are: 1. Perform stateful autoconfiguration without DAD 2. Use AR CoA as specified in draft-dommety-mobileip-lma-ipv6-02.txt 3. Create the CoA, assume that it is unique but perform DAD later (might create some problems). 4. Perform stateless autoconfiguration without DAD, by optimistically assuming that the mobile node's lower-order 64 bits address bits are very unlikely to experience any duplication in the network link served by the new access router. Note that DAD does not prevent a malicious user from using an address even thought DAD fails. 16. Handover Scenarios In this document, we classify the various handover cases according to how the initial network-layer message is sent. This first network-layer message is called the PD. It may be sent in response to various kinds of stimuli at lower layers protocols. For instance, signal strength measurements carried out at the link layer or below may provide a handover trigger which causes the PD to be sent. There are four cases: 1. mobile node sends PD to new access router with link connectivity to the new access router 2. new access router sends PD to mobile node with link connectivity to the mobile node Perkins, editor Expires 20 May 2001 [Page 14] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 3. mobile node sends PD to previous access router with link connectivity to the previous access router 4. previous access router sends PD to mobile node with link connectivity to the mobile node In the following subsections, we enumerate various sub-cases for each of the above cases. In section 17, we outline message control flows corresponding to appropriate subcases of the most interest. Finally, in section 18, we specify message formats for the messages in those control flows. 16.1. Mobile Node sends PD with Link Connectivity to New Access Router If the mobile sends an unauthenticated message, it can be formulated as part of router discovery; subsequent messaging would be the same as in subsection 16.2. Assuming that the mobile node sends out an authenticated message, the following possibilities exist. 1. Mobile node makes up a CoA and performs DAD and asks the old AR to forward the packets to the new CoA. 2. Mobile node makes up a CoA and does not perform DAD and asks the old AR to forward to the new CoA. 3. Mobile node does not get a CoA and asks the old AR to tunnel the packets to the new AR. The New AR delivers the packets based on old CoA. 4. Mobile node requests the new AR for a new CoA (Stateful) and the old AR asks the new AR to forward packets to the new CoA Questions: How does the mobile node know the new AR? One suggested method is: The IP address for this AR+ should be included in the router advertisement. When the MN has a data link connection to the new sub-net it will get this new AR+ address from the RA. The AR+ functionality should support: - AAA interface in the future. - new messages which we will propose. - proxy for the MN (e.g. allocating COA in behalf of the MN). Perkins, editor Expires 20 May 2001 [Page 15] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 16.2. New Access Router sends PD with Link Connectivity to Mobile Node There are three subcases: 1. The new AR sends PD only to tell the mobile that it moved. 2. The new AR sends its Address in PD, that is used by the mobile for two purposes: to detect movement and to ask the old AR to forward packets to the new AR. 3. The new AR assigns a new unique CoA and sends it to the mobile. Here there are two subcases: - The mobile asks the old AR to forward packets to the new CoA - The new AR asks the old AR to forward packets to the new CoA (on behalf of the mobile). 16.3. Mobile Node sends PD with Link Connectivity to Previous Access Router This is a Mobile Initiated Handoff. The previous access router in this case is still the MNs current default router, that is, the MN has not yet moved to the target AR or is not link layer connected (via some access point) to the target AR. The mobile has link layer connectivity to the Previous AR. The previous AR can either process the PD or forward it to the New AR. Two cases arise due to timing of the link-layer disconnect - The link layer connection to the old AR is intact until the PD is acknowledged. If the handoff scheme is assuming that the mobile is receiving some information such as new CoA etc from the old AR, then the link layer to the old AR is assumed to be intact until the PD is acknowledged, under normal conditions. - The link layer connection to the old AR could be torn down before the acknowledgment is received. In this case the normal operation of the protocol does not assume that the PD is acknowledged. There are two cases that arise depending on the amount of processing done by the previous AR. - The Old AR processes the PD. After the processing it could initiate a message sequence with the New AR (if known). Perkins, editor Expires 20 May 2001 [Page 16] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 - The Old AR simply routes the PD. The PD is forwarded to the New AR with out processing. Three levels of information are available to the mobile; ways to obtain this information is discussed later. 1. Mobile Node knows the new AR unicast address and network prefix In this situation, there are two subcases, as follows: - The mobile node gets a new CoA in the new subnet. The New CoA can be acquired statelessly by the mobile or can be statefully assigned by the new AR. The advantage of stateful method is that the new AR might cache some addresses which are already known to be unique, so it can offer one immediately when MN asks for it. According to RFC 2462 [4] DAD may be required for addresses obtained via stateful auto-configuration: "All addresses obtained manually or via stateful address auto configuration SHOULD be tested for uniqueness individually". For either stateless or stateful address autoconfiguration, there are two cases, depending on whether DAD is to be performed. The time to perform DAD is likely to be a concern. If DAD is needed in this case, the New AR has to perform DAD on the behalf of the mobile. It may be necessary to have an indication that tells the Mobile/Old AR that DAD is required on the new subnet. This applies to scenarios where CoA can be constructed uniquely using some mechanisims. - Mobile does not get a new CoA. Packets are forwded to the current CoA for a while. In this scheme the old AR forwards packets to the new AR. The new AR delivers the packets to the mobile based on the old CoA. Since there is connectivity, the mobile does not see a break in communication. At a later point in time, the mobile acquires a new CoA and performs a binding update. 2. Mobile Node knows the prefix of the New AR but does not know the New AR addess. This makes DAD difficult, so we can assume that DAD is not performed. In that case, the mobile node might be able to formulate a new CoA and ask the previous AR to bicast, or unicast to the new CoA. Perkins, editor Expires 20 May 2001 [Page 17] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 If the MN does not know its new AR, then it is very costly to figure it out, so this scenario may be a little bit unrealistic. We should figure out a scheme to calculate the address of the new AR if we know the network prefix. One way is to calculate any-cast address for the new AR and forward our messages to this any-cast address. On the other hand, if the mobile node gets the prefix information, it might not be a substantially greater effort to configure the new AR corresponging to the prefix. DISCUSSION NOTE: Alper, Mohamed Khalil, and Gopal feel that this is unrealistic. Hesham feels otherwise. 3. Mobile Node does not know the new AR or the prefix of the New AR In this case the mobile can request information from another entity (such as Old AR), if its get either the new AR unicast address or the prefix information, that scenario can be reduced to the above mentioned scenarions (3.1, and 3.2). Getting the New AR information at the mobile. A. No information about new AR. B. L2 has enough information embeded. This helps the mobile to get L3 details such as new AR or Prefix. C. Mobile sends a L3 information to the old access router and asks for information. An illustration of this is as follows: * MN figures out the link it's moving to. * Then it sends a message (an RS with an extension) to current AR. This message contains the link id (an L2 info) to AR. * AR maps this link id to newAR and newPrefix. * AR sends this info in another message (possible an RA with an extension). 16.4. Previous Access Router sends PD with Link Connectivity to Mobile Node One possibility is that the previous access router sends the message to the Mobile Node, and then all the subcases for scenario 3 (i.e., section 16.3) are applied. Another possibility is that the previous access router needs no further messages from the mobile node before Perkins, editor Expires 20 May 2001 [Page 18] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 making handover arrangements with the new access router by way of an inter-AR handover message. 17. Message flows In this section, we display some proposed message flows to take care of the most important scenarios and subscenarios detailed in section 16. The design decision has been taken to consider that scenarios 1 and 2 are already well-enough provided for by the smooth handover features of Mobile IPv6 [2]. These are the scenarios in which the PD cannot be sent until the mobile node has layer-2 connectivity to the new access router. Not much additional performance is likely to be gained, because there isn't any possibility to save time by anticipating mobile node movement, by definition. However, it is noted that schemes involving buffering can reduce packet loss even in these scenarios. For scenarios 3 and 4, in which the PD is issued while the mobile node still has layer-2 connectivity at the previous access router, another design decision has been taken. Since this specification deals with layer-3 issues, the handover is considered to require some layer three information relevant to the new access router. Specifically, the handover at layer 3 requires acquiring a new Care-of Address on the new link (see section 14), as well as prefix lifetime information and possibly other link parameters typically advertised by the new access router. Situations where the mobile node would be expected to acquire this information from advertisements from the new access router while still maintaining layer-2 connectivity with the previous access router are excluded from consideration in this specification. Otherwise, the protocol would actually become a special case of either scenario 1 or scenario 2. These have already been excluded as noted above. Thus, all solutions in this section are designed for use in situations falling under either scenario 3 or scenario 4. Furthermore, in scenario 3, the mobile node is presumed to require a care-of address before it can migrate to the new point of attachment. Thus, in scenario 3, the mobile node is presumed to require a response to its PD. Perkins, editor Expires 20 May 2001 [Page 19] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 18. Message Extension and Option Formats In this section, message and option formats are specified. The description for each message extension and option will specify which message or option it may be used with. 19. Security Considerations The security needed for smooth handover is almost the same as is needed for handling Binding Updates in IPv6. If a handover could be initiated by a node masquerading as the mobile node, a range of undesirable effects might result. The malicious node could usurp traffic destined from the mobile node, diverting it to a nearby router and possibly an unauthorized care-of address. The exact details of the possible effects would depend on the kinds of handover data available as part of the smooth handover process. 20. Acknowledgements Thanks to Yousuf Saifullah, Shavantha Kularatna, and Basavaraj for contributing the underlying text for section 5, as well as other supporting text. 21. References - Mobile IPv6 [2] - Stateless Address Autoconfiguration [4] - Neighbor Discovery [3] - Relevant drafts * draft-yegin-mobileip-nrouting-00.txt * draft-oneill-craps-handoff-00.txt * draft-elmalki-handoffsv6-00.txt * draft-mkhalil-mobileip-ipv6-handoff-00.txt * draft-koodli-mobileip-smoothv6-00.txt * draft-krishnamurthi-mobileip-buffer6-00.txt * draft-koodli-mobileip-fastv6-00.txt Perkins, editor Expires 20 May 2001 [Page 20] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 * draft-dommety-mobileip-lma-ipv6-01.txt * draft-oneill-handoff-state-00.txt And also the solutions proposed for MIPv4: - draft-calhoun-mobileip-proactive-fa-02.txt - draft-elmalki-mobileip-fast-handoffs-03.txt A. Application signaling When a handover event occurs, several immediate actions are likely to occur, as described in the main part of this draft. However, it is also likely that other programs may be affected by the handover. If the new access router has any significant new features, or if there are any significant features no longer available, then applications running on the mobile node may need to react to the changing conditions. Mobile IPv6, even with network-layer handover features, cannot operate on behalf of all possible applications. Thus, for those applications that need the information, a handover signal should be defined and made available. This will be have to be done in a system-dependent manner, so any further specification is outside the scope of this document. However, it may be appropriate for this signal to emanate from the same software that processes the network-layer handover features. B. Context Transfer In order to make link utilization more efficient, and to counteract certain known features of slow and/or lossy transmission media such as radio, mobile devices frequently establish some local state with the access router. For instance, a device may be identified by some means other than its IEEE MAC address, because the latter takes up too many bits over the slow medium. As another example, it may be advantageous to transfer security associations between access routers instead of having to re-establish those associations with distant entities in the network. Each particular piece of local state is potentially liable to be created separately at each new link establishment if steps are not taken otherwise. As the mobile node move from one access router to another in the IPv6 Internet, each kind of context and state is a candidate for handover from the previous access router to the new access router. As another example of context being used to improve performance for a mobile node, one may use buffering at either the new access router or the old access router (or both) to avoid dropping packets during Perkins, editor Expires 20 May 2001 [Page 21] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 the (presumably quite short) time during which a mobile node may be disconnected from both network links. Mobile IPv6 already offers some rudimentary handover features. For instance, a mobile node may send a Binding Update to its previous router. This causes the previous router to redirect packets towards the new care-of address of the mobile node. It is reasonable to view this process as assigning new state information (at the previous router) indexed by the care-of address of the mobile node. The previous router redirects packets by tunneling them to the mobile node's new care-of address, which is provided by the mobile node in the Binding Update. It is worthwhile to note that all such bits of state and context that are established by the mobile node with its access router tend to encumber the connectionless nature of IP itself. If there were no state at all, the mobile node could just send data at the new access router, and all packets sent to the previous router would be lost because the mobile node is not receiving packets there any more. In a pure connectionless architecture, losing packets is not necessarily a violation of protocol. Making the data stream reliable is viewed as a higher-level function. The intention in this draft is to explore ways to introduce the minimal amount of connection-oriented behavior into Mobile IPv6 so that the recognized pitfalls of unassisted handovers can be avoided. In this way, performance enhancements are possible that may be unavailable from higher level protocols. Perkins, editor Expires 20 May 2001 [Page 22] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in progress). draft-ietf-mobileip-ipv6-12.txt, April 2000. [3] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [4] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola 6000 Connection Drive 1501 West Shure Drive M/S M8-540 Irving, Texas 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com EMail: QA3445@email.mot.com Perkins, editor Expires 20 May 2001 [Page 23] Internet Draft Fast Handovers for Mobile IPv6 20 November 2000 The authors of this document are: Gopal Dommety Cisco Mohamed Khalil Nortel Basavaraj Patil Nokia Charles E. Perkins Nokia Phil Roberts Motorola Hesham Soliman Ericsson George Tsirtsis Flarion Alper Yegin Sun Microsystems Questions about this memo can also be directed to the editor: Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Perkins, editor Expires 20 May 2001 [Page 24]