DMM                                                          D. Liu, Ed.
Internet-Draft                                              China Mobile
Intended status: Informational                           JC. Zuniga, Ed.
Expires: April 23, August 18, 2014                                    InterDigital
                                                                P. Seite
                                                                  Orange
                                                                 H. Chan
                                                     Huawei Technologies
                                                           CJ. Bernardos
                                                                    UC3M
                                                        October 20, 2013
                                                       February 14, 2014

  Distributed Mobility Management: Current practices and gap analysis
             draft-ietf-dmm-best-practices-gap-analysis-02
             draft-ietf-dmm-best-practices-gap-analysis-03

Abstract

   The present document analyses deplyment analyzes deployment practices of existing IP
   mobility protocols in a distributed mobility management environment.
   It also then identifies some existing limitations when compared to the expected
   functionality of
   requirements defined for a fully distributed mobility management system.  The
   comparison is made taking into account the identified DMM
   requirements. solution.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 23, August 18, 2014.

Copyright Notice

   Copyright (c) 2013 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Functions of existing mobility protocols  . . . . . . . . . . .  4   3
   4.  DMM practices . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .  6   5
     4.2.  IP flat wireless network  . . . . . . . . . . . . . . . . .  6   5
       4.2.1.  Host-based IP DMM practices . . . . . . . . . . . . .  8   7
       4.2.2.  Network-based IP DMM practices  . . . . . . . . . . . . 12  11
     4.3.  3GPP network flattening approaches  . . . . . . . . . . . . 14  13
   5.  Gap analysis  . . . . . . . . . . . . . . . . . . . . . . . . . 17  16
     5.1.  Distributed processing - REQ1 . . . . . . . . . . . . . . 17  16
     5.2.  Transparency to Upper Layers  Bypassable network-layer mobility support - REQ2  . . . . . . . . . . . 19  18
     5.3.  IPv6 deployment - REQ3  . . . . . . . . . . . . . . . . . .  19
     5.4.  Existing mobility protocols - REQ4  . . . . . . . . . . . . 20  19
     5.5.  Co-existence - REQ5 . . . . . . . . . . . . . . . . . . . 20  19
     5.6.  Security considerations - REQ6  . . . . . . . . . . . . . .  20
     5.7.  Multicast - REQ7  . . . . . . . . . . . . . . . . . . . . . 21  20
     5.8.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  21
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . 22  21
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22  21
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 22  21
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . .  22
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 23  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   The distributed mobility management (DMM) WG has studied the problems
   of centralized deployment of mobility management protocols and
   specified the
   related 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  This
   document investigates whether it is feasible to deploy current IP
   mobility protocols in a DMM scenario in a way that can
   fullfil fulfill the requirements of DMM.  This document
   requirements.  It discusses current deployment practices of existing
   mobility protocols in a distributed mobility management environment
   and identifies the limitations (gaps) in these practices with respect
   to the expected functionality. DMM functionality, as defined in [I-D.ietf-dmm-requirements].

   The rest of this document is organized as follows.  Section 3
   analyzes existing IP mobility protocols by examining their functions
   and how these functions can be reconfigured configured and used to work in a DMM
   environment.  Section 4 presents the current practices of IP flat
   wireless networks and 3GPP architectures.  Both network- and host-
   based mobility protocols are considered.  Section 5 presents the gap
   analysis with respect to the current practices.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   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 IP address/prefix delegated to the mobile node
      and forwards them, based on internetwork location information,
      either directly towards their destination or to also introduces some other network
      element that knows how to forward the packets to their ultimate
      destination.

   Home address allocation  is the logical function that allocates the definitions of IP address/prefix (e.g., home address or home network prefix)
   mobility functions in Section 3.

   In this document there are also references to a
      mobile node.

   Location "distributed mobility
   management (LM)  is the logical function that manages and
      keeps track of the internetwork location information of environment".  By this term, we refer to a mobile
      node, scenario in
   which includes the mapping of the IP address/prefix
      delegated to the MN to the MN routing address or another mobility, access 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 (home address) by the application being run in an MN.
      The MN may be attached to more than one home networks.

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

3.  Functions of existing mobility protocols

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

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

   1.  Anchoring function (AF): allocation to a mobile node of an IP
       addres/prefix
       address/prefix (e.g., a HoA Home Address or HNP) Home Network Prefix)
       topologically anchored by the delegating node (i.e., the anchor
       node is able to advertise a connected route into the routing
       infrastructure for the delegated IP prefixes).  It is a control
       plane function.

   2.  Mobility Routing (MR)  Internetwork Location Management (LM) function: managing and
       keeping track of the internetwork location of an MN.  The
       location information may be a mapping of the IP delegated address
       /prefix (e.g., HoA or HNP) to the IP routing address of the MN or
       of a node that can forward packets destined to the MN.  It is a
       control plane function.

       In a client-server model of the system, location query and update
       messages may be exchanged between the client (LMc) and the server
       (LMs).

       Optionally, one (or more) proxy may exist between the LMs and the
       LMc, i.e., LMs-proxy-LMc.  Then, to the LMs, the proxy behaves
       like the LMc; to the LMc, the proxy behaves like the LMs.

   3.  Routing management (RM) function: packet interception and
       forwarding to/from the 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 where the MN is anchored
       to;

   4.  Location Update (LU): provisioning of MN location information to destination.

       RM may optionally be split into the LM function; control plane (RM-CP) and
       data plane (RM-DP).

   In Mobile IPv6 [RFC6275], the home agent (HA) typically provides the
   anchoring function (AF), Mobility Routing (MR), and Internetwork
   Location Management (LM) functions, while (AF); the mobile node provides location management server (LMs) is at
   the Location Update (LU) function.  Proxy Mobile IPv6 [RFC5213]
   relies on HA while the location management client (LMc) is at the MN; the
   routing management (RM) function is both ends of tunneling at the HA
   and the MN.

   In Proxy Mobile IPv6 [RFC5213], the Local Mobility Anchor (LMA) to provide
   mobile nodes with mobility support, without requiring
   provides the involvement
   of anchoring function (AF); the mobile nodes.  The required functionality location management server
   (LMs) is at the LMA while the location management client (LMc) is at
   the mobile node access gateway (MAG); the routing management (RM) function
   is provided in both ends of tunneling at the HA and the MAG.

   In Hirarchical mobile IPv6 (HMIPv6) [RFC5380], a location management
   proxy manner by the Mobile Access Gateway (MAG).
   With network-based IP mobility protocols, is at the local mobility anchor
   typically provides point (MAP) to proxy between the anchoring function (AF), Mobility Routing
   (MR), LMs
   at the LMA and Internetwork Location Management (LM) functions, while the
   mobile access gateway provides LMc at the Location Update (LU) function. MN.  The MAP also has RM funtion to
   enable tunneling between LMA and itself as well as tunneling between
   MN and itself.

4.  DMM practices

   This section documents deployment practices of existing mobility
   protocols in a distributed mobility management environment.  This
   description is divided into two main families of network
   architectures: i) IP flat wireless networks (e.g., evolved WiFi Wi-Fi
   hotspots) and, ii) 3GPP network flattening approaches.

   While describing the current DMM practices, references to the generic
   mobility management functions described in Section 3 will be are provided, as
   well as some initial hints on the identified gaps with respect to the
   DMM requirement requirements documented in [I-D.ietf-dmm-requirements].

4.1.  Assumptions

   There are many different approaches that can be considered to
   implement and deploy a distributed anchoring and mobility solution.
   Since this document cannot be too exhaustive, the
   The focus of the gap analysis is on current mobile network
   architectures and standardized IP mobility solutions. solutions, considering any
   kind of deployment options which do not violate the original protocol
   specifications.  In order to limit the scope of our analysis of
   current DMM practices, we consider the following list of technical
   assumptions:

   1.  Both host- and network-based solutions should SHOULD be covered. considered.

   2.  Solution should  Solutions SHOULD allow selecting and using the most appropriate
       IP anchor among a set of distributed available ones.

   3.  Mobility management should SHOULD be realized by the preservation of the
       IP address across the different points of attachment during the
       mobility (i.e.,
       provision of IP address continuity).  IP flows of
       applications

   Applications which do not need a constant can cope with changes in the MN's IP address should do
   not
       be handled by depend on IP mobility management protocols such as DMM.
   Typically, the a connection manager together with the operating system
   will configure the source address selection mechanism of the IP
   stack.  This might involve identifying application capabilities and
   triggering the mobility support accordingly.  Further considerations
   on application management and source address selection are out of the
   scope of this document.

   4.  Mobility management and traffic redirection should only be
       triggered due to IP mobility reasons, that is when the MN moves
       from the point of attachment where the IP flow was originally
       initiated.

4.2.  IP flat wireless network

   This section focuses on common IP wireless network architectures and
   how they can be flattened from an IP mobility and anchoring point of
   view using common and standardized protocols.  We take WiFi Wi-Fi as an
   exemplary wireless technology, as since it is widely known and deployed
   nowadays.  Some representative examples of WiFi deployed Wi-Fi deployment
   architectures are depicted on in Figure 1.

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

                 Figure 1: IP WiFi Wi-Fi network architectures

   In the figure, three typical deployment options are shown
   [I-D.gundavelli-v6ops-community-wifi-svcs].  On the left hand side of
   the figure, mobile nodes directly connect to a Residential Gateway
   (RG) which is a network device that is located in at the customer premises and provides
   both wireless layer-2 access connectivity (i.e., it hosts the 802.11
   Access Point function) with and layer-3 routing functions.  In the middle, middle
   of the figure, mobile nodes connect to WiFi Wi-Fi Access Points (APs) that
   are managed by a WLAN Controller (WLC), which performs radio resource
   management on the APs, system-wide mobility policy enforcement and
   centralized forwarding function for the user traffic.  The WLC could
   also implement layer-3 routing functions, or attach to an access
   router (AR).  Last, on the right-
   hand right-hand side of the figure, access
   points are directly connected to an access router, which router.  This can also be
   used as a generic connectivity model.

   In some network architectures, such as the evolved Wi-Fi hotspot,
   operators might make use of IP mobility protocols to provide mobility
   support to users, for example to allow connecting the IP WiFi Wi-Fi
   network to a mobile operator core and support roaming between WLAN
   and 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) role typically being played by
   the Access Aggregation Gateway or even by an entity placed on in the
   mobile operator's core network.

   Although we have adopted in this section has adopted the example of WiFi Wi-Fi networks,
   there are other IP flat wireless network architectures specified,
   such as WiMAX [IEEE.802-16.2009], which integrates both host and
   network-based IP mobility functionality.

   Existing IP mobility protocols can also be deployed in a "flatter"
   way, more
   flattened manner, so that the anchoring and access aggregation
   functions are distributed.  We next describe several practices for
   the deployment of existing mobility protocols in a distributed
   mobility management environment.  We limit our  The analysis in this section is
   limited to protocol solutions based on existing IP mobility
   protocols, either host- or network-based, such as Mobile IPv6
   [RFC6275], [RFC5555], Proxy Mobile IPv6 [RFC5213], [RFC5844] and NEMO
   [RFC3963].  Extensions to these base protocol solutions are also
   considered.  We pay special attention to how to efficiently select
   the management of the use of care-of-addresses source address (care-of-addresses versus home addresses in an efficient manner addresses) for
   different types of communications.  Finally, and in order to simplify the analysis, we
   divide it  The analysis is divided into two
   parts: host- and network-based practices.

4.2.1.  Host-based IP DMM practices

   Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile
   networks, the NEMO Basic Support protocol (hereafter, simply referred
   to as NEMO) [RFC3963] are well-known host-based IP mobility
   protocols.  They heavily rely on the function of the Home Agent (HA),
   a centralized anchor, to provide mobile nodes (hosts and routers)
   with mobility support.  In these approaches, the home agent typically
   provides the anchoring function (AF), Mobility Routing (MR), management (RM), and
   Internetwork Location Management (LM) functions, while the server (LMs) functions.  The mobile
   node provides possesses the Location Update (LU) function. management client (LMc) function and the
   RM function to enable tunneling between HA and itself.  We next
   describe some practices on how Mobile IPv6/NEMO MIPv6/NEMO and several additional
   protocol extensions can be deployed in a distributed mobility
   management environment.

   One approach to distribute the anchors can be to deploy several HAs
   (as shown in Figure 2), and assign to each MN the one topologically closest anchor
   to its
   topological location each MN [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 MIPv6/NEMO specifications do
   not prevent the simultaneous use of multiple home agents by a single
   mobile node.  This deployment model could be exploited by a mobile
   node to meet assumption #4 of Section 4.1 and use several anchors at
   the same time, each of them anchoring IP flows initiated at a
   different point of attachment.  However there is no mechanism
   specified by the IETF to enable an efficient dynamic discovery of
   available anchors and the selection of the most suitable one.  Note
   that some of these mechanisms have been defined outside the IETF (e.g.,
   3GPP).

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

     CN1    CN2     HA1    HA2         AR1    MN1     AR3    MN2
      |      |       |      |           |      |       |      |
      |<------------>|<=================+=====>|       |      | BT mode
      |      |       |      |           |      |       |      |
      |      |<----------------------------------------+----->| RO mode
      |      |       |      |           |      |       |      |

     Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO

   Since one of the goals of the deployment of mobility protocols in a
   distributed mobility management environment is to avoid the
   suboptimal routing caused by centralized anchoring, the Route
   Optimization (RO) support provided by Mobile IPv6 can also be used to
   achieve a flatter IP data forwarding.  By default, Mobile IPv6 and
   NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data
   traffic is always encapsulated between the MN and its HA before being
   directed to any other destination.  The Route Optimization (RO) mode
   allows the MN to update its current location on the CNs, and then use
   the direct path between them.  Using the example shown in Figure 2,
   MN1 is using BT mode with CN2 CN1 and MN2 is in RO mode with CN1. CN2.
   However, the RO mode has several drawbacks:

   o  The RO mode is only supported by Mobile IPv6.  There is no route
      optimization support standardized for the NEMO protocol because of
      the security problems posed by extending return routability tests
      for prefixes, although many different solutions have been
      proposed. proposed
      [RFC4889].

   o  The RO mode requires additional signaling, which adds some
      protocol overhead.

   o  The signaling required to enable RO involves the home agent, agent and
      it is
      repeated periodically because of for security reasons [RFC4225].  This
      basically means that the HA remains as a single point of failure,
      because the Mobile IPv6 RO mode does not mean HA-less operation.

   o  The RO mode requires additional support on from the correspondent
      node (CN).

   Notwithstanding these considerations, the RO mode does offer the
   possibility of substantially reducing traffic through the Home Agent,
   in cases when it can be supported on by the relevant correspondent
   nodes.  Note that a mobile node can also use its CoA directly
   [RFC5014] when communicating with CNs on the same link or anywhere in
   the Internet, although no session continuity support would be
   provided by the IP stack in this case.

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

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

                    Figure 3: Hierarchical Mobile IPv6

   Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] (as shown in Figure 3),
   is another host-based IP mobility extension that which 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
   Mobility Anchor Point (MAP) entity is introduced as a local mobility
   handling node deployed closer to the mobile node.  It provides LM
   proxy function between the LM server (LMs) at the HA and the LM
   client (LMc) at the MN.  It also possess RM function to tunnel with
   the HA and also to tunnel with the MN.

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

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

                    Figure 3: Hierarchical Mobile IPv6

   When HMIPv6 is used, the 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 plays the role of local home
   agent, while the LCoA is anchored at the access router level.  The
   mobile node uses the RCoA as the CoA signaled to its home agent.
   Therefore, while roaming within a local domain handled by the same
   MAP, the mobile node does not need to update its home agent (i.e.,
   the mobile node does not change its RCoA).

   The use of HMIPv6 allows achieving some form of route optimization, as
   since a mobile node may decide to directly use the RCoA as source
   address for a communication with a given correspondent node, notably
   if the MN does not expect to move outside the local domain during the
   lifetime of the communication.  This can be seen as a potential DMM
   mode of operation.  In the example shown in Figure 3, MN1 is using
   its global HoA to communicate with CN1, while it is using its RCoA to
   communicate with CN2.

   Additionally, a local domain might have several MAPs deployed,
   enabling hence therefore a different kind of HMIPv6 deployments (e.g., flat
   and distributed).  The HMIPv6 specification supports a flexible
   selection of the MAP (e.g., based on the distance between the MN and
   the MAP, taking into consideration the expected mobility pattern of
   the MN, etc.).

   An additional extension that can be used to help deploying a mobility
   protocol in a distributed mobility management environment is the the 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 purposes of this specification do not include
   the case of changing the mobile node's home address, as that might
   imply loss of connectivity for ongoing persistent connections, it
   could be used to force the change of home agent in those situations
   where there are no active persistent data sessions that cannot cope
   with a change of home address.

   There are other host-based approaches standardized within the IETF that
   can be used to provide mobility support.  For example MOBIKE
   [RFC4555] allows a mobile node encrypting traffic through IKEv2
   [RFC5996] to change its point of attachment while maintaining a
   Virtual Private Network (VPN) session.  The MOBIKE protocol allows
   updating the VPN Security Associations (SAs) in cases where the base
   connection initially used is lost and needs to be re-established.
   The use of the MOBIKE protocol avoids having to perform an IKEv2 re-
   negotiation.  Similar considerations to those made for Mobile IPv6
   can be applied to MOBIKE; though MOBIKE is best suited for situations
   where the address of at least one endpoint is relatively stable and
   can be discovered using existing mechanisms such as DNS.

4.2.2.  Network-based IP DMM practices

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP
   mobility protocol specified for IPv6 ([RFC5844] defines some IPv4
   extensions).  Architecturally, PMIPv6 is similar to MIPv6, as it
   relies on the function of the Local Mobility Anchor (LMA) to provide
   mobile nodes with mobility support, without requiring the involvement
   of the mobile nodes.  The required functionality at the mobile node
   is provided in a proxy manner by the Mobile Access Gateway (MAG).  With network-based IP mobility protocols, the local
   mobility anchor (LMA) typically provides the anchoring function (AF), Mobility
   Routing
   (MR), and management (RM) function, Internetwork Location Management (LM) functions, while the
   server (LMs) function and RM function.  The mobile access gateway
   (MAG) provides the Location Update (LU) function.  We
   next describe some practices on how network-based Management client (LMc) function and
   Routing management (RM) function to tunnel with LMA.  PMIPv6 is
   architecturally similar to MIPv6, as the mobility signaling and
   routing between LMA and MAG in PMIPv6 is similar to those between HA
   and MN in MIPv6.  The required mobility functionality at the MN is
   provided by the MAG so that the involvement in mobility support by
   the MN is not required.

   We next describe some practices on how network-based mobility
   protocols and several additional protocol extensions can be deployed
   in a distributed mobility management environment.

   One simple but still suboptimal approach to decentralize Proxy Mobile
   IPv6 operation can be to deploy several local 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 client based approach, a mobile node may use several anchors at
   the same time, each of them anchoring IP flows initiated at a
   different point of attachment.  This assignment can be static or
   dynamic (as described later in this document).  The main advantage of
   this simple approach is that the IP address anchor (i.e., the LMA)
   could be placed closer to the mobile node.  Therefore the resulting
   paths are close-to-optimal.  On the other hand, as soon as the mobile
   node moves, the resulting path will start deviating from the optimal
   one.

   <- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------>
       -------
       | CN1 |                      --------      --------      --------
       -------      --------        | MAG1 |      | 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
      |      |       |      |           |      |       |       |
      |<------------>|<================>|<---->|       |       |
      |      |       |      |           |      |       |       |
      |      |<------------>|<========================>|<----->|
      |      |       |      |           |      |       |       |

           Figure 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

   Similar to deploy several local the host-based IP mobility anchors and use case, network-based IP mobility
   has 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 client based
   approach, a mobile node may use several anchors at the same time,
   each of them anchoring IP flows initiated at different point of
   attachment.  This assignment can be static or dynamic (as described
   later in this document).  The main advantage of this simple approach
   is that the IP address anchor (i.e., the LMA) could be placed closer
   to the mobile node, and therefore resulting paths are close-to-
   optimal.  On the other hand, as soon as the mobile node moves, the
   resulting path would start to deviate from the optimal one.

   As for host-based IP mobility, there are some extensions defined extensions defined to mitigate the sub-optimal suboptimal routing issues
   that might may arise due to the use of a centralized anchor.  The Local
   Routing extensions [RFC6705] enable optimal routing in Proxy Mobile
   IPv6 in three cases: i) when two communicating MNs are attached to
   the 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 locally routed at the edge.  The main
   disadvantage of this approach is that it only tackles the MN-to-MN
   communication scenario, and only under certain circumstances.

   An interesting extension that can also be used to facilitate the
   deployment of network-based mobility protocols in a distributes distributed
   mobility management environment is the LMA runtime assignment
   [RFC6463].  This extension specifies a runtime local mobility anchor
   assignment functionality and corresponding mobility options for Proxy
   Mobile IPv6.  This runtime local mobility anchor assignment takes
   place during the Proxy Binding Update / Proxy Binding Acknowledgment
   message exchange between a mobile access gateway and a local mobility
   anchor.  While this mechanism is mainly aimed for load-balancing
   purposes, it can also be used to select an optimal LMA from the
   routing point of view.  A runtime LMA assignment can be used to
   change the assigned LMA of an MN, for example example, in case cases when the
   mobile node does not have any session active, active session, or when the running
   sessions can survive an IP address change.  Note that several
   possible dynamic local mobility anchor discovery solutions can be
   used, as described in [RFC6097].

4.3.  3GPP network flattening approaches

   The 3rd Generation Partnership Project (3GPP) is the standard standards
   development organization that specifies the 3rd generation mobile
   network and the Evolved Packet System (EPS), which mainly comprises
   the Evolved Packet Core (EPC) and a new radio access network,
   sometimes referred to as LTE (Long Term Evolution).

   Architecturally, the 3GPP Evolved Packet Core (EPC) network is
   similar to an IP wireless network running PMIPv6 or MIPv6, as it
   relies on the Packet Data Gateway (PGW) anchoring services to provide
   mobile nodes with mobility support (see Figure 5).  There are client-
   based and network-based mobility solutions in 3GPP, which for
   simplicity we will analyze be analyzed together.  We next describe how 3GPP
   mobility protocols and several additional completed or on-going ongoing
   extensions can be deployed to meet some of the DMM requirements
   [I-D.ietf-dmm-requirements].

            +---------------------------------------------------------+
            |                           PCRF                          |
            +-----------+--------------------------+----------------+-+
                        |                          |                |
   +----+   +-----------+------------+    +--------+-----------+  +-+-+
   |    |   |          +-+           |    |  Core Network      |  |   |
   |    |   | +------+ |S|__         |    | +--------+  +---+  |  |   |
   |    |   | |GERAN/|_|G|  \        |    | |  HSS   |  |   |  |  |   |
   |    +-----+ UTRAN| |S|   \       |    | +---+----+  |   |  |  | E |
   |    |   | +------+ |N|  +-+-+    |    |     |       |   |  |  | x |
   |    |   |          +-+ /|MME|    |    | +---+----+  |   |  |  | t |
   |    |   | +---------+ / +---+    |    | |  3GPP  |  |   |  |  | e |
   |    +-----+ E-UTRAN |/           |    | |  AAA   |  |   |  |  | r |
   |    |   | +---------+\           |    | | SERVER |  |   |  |  | n |
   |    |   |             \ +---+    |    | +--------+  |   |  |  | a |
   |    |   |   3GPP AN    \|SGW+----- S5---------------+ P |  |  | l |
   |    |   |               +---+    |    |             | G |  |  |   |
   |    |   +------------------------+    |             | W |  |  | I |
   | UE |                                 |             |   |  |  | P |
   |    |   +------------------------+    |             |   +-----+   |
   |    |   |+-------------+ +------+|    |             |   |  |  | 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

   The GPRS Tunnelling Protocol (GTP) [3GPP.29.060] [3GPP.29.281]
   [3GPP.29.274] [SDO-3GPP.29.060]
   [SDO-3GPP.29.281] [SDO-3GPP.29.274] is a network-based mobility
   protocol specified for 3GPP networks (S2a, S2b, S5 and S8
   interfaces).  Similar to PMIPv6, it can handle mobility without
   requiring the involvement of the mobile nodes.  In this case, the
   mobile node functionality is provided in a proxy manner by the
   Serving Data Gateway (SGW), Evolved Packet Data Gateway (ePDG), or
   Trusted Wireless Access Gateway (TWAG).

   3GPP specifications also include client-based mobility support, based
   on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for
   the S2c interface.  In this case, the UE User Equipment (UE) implements
   the mobile node functionality, while the home agent role is played by
   the PGW.

   A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO)
   enabled network [3GPP.23.401] [SDO-3GPP.23.401] allows offloading some IP services
   at the local access network, above the Radio Access Network (RAN) or
   at the macro, without the need to traverse back to the PGW (see
   Figure 6. 6).

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

                          Figure 6: LIPA scenario

   SIPTO enables an operator to offload certain types of traffic at a
   network node close to the UE's point of attachment to the access
   network, by selecting a set of GWs (SGW and PGW) that is are
   geographically/topologically close to the 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 same
   residential/enterprise IP network without the user plane traversing the mobile
   operator's network core. core in the user plane.  In order to achieve this,
   a Local GW (L-GW) collocated with the HeNB is used.  LIPA is
   established by the UE requesting a new PDN connection to an access
   point name for which LIPA is permitted, and the network selecting the
   Local GW associated with the HeNB and enabling a direct user plane
   path between the Local GW and the HeNB.

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

                        Figure 8: LIPA architecture

   The 3GPP architecture specifications also provide mechanisms to allow
   discovery and selection of gateways [3GPP.29.303]. [SDO-3GPP.29.303].  These
   mechanisms enable taking decisions taking into consideration topological
   location and gateway collocation aspects, using heavily the DNS as a
   "location database".

   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
   work item on LIPA Mobility and SIPTO at the Local Network (LIMONET)
   [3GPP.23.859] that is studying how to provide SIPTO and LIPA
   mechanisms with some additional, but still limited, mobility support. Rel-12.  In a glimpse, LIPA mobility
   support is limited to handovers between HeNBs that are managed by the
   same L-GW (i.e., mobility within the local domain), while seamless
   SIPTO mobility is still limited to the case where the SGW/PGW is at
   or above Radio Access Network (RAN) level.

5.  Gap analysis

   The goal of this section is to identify the limitations in the
   current practices, described in Section 4, with respect to the
   expected DMM
   requirements listed in [I-D.ietf-dmm-requirements].

5.1.  Distributed processing - REQ1

   According to requirement #1 stated in [I-D.ietf-dmm-requirements], IP
   mobility, network access and routing solutions provided by DMM MUST
   enable distributed processing for mobility management so that traffic
   does not need to traverse centrally deployed mobility anchors and
   thereby
   can avoid non-optimal routes. traversing single mobility anchor far from the optimal
   route.

   From the analysis performed in Section 4, a DMM deployment can meet
   the requirement "REQ#1 Distributed processing" usually relying on the
   following functions:

   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 might need to be
      placed closer to the 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 be achieved
      either by changing anchor for all ongoing sessions, or by
      assigning new anchors just for new sessions.

   Both the main client- and network-based IP mobility protocols, namely
   (DS)MIPv6 and PMIPv6 allows to deploy allow deploying multiple anchors (i.e., home
   agents and localized mobility anchors), therefore providing the
   multiple anchoring function.  However, existing solutions do only
   provide an optimal initial anchor assignment, a gap being thus the lack of
   dynamic anchor change/new anchor assignment. assignment is a gap.  Neither the HA
   switch nor the LMA runtime assignment allow changing the anchor
   during an ongoing session.  This actually comprises several gaps:
   ability to perform anchor assignment at any time (not only at the
   initial MN's attachment), ability of the current anchor to initiate/trigger initiate/
   trigger the relocation, and ability of transferring to transfer registration context
   between anchors.

   Dynamic anchor assignment may lead the MN to manage different
   mobility sessions served by different mobility anchors.  This is not
   an issue with client based mobility management where the mobility
   client natively knows each anchor associated to each mobility
   sessions.  However, it may raise issues with network based mobility
   management.  In this case, there is one gap, as the mobile client, located MN should be capable of
   handling IP addresses in a DMM-friendly way, meaning that the MN can
   perform smart source address selection (i.e., deprecating IP
   addresses from previous mobility anchors, so they are not used for
   new sessions).  Besides, managing different mobility sessions served
   by different mobility anchors may raise issues with network based
   mobility management.  In this case, the mobile client, located in the
   network (e.g., MAG), usually retrieves the MN's anchor from the MN's
   policy profile (e.g., Section 6.2 of [RFC5213]).  Currently, the MN's
   policy profile implicitly assumes a single serving anchor and, thus,
   does not maintain the association between home network prefix and
   anchor.

   The consequence of the distribution of the mobility anchors is that
   there might be more than one available anchor for a mobile node to
   use, so leading which leads to an anchor discovery and selection issue.
   Currently, there is no efficient mechanism specified by the IETF that
   allows to allow
   dynamically discover discovering the presence of nodes that can play the role of anchor, discover
   anchor role, discovering their capabilities and allow the
   selection of selecting the most
   suitable one.  There is also no mechanism to allow selecting a node
   that is currently anchoring a given home address/prefix (capability
   sometimes required to meet REQ#2).  There are though some mechanisms
   that could help discovering anchors, such as the Dynamic Home Agent
   Address Discovery (DHAAD), the use of the Home Agent (H) flag in
   Router Advertisements (which indicates that the router sending the
   Router Advertisement is also functioning as a Mobile IPv6 home agent
   on the link) or the MAP option in Router Advertisements defined by
   HMIPv6.  Note that there are 3GPP mechanisms providing this that
   functionality defined in [3GPP.29.303].

5.2.  Transparency [SDO-3GPP.29.303].

   Also note that REQ1 is such that the data plane traffic can avoid
   suboptimal route.  Distributed processing of the traffic is then
   needed only in the data plane.  The needed capability in distributed
   processing therefore should not contradict with centralized control
   plane.  Other control plane solutions such as charging, lawful
   interception, etc.  should not be limited.  Yet combining the control
   plane and data plane routing management (RM) function may limit the
   choice to distributing boht data plane and control plane together.
   In order to enable distributing only the data plane without
   distributing the control plane, a gap is to Upper Layers split the routing
   management function into the control plane (RM-CP) and data plane
   (RM-DP).

5.2.  Bypassable network-layer mobility support - REQ2

   The need for "transparency to upper layer", "bypassable network-layer mobility support" introduced
   in
   [I-D.ietf-dmm-requirements], requires [I-D.ietf-dmm-requirements] will enable dynamic mobility management,
   which basically leverages the two following functions:

   o  Dynamically assign/relocate anchor: a mobility anchor
   management.  Note that this requirement is assigned
      only not on dynamic mobilitly
   itself but only enables it.  It therefore leaves flexibility on the
   determination of whether network-layer mobility support is needed and
   the role to use of not use network-layer mobility support.  The
   requirement only enables one to use or not use network-layer mobility
   support.  It only enables the which basically leverages the two
   following functions:

   o  Dynamically assign/relocate anchor: a mobility anchor is assigned
      only to sessions which require IP continuity uses the network-layer mobility support.
      The MN may thus manage more than one session; some of them may be
      associated with anchored IP address(es), while the others may be
      associated with local IP address(es).

   o  Multiple IP address management: this function is ensued from related to the
      preceding and is about the ability of the mobile node to
      simultaneously use multiple IP addresses and select the best one
      (from an anchoring point of view) to use on a per-session/
      application/service basis.

   The dynamic anchor assignment/relocation needs to ensure that IP
   address continuity is guaranteed for sessions that need it and while
   needed (in uses such mobility
   support (e.g., in some scenarios, the provision of mobility locally
   within a limited area might be enough from the mobile node or the
   application point of view) at the relocated anchor.  Implicitly, when
   no applications are using the network-layer mobility support, DMM may
   releave the needed resources.  This for example implies may imply having the knowledge of
   which sessions are active at the mobile node,
   which node are active and are using the
   mobility support.  This is something typically known only by the MN e.g.,
   (e.g., by its connection manager).  Therefore, (part of) this
   knowledge might need to be transferred to/shared with the network.

   Multiple IP address management requires provides the MN with the choice to
   pick-up the correct address (with (provided with mobility support or not)
   depending on the application requirements.  When using client based
   mobility management, the mobile node is natively aware about the
   anchoring capabilities of its assigned IP addresses.  This is not the
   case with network based IP mobility management and current mechanisms
   does not allow the MN to be aware of the IP addresses properties (i.e.
   (i.e., the MN does not know whether the allocated IP addresses are
   anchored).  However, there are ongoing IETF works that are proposing
   that the network could indicate the different IP addresses properties
   during assignment procedures procedures, such as
   [I-D.bhandari-dhc-class-based-prefix],
   [I-D.korhonen-6man-prefix-properties].
   [I-D.korhonen-6man-prefix-properties] and [I-D.anipko-mif-mpvd-arch].
   However, although there exist these individual efforts that could be
   be considered as attempts to fix the gap, there is no solution close
   to be adopted and standardized in IETF.

5.3.  IPv6 deployment - REQ3

   This requirement states that DMM solutions SHOULD primariliy primarily target
   IPv6 as the primary deployment environment.. environment.  IPv4 support is not
   considered mandatory and solutions SHOULD NOT be tailored
   specifically to support IPv4, in particular in situations where
   private IPv4 addresses and/or NATs are used.

   All analyzed DMM practices support IPv6.  Some of them, such as
   MIPv6/NEMO MIPv6
   /NEMO (including the support of dynamic HA selection), MOBIKE, SIPTO
   have also IPv4 support.  Additionally, there are also some solutions
   that have some limited IPv4 support (e.g., PMIPv6).  In conclusion,
   this requirement is met by existing DMM practices.

5.4.  Existing mobility protocols - REQ4

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

   As stated in [I-D.ietf-dmm-requirements], a DMM solution could reuse
   existing IETF and standardized protocols before specifying new
   protocols.  Besides, Section 4 of this document discusses various
   ways to flatten and distribute current mobility solutions.  Actually,
   nothing prevent the distribution of mobility functions with vanilla
   IP mobility protocols.  However, as discussed in Section 5.1 and
   Section 5.2, limitations exist.  The 3GPP data plane anchoring
   function, i.e., the PGW, can be also be distributed, but with
   limitations; e.g., no anchoring relocation, no context transfer
   between anchors, centralized control plane . plane.  The 3GPP architecture is
   also going into the direction of flattening with SIPTO and LIPA
   where IP anchoring function, however these solutions are supposed to
   be deployed do and, thus, LIPA,
   though they do not provide mobility support.  In
   conclusion this requirement can be met, DMM can reuse existing
   mobility solutions, however some limitations exist.

5.5.  Co-existence - REQ5

   According to [I-D.ietf-dmm-requirements], DMM solution should MUST be able
   to co-exist with existing network deployments and deployments, end hosts. hosts and routers.

   All of current mobility protocols can co-exist with existing network
   deployments and end hosts.  There is no gap between existing mobility
   protocols and this requirement.

5.6.  Security considerations - REQ6

   As stated in [I-D.ietf-dmm-requirements], a DMM solution MUST NOT NOT
   introduce new security risks risks, or amplify existing security risks
   against which the risks,
   that cannot be mitigated by existing security mechanisms/protocols cannot offer
   sufficient protection. mechanisms or
   protocols.  Current mobility protocols all have all security
   mechanisms. mechanisms
   in place.  For example, Mobile IPv6 defines security features to
   protect binding updates both to home agents and correspondent nodes.
   It also defines mechanisms to protect the data packets transmission
   for Mobile IPv6 users.  Proxy Mobile IPv6 and other variation of
   mobile IP also have similar security considerations.

5.7.  Multicast - REQ7

   It is stated in [I-D.ietf-dmm-requirements] that DMM solutions SHOULD
   consider
   enable multicast traffic delivery so that solutions to be developed to avoid network
   inefficiency
   issues, such as duplicate in multicast subscriptions towards the
   downstream tunnel entities, can be avoided. traffic delivery.

   Current IP mobility solutions address mainly the mobility problem for
   unicast traffic.  Solutions relying on the use of an anchor point for
   tunneling multicast traffic down to the access router, or to the MN,
   mobile node, introduce the so-called "tunnel convergence problem".
   This means that multiple instances of the same multicast traffic can
   converge to the same node, defeating hence the advantage of using
   multicast protocols.

   The MULTIMOB WG in IETF has studied the this issue, for the specific case
   of PMIPv6, and has produced a baseline solution [RFC6224] as well as
   a routing optimization solution [RFC7028] to address the problem.
   The baseline solution suggests deploying an MLD proxy function at the
   MAG, and either a multicast router or another MLD proxy function at
   the LMA.  The routing optimization solution describes an architecture
   where a dedicated multicast tree mobility anchor (MTMA) or a direct
   routing option can be used to avoid the tunnel convergence problem.

   Besides the solutions proposed in MULTIMOB for PMIPv6, there are no
   solutions for other mobility protocols to address the multicast
   tunnel convergence problem.

5.8.  Summary

   We next list the main gaps identified from the analysis performed
   above.
   above:

   o  Existing solutions do only provide an optimal initial anchor
      assignment, a gap being the lack of dynamic anchor change/new
      anchor assignment.  Neither the HA switch nor the LMA runtime
      assignment allow changing the anchor during an ongoing session.

   o  The mobile node needs to simultaneously use multiple IP addresses,
      which requires additional support which might not
      While MOBIKE could be available on
      the mobile used to switch from a gateway to another in
      the middle of a session from MN side, there is no protocol support
      for the network side.

   o  The mobile node needs to simultaneously use multiple IP addresses,
      which requires additional support which might not be available on
      the mobile node's stack, especially for the case of network-based
      solutions.

   o  Currently, there is no efficient mechanism specified by the IETF
      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.  There are though some
      mechanisms that could help discovering anchors, such as the
      Dynamic Home Agent Address Discovery (DHAAD), the use of the Home
      Agent (H) flag in Router Advertisements (which indicates that the
      router sending the Router Advertisement is also functioning as a
      Mobile IPv6 home agent on the link) or the MAP option in Router
      Advertisements defined by HMIPv6.

   o  While existing network-based DMM practices may allow to deploy
      multiple LMAs and dynamically select the best one, this requires
      to still keep some centralization in the control plane, to access
      on the policy store (as defined in RFC5213).

   The following table summarizes the previous analysis, indicating the
   gaps existing DMM solutions have when compared to the requirements
   listed in [I-D.ietf-dmm-requirements].

      +------------+------+------+------+------+------+------+------+
      |            | REQ1 | REQ2 | REQ3 | REQ4 | REQ5 | REQ6 | REQ7 |
      +------------+------+------+------+------+------+------+------+
      | MIPv6/NEMO | X    | X    |      |      |      |      |  X   |
      | MIPv6 RO   | X    |      |      |      |      |      |  X   |
      | HMIPv6     | X    |      |      |      |      |      |  X   |
      | HA sel     | X    | X    |      |      |      |      |  X   |
      | MOBIKE     | X    | X    |      |      |      |      |  X   |
      | PMIPv6     | X    | X    |      |      |      |      |  *   |
      | LMA sel    | X    | X    |      |      |      |      |  X   |
      | LIPA       | X    | X    |      |      |      |      |  X   |
      | SIPTO      | X    | X    |      |      |      |      |  X   |
      | LIMONET    | X    | X    |      |      |      |      |  X   |
      +------------+------+------+------+------+------+------+------+

   * MULTIMOB optimizations for PMIPv6 can be used to handle multicast
   traffic.

6.  Security Considerations

   This document does not define any protocol, there is no security
   considerations.

7.  IANA Considerations

   None.

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

   [3GPP.23.401]
              3GPP, "General Packet Radio Service (GPRS) enhancements
              for Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013.

   [3GPP.23.859]
              3GPP, "Local IP access (LIPA) mobility and Selected IP
              Traffic Offload (SIPTO) at the local network", 3GPP
              TR 23.859 12.0.1, April 2013.

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

   [3GPP.29.274]
              3GPP, "3GPP Evolved Packet System (EPS); Evolved General
              Packet Radio Service (GPRS) Tunnelling Protocol for
              Control plane, to access
      on the policy store (as defined in RFC5213).  Currently, there is
      a lack of solutions/extensions that support a clear control and
      data plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0,
              June separation for IETF IP mobility protocols.

6.  Security Considerations

   This document does not define any protocol, so it does not introduce
   any new security concern.

7.  IANA Considerations

   None.

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

   [I-D.anipko-mif-mpvd-arch]
              Anipko, D., "Multiple Provisioning Domain Architecture",
              draft-anipko-mif-mpvd-arch-05 (work in progress), November
              2013.

   [3GPP.29.281]
              3GPP, "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
              September 2011.

   [3GPP.29.303]
              3GPP, "Domain Name System Procedures; Stage 3", 3GPP
              TS 29.303 10.4.0, September 2012.

   [I-D.bhandari-dhc-class-based-prefix]
              Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
              Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
              based prefix", draft-bhandari-dhc-class-based-prefix-05
              (work in progress), July 2013.

   [I-D.gundavelli-v6ops-community-wifi-svcs]
              Gundavelli, S., Grayson, M., Seite, P., and Y. Lee,
              "Service Provider Wi-Fi Services Over Residential
              Architectures",
              draft-gundavelli-v6ops-community-wifi-svcs-06 draft-gundavelli-v6ops-community-wifi-
              svcs-06 (work in progress), April 2013.

   [I-D.ietf-dmm-requirements]
              Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
              "Requirements for Distributed Mobility Management",
              draft-ietf-dmm-requirements-09 draft-
              ietf-dmm-requirements-12 (work in progress),
              September December
              2013.

   [I-D.korhonen-6man-prefix-properties]
              Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
              Liu, "IPv6 Prefix Properties",
              draft-korhonen-6man-prefix-properties-02 draft-korhonen-6man-prefix-
              properties-02 (work in progress), July 2013.

   [IEEE.802-16.2009]
              , "IEEE Standard for Local and metropolitan area networks
              Part 16: Air Interface for Broadband Wireless Access
              Systems", IEEE Standard 802.16, 2009, <http://
              standards.ieee.org/getieee802/download/802.16-2009.pdf>.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC4225]  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
              Nordmark, "Mobile IP Version 6 Route Optimization Security
              Design Background", RFC 4225, December 2005.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.

   [RFC4640]  Patel, A. and G. Giaretta, "Problem Statement for
              bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September
              2006.

   [RFC4889]  Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
              Mobility Route Optimization Solution Space Analysis", RFC
              4889, July 2007.

   [RFC5014]  Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
              Socket API for Source Address Selection", RFC 5014,
              September 2007.

   [RFC5026]  Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
              Bootstrapping in Split Scenario", RFC 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.

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
              5996, September 2010.

   [RFC6097]  Korhonen, J. and V. Devarapalli, "Local Mobility Anchor
              (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February
              2011.

   [RFC6224]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in Proxy Mobile
              IPv6 (PMIPv6) Domains", RFC 6224, April 2011.

   [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.

   [RFC7028]  Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and
              Y. Kim, "Multicast Mobility Routing Optimizations for
              Proxy Mobile IPv6", RFC 7028, September 2013.

   [SDO-3GPP.23.401]
              3GPP, "General Packet Radio Service (GPRS) enhancements
              for Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013.

   [SDO-3GPP.23.859]
              3GPP, "Local IP access (LIPA) mobility and Selected IP
              Traffic Offload (SIPTO) at the local network", 3GPP TR
              23.859 12.0.1, April 2013.

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

   [SDO-3GPP.29.274]
              3GPP, "3GPP Evolved Packet System (EPS); Evolved General
              Packet Radio Service (GPRS) Tunnelling Protocol for
              Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0,
              June 2013.

   [SDO-3GPP.29.281]
              3GPP, "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
              September 2011.

   [SDO-3GPP.29.303]
              3GPP, "Domain Name System Procedures; Stage 3", 3GPP TS
              29.303 10.4.0, September 2012.

Authors' Addresses

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

   Email: liudapeng@chinamobile.com

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

   Email: JuanCarlos.Zuniga@InterDigital.com
   URI:   http://www.InterDigital.com/

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

   Email: pierrick.seite@orange.com

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

   Email: h.a.chan@ieee.org

   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/