Individual Submission B. Patil, Ed. Internet-Draft Nokia Intended status: Informational C. Williams Expires: September 8, 2011 MCSR Labs J. Korhonen Nokia Siemens Networks March 7, 2011 Approaches to Distributed mobility management using Mobile IPv6 and its extensions draft-patil-mext-dmm-approaches-00 Abstract Mobility solutions at the IP layer have been specified in the IETF for IPv4 and IPv6. These solutions include host and network based mobility. All of the mobility protocols enable IP session continuity by providing the mobile host with an IP address or prefix that remains constant even as the host moves and attaches to different access networks and points of attachment. Mobile hosts are anchored at a gateway via a tunnel and the address/prefix provided to the host via the gateway remains unchanged across mobility events. All IP sessions initiated or terminated at a mobile host are anchored via the gateway. There are issues and concerns with such a mobility model which are discussed in this document. A mobility model wherein the mobility functions are distributed is a way of alleviating the concerns of a gateway centric approach. This document also considers ways to alleviate anchored mobility issues with approaches that could be considered in a deployment. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 8, 2011. Patil, et al. Expires September 8, 2011 [Page 1] Internet-Draft DMM with MIP6 March 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Issues with current mobility models . . . . . . . . . . . . . 4 3.1. Backhauling all traffic to a centralized GW . . . . . . . 4 3.2. Latency Considerations . . . . . . . . . . . . . . . . . . 5 3.3. Inefficient Routing and signaling overhead . . . . . . . . 5 3.4. Scalability and cost . . . . . . . . . . . . . . . . . . . 5 4. Enhancements to improve mobility . . . . . . . . . . . . . . . 6 4.1. HMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Dynamic assignment of HA . . . . . . . . . . . . . . . . . 6 4.3. Route Optimization . . . . . . . . . . . . . . . . . . . . 7 5. Distributed mobility - What does it imply . . . . . . . . . . 7 6. Approaches using current protocols for distributed mobility . 8 7. Potential future work . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 10 11. Informative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Patil, et al. Expires September 8, 2011 [Page 2] Internet-Draft DMM with MIP6 March 2011 1. Introduction Mobility solutions at the IP layer have been specified in the IETF for IPv4 and IPv6. These solutions include host and network based mobility. All of the mobility protocols enable IP session continuity by providing the mobile host with an IP address or prefix that remains constant even as the host moves and attaches to different access networks and points of attachment. Mobile hosts are anchored at a gateway via a tunnel and the address/prefix provided to the host via the gateway remains unchanged across mobility events. All IP sessions initiated or terminated at a mobile host are anchored via the gateway. There are issues and concerns with such a mobility model which are discussed in this document. A mobility model wherein the mobility functions are distributed is a way of alleviating the concerns of a gateway centric approach. This document also considers ways to alleviate anchored mobility issues with approaches that could be considered in a deployment. Mobile IPv6 as specified in [RFC3775] [RFC3776] is a host based mobility protocol. It requires the MN to be anchored at a home agent. The home agent assigns the MN an IPv6 address or prefix that is static for the duration of the registration period. Similarly Proxy Mobile IPv6 [RFC5213] is a network based mobility protocol in which the mobility access gateway (MAG) assigns the MN a prefix provided by the local mobility anchor (LMA) for the duration of a valid registration. This prefix does not change across mobility events. The home agent and LMA entities can be viewed as centralized gateways. These gateways generally serve a large number of mobile hosts. All traffic to/from mobile hosts associated with an HA/LMA is routed through these gateways and as a result raises concerns such as single point of failure, backhauling traffic to the gateway, etc. These are discussed in further detail in the document. It should also be noted that in addition to mobility for hosts, there is also specifications that deal with networks that are mobile. Network mobility is specified in [RFC3963] The mobility working groups in the IETF have extended the basic protocols to address various issues and concerns. Hierarchical Mobile IP [RFC5380] and flow mobility [RFC6088], [RFC6089] are just a few examples. Many of these extensions can be utilized in deployments to alleviate the issues that arise from an anchored mobility solution. A few approaches to how a distributed mobility model could be deployed using current protocols and extensions are also discussed in this document. Patil, et al. Expires September 8, 2011 [Page 3] Internet-Draft DMM with MIP6 March 2011 2. Terminology Distributed Mobility The term distributed mobility refers to an architecture in which the mobility function is distributed across multiple levels in a deployment. The mobility function could be provided by an access point or base-station or it could be a part of the access network. Distributed mobility would enable session continuity for hosts while not requiring that they be anchored at a single gateway (home agent) all the time. 3. Issues with current mobility models Current mobility protocols have been designed a stable topologically correct anchoring in mind. They just do not tolerate mid-session anchor relocation. HMIP6, HA Switch, HA-reliability and LMA Redirect are attempts to that direction but fail when the MN moves out some rather limited administrative area. In addition, one of the deployment considerations of Mobile IPv6 is the location of each of the home agents or gateways, both initially and over time. Each operator has unique requirements; therefore, no single deployment model will suit all operators. The operator's own organizational structure could also influence the mobility architecture. Some operators have network OAM responsibilities that are assigned geographically, while others use a more centralized model. The deployment architecture that has been traditionally put forth is to have a completely centralized model where all mobility control and data traffic is centralized. 3.1. Backhauling all traffic to a centralized GW This leads to backhauling all traffic to a centralized gateway which has unfavorable operational consequences. The sheer volume of the aggregated throughput to backhaul all user data from a local aggregation anchor to centralized data centers with home gateways will be expensive in many scenarios. With high density deployments, the centralized architecture leads to heavy backhaul utilization, and the inability to distribute load soon manifests unfavorably. In addition, local user traffic does not remain local. User traffic must travel all the way to the centralized gateway and back, even if the corresponding peer is topologically closer. In addition, a centralized gateway model increases the cost of backhaul by preventing the off-loading of high-bandwidth services Patil, et al. Expires September 8, 2011 [Page 4] Internet-Draft DMM with MIP6 March 2011 locally. Instead high-bandwidth services have their traffic backhauled to a centralized gateway in a data center. This will increase the distances and possibly the capacity associated with any backhaul. 3.2. Latency Considerations While the support for Internet offload of user data can significantly reduce the core network backhaul, the mobility management element may be strategically positioned deeper in the network to efficiently set-up and process the signaling and control including optional policies. Such a hybrid architecture can provide for supporting a mix of real-time and non-real-time broadband services. Real-time applications can benefit from lower latencies by having data closer to the subscriber and peers and not backhauled. Non-real-time applications (such as e-mail) derive no such performance benefit and may have a more centralized traffic approach. Current mobility models handle offload cases poorly. A consideration may be to clearly make a working toolbox for applications to select a prefix with anchored mobility and a prefix without anchoring. 3.3. Inefficient Routing and signaling overhead Inefficient routing mechanism of a completely centralized mobility deployment approach causes QoS deterioration and may lead to heavy network congestion in the core. In the centralized approach only the HA and the CNs manage a nodes mobility. Mobility signaling occurs each time a mobile node changes its point-of-attachment regardless of the locality and amplitude of its movement. As a consequence, the same level of signaling load is introduced independently of the user's mobility pattern. For example, if the HA and/or CNs are far from the MN, even if the MNs movement is small, the mobility signaling messages travel across several IP networks, the latencies of which reduce handover speed. Furthermore, route optimization which supports direct routing from CNs to the mobile node, generates excessive mobility messages and adds a significant extra load to the network. 3.4. Scalability and cost In a completely centralized Mobile IPv6-based deployment approach, the home agent becomes a single point of failure. Also, a distributed deployment approach may provide better overall capacity and performance, but this must be weighed against the increase in capital costs for deployment of local distributed gateways. In addition, a completely centralized deployment model makes it Patil, et al. Expires September 8, 2011 [Page 5] Internet-Draft DMM with MIP6 March 2011 difficult to scale with a large number of mobile nodes. Scalability costs are weighted from many perspectives such as the number of nodes in the overall system, the geographic distance of the traffic, the number of autonomous parties in the deployment approach and others. The deployment model 4. Enhancements to improve mobility Enhancements to the Mobile IPv6 protocol were done to improve mobile communications in certain circumstances so that mobility is efficient. A key area of enhancements is in the reducing the delays in the data path redirection operation that is defined in Mobile IPv6 operations. Mobile IPv6 has adopted route optimization and HMIPv6 to reduce the traversal of data traffic to the mobile nodes new location changes in its point of attachment. Delays in data traffic redirection will depend upon the location of the anchor agent that performs the redirection. As such enhancements focus on moving these anchor agents closer to the mobile node. 4.1. HMIPv6 Using Mobile IPv6, a mobile node sends location updates to any node it corresponds with each time it changes its location, and at intermittent intervals otherwise. This involves a lot of signaling and processing, and requires a lot of resources. Furthermore, although it is not necessary for external hosts to be updated when a mobile nodes moves locally, these updates occur for both local and global moves. Hierarchical Mobile IPv6 (HMIPv6)is designed to enhance mobility support in MIPv6 and micro-mobility management. The purpose benefit of the HMIPv6 enhancement is to reduce the amount of signaling required and to improve handoff speed. The key concept behind HMIPv6 is to locally handle handovers by the usage of an entity called the Mobility Anchor Point (MAP) located at any level in a hierarchical network of routers. The major issue on HMIPv6 is designing the MAP selection scheme that can reduce frequent handover mobility signaling and improve handover performance. 4.2. Dynamic assignment of HA Dynamic assignment of HA is an enhancement to reduce both the signaling traffic and the data traffic to the home network. The dynamic HA assignment may take into account the geographical proximity of the HA to the mobile node. It may also consider performance factors such as HA load-balancing or other criteria. Patil, et al. Expires September 8, 2011 [Page 6] Internet-Draft DMM with MIP6 March 2011 4.3. Route Optimization Mobile IPv6 Route optimization is an enhancement to optimize the data path between two communicating nodes despite changes in the IP connectivity on the mobile node side. The data path reduction between the communicating nodes helps to reduce one way packet delay when both nodes are under the same localized domain and the mobility gateway is far away. The process of reducing data path is referred to as route optimization. Route optimization helps reduce the delay and thus important for real-time applications. An enhanced version of route optimization may also enable continued communications during periods of temporary home-agent unavailability. 5. Distributed mobility - What does it imply Mobility is a service that provides significant value to a network operator. The ability to offer connectivity and services that work seamlessly across mobility events such as the switching of an access network type etc. creates a much superior end-user experience and thereby a demand for such service. Cellular networks have offered mobility for voice and messaging (short message service) since the late 80s and early 90s. These networks have been evolving and are now offering broadband data services and Internet connectivity. The network architectures are also using Internet protocols and technologies to a significant extent. Traditionally the architectures of these networks has been hierarchical in nature. While such an architecture served operators well in the past, it has limitations when it comes to offering data services and Internet connectivity. There is an effort to distribute functionality that generally has resided in centralized gateways much more closer to the edge of the network. The line between the access and core network is fading and hence a need to rethink how mobility service is affected in such an evolving architecture. Distributed mobility is a way to deploy existing mobility solutions that do not require a mobile host to be anchored at a gateway all the time but instead be attached to different mobility agents/gateways in the network depending on the access, location and other factors. Session continuity via distributed mobility is expected to be on par with that provided by an anchored mobility solution. Does it require an entirely new approach to mobility architectures that would be based on the goal of distributing mobility related functions? It is an easy option to consider redesigning on a clean sheet of paper. However this is not a pragmatic approach. It is much more optimal to consider what are the issues that are created as a result of a centralized gateway architecture and then develop Patil, et al. Expires September 8, 2011 [Page 7] Internet-Draft DMM with MIP6 March 2011 extensions to the protocols and, deployment models, that can address those issues. The implications of distributed mobility architectures on access and core networks needs to be also considered in any design. 6. Approaches using current protocols for distributed mobility We believe that most of the needed basic protocol functionality for distributed mobility management is already there. What is missing seem to be related to general system level design and lack of mobility aware APIs for application developers. One of the simple approaches for distributed mobility management is to avoid traditional "anchored mobility" like Mobile IPv6 when possible and rather use local (care-of) addresses for the communication. Use of local addressing also implies less mobility related signaling load in the network. For example [RFC5014] already provides means for an application to explicitly request for a prefix that has mobility characteristics (IPV6_PREFER_SRC_HOME) or a prefix that is local to the current access network (IPV6_PREFER_SRC_COA). It is not guaranteed that the IP stack in the MN would always respect the suggestion received from the application. In general it is also important that possible solutions in distributed mobility management space requires minimal changes in mobile hosts. Another aspect that is in interest of distributed mobility management concentrates on allocating mobility anchors that are topologically close to the MN. Existing protocols such as HMIPv6 [RFC5380] provide a solution that is close what is needed. What might be needed in addition is a mechanism to "chain" multiple MAP-domain to extend the micro-mobility area, or provide another RFC5014 like prefix type (IPV6_PREFER_SRC_MAP). We could also consider Mobile IPv6 + Proxy Mobile IPv6 interactions Scenario A.1 in [I-D.ietf-netlmm-mip-interactions] a similar solution. Finally, yet another approach for exploiting locality are Proxy Mobile IPv6 localized routing solutions [I-D.ietf-netext-pmip6-lr-ps] which allows bypassing the remote central Local Mobility Anchor when ever possible and have a direct communication via closer to MNs Mobile Access Gateways. Home Agent Switch extension to Mobile IPv6, Runtime LMA assignment [I-D.ietf-netext-redirect] extension to Proxy Mobile IPv6 and Mobile IPv4 Dynamic HA Assignment [RFC4433] all provide solutions to dynamically assign a mobility anchor to the MN. What is missing from these solutions, is a protocol or rather a system level solution for a "seamless mobility anchor relocation" during an existing mobility session. However, that would be rather challenging due the fact that a mobility anchor relocation usually implies topological location Patil, et al. Expires September 8, 2011 [Page 8] Internet-Draft DMM with MIP6 March 2011 chance in the network, which would also mean different prefixes/ subnetworks for home addresses from the IP routing point of view. Within a reasonably small autonomous system or otherwise restricted area maybe some kind of interior routing solution could be used to assist mobility anchor relocation. 7. Potential future work The Mobility Extensions for IPv6 (MEXT) WG in the IETF has been chartered to work on the distributed mobility topic. The potential exists to analyze and understand the implications of the architectures that are now being deployed in 3G and 4G networks and its relation to mobility. One of the key efforts could be in understanding the key concerns driving the need for a distributed mobility solution and identifying various approaches using existing protocols and extensions to overcome them. 1) work on the generic solution for anchor relocation. This might be a architecture describing work, rather than protocol work. I believe we have most protocols already in place but not glued together. 2) work on address selection beyond RFC 5014 (with coloring i.e. the end host stack knows properties of the prefix it got) and rapid deprecation/renumbering of prefixes (needed when CoAs change and applications try to use CoA for something local). This could potentially be new protocol work an containers for coloring prefixes (RA & DHCPv6) and how to handle local prefix deprecation during handovers. 3) work on localized mobility that does not involve signaling with gateways or "mobility signaling". This could lead to work below IP layer or something where e.g. intra-AS mobility is handled using some interior routing protocol enhancement. Potentially a framework document. 8. IANA Considerations This document has no requests to IANA. 9. Security Considerations This document is a discussion of distributed mobility solutions. Some of the approaches that are considered for deployment do have security implications. However since the approaches being discussed are based on existing mobility specifications developed within the IETF, they have already been reviewed for security. This document Patil, et al. Expires September 8, 2011 [Page 9] Internet-Draft DMM with MIP6 March 2011 does not raise any new security concerns. 10. Summary and Conclusion Distributed mobility is a way of deploying mobility protocols that minimise the issues that arise from a centralized gateway centric approach that comes from a hierarchical model. As the amount of traffic in a network grows, operators are less willing to transport all the traffic to a centralized gateway just for the sake of enabling mobility. The mobility models have to evolve to meet the changing environment of mobile networks and traffic patterns. Using many of the extensions and protocols that have been defined for Mobile IPv6 it is possible to deploy a mobility solution that meets the criteria of distributed mobility architecture. The concerns fo a centralized gateway approach can be addressed using deployment techniques effectively. 11. Informative References [I-D.ietf-netext-pmip6-lr-ps] Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized Routing Problem Statement", draft-ietf-netext-pmip6-lr-ps-05 (work in progress), February 2011. [I-D.ietf-netext-redirect] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, "Runtime LMA Assignment Support for Proxy Mobile IPv6", draft-ietf-netext-redirect-05 (work in progress), February 2011. [I-D.ietf-netlmm-mip-interactions] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-ietf-netlmm-mip-interactions-07 (work in progress), October 2010. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Patil, et al. Expires September 8, 2011 [Page 10] Internet-Draft DMM with MIP6 March 2011 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 Dynamic Home Agent (HA) Assignment", RFC 4433, March 2006. [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007. [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. Authors' Addresses Basavaraj Patil (editor) Nokia 6021 Connection drive Irving, TX 75039 USA Email: basavaraj.patil@nokia.com Patil, et al. Expires September 8, 2011 [Page 11] Internet-Draft DMM with MIP6 March 2011 Carl Williams MCSR Labs Palo Alto, CA 94306 USA Email: carlw@mcsr-labs.org Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo FINLAND Email: jouni.nospam@gmail.com Patil, et al. Expires September 8, 2011 [Page 12]