Internet DRAFT - draft-tu-dmm-with-mip

draft-tu-dmm-with-mip






Network Working Group                                              Y. Tu
Internet-Draft                                                    W. Luo
Intended status: Standards Track                                     ZTE
Expires: February 1, 2014                                      S. Tricci
                                                                 ZTE USA
                                                           July 31, 2013


        Distributed Mobility Management Approach with Mobile IP
                        draft-tu-dmm-with-mip-00

Abstract

   Based on the analysis of current centralized mobility management
   approaches, three main functions of current centralized mobility
   anchor are introduced, which are Mobility Routing (MR), Home Address
   Allocation (HAA), and Location Management (LM).

   Based on the proposal of decoupling those functions, this document
   provides a concept of architecture for Distributed Mobility
   Management (DMM) with some key approaches for DMM.

Requirements Language

   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 RFC 2119 [RFC2119].

Status of this Memo

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

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

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

   This Internet-Draft will expire on February 1, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the



Tu, et al.              Expires February 1, 2014                [Page 1]

Internet-Draft                   dmm-mip                       July 2013


   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.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  3
     2.1.  Conventions used in this document  . . . . . . . . . . . .  3
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Functional Decomposition . . . . . . . . . . . . . . . . .  4
     3.2.  An Example of Networking Model . . . . . . . . . . . . . .  4
     3.3.  Concept Architecture of Distributed Mobility Management  .  5
   4.  Overview of the Distributed Mobility Management Approaches . .  6
     4.1.  Initial Attachment . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Dynamic Mobility Management  . . . . . . . . . . . . . . .  7
     4.3.  Distributed Routing  . . . . . . . . . . . . . . . . . . .  7
     4.4.  Handover with Active Session . . . . . . . . . . . . . . . 10
   5.  Considerations of the Optimized Routing  . . . . . . . . . . . 12
   6.  Security Consideration . . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  References . . . . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
















Tu, et al.              Expires February 1, 2014                [Page 2]

Internet-Draft                   dmm-mip                       July 2013


1.  Introduction

   Centralized mobility anchoring has several drawbacks such as single
   point of failure, routing in a non optimal route and etc, which are
   discussed in [I-D.ietf-dmm-requirements].  Based on the analysis of
   current centralized mobility management approaches, three main
   functions are introduced, including Mobility Routing (MR), Home
   Address Allocation (HAA), and Location Management (LM).

   Based on the proposal of decoupling those functions, this draft
   provides a concept of architecture for Distributed Mobility
   Management (DMM) with some key approaches for DMM.


2.  Conventions and Terminology

2.1.  Conventions used in this document

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

2.2.  Terminology

   This draft introduces following terms which are very similar with
   terms defined in [I-D.ietf-dmm-best-practices-gap-analysis].

   Mobility Routing (MR), which is a logical function used for
   intercepting packets to/from the HoA of a mobile node and forwarding
   the packets, based on the corresponding location information to
   perform distributed routing.

   Home Address Allocation (HAA), which is a logical function used for
   allocating home network prefix or home address to a mobile node.

   Location Management (LM), which is a logical function, used for
   managing and keeping track of the internetwork location information
   of a mobile node, which includes a mapping of the HoA of the MN to
   the routing address of the MN (i.e. routing location) or another
   network element that knows how to forward packets towards the MN.


3.  Solution Overview








Tu, et al.              Expires February 1, 2014                [Page 3]

Internet-Draft                   dmm-mip                       July 2013


3.1.  Functional Decomposition

   The existing mobility management technology, such as MIP, PMIP and
   etc., bundles all the mobility management functions into one
   centralized Home Agent (HA) or Local Mobility Anchor (LMA).

   Sharing similar view with [I-D.ietf-dmm-best-practices-gap-analysis],
   this draft decomposes those centralized anchor into the following
   logical functions to allow a more flexible design to achieve
   distributed mobility management (DMM):

   a.  Home Address Allocation (HAA) function

   b.  Mobility Routing (MR) function

   c.  Location Management (LM) function

   Assuming for any given administrative domain, it consists of one or
   more so called local network (as illustrated in figure 1).  Further,
   each those local networks most likely consists of several routers
   which are deployed with mobility routing (MR) function, and one home
   address allocation (HAA) function and one location management (LM)
   function.

   The HAA and LM, depended on the operating policy, could be deployed
   as a combined entity or be deployed separately.

3.2.  An Example of Networking Model

   Figure 1 illustrates a possible deployment of distribute mobility
   management specified by this draft, which contains 3 local networks.

                One Administrative Domain

        (     LM1/HAA1    )(  LM2/HAA2 )(   LM3   HAA3  )
        (                 )(           )(               )
        (                 )(           )(               )
        (  MR11     MR12  )(     MR2   )( MR31    MR32  )
            +                               +
            |     Local        Local        |     Local
            |    Network1     Network2      |    Network3
            +                               +
           MN1                             MN2

   Figure 1.  An example of DMM deployment

   Both local network 1 and local network 3 contain multiple MRS (e.g.
   two MRs), while local network 2 includes one MR.  The LM and the HAA



Tu, et al.              Expires February 1, 2014                [Page 4]

Internet-Draft                   dmm-mip                       July 2013


   are co-located as ana signal entity in local network 1 and 2, while
   are deployed separately in local network 3.

   It should be noticed that, this figure is only an example.  In actual
   deployment, for one signal local network, multiple LMs and HAAs could
   also be deployed.  Also, it is assuming all local networks belong to
   a same administrative domain (e.g. one operator).  Otherwise, out of
   the scope of this draft.

3.3.  Concept Architecture of Distributed Mobility Management

   For supporting distributed mobility management, signaling
   interactions are needed between those MR, LM and HAA.  This section
   tries to illustrate architecture of the DMM approaches.

   +-------------------------------------+  +--------------------------+
   |  +---------+         +---------+    |  |        +---------+       |
   |  |   HAA   |         |   LM    +<---+--+------->+   LM    |       |
   |  +---+-----+         +----+----+    |  |        +----+----+       |
   |      ;                   /|\        |  |            /|\           |
   |     /|\                   |         |  |             |            |
   |      |                   \|/        |  |            \|/           |
   |      |               +----+----+    |  |        +----+----+       |
   |      +-------------> |   MR    +<---+--+------->+   MR    |       |
   |                      +--+---+--+    |  |        +--+---+--+       |
   |                        /|\ /|\      |  |          /|\ /|\         |
   |                         |   |       |  |           |   |          |
   |                         |___|       |  |           |___|          |
   |                                     |  |                          |
   | Home Local Network                  |  | Visited Local Network    |
   +-------------------------------------+  +--------------------------+

   Figure 2.  Architecture

   The local network to which the MN is initially attached is known as
   its home local network.  The HAA function of mobile node's home local
   network is responsible for IP address\prefix (i.e.  HoA) assignment
   for the mobile node.  During the movement, the mobile node could
   leave its home and enter one another local network which is known as
   visited local network in this draft.

   Interfaces among HAA, LM and MR are needed, and are described as
   following

   a.  Interface between HAA and MR, which supports signaling for prefix
       or IP address assignment, during the attachment of a mobile node
       to a MR




Tu, et al.              Expires February 1, 2014                [Page 5]

Internet-Draft                   dmm-mip                       July 2013


   b.  Interface between LM and MR, which supports signaling for
       maintaining the routing location of mobile node, and the set up
       of an optimized routing for mobile node

   c.  Interface between MR and MR, which supports the signaling for the
       handover of a mobile node from previous MR (pMR) to new MR (nMR)
       in control plane, and supports delivering traffic between mobile
       node and its correspondent node in a distributed manner in data
       plane.

   An administrative domain may have a large amount of mobile nodes;
   therefore the LM may need to maintain a large amount of information
   (i.e. tracing the routing location of those mobile nodes).

   It is better for an administrative domain to deploy multiple LMs.
   Those LMs could be deployed in a form of distributed database, and
   interfaces between them are necessary for information interactive.


4.  Overview of the Distributed Mobility Management Approaches

4.1.  Initial Attachment

   The initial attachment for distributed mobility management is
   triggered when a mobile node is initialized and attached to an access
   link on which the mobile node is connected to a MR.

   When determining that mobile node is authorized for the DMM service,
   MR interacts with HAA, which is in the same local network, by
   signaling, over the interface between them, for the purpose of HoA
   assignment.  The HoA assignment mechanism could be based on stateful
   or stateless mechanism.

   After configuring HoA for the mobile node, that local network becomes
   mobile node's home local network.  The MR, depends on the local
   policy, may interact with a LM which is also in mobile node's home
   local network (i.e.  MN's home LM) to update the mobile node's
   routing location.

   Updating mobile node's routing location during initial attachment is
   not a mandatory step.  Since the mobile node is currently attached to
   its home local network and the assigned HoA is anchored at mobile
   node's currently attached MR.  The traffic, which is designated to
   mobile node's HoA, should be routed to that MR by regular IPv6
   routing mechanism automatically.






Tu, et al.              Expires February 1, 2014                [Page 6]

Internet-Draft                   dmm-mip                       July 2013


4.2.  Dynamic Mobility Management

   Mobile node may change its point of attachment from pMR to nMR when
   it moves.  The nMR may locate at mobile node's home local network, or
   may at a different local network (i.e. visited local network).

   Based on the attachment event, the nMR should try to retrieve mobile
   node's HoA configuration status first (e.g. from mobile node's HAA in
   home local network), and update mobile node's LM with its new routing
   location (e.g.  IP address of nMR).

   Depend on the configuration of the network, new HoA which is anchored
   at nMR could be assigned to mobile node when the mobile node is
   attached to the nMR.  In this case, both HoAs anchored at pMR and nMR
   are respectively available for the mobile node.

   In this case, newly initiated session after the handover is preferred
   to use new HoA as source IP.  Meantime, old session which has already
   established before handover could still use the old HoA as source IP
   for the purpose of keeping session continuity.  The similar idea is
   also proposed in [I-D.seite-dmm-dma],
   [I-D.bernardos-dmm-distributed-anchoring] and
   [I-D.korhonen-dmm-local-prefix].

   But, one should be noted that, in the above configuration, mobile
   node should have ability to manage multiple HoAs, and should have
   ability to decide to return which one of those multiple HoAs when
   applications on the mobile node ask for an IP address to bind.

4.3.  Distributed Routing

   To perform optimized routing, the MRs need the location information
   which is maintained at the LMs.  Use the scenario illustrated in
   figure 1 as an example.

   The assumptions are as following:

   o  MN1 and MN2 are currently attached to MR11 and MR 31 respectively

   o  The destination IP address of the traffic (from MN2 to MN1) is set
      to the HoA of MN1

   o  The MN1's HoA above is anchor at MR12 (which means the regular
      IPv6 routing mechanism will deliver any packet whose destination
      IP address is set to MN1's HoA to MR12), not the MR to which the
      MN1 is currently attached (i.e.  MR11).

   Then, upon receiving the initial few packets of the traffic, MR31



Tu, et al.              Expires February 1, 2014                [Page 7]

Internet-Draft                   dmm-mip                       July 2013


   should determine how to forward the traffic optimally.

    +-----+      +-------+     +-------+    +--------+     +-----+
    | MN2 |      |  MR31 |     |  LM   |    |  MR11  |     | MN1 |
    +-----+      +-------+     +-------+    +--------+     +-----+
       |             |            |             |             |
       |1.IP Traffic |            |             |             |
       |===========> | 2. Query   |             |             |
       |             |----------> |             |             |
       |             | 3. Rsp     |             |             |
       |             |<------ ----|             |             |
       |   +------------------+   |             |             |
       |   | 4.Record Location|   |             |             |
       |   |   of MN1 Locally |   |             |             |
       |   +------------------+   |             |             |
       |             |  5. Distributed Routing  |             |
       |             |========================> |             |
       |             |            |             |6.IP Traffic |
       |             |            |             |===========> |
       |             |            |             |             |

   Figure 3.  Optimized routing based on location query

   Figure 3 illustrates one possible behavior the MR31 could take for
   the purpose of determining how to forward the traffic in an optimized
   manner.

   MR31 first determines whether it holds the routing location
   information of MN1 locally.  If not, MR31 will initiate a query to a
   LM (e.g.  MN1's home LM), who holds such information, by sending a
   query message via the interface between MR and LM.

   When receiving the response, MR31 should save the queried routing
   location information of MN1 locally.

   Based on the routing location information retrieved, MR31 could
   perform distributed routing for delivering the traffic.

   o  One of distributed routing mechanism: MR31 could set up its
      endpoint of a tunnel (e.g.  IP in IP tunnel) to MR11 based on
      MN1's routing location, encapsulate all IP packets of the traffic
      and send those encapsulated IP packets to MR11 in the established
      tunnel directly.

   o  Another one of distributed routing mechanism: as specified in
      [I-D.liebsch-mext-dmm-nat-phl], per-host-locator mechanism can be
      used by MR31 to perform distributed routing, in which, the locator
      is MN1's routing location.



Tu, et al.              Expires February 1, 2014                [Page 8]

Internet-Draft                   dmm-mip                       July 2013


   Only two example distributed routing mechanisms are list above.  Some
   better mechanisms can be developed in the future.

 +-----+      +-------+     +-------+    +--------+   +--------+   +-----+
 | MN2 |      |  MR31 |     |  LM1  |    |  MR12  |   |  MR11  |   | MN1 |
 +-----+      +-------+     +-------+    +--------+   +--------+   +-----+
    |             |            |             |            |           |
    |1.IP Traffic |            |             |            |           |
    |============>|            |             |            |           |
    |    +-------------------+ |             |            |           |
    |    |2.Don't have MN1's | |             |            |           |
    |    |  Routing Location | |             |            |           |
    |    +-------------------+ |             |            |           |
    |             | 3. Regular IPv6 Routing  |            |           |
    |             |========================> |            |           |
    |             |            |   4. Query  |            |           |
    |             |            |<------------|            |           |
    |             |            |   5. Rsp    | 6. Distributed         |
    |             |            |------------>|    Routing             |
    |             |     8. Redirect          |===========>|           |
    |             |<-------------------------|            7.IP Traffic|
    |             |            |             |            |==========>|
    |             |         9. Distributed Routing        |           |
    |             |======================================>|           |
    |             |            |             |           10.IP Traffic|
    |             |            |             |            |==========>|
    |             |            |             |            |           |
    |             |            |             |            |           |

   Figure 4.  Another approach for optimized routing

   multiple mechanisms can be used for setting up optimized routing for
   DMM.  Figure 4 illustrates another possible behavior the MR31 could
   take for the purpose of determining how to forward the traffic in an
   optimized manner.

   MR31 first determine whether it holds the routing location
   information of MN1 locally.  And if MR31 determines it doesn't hold
   such information, it will forward the traffic received by regular
   IPv6 routing mechanism.

   The traffic will be forwarded to MR12, based on the assumption that
   the destination IP address of the traffic (i.e.  HoA of MN1) is
   anchored at MR12.  Upon receiving the traffic, MR12 will determine
   that the MN1 is not attached to itself.  As a result, MR12 will query
   with LM for MN1's routing location.

   When MN1's routing location information is determined, MR12 could



Tu, et al.              Expires February 1, 2014                [Page 9]

Internet-Draft                   dmm-mip                       July 2013


   perform distributed routing for delivering the traffic, as described
   above, to MR11 to which the MN1 is currently attached and then
   forwarded to MN1 by MR11.

   MR12 is further preferred to send another message to MR31 via
   interface between MRs to inform MR31 with MN1 current routing
   location to trigger the direction.  The MR31, based on the received
   routing location information, will perform distributed routing for
   delivering the rest IP packets of traffic, first to MR11, then to
   MN1, as described above.

   It should be noted that, for both behaviors described above, when the
   routing between MN1 and MN2 is established, the routing is optimized:
   MN2=>MR31=>MR11=>MN1.

   For the latter behavior, if the MN1 is currently attached to the
   MR12, the routing for traffic from MN2 to MN1 will be identical with
   regular IPv6.  But, how the MR12 can determine MR31 (i.e. the MR to
   which the MN2 is attached) is a challenge.

4.4.  Handover with Active Session

   Section 4.2 has already discussed scenarios the mobile node changes
   its point of attachment, but without discussing how to maintain the
   continuity of sessions which are initiated before the handover.


























Tu, et al.              Expires February 1, 2014               [Page 10]

Internet-Draft                   dmm-mip                       July 2013


    +---+     +--------+   +--------+   +-------+  +--------+     +---+
    |MN1|     |  MR11  |   |   MR2  |   |  LM1  |  |  MR31  |     |MN2|
    +---+     +--------+   +--------+   +-------+  +--------+     +---+
      |            |            |           |           |           |
      |            |           1. Ongoing traffic       |           |
      |<==========>|<==================================>|<========> |
      |            |  2. Context|           |           |           |
      |            |  Transfer  |           |           |           |
      |            |<---------->|           |           | 3. IP     |
      |            |            |           |           | Traffic   |
      |            |            4. Distributed Routing  |<========= |
      |            |<===================================|           |
      |            |5. Transfer |           |           |           |
      |            |==========> |           |           |           |
      |    6. IP Traffic        |           |           |           |
      |<======================= |           |           |           |
      |            |            | 7. Redirect           |           |
      |            |----------------------------------> |           |
      |            |            |           | +----------------+    |
      |            |            |           | | 8. Update      |    |
      |            |            |           | | Location of MN1|    |
      |            |            |           | +----------------+    |
      |            |            |           |           |  9. IP    |
      |            |            |           |           |  Traffic  |
      |            |            |10. Distributed Routing|<==========|
      |    11. IP Traffic       |<======================|           |
      |<========================|                       |           |
      |            |            |                       |           |

   Figure 5.  Handover with Active Session

   Figure 5 illustrates approaches for handover of MN1 from pMR (MR11)
   to nMR (MR2).  During the handover, the nMR need to update MN1's new
   routing location to the LM.

   Context transfer between nMR and pMR is always necessary, e.g.
   security context.  The nMR could inform the pMR with MN1's new
   routing location information during the context transfer.

   Based on the received information, pMR sets up mobility context for
   MN1 locally to at least record MN1's new routing location.  It should
   be noted that, the mobility context for a specific mobile node which
   is performing handover is just a temporarily information.  When the
   handover is finished, the correspondent mobility context need to be
   deleted.

   MR31 to which the MN2 is attached isn't aware of the handover event
   of MN1.  Thus, the traffic from MN2 to MN1 will still be forwarded by



Tu, et al.              Expires February 1, 2014               [Page 11]

Internet-Draft                   dmm-mip                       July 2013


   MR31 to the pMR (MR11) in a distributed routing manner (which is
   described in section 4.3 above).

   For reducing packet loss, the pMR is preferred to establish a
   directional tunnel to nMR and forward the received packets from MR31
   to nMR via the tunnel.  The key is that, the pMR needs to send a
   message to MR31 to update MN1's routing location stored in MR31
   locally.  Based on the updated routing location information of MN1,
   MR31 will forward the upcoming traffic from MN2 to MN1 to the nMR
   directly.


5.  Considerations of the Optimized Routing

   One can note that, the routing between MN and CN is optimized based
   on the mechanism described in section 4.2.  The CN is assumed to be a
   mobile node.  That means CN must be attached to a certain MR, and
   that MR will keep track of the location of CN and interpreted any
   packet sent from CN to MN.  But, when CN is a fixed node, there may
   be no such MR which servers the CN.

   In real world, most of such fixed nodes (CN) are deployed in a
   centralized manner, e.g.  CDN/IDC/Web Servers and etc.  Those fixed
   nodes are generally converged by a couple of access routers, although
   the topology within those fixed nodes may be very complicating, to
   access operator's IP bearer network.  Figure 6 is an example.

     __________
    /    CN     \            ,--------.
   ((CDN\IDC\Web )---Access Router     `.
   (   Server)   )    ,--'               `'
    \___________/     \                 _ -'
                        '--  MR  -----''
                              |
                              |
                             MN1

   Figure 6.  CNs are fixed nodes

   For the scenario described in figure 6, a direct solution is to
   implement MR function with convergence access router or gateway
   router (i.e. the access router illustrated in the above figure).

   Another alternative is to use anycast mechanism described in
   [I-D.ietf-dmm-best-practices-gap-analysis] and
   [I-D.wakikawa-mext-global-haha-spec].  Anycast mechanism could
   guarantee the traffic sent from CN to MN to reach a nearest MR which
   anycast the HNP aggregation of the mobile node.



Tu, et al.              Expires February 1, 2014               [Page 12]

Internet-Draft                   dmm-mip                       July 2013


6.  Security Consideration

   This draft proposes signaling messages interaction over interfaces
   among MRs, LMs and HAAs for supporting Distributed Mobility
   Management (figure 2).  The security issues should be considered for
   those messages.

   Since, this draft assumes all local networks belong to a same
   administrative domain (e.g. one operator), then signaling interfaces
   among those MRs, LMs and HAAs can be established directly.  Security
   association mechanism which is used for protecting PB\PB messages
   defined in [RFC3775] can be reused for protecting signaling messages
   (such as IP address allocation, routing location information
   update\query) between MR and LM\HAA.

   Signaling between MRs (such as signaling for distributed mobility
   support) in this draft is preferred to be protected by using end-to-
   end security association(s) offering integrity and data origin
   authentication.  The MR is proposed to implement IPsec [RFC4301] or
   other equivalents for protecting the messages.  E.g.  IPsec
   Encapsulating Security Payload (ESP, [RFC4303]) in transport mode
   with mandatory integrity protection could be used for protecting
   those signaling messages.


7.  IANA Considerations

   This document makes no request of IANA.


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.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

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



Tu, et al.              Expires February 1, 2014               [Page 13]

Internet-Draft                   dmm-mip                       July 2013


8.2.  References

   [I-D.bernardos-dmm-distributed-anchoring]
              Bernardos , CJ. and JC. Zuniga , "PMIPv6-based distributed
              anchoring", April 2013.

   [I-D.ietf-dmm-best-practices-gap-analysis]
              Liu, D., "Distributed Mobility Management: Current
              practices and gap analysis", June 2013.

   [I-D.ietf-dmm-requirements]
              Chan, H., "Requirements for Distributed Mobility
              Management", July 2013.

   [I-D.korhonen-dmm-local-prefix]
              Korhonen , J. and T. Savolainen , "Local Prefix Lifetime
              Management for Proxy Mobile IPv6", June 2013.

   [I-D.liebsch-mext-dmm-nat-phl]
              Liebsch , M., "Per-Host Locators for Distributed Mobility
              Management", March 2012.

   [I-D.seite-dmm-dma]
              Seite , P. and P. Bertin , "Distributed Mobility
              Anchoring", July 2012.

   [I-D.wakikawa-mext-global-haha-spec]
              Wakikawa , R., "Global HA to HA Protocol Specification",
              September 2011.


Authors' Addresses

   Yangwei Tu
   ZTE
   No.68, Zijinhua RD,Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Email: tu.yangwei@zte.com.cn











Tu, et al.              Expires February 1, 2014               [Page 14]

Internet-Draft                   dmm-mip                       July 2013


   Wen Luo
   ZTE
   No.68, Zijinhua RD,Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Email: luo.wen@zte.com.cn


   Tricci So
   ZTE USA


   Phone:
   Fax:
   Email: tso@zteusa.com
   URI:


































Tu, et al.              Expires February 1, 2014               [Page 15]