| TOC |
|
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.
This Internet-Draft will expire on May 6, 2004.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document describes goals for Localized Mobility Management (LMM) for IP layer mobility, such Mobile IP and Mobile IPv6. These goals are intended to guide the design of a protocol specification for LMM. Localized Mobility Management, in general, introduces enhancements to IP layer mobility protocols to reduce the amount of latency in IP layer mobility management messages exchanged between a Mobile Node (MN) and its peer entities. 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 goals 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 goals for architecting and deploying LMM schemes.
| TOC |
| TOC |
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, IP layer mobility management is facing a number of technical challenges in terms of performance and scalability [4][5][6]. 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 protocols [2][3], 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 [3], 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.
The same approach applies also to a number of other IP layer mobility management protocols. For example, in the Host Identity Protocol (HIP) mobility management scheme, a Mobile Node sends an Readdress (REA) packet to its peer; this is very similar the Binding Updates send in Mobile IPv6 Route Optimization. In general, IP layer mobility protocols maintain a binding between a host identifier and either one care-of address or a set of care-of addresses. In Mobile IP, the home address acts as the host identifier, and only one care-of address is allowed. In other IP layer mobility protocols the host identifier is typically something else and more than one care-of addresses may be allowed.
After movement, traffic destined for the Mobile Node is sent to the old care-of address and is, effectively, dropped until the peer entities processes mobility management messages. If the Mobile Node is at some geographical and topological distance away from a peer entity, 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. Recently, Mobile IP has been extended by certain local mobility mechanisms, aiming to alleviate the above performance limitations; they are identified as hierarchical/regional or more generically Localized Mobility Management (LMM).
LMM Localized mobility management schemes allow the Mobile Node to continue receiving traffic on the new subnet without any change in the bindings at the peer entities. 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:
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.
| TOC |
See [7] for mobility terminology used in this document.
- Peer entity
- A generic name used for nodes that communicate with a mobile node. In Mobile IP and IPv6, the Home Agent and Correspondent Node are peer entities.
| TOC |
This section describes the requirements for a LMM solution. The requirements are relevant to both all IP layer local mobility management schemes, independent of the actual IP layer macro mobility protocol.
LMM is introduced to minimize the signaling traffic to the peer entities, e.g. Home Agent and/or Correspondent Node(s), for intra-domain mobility (within a Local Coverage Area). This is the fundamental reason for introducing localized mobility management. In the LMM infrastructure a peer entity 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.
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.
LMM protocol MUST NOT interfere with the security provisioning that exists between the peer entities and the Mobile Node.
LMM protocol MUST NOT introduce new security holes or the possibility for DOS-style attacks.
Any Localized Mobility Management protocol MUST NOT inject any additional functionality over the base IP layer macro mobility protocol employed. Thus, the LMM framework MUST NOT add any modifications or extensions to the peer entities, including Mobile IP or Mobile IPv6 Correspondent Node(s) and Home Agents. It is essential to minimize the involvement of the Mobile Node in routing beyond what is in the basic mobility protocol. Preferences, load balancing, and other complex schemes requiring heavy mobile node involvement in the mobility management task SHOULD BE avoided.
Non-LMM-aware routers, hosts, Mobile IP and IPv6 Home Agents, and Mobile Nodes MUST be able to interoperate with LMM agents.
The LMM framework MUST NOT increase the number of messages between the mobile host and the respective peer entities. 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.
The LMM complexity MUST increase at most linearly with the size of the local domain and the number of Mobile Nodes.
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. While host routes apparently 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.
The LMM framework MUST NOT introduce additional points of failure in the network. The current access router would be excluded from this requirement.
The LMM framework MUST NOT interfere with the basic IP mobility performance of a mobile host communications with a peer entity.
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.
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.
The LMM framework MUST not prevent header compression from being applied. It is recommended that andidate LMM designs that require additional header overhead for tunnel 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.
By its very nature, LMM reintroduces triangle routing
into the base IP layer mobility protocol 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.
The following LMM requirements pertain to both inter-domain and intra-domain hand-off.
The LMM framework MUST NOT increase the amount of latency or amount of packet loss, compared to what exists with the core Mobile IP and Mobile IPv6 specification [2][3]. Indeed, the LMM framework SHOULD decrease the amount of latency or amount of packet loss that exists with the core mobility protocols.
The LMM framework MUST NOT increase the amount of service disruption, compared to that already exists with the Mobile IP and Mobile IPv6 core mobility specifications. Again, the LMM framework SHOULD decrease the amount of service disruption that already exists with the IP layer mobility management protocols.
The LMM framework MUST NOT increase the number of messages between the mobile host and the respective peer entities. The LMM framework SHOULD decrease the number of messages between the mobile host and the respective peer entities. With respect to Mobile IP and Mobile IPv6, the current number of messages is defined in the Mobile IP core mobility specifications [2][3].
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 IPv6, 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).
The LMM framework MUST NOT disrupt core IP routing outside the local domain.
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 carrierÂ’s 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.
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.
LMM SHOULD simplify the network design and provisioning for enabling LMM capability in a network and allow progressive LMM deployment capabilities.
LMM MUST avoid any forwarding loops.
The LMM MUST have the ability to coexist with QoS schemes to hide the mobility of the MN to its peer by avoiding end-to-end QoS signaling.
The LMM MUST have the ability to coexist with the QoS schemes to facilitate the new provisioning of both uplink and downlink QoS after a handoff.
| TOC |
This document does not generate any additional security considerations.
| TOC |
Thank you to all who participated in the LMM requirement discussion on the Mobile IP working group alias. First, the editor wishes to recognize Theo Pagtzis's 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. Special thanks also to Gabriel Montenegro, John Loughney, Alper Yegin, Alberto Lopez Toledo, and Madjid Nakhjiri for providing input to the draft in its preliminary stage and many other comments they had. Thanks to the LMM requirement analysis design team: Hesham Soliman, Erik Nordmark, Theo Pagtzis, James Kempf, and Jari Malinen.
Additional comments on the LMM requirements were received from: Charlie Perkins, Muhammad Jaseemuddin, Tom Weckstr, Jim Bound, Gopal Dommety, Glenn Morrow, Arthur Ross, Samita Chakrabarti, Karim El-Malki, Phil Neumiller, Behcet Sarikaya, Karann Chew, Michael Thomas, Pat Calhoun, Bill Gage, Vinod Choyi, John Loughney, Wolfgang Schoenfeld, David Martin, Daichi Funato, Ichiro Okajima, Jari Malinen, Kacheong Poon, Koshimi Takashi, and Cedric Westphal.
An LMM requirement analysis of this body of work was completed by a number of members of the Mobile IP working group and published in .
In addition special thanks to the Mobile IP working group chairs, Phil Roberts, Gabriel Montengro, and Basavaraj Patil, for their input as well as capturing/organizing the initial set of requirements from the discussions.
| TOC |
| [1] | Pagtzis, T., Williams, C., Kirstein, P., Perkins, C. and A. Yegin, "Requirements for Localised IP Mobility Management", in Proceedings of IEEE Wireless Communications and Networking Conference (WCNC2003), Louisiana, New Orleans, March 2003. |
| [2] | Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. |
| [3] | Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 2003. |
| [4] | Karlsson, G., "Quality Requirements for Multimedia Network Services", in Proceedings of Radiovetenskap och kommunikation, pages 96-100, June 1996. |
| [5] | Kurita, T., Iai, S. and N. Kitawaki, "Effects of transmission delay in audiovisual communications", Electronics and Communications in Japan, Vol 77, No 3, pages 63-74, 1995. |
| [6] | Wang, Y., Claypool, M. and Z. Zuo, "An Empirical Study of RealVideo Performance Across the Internet", in Proceedings of ACM SIGCOMM Internet Measurement Workshop, Nov 2001. |
| [7] | Manner, J. and M. Kojo, "Mobility Related Terminology", draft-ietf-seamoby-mobility-terminology-04 (work in progress), April 2003. |
| TOC |
| [8] | Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mobileip-fast-mipv6-07 (work in progress), September 2003. |
| [9] | Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mobileip-hmipv6-08 (work in progress), July 2003. |
| TOC |
| Carl Williams | |
| MCSR Labs | |
| 3790 El Camino Real | |
| Palo Alto, CA 94306 | |
| USA | |
| Phone: | +1 650 279 5903 |
| EMail: | carlw@mcsr-labs.org |
| Pekka Nikander | |
| Ericsson Research Nomadiclab | |
| Jorvas FI-02420 | |
| Finland | |
| Phone: | +358 9 299 1 |
| EMail: | pekka.nikander@nomadiclab.com |
| TOC |
HMIPv6 was evaluated as a localized mobility management protocol, and that it was mostly found to satisfy the requirements put forth in this document. This section details one exception with some explanation.
Exception 1:
One LMM requirement that needs further clarification with respect to HMIPv6 is the requirement that states that LMM should not introduce additional single points of failure. The HMIPv6 Mobility Anchor Point (MAP) is a new single point of failure. Proposals for HMIPv6 MAP replication can be optionally incorporated in order to avoid this new single point of failure. Such proposals can also be applied to the base Mobile IPv6 specification to also allow for Home Agent failover as well.
| TOC |
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2003). 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 assignees.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.