Network Working Group H. Yokota Internet-Draft KDDI Lab Intended status: Informational P. Seite Expires: April 21, 2011 France Telecom - Orange E. Demaria Telecom Italia Z. Cao China Mobile October 18, 2010 Use case scenarios for Distributed Mobility Management draft-yokota-dmm-scenario-00.txt Abstract This document explores applicability of Distributed Mobility Management (DMM) and use case scenarios for different parts of the mobile network. DMM approaches and scenarios are divided into two cases: partially and fully distributed. For each case, benefits and issues are provided. It also refers to applicability of existing protocols and necessity of development of new protocols in order to provide a guideline for best suited solutions for the target architecture. 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 April 22, 2011. Copyright Notice Copyright (c) 2010 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 Yokota, et al. Expires April 22, 2011 [Page 1] Internet-Draft dmm-scenario October 2010 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Yokota, et al. Expires April 22, 2011 [Page 2] Internet-Draft dmm-scenario October 2010 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicable networks for DMM . . . . . . . . . . . . . . . . . 6 3.1. Mobile core network . . . . . . . . . . . . . . . . . . . 6 3.2. Access network . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Host to host . . . . . . . . . . . . . . . . . . . . . . . 7 4. Approaches for DMM . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Partially distributed approach . . . . . . . . . . . . . . 8 4.1.1. Control/data plane separation . . . . . . . . . . . . 8 4.1.2. Dynamic mobility management . . . . . . . . . . . . . 9 4.2. Fully distributed approach . . . . . . . . . . . . . . . . 10 4.2.1. P2P type of network (search and delivery) . . . . . . 10 4.2.2. Broadcast/multicast type of network (multiple delivery) . . . . . . . . . . . . . . . . . . . . . . 11 5. Analysis for applicability . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Yokota, et al. Expires April 22, 2011 [Page 3] Internet-Draft dmm-scenario October 2010 1. Requirements notation 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]. Yokota, et al. Expires April 22, 2011 [Page 4] Internet-Draft dmm-scenario October 2010 2. Introduction Rich content applications, emergence of smart-phones, USB dongles and higher-speed radio access systems are all requiring an exorbitantly high capacity mobile network. Mobility management has adopted a centralized and often hierarchical architecture, for example, Home Agent/Foreign Agent in Mobile IPv4[RFC3344], LMA/MAG in Proxy Mobile IPv6[RFC5213], GGSN/SGSN in GPRS, PDN GW/Serving GW in EPC. However, in order to accommodate ever increasing mobile data traffic, more scalable and distributed architecture needs to be introduced. Existing mobility management protocols, which are designed for a centralized architecture, may need to be extended accordingly. Based on the problem statement in [DMM-PS], this document explores applicability of distributed mobility management and use case scenarios to provide a guideline for best suited solutions. Yokota, et al. Expires April 22, 2011 [Page 5] Internet-Draft dmm-scenario October 2010 3. Applicable networks for DMM Distributed mobility management can be applied at different parts of the mobile network. This section introduces possible scenarios for introducing DMM. +----------+ +----------+ +----------+ \ | HA/LMA | | HA/LMA | ... | HA/LMA | Core-level | +----+-----+ +-----+----+ +-----+----+ | _____|_____________|________________|_____ | Mobile (__________________________________________) > Core | | | | Network +----+-----+ +-----+----+ +-----+----+ | | AR/FA/MAG| | AR/FA/MAG| ... | AR/FA/MAG| AR-level | +----------+ +----------+ +----------+ / _____|_____________|________________|_____ (__________________________________________) | | | | \ +--+--+ +--+--+ +--+--+ +--+--+ | | AP | | AP | | AP | ... | AP | Access-level > Access +-----+ +-----+ +-----+ +-----+ | Network | | | / +--+ +--+ +--+ |MH|--->|MH| |MH| Host-level +--+ +--+ +--+ Figure 1: Multiple level of distribution 3.1. Mobile core network Conventional mobility management assumes a single mobility anchor per MH (e.g., home agent), which has been regarded as a negative aspect due to the cause of concentration of mobile data traffic and a single point of failure. By topologically distributing mobility anchors, mobile hosts can be managed in a decentralized way and mobile data traffic can also be distributed ("Core-level" distribution in Figure 1). If each mobility anchor covers specific geographical area and a mobile host crosses this boundary, change of the mobility anchor occurs, and this handover must be handled properly by, for example, transferring the binding information of the mobile host from the old to the new mobility anchor. When different mobility anchors manage different blocks of IP addresses, packet delivery to/from the mobile host must also be assured after handover. If the mobile network adopts hierarchical architecture, such as home agent and foreign agent in Mobile IPv4 or local mobility anchor and mobile access gateway in PMIPv6, more flat architecture can be considered by confining the mobility management within a specific Yokota, et al. Expires April 22, 2011 [Page 6] Internet-Draft dmm-scenario October 2010 region and directly exchanging mobile data at a specific level of hierarchy ("AR-level" distribution in Figure 1). The former approach is regarded as localized mobility management and the latter as route localization. Several methods and protocols have been proposed, but no universal and self-contained protocol exists. Moreover, there are different possibilities to distribute mobility functions. The mobility anchors may be confined to the first access router; but less flat mobility architecture is also possible where a flatten mobility anchor is meant to anchor the traffic of several access routers. 3.2. Access network Location of information content is getting distributed and closer to users. Consumer Generated Media (CGM) contributed by end users can be innately located in a distributed manner. Content Delivery Network, which has been constructed near the backbone network, is getting more distributed along with cache technology and closer to the access network for further efficient use of network resources. As a wireless access method, WiFi is rapidly prevailing and its access points are being more installed in residential and public areas. As for the cellular system as well, picocell or femtocell are gaining higher attention for more efficient spectrum usage and data traffic offload (e.g., 3GPP LIPA/SIPTO). These access nodes basically have layer 2 capability, but by adding layer 3 capability, they can handle IP-level mobility management working as, for example, a foreign agent or MAG ("Access-level" distribution in Figure 1). The same protocol can be applied as in Section 3.1, but the number of access nodes (i.e., WiFi APs or pico/femto-cells) is much larger to the home agent and more frequent handover is likely to happen. Therefore, scalability and signaling overhead need to be more carefully considered. 3.3. Host to host This is more peer-to-peer approach, whereby once the corresponding host is found, both hosts directly communicate ("Host-level" distribution in Figure 1). In order to discover the peer host, information server such as DNS is required in the network, which can be centralized or distributed. While MIPv6[RFC3775] is not a peer- to-peer communication protocol, its route optimization mechanism can provide a host-to-host communication leveraging the home agent. Yokota, et al. Expires April 22, 2011 [Page 7] Internet-Draft dmm-scenario October 2010 4. Approaches for DMM 4.1. Partially distributed approach Distributed approach can be applied partially (1) by considering the separation of control and data planes with taking advantage of differences in traffic volume or host behavior, and/or (2) by providing mobility only to the hosts who really need it, thereby saving resources for mobility management. 4.1.1. Control/data plane separation Conventional mobility management protocols such as Mobile IP or Proxy Mobile IP combine the control and data planes, which means that all signaling packets and data packets go through the home agent or local mobility anchor (MIPv6 route optimization[RFC3775] is not considered). The volume of data traffic is much higher than that of control traffic, so by separating the control and data planes and applying a distributed architecture to the data plane, effective traffic distribution can be achieved without reallocating mobility anchors during the session, as described in Section 3.1. This simplifies the interaction between distributed mobility anchors (MAs), but new signaling between the control and data plane functional entities is required. A partially distributed mobility management is depicted in Figure 2. In this example, the routing function of the mobility anchor (MA) is confined with the access router, but less flat deployment is also possible (see Section 3.1). If the mobile host attaches to MA1 and initiates an IP communication with a correspondent host (CH), the traffic will be anchored to MA1. When performing handover to MA2, the control function updates the routing state of MA1 in order to forward packets to the new MH's location. Registration update to the control function may be initiated by the host or controlled by the network. Yokota, et al. Expires April 22, 2011 [Page 8] Internet-Draft dmm-scenario October 2010 +----------+ Registration |Control |<-------------------+ | Function |------------------+ | +----------+ Route Setup | | ^ | | | Reg. V V | +--|-------+ data +---|------+ | | *****************************| | | | * MA1 | | *| MA2 | +--|-*-----+ +--*|------+ | * *| +|-*-+ +*|--+ | MH | | MH | +----+ +----+ Figure 2: Control/data plane separation scenario 4.1.2. Dynamic mobility management If the mobile host is nomadic meaning once attached, rarely moved, or is idle in most of time, it should be enough to provide handover capability only when it is really needed. This can save signaling traffic and resources for maintaining mobility bindings. One scenario, which is depicted in Figure 3, is that the mobile host acquires an IP address (IP1) from the local access router (AR1) and when this mobile host moves to another network, this local access router plays a role of home agent to this mobile host and interacts with the access router (AR2) in the new network for continuous packet delivery. Communications newly initiated with IP2 while the mobile host is attached to AR2 will be routed in a standard way. In other words, the mobile host plays with an IP flow to AR1 (the IP flow initiated while attached to AR1) and an IP flow via AR2. If the mobile node moves away from AR2, while maintaining communications, two mobility anchors will come into play: the data traffic will be anchored in AR1 for communication initiated via AR1 and in AR2 for communication initiated via AR2. Yokota, et al. Expires April 22, 2011 [Page 9] Internet-Draft dmm-scenario October 2010 data:IP1 +--------+ *************| | data:IP2 * **********| CH |oooooooooo * * +--------+ o *->* o * * o +--*--*----+ +----o-----+ | * * AR1| _______________ | o AR2| | * *******)_______________)**** o | +--*-------+ +--*-o-----+ *<--IP1 IP1-->* o<--IP2 +*---+ +*-o-+ | MH | -------------> | MH | +----+ +----+ Figure 3: Dynamic mobility management Dynamic mobility management can be combined with the approaches for control/data plane distribution considered in this document (i.e., separation of control and data planes in Section 4.1.1 and fully distributed approach in Section 4.2). 4.2. Fully distributed approach This section describes the distribution schemes applied to both control and data planes. One of the most significant issues of the distributed control plane (e.g., distributed home agents), is that a special mechanism is needed to identify the mobility anchor that maintains the mobility binding of the mobile host. In a fully distributed mobility management, the routing and control functions of the mobility anchor (MA) are confined with an access router, but less flat deployment is also possible (see Section 3.1). If the mobile host attaches to a MA and initiates an IP communication with a correspondent node, the traffic will be anchored to this MA. When performing handover to another MA, this movement will be shared by these two MAs or all MAs or may be handled independently. The previous MA can forward packets to the new MH's location with this information. Registration update to the control function can be initiated by the host or controlled by the network. The following subsections provide clues to fully distributed mobility management schemes. 4.2.1. P2P type of network (search and delivery) This approach searches for the correct mobility anchor before delivering packets. Distributed Hash Table (DHT) is a popular Yokota, et al. Expires April 22, 2011 [Page 10] Internet-Draft dmm-scenario October 2010 mechanism for its efficiency. However, as the number of mobility anchors increases, the number of hops increases and the search time cannot be ignored. Also, when the mobile host moves to another network, the location information needs to be updated and according to the search scenario, this information may need to be disseminated among distributed mobility anchors. The user data can be continuously delivered to the MH in the new location by, for example, the new MA's searching for the old MA and getting data forwarded from it. +----------+ Search | | Search +--------->| MA |<-------+ | +----------+ | | | V V +----------+ Search +----------+ | |<---------------->| | | MA**************************** MA | +--^--*----+ data +--*-^-----+ Reg.* * |Reg. +|--*+ +*-|-+ | MH | | MH | +----+ +----+ Figure 4: P2P type of network 4.2.2. Broadcast/multicast type of network (multiple delivery) In this approach, packets are delivered to all or multiple mobility anchors and only the corresponding mobility anchor delivers the packets to the mobile host. This does not require the search mechanism and the signaling between MAs is not mandatory when the MH moves to a new location, but the use of the network resources is not efficient since the packets are multiply delivered. This is effective and feasible in relatively limited areas; from local to metropolitan areas, but not suitable for the global area network. Yokota, et al. Expires April 22, 2011 [Page 11] Internet-Draft dmm-scenario October 2010 +----------+ +----------+ | | data | | | MA | **************| MA | +----------+ * +----------+ data * * * * +-----*----+ * +----------+ | *********** | | | MA**************************** MA | +--^--*----+ data +--*-^-----+ Reg.* * |Reg. +|--*+ +*-|-+ | MH | | MH | +----+ +----+ Figure 5: BC/MC type of network Yokota, et al. Expires April 22, 2011 [Page 12] Internet-Draft dmm-scenario October 2010 5. Analysis for applicability In the case where the current hierarchical mobile network architecture should be maintained, Core-level distribution is one scenario and a new protocol is needed to handle the reallocation of HA/LMA for an active session. If a more flat architecture is desired, the role of the HA/LMA should be minimized and AR-level or Access-level distribution is a more preferred scenario. Two scenarios can be envisaged: only the routing functions of mobility anchors can be distributed or the mobility management can be fully distributed, meaning that both the control and routing functions of mobility anchors are distributed closer to the access routers. In the first scenario, the control/data plane separation is considered; in this case, a new protocol between the control functional entity, which maintains the mobility bindings, and the data functional entity, which routes data packets to the corresponding peer entity, is needed. Distributing the mobility anchor close to the access would lead to inter AR/MAG mobility. In this case, inter-AR/MAG communications features of FMIPv4/v6[RFC4988][RFC5568] or PFMIPv6[RFC5949] can be used. When PMIPv6 is used, Localized routing for PMIPv6[ID-PMIPv6LR] can be considered for direct routing between MAGs. Note that the scenario where the LMAs are distributed is not included in this work. For Host-level distribution, MIPv6 route optimization mechanism can be a candidate to support this scenario. Distribution of mobility anchors facilitates the dynamic mobility management since IP flows can be individually anchored close to the access router on which the host was attached when initiating the IP communication. Dynamic feature may not require specific support and existing mobility protocols could be used. An example of fully distributed and dynamic mobility management is described in [ID-DMA]. Depending on the mobility scenario, the mobile host may have two IP addresses: one for direct communication and another for mobility, which must be sustained before and after handover, in which case the mobile host needs to be capable of distinguishing them (with the help of the network). If fully distributed approach is sought, a mechanism to find the network node that holds the location of the mobile host needs to be clarified. This document gives only clues for solutions but detailed work in the area is clearly needed. The broadcast/multicast approach is a simpler scenario and may not require a specific signaling protocol This approach, however, will be more suitable for a limited scope of network; for example, campus network, metropolitan area network or data center network could benefit from this approach. Yokota, et al. Expires April 22, 2011 [Page 13] Internet-Draft dmm-scenario October 2010 6. Security Considerations Security aspect is not considered in this document. Yokota, et al. Expires April 22, 2011 [Page 14] Internet-Draft dmm-scenario October 2010 7. IANA Considerations This specification does not require any IANA Actions. Yokota, et al. Expires April 22, 2011 [Page 15] Internet-Draft dmm-scenario October 2010 8. Co-authors and Contributors This document is a joint effort by the following participants as well as those on the authors' list. Each individual has made significant contributions to this work. Dapeng Liu: liudapeng@chinamobile.com H. Anthony Chan: h.a.chan@ieee.org Charles E. Perkins: charles.perkins@tellabs.com Telemaco Melia: telemaco.melia@alcatel-lucent.com Hui Deng: denghui@chinamobile.com Wassim Haddad: Wassam.Haddad@ericsson.com Yokota, et al. Expires April 22, 2011 [Page 16] Internet-Draft dmm-scenario October 2010 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [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. [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009. [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", RFC 4988, October 2007. [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 2010. 9.2. Informative References [DMM-PS] Chan, H., Ed., "Problem statement for distributed and dynamic mobility management", draft-chan-distributed-mobility-ps-00, October 2010. [ID-DMA] Seite, P., Ed. and P. Bertin, "Dynamic Mobility Anchoring", draft-seite-netext-dma-00.txt , March 2010. [ID-PMIPv6LR] Krishnan, S., Ed., "Localized Routing for Proxy Mobile IPv6", draft-krishnan-netext-pmip-lr-02 , July 2010. Yokota, et al. Expires April 22, 2011 [Page 17] Internet-Draft dmm-scenario October 2010 Authors' Addresses Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama, 356-8502 Japan Email: yokota@kddilabs.jp Pierrick Seite France Telecom - Orange 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 France Email: pierrick.seite@orange-ftgroup.com Elena Demaria Telecom Italia via G. Reiss Romoli, 274 TORINO, 10148 Italy Email: elena.demaria@telecomitalia.it Zhen Cao China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing, 100053 China Email: zehn.cao@gmail.com Yokota, et al. Expires April 22, 2011 [Page 18]