MEXT Working group D. Liu (Ed.) Internet-Draft China Mobile Intended status: Informational March 7, 2011 Expires: September 8, 2011 Distributed Deployment of Mobile IPv6 draft-liu-mext-distributed-mobile-ip-00 Abstract This document describes a distributed deployment approach of mobile IPv6 protocol. 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. 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. Liu (Ed.) Expires September 8, 2011 [Page 1] Internet-Draft Distributed Mobile IP March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Distributed Mobility Deployment Scenario . . . . . . . . . . . 3 4. Limitations of Centralized Approach . . . . . . . . . . . . . 4 4.1. Non-optimal Routes . . . . . . . . . . . . . . . . . . . . 4 4.2. Non-optimality in Evolved Network Architecture . . . . . . 6 4.3. Low Scalability of Centralized Route and Mobility Context Maintenance . . . . . . . . . . . . . . . . . . . 6 4.4. Wasting Resources to Support Mobile Nodes Not Needing Mobility Support . . . . . . . . . . . . . . . . . . . . . 7 4.5. Complicated Deployment with Too Many Variants and Extensions of MIP . . . . . . . . . . . . . . . . . . . . 7 4.6. Mobility Signaling Overhead with Peer-to-Peer Communications . . . . . . . . . . . . . . . . . . . . . . 8 4.7. Single Point of Failure and Attack . . . . . . . . . . . . 8 5. Distributed Mobility Deployment Solution . . . . . . . . . . . 8 6. Distributed Mobility Deployment Considerations . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Co-authors and contributors . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Liu (Ed.) Expires September 8, 2011 [Page 2] Internet-Draft Distributed Mobile IP March 2011 1. Introduction Mobile IPv6 and its variations are based on the similar principles where a given mobility agent (e.g. the Home Agent (HA) in Mobile IP) maintains Mobile Nodes (MNs) bindings. Data traffic is then encapsulated between the MN and its mobility agent. These approaches lead to the implementation of centralised architectures where both MN context and traffic encapsulation need to be maintained at a central network entity, the mobility agent. Thus, when hundreds of thousands of MNs are communicating in a given communicating in a given cellular network, a centralized mobility anchoring point causes well-known bottlenecks and single point of failure issues, which requires costly network dimensioning and engineering to be fixed. In addition, tunnelling encapsulations impact the overall network efficiency since they require the maintenance of MN's specific contexts in each tunnel end nodes and they incur delays in packet processing and transport functions. This document introduces a distributed approach of deployment mobile ipv6 and its variations in a more optimal way especially for the flat network architecture. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Distributed Mobility Deployment Scenario The rapid increasing of mobile data traffic giving much pressure to the mobile operator's core network. To lower the cost, it is now preferable to offload the traffic that are not generated by mobile services from the IP core of the mobile network (e.g. Internet traffic should be offloaded). On the other hand, IP communications with mobile services are routed via a centralized anchor point (e.g., the PGW in 3GPP/EPS mobile network). In current proposals for network evolution, a local traffic anchor (i.e. a local gateway, L-GW), usually located near the access router, is in charge of offloading the traffic (e.g. Internet and local traffic). Liu (Ed.) Expires September 8, 2011 [Page 3] Internet-Draft Distributed Mobile IP March 2011 +----+ ,-'' |CN |. +----------+ ,' +----+ \---------| central | / Packet \ | anchor | | Data | +----------+ \ Network ,' | `. _, | `-..____,,' ***************** * IP network * __...._ * * ,' `-. +---------+ +----+ +----+ / Internet \ | Local |__ |L-GW| |L-GW|--- | Access | | Content | +----+ +----+ \ ,' | Delivery| * * `-._ _,' | Network | ****************** `''' +---------+ || || +----+ +----+ |AR1 | |AR2 | +----+ +----+ | | | | | | MN1 MN2 MN3 Figure 1: Scenario of L-GW deployment In this scenario, mobile ip deployment is different from traditional centralized way. Considerations should be made to deploy mobile ip in a more optimal way in this architecture. 4. Limitations of Centralized Approach This section describes the problems or limitations in a centralized mobility approach and compares it against the distributed approach. 4.1. Non-optimal Routes Routing via a centralized anchor often results in a longer route. Figure 2 shows two cases of non-optimized routes. Liu (Ed.) Expires September 8, 2011 [Page 4] Internet-Draft Distributed Mobile IP March 2011 +------+ |HA/LMA| +------+ /\ \ \ +---+ / \ \ \ |CDN| / \ \ \ +---+ / \ \ \ | / \ \ \ | +------+ +------+ +------+ +------+ |FA/MAG| |FA/MAG| |FA/MAG| |FA/MAG| +------+ +------+ +------+ +------+ | | ---- ---- | CN | | MN | ---- ---- Figure 2: Non-optimized route when communicating with CN and when accessing local content. In the first case, the MN and the CN are close to each other but are both far from the mobility anchor. Packets destined to the MN need to be routed via the mobility anchor, which is not in the shortest path. The second case involves a content delivery network (CDN). A user may obtain content from a server, such as when watching a video. As such usage becomes more popular, resulting in an increase in the core network traffic, service providers may relieve the core network traffic by placing these contents closer to the users in the access network in the form of cache or local CDN servers. Yet as the MN is getting content from a local or cache server of a CDN, even though the server is close to the MN, packets still need to go through the core network to route via the mobility anchor in the home network of the MN, if the MN uses the HoA as the session identifier. In a distributed mobility management design, mobility anchors are distributed in different access networks so that packets may be routed via a nearby mobility anchor function, as shown in Figure 2. Due to the above limitation, with the centralized mobility anchor design, route optimization extensions to mobility protocols are therefore needed. Whereas the location privacy of each MN may be compromised when the CoA of an MN is given to the CN, those mobility protocol deployments that lack such optimization extensions will encounter non-optimal routes, which affect the performance. In contrast, route optimization may be naturally an integral part of a distributed mobility management design. Liu (Ed.) Expires September 8, 2011 [Page 5] Internet-Draft Distributed Mobile IP March 2011 4.2. Non-optimality in Evolved Network Architecture Centralized mobility management is currently deployed to support the existing hierarchical mobile data networks. It leverages on the hierarchical architecture. However, the volume of wireless data traffic continues to increase exponentially. The data traffic increase would require costly capacity upgrade of centralized architectures. It is thus predictable that the data traffic increase will soon overload the centralized data anchor point, e.g., the P-GW in 3GPP EPS. In order to address this issue, a trend in the evolution of mobile networks is to distribute network functions close to access networks. These network functions can be the content servers in a CDN, and also the data anchor point. Mobile networks have been evolving from a hierarchical architecture to a more flattened architecture. In the 3GPP standards, the GPRS network has the hierarchy GGSN - SGSN - RNC - NB (Node B). In 3GPP EPS networks, the hierarchy is reduced to P-GW - S-GW - eNB (Evolved NB). In some deployments, the P-GW and the S-GW are collocated to further reduce the hierarchy. Reducing the hierarchy this way reduces the number of different physical network elements in the network, contributing to easier system maintenance and lower cost. As mobile networks become more flattened, the centralized mobility management can become non- optimal. Mobility management deployment with distributed architecture is then needed to support the more flattened network and the CDN networks. 4.3. Low Scalability of Centralized Route and Mobility Context Maintenance Special routes are set up to enable session continuity when a handover occurs. Packets sent from the CN need to be tunneled between the HA and FA in MIP and between the LMA and MAG in PMIP. However, these network elements at the ends of the tunnel are also routers performing the regular routing tasks for ordinary packets not involving a mobile node. These ordinary packets need to be directly routed according to the routing table in the routers without tunneling. Therefore, the network must be able to distinguish those packets requiring tunneling from the regular packets. For each packet that requires tunneling owing to mobility, the network will encapsulate it with a proper outer IP header with the proper source and destination IP addresses. The network therefore needs to maintain and manage the mobility context of each MN, which is the relevant information needed to characterize the mobility situation of that MN to allow the network to distinguish their packets from other packets and to perform the required tunneling. Setting up such special routes and maintaining the mobility context for each MN is more difficult to scale in a centralized design with a large number of MNs. Distributing the route maintenance function and the mobility Liu (Ed.) Expires September 8, 2011 [Page 6] Internet-Draft Distributed Mobile IP March 2011 context maintenance function among different networks can be more scalable. 4.4. Wasting Resources to Support Mobile Nodes Not Needing Mobility Support The problem of centralized route and mobility context maintenance is aggravated when the via routes are set up for many more MNs that are not requiring IP mobility support. On the one hand, the network needs to provide mobility support for the increasing number of mobile devices because the existing mobility management has been designed to always provide such support as long as a mobile device is attached to the network. On the other hand, many nomadic users connected to a network in an office or meeting room are not even going to move for the entire network session. It has been studied that over two-thirds of a user mobility is local. In addition, it is possible to have the intelligence for applications to manage mobility without needing help from the network. Network resources are therefore wasted to provide mobility support for the devices that do not really need it at the moment. It is necessary to dynamically set up the via routes only for MNs that actually undergo handovers and lack higher-layer mobility support. With distributed mobility anchors, such dynamic mobility management mechanism may then also be distributed. Therefore, dynamic mobility and distributed mobility may complement each other and may be integrated. 4.5. Complicated Deployment with Too Many Variants and Extensions of MIP Mobile IP (MIP), which has primarily been deployed in a centralized manner for the hierarchical mobile networks, already has numerous variants and extensions including PMIP, Fast MIP (FMIP), Proxy-based FMIP (PFMIP), hierarchical MIP (HMIP), Dual-Stack Mobile IP (DSMIP) and there may be more to come. These different modifications or extensions of MIP have been developed over the years owing to the different needs that are found afterwards. Deployment can then become complicated, especially if interoperability with different deployments is an issue. While adaptations for MIP are being proposed for the deployment in a distributed manner for more flattened networks, it is desirable to also take a holistic view of different networks and scenarios and integrate the different MIP extensions. The result will then be a more comprehensive mobility solution with options that can be turned on or off depending on different scenarios. A desirable feature of mobility management is to be able to work with network architectures of both hierarchical networks and flattened networks, so that the mobility management protocol possesses enough flexibility to support different networks. In addition, one goal of dynamic mobility management is the Liu (Ed.) Expires September 8, 2011 [Page 7] Internet-Draft Distributed Mobile IP March 2011 capability to selectively turn on and off mobility support and certain different mobility signaling. Such flexibility in the design is compatible with the goal to integrate different mobility variants as options. Some additional extensions to the base protocols may then be needed to improve the integration. 4.6. Mobility Signaling Overhead with Peer-to-Peer Communications In peer-to-peer communications, end users communicate by sending packets directly addressed to each other's IP address. However, they need to find each other's IP address first through signaling in the network. While different schemes for this purpose may be used, MIP already has a mechanism to locate an MN and may be used in this way. In particular, MIPv6 Route Optimization (RO) mode enables a more efficient data packets exchange than the bidirectional tunneling (BT) mode. This RO mode is expected to be used whenever possible unless the MN is not interested in disclosing its topological location, i.e., the CoA, to the CN (e.g., for privacy reasons) or some other network constraints are put in place. However, MIPv6 RO mode requires exchanging a significant amount of signaling messages in order to establish and periodically refresh a bidirectional security association (BSA) between an MN and its CN. While the mobility signaling exchange impacts the overall handover latency, the BSA is needed to authenticate the binding update and acknowledgment messages (note that the latter is not mandatory). In addition, the amount of mobility signaling messages increases further when both endpoints are mobile. A dynamic mobility management capability to turn off these signaling when they are not needed will enable the RO mode between two mobile endpoints at minimum or no cost. It will also reduce the handover latency owing to the removal of the extra signaling. These benefits for peer-to-peer communications will encourage the adoption and large-scale deployment of dynamic mobility management. 4.7. Single Point of Failure and Attack A centralized mobility anchoring architecture is generally more vulnerable to a single point of failure or attack, requiring duplication and backups of the support functions. On the other hand, a distributed mobility management architecture has intrinsically mitigated the problem to a local network which is then of a smaller scope. In addition, the availability of such functions in neighboring networks has already provided the needed architecture to support protection. 5. Distributed Mobility Deployment Solution One solution to deploy Mobile IP in a flat architecture is to Liu (Ed.) Expires September 8, 2011 [Page 8] Internet-Draft Distributed Mobile IP March 2011 implement the HA functionalities in the access routers, as shown on Figure 2. Any given IP flow can be considered as implicitly anchored on the current host's access router when set up. In addition, dynamic mobility anchoring [I-D.kassi-mobileip-dmi] could avoid data encapsulation for motionless nodes: until the host does not move, the IP flow is delivered as for any standard IPv6 node. The anchoring function at the access router is acting only to manage traffic indirection while the host moves to a new access router. So, when the MN handoff, its current traffic is still attached to the anchor access router which is responsible for forwarding the IP flows to the MN.For example, let's consider an IP flow, flow#1, initiated by the mobile node, MN, when attached to AR2. Flow#1 will is routed in a standard way as long as the MN remain attached to AR2. If the MN moves to AR3, flow#1 remains anchored to AR2, which plays the role of HA. If MN starts a new IP communication, flow#2, while attached to AR3; flow#2 will be routed in a standard way as long as the MN remains attached to AR3. Then, if the MN moves to AR1, flow#1 and flow#2 will be respectively anchored to AR2/HA and AR3/HA. +---+ +---+ +---+ |CN1| |CN2| |CN3| +---+ +---+ +--,+ _.---------+----------. \ ,----'' | `---'-. ,-' |flow#1 \ `-. ,' | ' `. ( IP Network| \ `. | ' ,' `-. ; ,\' ;-----. ; _.----' ' ,' `---------+----------'' | / | ' +---'---+ +---:---+ +-------+ | AR1 | | AR2`--|------------| AR3 | | HA | | HA |------------|HA | +-------+ +-------+ +-------+ flow#1 \\ \flow#2 tunnelled \\ ' +-----+ +--\--+ | MN | ----move-------> | MN | +-----+ +-----+ Liu (Ed.) Expires September 8, 2011 [Page 9] Internet-Draft Distributed Mobile IP March 2011 Figure 3: Distributed Client Based Mobility 6. Distributed Mobility Deployment Considerations The following considerations should be applied in distributed mobile ip deployment: 1. multiple home address handling The mobile node will have multiple home agents associate with it. Each home agent will assign a home address to the mobile node. The applications on the mobile node need to select the right home address to matain the session continuity. The sessions that established before handover should use the home address which is allocated by the previous home agent. The newly initiate session should use the home address that newly allocated by the current home agent. 2. HA selection The mobile node should select the nearest HA for its communication. Mechanisms should be specified for the nearest HA selection. 3. CN initiate communication Since the mobile node has multiple home addresses, the CN should choose the proper home address to initate communication with the mobile node. Mechanisms should be specified for CN to chose the proper home address. 7. Security Considerations TBD 8. IANA Considerations None 9. Co-authors and contributors The following people contributed to this document (in no specific order): Pierrick Seite: pierrick.seite@orange-ftgroup.com Liu (Ed.) Expires September 8, 2011 [Page 10] Internet-Draft Distributed Mobile IP March 2011 Hidetoshi Yokota: yokota@kddilabs.jp Charles E. Perkins: charles.perkins@tellabs.com Melia Telemaco: telemaco.melia@alcatel-lucent.com Elena Demaria: elena.demaria@telecomitalia.it Wassim Michel Haddad: Wassam.Haddad@ericsson.com Jun Song: song.jun@zte.com.cn Hui Deng: denghui@chinamobile.com Zhen Cao: caozhen@chinamobile.com other contributors and co-authors will be added in the update version. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.chan-netext-distributed-lma] Chan, H., Xia, F., Xiang, J., and H. Ahmed, "Distributed Local Mobility Anchors", draft-chan-netext-distributed-lma-03 (work in progress), March 2010. [I-D.ietf-mext-flow-binding] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic Support", draft-ietf-mext-flow-binding-11 (work in progress), October 2010. [I-D.kassi-mobileip-dmi] Kassi-Lahlou, M., "Dynamic Mobile IP (DMI)", draft-kassi-mobileip-dmi-01 (work in progress), January 2003. [I-D.seite-netext-dma] Seite, P. and P. Bertin, "Dynamic Mobility Anchoring", Liu (Ed.) Expires September 8, 2011 [Page 11] Internet-Draft Distributed Mobile IP March 2011 draft-seite-netext-dma-00 (work in progress), May 2010. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. Author's Address Dapeng Liu China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: liudapeng@chinamobile.com Liu (Ed.) Expires September 8, 2011 [Page 12]