DMM                                                          D. Liu, Ed.
Internet-Draft                                              China Mobile
Intended status: Informational                           JC. Zuniga, Ed.
Expires: August 15, December 19, 2013                                  InterDigital Communications, LLC
                                                                P. Seite
                                                 France Telecom -
                                                                 H. Chan
                                                     Huawei Technologies
                                                           CJ. Bernardos
                                        Universidad Carlos III de Madrid
                                                       February 11,
                                                           June 17, 2013

  Distributed Mobility Management: Current practices and gap analysis



   The present document discusses how to best deploy the current IP analyses deplyment practices of existing
   mobility protocols in a distributed mobility management (DMM) scenarios and
   analyzes the gaps of such best current practices against the DMM
   requirements.  These best current practices are achieved by
   redistributing the existing MIPv6 and PMIPv6 functions in the DMM
   scenarios.  The analyses is environment.
   It also applied identifies some limitations compared to the real world deployment expected
   functionality of IP a fully distributed mobility in WiFi network and in cellular network. management system.  The
   comparison is made taking into account the identified DMM

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

   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 August 15, December 19, 2013.

Copyright Notice

   Copyright (c) 2013 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
   ( 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 . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
   2.  Conventions and  Terminology  . . . . . . . . . . . . . . . . .  4
     2.1.  Conventions used in this document  . . . . . . . . . . . .  4
     2.2.  Terminology  3
   3.  Functions of existing mobility protocols . . . . . . . . . . .  4
   4.  DMM practices  . . . . . . . . . . . .  4
   3.  Current IP mobility protocol analysis . . . . . . . . . . . .  5
     3.1.  IP mobility protocols and their mobility management
           functions  .
     4.1.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Reconfiguring existing functions in DMM scenario . . . . .  7
   4.  Current practices of
     4.2.  IP mobility protocols . . . . . . . . . .  8
     4.1.  Fundamentals of distribution flat wireless network . . . . . . . . . . . . . . .  8
     4.2.  Flattening the WiFi Network . .  6
       4.2.1.  Host-based IP DMM practices  . . . . . . . . . . . . .  9
       4.2.1.  8
       4.2.2.  Network-based Mobility Management  . . . . . . . . . IP DMM practices . 11
       4.2.2.  Client-based Mobility Management . . . . . . . . . . . 12 11
     4.3.  IP mobility protocol deployment in  3GPP network  . . . . . 13
       4.3.1.  3GPP LIPA/SIPTO  . . . . . . flattening approaches . . . . . . . . . . . . . 15
     4.4.  Fully distributed scenario with separation of control
           and data planes  . . . 13
   5.  Gap analysis . . . . . . . . . . . . . . . . . . 17
   5.  Gap analysis . . . . . . . 16
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . 19
     5.1.  Gap analysis with reconfiguration MIPv6 and PMIPv6
           functions in DMM scenario such as the flattened WiFi
           network . 18
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   8.  Informative References . . . 19
       5.1.1.  Considering existing protocols first . . . . . . . . . 19
       5.1.2.  Compatibility . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . 19
       5.1.3.  IPv6 deployment  . . . . . . . . . . . . . . . . . . . 20
       5.1.4.  Security considerations  . . . . . . . . . . . . . . . 20
       5.1.5.  Distributed deployment . . . . . . . . . . . . . . . . 20
       5.1.6.  Transparency to Upper Layers when needed . . . . . . . 21
       5.1.7.  Route optimization . . . . . . . . . . . . . . . . . . 21
     5.2.  Gap analysis summary with reconfiguration MIPv6 and
           PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.3.  Gap analysis from the 3GPP LIPA/SIPTO scenario . . . . . . 22
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26

1.  Introduction

   The distributed mobility management (DMM) WG has studied the problems
   of centralized deployment of mobility management protocols and the
   related requirements of DMM [ID-dmm-requirements]. [I-D.ietf-dmm-requirements].  In order to guide
   the deployment and before defining any new DMM protocol, the DMM WG
   is chartered to investigate first whether it is feasible to deploy
   current IP mobility protocols in a DMM scenario in a way that can meet
   fullfil the requirements of DMM.  This document discusses how to best deploy current
   deployment practices of existing mobility protocols in DMM scenarios to solve the problems of
   centralized deployment.  It then analyzes a distributed
   mobility management environment and identifies the gaps of such best limitations in
   these practices against with respect to the DMM requirements. expected functionality.

   The rest of this document is organized as follows: follows.  Section 3
   analyzes the current existing IP mobility protocols by examining their existing functions
   and how these functions can be reconfigured to achieve the best practices work in a DMM scenarios.
   environment.  Section 4 presents the current practices of WiFi network IP flat
   wireless networks and 3GPP network.  With WiFi, a
   DMM scenario is the flattened WiFi network.  After presenting the
   fundaments what one can do to achieve distribution, the existing
   mobility management functions are reconfigured in the flattened
   networks for both architectures.  Both network- and host-based host-
   based mobility protocols using
   these fundaments as guiding priciples.  The current practices in 3GPP
   are also described, and the DMM scenarios are LIPA and SIPTO. considered.  Section 5 presents the gap analyses on the best practice achieved by
   reconfiguring currently existing functions in the DMM scenario which
   analysis with respect to both those in the WiFi and the 3GPP networks. current practices.

2.  Conventions and Terminology

2.1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2.2.  Terminology

   All general mobility-related terms and their acronyms used in this
   document are to be interpreted as defined in the Mobile IPv6 base
   specification [RFC6275] and in the Proxy mobile IPv6 specification
   [RFC5213].  These terms include mobile node (MN), correspondent node
   (CN), home agent (HA), local mobility anchor (LMA), and mobile access
   gateway (MAG).

   In addition, this document uses the following terms:

   Mobility routing (MR)  is the logical function that intercepts
      packets to/from the HoA of a IP address/prefix delegated to the mobile node
      and forwards them, based on internetwork location information,
      either directly towards their destination or to some other network
      element that knows how to forward the packets to their ultimate

   Home address allocation  is the logical function that allocates the
      IP address/prefix (e.g., home network prefix address or home address network prefix) to a
      mobile node.

   Location management (LM)  is the logical function that manages and
      keeps track of the internetwork location information of a mobile
      node, which includes the mapping of the IP address/prefix
      delegated to the MN HoA to the MN routing address or another network
      element that knows where to forward packets destined for the MN.

   Home network of an application session (or an HoA IP address)  is the
      network that has allocated the IP address used as the session
      identifier (HoA) (home address) by the application being run in an MN.
      The MN may be attached to more than one home networks.

3.  Current IP

   In the document, several references to a distributed mobility protocol analysis

   management environment are made.  By this term, we refer to an
   scenario in which the IP mobility protocols mobility, access network and their routing
   solutions allow for setting up IP networks so that traffic is
   distributed in an optimal way and does not rely on centrally deployed
   anchors to manage IP mobility management functions sessions.

3.  Functions of existing mobility protocols

   The host-based Mobile IPv6 [RFC6275] and its network-based extension,
   PMIPv6 [RFC5213], are both a logically centralized mobility management approach
   approaches addressing primarily hierarchical mobile networks.
   Although they are a centralized approach, approaches, they have important
   mobility management functions resulting from years of extensive work
   to develop and to extend these functions.  It is therefore fruitful
   to take these existing functions and reconfigure examine them in a DMM scenario
   in order to understand how to best deploy the existing mobility protocols
   in a distributed mobility management environment.

   The existing mobility management functions of MIPv6, PMIPv6, and
   HMIPv6 are the following:

   1.  Anchoring:  Anchoring function (AF): allocation of home network prefix or HoA to a mobile node of an MN that
       registers with IP
       addres/prefix (e.g., a HoA or HNP) topologically anchored by the network;

       delegating node (i.e., the anchor node is able to advertise a
       connected route into the routing infrastructure for the delegated
       IP prefixes).

   2.  Mobility Routing (MR) function: packets interception and
       forwarding to/from the HoA of IP address/prefix delegated to the MN,
       based on the internetwork location information, either to the
       destination or to some other network element that knows how to
       forward the packets to their destination;

   3.  Internetwork Location Management (LM) function: managing and
       keeping track of the internetwork location of an MN, which
       includes a mapping of the IP delegated address/prefix (e.g., HoA
       or HNP) to the mobility anchoring point
       that where the MN is anchored

   4.  Location Update (LU): provisioning of MN location information to
       the LM function;

   Figure 1 shows

   In Mobile IPv6 [RFC6275] [RFC6275], the home agent typically provides the
   anchoring function (AF), Mobility Routing (MR), and Internetwork
   Location Management (LM) functions, while the mobile node provides
   the Location Update (LU) function.  Proxy Mobile IPv6 [RFC5213]
   relies on the function of the Local Mobility Anchor (LMA) to provide
   mobile nodes with their existing mobility management functions.  In Network1, support, without requiring the
   combination involvement
   of the functions MR, LM and HoA allocation in network1 is mobile nodes.  The required functionality at the home agent in MIPv6 and mobile node
   is provided in a proxy manner by the Mobile Access Gateway (MAG).
   With network-based IP mobility protocols, the local mobility anchor in PMIPv6.
   In Network3,
   typically provides the AR32+LU combination together with additional
   signaling with MN comprises anchoring function (AF), Mobility Routing
   (MR), and Internetwork Location Management (LM) functions, while the Mobile Access Gateway (MAG) in
   PMIPv6.  The
   mobile nodes MN11 and MN12 were originally attached to
   Network1 and were allocated access gateway provides the IP prefixes for their respective home
   addresses HoA11 and HoA12.

   Using MIPv6, MN11 has moved to Network3, from which it is allocated Location Update (LU) function.

4.  DMM practices

   This section documents deployment practices of existing mobility
   protocols in a
   new prefix to configure the distributed mobility management environment.  This
   description is divided into two main families of network
   architectures: i) IP address IP31.  LM1 maintains flat wireless networks (e.g., evolved WiFi
   hotspots) and, ii) 3GPP network flattening approaches.

   While describing the
   binding HoA11:IP31 so that packets from CN21 in Network2 destined current DMM practices, references to
   HoA11 the generic
   mobility management functions described in Section 3 will be intercepted by MR1, which will then tunnel them to
   IP31.  MN11 must perform mobility signaling using
   provided, as well as some initial hints on the LU function.

   Using PMIPv6, MN12 has moved to Network3 and attached identified gaps with
   respect to the access
   router AR32 which has the IP address IP32 DMM requirement documented in Network3.  LM1 maintains
   the binding HoA12:IP32.  The access router AR32 also behaves like a
   home link to MN12 so

4.1.  Assumptions

   There are many different approaches that MN12 can use its original IP address HoA12.

    Network1                      Network3                      Network2
     | LM1 |
     HoA1 alc                      IP3 alc                       IP2 alc
     | MR1 |
     .     .
     .     .
     .     .                   +----+   +----+                    +----+
     .     .                   |MN11|   |AR32|                    |CN21|
     .     .                   |+LU |   |+LU |                    |    |
     .     .                   +----+   +----+                    +----+
     .     .                    IP31,    IP32,
     .   HoA11      =====>      HoA11      |
     .              MIPv6                  |
     .                                  +----+
     .                                  |MN12|
     .                                  +----+
   HoA12            =====>               HoA12

   Figure 1.  MIPv6, PMIPv6 be considered to
   implement and their functions.

3.2.  Reconfiguring existing functions in DMM scenario deploy a distributed anchoring and mobility solution.
   Since this document cannot be too exhaustive, the focus is on current
   mobile network architectures and standardized IP mobility solutions.
   In order to best deploy limit the scope of our analysis of current protocols in DMM scenario, practices,
   we consider the
   existing mobility functions following list of MIPv6, PMIPv6, technical assumptions:

   1.  Both host- and HMIPv6 configured
   into a DMM scenario as follows.

    Network1                      Network3                      Network2
     +-----+                       +-----+                       +-----+
     | LM1 |                       | LM3 |                       | LM2 |
     +-----+                       +-----+                       +-----+
  HoA11<-->IP31                       |                             |
  HoA12<-->IP32                       |                             |
     HoA1 alc                      IP3 alc                       IP2 alc
        |                             |                             |
        |                             |                             |
     +-----+                       +-----+                       +-----+
     | MR1 |                       | MR3 |                       | MR2 |
     +-----+                       +-----+                       +-----+
     .     .                         / \
     .     .                        /   \
     .     .                       /     \
     .     .                   +----+   +----+                    +----+
     .     .                   |MN11|   |AR32|                    |CN21|
     .     .                   |+LU |   |+LU |                    |    |
     .     .                   +----+   +----+                    +----+
     .     .                    IP31,    IP32,
     .   HoA11      =====>      HoA11      |
     .              MIPv6                  |
     .                                  +----+
     .                                  |MN12|
     .                                  +----+
   HoA12            =====>               HoA12

   Figure 2.  Reconfiguring existing functions in DMM scenario.

   Achieving the best practices by reconfiguring the existing functions
   in this manner will network-based solutions should be applied to covered.

   2.  Solution should allow selecting and using the DMM scenario of most appropriate IP
       anchor among a flattened
   WiFi network in Section 4.2.

4.  Current practices set of IP mobility protocols

   This section covers distributed ones.

   3.  Mobility management should be realized by the practices for distribution preservation of the
       IP mobility
   management.  Basically, address across the scenario presents a way to distribute different points of attachment during the
       mobility functions.  Gap analysis will be made on these

4.1.  Fundamentals of distribution

   There are many possibilities to implement a distributed mobility
   management system and this document could not be exhaustive.
   However, this document is supposed to focus on current mobility
   architectures and to reuse existing mobility protocol as much as
   possible; it thus allows fixing the main technical guidelines and
   assumptions for current practices.  Then, gap analysis will analyze
   these basic solution guidelines with respect to the requirements from
   [ID.ietf.dmm.requirements] and pave the way for optimizations.
   Technical guidelines for DMM current practices are as follows:

   The technical assumptions or guidelines are:
   1.  When mobility support is required, the system will select the
       mobility anchor closest to the MN.
   2.  This document focuses on mobility management realized by
       preservation (i.e., provision of the IP address across the different points of
       attachment during the mobility. continuity).  IP flows of
       applications which do not need a constant IP address are should not
       be handled by DMM.  It is typically the role of a connection
       manager to distinguish application capabilities and trigger the
       mobility support accordingly.  Further considerations on
       application management are out of the scope of this document.
   3.  IP address preservation is ensured thanks to traffic redirection.

   4.  Mobility traffic redirection is limited within the access
       network, e.g., traffic redirection taking place between access
       routers.  In this document, traffic redirection relies on Network
       based mobility management protocols like PMIP [RFC 5213] or GTP
       [TS 23.402].  Mobility management and traffic redirection come
       into play should only be
       triggered due to IP mobility reasons, that is when the MN moves
       from the point of attachment where the IP flow has been initiated; in case of mobility, this
       point of attachment becomes the anchoring point.  It implies that
       the MN could be managed by more the one anchor when more than one was originally

4.2.  IP flow, initiated within different points of attachment, are
   5.  An access router will advertise anchored prefixes flat wireless network

   This section focuses on common IP wireless network architectures and a local
       prefix, i.e., a prefix topologically valid at the access router.
       When being initiated,
   how they can be flattened from an IP communication must prefer the local
       prefix to the anchored prefix.  Prefix management mobility and anchoring point of
   view using common and standardized protocols.  Since WiFi is realized
       with IPv6 prefix deprecation.

4.2.  Flattening the WiFi Network

   The most common Wi-Fi
   widely deployed wireless access technology nowadays, we take it as
   example in the following.  Some representative examples of WiFi
   deployed architectures are depicted on figure 3.  In
   some cases, these architectures can rely on Proxy Mobile IPv6, where
   the access aggregation gateway plays the role of LMA and the MAG is
   supported either by the Residential Gateway (RG), the WLAN Controller
   (WLC) or an Access Router (AR) [ID. gundavelli-v6ops-community-wifi-

                       +--------+ Figure 1.

                     +-------------+             _----_
    +---+            |   Access    |           _(      )_
    |AAA|. . . . . . . | Access Aggregation |----------( Internet )
    +---+            | Aggreg   Gateway   |           (_      _)
                       | Gateway|
                     +-------------+             '----'
                        |  |   |    PMIP
                        |  |   +-----|-------+   +-------------+
                        |  |                 |
                PMIP  |  - PMIP              +-----+
        +---------------+  |              | AR  |
        |                  |              +--+--+
     +-----+            +-----+            +-----+         *---------*         *----+----*
     | RG  |            | WLC |        (    LAN    )
     +-----+            +-----+         *---------*
        .               /    \             /    \
       / \          +----+  +----+     +----+  +----+
      MN MN         |WiFi|  |WiFi|     |WiFi|  |WiFi|
                    | AP |  | AP |     | AP |  | AP |
                    +----+  +----+     +----+  +----+
                       .                  .
                      / \                / \
                     MN MN              MN MN

                  Figure 3. 1: IP WiFi network architectures.

   Because of network densification and distribution of content, it may
   be necessary to distribute architectures

   In the access aggregation gateway functions
   closer to figure, three typical deployment options are shown
   [I-D.gundavelli-v6ops-community-wifi-svcs].  On the MN; see [ID.ietf-dmm-requirements] for motivation left hand side of
   the figure, mobile nodes directly connect to a Residential Gateway
   (RG) which is a network flattening.  In an extreme distribution case, device that is located in the customer
   premises and provides both wireless layer-2 access
   aggregation gateway functions, including connectivity
   (i.e., it hosts the mobility 802.11 Access Point function) with layer-3
   routing functions.  In the middle, mobile nodes connect to WiFi
   Access Points (APs) that are managed by a WLAN Controller (WLC),
   which performs radio resource management
   functions, may all be located at on the AR as shown in Figures 4 APs, system-wide
   mobility policy enforcement and 5,
   respectively.  These two figures depict centralized forwarding function for
   the network- and client-based
   distributed mobility management scenarios. user traffic.  The AR is expected WLC could also implement layer-3 routing
   functions, or attach to
   support the HoA allocation function.  Then, depending an access router (AR).  Last, on the mobility
   situation right-
   hand side of the MN, the AR can run different functions:

   1.  the AR figure, access points are directly connected to an
   access router, which can act as also be used a legacy IP router;

   2.  the AR can provide the MR function (i.e. act generic connectivity model.

   In some network architectures, such as mobility anchor);

   3. the AR can evolved Wi-Fi hotspot,
   operators might make use of IP mobility protocols to provide mobility
   support to users, for example to allow connecting the LU functions;

   4.  the AR can provide both MR IP WiFi network
   to a mobile operator core and LU functions.

   For example, [I-D.seite-dmm-dma] support roaming between WLAN and [I-D.bernardos-dmm-distributed-
   anchoring] are PMIPv6 based implementation of this scenario.

4.2.1.  Network-based Mobility Management

   Basic 3GPP
   accesses.  Two main protocols can be used: Proxy Mobile IPv6
   [RFC5213] or Mobile IPv6 [RFC6275], [RFC5555], with the anchor role
   (e.g., local mobility anchor or home agent) typically being played by
   the Access Aggregation Gateway or even by an entity placed on the
   mobile operator's core network.

   Existing IP mobility protocols can also be deployed in a "flatter"
   way, so the anchoring and access aggregation functions are
   distributed.  We next describe several practices for distribution the deployment
   of network-based existing mobility protocols in a distributed mobility management
   is depicted
   environment.  We limit our analysis in Figure 4.

   Initially, MN1 attaches to AR1, (1).  According this section to vanilla protocol
   solutions based on existing IP mobility protocols, either host- or
   network-based, such as Mobile IPv6
   operations, AR1 advertises a prefix (HoA1) to MN1 [RFC6275], [RFC5555], Proxy Mobile
   IPv6 [RFC5213], [RFC5844] and then, AR1, acts
   as a legacy IP router.  Then, MN1 initiates a communication with CN11
   using an IP address formed from NEMO [RFC3963].  Extensions to these
   base protocol solutions are also considered.  We pay special
   attention to the prefix HoA1.  So, AR1 runs usual
   IP routing? and mobility management does not come into play.

   In case (2), MN1 performs a handover from AR1 to AR3 while
   maintaining ongoing IP communication with CN11.  AR1 becomes of the
   mobility anchor use of care-of-addresses versus
   home addresses in an efficient manner for different types of
   communications.  Finally, and in order to simplify the MN1-CN11 analysis, we
   divide it into two parts: host- and network-based practices.

4.2.1.  Host-based IP communication: AR1 runs MR DMM practices

   Mobile IPv6 (MIPv6) [RFC6275] and LM
   functions for MN1.  AR3 performs LU up its extension to support mobile
   networks, the LM in AR1: AR3
   indicates to AR1 NEMO Basic Support protocol (hereafter, simply NEMO)
   [RFC3963] are well-known host-based IP mobility protocols.  They
   heavily rely on the new location function of the MN1.  AR3 advertises both
   HoA1 and Home Agent (HA), a new IP prefix (HoA3) which is supposed centralized
   anchor, to be used for new
   IP communication, e.g., if MN1 initiates IP communication provide mobile nodes (hosts and routers) with CN21.
   Prefix HoA1 is deprecated as it is expected to be used only for
   communications anchored to AR1.  AR3 shall act as a legacy IP router
   for MN1-CN21 communication, i.e., mobility management does not come.
   support.  In case (3), MN1 performs a handover from AR1 to AR2 with ongoing IP
   communication with CN11 and CN21.  AR1 is these approaches, the mobility anchor for home agent typically provides the
   MN1-CN11 IP communication.  AR3 becomes
   anchoring function (AF), Mobility Routing (MR), and Internetwork
   Location Management (LM) functions, while the mobility anchor for mobile node provides
   MN1-CN21 IP communication.  Both AR1 and AR3 run MR and LM functions
   for MN1, respectively, anchoring HoA1 Location Update (LU) function.  We next describe some practices
   on how Mobile IPv6/NEMO and HoA3.  AR2 performs
   location updates up several additional protocol extensions
   can be deployed in a distributed mobility management environment.

   One approach to distribute the LMs anchors can be to deploy several HAs
   (as shown in AR1 and AR3 for respectively
   relocate HoA1 Figure 2), and HoA3.  AR2 advertises a new prefix (HoA2), expected assign to each MN the one closest to its
   topological location [RFC4640], [RFC5026], [RFC6611].  In the example
   shown in Figure 2, MN1 is assigned HA1 (and a home address anchored
   by HA1), while MN2 is assigned HA2.  Note that Mobile IPv6 / NEMO
   specifications do not prevent the simultaneous use of multiple home
   agents by a single mobile node.  This deployment model could be used for new IP communications, and deprecates HoA1 and HoA3
   exploited by a mobile node to meet assumption #4 and use several
   anchors at the anchored same time, each of them anchoring IP sessions.

            Network1                Network1     Network3
+----+     HoA1 alc     +----+     HoA1 alc      HoA3 al        +----+
|CN11|      +-----+     |CN11|      +-----+      +-----+        |CN21|
|    |------|     |     |    |------| MR1 |------|     |------- |    |
+----+      |     |     +----+      | LM1 |------|LU31 |        +----+ flows initiated
   at different point of attachment.  However there is no mechanism
   specified to enable an efficient dynamic discovery of available
   anchors and the selection of the most suitable one.

    <- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ---->
       -------                          -------
       | AR1 CN1 |         -------          | AR1 |-(o) zzzz (o)
       -------         |      |AR3  |
            |     | HA1 |          -------           |
                       -------   (MN1 anchored at HA1) -------
                                        -------        | MN1 |
            +-----+                 +-----+      +-----+
                                        | AR2 |-(o)    -------
                       | HA2 |          -------
                       -------          | AR3 |-(o) zzzz (o)
                                        -------           |
       -------                   (MN2 anchored at HA2) -------
             +----+                               +----+
             |MN1 CN2 |                               |MN1                          -------        | MN2 |
       -------                          | AR4 |-(o)    -------

      CN1    CN2     HA1    HA2         AR1    MN1     AR3    MN2
       |      |
             +----+                               +----+
             HoA11                                HoA11,
       (1)                              (2)

                              Network1                HoA2 al
                  +----+     HoA1 alc                 +-----+
                  |CN11|      +-----+       |      |           |    |------| MR1 |-----------------|LU21 |-------+
                  +----+      | LM1 |-----------------|AR2       |      |
       |<------------>|<=================+=====>|       | AR1      | BT mode
       |      |       |      |           |      Network3   +-----+      |
                              +-----+      HoA3 al       |      |        +----+
       |      |<----------------------------------------+----->| RO mode
       |        |MN1      |
                               +----+      |MR3  |------       |      |           |
                               |CN21|      |LM3  |--------        +----+      |    |------|       |                HoA11,
                               +----+      |AR3      |                HoA31
                                           +-----+       (3)

     Figure 4.  Network-based DMM architecture for a flat network.

4.2.2.  Client-based Mobility Management

   Basic practices for distribution 2: Distributed operation of client-based mobility management
   is depicted in Figure 5.  Here, client-based Mobile IPv6 (BT and RO) / NEMO

   Since one of the goals of the deployment of mobility protocols in a
   distributed mobility management does
   not necessary implies environment is to avoid the
   suboptimal routing caused by centralized anchoring, the Route
   Optimization (RO) support provided by Mobile IP because, according IPv6 can also be used to distribution
   fundamentals (section 4.1), current practices rely on principles
   inherited from PMIP
   achieve a flatter IP data forwarding.  By default, Mobile IPv6 and
   NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data
   traffic redirection takes place only is always encapsulated between
   access routers.  However, with client based mobility, the MN is
   authorized to send information on and its ongoing mobility session; for
   example in order to facilitate localization update operations

   In case (1), MN1 attaches HA before being
   directed to AR1.  AR advertises any other destination.  The Route Optimization (RO) mode
   allows the prefix HoA1 MN to
   MN1 update its current location on the CNs, and then acts as a legacy IP router.  MN1 initiates a communication
   with CN11.

   In case (2), use
   the direct path between them.  Using the example shown in Figure 2,
   MN1 performs a handover from AR1 to AR3 is using BT mode with ongoing IP
   communication CN2 and MN2 is in RO mode with CN11.  AR1 becomes CN1.
   However, the mobility anchor RO mode has several drawbacks:

   o  The RO mode is only supported by Mobile IPv6.  There is no route
      optimization support standardized for the
   MN1-CN11 IP communication: AR1 runs MR and LM functions for MN1. NEMO protocol, although
      many different solutions have been proposed.

   o  The
   MN performs LU directly up RO mode requires additional signaling, which adds some
      protocol overhead.

   o  The signaling required to enable RO involves the LM in AR1 or via AR3; in this case
   AR3 acts as a proxy locator (pLU) (e.g. home agent, and
      it is repeated periodically because of security reasons [RFC4225].

      This basically means that the HA remains as a FA single point of
      failure, because the Mobile IPv6 RO mode does not mean HA-less

   o  The RO mode requires additional support on the correspondent node

   Notwithstanding these considerations, the RO mode does offer the
   possibility of substantially reducing traffic through the Home Agent,
   in MIPv4).  AR3
   allocates a new IP prefix (HoA3) for new IP communications.  HoA3 is
   supposed to cases when it can be used for new IP communications, e.g., if MN1 initiates
   IP communication with CN21.  AR3 shall act as a legacy IP router for
   MN1-CN21 communication.

              Network1                Network1     Network3
  +----+     HoA1 alc     +----+     HoA1 alc                     +----+
  |CN11|      +-----+     |CN  |      +-----+      +-----+        |CN21| supported on the relevant correspondent

     <- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
                                                   /|AR1|-(o) zz (o)
                                         -------- / -----         |    |------|
                                         | MAP1 |<             -------
                                         -------- \ -----      |    |------| MR1 |------|     |------- MN1 |
        -------                                    \|AR2|      -------
  +----+ CN1 |                                     -----  HoA anchored
        -------                                     -----     at HA1
                        -------                    /|AR3|  RCoA anchored
                        |     +----+ HA1 | LM1 |------|pLU31|        +----+          -------- / -----     at MAP1
                        -------          | MAP2 |<         LCoA anchored
                                         -------- \ -----     at AR1
        -------                                     -----
        | CN2 |                                     -----
        -------                                    /|AR5|
                                         -------- / -----
                                         |                 | MAP3 |<
                                         -------- \ -----

     CN1      CN2         HA1              MAP1      AR1         MN1
      |      |AR31        |           |                | ________|__________ |
      |<------------------>|<==============>|<________+__________>| HoA
      |        |           |
              +-----+                 +-----+      +-----+                |         |           |
      |        |<-------------------------->|<===================>| RCoA
      |        |
               +----+                               +----+
               |MN1           |                               |MN1                |         |           |                               |LU31|
               +----+                               +----+
               HoA11                                HoA11,

        (1)                              (2)

                    Figure 5.  Client-based DMM architecture for a flat network.

4.3. 3: Hierarchical Mobile IPv6

   Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] is another host-based IP
   mobility protocol deployment in 3GPP network extension that can be considered as a complement to provide
   a less centralized mobility deployment.  It allows reducing the
   amount of mobility signaling as well as improving the overall
   handover performance of Mobile IPv6 by introducing a new hierarchy
   level to handle local mobility.  The 3rd Generation Partnership Project (3GPP) Mobility Anchor Point (MAP)
   entity is introduced as a local mobility handling node deployed
   closer to the mobile node.

   When HMIPv6 is used, the standard
   development organization MN has two different temporal addresses: the
   Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA).
   The RCoA is anchored at one MAP, that specifies plays the 3rd generation role of local home
   agent, while the LCoA is anchored at the access router level.  The
   network and LTE (Long Term Evolution).  By November 2, 2012, there
   are 113 commercial LTE networks in 51 countries already deployed, and
   there are 360 operators in 105 countries investing in LTE.  GSA
   forecasts 166 commercial LTE networks in 70 countries node uses the RCoA as the CoA signaled to its home agent.
   Therefore, while roaming within a local domain handled by end of 2012. the same
   MAP, the mobile node does not need to update its home agent (i.e.,
   the mobile node does not change RCoA).

   The 3GPP SAE network architecture is visualized in use of HMIPv6 allows some route optimization, as a mobile node
   may decide to directly use the Figure 6:

              .....................................|    |
              .                                    |HSS |
              .        ............................|    |
              .        .                           +----+
              .        .                           +----+
              .        .   ........................|    |
              .        .   .                       |PCRF|.........
              .        .   .                .......|    |        .
              .        .   .                .      +----+        .
      +---------+    +-------+    +----------+               ^ ^ ^ ^ ^
      |3GPP     |    |Serving|    |  PDN GW  |..............(IP Network)
      |access   |....|GW     |....|          |                v v v v v
      +---------+    +-------+    +----------+
                                   . | | .  .
                                   . | | .  .
                                   . | | .  .
                                   . | | .  .
      +---------+.............S2a... | | .  .
      |Trusted  |                   /  | .  .
      |non-3GPP | ------------S2c---   | .  .
    ..|access   |/                     | .  .
    . +---------+                      | .  .
    .          /                       | .  .
   +--+       /                        | .  .
   |  |--S2c--                         | .  .
   |UE|                                | .  .
   |  |--S2c--                        /  .  .
   +--+       \        -------S2c-----   .  .
    .          \      /                  .  .
    . +---------+    +----+              .  .      +----+
    ..|         |\  /|    |...S2b.........  .......|    |
      |Untrusted| -- |ePDG|                        |AAA |
      |non-3GPP |    |    |........................|    |
      |non-3GPP |    +----+                        +----+
      |access   |                                    .
      |         |.....................................

   Figure 6. 3GPP SAE architecture.

   In SAE architecture, there are two types of non-3GPP access network:
   trusted and untrusted.  Trusted non-3GPP access means that the non-
   3GPP access network has RCoA as source address for a trust relationship
   communication with a given correspondent node, notably if the 3GPP operator.
   Untrusted means MN does
   not expect to move outside the operator considers local domain during the non-3GPP network as
   untrusted, lifetime of
   the non-3GPP network may either be or not communication.  This can be deployed by
   the same operator.  The mobility support within the 3GPP network
   mostly relies on s5/s8 interface which is based on GTP or PMIP.  For seen as a potential DMM mode of
   operation.  In the scenario which provide non-3GPP network and 3GPP network
   mobility, there are mainly three solutions that example shown in Figure 3, MN1 is using IP mobility

   In 3GPP SAE architecture, there are three interfaces that use IP
   mobility protocol:
   1.  S2a Interface: S2a its global
   HoA to communicate with CN1, while it is the interface between trusted non-3GPP
       access network using its RCoA to
   communicate with CN2.

   Additionally, a local domain might have several MAPs deployed,
   enabling hence different kind of HMIPv6 deployments (e.g., flat and
   distributed).  The HMIPv6 specification supports a flexible selection
   of the EPC.  This interface could be MAP (e.g., based on GTP
       or PMIP.  When using PMIP, the PDN gateway in distance between the EPC will
       function as LMA.  The mobile station will anchor at this LMA/
       PDN-Gateway entity.  The mobile station will maintain the session
       continuity when handover between the non-3GPP access network MN and
       3GPP network.
   2.  S2b Interface: S2b is the interface between MAP,
   taking into consideration the trusted-non-3GPP
       access network and expected mobility pattern of the PDN gateway.  This interface is based on
       PMIP.  The PDN-gateway functions as PMIP LMA.  The mobile station
       will anchor at this LMA/PDN-Gateway entity.  The ePDG MN,

   An additional extension that can be used to help deploying a mobility
   protocol in a distributed mobility management environment is the EPC
       network will function as PMIP MAG.  The mobile station will
       maintain the session continuity when handover between
   Home Agent switch specification [RFC5142], which defines a new
   mobility header for signaling a mobile node that it should acquire a
   new home agent.  Even though the non-
       3GPP access network and 3GPP network.
   3.  S2c Interface: S2c is purposes of this specification do
   not include the interface between case of changing the mobile station
       and the EPC network.  It can node's home address, as
   that might imply loss of connectivity for ongoing persistent
   connections, it could be used in both trusted and un-
       trusted 3GPP access network.  S2c interface uses DSMIPv6 protocol
       which is specified by IETF.  The PDN gateway functions as DSMIPv6
       Home to force the change of home agent in this scenario.  When using non-trusted-non-3GPP
       access network, the mobile station will first establish IPSec
       tunnel toward the ePDG, and runs DSMIPv6 inside this IPSec
       tunnel.  The mobile station will maintain the session continuity
       when handover between the non-3GPP access network and 3GPP


   Another scenario
   those situations where there are no active persistent data sessions
   that uses cannot cope with a change of home address.

4.2.2.  Network-based IP DMM practices

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP
   mobility protocol in 3GPP currently specified for IPv6 ([RFC5844] defines some IPv4
   extensions).  Architecturally, PMIPv6 is similar to MIPv6, as it
   relies on the function of the LIPA/SIPTO scenario.  LIPA stands for Local IP Access. Mobility Anchor (LMA) to provide
   mobile nodes with mobility support, without requiring the involvement
   of the mobile nodes.  The
   following figure shows required functionality at the LIPA scenario.

     +---------+ IP traffic to mobile operator's CN
     |Mobile   |....................................(Operator's CN)
     |Station  |..................
     +---------+                 . Local IP traffic
                           |enterprise |
                           |IP network |

   Figure 7.  LIPA scenario.

   The main feature of LIPA node
   is that the mobile station can access provided in a
   local proxy manner by the Mobile Access Gateway (MAG).
   With network-based IP network through H(e)NB.  H(e)NB is a small, low-power
   cellular base station, mobility protocols, the local mobility anchor
   typically designed for use in a home or
   enterprise.  The provides the anchoring function (AF), Mobility Routing
   (MR), and Internetwork Location Management (LM) functions, while the
   mobile station can access gateway provides the local network's
   service, for example, connect to a user home's TV, computers, picture
   libraries etc.  The LIPA architecture is illustrated Location Update (LU) function.  We
   next describe some practices on how network-based mobility protocols
   and several additional protocol extensions can be deployed in Figure 8.

  +---------------+-------+  +----------+  +-------------+
  |Residential a
   distributed mobility management environment.

   <- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------>
       |  |H(e)NB CN1 |                      --------      --------      --------
       -------      --------        | Backhaul MAG1 |  |Mobile      |
  |Enterprise  |..|-------|..|          |..|Operator     |..(IP Network)
  |Network MAG2 |      | MAG3 |
                    | LMA1 |        ---+----      ---+----      ---+----
       -------      --------           |             |             |
       | CN2 |                        (o)           (o)           (o)
       -------      --------          x                           x
                    | LMA2 |         x                           x
       -------      --------       (o)                          (o)
       | CN3 |                      |                            |
       -------                   ---+---                      ---+---
                      Anchored   | MN1 |          Anchored    | MN2 |
                      at LMA1 -> -------          at LMA2 ->  -------

     CN1    CN2     LMA1   LMA2        MAG1   MN1     MAG3    MN2
      |      |       |      |           |      |       |       |
      |<------------>|<================>|<---->|       |       |
      |      |       |      |           |      |       |       |
      |      |<------------>|<========================>|<----->|
      |  |L-GW      |       |      |  |Core network           |
  +---------------+-------+  +----------+  +-------------+
                      /      |
                   +-----+       | UE       |

           Figure 8.  LIPA architecture.

   There is 4: Distributed operation of Proxy Mobile IPv6

   As with Mobile IPv6, plain Proxy Mobile IPv6 operation cannot be
   easily decentralized, as in this case there also exists a single
   network anchor point.  One simple but still suboptimal approach, can
   be to deploy several local gateway function mobility anchors and use some selection
   criteria to assign LMAs to attaching mobile nodes (an example of this
   type of assignment is shown in Figure 4).  As per the H(e)NB.  The local gateway
   (L-GW) function acts as client based
   approach, a GGSN (UMTS) or P-GW (LTE).  The mobile
   station uses a special APN to establish the PDP context or the
   default bearer towards node may use several anchors at the L-GW.

   One thing that needs to same time,
   each of them anchoring IP flows initiated at different point of
   attachment.  This assignment can be noted is that static or dynamic (as described
   later in 3GPP Release 10, there this document).  The main advantage of this simple approach
   no mobility support when that the mobile stations moves between H(e)NBs.
   The bearer will IP address anchor (i.e., the LMA) could be broken when placed closer
   to the mobile moves among H(e)NBs.  For
   example, when several H(e)NBs node, and therefore resulting paths are deployed in an office, there is no
   mobility support when close-to-
   optimal.  On the other hand, as soon as the mobile station needs to do handover between node moves, the H(e)NBs.  The user session
   resulting path would be broken when a user moves start to deviate from
   one H(e)NB coverage the optimal one.

   As for host-based IP mobility, there are some extensions defined to
   mitigate the sub-optimal routing issues that might arise due to another. the
   use of a centralized anchor.  The SIPTO (Selected IP Traffic Offload) scenario is illustrated Local Routing extensions [RFC6705]
   enable optimal routing in Proxy Mobile IPv6 in three cases: i) when
   two communicating MNs are attached to the Figure 9.  There same MAG and LMA, ii) when
   two communicating MNs are attached to different MAGs but to the same
   LMA, and iii) when two communicating MNs are attached to the same MAG
   but have different LMAs.  In these three cases, data traffic between
   the two mobile nodes does not traverse the LMA(s), thus providing
   some form of path optimization since the traffic is also a local gateway function near locally routed at
   the base
   station. edge.  The traffic main disadvantage of this approach is that it only
   tackles the MN-to-MN communication scenario, and only under certain

   An interesting extension that can also be routed through the local gateway used to
   offload facilitate the traffic.

   In both LIPA and SIPTO architecture,
   deployment of network-based mobility protocols in a distributes
   mobility management environment is the LMA runtime assignment
   [RFC6463].  This extension specifies a runtime local gateway functions as
   the mobility anchor point
   assignment functionality and corresponding mobility options for the Proxy
   Mobile IPv6.  This runtime local traffic.

                             SIPTO Traffic
                             +------+        +------+
                             |L-PGW |   ---- | MME  |
                             +------+  /     +------+
                                 |    /
   +-------+     +------+    +------+/       +------+
   |  UE   |.....|eNB   |....| S-GW |........| P-GW |...> CN Traffic
   +-------+     +------+    +------+        +------+

   Figure 9.  SIPTO architecture.

4.4.  Fully distributed scenario with separation of control and data

   For either mobility anchor assignment takes
   place during the WiFi network Proxy Binding Update / Proxy Binding Acknowledgment
   message exchange between a mobile access gateway and cellular network such as 3GPP, the
   DMM scenario a local mobility
   anchor.  While this mechanism is mainly aimed for load-balancing
   purposes, it can also be a fully distributed scenario separation of
   control and data planes.  The reconfiguration used to select an optimal LMA from the
   routing point of mobility management
   functions in these scenario may consist view.  A runtime LMA assignment can be used to
   change the assigned LMA of multiple MRs and a
   distributed LM database.  Figure 10 shows such an MN, for example DMM
   architecture with the same three networks as in Figure 3.  As is in
   Figure 3, each network in Figure 10 has its own IP prefix allocation
   function.  In the data plane, case when the mobility routing function mobile
   node does not have any session active, or when running sessions can
   survive an IP address change.

4.3.  3GPP network flattening approaches

   The 3rd Generation Partnership Project (3GPP) is
   distributed to multiple locations at the MRs so standard
   development organization that routing can be
   optimized.  In specifies the control plane, 3rd generation mobile
   network and LTE (Long Term Evolution).

   Architecturally, the MRs may exchange signaling with
   each other.  In addition 3GPP Evolved Packet Core (EPC) network is
   similar to these features in Figure 3, an IP wireless network running PMIPv6 or MIPv6, as it
   relies on the LM
   function in Figure 10 is a distributed database, Packet Data Gateway (PGW) anchoring services to provide
   mobile nodes with multiple
   servers, mobility support (see Figure 5).  There are client-
   based and network-based mobility solutions in 3GPP, which for
   simplicity we will analyze together.  We next describe how 3GPP
   mobility protocols and several additional completed or on-going
   extensions can be deployed to meet some of the mapping of HoA to CoA.

    Network1     Network3     Network2
    +-----+ DMM requirements

            |                           PCRF                          |
                        |                          |                |
   +----+   +-----------+------------+    +--------+-----------+  +-+-+
   |    |   |          +-+           |    |  Core Network      |  |   |
   |    |   | +------+ |S|__         |    | +--------+  +---+  |  |   |
   |    |   | |GERAN/|_|G|  \        |    | |  HSS   |  |   |  |  |   |
   |    +-----+ UTRAN| |S|   \       |    | +---+----+  |   |  |  | E |
   |    |   | +------+ |N|  +-+-+    |    |     |       |   |  |  | x |
   |    |   |          +-+ /|MME|    |    | +---+----+  |   |  |  | t |
   |    |   | +---------+ / +---+    |    | |  3GPP  |  |   |  |  | e |
   |    +-----+ E-UTRAN |/           |    | |  AAA   |  |   |  |  | r |
   |    |   | +---------+\           |    | | SERVER |  |   |  |  | n |
   |    |   |             \ +---+    | LM1    | +--------+  | LM3   |  | LM2  |
    +-----+      +-----+      +-----+
   HoA1 alc     HoA3 alc     HoA2 alc a | \ \      /
   | \      / /    |   |  \  \   /   3GPP AN    \|SGW+----- S5---------------+ P |  \   /  /  |  |   \   \/ l |   \/   /
   |    |    \  / \   |  / \  /               +---+    |    |     \/    \|/    \/             | G |     /\    /|\    /\  |  |    /  \ /   |  \ /  \
   |    |   /   /\   +------------------------+    |   /\   \             | W |  /  /   \  |  /   \  \  | I | / /      \
   | /      \ \ UE |
    +-----+      +-----+      +-----+                                 | MR1 |------| MR3 |------| MR2             |   |  |  | P |
   |    |   +------------------------+    |             |   +-----+      +-----+      +-----+
       .           / \
       .          /   \
       .         /     \
       .      +----+ +----+    +----+
       .      |AR31| |MN11|    |CN21|
       .      |+LU   | |+LU
   |    |   |+-------------+ +------+|    |
       .      +----+ +----+    +----+
     HoA11     IP31   IP32,             |    HoA11   |

   Figure 10.  A distributed architecture for mobility management.

   To perform mobility routing, the MRs need the location information
   which is maintained at the LMs.  The MRs are therefore the clients of
   the LM servers and may also send location updates to the LM as the
   MNs perform the handover.  The location information may either be
   pulled from the LM servers by the MR, or pushed to the MR by the LM
   servers.  In addition, the MR may also cache a limited amount of
   location information.

   This figure shows three MRs (MR1, MR2, and MR3) in three networks.
   MN11 has moved from the first network supported by MR1 and LM1 to the
   third network supported by MR3 and LM3.  It may use an HoA (HoA11)
   allocated to it when it was in the first network for those
   application sessions that had already started when MN11 was attached
   there and that require session continuity after the handover to the
   third network.  When MN11 was in the first network, no location
   management  |  | n |
   |    |   || Untrusted   +-+ ePDG +-S2b---------------+   |  |  | e |
   |    +---+| non-3GPP AN | +------+|    |             |   |  |  | t |
   |    |   |+-------------+         |    |             |   |  |  | w |
   |    |   +------------------------+    |             |   |  |  | o |
   |    |                                 |             |   |  |  | r |
   |    |   +------------------------+    |             |   |  |  | k |
   |    +---+  Trusted non-3GPP AN   +-S2a--------------+   |  |  | s |
   |    |   +------------------------+    |             |   |  |  |   |
   |    |                                 |             +-+-+  |  |   |
   |    +--------------------------S2c--------------------|    |  |   |
   |    |                                 |                    |  |   |
   +----+                                 +--------------------+  +---+

             Figure 5: EPS (non-roaming) architecture overview

   GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is needed so that LM1 will not keep an entry of HoA11.
   After MN11 has performed its handover to the third network, the
   database server LM1 maintains a mapping of HoA11 to MR3.  That is,
   LM1 points network-based
   mobility protocol specified for 3GPP networks (S2a, S2b, S5 and S8
   interfaces).  Similar to the third network and PMIPv6, it is can handle mobility without
   requiring the third network that will
   keep track involvement of how to reach MN11.  Such a hierarchical mapping can
   prevent frequent update signaling to LM1 as MN11 performs intra-
   network handover within the third network. mobile nodes.  In other words, this case, the
   concept of hierarchical
   mobile IP [RFC5380] node functionality is applied here but only
   in location management and not in routing in the data plane.

5.  Gap analysis

5.1.  Gap analysis with reconfiguration MIPv6 and PMIPv6 functions provided in
      DMM scenario such as a proxy manner by the flattened WiFi network

5.1.1.  Considering existing protocols first

   The fourth DMM requirement is on existing
   Serving Data Gateway (SGW), Evolved Packet Data Gateway (ePDG), or
   Trusted Wireless Access Gateway (TWAG).

   3GPP specifications also include client-based mobility protocols [ID-dmm-

   REQ4: A DMM solution SHOULD first consider reusing and extending
   IETF-standardized protocols before specifying new protocols.

   The best current practice is using support, based
   on adopting the existing mobility management
   functions use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for
   the current protocols.

5.1.2.  Compatibility

   The first part of S2c interface.  In this case, the fifth DMM requirement UE implements the mobile node
   functionality, while the home agent role is on compatibility:

   REQ5: (first part) The DMM solution MUST be able to co-exist with
   existing network deployments played by the PGW.

   A Local IP Access (LIPA) and end hosts.  For example, depending
   on Selected IP Traffic Offload (SIPTO)
   enabled network [3GPP.23.829] allows offloading some IP services at
   the environment in which DMM is deployed, DMM solutions may need
   to be compatible with other deployed mobility protocols local access network, above the Radio Access Network (RAN) or may at
   the macro, without the need to interoperate with a network or mobile hosts/routers that do not
   support DMM protocols.

   Different deployments using traverse back to the same abstract functions are basically
   reconfiguration of these same functions if their functions use common
   message formats between these functions.  A design principle PGW (see
   Figure 6.

     +---------+ IP traffic to mobile operator's CN
     |  User   |....................................(Operator's CN)
     | Equipm. |..................
     +---------+                 . Local IP traffic
                           |enterprise |
                           |IP network |

                          Figure 6: LIPA scenario

   SIPTO enables an operator to offload certain types of traffic at a
   network node close to the
   IPv6 message format accommodates the use UE's point of common message formats as
   it allows attachment to define extension headers, e.g., use the access
   network, by selecting a set of mobility header GWs (SGW and options.  It is shown in Section 4 PGW) that MIPv6, PMIPv6, HMIPv6,
   Distributing mobility anchors can be constructed from is
   geographically/topologically close to the abstract
   functions by adding more features and additional messages one on top UE's point of attachment.

                             SIPTO Traffic
                             +------+        +------+
                             |L-PGW |   ---- | MME  |
                             +------+  /     +------+
                                 |    /
   +-------+     +------+    +------+/       +------+
   |  UE   |.....|eNB   |....| S-GW |........| P-GW |...> CN Traffic
   +-------+     +------+    +------+        +------+

                       Figure 7: SIPTO architecture

   LIPA, on the other hand, enables an IP capable UE connected via a
   Home eNB (HeNB) to access other IP capable entities in the above order.  The later protocol will therefore
   support same
   residential/enterprise IP network without the one from which user plane traversing
   the later mobile operator's network core.  In order to achieve this, a
   Local GW (L-GW) collocated with the HeNB is constructed by adding more

5.1.3.  IPv6 deployment

   The third DMM requirement on IPv6 deployment used.  LIPA is
   established by the following.

   REQ3: DMM solutions SHOULD target IPv6 as the primary deployment
   environment and SHOULD NOT be tailored specifically UE requesting a new PDN connection to support IPv4,
   in particular in situations where private IPv4 addresses and/or NATs
   are used.

   This is not an issue when using access
   point name for which LIPA is permitted, and the network selecting the
   Local GW associated with the mobility management functions of
   MIPv6 HeNB and PMIPv6 which are originally designed for IPv6.

5.1.4.  Security considerations

   The second part of enabling a direct user plane
   path between the fourth requirement as well as Local GW and the sixth DMM
   requirement [ID-dmm-requirements] are as follows:

   REQ5 (second part): Furthermore, HeNB.

   +---------------+-------+  +----------+  +-------------+    =====
   |Residential |  |H(e)NB |  | Backhaul |  |Mobile       |   ( IP  )
   |Enterprise  |..|-------|..|          |..|Operator     |..(Network)
   |Network     |  |L-GW   |  |          |  |Core network |   =======
   +---------------+-------+  +----------+  +-------------+
                    | UE  |

                        Figure 8: LIPA architecture

   Both SIPTO and LIPA have a very limited mobility support, specially
   in 3GPP specifications up to Rel-10.  In Rel-11, there is currently a DMM solution SHOULD
   work across
   different networks, possibly operated as separate administrative
   domains, when allowed by the trust relationship between them.

   REQ6: DMM protocol solutions MUST consider security aspects,
   including confidentiality item on LIPA Mobility and integrity.  Examples of aspects SIPTO at the Local Network (LIMONET)
   [3GPP.23.859] that is studying how to be
   considered are authentication provide SIPTO and authorization LIPA
   mechanisms that allow with some additional, but still limited, mobility support.
   In a legitimate mobile host/router to use the glimpse, LIPA mobility support provided
   by the DMM solution; signaling message protection in terms of
   authentication, encryption, etc.; data integrity and confidentiality;
   opt-in or opt-out data confidentiality to signaling messages
   depending on network environments or user requirements.

   It is preferred limited to handovers between
   HeNBs that these security requirements are considered as an
   integral part of managed by the DMM design.

5.1.5.  Distributed deployment

   The first DMM requirement has 2 parts.  The first part same L-GW (i.e., mobility within the
   local domain), while seamless SIPTO mobility is on
   distributed deployment whereas still limited to the
   case where the second part SGW/PGW is on avoiding longer

   REQ1: (part 1)IP mobility, network access and routing solutions
   provided by at or above Radio Access Network (RAN)

5.  Gap analysis

   The goal of this section is to identify the limitations in the
   current practices with respect to providing the expected DMM MUST enable distributed deployment for mobility

   From the analysis performed in Section 4, we can first identify a
   basic set of IP sessions (part 2) so functions that traffic does not need a DMM solution needs to
   traverse centrally deployed mobility provide:

   o  Multiple (distributed) anchoring: ability to anchor different
      sessions of a single mobile node at different anchors.  In order
      to make this feature "DMM-friendly", some anchors and thus can might need to be routed
   in an optimal manner.

      placed closer to the first part, multiple MRs mobile node.

   o  Dynamic anchor assignment/re-location: ability to i) optimally
      assign initial anchor, and ii) dynamically change the initially
      assigned anchor and/or assign a new one (this may also require to
      transfer mobility context between anchors).  This can exist in MIPv6 be achieved
      either by simply having
   an HA changing anchor for each home network.  Yet it is complicated all ongoing sessions, or by
      assigning new anchors just for new sessions.

   o  Multiple IP address management: ability of the MN to
   move its HA from one network mobile node to another.  Therefore this requirement
   is not fully met in
      simultaneously use multiple IP addresses and select the best current practice.

   With the second part, one can examine dynamic mobility and route
   optimization to be discussed later.

5.1.6.  Transparency to Upper Layers when needed

   To see how
      (from an anchoring point of view) to avoid traversing centralized deployed mobility anchors,
   let us look at the second requirement use on non-optimal routes [ID-dmm-

   REQ2: DMM solutions MUST provide transparent mobility a per-session/
      application/service basis.  Depending on the mobile node support,
      this functionality might require more or less support above from the IP layer when needed.  Such transparency
      network side.  This is needed, for example,
   when, upon change of point typically the role of attachment a connection manager.

   In order to summarize the Internet, previously listed functions, Figure 9 shows
   application flow cannot cope with example of a change conceptual DMM solution deployment.

        (                                                  )
              /                  |                  \
             /    * Internet     |      x Internet   \         Internet
            /    * / access      |     x / access     \       / access
           /    * / (IP a)       |    x / (IP b)       \     /
        --+------+-----      ----+-----+----      ------+---+----
        | distributed | * * *| distributed |      | distributed |
        |   anchor 1  |      |   anchor i  |      |   anchor n  |
        ---+-----------      ---+-----------      ---+-----------
           |                    |                    |
          (o)                  (o)                  (o)
                  session X   * x  session Y
                   anchored  * x   anchored
                     at 1   * x      at i
                    (IP a) (o)      (IP b)
                         | MN1 |

                          Figure 9: DMM functions

   Based on the analysis performed in Section 4, the following list of
   gaps can be identified:

   o  Both the main client- and network-based IP address.
   Otherwise, support for maintaining a stable home IP address or prefix
   during handovers may be declined.

   In order mobility protocols,
      namely (DS)MIPv6 and PMIPv6 allows to avoid traversing long routes after deploy multiple anchors
      (i.e., home agents and localized mobility anchors), therefore
      providing the MN has moved to multiple anchoring function.  However, existing
      solutions do only provide an optimal initial anchor assignment, a
   new network,
      gap being the new network could simply be used as lack of dynamic anchor change/new anchor assignment.
      Neither the home network
   for new sessions.

   Yet HA switch nor the capability to use different IP addresses for different IP
   sessions are not in LMA runtime assignment allow
      changing the existing mobility management functions. anchor during an ongoing session.  This
   requirement is then not met in actually
      comprises several gaps: ability to perform anchor assignment at
      any time (not only at the best practice.

5.1.7.  Route optimization

   The second part initial MN's attachment), ability of first requirement is on route optimization.

   REQ1: (part 1)IP mobility, network access the
      current anchor to initiate/trigger the relocation, and routing solutions
   provided by DMM MUST enable distributed deployment for mobility
   management ability of
      transferring registration context between anchors.

   o  The dynamic anchor relocation needs to ensure that IP address
      continuity is guaranteed for sessions (part 2) so that traffic does not need to
   traverse centrally deployed mobility anchors and thus can be routed
   in an optimal manner.

   Although there are existing route optimization extensions, they
   generally compromise with location privacy so that this requirement
   is not met.

5.2.  Gap analysis summary with reconfiguration MIPv6 and PMIPv6

   The gap analyses it at the
      relocated anchor.  This for different protocols are summarized in this

   Table 1.  Summary example implies having the knowledge
      of Gap Analysis

           Existing                              Distri- trans-
           proto-            IPv6      Security  buted   parency Route
           cols     Compati- deploy-   consi-    deploy- when    Optimi-
           first    bility   ment      derations ment    needed  zation

MIPv6         Y        Y        Y          Y        N       N       N

PMIPv6        Y        Y        Y          Y        N       N       N
                   (supports            (MN-AR)

HMIPv6        Y        Y        Y          Y        N       N       N
                   (supports            (MN-AR)

Optimize      Y        Y        Y          Y        N       N    locat-
route              (supports                                     ion pr
                     above)                                      ivacy

Reconfigure   Y        Y        Y          Y        Y       N       N
mobility           (supports
functions            above)
in DMM

5.3.  Gap analysis from which sessions are active at the 3GPP LIPA/SIPTO scenario

   From mobile node, which is
      something typically known only by the real deployment perspective, it MN (namely, by its
      connection manager).  Therefore, (part of) this knowledge might
      need to be noted that in
   3GPP LIPA/SIPTO scenario, there is no mobility support when handover
   between local gateways. transferred to/shared with the network.

   o  Dynamic discovery and selection of anchors.  There might be more
      than one available anchor for a mobile node to use.  Currently,
      there is no current IP mobility protocol efficient mechanism that allows to dynamically
      discover the presence of nodes that can play the role of anchor,
      discover their capabilities and allow the selection of the most
      suitable one.

   o  NOTE: This section is in progress.  More gaps are still to be used
      identified and more text added to solve this problem currently.  DMM may provide a solution
   for this scenario. these bullets (perhaps even
      assigning one subsection to each one).  More discussion/feedback
      from the group is still needed.

6.  Security Considerations



7.  IANA Considerations



8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

              Bernardos, CJ. and JC. Zuniga, "PMIPv6-based distributed
              anchoring", draft-bernardos-dmm-distributed-anchoring-01
              (work in progress), September 2012.

              Bernardos, C., Oliva, A., Giust, F., Melia, T., and R.
              Costa, "A PMIPv6-based solution for Distributed Mobility
              Management", draft-bernardos-dmm-pmip-01 (work in
              progress), March 2012.

              Kim, J., Koh, S., Jung, H.,

              3GPP, "Local IP Access and Y. Han, "Use of Proxy
              Mobile IPv6 for Distributed Mobility Management",
              draft-jikim-dmm-pmip-00 (work in progress), March 2012.

              Liebsch, M., "Per-Host Locators for Distributed Mobility
              Management", draft-liebsch-mext-dmm-nat-phl-02 (work in
              progress), Selected IP Traffic Offload
              (LIPA-SIPTO)", 3GPP TR 23.829 10.0.1, October 2012.

              Liu, D., Deng, H., and W. Luo, "DMM Dynamic Anchor
              Discussion", draft-liu-dmm-dynamic-anchor-discussion-00
              (work in progress), March 2012.

              Liu, D., Song, J., and W. Luo, "PMIP Based DMM
              Approaches", draft-liu-dmm-pmip-based-approach-02 (work in
              progress), March 2012.

              Luo, W. and J. Liu, "PMIP Based DMM Approaches",
              draft-luo-dmm-pmip-based-dmm-approach-01 (work in
              progress), March 2012.

              Ma, Z. and X. Zhang, "An AR-level solution support for
              Distributed Mobility Management", draft-ma-dmm-armip-00
              (work in progress), February 2012.

              Patil, B., Williams, C., and J. Korhonen, "Approaches to
              Distributed 2011.

              3GPP, "Local IP access (LIPA) mobility management using Mobile IPv6 and its
              extensions", draft-patil-dmm-issues-and-approaches2dmm-00
              (work in progress), Selected IP
              Traffic Offload (SIPTO) at the local network", 3GPP
              TR 23.859 12.0.1, April 2013.

              3GPP, "General Packet Radio Service (GPRS); GPRS
              Tunnelling Protocol (GTP) across the Gn and Gp interface",
              3GPP TS 29.060 3.19.0, March 2012.

              Sarikaya, B., "Distributed Mobile IPv6",
              draft-sarikaya-dmm-dmipv6-00 (work in progress),
              February 2012.

   [I-D.seite-dmm-dma] 2004.

              Gundavelli, S., Grayson, M., Seite, P. and P. Bertin, "Distributed Mobility Anchoring",
              draft-seite-dmm-dma-05 (work in progress), July 2012.

              Xue, K., Li, L., Hong, P., and P. McCann, "Routing
              optimization in DMM",
              draft-xue-dmm-routing-optimization-00 Y. Lee,
              "Service Provider Wi-Fi Services Over Residential
              draft-gundavelli-v6ops-community-wifi-svcs-06 (work in
              June 2012.

              Yokota, H., April 2013.

              Chan, A., Liu, D., Seite, P., Demaria, E., Yokota, H., and Z. Cao, "Use case
              scenarios J. Korhonen,
              "Requirements for Distributed Mobility Management",
              draft-ietf-dmm-requirements-05 (work in progress),
              October 2010.

              June 2013.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Valadon, G., Petrescu, A., and J. Murai, "Migrating Home
              Agents Towards Internet-scale P.
              Thubert, "Network Mobility Deployments",
               Proceedings of the ACM 2nd CoNEXT Conference on Future
              Networking Technologies,  Lisboa, Portugal, December 2006.

              Bertin, P., Bonjour, S., and J-M. Bonnin, "Distributed or
              Centralized Mobility?",  Proceedings of Global
              Communications Conference (GlobeCom), December 2009.

              Bertin, (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC4225]  Nikander, P., Bonjour, S., and J-M. Bonnin, "A Distributed
              Dynamic Mobility Management Scheme Designed for Flat IP
              Architectures",  Proceedings of 3rd International
              Conference on New Technologies, Mobility and Security
              (NTMS), 2008.

              Chan, H., "Distributed Mobility Management with Mobile
              IP",  Proceedings of IEEE ICC 2012 Workshop on
              Telecommunications: from Research to Standards, June 2012.

              Chan, H., "Proxy Mobile IP with Distributed Mobility
              Anchors",  Proceedings of GlobeCom Workshop on Seamless
              Wireless Mobility, December 2010.

              Chan, H., Yokota, H., Xie, Arkko, J., Seite, P., and D. Liu,
              "Distributed and Dynamic Mobility Management in Mobile
              Internet: Current Approaches and Issues", February 2011.

              Lee, JH., Bonnin, JM., and X. Lagrange, "Host-based
              Distributed Mobility Management Support Protocol for IPv6
              Mobile Networks",  Proceedings of IEEE WiMob, Barcelona,
              Spain, October 2012.

              Wakikawa, R., Valadon, Aura, T., Montenegro, G., and J. Murai, "Migrating Home
              Agents Towards Internet-scale Mobility Deployments",
               Proceedings of the ACM 2nd CoNEXT Conference on Future
              Networking Technologies, E.
              Nordmark, "Mobile IP Version 6 Route Optimization Security
              Design Background", RFC 4225, December 2006.

              Giust, F., de la Oliva, A., Bernardos, CJ., and RPF. Da
              Costa, "A network-based localized mobility solution for
              Distributed Mobility Management",  Proceedings of 14th
              International Symposium on Wireless Personal Multimedia
              Communications (WPMC), October 2011.

              Zhang, L., Wakikawa, R., and Z. Zhu, "Support Mobility in
              the Global Internet",  Proceedings of ACM Workshop on
              MICNET, MobiCom 2009, Beijing, China, September 2009.

   [RFC4068]  Koodli, R., "Fast Handovers 2005.

   [RFC4640]  Patel, A. and G. Giaretta, "Problem Statement for
              bootstrapping Mobile IPv6", IPv6 (MIPv6)", RFC 4068,
              July 2005.

   [RFC4988]  Koodli, R. 4640,
              September 2006.

   [RFC5026]  Giaretta, G., Kempf, J., and C. Perkins, V. Devarapalli, "Mobile IPv4 Fast Handovers", IPv6
              Bootstrapping in Split Scenario", RFC 4988, 5026, October 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.

   [RFC5949]  Yokota,

   [RFC5555]  Soliman, H., Chowdhury, K., Koodli, R., Patil, B., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

   [RFC5844]  Wakikawa, R. and F.
              Xia, "Fast Handovers S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5949,
              September 5844, May 2010.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC6463]  Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
              "Runtime Local Mobility Anchor (LMA) Assignment Support
              for Proxy Mobile IPv6", RFC 6463, February 2012.

   [RFC6611]  Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6)
              Bootstrapping for the Integrated Scenario", RFC 6611,
              May 2012.

   [RFC6705]  Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
              Dutta, "Localized Routing for Proxy Mobile IPv6",
              RFC 6705, September 2012.

Authors' Addresses

   Dapeng Liu (editor)
   China Mobile
   Unit2, 28 Xuanwumenxi Ave, Xuanwu District, District
   Beijing 100053,  100053


   Juan Carlos Zuniga (editor)
   InterDigital Communications, LLC
   1000 Sherbrooke Street West, 10th floor
   Montreal, Quebec  H3A 3G4


   Pierrick Seite
   France Telecom -
   4, rue du Clos Courtel, BP 91226, 91226
   Cesson-Sevigne 35512,  35512

   H Anthony Chan
   Huawei Technologies
   5340 Legacy Dr. Building 3, 3
   Plano, TX 75024,  75024



   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911

   Phone: +34 91624 6236