INTERNET-DRAFT Carl Williams, Editor Internet Engineering Task Force DoCoMo USA Labs Issued: June 28, 2002 Expires: December 28, 2002 Localized Mobility Management Requirements Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 describes requirements for Localized Mobility Management (LMM) for Mobile IP and Mobile Ipv6 protocols. These requirements are intended to guide the design of a protocol specification for LMM. Localized Mobility Management, in general, introduces 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 addition, LMM seeks to reduce the amount of signaling over the global Internet when a mobile node traverses within a defined local domain. The identified requirements are essential for localized mobility management functionality. They are intended to be used as a guide for analysis on the observed benefits over the identified requirements for architecting and deploying LMM schemes. Carl Williams, Editor Expires December 28, 2002 [Page 1] INTERNET DRAFT Localized Mobility Management Requirements June 2002 Table of Contents 1.0 Introduction .................................................... 2 2.0 Terminology ..................................................... 4 3.0 Requirements .................................................... 5 3.1 Intra-domain mobility ........................................ 5 3.2 Security ..................................................... 5 3.3 Induced LMM functional requirement ........................... 6 3.4 Scalability, Reliability, and Performance .................... 6 3.5 Mobility Management Support .................................. 8 3.6 Auto-configuration capabilities for LMM constituents.......... 8 3.7 Interworking with IP routing infrastructure requirement....... 9 3.8 Sparse routing element population requirement ................ 9 3.9 Support for Mobile IPv6 Handover ............................. 9 3.10 Simple network design requirement ........................... 9 3.12 Stability ................................................... 10 3.13 QoS Requirements ............................................ 10 4.0 Acknowledgments ................................................. 10 5.0 References ...................................................... 11 6.0 Author's Addresses .............................................. 12 7.0 Full Copyright Statement ........................................ 12 1.0 Introduction In order to meet the demands of real-time applications and the expectations of future wireless users for service level quality similar to the one of wireline users, base mobility management in IP networks, and in particular Mobile IP and Mobile IPv6 is facing a number of technical challenges in terms of performance and scalability. These manifest themselves as increased latencies in the control signaling between a Mobile Node and its peer entities, namely the Home Agent (HA) and its Corresponding Nodes (CNs). In the base Mobile IP protocol [6][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. 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 Carl Williams, Editor Expires December 28, 2002 [Page 2] INTERNET DRAFT Localized Mobility Management Requirements June 2002 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 (LMM)". Localized mobility management schemes 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 or reduced until such time as the Mobile Node is in a position to manage the latency cost. Having provided some motivation and brief summary of the underlying principles of LMM, it is important to enumerate goals for LMM. Goals for LMM: - reduce the signaling induced by changes in the point of attachment due to the movement of a host; reduction in signaling delay will minimize packet loss and possible session loss; - reduce the usage of air-interface and network resources for mobility; - reduce the processing overhead at the peer nodes, thereby improving protocol scalability; - avoid or minimize the changes of, or impact to the Mobile Node, Home Agent or the Correspondent Node; - avoid creating single points of failure; - simplify the network design and provisioning for enabling LMM capability in a network; - allow progressive LMM deployment capabilities. Identifying a solid set of requirements that will render the protocol internals, for some LMM scheme, robust enough to cater for the aforementioned considerations becomes essential in designing a widely accepted solution. The remainder of this document present a set of requirements that encompass essential considerations for the design of an LMM scheme. It is with this foundation that we can seek to ensure that the resulting LMM solution will best preserve the fundamental philosophies and architectural principles of the Internet in practice today. Carl Williams, Editor Expires December 28, 2002 [Page 3] INTERNET DRAFT Localized Mobility Management Requirements June 2002 2.0 Terminology See [2] for additional terminology. Administrative Domain A collection of networks under the same administrative control and grouped together for administrative purposes. [2] Local Mobility The movement of an IP device without requiring a change to its routable IP address seen by the CN or HA. Although its point of attachment may change during the move, the IP addresses used to reach the device (both its home and globally visible routable IP address) do not change. Local Coverage Area A Local Coverage Area (LCA) contains one or more (LCA) IP subnets. Within the LCA, the globally visible routable IP address assigned to a Mobile Host or Mobile Router serving a Mobile Network does not change. Local Mobility Agent A Mobile Node may use a Local Mobility Agent to (LMA) carry out the local mobility mangement functionality. The LMA functionality will reside on router(s) within the Local Coverage Area. Localized Mobility A method of moving an IP device without requiring Management (LMM) a change to its routable IP address seen by its peers, namely the MN's HA and its CNs, in order to restrict the signaling area, thus possibly reducing the amount of signaling. Strong Authentication Techniques that permit entities to provide evidence that they know a particular secret without revealing the secret. [3] 3.0 LMM Requirements This section describes the requirements of a LMM solution. The requirements are relevant to both Mobile IPv4 and Mobile IPv6. Carl Williams, Editor Expires December 28, 2002 [Page 4] INTERNET DRAFT Localized Mobility Management Requirements June 2002 3.1 Intra-domain mobility LMM is introduced to minimize the signaling traffic to the Home Agent and/or Correspondent Node(s) for intra-domain mobility (within an Local Coverage Area). This is the fundamental reason for introducing localized mobility management extensions to core Mobile IPv6. In the LMM infrastructure a Correspondent Node or Home Agent outside the administration domain MUST always be able to address the mobile host by the same IP address, so that from the point of view of hosts outside the administration domain, the IP address of the mobile host remains fixed regardless of any changes in the Mobile Node's subnet. It is not the intent or goal for LMM to enter the intra-subnet (intra AR) mobility problem space. See [4] for more information on this specific problem space. 3.2 Security 3.2.1 LMM protocol MUST provide for "security provisioning" within the respective local coverage area. The security of exchanging LMM specific information and signaling MUST be ensured. Security provisioning includes protecting the integrity, confidentiality, and authenticity of the transfer of LMM specific information within the administration domain. If applicable, replay protection MUST exist mutually between the LMM agents. 3.2.2 LMM protocol MUST provide for the security provisioning to be disabled. In certain environments the security within the Local Coverage Area may not be necessary, or it may be preferred to minimize the LMM protocol overhead. This feature would be used at the network operator's own risk. 3.2.3 LMM protocol MUST NOT interfere with the security provisioning that exists between the Home Agent and the Mobile Node. 3.2.4 LMM protocol MUST NOT interfere with the security provisioning that exists between the Correspondent Node and the Mobile Node. 3.2.5 LMM protocol MUST NOT introduce new security holes or the possibility for DOS-style attacks. Carl Williams, Editor Expires December 28, 2002 [Page 5] INTERNET DRAFT Localized Mobility Management Requirements June 2002 3.2.6 An LMM scheme MUST provide support for security at the level associated with routing. LMM SHOULD also ensure that the network be able to maintain topological confidentiality from visiting mobile nodes. That is to say that the LMM scheme in use SHOULD NOT reveal the visited network's topology to the Mobile Node. 3.3 Induced LMM functional requirements 3.3.1 Any Localized Mobility Management protocol MUST NOT inject any additional functionality over base Mobility [6, 9] at the Home Agent or any of its peer CNs. Thus, the LMM framework MUST NOT add any modifications or extensions to the Correspondent Node(s) and Home Agent. It is essential to minimize the involvement of the Mobile Node in routing beyond what is in the basic MIP and MIpv6 protocol. Preferences, load balancing, and other complex schemes requiring heavy mobile node involvement in the mobility management task SHOULD BE avoided. 3.3.2 Non-LMM-aware routers, hosts, Home Agents, and Mobile Nodes MUST be able to interoperate with LMM agents. 3.3.3 The LMM framework MUST NOT increase the number of messages between the mobile host and the respective Correspondent Node(s) and Home Agent. Indeed, the LMM framework MUST minimize the global signaling between the MN and its peers. The amount of regional signaling MUST NOT surpass the amount of global signaling that would have otherwise occurred if LMM were not present. 3.4 Scalability, Reliability, and Performance 3.4.1 The LMM complexity MUST increase at most linearly with the size of the local domain and the number of Mobile Nodes. 3.4.2 Any Localized Mobility Management protocol MUST assure that that LMM routing state scales at most linearly with the number of Mobile Nodes registered, and that the increase in routing state is confined to those ARs/ANRs involved in implementing the LMM protocol at hand. This would involve MIP-specific routing state as binding caches in addition to standard routing table host routes. While host routes cannot be eliminated by any mobility management protocol including base IP mobility, any LMM protocol MUST keep the number of host routes to a minimum. Carl Williams, Editor Expires December 28, 2002 [Page 6] INTERNET DRAFT Localized Mobility Management Requirements June 2002 3.4.3 The LMM framework MUST NOT create single points of failure in the network. The current access router would be excluded from this requirement. 3.4.4 The LMM framework MUST NOT interfere with the basic IP mobility performance of a mobile host communications with a Correspondent Node(s). 3.4.5 Scalable expansion of the network The LMM framework MUST allow for scalable expansion of the network and provide for reasonable network configuration with regard to peering, inter-administrative domain connectivity, and other inter-administrative domain interoperability characteristics of interest to wireless ISPs. The LMM framework MUST NOT introduce any additional restrictions in how wireless ISPs configure their network, nor how they interconnect with other networks beyond those introduced by standard IP routing. In addition, the amount of regional signaling MUST NOT increase as the Local Domain expands in size. 3.4.6 Resilience to topological changes The LMM protocols MUST be topology-independent. The LMM protocols MUST be able to adapt to topological changes within the domain. The topological changes may include the addition or removal/failure of LMM agents or that of changes in the routing of the local domain over which the LMM scheme is applied. 3.4.7 Header or Tunneling overhead Any additional header or tunneling overhead caused by LMM MUST be reduced on the radio link by compression. The transfer of compressor state on movement SHOULD be possible so as not to introduce any perceived service disruption. Candidate LMM designs that require additional header overhead for tunnels MUST be reviewed by the ROHC working group to determine if the header compressor can be restarted from transferred compressor context when handover occurs without requiring any full header packet exchange on the new link. Carl Williams, Editor Expires December 28, 2002 [Page 7] INTERNET DRAFT Localized Mobility Management Requirements June 2002 3.4.8 Optimized signaling within the Local Coverage Area By its very nature, LMM reintroduces triangle routing into Mobile IPv6 in that all traffic must go through the LMM agent. There is no way to avoid this. The LMM framework SHOULD be designed in such a way as to reduce the length of the unwanted triangle leg. The LMM design SHOULD not prohibit optimal placement of LMM agents to reduce or eliminate additional triangle routing introduced by LMM. NOTE: It is not required that a LMM scheme specify LMM agents as part of its solution. 3.5 Mobility Management Support The following LMM requirements pertain to both inter-domain and intra-domain hand-off. 3.5.1 The LMM framework MUST NOT increase the amount of latency or amount of packet loss that exists with the core Mobile IP and Mobile IPv6 specification [6, 9]. Indeed, the LMM framework SHOULD decrease the amount of latency or amount of packet loss that exists with the core mobility protocols. 3.5.2 The LMM framework MUST NOT increase the amount of service disruption that already exists with the core mobility specifications. Again, the LMM framework SHOULD decrease the amount of service disruption that already exists with the core mobility protocols. 3.5.3 The LMM framework MUST NOT increase the number of messages between the mobile host and the respective Correspondent Node(s) and Home Agent as is in the core mobility specifications [6, 9]. The LMM framework SHOULD decrease the number of messages between the mobile host and the respective Correspondent Node(s) and Home Agent as is in the core mobility specifications [6, 9]. 3.6 Auto-configuration capabilities for LMM constituents It is desirable that in order to allow for simple incremental deployment of an LMM scheme, the local mobility agents MUST require minimal (if any) manual configuration. This plug-and-play feature could make use of IPv6 auto-configuration mechanisms in the case of Mobile IPv6 [6], even though most likely other automatic configurations will be needed (such as, for example, learning about adjacent LMM agents). Auto-configuration also facilitates the network to dynamically adapt to general topological changes (whether planned or due to link or node failures). Carl Williams, Editor Expires December 28, 2002 [Page 8] INTERNET DRAFT Localized Mobility Management Requirements June 2002 3.7 LMM inter-working with IP routing infrastructure requirement The LMM framework MUST NOT disrupt core IP routing outside the local domain. 3.8 Sparse routing element population requirement Any LMM protocol MUST be designed to be geared towards incremental deployment capabilities; the latter implies that the LMM scheme itself imposes minimum requirements on the carriers network. Incremental deployment capabilities for an LMM protocol signifies that an initial set of sparse LMM agents can populate the administration domain of a network provider and operate sufficiently. In addition, any LMM scheme MUST be compatible with any additional deployment of LMM agents in future infrastructure expansions; that is to say, allow progressive LMM deployment capabilities. It is for this reason that the LMM framework MUST NOT require that all routing elements be assumed to be LMM-aware in the signaling interactions of an LMM protocol. The LMM framework MUST BE supported, at the very minimum, by a sparse (proper subset) LMM agent population that is co-located within the routing topology of a single administration domain. 3.9 Support for Mobile IPv4 or Mobile IPv6 Handover Since one of the primary goals of LMM is to minimize signaling during handover, an LMM solution MUST be available for the standardized Mobile IPv4 or Mobile IPv6 handover algorithms. LMM and the Mobile IP or Mobile IPv6 handover algorithms MUST maintain compatibility in their signaling interactions for fulfilling complementary roles with respect to each other. This requirement SHOULD NOT be interpreted as ruling out useful optimizations of LMM and Mobile IP or Mobile IPv6 handoff schemes that simplify the implementation or deployment of LMM or Mobile IP or Mobile IPv6 handoff. 3.10 Simple Network design requirement LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities. Carl Williams, Editor Expires December 28, 2002 [Page 9] INTERNET Draft Localized Mobility Management Requirements June 2002 3.12 Stability LMM MUST avoid any routing loops. 3.13 Quality of Service requirements 3.13.1 The LMM MUST have the ability to interwork with the QoS schemes to hide the mobility of the MN to its peer by avoiding end-to-end QoS signaling. 3.13.2 The LMM MUST have the ability to interwork with the QoS schemes to facilitate the new provisioning of both uplink and downlink QoS after a handoff. 4.0 Acknowledgments Thank you to all who participated in the LMM requirement discussion on the Mobile IP working group alias. First, I want to recognize Theo Pagtzis's (University College London) work on LMM requirement analysis. Theo has contributed significantly to the LMM discussion on the mailing list and at IETF working group meetings and has provided text for various requirements and the text for the introduction detailing motivation and basic LMM principles. Theo's work on requirement analysis will be published soon (see [1] below). Special thanks also to John Loughney (Nokia), Alper Yegin (DoCoMo USA Labs) and Madjid Nakhjiri (Motorola) for providing input to the draft in its preliminary stage. As editor of the draft a small team was put together to work with me on LMM requirement analysis: Hesham Soliman (Ericsson), Erik Nordmark (Sun), Theo Pagtzis (UCL), James Kempf (DoCoMo USA Labs), and Jari Malinen (Nokia). Many other working group members have participated in the requirement analysis of LMM for IPv6. This included writing requirements listed in this document as well as providing insight into requirement analysis. This made my job as editor of this document quite easy. Members who contributed are: Charlie Perkins (Nokia), Theo Pagtzis (University College London), Muhammad Jaseemuddin (Nortel), Tom Weckstr (Helsinki University), Jim Bound (Compaq), Erik Nordmark (Sun), James Kempf (DoCoMo USA Labs), Gopal Dommety (Cisco), Glenn Morrow (Nortel), Arthur Ross (IEEE), Samita Chakrabarti (Sun), Hesham Soliman (Ericsson), Carl Williams, Editor Expires December 28, 2002 [Page 10] INTERNET DRAFT Localized Mobility Management Requirements June 2002 Karim El-Malki (Ericsson), Phil Neumiller (Telocity), Behcet Sarikaya (Alcatel), Karann Chew (University of Surrey), Michael Thomas (Cisco), Pat Calhoun (Black Storm Networking), Bill Gage (Nortel Networks), Vinod Choyi (Alcatel), John Loughney (Nokia), Wolfgang Schoenfeld (GMD IPSI), and David Martin (Nextel). Recent comments received by Atsushi Takeshita (DoCoMo USA Labs), Daichi Funato (DoCoMo USA Labs), Youngjune Gwon (DoCoMo USA Labs), Ichiro Okajima (NTT DoCoMo), Jari Malinen (Nokia), Kacheong Poon (DoCoMo USA Labs) and Koshimi Takashi (NTT DoCoMo). Thanks to Cedric Westphal (Nokia) for a thorough reviewing of the draft. In addition special thanks to the Mobile IP working group chairs for their input as well as capturing and organizing the initial set of requirements from the discussions, Phil Roberts (Magisto) and Basavaraj Patil (Nokia). 5.0 References [1] Theo Pagtzis, "Requirements for Localized Mobility Management in IPv6 Networks"; Paper in Submission; Work In Progress, November 2001. [2] Manner, J. et al; "Mobility Related Terminology"; draft-manner-seamoby-terms-02.txt; Work In Progress; July 2001. [3] J.J. Tardo and K. Alagappan, "SPX: Global Authentication Using Public Key Certificates." In Proc IEEE Symp. Research in Security and Privacy. IEEE CS Press, 1991. [4] Roberts, P., "Local Subnet Mobility Problem Statement"; draft-proberts-local-subnet-mobility-problem-01.txt; Work In Progress; May 2001. [5] Perkins, C., "IP Mobility Support". IETF, Request for Comments (RFC) 2002, October 1996. [6] David B. Johnson, Charles Perkins, "Mobility Support in IPv6"; draft-ietf-mobileip-ipv6-14.txt; July 2001. [7] Tsirtsis, G. (Editor), "Fast Handovers for Mobile IPv6"; draft-ietf-mobileip-fast-mipv6-00.txt; a work in progress; February 2001. [8] Loughney, J. (Editor), "SeaMoby Micro Mobility Problem Statement"; draft-ietf-seamoby-mm-problem-01.txt; a work in progress; February 2001. [9] Perkins, C., "IP Mobility Support for IPv4," RFC3220, January 2002. Carl Williams, Editor Expires December 28, 2002 [Page 11] INTERNET DRAFT Localized Mobility Management Requirements June 2002 6.0 Authors' Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Megisto Systems 6000 Connection Drive 20251 Century Blvd Irving, TX 75039 Suite 120 USA Germantown Maryland, 20874-1191 Phone: +1 972-894-6709 EMail: proberts@megisto.com EMail: Raj.Patil@nokia.com Fax : +1 972-894-5349 Questions about this memo can also be directed to: Carl Williams DoCoMo Communications Laboratories USA, Inc. 181 Metro Drive, Suite 300 San Jose, CA 95110 USA phone: +1 408 451 4741 fax: +1 408 573 1090 email: carlw@docomolabs-usa.com 7.0 Full Copyright Statement Copyright (C) The Internet Society (2000). 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. Carl Williams, Editor Expires December 28, 2002 [Page 12]