1. Introduction and Overview 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. 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. In the present context, this may be viewed as assigning new state information (at the previous router) to 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. It is also noteworthy that most link establishment protocols are, naturally, concerned with the mobile node's care-of address, with 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. There are many 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 requires Duplicate Address Detection, which also can have the effect of inserting 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. 2. Scope of the Solution The main goal is to minmise the delay in routing packets to the mobile node as it moves from one point of attachment to another. We will consider just the routing of packets aspect of the problem and not focus (initially) on transfering any context related information that a MN may have at its previous point of attachment. Multiple scenarios need to be considered. The solution is required to enable improved handoffs in the following scenarios: a. Intra-technology handoff (Single domain) b. Intra-technology handoff (between administrative domains) c. Inter-technology handoff (Single domain) d. Inter-technology handoff (between administrative domains) The handoff solution should also be specified to work whether the mobile node is in idle or in active mode. The handoff 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. The handoff 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 handoff solution should work well with the protocols needed to maintain routing through the agent hierarchy. The handoff solution should not depend on the specifics of any air-interface or layer two (L2) technologies. Triggers from L2 can be incorporated into the solution space. The solution MAY allow for later extensions to account for layer two specific features. 3. Terminology Access Router -- the router offering connectivity to the mobile node at its new 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 Fast Handover -- a handover operation that minimizes or eliminates delay for establishing new communications paths to the mobile node at 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. Serving Domain -- the administrative network domain which contains the access routers serving the mobile node. 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 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 minimum value will be specified in this document. Note further that the delay measured for handover operations is the time from the last connectivity between the mobile node and its previous access router, to the time when the context transfer to the new access router has been completed. Thus, it is possible for some handover operations to cause zero delay. Negative values are not considered useful for discussion in this document. Question: Is this an Informational Internet Draft? 4. 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. In the case where the mobile node sends a Binding Update to its previous access router, the access router tunnels packets sent to the old 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 very short lifetime. See [MobileIPv6] for details. For mobile-controlled handovers (see section 5.2), it is natural to associate any additional handover features to this Binding Update, since it is the first opportunity that the mobile node has to communicate such requests to its previous access router. Furthermore, just as with the Binding Update, the handover request has to be accompanied by authentication data that may be used by the previous router to make sure that the handover request has indeed been issued by the intended mobile node. 5. 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 - 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. For IPv6, naturally, designs for network-controlled handover are likely to have various interactions with Stateless Address Autoconfiguration, Neighbor Discovery, and other features of link establishment in IPv6. 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. 5.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. 5.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 many 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. 6. Tunnel Extension When a mobile node moves to a new access router, it is possible that a tunnel will 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, or by any of several techniques associated with network-controlled handovers. 7. 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 by 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 the next session. at this point, we could list the various handover features that have been mentioned (e.g., by George Tsirtsis et al.). 8. Interactions with Regional Registrations Seamless handover has to do with enabling the mobile node to move from one point of attachment to another within a serving domain. Regional Registration 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 care-of address instead of the previous packets. Regional Registration 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 is likely to 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 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. 9. How to do it If there is any general agreement about the use of the a particular solution, that would go here. 10. 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 context that were available as part of the smooth handover process. 11. Acknowledgements Thanks to Basavaraj Patil for contributing the text from which section 2 was developed. 12. References - Mobile IPv6 - Stateless Address Autoconfiguration - Neighbor Discovery - Relevant drafts = Bicasting = CRAPS = LMA (?) = LIMIPH (?) = draft-yegin-mobileip-nrouting-00.txt = draft-oneill-craps-handoff-00.txt = draft-elmalki-handoffsv6-00.txt = Efficient and FAST Handoff Technique (Posted on 10/4) to this list and to be issued as an I-D in the next few days = draft-koodli-mobileip-smoothv6-00.txt And also the solutions proposed for MIPv4: - draft-calhoun-mobileip-proactive-fa-02.txt - draft-elmalki-mobileip-fast-handoffs-03.txt APPENDIX: Application signaling When a handover event occurs, several immediate actions are likely to occur, as described in previous sections. 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.