INTERNET-DRAFT Carl Williams, Editor Internet Engineering Task Force Sun Microsystems Issued: July 13, 2001 Expires: January 13, 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 Mobile IP is required for hosts moving within the Internet topology. Mobile IP manages IP mobility resulting from the change in Care-of-Address when a host moves within the Internet topology. When a Mobile Node moves from one point of attachment to another, a mobility binding update to the respective home agent and/or correspondent node(s) occurs. Localized Mobility Management (LMM) refers to a method of handling mobility locally, restricting the resultant signaling to a specific area, and possibly reducing the amount of signaling. This document describes requirements which are designed to guide development of optional extensions to the Mobile IPv6 protocol in providing for Localized Mobility Management functionality. Carl Williams, Editor Expires January 13, 2002 [Page 1] INTERNET DRAFT Localized Mobility Management Requirements July 2001 Table of Contents 1.0 Introduction .................................................... 2 2.0 Terminology ..................................................... 2 3.0 Requirements .................................................... 3 3.1 Intra-domain mobility ........................................ 3 3.2 Security ..................................................... 4 3.3 Scope of LMM effect .......................................... 4 3.4 Scalability and Performance .................................. 4 3.5 Mobility Management Support .................................. 5 3.6 Sparse routing element population requirement ................ 5 3.7 Interworking with hand-off mechanisms ........................ 5 3.8 Simple Network design requirement ............................ 6 3.9 Location Privacy requirement ................................. 6 3.10 Reliablity .................................................. 6 4.0 Acknowledgments ................................................. 6 5.0 References ...................................................... 6 6.0 Author's Addresses .............................................. 7 7.0 Full Copyright Statement ........................................ 7 1.0 Introduction The emergence of Mobile IPv6 as the dominant protocol for supporting mobile data networking provides a productive springboard from which to explore and develop wireless mobile networking. The overall goals of LMM are: - reducing the signaling induced by changes in the point of attachment due to the movement of a host; - reducing the usage of air-interface resources for mobility; - avoid changes 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. Latency costs can be high due to mobility binding updates and registration processing. In addition, radio interface resources are scarce, when compared to wired interfaces, and thus expensive, which calls for special measures from IP mobility management protocols in providing a highly efficient data transport to and from a mobile device where the routable IP address of the node changes during movement to a new point of attachment [1]. Increasing the efficiency of the registration process of mobile hosts is an approach that addresses the goals of reducing latency costs and the conservation of radio resources. One class of solutions in this regard focuses on extensions to the IP layer mobility protocol in order to restrict the region of signaling, thus possibly reducing the amount of signaling. This functionality is commonly referred to as Localized Mobility Management (LMM). Carl Williams, Editor Expires January 13, 2002 [Page 2] INTERNET DRAFT Localized Mobility Management Requirements July 2001 Through LMM, the user can gain the benefit of smoother hand-offs as well as reducing the signaling initiated from the mobile node and thus minimizing radio resources usage. Inherently, this allows for increased scalability and reduces the need for additional route optimization. This document lays out requirements in order to guide development of LMM in order that the resulting solution will best preserve the the fundamental philosophies and architectural principles of the Internet in practice today. 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. [3] Local Mobility The movement of an IP device without requiring a change to its routable IP address seen by the CN or HA. Althoughits point of attachment may change during themove, the IP addresses used to reach the device(both its home and IP subnet routable IPaddress) do not change. Local Mobility Domain A Local Mobility Domain contains one or more IP subnets, networks, or Administrative Domains. Within the Local Mobility Domain, the globally visible routable IP address assigned to a MobileHost or Mobile Router serving a Mobile Networkdoes not change. Localized Mobility A method of handling mobility locally, in order Management (LMM) to restrict the signaling area,thus possibly reducing the amount of signaling. 3.0 LMM Requirements This section describes the requirements of a LMM solution for Mobile IPv6. Only Mobile IPv6 based requirements are described here. 3.1 Intra-domain mobility LMM is introduced to minimize the signaling trafficto the home agent and/or correspondent node(s) for intra-domain mobility. In the LMM infrastructure a correspondent node or home agent outside the administration domainMUST always be able to address the mobile host by the same IP address, sothat from the point of view of hosts outside the administration domain, the IP address of the mobile host remains fixed. It is not the intent or goal for LMM to enter the intra-subnet (intra AR) mobility problem space. See [SubnetMobPro] for more information on this specific problem space. Carl Williams, Editor Expires January 13, 2002 [Page 3] INTERNET DRAFT Localized Mobility Management Requirements July 2001 3.2 Security 3.2.1 LMM protocol MUST provide for "security provisioning" within the respective administration domain. 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 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 administration domain 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 host. 3.2.4 LMM protocol MUST NOT interfere with the security provisioning that exists between the correspondent node and the mobile host. 3.2.5 LMM protocol MUST NOT introduce new security holes or the possibility for DOS-style attacks. 3.3 Scope of LMM effect 3.3.1 The LMM framework MUST NOT add any modifications or extensions to the correspondent node(s) and home agent. 3.3.2 Non-LMM-aware routers, hosts, home agents, and mobile nodes MUST be able to interoperate with LMM-aware 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. 3.3.4 Connectivity to the mobile host MUST always be maintained in the presence of failure of LMM agents (infrastructure). 3.4 Scalability and Performance 3.4.1 The LMM framework MUST be able to support a large number of mobile hosts. 3.4.2 The LMM framework MUST NOT interfere with the Mobile IPv6 performance of a mobile host communications with a correspondent node(s). 3.4.3 Scalable expansion of the network The LMM framework MUST allow scalable expansion of the network and provide for reasonable network configuration with regard to peering, interadministrative domain connectivity, and other interadministrative 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. Carl Williams, Editor Expires January 13, 2002 [Page 4] INTERNET DRAFT Localized Mobility Management Requirements July 2001 3.4.3 Header overhead Any additional header overhead caused by LMM MUST be reduced by compression and 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. 3.4.4 Optimized signaling within the administrative domain 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 that as to reduce the length of the unwanted triangle leg. The LMM framework SHOULD support optimal placement of LMM agents to reduce or eliminate additional triangle routing introduced by LMM. 3.5 Mobility Management Support The following LMM requirements pertain to both inter-domain hand-off and between administrative domains as well. 3.5.1 The LMM framework MUST NOT increase the amount of latency or amount of packet loss that exists with the core Mobile IPv6 specification [6]. 3.5.2 The LMM framework MUST NOT increase the amount of service disruption that already exists with the core Mobile IPv6 specification. 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 Mobile IPv6 specification. 3.5.4 The LMM framework SHOULD support the auto-configuration capabilities for mobility agents/FAs, access routers. 3.6 Sparse routing element population requirement The LMM framework SHOULD be supported, at the very minimum, by a sparse (proper subset) routing element population within a single administration domain. 3.7 Interworking with hand-off mechanisms 3.7.1 The LMM framework MAY include methods for interworking with Mobile IPv6 fast hand-off solutions [7]. 3.7.2 The LMM framework MAY provide input to the hand-off process. Carl Williams, Editor Expires January 13, 2002 [Page 5] INTERNET DRAFT Localized Mobility Management Requirements July 2001 3.8 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. 3.9 Location privacy support The LMM framework MUST allow for location privacy. 3.10 Reliablity 3.10.1 LMM framework MAY include recovery from failure of LMM agents. 3.10.2 LMM framework MAY include mechanisims for inclusion of the indication of Failure of LMM agents. 4.0 Acknowledgments Thank you to all who participated in the LMM requirement discussion on the Mobile IP working group alias. Those individuals are: Charlie Perkins (Nokia), Theo Pagtzis (Nokia), Muhammad Jaseemuddin (Nortel), Tom Weckstr (Helsinki University), Jim Bound (Compaq), Erik Nordmark (Sun), James Kempf (Sun), Gopal Dommety (Cisco), Glenn Morrow (Nortel), Arthur Ross (IEEE), Samita Chakrabarti (Sun), Hesham Soliman (Ericsson), Karim El-Malki (Ericsson), Phil Neumiller (Telocity), Behcet Sarikaya (Alcatel), Karann Chew (University of Surrey), Michael Thomas (Cisco), Pat Calhoun (Sun), Bill Gage (Nortel Networks), Vinod Choyi (Alcatel), John Loughney (Nokia), Wolfgang Schoenfeld (GMD Fokus), and David Martin (Nextel). Special thanks to Alper Yegin (Sun), John Loughney (Nokia) and Madjid Nakhjiri (Motorola) for providing input to the draft in its preliminary stage. 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] Westberg, L., Lindqvist M., Realtime Traffic over Cellular Access Networks; draft-westberg-realtime- cellular-04.txt; Work In Progress; December 2001 [2] Manner, J. et al; "Mobility Related Terminology"; draft-manner-seamoby-terms-00.txt; Work In Progress; January 12, 2001. [3] Yavatkar, R., Pendarakis, D., Guerin, R.; "A Framework for Policy-based Admission Control"; RFC 2753; January 2000. [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". Internet Engineering Task Force, Request for Comments (RFC) 2002, October 1996. Carl Williams, Editor Expires January 13, 2002 [Page 6] INTERNET DRAFT Localized Mobility Management Requirements July 2001 [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. 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 Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA phone: +1 650 786 5186 fax: +1 650 786 5896 email: Carl.Williams@eng.sun.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. Carl Williams, Editor Expires January 13, 2002 [Page 7] INTERNET DRAFT Localized Mobility Management Requirements July 2001 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 January 13, 2002 [Page 8]