Network Working Group Eric Njedjou Julien Riera Internet Draft France Telecom Expires August 2006 February 2006 Problem Statement for Network Global Mobility Management draft-njedjou-netlmm-globalmm-ps-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. "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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" This Internet-Draft will expire on August 27, 2006. Copyright Notice Copyright © The Internet Society (2006) Abstract This document discusses the problem of network global mobility management in a context where integrated IP access networks providers are looking for efficient solutions to the inter-system IP mobility problem. The document extends the current scope of netlmm to address the problem of moving between "topologically distant" IP access domains njedjou Expires August 2006 [Page 1] Internet-Draft problem statement February 2006 Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Abbreviations...............................................5 4. Deployment scenarios considered.............................6 4.1. Movement between different access network providers.........6 4.2. Movement within an integrated access network provider.......7 5. Issues and problems with Existing global mobility management (gmm)solutions.................................9 5.1. Signaling ratio over the radio..............................9 5.2. Complexity of global mobility management procedures and of hosts.................................................10 5.3. Guarantee of service level, other stringent requirements on terminals................................10 5.4. Mobility between two netlmm compatible domains owned by a same operator..........................................11 6. Security Considerations....................................13 7. Conclusion.................................................13 8. References.................................................13 9. Acknowledgments............................................14 10. Authors Addresses..........................................14 1. Introduction Global mobility management solutions have been under design by the IETF for the past fifteen years or so (assuming the creation of the Mobile IP Working Group as a start). The basic goal pursued at the time of starting that effort, was the ability to continue an IP session when a host IP address had to change. The targeted IP sessions were those involving a transport level connection. No other motivation but to achieve session continuity has really been taken into account so far in defining the existing solutions for global mobility management. Effectively, the main goal has always been to hide the IP address change from the transport level as well as from the correspondent node perspective. In such a way, a host would keep sending packets and continue to be reachable while moving. Therefore, from a network standpoint, having a mobility anchor node perform the route update or notify its correspondents that the moving host care-of address had changed was sufficient enough to achieve the precedent goal. Solutions as Mobile IP or HIP operate on that pattern. Actually, global mobility management architectures and protocols from the IETF have grown in more or less a parallel to those Njedjou Expires August 2006 [Page 2] Internet-Draft problem statement February 2006 designed in other SDOs as 3GPP where other considerations were taken into account aside that of just continuing the IP session of a user. Indeed 3GPP would be motivated by other considerations as for example the need for the provider to control the selection of the target access network of attachment. And still, future global mobility systems will tend to marry existing mechanisms from different standardization actors (IETF, 3GPP, IEEE802…) built with different purposes and motivations. This tendency will grow even wider as services will move to be all-IP based and access agnostic. With that thinking, there is a growing feeling that the match between the mechanisms built in these different SDOs is far from optimal and suitable. This is especially true when considering some market oriented requirements as can have mobile operators owning several types of access networks that they want to make inter-work to provide their users with global mobility. Indeed the fact that an IP handover should be seamless is not the only motivation when solving the global mobility problem solving. What appears as a simple movement actually involves a lot of external factors. While ensuring seamless continuity for the user, other objectives are to be fulfilled. For integrated access system operators, such objectives can be as numerous as the needs to: . Judiciously using the "newly" available radio capacity (Wifi, Wimax…) to unblock cellular systems and provide multimedia services; . Guaranteeing service level for the users by helping them determine the best system for the service they get to access to; . Optimizing the use of the radio resources (especially on cellular), so as to dedicate the radio spectrum to serving more data/voice by lowering the signaling overhead; . Making integrated (and therefore already composite) architectures less complex, as well as minimizing protocols to render overall systems more scalable; . Lowering requirements and constraints on hosts for a straightforward support of inter-system mobility. The two first and last bullets points basically require that the global mobility management system be network controlled oriented as opposed to terminal controlled. Also given such requirements, global mobility management solutions as they exist today seem to hardly meet the previously indicated market needs. 2. Terminology Terminology is an aspect of mobility management that is in constant change, because of often evolving requirements. The terms "aggregate router", "care-of-address", "IP location update", Njedjou Expires August 2006 [Page 3] Internet-Draft problem statement February 2006 "mobility management", "global mobility management", "local mobility management" "mobility anchor" will be given the interpretation precised below. These interpretations are meant consensual enough not to confuse the reader. Aggregate router This is a specific router in an access network acting as its border router on the core network side. Care-of-address In this document, a care-of-address refers to an IP address temporarily acquired by a mobile host while visiting an IP access network, irrespective of which global mobility management protocol the host is running. Therefore, a host may have a care-of-address without running MIP. Coming revisions of this document might suggest an alternative expression to avoid ambiguity. IP location update This is a generic procedure whereby a host informs a mobility anchor in the network or a correspondent located anywhere on the internet that it has a new active care-of-address and therefore a new IP location. This procedure is called registration in Mobile IPv4 and re-association in HIP. Mobility management RFC 3753 defines local and global mobility management but the notion of mobility management itself is not defined. For the purposes of this document, mobility management will be defined as the process of performing and sequencing the following actions; . Collect information from terminal, Radio Access Points and Resource Controllers to assess the need or opportunity for a handover . Choose a handover target, as a result of deciding the next Radio Access Network and Point of attachment based on collected information, QoS needs and other policies. . Execute the handover on the terminal. This generally consists in switching between radio links, preparing the IP configuration over the new link and performing the IP location update. This definition does not make any assumption of which side between the network and the terminal decides of the handoff target. Global mobility management Njedjou Expires August 2006 [Page 4] Internet-Draft problem statement February 2006 Mobility management is said to be global whenever it involves a mobile host that is moving between IP domains that are "topologically distant". IP Domains are considered topologically distant when their respective aggregate routers are located multiple hops away from one another. Heterogeneous access networks would usually constitutes such IP domains. These domains can be part of the same administrative boundaries, eg an operator integrating several access networks providers. Network global mobility management A global mobility management procedure controlled by the network Local mobility management Mobility management is said to be local whenever it involves a mobile host moving between IP domains that are topologically close. Such domains would usually be confined into a single access network. Mobility anchor A mobility anchor is an IP node that either: . Performs the forwarding and path update of IP packets destined to the moving host . notifies correspondents that the moving host care-of address has changed With this definition, a mobility anchor only participates to the goal of making the moving host reachable. The Home Agent of MIP and the Rendez-Server of HIP are example of defined mobility anchors. However the mobility anchor described in the deployment scenario of this document will not refer to these specific nodes. Inter-System Mobility Server This is a node typically located in an integrated operator network and that help deciding of the mobile host target system (step 2 of mobility management) based on several criteria. Such a node is used in this document to illustrate the network global mobility management problem. Considerations associated with selection criteria are clearly out of scope. 3. Abbreviations gmm: global mobility management Njedjou Expires August 2006 [Page 5] Internet-Draft problem statement February 2006 netgmm: network global mobility management netlmm: network localized mobility management 4. Deployment scenarios considered As said, global mobility refers to the "movement" performed by a host as it changes its point of attachment from an access network to another one topologically distant. Typically, such movement will either occur between two access networks of different providers or also between two access networks owned by the same service provider. The problem raised in this document addresses the later category of movement. 4.1. Movement between different access network providers The following figure depicts a deployment model where a host is moving between two access networks operated by different providers. Such providers will usually not cooperate for the purpose of mobility management as defined earlier. * * * * * +----------+ * | Mobility | * | Anchor | * +----------+ * * * * * * * * * * * * * * Internet * * * * * * * * * * * * * * +-------+ +-------+ |AggR A1| |AggR B1| +-------+ +-------+ AN A @ @ @ AN B Provider A @ @ @ Provider B @ @ @ @ @ @ +-----+ +-----+ +-----+ Njedjou Expires August 2006 [Page 6] Internet-Draft problem statement February 2006 |AR A1| |AR A2| |AR B1| +-----+ +-----+ +-----+ * * * * * * * * * * * * * * * * * * * * /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ ------ ------ ------ ------ ------ | | | | | | +--+ +--+ |MN|----------------->|MN| +--+ +--+ Figure 1: example Deployment scenario for two access networks owned by different providers The terminal is in this case (as the only node capable of getting access networks information), in good position to perform the mobility management functions on its own. Global mobility management solutions as they are specified today (i.e basically host based) well apply to this deployment model. Indeed with such a scenario, seamless global mobility requirements as prescribed earlier can not be met in practice, because access networks from different providers would usually not cooperate for mobility management. 4.2. Movement within an integrated access network provider The following figure depicts a classical deployment scenario for an operator that is owner of several access networks that it wants to make cooperate because of the need to ensure the goals and requirements as listed in the introduction. * * * * * * * + ----------+ * |Inter-System| * | Mobility | * Operator network + ----------+ * * +----------+ Njedjou Expires August 2006 [Page 7] Internet-Draft problem statement February 2006 * |Mobility | * | Anchor | AN A * +----------+ * AN B Capacity Capacity Control * * Control * * * * * * * * * * * +-------+ +-------+ |AggR A1| |AggR B1| +-------+ +-------+ AN A @ @ @ AN B @ @ @ @ @ @ @ @ @ +-----+ +-----+ +-----+ |AR A1| |AR A2| |AR B1| +-----+ +-----+ +-----+ * * * * * * * * * * * * * * * * * * * * /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ ------ ------ ------ ------ ------ | | | | | | +--+ +--+ |MN|----------------->|MN| +--+ +--+ Figure 2: Deployment scenario for an integrated operator In such an integrated operator scenario, the network is in good position to perform mobility management. It specifically is able to watch over the capacity of every system. A function therein (represented here with an Inter-System Mobility Server) would basically keep the terminal "inter-system" state. Specifications as the 802.21 draft would see the MIH Point of Service into such a server. Note that such a function can be co-located to the node acting as the IP Mobility anchor. However these considerations are informative only and out of scope here. The IP mobility anchor here would be only dedicated at performing the routing update consequently to changing active IP connectivity of the host from one access system to another. Njedjou Expires August 2006 [Page 8] Internet-Draft problem statement February 2006 When a core network is able to federate the access systems, and with the use of appropriate information exchange protocols and mechanisms within network nodes, an entity as the precedent Inter- System Mobility Server can also be in favorable position to have the knowledge that a specific host it is serving is using a specific care-of-address (without requiring explicit notice from that host). Effectively address assignment schemes for a provider deployment are likely to be dynamic based. So that the intelligence that a moving host visiting a specific access network is holding a specific care-of-address is already available somewhere in the network and therefore could be easily made available to a mobility anchor serving the host. On the event of a handover, to another access network of the integrated provider, the target IP configuration of the host(including the care-of-address to use) can be prepared in the network (especially when dynamically assigned) and made available to the mobility anchor. This will in turn be able to forward future packets to the new host location upon the host receiving such configuration. Therefore, the explicit IP location update as well as the necessity to keep association states between host and mobility anchor of existing global mobility solutions (Registration and REA procedures of MIP or HIP) can be avoided in this model. The next paragraph precisely describes the problem encountered when resorting to such an explicit IP location update and association with IP mobility anchor. It is to be made explicitly clear that any specific procedure by which the network can be aware of the terminal new and old IP configuration is not mandated. Every implementation of the deployment model can figure out how they want to get the information. 5. Issues and problems with Existing global mobility management (gmm)solutions This paragraph captures the reasons why classical gmm solutions are problematic in regards to driving requirements as presented in the introduction. 5.1. Signaling ratio over the radio Global mobility management solutions known to date do not guarantee an efficient use of the radio capacity, especially with the need to associate to a mobility anchor and perform frequent explicit IP location updates from hosts. Njedjou Expires August 2006 [Page 9] Internet-Draft problem statement February 2006 Terminals are required to support more and more control planes. A single terminal could have to support, multiple radios, as well as authentication, inter-system mobility, IMS… that all generate fair amount of signaling Aside IP session continuity, integrated mobility architecture will also have to address such transitions as VoIP to circuit switched voice. So will multi-systems terminals. This new type of session continuity requires specific mobility anchors that are different from entities as Home Agents (that can only perform the switch between two IP legs). Therefore, it is a strong requirement that signaling overhead from hosts to these different mobility anchors do not grow as their number or type will multiply. 5.2. Complexity of global mobility management procedures and of hosts As said in the introduction, simplifying architectures that already have composite systems, as well as minimizing the protocols is a requirement on the road to rendering next generation mobility architectures more scalable. Also lowering software support requirements on hosts would facilitate early adoption of seamless mobility by reducing the time to market for terminals to be seamless mobility compatible. Complete global mobility management procedures would basically require that a mechanism exist to perform the procedures as described in paragraph 2, basically collecting information to prepare a handover, and indicate the target to the terminal. Known solutions for gmm do not provide these steps. Therefore they usually superpose to the previous steps to create complex state machines and heavy message exchange flows between hosts and the network. Also, usually a terminal will already have mobility management states for every activated link (UMTS, Wimax…). To that, has to superpose the state of association to the mobility anchor of classical global mobility management protocol. Such an association (needed because of the host has to explicitly send its IP location to the network) adds sensitiveness to the overall stability. Lowering hosts complexity is already a requirement of netlmm. Another example is about the VoIP to Circuit Switched transition work carried out in 3GPP is being addressed with no specific needed support on the host but native IMS. 5.3. Guarantee of service level, other stringent requirements on terminals Njedjou Expires August 2006 [Page 10] Internet-Draft problem statement February 2006 An integrated deployment model as presented in 3.2 has the ability to facilitate network control. Network control brings guarantee of service level to moving users as well as assurance that the capacity of provider spread across systems is used efficiently. Network control implies that the initiation of the IP location update procedure is governed by rules indicated by the network. Therefore, a specific requirement is to be observed by the existing global mobility protocol stack to perform the IP location update only upon indication from the network to switch between links. Furthermore, as these gmm solutions let it totally implementation dependant the set of events that trigger the IP location update procedure, it is practically impossible for all implementations to have the same state machine for triggering that IP location change notice. Therefore, implementations as would be wanted for network control will have to be featured in a way to perform the IP location procedure only after a network indication to do so. Flexibility of standard implementation is often desired but can be become cumbersome in some cases. Many operators are building roadmaps for deploying seamless mobility for IP services with previously indicated requirements. Because of the previously identified problem of gmm solutions to date, such operators have to make specific requests for quotations to smart devices vendors to design implementations that fit their purposes of network control. This burden becomes considerable when deployment is considered at a large scale. 5.4. Mobility between two netlmm compatible domains owned by a same operator An alternative deployment scenario for an integrated provider willing to offer global mobility would via the aggregation of several netlmm operated access networks into a core network. * * * * * * * Operator's * * Aggregation * * Network * * * * * * * * * * * * * * * Njedjou Expires August 2006 [Page 11] Internet-Draft problem statement February 2006 +-------+ +-------+ |AggR A1| |AggR B1| +-------+ +-------+ @ @ @ @ @ @ * * * * * * * * * * * * * NETLMM * * NETLMM * * Compatible * * Compatible * * Network * * Network * * A * * B * AN A * * * * AN B * * * * * * * * * * * * * * * * * * * * * * * * * /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ / A1 \ / A2 \ / A3 \ / B1 \ / B2 \ ------ ------ ------ ------ ------ | | | | | | +--+ +--+ |MN|------------------->|MN| +--+ +--+ Figure 3: Mobility between operator's aggregated Netlmm domains As in the scenario of figure 2, the fact that both netlmm domains belong to the same administration, make it possible the exchange of information for mobility management within the network. Even in the case where the same localized mobility management protocol is used in both access domains, a classical global mobility protocol will have to be resorted to for the inter-domain transition. For architecture scalability and host simplicity, it would not be desirable to multiply such mobility protocols. Instead Netlmm solutions would certainly better be commoditized for integrated architectures and global mobility, so that the hosts and the network do not require any additional mobility management protocol to achieve the inter-domain movement. However, it is not clear at this point whether generalizing netlmm to the global problem would be the right approach. Also, SDOs as 3GPP are working on evolved architectures that require global IP mobility protocols. Solutions Njedjou Expires August 2006 [Page 12] Internet-Draft problem statement February 2006 meeting requirements presented in this document would be particularly adapted to these new architectures. Available gmm solutions may still work for these evolutions, but at the cost of the burden presented earlier. It is to be made clear that in the case where access domains A and B are operated by different administrations (as in figure 1), the moving host stands as the unique federation entity and would therefore have to be more implicated in the mobility management. Classical global mobility management schemes would probably have to be used for this latter case. As a general observation it is worth reminding that it is making more and more sense from the market perspective to fill two parallel streams and families of solutions for mobility management, respectively meeting the requirement of terminal and network control. 6. Security Considerations Part of network global mobility management requirement should be not to incur additional security problems to those already encountered by known gmm protocols. Any moving host always has to get authenticated to the node that takes care of its mobility. Such a node is the IP mobility anchor for classical gmm and could be a different node for netgmm. 7. Conclusion This document has tried to illustrate the problem of performing network global mobility management with IETF already defined solutions. The context has been confined to a specific family of deployment scenarios, deemed to have the potential to grow wide enough to legitimate dedicated solutions. 8. References [MIPV4] "IP Mobility Support", C. Perkins (editor), RFC 2002, October 1996. [MIPV6] "Mobility Support in IPv6", D. Johnson, C. Perkins, and Jari Arkko, RFC 3677, June 2004. [TERM] "Mobility Related Terminology", J. Manner, M., RFC 3753 June 2004 Njedjou Expires August 2006 [Page 13] Internet-Draft problem statement February 2006 [HIP] "Host Identity Protocol", P. Jokela (editor), draft-ietf- hip-base-04, work in progress, October 2005 [NETLMM] "Problem Statement for IP Local Mobility", J. Kemps (editor), draft-ietf-netlmm-nohost-ps-00.txt, work in progress, February 2006 9. Acknowledgments The authors would like to acknowledge reviewers of this document. 10. Authors Addresses Eric Njedjou France Telecom 4, rue du CLos Courtel 35512 Cesson Sévigné BP 91226 France Phone: +33299124878 Email: eric.njedjou@france.telecom.com Julien Riera France Telecom 38/40, rue du Général Leclerc 92794 Issy Les Moulineaux Cedex 9 France Phone: +33145298994 Email: julien.riera@francetelecom.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required Njedjou Expires August 2006 [Page 14] Internet-Draft problem statement February 2006 to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Njedjou Expires August 2006 [Page 15]