DMM Working Group CJ. Bernardos Internet-Draft A. de la Oliva Intended status: Standards Track UC3M Expires: July 30, 2012 F. Giust IMDEA Networks and UC3M T. Melia Alcatel-Lucent January 27, 2012 A PMIPv6-based solution for Distributed Mobility Management draft-bernardos-dmm-pmip-00 Abstract The number of mobile users and their traffic demand is expected to be ever-increasing in future years, and this growth can represent a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. For this reason it has been waved a need for distributed and dynamic mobility management approaches, with the objective of reducing operators' burdens, evolving to a cheaper and more efficient architecture. This draft describes a solution to distribute the data forwarding plane on Proxy Mobile IPv6 domains, thus trying to overcome the suboptimal data path introduced when the LMA is traversed. 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 July 30, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Bernardos, et al. Expires July 30, 2012 [Page 1]
Internet-Draft A DMM solution for PMIPv6 January 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Description of the solution . . . . . . . . . . . . . . . . . 4 3.1. Initial registration . . . . . . . . . . . . . . . . . . . 5 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . . 5 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 7 3.4. The CMD as PBU/PBA proxy . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Bernardos, et al. Expires July 30, 2012 [Page 2]
Internet-Draft A DMM solution for PMIPv6 January 2012 1. Introduction Current IP mobility solutions, standardized with the names of Mobile IPv6 [RFC6275], or Proxy Mobile IPv6 [RFC5213], just to cite the two most relevant examples, offer mobility support at the cost of handling operations at a cardinal point, the mobility anchor, and burdening it with data forwarding and control mechanisms for a great amount of users. As stated in [I-D.chan-distributed-mobility-ps], centralized mobility solutions are prone to several problems and limitations: longer (sub-optimal) routing paths, scalability problems, signaling overhead (and most likely a longer associated handover latency), more complex network deployment, higher vulnerability due to the existence of a potential single point of failure, and lack of granularity on the mobility management service (i.e., mobility is offered on a per-node basis, not being possible to define finer granularity policies, as for example per-application). There are basically two main approaches being researched now: one aimed at making Mobile IPv6 work in a distributed way (a complete solution can be found in [I-D.bernardos-mext-dmm-cmip]), and another one doing the same exercise for Proxy Mobile IPv6. In this draft we describe a solution to achieve a DMM behavior for network-based mobility support (i.e., inspired by PMIPv6). This document is based on a research paper of the same authors, currently under submission, called "A Network-based Localized Mobility Solution for Distributed Mobility Management" [Net-basedDMM]. 2. Terminology The following terms used in this document are defined in the Proxy Mobile IPv6 specification [RFC5213]: Local Mobility Anchor (LMA) Mobile Access Gateway (MAG) Mobile Node (MN) Binding Cache Entry (BCE) Proxy Care-of Address (P-CoA) Proxy Binding Update (PBU) Proxy Binding Acknowledgement (PBA) The following terms are defined and used in this document: Bernardos, et al. Expires July 30, 2012 [Page 3]
Internet-Draft A DMM solution for PMIPv6 January 2012 MAAR (Mobility Anchor and Access Router). First hop routers where the mobile nodes attach to. They also play the role of mobility managers for the IPv6 prefixes they anchor. CMD (Central Mobility Database). Node that stores the BCEs for the MNs in the mobility domain. A-MAAR (Anchor MAAR). MAAR which was previously visited by the MN and is still involved in an active flow using an IPv6 prefix it has advertised to the MN (i.e., MAAR where that IPv6 prefix is anchored). S-MAAR (Serving MAAR). MAAR which the MN is currently attached to. 3. Description of the solution The purpose of Distributed Mobility Management approaches is to overcome the limitations of the traditional centralized mobility management by bringing the mobility anchor closer to the MN. Following this idea, in our proposal, the central anchor is moved to the edge of the network, being deployed in the default gateway of the mobile node. That is, the first elements that provide IP connectivity to a set of MNs are also the mobility managers for those MNs. In the following, we will call these Mobility Anchor and Access Routers (MAARs). However, MAARs leverage on the Central Mobility Database (CMD) to access and update information related to the MNs, stored as mobility sessions; hence, a centralized node maintains a global view on the status of the network. The CMD is queried whenever a MN is detected to join the mobility domain. It might be a fresh attachment or a handover, but as MAARs do not store any mobilty session, they contact the CMD to retrieve the data of interest and eventually take the appropriate action. The procedure adopted for the query and the messages exchange sequence might vary to optimize the update latency and/or the signaling overhead. Here is presented one method for the initial registration, and three different approaches to update the mobility sessions using PBUs and PBAs. Each approach assigns a different role to the CMD: o The CMD is a PBU/PBA relay o The CMD is only a MAAR locator o PBU/PBA is a PBU/PBA proxy Bernardos, et al. Expires July 30, 2012 [Page 4]
Internet-Draft A DMM solution for PMIPv6 January 2012 3.1. Initial registration Upon the MN's attachment to a MAAR, say MAAR1, an IPv6 global prefix belonging to the MAAR's prefix pool is reserved for it (Pref1). The prefix is sent in a PBU with the MN's Identifier (MN-ID) to the CMD, which, since the session is new, stores a Binding Cache Entry containing as main fields the MN-ID, the MN's prefix and MAAR1's address as Proxy-CoA. The CMD replies to MAAR1 with a PBA indicating that the MN's registration is fresh and no past status is available. MAAR1 sends a Router Advertisement (RA) in unicast to the MN including the prefix reserved before, that can be used by the MN to configure an IPv6 address (e.g., with stateless auto-configuration). The address is routable at the MAAR, in the sense that it is on the path of packets addressed to the MN. Moreover, the MAAR acts as plain router for those packets, as no encapsulation nor special handling takes place. Figure 1 illustrates this scenario. +-----+ +---+ +--+ |MAAR1| |CMD| |CN| +-----+ +---+ +*-+ | | * MN | * +---+ attach. | ***** _|CMD|_ detection | flow1 * / +-+-+ \ | | * / | \ |--- PBU -->| * / | \ | | * / | \ | BCE +---*-+-' +--+--+ `+-----+ | creation | * | | | | | | | |MAAR1+------+MAAR2+-----+MAAR3| |<-- PBA ---| | * | | | | | | | +---*-+ +-----+ +-----+ | | * | | Pref1 * | | +*-+ | | |MN| | | +--+ (Operations sequence) (Packets flow) Figure 1: First attachment to the network 3.2. The CMD as PBU/PBA relay When the MN moves from its current access, it associates to MAAR2 (now the S-MAAR), which delegates another IPv6 prefix (Pref2) and sends it to the CMD for registration. The CMD has already an entry for the MN, binding the MN-ID to its former location; thus, it Bernardos, et al. Expires July 30, 2012 [Page 5]
Internet-Draft A DMM solution for PMIPv6 January 2012 forwards the PBU to the MAAR indicated as Proxy CoA, in this case MAAR1 (now the A-MAAR), and it updates the P-CoA field with the S-MAAR's address. Upon PBU reception, MAAR1 replies to the CMD with a PBA to ensure that the new location has successfully changed, containing the prefix anchored at MAAR1. The CMD updates the BCE adding the P-MAAR address in the list of old P-CoAs and forwards the PBA to the new S-MAAR, containing the previous Proxy-CoA and the prefix anchored to it, so that a tunnel can be established between the two MAARs and new routes are set appropriately to recover the flow(s). Now packets destined to Pref1 are first received by MAAR1, encapsulated into the tunnel and forwarded to MAAR2, which finally delivers them to their destination. In uplink, when the MN transmits packets using Pref1 for the source address, they are sent to MAAR2, as it is MN's new default gateway, then tunneled to MAAR1 which routes them towards the next hop to destination. Conversely, packets carrying Pref2 are routed by MAAR2 without any special packet handling both for uplink and downlink. The procedure is depicted in Figure 2. +-----+ +---+ +-----+ +--+ +--+ |MAAR1| |CMD| |MAAR2| |CN| |CN| +-----+ +---+ +-----+ +*-+ +*-+ | | | * * | | MN * +---+ * | | attach. ***** _|CMD|_ * | | det. flow1 * / +-+-+ \ *flow2 | |<-- PBU ---| * / | \ * | BCE | * / | ******* | check+ | * / | * \ | update | +---*-+-' +--+-*+ `+-----+ |<-- PBU ---| | | * | | *| | | route | | |MAAR1|______|MAAR2+-----+MAAR3| update | | | **(______)** *| | | |--- PBA -->| | +-----+ +-*--*+ +-----+ | BCE | * * | update | Pref1 * *Pref2 | |--- PBA -->| +*--*+ | | route ---move-->|*MN*| | | update +----+ (Operations sequence) (Packets flow) Figure 2: Scenario after a handover, CMD as relay For next MN's movements the process is repeated except for the number of P-MAARs involved, that rises accordingly to the number of prefixes Bernardos, et al. Expires July 30, 2012 [Page 6]
Internet-Draft A DMM solution for PMIPv6 January 2012 that the MN wishes to maintain. Indeed, once the CMD receives the first PBU from the new S-MAAR, it forwards copies of the PBU to all the A-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR prior to handover) and old P-CoAs. They reply with a PBA to the CMD, which aggregates them into a single one to notify the S-MAAR, that finally can establish the tunnels with the A-MAARs. It should be noted that this design separates the mobility management at the prefix granularity, and it can be tuned in order to erase old mobility sessions when not required, while the MN is reachable through the latest prefix acquired. Moreover, the latency associated to the mobility upadate is bound to the PBA sent by the furthest A-MAAR, that takes the longest time to reach the CMD. The drawback can be mitigated introducing a timeout at the CMD, by which, after its expiration, all the PBAs so far collected are transmitted, and the remaining are sent later upon their arrival. 3.3. The CMD as MAAR locator The latency experienced in the approach shown before can be mitigated if the A-MAARs are allowed to signal directly their information to the new S-MAAR. This procedure reflect what was described in Section 3.2 up to the moment the A-MAAR receives the PBU. At that point an A-MAAR is aware of the new MN's location (i.e., S-MAAR) and, besides sending a PBA to the CMD, it also sends a PBA to the S-MAAR including the prefix it is anchoring. The CMD is relieved from forwarding the PBA to the S-MAAR, as it receives a copy directly from the A-MAAR with the necessary information to build the tunnel and set the appropriate routes. In Figure 3 is illustrated the new messages sequence, while the data forwarding is unaltered. Bernardos, et al. Expires July 30, 2012 [Page 7]
Internet-Draft A DMM solution for PMIPv6 January 2012 +-----+ +---+ +-----+ +--+ +--+ |MAAR1| |CMD| |MAAR2| |CN| |CN| +-----+ +---+ +-----+ +*-+ +*-+ | | | * * | | MN * +---+ * | | attach. ***** _|CMD|_ * | | det. flow1 * / +-+-+ \ *flow2 | |<-- PBU ---| * / | \ * | BCE | * / | ******* | check+ | * / | * \ | update | +---*-+-' +--+-*+ `+-----+ |<-- PBU ---| | | * | | *| | | route | | |MAAR1|______|MAAR2+-----+MAAR3| update | | | **(______)** *| | | |--------- PBA -------->| +-----+ +-*--*+ +-----+ |--- PBA -->| route * * | BCE update Pref1 * *Pref2 | update | +*--*+ | | | ---move-->|*MN*| | | | +----+ (Operations sequence) (Packets flow) Figure 3: Scenario after a handover, CMD as locator 3.4. The CMD as PBU/PBA proxy A further enhancement of previous solutions can be achieved when the CMD sends the PBA to the new S-MAAR before notifying the A-MAARs of the location change. Indeed, when the CMD receives the PBU for the new registration, it is already in possess of all the information that the new S-MAAR requires to set up the tunnel and the routes. Thus the PBA is sent to the S-MAAR immediately after a PBU is received. In parallel, a PBU is sent by the CMD to the A-MAARs to notify them about the new MN's location, so they receive the information to establish the tunnel and routes on their side. When A-MAARs complete the update, they send a PBA to the CMD to indicate that the operation is concluded and the information are updated in all network nodes. This scheme is depicted in Figure 4, where, again, the data forwarding is kept untouched. Bernardos, et al. Expires July 30, 2012 [Page 8]
Internet-Draft A DMM solution for PMIPv6 January 2012 +-----+ +---+ +-----+ +--+ +--+ |MAAR1| |CMD| |MAAR2| |CN| |CN| +-----+ +---+ +-----+ +*-+ +*-+ | | | * * | | MN * +---+ * | | attach. ***** _|CMD|_ * | | det. flow1 * / +-+-+ \ *flow2 | |<-- PBU ---| * / | \ * | BCE | * / | ******* | check+ | * / | * \ | update | +---*-+-' +--+-*+ `+-----+ |<-- PBU ---x--- PBA -->| | * | | *| | | route | route |MAAR1|______|MAAR2+-----+MAAR3| update | update | **(______)** *| | | |--- PBA ->| | +-----+ +-*--*+ +-----+ | BCE | * * | update | Pref1 * *Pref2 | | | +*--*+ | | | ---move-->|*MN*| | | | +----+ (Operations sequence) (Packets flow) Figure 4: Scenario after a handover, CMD as proxy 4. IANA Considerations TBD. 5. Security Considerations TBD. 6. Acknowledgments The authors would like to thank Marco Liebsch for his comments and discussion on this document. The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL project). The work of Carlos J. Bernardos has also been partially supported by the Ministry of Science and Innovation of Spain under the QUARTET project (TIN2009-13992-C02-01). Bernardos, et al. Expires July 30, 2012 [Page 9]
Internet-Draft A DMM solution for PMIPv6 January 2012 7. References 7.1. Normative References [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. 7.2. Informative References [I-D.bernardos-mext-dmm-cmip] Bernardos, C. and F. Giust, "A IPv6 Distributed Client Mobility Management approach using existing mechanisms", draft-bernardos-mext-dmm-cmip-00 (work in progress), March 2011. [I-D.chan-distributed-mobility-ps] Chan, A., "Problem statement for distributed and dynamic mobility management", draft-chan-distributed-mobility-ps-05 (work in progress), October 2011. [Net-basedDMM] Giust, F., de la Oliva, A., Bernardos, CJ., and RP. Ferreira Da Costa, "FA Network-based Localized Mobility Solution for Distributed Mobility Management", under submission , 2011. Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Bernardos, et al. Expires July 30, 2012 [Page 10]
Internet-Draft A DMM solution for PMIPv6 January 2012 Antonio de la Oliva Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 8803 Email: aoliva@it.uc3m.es URI: http://www.it.uc3m.es/aoliva/ Fabio Giust Institute IMDEA Networks and Universidad Carlos III de Madrid Av. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain Phone: +34 91481 6979 Email: fabio.giust@imdea.org Telemaco Melia Alcatel-Lucent Bell Labs Route de Villejust Nozay, Ile de France 91620 France Email: telemaco.melia@alcatel-lucent.com Bernardos, et al. Expires July 30, 2012 [Page 11]