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]