James Kempf Internet Draft DoCoMo Communications Laboratories USA Document: draft-kempf-mobileip-fastho-lmm-00.txt Dana Blair Expires: December 2002 Cisco Systems June 2002 Paul Reynolds Orange Alan O'Neill Flarion Leveraging Fast Handover Protocols to Support Localized Mobility Management in Mobile IP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This draft is an individual submission to the Mobile IP working group. 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 Longstanding work in the Mobile IP Working Group has been directed at enhancements to Mobile IPv4 and Mobile IPv6 to reduce the amount of latency in binding updates sent to the Home Agent and, for route- optimization, Correspondent Nodes, upon Care of Address change. In cases where the Home Agent and Mobile Node are separated by continental or transcontinental distances, this latency can be rather high and can interfere with the Mobile Node receiving its traffic upon Care of Address change when break-before-make handover is required. This draft discusses a solution that leverages the more recent fast handover work and mechanisms already described in the protocol specifications for Mobile IPv6 and the route optimization extension of Mobile IPv4. This alternative has certain simplicity, scalability, and robustness advantages over a design that incorporates additional mobility agents, and requires no additional mechanism in the network or change to the Mobile Node beyond that required to support these protocols. Kempf, et. al. [Page 1] Internet Draft Fast Handover and LMM June, 2002 Table of Contents 1.0 Introduction.................................................2 2.0 Fast Handover Approach.......................................3 3.0 Advantages of the Fast Handover Approach.....................4 4.0 Applicability Statement and Further Work.....................5 5.0 Security Considerations......................................6 6.0 References...................................................6 7.0 Author's Contact Information.................................7 8.0 Full Copyright Statement.....................................7 1.0 Introduction In the base Mobile IP protocol [1][2], movement between two subnets requires that the Mobile Node obtain a new Care of Address in the new subnet. This allows the Mobile Node to receive traffic on the new subnet. In order for the routing change to become effective, however, the Mobile Node must issue a binding update (also known in Mobile IPv4 as a Home Agent registration) to the Home Agent so that the Home Agent can change the routing from the previous subnet to the new subnet. The binding update establishes a host route on the Home Agent between the Mobile Node's Home Address and its new Care of Address. In addition, if route optimization is in use [2], the Mobile Node may also issue binding updates to Correspondent Nodes to allow them to send traffic directly to the new Care of Address rather than tunneling their traffic through the Home Agent. When using break-before-make handover, traffic destined for the Mobile Node is sent to the old Care of Address and is, effectively, dropped until the Home Agent processes the MIPv6 Binding Update or MIPv4 Home Agent Registration. If the Mobile Node is at some geographical and topological distance away from the Home Agent and Correspondent Nodes, the amount of time involved in sending the binding updates may be greater than 100 hundred milliseconds. This latency in routing update may cause some packets for the Mobile Node to be lost at the old Access Router. This problem has been called "localized mobility management," and a set of requirements for a solution have been developed in the context of Mobile IPv6 [8]. In this draft, we propose the following alternatives: o The protocols developed for Mobile IP fast handover [5][6], o The forwarding from previous Foreign Agent functionality in the Mobile IPv4 route optimization specification [7], o The local Home Agent functionality in the base Mobile IPv6 specification [2]. Kempf, et. al. [Page 2] Internet Draft Fast Handover and LMM June, 2002 Our contention is that these protocols, when implemented and deployed, already provide support for localized mobility management, since they allow the Mobile Node to continue receiving traffic on the new subnet without any change in the Home Agent or Correspondent Node binding. The latency involved in updating the Care of Address bindings at far geographical and topological distances is eliminated until such time as the Mobile Node is in a position to manage the latency cost. These protocols do not directly reduce the latency of Home Agent binding, but rather, they serve to manage the latency such that the frequency and impact are reduced during break-before- make handover. We argue that the resulting design is simpler, more robust, and more scalable than designs involving stateful mobility agents, and also potentially less expensive to deploy. 2.0 Fast Handover Approach The Mobile IP working group has been examining mechanisms to enable a Mobile Node to obtain traffic on its new subnet prior to fully changing the Care of Address at the Home Agent. The intent of this work was to further optimize IP subnet handover so that continuity of real time traffic streams to and from the Mobile Node could be maintained. These approaches have been called "fast handover," and are illustrated in Figure 2. (Note that this diagram applies to the Postreg method in [5] and [6] but not the Prereg method in [5]). * * +------------+ +------------+ ( Old Access )TTTTTTTTTTT( New Access ) ( Router ) ( Router ) ... +------------+ +------------+ * * * ~~~ +--------+ ~~~ | Mobile | ~~~ | Node | ======> ~~~ +--------+ In these methods, the old Access Router tunnels the Mobile Node's traffic to the new Access Router rather than dropping it as in standard Mobile IP (indicated by the 'T' in the above diagram) or directly to the Mobile Node via the new Access Router. Depending on the protocol and how it is deployed, these techniques are able to achieve IP subnet handover latencies that are equivalent to or only slightly greater than the link layer blackout period which is a natural consequence of break-before-make handover. In addition to the fast handover algorithms, if the Mobile Node does not implement the fast handover algorithms, traffic can be forwarded from the old Access Router to Mobile Node through use of Forwarding from Previous Foreign Agent [7] and Forwarding from Previous Care of Address [2]. These protocols are a basic part of Mobile IP or its Kempf, et. al. [Page 3] Internet Draft Fast Handover and LMM June, 2002 extensions. In these protocols, the Mobile Node sends a binding update to the old Access Router requesting that it forward traffic. The Access Router acts as an on-link Home Agent in this case. Localized mobility management can be achieved with the fast handover protocols by continuing to tunnel to the Mobile Node from the old Access Router, now called an "anchor" Access Router, when the Mobile Node moves to another Access Router. The fast handover protocols [5][6] contain a mechanism for three way handover, that allows the mobile end of the tunnel to be transferred from one Access Router to another while keeping the network end of the tunnel fixed. If the tunnel terminates at the Mobile Node, Forwarding from Previous Foreign Agent or Forwarding from Previous Care of Address is in use, the Mobile Node sends a binding update to the old Access Router after it has moved requesting that the old Access Router tunnel any packets underway to the new Access Router. In turn, the old Access Router can inform the anchor Access Router using the inter-router fast handover signaling in the fast handover protocols to switch the end of the tunnel to the new Access Router. After the tunnel between the anchor Access Router and old Access Router has cleared, it can be brought down to avoid tunnel chaining. At some point, the Mobile Node's current Access Router may signal the Mobile Node to actually complete Home Agent binding update, or the Mobile Node's traffic pattern may be such that the Mobile Node decides it can afford to pay the latency cost of Home Agent binding update Note that the fast handover protocols in and of themselves do not specifically solve the Home Agent binding latency problem, since they do not remove Home Agent binding latency, they only postpone it. Their contribution is rather to mitigate the negative effect of the problem on the Mobile Node's IP service, namely that the Mobile Node's traffic gets dropped on the old Access Router. In addition, since fast handover technique of some type is required regardless of whether a Mobility Agent is deployed if real time traffic is to be accommodated, implementation and deployment is considerably simplified if the fast handover algorithms can be used for localized mobility management too. Even with a Mobility Agent in the domain, the latency of binding update to the Mobility Agent will cause packets to be lost if the old Access Router doesn't forward them. 3.0 Advantages of the Fast Handover Approach The main characteristic of the fast handover approach is that it keeps state involved with Mobile Node location in the Access Routers, which must deal with that state anyway, rather than introducing another agent at a location topologically remote from where the action is. Consider what happens when an anchor Access Router crashes. Some number of bindings between tunnel end points and Mobile Node Care of Addresses are lost, in addition to service for Mobile Nodes which Kempf, et. al. [Page 4] Internet Draft Fast Handover and LMM June, 2002 are locally resident on the subnet. Service may be resumed quickly if another Access Router is associated with the same subnet. However, the outage only affects those Mobile Nodes that are utilizing the down Access Router as their anchor, and the locally resident Mobile Nodes. Locally resident Mobile Nodes on other subnets and tunnel bindings in other Access Routers are not affected. The topological impact of the outage is thus considerably less than for a Mobility Agent. Since the Access Router doesn't need special engineering for high reliability, it can be produced much more cheaply. Reliability can be achieved by having multiple Access Routers on the subnets. The Access Routers also provide replicated service on a daily basis for load balancing. The cost of the resulting system might be expected to scale according to typical IP methods with push state to the edge of the network, access router and/or MN, where the impact of a failure is minimized. If the Mobile Node's fast handover support is designed to take advantage of slack traffic to register with the Home Agent, then an interruption in service due to an anchor Access Router crashing should automatically trigger registration at the Home Agent. The Mobile Node's traffic is quickly restored when the binding completes, limiting the outage. Leveraging fast handover for localized mobility management also has other advantages: o If the end of the tunnel terminates at the Access Router, there is no tunnel encapsulation overhead on the link. Some fast handover protocols allow tunnel termination at the Access Router, while others terminate the tunnel at the Mobile Node. o Because the fast handover protocols are required for good handover performance anyway, no additional mechanism is required to eliminate Home Agent binding latency. This considerably simplifies the implementation of the Mobile Node and Home Agent. o Network management is improved because there are no new agents and agent advertisement protocols requiring management. Management of Access Routers is required regardless of whether Mobility Agents are deployed, so not having to deploy them removes a source of management work. 4.0 Applicability Statement and Further Work Many current wireless network deployments consist of an aggregation router connected by low speed, point to point links with a collection of Access Routers in a star topology. The architecture proposed here assumes that either Access Routers the have a high capacity connection with the aggregation router or that the Access Routers are interconnected and connect to the backbone with a topology different than a star. Tunneling between Access Routers requires the Mobile Node's traffic to traverse the link between the aggregation point router and the Access Router twice, once down and Kempf, et. al. [Page 5] Internet Draft Fast Handover and LMM June, 2002 once back through the tunnel. If the capacity of the link between the aggregation point router and the Access Router is low compared to combined MNs expectations, then the additional overhead may make the fast handover solution uneconomical relative to a Mobility Agent solution where the Mobile Node's traffic only traverses the link once. The fast handover inter-router signaling in [5][6] could be extended to allow the Access Router to signal the aggregation router to handle the tunnel. This would allow the higher capacity aggregation point router to perform tunneling of the Mobile Node's traffic prior to sending it down the T1 line to the old Access Router. In some cases, if a Mobile Node is moving across a cluster of Access Routers connected by T1 lines to the same aggregation point router, the tunnel might only need to extend from the aggregation point router to another Access Router within the cluster. The tunnel overhead on such a configuration is no more than for a Mobility Agent configuration. When the Mobile Node moves off the cluster, the new Access Router could signal the Mobile Node to complete Home Agent binding for a new Care of Address, or it could continue to provide tunnel service, depending on the capacity of the connection between the aggregation point router and the new Access Router. This option requires additional work to determine the effect on multicast, reverse tunneling, backward compatibility with existing Mobile IP implementations, and inter-technology handover. 5.0 Security Considerations The security of the Mobility Agent protocols and fast handoff protocols are described in their specifications. This draft introduces no new security considerations. 6.0 References [1] Perkins, C., "IP Mobility Support for IPv4," RFC3220, January 2002. [2] Johnson, D., et. al. " Mobility Support in IPv6," draft-ietf- mobileip-ipv6-17.txt, a work in progress. [3] Gustafsson, E., et. al., "Mobile IPv4 Regional Registration," draft-ietf-mobileip-reg-tunnel-06.txt, a work in progress. [4] Soliman, H., et. al., " Hierarchical MIPv6 mobility management (HMIPv6)," draft-ietf-mobileip-hmipv6-05.txt, a work in progress. [5] El Malki, K., et. al., "Low Latency Handoffs in Mobile IPv4," draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt, a work in progress. [6] Dommety, G., et. al., "Fast Handovers for Mobile IPv6," draft- ietf-mobileip-fast-mipv6-04.txt, a work in progress. [7] Perkins, C., and Johnson, D., "Route Optimization in Mobile IP," draft-ietf-mobileip-optim-11.txt, a work in progress. [8] Williams, C., "Localized Mobility Management Requirements for IPv6," draft-ietf-mobileip-lmm-requirements-01.txt, a work in progress. Kempf, et. al. [Page 6] Internet Draft Fast Handover and LMM June, 2002 7.0 Author's Contact Information James Kempf Phone: +1 408 451 4711 DoCoMo Communications Email: kempf@docomolabs-usa.com Laboratories USA 180 Metro Drive Suite 300 San Jose, CA USA 95430 Dana Blair Email: dblair@cisco.com Cisco Systems Phone: +1 678 352 2789 Paul Reynolds Phone: +44 7 973 746 050 Orange Email: paul.reynolds@orange.co.uk Bradley Stoke Bristol UK Alan O'Neill Phone: +1 908 947 7033 Flarion Technologies Email: oneill@flarion.com 8.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kempf, et. al. [Page 7]