[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                             W. Luo
Internet-Draft                                                    J. Liu
Intended status: Standards Track                                     ZTE
Expires: January 30, 2014                                  July 29, 2013


                       PMIP Based DMM Approaches
                draft-luo-dmm-pmip-based-dmm-approach-02

Abstract

   Proxy Mobile IPv6 (PMIPv6) is standardized by IETF to supply mobility
   management for mobile nodes (MN).  For supporting Distributed
   Mobility Management based on current PMIP standard, enhanced Proxy
   Mobile IPv6 (ePMIP) with two new logic functions is introduced. (1)
   Location Management Function (LMF), (2) Distributed Anchoring
   Function (DAF), including Distributed Routing sub-Function (DRF) and
   Distributed Mobility sub-Function (DMF).  Basic signalling procedures
   and considerations are also described in this document.

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 January 30, 2014.









Luo & Liu               Expires January 30, 2014                [Page 1]


Internet-Draft          PMIP Based DMM Approaches              July 2013


Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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 Used in This Document . . . . . . . . . . . . . .   3
   3.  Overview of Ehanced Porxy Mobile IPv6 . . . . . . . . . . . .   3
     3.1.  Ehanced PMIP Networking Schematic . . . . . . . . . . . .   4
     3.2.  Functions of eMAG . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Functions of eLMA . . . . . . . . . . . . . . . . . . . .   5
   4.  Overview of ePMIP Approaches  . . . . . . . . . . . . . . . .   6
     4.1.  Initial Registration  . . . . . . . . . . . . . . . . . .   6
     4.2.  Optimized Routing . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Handoff when Optimaized Routing is Established  . . . . .   9
     4.4.  Multiple eLMAs Consideration  . . . . . . . . . . . . . .  11
       4.4.1.  Determining eLMA Based on Configuration . . . . . . .  11
       4.4.2.  Determining eLMA Based on IPv6 Hop-by-Hop Options
               Header  . . . . . . . . . . . . . . . . . . . . . . .  12
       4.4.3.  Determining eLMA Based on Interface Between eLMAs . .  13
   5.  CN Considerations . . . . . . . . . . . . . . . . . . . . . .  14
     5.1.  CN Which is not Registered with eLMA  . . . . . . . . . .  14
     5.2.  Routing Optimization Considerations when the CN is a
           Fixed Node  . . . . . . . . . . . . . . . . . . . . . . .  15
   6.  Handoff between eMAG and MAG  . . . . . . . . . . . . . . . .  16
   7.  Considerations for Other Implementation . . . . . . . . . . .  17
     7.1.  One Alternative Implementation  . . . . . . . . . . . . .  17
     7.2.  Optimized Routing Consideration . . . . . . . . . . . . .  18
     7.3.  Correspondent Node Consideration  . . . . . . . . . . . .  18
     7.4.  Location Management Consideration . . . . . . . . . . . .  19
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   9.  Difference with Localized Routing . . . . . . . . . . . . . .  21
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     11.2.  Informative References . . . . . . . . . . . . . . . . .  23



Luo & Liu               Expires January 30, 2014                [Page 2]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

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.draft-ietf-dmm-requirements].  For supporting
   Distributed Mobility Management to eliminate those drawbacks,
   enhanced Proxy Mobile IPv6 (ePMIP) with two new logic functions based
   on PMIP ([RFC5213]) is introduced in this document . (1) Location
   Management Function (LMF), maintaining the mappings between IP
   addresses and location information of mobile nodes.  (2) Distributed
   Anchoring Function (DAF), including Distributed Routing sub-Function
   (DRF) which enables optimized routing between mobile node and its
   correspondent node and Distributed Mobility sub-Function (DMF) which
   guarantees mobile node's mobility with minimal packet loss when
   optimized routing is established.

   DAF can be deployed in [RFC5213]specified MAG to constitute an eMAG,
   and LMF can be deployed in [RFC5213] specified LMA to constitute an
   eLMA.  This document intends to provide approaches for eliminating
   those drawbacks by means of allowing mobile node can change its
   traffic anchor point dynamically.  Besides, Distributed Mobility
   Management approaches are considered not only for communication
   between two mobile nodes, but also for communication between a mobile
   node and a fixed node (section 5.2).  Further, an alternative
   implementation is also considered in section 7.

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

3.  Overview of Ehanced Porxy Mobile IPv6

   For supporting Distributed Mobility Management discussed in [I-D
   DMM], enhanced Proxy Mobile IPv6 (ePMIP) with two new logic functions
   is introduced in this document . (1) Location Management Function
   (LMF), maintaining the mappings between IP addresses and location
   information of mobile nodes (perhaps location information of fixed
   nodes are also included). (2) Distributed Anchoring Function (DAF),
   including Distributed Routing sub-Function (DRF) which enables
   optimized routing between mobile node and its correspondent node and
   Distributed Mobility sub-Function (DMF) which guarantees the mobile
   node's mobility when optimized routing is enabled.





Luo & Liu               Expires January 30, 2014                [Page 3]


Internet-Draft          PMIP Based DMM Approaches              July 2013


3.1.  Ehanced PMIP Networking Schematic

          Prefix A          Prefix B        Prefix C+D        Prefix X
          \  |  /           \  |  /          \  |  /       |  \  |  /
           \ | /             \ | /            \ | /        |   \ | /
           eLMA1             eLMA2            eLMA3        |    LMA
                                                           |
     (        )(        )(        ) (        )   (        )|(        )
     (  area1 )(  area2 )(  area3 ) (  area4 )...(  arean )|( arean+1)
     (        )(        )(        ) (        )   (        )|(        )
     (  eMAG1 )(  eMAG2 )(  eMAG3 ) (  eMAG4 )...(  eMAGn )|(   MAG  )
          |                             |
          |                             |               +-----+
          |                             |               | CN2 |
         MN1                           CN1              +-----+

                        PMIP Domain with ePMIP deployed


   Figure 1.  RFC[5213] specified PMIP Domain with ePMIP deployed

   The ePMIP can be implemented in many ways.  One is to extend Location
   Management Function in [RFC5213] specified Local Mobility Anchor
   (i.e. legacy LMA) and to extend Distributed Anchoring Function in
   [RFC5213] specified Mobile Access Gateway (i.e.  legacy MAG).  Legacy
   LMA with LMF is called as enhanced local mobility anchor (eLMA), and
   legacy MAG with DAF is called as enhanced mobile access gateway
   (eMAG) respectively in the context of this document.

   Figure 1 illustrates a possible deployment for ePMIP, in which ePMIP
   is deployed within a PMIP domain.  Mechanism specified by the ePMIP
   is enabled automatically for a mobile node when it attaches to an
   eMAG and without any of its awareness, therefore there is no
   additional requirement for a IPv6 mobile node.  For fixed node
   considerations, please refer to section 5.2.

   Clear boundary between ePMIP and PMIP is not necessary, however,
   deploying ePMIP in a continuous area is preferred.  Distributed
   mobility management approaches will be applied only when
   correspondent node of this mobile node also attaches to an entity
   which supports at least DRF (e.g. an eMAG), otherwise [RFC5213]
   specified PMIP (say legacy PMIP) approaches will be applied (for more
   details, refer to section 5).  For supporting distributed mobility
   management approaches, new signalling messages among the LMFs and
   DAFs are also proposed in this draft.

   For other implementation considerations, please refer to section 7.




Luo & Liu               Expires January 30, 2014                [Page 4]


Internet-Draft          PMIP Based DMM Approaches              July 2013


3.2.  Functions of eMAG

   The eMAG is fully compatible with legacy MAG with limited additional
   functions which are included in the distributed anchoring function.
   The general considerations of the eMAG (DAF is a part of eMAG) are
   described as following:

   - If eMAG decides to route traffic from its attached mobile node in
   an optimized way, it should invoke the Distributed Anchoring Function
   (DAF), more specifically, the Distributed Routing Function (DRF), to
   enable distributed mobility management approaches.

   - Optimized routing is realized by a direct tunnel between two DRFs
   of mobile node and its correspondent node.  DRF is responsible for
   maintaining location information of mobile node's correspondent node.

   - If correspondent node also attaches to an eMAG and is registered
   with an eLMA, the direct tunnel is established between two eMAGs and
   tunnel endpoints are IP addresses of these two eMAGs (or CoAs of
   these two communicating peers).  For other scenarios, e.g. the
   correspondent node is a fixed node, refer to section 5.

   - Optimized routing can only be enabled when location of
   correspondent node is determined.  In case the location cannot be
   determined locally, DRF should initiate a query approach with a
   corresponding LMF.  In case DRF is informed with the location (could
   be CN's new location in handoff scenario), it should update the
   location locally and forward any follow-up traffic based on that
   location.  In case location of correspondent node cannot be
   determined by any means, common routing (e.g. PMIP routing) mechanism
   should be used.

   - For supporting mobile node's handoff from previously attached eMAG
   (p-eMAG) to newly attached eMAG (n-eMAG), Distributed Mobility
   Function (DMF) of both eMAGs shall be enabled.  The responsibility of
   n-DMF (n-eMAG) is to inform p-DMF (p-eMAG) with new location of that
   mobile node during handoff.  The responsibility of p-DMF (p-eMAG ) is
   to forward any received traffic which designated to that mobile node
   from DRF of correspondent node to n-DMF (n-eMAG ) and to inform the
   DRF with new location for session continuity.

3.3.  Functions of eLMA

   The eLMA is fully compatible with legacy LMA with limited additional
   functions which are included in the Location Management Function.
   The general considerations of the eLMA (LMF is a part of eLMA) are
   described as following:




Luo & Liu               Expires January 30, 2014                [Page 5]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   - The responsibility of LMF is to determine the location of a
   specified mobile node (perhaps a fixed node, please refer to section
   5) identified by its IP address (e.g. HoA) when it is queried by DRF.
   Interface between LMFs for determining the location information is
   proposed, for other alternatives, please refer to section 4.4.

   - The location information of a mobile node can be its CoA, and
   mechanisms for maintaining the mapping of mobile node's IP address
   and its location information (i.e. HoA-CoA correlation) can be based
   on Binding Cache Entry (BCE) which is specified in [RFC5213].

4.  Overview of ePMIP Approaches

   As described above, one implementation of ePMIP is to deploy LMF with
   legacy LMA to constitute an eLMA, and deploy DAF (including DRF and
   DMF sub-functions) with legacy MAG to constitute an eMAG.  The
   sections including section 4 to 6 assume ePMIP adopts this
   implementation.  Considerations for other alternative
   implementations, please refer to section 7.

   The overall assumptions for section 4 are as following:

   - The correspondent node is also a mobile node which attaches to an
   eMAG and is registered with an eLMA.

   For other scenarios, such as correspondent node is a fixed station or
   not registered with an eLMA, please refer to section 5.

4.1.  Initial Registration

   The initial registration procedure for ePMIP is triggered when a
   mobile node is initialized and attaches to an access link on which
   there is an eMAG.  The most likely procedures for initial
   registration are identical with those specified in [RFC5213].

   When determining the mobile node is authorized for the network-based
   mobility management service, eMAG sends PBU to a selected eLMA for
   the mobile node to complete the registration.  General, an eLMA is
   always preferred for the mobile node, unless there has other
   constraints.

   For example, If the mobile node's policy profile includes a filed of
   mobile node's IPv6 home network prefix(es) assigned to the mobile
   node's connected interface, and if the HNP(es) is(are) managed by a
   legacy LMA, the eMAG shall send a PBU to that LMA.  In this case, the
   eMAG shall act as a legacy MAG for this mobile node which means the
   DAF function in this eMAG shall be disabled for this mobile node.




Luo & Liu               Expires January 30, 2014                [Page 6]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   When initial registration with eLMA is completed, the mobile node
   gets its HNP(es) and eLMA creates a binding cache entry for this
   mobile node to maintain the mapping of this mobile node's HNP(es) and
   Proxy-CoA.

4.2.  Optimized Routing

   As described in section 3.2, ePMIP leverages a direct tunnel between
   two eMAGs which are implemented with DRF to realize an optimized
   routing between mobile node and its correspond node.  The effect is
   similar with the MAG-MAG tunnel specified in
   [I-D.ietf-netext-pmip-lr] but the principle is different, refer to
   section 9 for more information.

   +-----+      +--------+    +-------+    +--------+     +-----+
   | MN1 |      |  eMAG1 |    |  eLMA |    |  eMAG4 |     | MN2 |
   +-----+      +--------+    +-------+    +--------+     +-----+
      |             |            |             |             |
      |  1.Attach and PMIP Reg.  |  1.Attach and PMIP Reg.   |
      |<------------|----------->|<------------|------------>|
      |             |            |             |             |
      |2.uplink Data|            |             |             |
      |============>| 3. PBQR    |             |             |
      |             |----------->|             |             |
      |             | 4. PBQA    |             |             |
      |             |<-----------|             |             |
      |   +------------------+   |             |             |
      |   | 5.Record Location|   |             |            |
      |   |   of MN2         |   |             |             |
      |   +------------------+   |             |             |
      |             |  6.uplink data in tunnel |             |
      |             |=========================>|             |
      |             |            |             |7.uplink data|
      |             |            |             |============>|
      |             |   8. Ongoing traffic     |             |
      |<===========>|<========================>|<===========>|
      |             |            |             |             |


   Figure 2.  Optimized Routing

   Figure 2 illustrates data delivery approaches of ePMIP for
   Distributed Mobility Management.  Except for the general assumptions
   applied for section 4, two more assumptions are also applied as
   following:

   - Mobile nodes (MN1 and MN2) attach to different eMAGs (eMAG1 and
   eMAG4) respectively.



Luo & Liu               Expires January 30, 2014                [Page 7]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   - Mobile nodes are registered with a same eLMA.

   For other scenarios, such as mobile nodes are registered with
   different eLMAs, refer to section 4.4.

   After the initial registration, both mobile nodes get their HNPes.
   And eLMA maintains the mappings of HNP(es) and Proxy-CoAs of both
   mobile nodes in binding cache entries for them respectively .

   The communication between MN1 and MN2 is initiated by MN1 sending IP
   packets to MN2 (i.e. uplink traffic).  The destination IP address of
   the uplink traffic is set to HoA of MN2.  Upon receiving the initial
   uplink traffic, eMAG1 should determine whether an optimized routing
   can be established by the support of DRF on it.

   The eMAG1 (DRF) should determine whether it holds the location (i.e.
   CoA) of MN2 locally first.  If not, eMAG1 (DRF) should determine the
   location by initiating a query (i.e. sending a PMIP Binding Query
   Request, PBQR) to eLMA (LMF) who holds the BCE for MN2.  Based on HNP
   of MN2 provided in the PBQR, eLMA (LMF) could derive the location of
   MN2 (i.e. CoA) in a corresponding BCE and responses eMAG1 (DRF) with
   an answer (i.e. sending a PMIP Binding Query Answer, PBQA) carrying
   the location information.  Upon receiving the PBQA, eMAG1 (DRF)
   records the location of MN2 locally.

   Upon the location of MN2 is determined, eMAG1 (DRF) sets up its
   endpoint of a tunnel (e.g. IP in IP tunnel) to eMAG2 (DRF).  And all
   follow-up uplink traffic will be encapsulated by eMAG1 (DRF) and sent
   to eMAG4 (DRF) in the established tunnel directly.

   Before the optimized routing is established, eMAG1 could forward the
   first few packets of the uplink traffic to eLMA via bi-directional
   PMIP tunnel between the two as specified by legacy PMIP.  In this
   case, the routing of the first few packets is non-optimized, and the
   delay of those packets may be a litter bit larger than the follow-up
   traffic.  Another alternative is that eMAG1 buffers those packets
   until the optimized routing is set up.  In this case, how to
   determine capacity of the buffer should be carefully considered.

   Upon receiving encapsulated packet in the eMAG-eMAG tunnel, the eMAG4
   (DRF) needs to decapsulate the packet and forwards the uplink traffic
   to MN2.  As an alternative, eMAG4 (DRF) may parse the packet and
   record the location of MN1.  The location of MN1 can be derived from
   the outer IP header of the encapsulated packet (i.e. the IP address
   of the tunnel entry point).

   Upon receiving downlink traffic from MN2 to MN1, eMAG4 (DRF) should
   also set up its endpoint of a tunnel to eMAG1 (DRF) for the downlink



Luo & Liu               Expires January 30, 2014                [Page 8]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   traffic when the location of MN1 is determined.  At this moment, a
   bi-directional tunnel between two eMAGs has been established for all
   follow-up uplink and downlink traffic and an optimized routing for
   MN1 and MN2 is set.

4.3.  Handoff when Optimaized Routing is Established

   MN1 may change its point of attachment from previously attached eMAG
   (p-eMAG) to newly attached eMAG (n-eMAG) at any time after the
   optimized routing has been established as described in section 4.2.
   The routing shall still be remained optimized after handoff.

   [I-D.ietf-netext-pmip-lr] also specifies a method for re-establishing
   optimized routing after the handoff which leverages another new
   trigger from LMA to both MAGs involved.  The consequence is to make
   the routing non-optimized during the handoff, and optimized again
   after the handoff.  The handoff approach specified here is much
   different from [I-D.ietf-netext-pmip-lr] specified approach and may
   provide less latency and jitter.

   +---+     +--------+   +--------+   +-------+  +--------+     +---+
   |MN1|     | p-eMAG |   | n-eMAG |   |  eLMA |  |  eMAG4 |     |MN2|
   +---+     +--------+   +--------+   +-------+  +--------+     +---+
     |            |            |           |           |           |
     |            |           1. Ongoing traffic       |           |
     |<==========>|<==================================>|<=========>|
     |            |            |           |           |           |
     |            | 2.attach and PMIP Reg. |           |           |
     |<----------------------->|<--------->|           |           |
     |            |  3.PBCI    |           |           |           |
     |            |<-----------|           |           |           |
     |            |  4.PBCA    |           |           |           |
     |            |----------->|           |           |           |
     |   5. Uplink traffic     |           |           |           |
     |========================>|           |           |           |
     |            |  +-----------------+   |           |           |
     |            |  | 6.Determine the |   |           |           |
     |            |  | Location of MN2 |   |           |           |
     |            |  +-----------------+   |           |           |
     |            |            |           |           |           |
     |            |      +--------------------------------------------+
     |            |      |   7. Process of uplink traffic is similar  |
     |            |      |      with the approaches in figure 2       |
     |            |      +--------------------------------------------+
     |            |            |           |           |           |
     |            |            | 8 . Downlink Traffic  |           |
     |            |<===================================|<==========|
     |            |===========>|           |           |           |



Luo & Liu               Expires January 30, 2014                [Page 9]


Internet-Draft          PMIP Based DMM Approaches              July 2013


     |<========================|           |           |           |
     |            |            | 9. PBCI   |           |           |
     |            |----------------------------------->|           |
     |            |            |           | +----------------+    |
     |            |            |           | | 10. Update     |    |
     |            |            |           | | Location of MN1|    |
     |            |            |           | +----------------+    |
     |            |            | 11. PBCA  |           |           |
     |            |<-----------------------------------|           |
     |            |     12. Ongoing Downlink Traffic   |           |
     |<========================|<======================|<==========|
     |            |            |                       |           |


   Figure 3.  Handoff When Optimized Routing is Established

   Figure 3 illustrates approach for handoff of MN1 from p-eMAG to
   n-eMAG.  During handoff, legacy PMIP specified procedure is performed
   for MN1 to maintain its HNP(es) unchanged.  The n-eMAG on new access
   link, upon detecting MN1 on the link, assigns a new CoA for MN1 and
   generates a PBU message to eLMA for updating the BCE for MN1.  In
   sequence, eLMA responses a PBA message to n-eMAG with one additional
   new extension which includes the previous location of MN1 (i.e. CoA
   of MN1 assigned by p-eMAG).

   Further, n-eMAG (DMF) initiates an inform message (i.e. PMIP Binding
   Change Inform, PBCI) to p-eMAG (DMF) with new location of MN1 (i.e.
   CoA assigned by n-eMAG) based on the acquired previous location of
   MN1.  Sequencely, p-eMAG (DMF) updates the location of MN1 and
   responses with an acknowledge message (i.e. PMIP Binding Change Ack,
   PBCA) with all location information of the MN1's current
   correspondent nodes (in figure3, the current correspondent node is
   only MN2).

   Upon uplink traffic arriving at n-eMAG instead of p-eMAG, n-eMAG
   (DRF) can derive the location of MN2 locally and forwards the traffic
   in an optimized way of routing (i.e.  MN1->n-eMAG->eMAG4->MN2).

   The most likely is that downlink traffic during the handoff is still
   forwarded by eMAG4 (DRF) to p-eMAG (DRF) before location of MN1
   stored in eMAG4 (DRF) locally is updated (i.e.
   MN2->eMAG4->p-eMAG->MN1) and is discarded by p-eMAG (DRF).

   For reducing packet loss, p-eMAG (DMF) is proposed to establish a
   directional tunnel to n-eMAG (DMF) and forward any received downlink
   traffic to n-eMAG (DMF) via the tunnel.  Meanwhile, p-eMAG (DMF) is
   also proposed to update the location of MN1 stored in eMAG4 (DRF) by
   initiating a PBCI to eMAG4 (DRF) to indicate eMAG4 (DRF) to forward



Luo & Liu               Expires January 30, 2014               [Page 10]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   follow-up downlink traffic to n-eMAG (DRF) directly:
   MN2->eMAG4->n-eMAG->MN1.

4.4.  Multiple eLMAs Consideration

   As illustrated in figure 1, multiple eLMAs can be deployed.  The most
   likely is that the mobile node and its correspondent node (i.e.
   another mobile node) are registered with different eLMAs.  The
   approaches described in subsection 4.2 and 4.3 simply assume both
   mobile nodes are registered with the same eLMA (the same assumption
   applied to [I-D.ietf-netext-pmip-lr]), and this section considers
   multiple eLMAs.

   Announce PA       Announce PB   Announce PC and PD
    \   |   /         \   |   /        \   |   /
     \  |  /           \  |  /          \  |  /
    +--------+       +--------+        +--------+
    |  eLMA1 |       |  eLMA2 |        |  eLMA3 |
    +-----+--+       +--------+        +---+----+
         |                  _______________|
         /                 |
    +---+----+        +----+---+
    |  eMAG1 |        |  eMAG2 |
    +---+----+        +---+----+
        |                 |
     +--+-+             +-+--+
     | MN1|             | MN2|
     +----+             +----+


   Figure 4.  Mobile node and its Correspondent Node are Registered with
   Different eLMAs

   As illustrated in figure 4, MN1 is registered with eLMA1 by eMAG1,
   and MN2 is registered with eLMA3 by eMAG2 respectively.  Based on
   RFC[5213], only the LMA which is involved in PMIP registration for a
   mobile node holds this mobile node's Binding Cache Entry.  Therefore,
   in figure 4, only eLMA1 holds the location information of MN1 and
   only eLMA3 holds the location information of MN2.

   As described in section 4.2, before establishing optimized routing
   for the traffic, eMAG1 shall determine the location of MN2.  In case
   the location can not be determined locally, eMAG1 shall determine to
   which eLMA it should send a PBQR message.

4.4.1.  Determining eLMA Based on Configuration





Luo & Liu               Expires January 30, 2014               [Page 11]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   As illustrated in figure 4, each eLMA manages a set of IPv6 prefixes
   with which it uses to allocate home network prefixes or HoAs to the
   MNs registered to that eLMA.  For example, eLMA1 announces prefixes
   PA to routing system and eLMA3 announces prefixes PC+PD.

   If eMAGs could be aware of the IPv6 prefixes configurations of each
   eLMA, e.g. from operator's management plane since they are in a same
   administrative domain.  The eMAG (DRF) can determine the
   corresponding eLMA (LMF) to which it should send the PBQR, based on
   the destination IPv6 address of the traffic and the configured
   information.

   For example, the destination IP address of the traffic from MN1 to
   MN2 is MN2's HoA.  Based on configuration information, eMAG1 (DRF)
   can determine the HNP of MN2 is prefix PC and is managed by eLMA3.
   Therefore, eMAG1 (DRF) can determine the eLMA3 (LMF) should be
   queried when it wants to determine the location of MN2.

   This solution looks simple, but it depends on static configured
   information on every eMAGs.  If configuration of a eLMA is changed
   (e.g. add a prefix PE into eLMA1's IPv6 prefix set), the most likely
   is that the configured information in all eMAGs in same
   administrative domain needs update.  It seems like that this solution
   works well for a administrative domain with small number of eMAGs.

4.4.2.  Determining eLMA Based on IPv6 Hop-by-Hop Options Header

    Announce PA       Announce PB     Announce PC and PD
      \  |  /           \  |  /           \  |  /
       \ | /             \ | /             \ | /
       eLMA1             eLMA2             eLMA3
                                             +
                                            /!\
           ,------- Router1-------- Router2 .|
          |
          |
        eMAG1

    eMAG1 initiates a query message (PBQR) carried in a IP
    packet whose destination IP address is HoA of MN2.
    The packet will be intercepted, processed and terminated by
    eLMA3 who manages the prefix of the MN2's HoA based on
    the mechanism of the Hop-by-Hop Option Header.


   Figure 5.  Determining eLMA Based on Hop-by-Hop Options Header





Luo & Liu               Expires January 30, 2014               [Page 12]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   When constructing a PBQR message, eMAG1 can use HoA of MN2 as
   destination IP address of this message and construct an appropriate
   IPv6 Hop-by-Hop Option Header as extension header ([RFC2460]).  The
   HoA of MN2 is the destination IP address of the uplink traffic.

   When IP packet which includes the PBQR message is sent into the
   routing system, standard routing mechanism ensures the packet can
   reach eLMA3 which manages the prefix of MN2's HoA.  Depending on the
   mechanism of the Hop-by-Hop Option Header, each router including
   eLMA3 on the routing pass of this packet will intercept the packet
   and check the Hop-by-Hop Option Header.

   Based on the indication carried by the options in Hop-by-Hop Option
   Header, eLMA3 determines whether the prefix of destination IP address
   belongs to its management.  If it does, eLMA3 shall treat itself as
   destination of this message and let the LMF on it process the
   message.

   It seems like that, all common routers on the routing pass of this
   packet will check the Hop-by-Hop Option Header and may cause some
   delay.  Another disadvantage is that it will take relative longer
   time to make sure no location information of correspondent node can
   not be determined (refer to section 5.1 for more details).

4.4.3.  Determining eLMA Based on Interface Between eLMAs

    +-----------------------------+
    |            eLMA2            |
    |                             |
    |  eLMA1--------------> eLMA3 |
    |    /|\  further query       |
    +-----+-----------------------+
          |
   query  |
          |
         eMAG1


   Figure 6.  Determining eLMA Based on Interface Between eLMAs

   Interface between eLMAs which are located in a same administrative
   domain is introduced for determining location information of a
   particular mobile node.

   When determining location of correspondent node, eMAG1 (DRF), in
   figure 6, could simply send a PBRQ message to any random eLMA (LMF)
   it considers convenient (e.g. eLMA1).  The most likely is that the
   eLMA (LMF) queried does not hold the relevant location information.



Luo & Liu               Expires January 30, 2014               [Page 13]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   But the eLMA (LMF) can determine which eLMA (LMF) holds the
   information (e.g. eLMA3).

   For example, if IPv6 prefixes managed by each eLMA are awared of, the
   eLMA1 (LMF) can determine which eLMA (LMF) should be queried further
   and query it.  It can be expected that the number of eLMA deployed in
   a administrative domain will not be large (as illustrated in figure
   1), therefore, depending on configuration is applicable.

5.  CN Considerations

   The assumption of section 4 is that the correspondent node is also a
   mobile mode and is registered with eLMA by eMAG.  Other scenarios,
   such as correspondent node is a fixed node, or a mobile node but is
   not registered with eLMA, are considered in this section.

5.1.  CN Which is not Registered with eLMA

   This section considers scenario that the correspondent node (e.g.
   CN2 in figure 1) is a mobile node but not registered with eLMA.  For
   example, CN2 is registered with a legacy LMA by attaching to a legacy
   MAG.  For another example, CN2 just locates in common IPv6
   environment.

   When mobile node (MN1 in figure 1) initiates uplink traffic to
   correspondent node (CN2 in figure 1), eMAG1 (DRF) to which MN1
   attaches should initiate a query for determining location of CN2 as
   described in section 4.2.

   According to section 4.4.1, eMAG1 (DRF) can not determine to which
   eLMA (LMF) it should send the query message, because CN2's prefix is
   out of the management of any eLMA.  In this case, eMAG1 (DRF) can
   make sure no location information can be determined.

   According to section 4.4.2, eMAG1 (DRF) should construct a query
   message and set message's destination to IP address of CN2.  The
   query message will be routed to CN2 based on common routing mechanism
   and no response is excepted.  The eMAG1 (DRF) should wait for the
   response until the related timer is timeout.  Before eMAG1 (DRF) can
   make sure no location information can be determined, one or more
   query message may be re-sent by eMAG1 (DRF).  Thus, it will take a
   relative longer time to make sure no location information can be
   determined.

   According to section 4.4.3, eMAG1 (DRF) can send a query message to
   any one of those eLMAs (LMF) and the eLMA (LMF) queried performs the
   query among those eLMAs (LMF).  In this case, eMAG1 (DRF) can make
   sure no location information can be determined.



Luo & Liu               Expires January 30, 2014               [Page 14]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   As described above, the failed queries are excepted and location
   information of CN2 can not be determined by eMAG1 (DRF).  In this
   case, eMAG1 should behavior as a legacy MAG for this session and PMIP
   specified routing mechanism shall be applied for the uplink traffic
   (i.e. no optimized routing), e.g. MN->eMAG1->E-LMA->common
   router->CN.

   Of course, if the correspondent node itself is a fixed node, same
   rules described above are also applicable.

5.2.  Routing Optimization Considerations when the CN is a Fixed Node

   As described above, if correspondent node is a fixed node, eMAG1 will
   behavior as a legacy MAG and no optimized routing is enabled.

   Most of correspondent nodes which are fixed nodes are deployed in a
   centralized manner in most deployment, 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
   complicate, to access operator's IP bearer network which is
   illustrated in figure 7.  If mechanism which providing optimized
   routing cannot be applied when correspondent node are fixed nodes of
   these kind, effect of this mechanism will be very limited.

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


   Figure7.  Correspondent Nodes are Fixed Nodes Cause Non-optimized
   Routing

   Refer to figure 7, it seems like that non-optimized routing (e.g.
   between MN1 and CDN) will be a problem for this deployment as
   discussed in [I-D DMM Problem Statement].  For purpose of eliminating
   non-optimized routing, one implementation is to replace those common
   access routers in figure 7 with routers which are implemented with
   Distributed Routing Function (DRF).  No Distributed Mobility Function
   (DMF) is needed, since nodes attached are all fixed nodes.

          ,-------.
        ,'         `-.



Luo & Liu               Expires January 30, 2014               [Page 15]


Internet-Draft          PMIP Based DMM Approaches              July 2013


       (  CDN\IDC\Web )-.                 _.----.
       (  Server      )  \       ,--_.--''       `-.
        \____________'   AR+DRF-'                   `-------.
    ,-----------.          /  -.                             \
   ; Fixed User  :       ,'     `-                            \
   : Equipments  ;---AR+DRF ----LMF                    eLMA    :
    `-----------'        \     ,-                              ;
                      AR+DRF--'              ,----.           ;
        ,-----------.   / `\              eMAG    `--.        ;
       ; Fixed User  : /     -------------' |          `-----'
       : Equipments  ;/                     |
        `-----------'                       |
                                            |
                                           MN1


   Figure 8.  Applying Optimized Routing when Correspondent Nodes are
   fixed nodes

   Additionally, one more LMF needs deployed as illustrated in figure 8.
   The responsibility of that LMF is to response any received PBRQ
   message with location of queried fixed node (e.g. IP address of one
   of those AR+DRF).  Method specified in section 4.2.2 may not be
   applicable, because PBRQ will be routed to one of those AR+DRF
   directly.  No response will be expected, except that the AR+DRF is
   also co-located with a LMF.

6.  Handoff between eMAG and MAG

   As illustrated in figure 1, ePMIP is deployed in PMIP domain (no
   clear boundary), and belongs to a same administrative domain, e.g. a
   same operator.  The mobile node which is initial registered with eLMA
   by attaching a eMAG may handoff to a legacy MAG and vice versa.  By
   supporting the handoff between eMAG and MAG , ePMIP can be deployed
   in manner of incremental when assuming PMIP is well deployed.

   As described above, eLMA is a legacy LMA implemented with LMF, and
   eMAG is a legacy MAG implemented DAF (DRF+DMF).  When a mobile node
   which attaches to an eMAG handoff to a legacy MAG, the legacy MAG
   will perform PMIP registration to the eLMA and establish a bi-
   directional tunnel with the eLMA.  In this case, PMIP routing
   mechanism will be applied (i.e. no routing optimization).  On the
   other hand, when a mobile node which attaches to a legacy MAG handoff
   to an eMAG, the eMAG will perform PMIP registration to the legacy LMA
   and establish a bi-directional tunnel with the legacy LMA.  In this
   case, PMIP routing mechanism will also be applied (i.e. no routing
   optimization).




Luo & Liu               Expires January 30, 2014               [Page 16]


Internet-Draft          PMIP Based DMM Approaches              July 2013


7.  Considerations for Other Implementation

   As described in section 3.1, ePMIP can be implemented in many ways.
   Section 3.1 also indicates one of those implementations, i.e.
   deploying LMF in legacy LMA, and DAF in legacy MAG.  This section
   considers one alternative implementation.

7.1.  One Alternative Implementation

   One alternative implementation is to deploy DAF in legacy LMA, and
   deploy LMF independently.  When multiple LMFs are deployed,
   interfaces between those LMFs are necessary as illustrated in figure
   10.

                 _.---------------------.
           ,---''       LMF2             `--- ,
         ,'       _..-''    ``-.._             ;
      ,-'        LMF1 --------- LMF3            \
     /                                           : Prefix ePMIP
    /  ( area1 )( area2 )( area3 )...( arean )   |     /
   |   (       )(       )(       )   (       )   ;    /         ( arean+1)
   :   ( eLMA1 )( eLMA2 )( eLMA3 )...( eLMAn ) BG+DRF ---       (        )
    \      |        |       |                  /      \         (   LMA  )
     `-----+.       | _.----+--ePIMP Area-----'        \             |
           | `------|'      |                                        |
           |        |       |                                        |
          MAG1     MAG2    MAG3                                     MAG
           |                |
          MN1              CN1


   Figure 10.  One Alternative Implementation of ePMIP

   For routing consideration, a clear boundary seems necessary if ePMIP
   takes this kind of implementation.  A set of IPv6 prefixes which are
   used for allocating HNP(es) or HoA(s) to mobile nodes should be
   assigned to ePMIP area and each LMA manages part of them.  The eLMAs
   don't announce any IPv6 prefix to routing system.  Instead, a border
   gateway implemented with DRF (BG+DRF) which is located at the
   boundary of this ePMIP area announces those set IPv6 prefix(es) to
   outside as illustrated in figure 10.

   The node inside ePMIP area could be a mobile node or a fixed node.
   When a correspondent node located outside of ePMIP area sends IP
   traffic to a node located inside ePMIP area, traffic will be routed
   to BG+DRF which announces the management of the prefix of the
   traffic's destination IP address.




Luo & Liu               Expires January 30, 2014               [Page 17]


Internet-Draft          PMIP Based DMM Approaches              July 2013


7.2.  Optimized Routing Consideration

   Consider that a mobile node (MN1) is initiated in ePMIP area and
   attaches to a legacy MAG, legacy PMIP registration procedures will be
   performed.  The MAG will select a local mobility anchor (e.g. eLMA1)
   for MN1 and send a PBU to it.  Note that, the LMA selected by the MAG
   is actually an eLMA.  MAGs cannot tell the distinguishes between LMAs
   and eLMAs.

   After successful PMIP registration, MN1 acquires its HNP(es) and
   eLMA1 manages a binding cache entry for MN1 as specified by legacy
   PMIP.  Further, eLMA1 (DRF) has to inform a corresponding LMF with
   the HNP(es) and location information of MN1 (i.e. IP address of eLMA1
   itself).  LMF will manage the mapping between HNP(es) and location.
   How to determine which LMF the eLMA1 (DRF) should inform, refer to
   section 7.4.

   Consider that correspondent node (CN1) of MN1 is also a mobile node
   and is located in same ePMIP area (refer to section 7.3 for other
   scenarios).

   Upon receiving uplink traffic from MN1 to CN1 via the bi-directional
   PMIP tunnel, eLMA1 (DRF) should determine whether it holds location
   information of CN1 locally.  If not, a corresponding LMF should be
   queried by eLMA1 (DRF), and the required location (e.g. IP address of
   eLMA3) should be stored by eLMA1 (DRF) locally.  Upon determining the
   location, eLMA1 (DRF) sets up a tunnel to eLMA3 (DRF) by using the
   location of CN1 as tunnel endpoint, and forwards uplink traffic to
   eLMA3 (DRF) directly.

   Upon movement of MN1, a PMIP handoff from pMAG to nMAG will be
   triggered.  [RFC6097] provides a mechanism for LMA discovery, and
   requires nMAG of a mobile node should discovery a same LMA with which
   the pMAG has discovered for that mobile node.  The nMAG in this draft
   does not have to discover a same eLMA (i.e. eLMA1) but a best eLMA
   (e.g. eLMA2) for MN1 and performs PMIP registration.  The
   implementation can take any method specified in [RFC6097] for
   discovering the best eLMA.

   The eLMA2 (DRF) should update LMF with new location information of
   MN1 (e.g. IP address of eLMA2 itself) and eLMA2 (DMF) should also
   inform eLMA1 with the new location.  The approaches are quite similar
   with those described in section 4.3.

7.3.  Correspondent Node Consideration

   The correspondent node may be located outside of ePMIP area (could be
   a mobile node or a fixed node).  In this case, the prefixes or IP



Luo & Liu               Expires January 30, 2014               [Page 18]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   address of CN are not managed by ePMIP.  Actually, the set of IPv6
   prefixes which are assigned to ePMIP can be configured in LMF.  In
   this case, when eLMA1 (DRF) queries LMF CN's location, the LMF will
   response with IP address of BG+DRF.  The routing will be: MN1 <-> MAG
   <-> eLMA <->BR+DRF <-> CN.

   In the case of the correspondent node is a fixed node and is located
   inside ePMIP area, it seems like that the traffic from CN to MN1
   cannot be routed correctly, because CN doesn't have any idea of MN1's
   location.

   A simple approach is to let BG+DRF also announce the set of prefixes
   which are assigned to ePMIP to routing system in ePMIP area.  In this
   case, traffic will be routed to BG+DRF and further forwarded by
   BG+DRF.  But it seems that the BG+DRF could be overloaded easily and
   routing will be no-optimal.

   Another approach is to deploy multiple routers implemented with DRF
   in ePMIP area and let them announce same set of prefix(es) which are
   assigned to ePMIP to routing system (as illustrated in figure 11).
   In this case, the anycast mechanism is used for attract traffic from
   CN and optimized routing is enabled: CN <->Access Router <->
   Router+DRF <-> eLMA <-> MAG <-> MN

        ,--------------
       /  CN             `------------.
     ,'    |                LMF2       `---.
    /      |          _..-''    ``-.._      `.
   ;     Access      LMF1 --------- LMF3      `.
   +     Router                                 `.
   |                                              \
   |         \   |   /  Prefix ePMIP  \   |   /    \
   |          \  |  /                  \  |  /      \
   :         router+DRF               router+DRF     :
    :         /  |  \                  /  |  \       |     Prefix ePMIP
    |        /   |   \                /   |   \      |     /
    |                                                |    /
    +      ( area1 )( area2 )( area3 )...( arean )  BG+DRF---
     \     (       )(       )(       )   (       )   |    \
      \    ( eLMA1 )( eLMA2 )( eLMA3 )...( eLMAn )   |     \
       ` --------------------------------------------;


   Figure 11.  Anycast Mechanism for Attracting Traffic From CN

7.4.  Location Management Consideration





Luo & Liu               Expires January 30, 2014               [Page 19]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   As illustrated in figure 11, multiple LMFs can be deployed in ePMIP
   area.  When a mobile node is registered with an eLMA, the eLMA (DRF)
   needs to update location of this mobile node in a corresponding LMF.
   And when eLMA (DRF) want to determine location information of a
   mobile node, it need to query a corresponding LMF.

   Interface between those LMFs is proposed in this draft.  One
   preferred LMF can be configured in every specific eLMAs (DRF).  If
   eLMA (DRF) need to update or query location of a mobile node (or
   correspondent node), it can always sends a corresponding message to
   that preferred LMF.  Upon receiving the message, that preferred LMF
   should determine which LMF is responsible for managing the location
   for that mobile (or correspondent node) and relay the message to that
   determined LMF.

   Many methods can be used by preferred LMF for determining to which
   LMF it should relay the message.  For example, Hash algorithm
   (hashing the HNP(es)), DHT algorithm and etc.

8.  Security Considerations

   This draft defines several new signaling messages among eMAGs and
   eLMAs for supporting Distributed Mobility Management.  Security
   considerations for those messages are considered in this section for
   two implementation cases discussed in this draft.

   For first implementation case, as described in section 3.1, deploying
   LMF in legacy LMA, and DAF in legacy MAG, respectively eLMA and eMAG.
   Basic assumption is that all those eMAGs and eLMAs belong to one same
   administrative domain (e.g. a same operator), other scenarios are out
   of scope of this draft.

   The function of signaling messages PBQR/PBQA between eMAG and eLMA is
   for acquiring location information of a specific mobile node (or a
   fixed node).  This draft uses the same security association mechanism
   which is defined in [RFC5213] to protect those PBQR\PBQA messages.
   The function of signaling messages PBCI/PBCA exchanged between eMAGs
   is for supporting mobile node's handoff when optimized routing has
   been established.  This is an essential feature for supporting
   Distributed Mobility Management.  The said PBCI/PBCA messages MUST be
   protected by using end-to-end security association(s) offering
   integrity and data origin authentication, the eMAGs is proposed to
   implement IPsec [RFC4301] or other equivalents for protecting
   PBCI\PBCA messages.  E.g. IPsec Encapsulating Security Payload (ESP,
   [RFC4303]) in transport mode with mandatory integrity protection
   could be used for protecting those signaling messages.





Luo & Liu               Expires January 30, 2014               [Page 20]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   Similar security considerations for protecting PBQR/PBQA and PBCI/
   PBCA messages which are described for the first implementation case
   above are also applied for the second implementation case which is
   described in section 7, i.e. deploying DAF in the legacy LMA to
   constitute eLMA, and deploying LMF independently.

9.  Difference with Localized Routing

   [I-D.ietf-netext-pmip-lr] (i.e. LR) allows mobile nodes attached to
   the same or different mobile access gateways to route traffic by
   using localized forwarding or a direct tunnel between the gateways.
   The core idea is to establish an optimized forwarding path between
   two mobile nodes.  Such localized communication enables offloading
   traffic from LMAs and from the core network to the edge.  Since
   traffic can be routed by MAGs directly, those MAGs can be considered
   as a kind of traffic anchor point.  In this point of view, LR could
   be a potential solution for Distributed Mobility Management taken MAG
   as mobile node's dynamic anchor.

   But LR cannot be used as a DMM solution directly, it still has some
   gaps, e.g. packet loss, scalability and etc.  LR does not consider
   solution for scenario when two mobile nodes are attached to different
   MAGs and registered with different LMAs (i.e. scenario A22 described
   in [RFC6279]), because PMIPv6 does not define any interface between
   LMAs.  But it is most likely that, in a real network, multiple LMAs
   are deployed.  Because deploying a single LMA in same administrative
   domain (e.g. a same operator) is prone to single point of failure and
   low performance due to bottleneck.  We can say that, a large part of
   MN-MN communications will fall into scenario A22.  In this case, if
   scenario A22 is not considered, the usage of LR will be limited.
   This draft considers inter-LMA communications which is one of the
   main differences from LR.

   In scenario when MN and CN attached to different MAGs but same LMA
   (i.e. scenario A21 described in section 5 of
   [I-D.ietf-netext-pmip-lr]) , if MN detaches from its current MAG and
   attaches to a new MAG the localized routing state needs to be re-
   established.  During this period packets from CN will arrive at the
   old MAG, this will result in packet loss.  The packet loss problem
   will be even more worse when MN handoffs from Scenario A12 to A22, in
   Scenario A22, neither LMA nor MAG has a means to determine and
   initiate LR , this can result in transient packet loss when routing
   switches between the localized path into the normal path through the
   LMAs as described in section 7 of [I-D.ietf-netext-pmip-lr].  Due to
   this limitation LR is not applicable for packet-loss-sensitive
   applications.  This draft considers this issue and can guarantee
   minimal packet loss.  This is another differences from LR.




Luo & Liu               Expires January 30, 2014               [Page 21]


Internet-Draft          PMIP Based DMM Approaches              July 2013


   MN and CN in LR MUST be PMIPv6 mobile nodes.  However, in real
   deployment scenarios, a large part of communications between MN and
   its CN involve accessing fixed node by MN (e.g. access a web server
   ).  As described in section 5.2 (figure 7), non-optimized routing
   could be a problem for MN accessing fixed node.  So if this scenario
   is not considered, the usage of LR will also be limited.  This draft
   considers the routing optimization between mobile node and fixed node
   which is one another difference from LR.

   In technical level, LR is established by utilizing Localized Routing
   Initiation (LRI) and Local Routing Acknowledgment (LRA) message
   between MAG and LMA.  LMA provides one MAG with IP address of another
   MAG, and this approach will lead to so called race condition
   situation when both mobile nodes move and attach to a new access
   router simultaneously (refer to last bullet in section 3.2 of
   [RFC6279]).  Solution specified in this draft utilize location
   information query mechanism to establish the optimized path which
   eliminates the race condition and also provides more flexibility in
   different deployment implementations(e.g. deploying LMF in LMA and
   DAF in MAG, deploying DAF in LMA and deploying LMF independently).

10.  IANA Considerations

   This document makes no request of IANA.

11.  References

11.1.  Normative References

   [I-D.ietf-netext-pmip-lr]
              Krishnan, S., Koodli , R., Loureiro, P., Wu, Q., and A.
              Dutta , "Localized Routing for Proxy Mobile IPv6", January
              2012.

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

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



Luo & Liu               Expires January 30, 2014               [Page 22]


Internet-Draft          PMIP Based DMM Approaches              July 2013


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

   [RFC6279]  Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6
              (PMIPv6) Localized Routing Problem Statement", RFC 6279,
              June 2011.

11.2.  Informative References

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

Authors' Addresses

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

   Email: luo.wen@zte.com.cn


   Juan Liu
   ZTE
   No.68, Zijinhua RD,Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Email: liu.juan45@zte.com.cn



















Luo & Liu               Expires January 30, 2014               [Page 23]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/