Internet DRAFT - draft-xue-dmm-routing-optimization

draft-xue-dmm-routing-optimization







DMM                                                               K. Xue
Internet-Draft                                                     L. Li
Intended status: Standards Track                                 P. Hong
Expires: December 22, 2013                                          USTC
                                                               P. McCann
                                                                  Huawei
                                                           June 20, 2013


                      Routing optimization in DMM
               draft-xue-dmm-routing-optimization-02.txt

Abstract

   This draft proposes a PMIP-based routing optimization method in
   distributed anchor architecture.  The anchor of the mobile node is
   able to communicate with the anchor of corresponding node directly
   using optimized routing.  In this draft, there are two modes for the
   setup of routing optimization: the direct mode and the relay mode.
   The difference between them lies in that whether the routing
   optimization is set up directly or under the assistance of a third
   anchor.  The situation that Communication Node(CN) is a fixed
   terminal or a content server is also considered and 3 solutions are
   provided correspondingly.  The method proposed in this draft can
   reduce the delay and save signaling overhead in the current scheme.

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 December 22, 2013.









Xue, et al.             Expires December 22, 2013               [Page 1]

Internet-Draft         Routing optimization in DMM             June 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
     2.1.  Conventions Used in This Document . . . . . . . . . . . .   4
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Motivations . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Long Routing in Current Distributed Anchor Scenario . . .   4
     3.2.  Signaling Overhead Analysis . . . . . . . . . . . . . . .   5
   4.  The Function of D-MAG . . . . . . . . . . . . . . . . . . . .   6
   5.  Overview of the Proposed Protocol . . . . . . . . . . . . . .   6
     5.1.  The Direct Mode . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  The Relay Mode  . . . . . . . . . . . . . . . . . . . . .   9
   6.  CN considerations . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  The Direct Mode . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  The Relay Mode  . . . . . . . . . . . . . . . . . . . . .  13
       6.2.1.  P-D-MAG as A Relay  . . . . . . . . . . . . . . . . .  13
       6.2.2.  F-D-MAG as A Relay  . . . . . . . . . . . . . . . . .  14
   7.  Message Format  . . . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  Enhanced Proxy Binding Update Message . . . . . . . . . .  16
     7.2.  Enhanced Proxy Binding Acknowledgement Message  . . . . .  17



Xue, et al.             Expires December 22, 2013               [Page 2]

Internet-Draft         Routing optimization in DMM             June 2013


     7.3.  Mobility option . . . . . . . . . . . . . . . . . . . . .  18
       7.3.1.  Corresponding node address option . . . . . . . . . .  18
       7.3.2.  D-MAG address option  . . . . . . . . . . . . . . . .  19
       7.3.3.  Former tunnels information option . . . . . . . . . .  20
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  22
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     11.1.  Normative Reference  . . . . . . . . . . . . . . . . . .  22
     11.2.  Informative Reference  . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   The original centralized mobility management methods (such as the
   Mobile IPv6, 3GPP EPS etc.) have many drawbacks including the long
   routing problem, non- optimal architecture, heavy signaling overhead
   etc.  Therefore, distributed mobility managements are discussed and
   studied widely.

   In the current research of distributed mobility management (DMM), the
   method that the anchor undertakes the role of both LMA and MAG
   simultaneously is called the fully distributed mobility management
   scheme.  The distributed anchor
   [I-D.bernardos-dmm-distributed-anchoring] is one of the fully
   distributed mobility management methods.  The distributed anchor
   means that the newly generated communication sessions are anchored by
   mobile node's current anchor.  For example, when the mobile node
   moves from one anchor to another anchor (handover), the communication
   sessions generated after the handover are anchored by the new anchor.

   Under the current distributed anchor schemes, when mobile node moves
   to a new anchor, the former flow is forwarded by the former anchor to
   the new anchor.  Therefore, the long routing problem still exists.
   In the existing work of PMIPv6 as [I-D.ietf-netext-pmip-lr], the
   communication between LMAs is not involved since it assumes the
   mobility management function should be accomplished under the
   centralized architecture.  However, in the distributed architecture
   aforementioned, each distributed anchor could be regarded as the LMA
   for the communication session generated on it.  Therefore, it is
   necessary to have communications between distributed anchors but
   current schemes in PMIPv6 do not support such scenario.  In this
   draft, we propose a routing optimization scheme in distributed anchor
   scenario based on PMIPv6 to solve the non-optimization routing
   problem in the current work.

2.  Conventions and Terminology




Xue, et al.             Expires December 22, 2013               [Page 3]

Internet-Draft         Routing optimization in DMM             June 2013


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

   The following terms are defined and used in this document:

   Distributed MAG (D-MAG).  It is the distributed anchor in our method
   and it provides mobility management function.

   First D-MAG (F-D-MAG).  It is the first hop D-MAG where the sessions
   firstly start.  F-D-MAG assigns IPv6 prefixes and provides mobility
   management function for the registered mobile node.

   Previous D-MAG (P-D-MAG).  It is the D-MAG that mobile node attaches
   before handover.

   New D-MAG (N-D-MAG).  It is the D-MAG that mobile node attaches
   currently.

   Enhanced Proxy Binding Update (ePBU).  It is the enhanced PBU
   designed for optimized routing tunnel setup, state update, etc.  It
   contains Routing Optimization Indicator (ROI) as a 2-bit state flag

   Enhanced Proxy Binding Acknowledge (ePBA).  It is the enhanced PBA
   designed for optimized routing tunnel setup, state update, etc.  It
   contains Routing Optimization Indicator (ROI) as a 2-bit state flag

3.  Motivations

3.1.  Long Routing in Current Distributed Anchor Scenario

   In current DMM approaches, when the mobile node moves to a new
   anchor, the communication session generated before MUST be forwarded
   to the new D-MAG by the original anchor.  Therefore, there is still a
   long routing problem in such schemes and it MAY bring in delay and
   jitter.  As Figure.1 shows, in the current approaches, when the
   mobile node (MN) moves from P-Anchor(the previous anchor) to
   N-Anchor(the new anchor), the communication session generated before
   handover (On P-Anchor) will be forwarded to the new anchor (N-Anchor
   in Figure.1) by the previous anchor (P-Anchor).  The problem would
   become more severe when the mobile node (MN) moves across multiple
   anchors with the original communication sessions still going.  It is
   because the distance between the original anchor and the new anchor
   MAY be rather long for a certain communication session.



Xue, et al.             Expires December 22, 2013               [Page 4]

Internet-Draft         Routing optimization in DMM             June 2013


                       +----------+    +----------+
                       |   CN     |    |   CN     |
                       |          |    |          |
                       +----/-----+    +----/-----+
                            |               |
                            | _,,,.-----..,,|
                          ,-|`              |``-.
                        /   | Core Network  |    \
                        \   |               |    /
                          '-|,              |_,-'
                Old session | ``''''----'''`|  New session
                            |               |
                            |               |
                       +----|-----+    +----------+
                       |    +-----------+         |
                       | P-Anchor |    || N-Anchor|
                       +----------+    +|---|-----+
                                        |   |
                                        |   |
                                       +------+
                         ---Move-->    |  MN  |
                                       +------+

             Figure 1: Data flow in the current DMM approaches


3.2.  Signaling Overhead Analysis

   In this section, the analysis of the signaling overhead by simply
   adopting current routing optimization schemes in PMIPv6 is given
   briefly.

   The routing optimization or local routing schemes in current PMIPv6
   MAY bring in much more signaling overhead when applied in the
   distributed anchor scenario.  The procedure of local routing is
   showed in Figure.2.  The LMA (Local Mobility Anchor) of MN sends
   routing optimization trigger to the LMA of CN to start the routing
   optimization.  The LMA of MN also needs to send the address of MN's
   MAG to the LMA of CN.  Afterwards, the LMA of CN sends routing
   optimization initiation command to the MAG of CN.  Then the MAG of CN
   sets up tunnel with the MAG of MN and the routing optimization is
   established [I-D.loureiro-netext-pmipv6-ro].


Xue, et al.             Expires December 22, 2013               [Page 5]

Internet-Draft         Routing optimization in DMM             June 2013

         +-------+ +-------+           +-------+        +-------+
         |MAG(MN)| |LMA(MN)|           |LMA(CN)|        |MAG(CN)|
         +---/---+ +---/---+           +---/---+        +---/---+
             |         |                   |                |
             |         |                   |                |
             |         |-1.RO Trigger----->|                |
             |         |                   |                |
             |         |                   |-2.RO Init----->|
             |         |                   |                |
             |<-------------3.RO Setup----------------------|
             |         |                   |                |
             |--------------4.RO Setup Ack----------------->|
             |         |                   |                |
             |         |                   |<-5.RO Init Ack-|
             |         |                   |                |
             |         |<-6.RO Trigger Ack-|                |
             |         |                   |                |

            Figure 2: The procedure of local routing in PMIPv6


   If it is adopted in the distributed anchor scenario, each anchor
   could be regarded as a LMA for the communication sessions generated
   on it.  The mobile node MAY have multiple communication sessions
   generated on different anchors.  When the mobile node moves, each
   anchor of MN needs to send messages to each CN's anchor.  Since the
   mobile node moves across multiple anchors, there would be multiple
   LMAs of MN and multiple LMAs of CN.  Therefore, the signaling
   overhead is large.  Secondly, these signalings are distributed across
   the Internet, so the delay would be longer for all of these messages.

4.  The Function of D-MAG

   D-MAG(Distributed MAG) is the distributed anchor in this draft.  It
   is in charge of the prefix allocation and the mobility management for
   a specific communication session generated on it.  It runs the
   functionalities of PMIP's MAG and LMA based on communication
   sessions.  It is a logical entity that could be integrated into the
   access router.

5.  Overview of the Proposed Protocol

   We propose two solutions to optimize the routing.  The first solution
   is the Direct Mode which means that the routing optimization is set
   up between the MN's D-MAG and CN's D-MAG by exchanging messages
   between the two entities directly.  The second solution is the Relay
   Mode which means that the routing optimization between the MN's D-MAG
   and CN's D-MAG SHALL be set up under the assistance of a third D-MAG.

   There are two stages in our protocol.  The first stage is the
   initiation of the routing optimization and the second stage is the
   maintenance of the routing optimization.  The initiation is the setup
   procedure of the routing optimization when mobile node moves to a new



Xue, et al.             Expires December 22, 2013               [Page 6]

Internet-Draft         Routing optimization in DMM             June 2013


   anchor from the first anchor.  The maintenance stage is the
   maintenance of routing optimization when the mobile node moves from
   the previous anchor to the new anchor after the setup of routing
   optimization.

5.1.  The Direct Mode

   (a)Initiation of Routing Optimization

   Figure 3 illustrates the initiation of routing optimization.  The
   original communication session for MN is generated in F-D-MAG and
   uses the prefix it assigns.  The F-D-MAG is the first hop D-MAG where
   the session firstly starts.

   When MN moves to its N-D-MAG, MN's N-D-MAG sends enhanced PBU (ePBU)
   with ROI (Routing Optimization Indicator) = 01 to its F-D-MAG to
   inform that the prefixes it assigns are still being used. ePBU is an
   enhanced proxy binding update (ePBU) with a 2-bit state flag ROI.
   This message is OPTIONAL because there is already a prefix lifetime
   extension message in the protocol of PMIPv6 as [RFC5213].

   MN's N-D-MAG sends ePBU with ROI= 10 to CN's F-D-MAG to query the
   address of CN's current D-MAG.  We MAY assume the address of CN's
   F-D-MAG is known to MN's N-D-MAG.  Even if it is unknown to MN's
   N-D-MAG, the ePBU to CN's F-D-MAG could be delivered in the following
   way.  Firstly, MN's D-MAG intercepts the first uplink packet of MN
   and gets the address of CN which is the destination address of the
   packet.  Then, it sends ePBU to the address of CN and the ePBU would
   be intercepted by CN's F-D-MAG.  Afterwards, CN's F-D-MAG would
   recognize the ePBU and sends back enhanced PBA (ePBA) which includes
   the address of CN's current D-MAG.

   MN's N-D-MAG sends ePBU with ROI=11 to CN's current D-MAG to execute
   the routing optimization.  Under this circumstance, a bi-directional
   tunnel will be established between MN's N-D-MAG and CN's D-MAG.


Xue, et al.             Expires December 22, 2013               [Page 7]

Internet-Draft         Routing optimization in DMM             June 2013

   +------+  +---------+    +---------++---------++---------+  +------+
   |  MN  |  | N-D-MAG |    | F-D-MAG || F-D-MAG ||  D-MAG  |  |  CN  |
   |      |  |  (MN)   |    |  (MN)   ||  (CN)   ||  (CN)   |  |      |
   +--/---+  +----/----+    +----/----++----/----++----/----+  +--/---+
      |           |              |          |          |          |
      |<-1.Attach-|              |          |          |          |
      |  /RS      |              |          |          |          |
      |    2.Registration        |          |          |          |
      |           |              |          |          |          |
      |           |-3.ePBU(ROI)->|          |          |          |
      |           |              |          |          |          |
      |           |<-4.ePBA(ROI)-|          |          |          |
      |           |              |          |          |          |
      |           |-----5.ePBU(ROI)-------->|          |          |
      |           |              |          |          |          |
      |           |<----6.ePBA(ROI)---------|          |          |
      |           |              |          |          |          |
      |           |-----------7.ePBU(ROI)------------->|          |
      |           |              |          |          |          |
      |           |<----------8.ePBA(ROI)--------------|          |
      |           |              |          |          |          |
      |<-9.RA-----|              |          |          |          |
      |           |              |          |          |          |
      |<-10A.IP-->|<---------10B.IP Packet------------>|<-10A.IP->|
      |  packet   |              |          |          |  packet  |


          Figure 3: The initiation of routing optimization for DM


   (b)Maintenance of routing optimization

   Figure 4 illustrates procedure of the maintenance for routing
   optimization

   When MN moves from previous D-MAG(P-D-MAG) to another new D-MAG
   (N-D-MAG in Figure 4), N-D-MAG sends ePBU with ROI = 01 to F-D-MAG in
   order to announce the prefixes that F-D-MAG assigns are still being
   used.  It is also OPTIONAL and the reason is the same with that in
   section 5.1(a).

   N-D-MAG sends ePBU with ROI=00 to P-D-MAG to request former tunnel
   information on P-D-MAG.  The tunnel information contains all the
   addresses of CNs' current D-MAGs.  P-D-MAG sends back ePBA with
   ROI=00 which includes the former tunnel information.  The mobile node
   MAY move across multiple D-MAGs, therefore, it could have multiple
   routing optimization tunnels on P-D-MAG.  The information of all the
   tunnels could be obtained through one exchange of message (message 6
   and 7 in Figure 4).  In this way, the signaling overhead mentioned in
   Section 3.2 can be reduced.  The former tunnels on P-D-MAG could be
   deleted explicitly through the exchange of ePBU/ePBA between N-D-MAG
   and P-D-MAG, or they would be deleted upon timer expiration.

   Then N-D-MAG of MN sends ePBU with ROI=11 to each CN's D-MAG of CN to
   maintain routing optimization.  Under this circumstance, a bi-
   directional tunnel would be established between the N-D-MAG(MN) and
   each D-MAG(CN).  Consequently, the routing optimization could be
   continued.





Xue, et al.             Expires December 22, 2013               [Page 8]

Internet-Draft         Routing optimization in DMM             June 2013


   +------+  +---------+    +---------++---------++---------+  +------+
   |  MN  |  | N-D-MAG |    | F-D-MAG || P-D-MAG ||  D-MAG  |  |  CN  |
   |      |  |  (MN)   |    |  (MN)   ||  (MN)   ||  (CN)   |  |      |
   +--/---+  +----/----+    +----/----++----/----++----/----+  +--/---+
      |<----------1A.IP packet------------->|<-1B.IP-->|<-1C.IP-->|
      |<-2.Attach-|              |          |  packet  |  packet  |
      |  /RS      |              |          |          |          |
      |    3.Registration        |          |          |          |
      |           |              |          |          |          |
      |           |-4.ePBU(ROI)->|          |          |          |
      |           |              |          |          |          |
      |           |<-5.ePBA(ROI)-|          |          |          |
      |           |              |          |          |          |
      |           |-----6.ePBU(ROI)-------->|          |          |
      |           |              |          |          |          |
      |           |<----7.ePBA(ROI)---------|          |          |
      |           |              |          |          |          |
      |           |-----------8.ePBU(ROI)------------->|          |
      |           |              |          |          |          |
      |           |<----------9.ePBA(ROI)--------------|          |
      |           |              |          |          |          |
      |<-10.RA----|              |          |          |          |
      |           |              |          |          |          |
      |<-11A.IP-->|<---------11B.IP packet------------>|<-11A.IP->|
      |  packet   |              |          |          |  packet  |



     Figure 4: The maintenance of routing optimization for direct mode


5.2.  The Relay Mode

   (a)Initiation of routing optimization

   In relay mode, the initiation of routing optimization is the same
   with that in the direct mode described in section 5.1(a).

   (b)Maintenance of routing optimization

   Figure 5 illustrates the procedure of maintenance stage for relay
   mode.


Xue, et al.             Expires December 22, 2013               [Page 9]

Internet-Draft         Routing optimization in DMM             June 2013

    +------+  +---------+    +---------++---------++---------+  +-----+
    |  MN  |  | N-D-MAG |    | F-D-MAG || P-D-MAG ||  D-MAG  |  |  CN |
    |      |  |  (MN)   |    |  (MN)   ||  (MN)   ||  (CN)   |  |     |
    +--/---+  +----/----+    +----/----++----/----++----/----+  +--/--+
       |<----------1A.IP packet------------->|<-1B.IP-->|<-1C.IP-->|
       |<-2.Attach-|              |          |  packet  |  packet  |
       |  /RS      |              |          |          |          |
       |    3.Registration        |          |          |          |
       |           |              |          |          |          |
       |           |-4.ePBU(ROI)->|          |          |          |
       |           |              |          |          |          |
       |           |<-5.ePBA(ROI)-|          |          |          |
       |           |              |          |          |          |
       |           |-----6.ePBU(ROI)-------->|          |          |
       |           |              |          |-7.ePBU-->|          |
       |           |              |          |  (ROI)   |          |
       |           |              |          |<-8.ePBA--|          |
       |           |              |          |  (ROI)   |          |
       |           |<----9.ePBA(ROI)---------|          |          |
       |           |              |          |          |          |
       |<-10.RA----|              |          |          |          |
       |           |              |          |          |          |
       |<-11A.IP-->|<---------11B.IP Packet------------>|<-11A.IP->|
       |  packet   |              |          |          |  packet  |


     Figure 5: The maintenance of routing optimization for relay mode


   When MN moves from previous D-MAG(P-D-MAG) to another new
   D-MAG(N-D-MAG), namely the N-D-MAG in Figure 5, N-D-MAG sends ePBU
   with ROI = 01 to F-D-MAG in order to announce the prefixes that
   F-D-MAG assigns are still being used.  It is also OPTIONAL and the
   reason is the same with that in section 5.1(a).

   N-D-MAG of MN sends ePBU with ROI=00 to P-D-MAG of MN to request the
   context transfer of routing optimization.

   P-D-MAG of MN sends ePBU with ROI=11 to each D-MAG of CN to maintain
   routing optimization.  P-D-MAG of MN works as a relay for the request
   of routing optimization maintenance.

   Finally, P-D-MAG of MN sends back the ePBA to MN's N-D-MAG.  The ePBA
   contains the address of CN's D-MAG.  Therefore, the data could be
   transmitted using optimized routing.











Xue, et al.             Expires December 22, 2013              [Page 10]

Internet-Draft         Routing optimization in DMM             June 2013


   When there are multiple tunnels established in the P-D-MAG, only one
   pair of ePBU/ePBA (message 6 and 9) exchange between the N-D-MAG (MN)
   and P-D-MAG (MN) is needed to acquire all the tunnel information.  In
   this way, we save the signaling overhead.  Besides, the message
   querying for the tunnel information from N-D-MAG to P-D-MAG does not
   need to be delivered through the Internet, which would reduce the
   signaling delay than querying from the F-D-MAG of CN over the
   Internet.

6.  CN considerations

   CN could also be a fixed terminal or a content server and it is
   capable to set up tunnels with the MN's D-MAG.  For such CN, we also
   provide two modes, the direct mode and the relay mode.  Likewise,
   there are also two stages.  The first one is the initiation stage and
   the other one is the maintenance stage.  This consideration requires
   CN to support the ability of tunnel setup like exchanging message
   with D-MAG.

6.1.  The Direct Mode

   (a) Initiation of routing optimization

               +------+  +---------+    +---------+ +-----+
               |  MN  |  | N-D-MAG |    | F-D-MAG | |  CN |
               |      |  |  (MN)   |    |  (MN)   | |     |
               +--/---+  +----/----+    +----/----+ +--/--+
                  |           |              |         |
                  |<-1.Attach-|              |         |
                  |  /RS      |              |         |
                  |    2.Registration        |         |
                  |           |              |         |
                  |           |-3.ePBU(ROI)->|         |
                  |           |              |         |
                  |           |<-4.ePBA(ROI)-|         |
                  |           |              |         |
                  |           |-----5.ePBU(ROI)------->|
                  |           |              |         |
                  |           |<----6.ePBA(ROI)--------|
                  |           |              |         |
                  |<-7.RA-----|              |         |
                  |           |              |         |
                  |<--8A.IP-->|<---8B.IP packet------->|
                  |  packet   |              |         |


              Figure 6: The initiation stage for direct mode




Xue, et al.             Expires December 22, 2013              [Page 11]

Internet-Draft         Routing optimization in DMM             June 2013


   Figure 6 illustrates the initiation stage for these special CNs in
   the direct mode.

   The original session is generated in F-D-MAG and uses the prefixes it
   assigns.  When MN moves, N-D-MAG sends ePBU (set ROI = 01) to F-D-MAG
   to inform that the prefixes it assigns are still being used.  This
   step is optional and the reason is the same with that in section
   5.1(a).

   N-D-MAG sends ePBU (set ROI = 11) to all CNs to inform of the
   execution of routing optimization.  Under this circumstance, a bi-
   directional tunnel will be established between N-D-MAG and CN.

   (b) Maintenance of routing optimization

         +------+  +---------+    +---------++---------+  +-----+
         |  MN  |  | N-D-MAG |    | F-D-MAG || P-D-MAG |  |  CN |
         |      |  |  (MN)   |    |  (MN)   ||  (MN)   |  |     |
         +--/---+  +----/----+    +----/----++----/----+  +--/--+
            |<----------1A.IP packet------------->|<-1B.IP-->|
            |<-2.Attach-|              |          |  packet  |
            |  /RS      |              |          |          |
            |    3.Registration        |          |          |
            |           |              |          |          |
            |           |-4.ePBU(ROI)->|          |          |
            |           |              |          |          |
            |           |<-5.ePBA(ROI)-|          |          |
            |           |              |          |          |
            |           |-----6.ePBU(ROI)-------->|          |
            |           |              |          |          |
            |           |<----7.ePBA(ROI)---------|          |
            |           |              |          |          |
            |           |----------8.ePBU(ROI)-------------->|
            |           |<---------9.ePBA(ROI)---------------|
            |<-10.RA----|              |          |          |
            |           |              |          |          |
            |<-11A.IP-->|<---------11B.IP Packet------------>|
            |  packet   |              |          |          |


              Figure 7: The maintenance stage for direct mode


   Figure 7 illustrates the maintenance stage for these special CNs in
   direct mode.

   The original session is generated in F-D-MAG and uses the prefixes
   F-D-MAG assigns.



Xue, et al.             Expires December 22, 2013              [Page 12]

Internet-Draft         Routing optimization in DMM             June 2013


   When MN moves from P-D-MAG to N-D-MAG, N-D-MAG sends ePBU (set ROI =
   01) to F-D-MAG to inform that the prefixes it assigns are still being
   used.  This step is optional and the reason is the same with that in
   section 5.1(a).

   N-D-MAG optionally sends ePBU (set ROI = 00) to P-D-MAG to delete all
   the former tunnels related to that MN explicitly.  For multiple
   tunnels related to the MN&#65292;only one pair of ePBU/ePBA is
   required.

   N-D-MAG sends ePBU (set ROI = 11) to all CNs to inform of the
   execution of routing optimization.  Under this circumstance, a bi-
   directional tunnel will be established between N-D-MAG and CNs.

6.2.  The Relay Mode

   There are two types of relays, the first type is the P-D-MAG relay
   and the other one is the F-D-MAG relay.  The difference lies in that
   the routing optimization request is relayed by different D-MAGs.

6.2.1.  P-D-MAG as A Relay

         +------+  +---------+    +---------++---------+  +-----+
         |  MN  |  | N-D-MAG |    | F-D-MAG || P-D-MAG |  |  CN |
         |      |  |  (MN)   |    |  (MN)   ||  (MN)   |  |     |
         +--/---+  +----/----+    +----/----++----/----+  +--/--+
            |<----------1A.IP packet------------->|<-1B.IP-->|
            |<-2.Attach-|              |          |  packet  |
            |  /RS      |              |          |          |
            |    3.Registration        |          |          |
            |           |              |          |          |
            |           |-4.ePBU(ROI)->|          |          |
            |           |              |          |          |
            |           |<-5.ePBA(ROI)-|          |          |
            |           |              |          |          |
            |           |-----6.ePBU(ROI)-------->|          |
            |           |              |          |-7.ePBU-->|
            |           |              |          |  (ROI)   |
            |           |              |          |          |
            |           |              |          |<-8.ePBA--|
            |           |<----9.ePBA(ROI)---------|  (ROI)   |
            |<-10.RA----|              |          |          |
            |           |              |          |          |
            |<-11A.IP-->|<---------11B.IP Packet------------>|
            |  packet   |              |          |          |






Xue, et al.             Expires December 22, 2013              [Page 13]

Internet-Draft         Routing optimization in DMM             June 2013


            Figure 8: The maintenance stage for P-D-MAG relay.


   Like the relay mode described in section 5.2, the P-D-MAG works as a
   relay in the stage of routing optimization maintenance.

   (a) Initiation of routing optimization

   The initiation stage is the same with that in direct mode of section
   6.1(a).

   (b) Maintenance of routing optimization

   Figure 8 illustrates the procedure of maintenance stage for P-D-MAG
   relay.

   When MN moves, N-D-MAG sends ePBU with ROI=01 to F-D-MAG to inform
   that the prefixes it assigns are still being used.  This step is
   optional and the reason is the same with that in section 5.1(a).

   N-D-MAG sends ePBU to P-D-MAG with ROI=00 to request the transferring
   of former tunnels.  P-D-MAG sends ePBU with ROI = 11 to CNs to inform
   of the execution of routing optimization.  The address of N-D-MAG is
   included in this ePBU (message 7).  In this way, P-D-MAG works as a
   relay.  P-D-MAG deletes the former tunnels and sends ePBA with ROI =
   11 back to N-D-MAG.  Under this circumstance, a bi-directional tunnel
   will be established between N-D-MAG and CNs and data is transmitted
   in optimized routing.

6.2.2.  F-D-MAG as A Relay

   In this section, the F-D-MAG works as the relay for both the
   initiation and maintenance stage of routing optimization.

   (a) Initiation of routing optimization


Xue, et al.             Expires December 22, 2013              [Page 14]

Internet-Draft         Routing optimization in DMM             June 2013

               +------+  +---------+    +---------+ +-----+
               |  MN  |  | N-D-MAG |    | F-D-MAG | |  CN |
               |      |  |  (MN)   |    |  (MN)   | |     |
               +--/---+  +----/----+    +----/----+ +--/--+
                  |           |              |         |
                  |<-1.Attach-|              |         |
                  |  /RS      |              |         |
                  |    2.Registration        |         |
                  |           |-3.ePBU(ROI)->|         |
                  |           |              |         |
                  |           |              |-4.ePBU->|
                  |           |              |  (ROI)  |
                  |           |              |         |
                  |           |              |<-5.ePBA-|
                  |           |<-6.ePBA(ROI)-|  (ROI)  |
                  |<-7.RA-----|              |         |
                  |           |              |         |
                  |<--8A.IP-->|<---8B.IP packet------->|
                  |  packet   |              |         |



              Figure 9: The initiation stage of F-D-MAG relay


   Figure 9 illustrates the initiation stage of F-D-MAG relay.

   The original session is generated in F-D-MAG and uses the prefixes
   F-D-MAG assigns.  When MN moves, N-D-MAG sends ePBU with ROI = 01 to
   F-D-MAG to inform that the prefixes it assigns are still being used
   and that the Routing Optimization Communication mode is used.

   F-D-MAG sends ePBU with set ROI = 11 to CN to inform the execution of
   routing optimization.  In this message (message 4), it tells CN the
   address of N-D-MAG which is the new care of address of MN.  In this
   way, F-D-MAG works as a relay for the request of routing optimization
   for N-D-MAG.  Afterwards, the data could be transmitted between
   N-D-MAG and CN using optimized routing.

   (b) Maintenance of routing optimization

   Figure 10 illustrates the maintenance stage when F-D-MAG works as a
   relay.  When MN moves from P-D-MAG to N-D-MAG, N-D-MAG sends ePBU
   with ROI =01 to F-D-MAG to inform that the prefixes it assigns are
   still being used and inform to keep using the Routing Optimization
   Communication mode.



Xue, et al.             Expires December 22, 2013              [Page 15]

Internet-Draft         Routing optimization in DMM             June 2013

         +------+  +---------+    +---------++---------+  +-----+
         |  MN  |  | N-D-MAG |    | F-D-MAG || P-D-MAG |  |  CN |
         |      |  |  (MN)   |    |  (MN)   ||  (MN)   |  |     |
         +--/---+  +----/----+    +----/----++----/----+  +--/--+
            |<----------1A.IP packet------------->|<-1B.IP-->|
            |<-2.Attach-|              |          |  packet  |
            |  /RS      |              |          |          |
            |    3.Registration        |          |          |
            |           |-4.ePBU(ROI)->|          |          |
            |           |              |----5.ePBU(ROI)----->|
            |           |              |<---6.ePBA(ROI)------|
            |           |<-7.ePBA(ROI)-|          |          |
            |           |              |          |          |
            |<-10.RA----|              |          |          |
            |           |-----9.ePBU(ROI)-------->|          |
            |           |<---10.ePBA(ROI)---------|          |
            |           |              |          |          |
            |           |              |          |          |
            |<-11A.IP-->|<---------11B.IP Packet------------>|
            |  packet   |              |          |          |


            Figure 10: The maintenance stage for F-D-MAG relay


   F-D-MAG sends ePBU with set ROI = 11 to CN to inform the execution of
   routing optimization.  In this message (message 5), it tells CN the
   address of N-D-MAG which is the new care of address of MN.  In this
   way, F-D-MAG works as a relay for the request of routing optimization
   for N-D-MAG.

   N-D-MAG optionally informs P-D-MAG to delete the former tunnel
   explicitly or wait upon timer expiration.  For multiple sessions
   related to the MN&#65292;only one pair of ePBU/ePBA is required.  So
   it MAY save the signaling overhead.

7.  Message Format

7.1.  Enhanced Proxy Binding Update Message

      0               1               2               3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |            Sequence #         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|H|L|K|M|R|P|ROI|  Reserved   |            Lifetime           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     .                                                               .

     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   The enhanced PBU (ePBU) is the original proxy binding update added
   with 2-bit ROI state flag.

   ROI:



Xue, et al.             Expires December 22, 2013              [Page 16]

Internet-Draft         Routing optimization in DMM             June 2013


   2-bit state flag.

   Mobility options:

   A variable-length field of such length that the complete Mobility
   Header is an integer multiple of 8 octets long.  This field contains
   zero or more TLV-encoded mobility options.  The encoding and format
   of defined options are described in Section 6.2 of [RFC6275].  The
   distributed mobile access gateway MUST ignore and skip any options
   that it does not understand.

   As per this specification, the following mobility options are valid
   in an Enhanced Proxy Binding Update message.  These options can be
   present in the message in any order.  There cannot be more than one
   instance of any of the following options:

   Corresponding node's address option

   D-MAG address option

   Former tunnels information option

7.2.  Enhanced Proxy Binding Acknowledgement Message

   The enhanced PBA (ePBA) is the original proxy binding acknowledgement
   added with 2-bit ROI state flag.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |   Status      |K|R|P|ROI| Rev |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Sequence #            |           Lifetime            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   ROI:

   2-bit state flag.

   Mobility options:



Xue, et al.             Expires December 22, 2013              [Page 17]

Internet-Draft         Routing optimization in DMM             June 2013


   A variable-length field of such length that the complete Mobility
   Header is an integer multiple of 8 octets long.  This field contains
   zero or more TLV-encoded mobility options.  The encoding and format
   of defined options are described in Section 6.2 of [RFC6275].  The
   distributed mobile access gateway MUST ignore and skip any options
   that it does not understand.

   As per this specification, the following mobility options are valid
   in an Enhanced Proxy Binding Acknowledgement message.  These options
   can be present in the message in any order.  There cannot be more
   than one instance of any of the following options:

   Corresponding node address option

   D-MAG address option

   Former tunnels information option

7.3.  Mobility option

7.3.1.  Corresponding node address option

   A new option, corresponding node address option is defined for use
   with the Enhanced Proxy Binding Update and Enhanced Proxy Binding
   Acknowledgement messages exchanged between the distributed mobile
   access gateways.  This option is used for exchanging the
   corresponding node's address.

   The format of the corresponding node address option is shown below.
   Based on the size of the identifier, the option MUST be aligned
   appropriately, as per mobility option alignment requirements
   specified in [RFC6275].

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |   Type        |    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                  Corresponding Node's Address                 +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Type:





Xue, et al.             Expires December 22, 2013              [Page 18]

Internet-Draft         Routing optimization in DMM             June 2013


   Approval of new corresponding node address option type value is to be
   made through IANA Expert Review.

   Length:

   8-bit unsigned integer, representing the length in octets of the
   mobility option, not including the Option Type and Option Length
   fields.

   Corresponding Node's Address:

   A variable length field containing the corresponding node's address.

7.3.2.  D-MAG address option

   A new option, D-MAG address option is defined for use with the
   Enhanced Proxy Binding Acknowledgement messages exchanged between the
   distributed mobile access gateways.  This option is used for
   exchanging current D-MAG address of the corresponding node.

   The format of the D-MAG address option is shown below.  Based on the
   size of the identifier, the option MUST be aligned appropriately, as
   per mobility option alignment requirements specified in [RFC6275].

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |   Type        |    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                  D-MAG's Address                              +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Type:

   Approval of new D-MAG address option value is to be made through IANA
   Expert Review.

   Length:

   8-bit unsigned integer, representing the length in octets of the
   mobility option, not including the Option Type and Option Length
   fields.

   D-MAG's Address:



Xue, et al.             Expires December 22, 2013              [Page 19]

Internet-Draft         Routing optimization in DMM             June 2013


   A variable length field containing the D-MAG's address.

7.3.3.  Former tunnels information option

   A new option, former tunnels information option is defined for use
   with the Enhanced Proxy Binding Update and Enhanced Proxy Binding
   Acknowledgement messages exchanged between the distributed mobile
   access gateways.  This option is used for exchanging the information
   of former tunnels.

   The format of the former tunnels information option is shown below.
   Based on the size of the identifier, the option MUST be aligned
   appropriately, as per mobility option alignment requirements
   specified in [RFC6275].

   Type:

   Approval of former tunnels information option type value is to be
   made through IANA Expert Review.

   Length:

   8-bit unsigned integer, representing the length in octets of the
   mobility option, not including the Option Type and Option Length
   fields.  This field can also indicate the number of former tunnels
   listed in the option.

   The Destination Address of The Xth Tunnel:

   It indicates the address of the Xth tunnel.

   The SPI value of The Xth Tunnel:

   It indicates the SPI value of the Xth tunnel.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |   Type        |    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          The Destination Address of The 1st Tunnel            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               The SPI value of The 1st Tunnel                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          The Destination Address of The 2nd Tunnel            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               The SPI value of The 2nd Tunnel                 |



Xue, et al.             Expires December 22, 2013              [Page 20]

Internet-Draft         Routing optimization in DMM             June 2013


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         .......                               |
     .                         .......                               .
     .                         .......                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



8.  Security Considerations

   Security threats for routing optimization in network-based
   distributed mobility management comprise the danger of unauthorized
   set up or redirect of an established forwarding path by a malicious
   node.  Signaling messages of this protocol between D-MAGs must be
   authenticated by means of IPsec [RFC4301].

   Protection of signaling messages between D-MAGs uses the mechanisms
   of Encapsulating Security Payload (ESP) [RFC4301] in transport mode
   with mandatory data origin authentication by means of a non-null
   payload authentication algorithm.  The use of encryption is optional.
   In particular, if the network which interconnects two D-MAGs is not
   trusted, the use of encryption is recommended to support
   confidentiality protection between MAGs respectively.

9.  IANA Considerations

   This document defines three new Mobility Header options, the
   Corresponding Node Address option, the D-MAG Address option, the
   Former Tunnels Information option.  These options are described in
   Section 7.3 The new Mobility Header Type values for the ePBU/ePBA
   should be allocated and the approval of new type values is to be made
   through IANA Expert Review.

   The Corresponding Node Address option, defined in Section 7.3.1, is
   used to exchange Corresponding Node Address between distributed
   mobile access gateways.  The approval of new type value is to be made
   through IANA Expert Review.

   The D-MAG Address option, defined in Section 7.3.2, is used to
   exchange the current D-MAG address of the corresponding node between
   distributed mobile access gateways.  The approval of new type value
   is to be made through IANA Expert Review.

   The Former Tunnels Information option, defined in Section 7.3.3, is
   used to exchange Former Tunnels Information between distributed
   mobile access gateways.  The approval of new type value is to be made
   through IANA Expert Review.



Xue, et al.             Expires December 22, 2013              [Page 21]

Internet-Draft         Routing optimization in DMM             June 2013


   This document also creates a 2-bit status flag in the Proxy Binding
   Update/Proxy Binding Acknowledgement message called the "Routing
   Optimization Indicator" in Section 7.

10.  Acknowledgements

   The authors would like to specially thank Peter J. McCann for his
   thorough reviews of this document.The authors would also like to
   thank Lei Zhu, Ning He and Dan Ni for all the discussions on this
   topic.

11.  References

11.1.  Normative Reference

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

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

11.2.  Informative Reference

   [I-D.bernardos-dmm-distributed-anchoring]
              Bernardos, C. and J. Zuniga, "PMIPv6-based distributed
              anchoring", draft-bernardos-dmm-distributed-anchoring-02
              (work in progress), April 2013.

   [I-D.chan-dmm-architecture]
              Chan, A., "A architecture of distributed mobility
              management using mip and pmip", draft-chan-dmm-
              architecture-00 (work in progress), March 2012.

   [I-D.ietf-netext-pmip-lr]
              Krishnan, S., Koodli, R., Loureiro, P., Wu, W., and A.
              Dutta, "Localized Routing for Proxy Mobile IPv6", draft-
              ietf-netext-pmip-lr-10 (work in progress), May 2012.

   [I-D.loureiro-netext-pmipv6-ro]
              Loureiro, P. and M. Liebsch, "Proxy Mobile IPv6 Localized
              Routing", draft-loureiro-netext-pmipv6-ro-02 (work in
              progress), March 2010.

Authors' Addresses




Xue, et al.             Expires December 22, 2013              [Page 22]

Internet-Draft         Routing optimization in DMM             June 2013


   Kaiping Xue
   USTC
   Room 305, EEIS Department, USTC West Campus
   Shushan District, Hefei , Anhui   230027
   P. R. China

   Phone: +86-551-3601334
   Email: kpxue@ustc.edu.cn


   Lin Li
   USTC
   Room 305, EEIS Department, USTC West Campus
   Shushan District, Hefei , Anhui   230027
   P. R. China

   Phone: +86-551-3601334
   Email: linl@mail.ustc.edu.cn


   Peilin Hong
   USTC
   Room 305, EEIS Department, USTC West Campus
   Shushan Distric, Hefei , Anhui   230027
   P. R. China

   Phone: +86-551-3601334
   Email: plhong@ustc.edu.cn


   Peter J. McCann
   Huawei
   400 Crossing Blvd, 2nd Floor
   Bridgewater , NJ   08807
   USA

   Phone: +1-908-541-3563
   Email: peter.mccann@huawei.com













Xue, et al.             Expires December 22, 2013              [Page 23]