Internet DRAFT - draft-ma-mext-dmm-romip

draft-ma-mext-dmm-romip






Mobility EXTensions for IPv6                                Zhengming Ma
Internet-Draft                                                 Xun Zhang
Intended status: Standards Track                  SUN YAT-SEN UNIVERSITY
Expires: July 7, 2012                                    January 4, 2012


     A Route Optimization solution support for Distributed Mobility
                               Management
                     draft-ma-mext-dmm-romip-00.txt

Abstract

   The mobile users and their traffic demands are expected to be ever-
   increasing in future years, and this growth will impose a limitation
   for deploying current mobility management schemes that are
   intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6.  This
   evolution in user traffic demand can be tackled by a different
   approach for IP mobility, called Distributed Mobility Management,
   which is focusing on moving the mobility anchors from the core
   network and pushing them closer to the users, at the edge of the
   network.  Following this idea, in our proposal, the central anchor is
   being deployed in the access router of the mobile node(MN).  That is,
   the first elements that provide IP connectivity to a set of MNs are
   also the mobility managers for those MNs.  In the following, we will
   call MAAR (Mobility anchor and Access Router).

   This draft strictly abides by the three principles:

   (1) The MN doesn't participate in any mobility-related signaling.MAAR
   and AAA are responsible for managing IP mobility on behalf of the
   host.

   (2) The MN's movement is transparent to the communication node
   (CN).The Home Address (HoA) and Care-of address (CoA) are not for
   users but for specific sessions in this draft.A MN initiates a
   session by using the MN's address assigned by a MAAR which the MN is
   registered as the HoA for this session.The MN's address assigned by a
   new MAAR which the MN moves to its access link as the CoA for the
   session.

   (3) The MN can directly forward packages to the CN and the packages
   don't need to pass the home mobility anchor.  It can reduce the heavy
   burdens on home mobility anchor and maintain all the continuity of
   the conversation.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the



Zhengming Ma & Xun Zhang  Expires July 7, 2012                  [Page 1]

Internet-Draft        A RO solution support for DMM         January 2012


   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 July 7, 2012.

Copyright Notice

   Copyright (c) 2012 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.























Zhengming Ma & Xun Zhang  Expires July 7, 2012                  [Page 2]

Internet-Draft        A RO solution support for DMM         January 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
     2.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  MAAR Operation . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Operation between MAAR and AAA . . . . . . . . . . . . . .  6
     3.2.  The assumptions about a session  . . . . . . . . . . . . .  6
     3.3.  Binding list in MAAR . . . . . . . . . . . . . . . . . . .  7
     3.4.  Operation between MAARs  . . . . . . . . . . . . . . . . .  7
   4.  Description of the solution  . . . . . . . . . . . . . . . . .  8
   5.  Forwarding Considerations  . . . . . . . . . . . . . . . . . . 10
     5.1.  Forwarding Packets Sent by the Mobile Node . . . . . . . . 10
     5.2.  Forwarding Packets to the Mobile Node  . . . . . . . . . . 12
   6.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  sDBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.2.  sDBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.3.  dDBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.4.  dDBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

























Zhengming Ma & Xun Zhang  Expires July 7, 2012                  [Page 3]

Internet-Draft        A RO solution support for DMM         January 2012


1.  Introduction

   Mobile IPv6 [RFC6275] requires client functionality in the IPv6 stack
   of a mobile node.  Exchange of signaling messages between the mobile
   node and home agent enables the creation and maintenance of a binding
   between the mobile node's home address and its care-of address.
   Mobility as specified in requires the IP host to send IP mobility
   management signaling messages to the home agent, which is located in
   the network.

   Proxy Mobile IPv6 [RFC5213] is a network-based mobility to solving
   the IP mobility challenge.  It is possible to support mobility for
   IPv6 nodes without host involvement by extending Mobile IPv6
   signaling messages between a network node and a home agent.  In order
   to facilitate such network-based mobility, the PMIPv6 protocol
   defines a Mobile Access Gateway (MAG), which acts as a proxy for the
   Mobile IPv6 signaling, and the Local Mobility Anchor (LMA) which acts
   similar to a Home Agent.  The LMA and the MAG establish a
   bidirectional tunnel for forwarding all data traffic belonging to the
   Mobile Nodes.

   Both the Mobile IPv6 and Proxy Mobile IPv6 offer mobility support at
   the cost of handling operations at a cardinal point, the mobility
   anchor, and burdening it with data forwarding and control mechanisms
   for a great amount of users.  As stated in [I-D.chan-distributed-
   mobility-ps], centralized mobility solutions are prone to several
   problems and limitations: longer (sub-optimal) routing paths,
   scalability problems, signaling overhead (and most likely a longer
   associated handover latency), more complex network deployment, higher
   vulnerability due to the existence of a potential single point of
   failure, and lack of granularity on the mobility management service
   (i.e., mobility is offered on a per-node basis, not being possible to
   define finer granularity policies, as for example per-application).

   In the paper "A Network-based Localized Mobility Solution for
   Distributed Mobility Management" [Net-basedDMM], the authors describe
   two approaches: one is fully distributed approach and another is
   partially distributed approach.  The main issue in the first one is
   how a Mobility Anchor and Access Router (MAAR) can differentiate
   between the first attachment to the network and subsequent handovers.

   This document describes MAAR and AAA supporting for managing IP
   mobility on behalf of the host.  This solution not only can settle
   the issue that mobility entities can differentiate between the first
   attachment to the network and subsequent handovers, but also reduce
   the heavy burdens on home mobility anchor.  The MN can directly
   forward packages to the CN.  The packages don't need to pass the home
   mobility anchor.  This document strictly abides by the two



Zhengming Ma & Xun Zhang  Expires July 7, 2012                  [Page 4]

Internet-Draft        A RO solution support for DMM         January 2012


   principles.  The first one is that the MN's movement is transparent
   to CN.  Another one is the MN doesn't participate in any mobility-
   related signaling.


2.  Conventions used in this document

2.1.  Requirements

   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 document also uses the terminology define in [RFC6275].The
   following terminology is also used:

   MAAR (Mobility anchor and Access Router).  First hop routers where
   the mobile nodes attach to.  They can play the role of mobility
   managers for the IPv6 prefixes they anchor, or can for the IPv6
   addresses they anchor.  In this draft, MAAR assigns the IPv6 address
   for each currently registered MN.  So that MAAR can performs mobility
   management on behalf of a mobile node.  Every MAAR is responsible for
   detecting the mobile node's movements to and from the access link and
   for initiating binding registrations.

   AAA (Authentication, Authorization and Accounting ).  AAA server
   records the user's static and dynamic information.  The dynamic
   information includes the address information of MAAR which the MN is
   registered right now.

   DBU/DBA (Distributed BU/BA).  A MAAR sends the DBU/DBA message to
   another MAAR for establishing or updating corresponding binding list.
   In this draft, we have two kinds of the DBU/DBA message.  One is the
   sDBU/sDBA message and another is the dDBU/dDBA message.

   sDBU/sDBA.  The MAAR attached by the MN currently to sends a sDBU
   message to the MAAR attached by MN before the MN's movement.  After
   that, the MAAR attached by MN currently receives a sDBA message
   including the address of CN's MAAR which the CN is currently attached
   to.  After that, the MAAR attached by the MN currently updates its
   internal binding list.

   dDBU/dDBA.  The MAAR attached by the MN currently sends a dDBU
   message to the MAAR attached by CN for refreshing the internal
   binding list of the CN's MAAR which the CN is currently attached to.
   After receiving the dDBU message, the CN's MAAR replies a dDBA



Zhengming Ma & Xun Zhang  Expires July 7, 2012                  [Page 5]

Internet-Draft        A RO solution support for DMM         January 2012


   message to the MN's MAAR.


3.  MAAR Operation

   In this draft, the packages sent by the MN or the CN don't need to go
   by the home mobility anchor.  In this solution, both of MN and CN
   move to the MAARs' access links and get the corresponding addresses
   assigned by corresponding MAARs.  For example, a user A (this user A
   can be thought as a MN) attaches to the A_MAAR1's access link, and
   establishes the first communication with a user B (this user B can be
   thought as a CN).  At same time, the user B attaches to the B_MAAR1's
   access link.  After that, both the user A and B move and respectively
   attach to the A_MAAR2's access link and the B_MAAR2's access link.
   In this solution, the packages sent by the MN or the CN don't need to
   pass the A_MAAR1 and the B_MAAR1.This section describes the
   operational details.

3.1.  Operation between MAAR and AAA

   MAAR MUST send a diameter request message to the AAA when detects the
   MN's movement to its access link.  After receiving the message, the
   AAA checks the dynamic information by using the MN's ID.  If the AAA
   finds the address information of the MAAR which attached by the MN
   before its movement, then the AAA sends a diameter response message
   with the address of the MAAR attached by the MN before its movement.
   If the AAA can't find this information, then the MAAR receives the
   diameter response message with the zero address.  After that, the
   MAAR will differentiate between the first attachment to the network
   and subsequent handovers.  Sending out the diameter response message,
   the AAA MUST update the dynamic information including the address
   information of MAAR which the MN is currently attached to.

3.2.  The assumptions about a session

   The Home Address (HoA) and Care-of address (CoA) is not for users but
   also for specific sessions.  For a user initiating a session or
   accepting a session, no matter how it moves, the HoA for the session
   is unchanged, while the CoA for the session is changed.

   The MN (the user A) initiates a session with the CN (the user B) by
   using the address (A_HoA1) assigned by A_MAAR1 which the user A is
   registered as the HoA for the session.  The user B accepts this
   session by using the address (B_HoA1) assigned by B_MAAR1 which the
   user B is registered as the HoA for this session.

   When the user A moves from its current access link, it associates to
   a new MAAR (A_MAAR2) which delegates another IPv6 address (A_HoA2).



Zhengming Ma & Xun Zhang  Expires July 7, 2012                  [Page 6]

Internet-Draft        A RO solution support for DMM         January 2012


   The A_HoA2 can be both thought as a CoA of the user A and a CoA of
   the session.  If the user A sends packages to the user B, the source
   address must be A_HoA1, and the destination address must be
   B_HoA1.The user A can initiate a new session with a new CN (for
   example a user C) by using A_HoA2 which the user A can be registered
   as the HoA for the new session.  If the user A sends packages to the
   user C, the source address must be A_HoA2.

   When the user B moves from its current access link, it associates to
   a new MAAR (B_MAAR2) which delegates another IPv6 address (B_HoA2).
   The B_HoA2 can be both thought as a CoA of the user B and a CoA of
   the session.  If the user B sends packages to the user A, the source
   address must be B_HoA1, and the destination address must be
   A_HoA1.The user B can initiate a new session with a new MN (for
   example a user D) by using the B_HoA2 which the user B can be
   registered as the HoA for the new session.  If the user B sends
   packages to the user D, the source address must be B_HoA2.

3.3.  Binding list in MAAR

   Every MAAR must maintain two binding lists for each currently
   registered mobile node.  One is the internal binding list, and
   another is the external binding list.  The first one maintains a
   binding of CN's HoA and the address of CN's MAAR.  The CN's HoA is
   the address which the CN accepting the session and registering as the
   HoA of the session.  The second one maintains a binding of MN's HoA
   and MN's CoA.  The MN's HoA is the address which the MN initiating
   the session and registering as the HoA of the session.  The MN's CoA
   is assigned by the MAAR which the MN is currently attached to.  The
   external binding list is used to transmit packets to MN.  The
   internal binding list is used to transmit packets from MN.

   For example, the A_MAAR2 of the user A stores two binding lists.  One
   is the internal binding list, and another is the external binding
   list.  The first list stores a binding of B_HoA1 and the address of
   the MAAR attached by the user B currently.  The second one stores a
   binding of A_HoA1 and A_HoA2.The B_MAAR2 of the user B stores two
   binding lists.  One is the internal binding list, and another is the
   external binding list.  The first list stores a binding of A_HoA1 and
   the address of the MAAR which the user A is currently attached to.
   The second one stores a binding of B_HoA1 and B_HoA2.

3.4.  Operation between MAARs

   If the MAAR which the MN is currently attached to learns that the MN
   is the handover attachment, the MAAR will send a sDBU message to the
   MAAR attached by the MN before its movement.  The address information
   of the MAAR attached by the MN before its movement is included in the



Zhengming Ma & Xun Zhang  Expires July 7, 2012                  [Page 7]

Internet-Draft        A RO solution support for DMM         January 2012


   diameter response message.  At this time, the MAAR attached by the MN
   before its movement has two binding lists.  One is the internal
   binding list, and another is the external binding list.  After
   receiving the sDBU message, the MAAR searches the internal binding
   list by using the CN's HoA and gets the address of the MAAR which the
   CN is currently attached to.  After that, the MAAR attached by the MN
   before its movement will send a sDBA message including the MN's HoA,
   the CN's HoA and the address of the MAAR which the CN is currently
   attached to.

   If the MAAR which the MN is currently attached to receives the sDBA
   message, the MAAR sends a dDBU message to the MAAR attached by the CN
   currently including the address of the MAAR attached by the MN
   currently.  After receiving the dDBU message, the MAAR attached by
   the CN currently refreshes the internal binding list.  The MN's MAAR
   and the CN's MAAR establish a bidirectional tunnel for forwarding all
   data traffic belonging to the MN.


4.  Description of the solution

   The purpose of Distributed Mobility Management approaches is to
   overcome the limitations of the traditional centralized mobility
   management by bringing the mobility anchor closer to the MN.
   Following this idea, in our proposal, the central anchor is moved to
   the edge of the network, being deployed in the access router of the
   mobile node.  That is, the first elements that provide IP
   connectivity to a set of MNs are also the mobility managers for those
   MNs.  In the following, we will call MAAR (Mobility anchor and Access
   Router).

   Upon the user A attaches to a MAAR, say A_MAAR1, the user A
   establishes the first communication with the user B. At the same
   time, the user B attaches to a MAAR, say B_MAAR1.After that, the user
   A moves from its current access and is now attached to A_MAAR2.  The
   user B moves from its current access and is now attached to
   B_MAAR2.A_HoA1 is the address of the user A assigned by A_MAAR1.
   A_HoA2 is the address of the user A assigned by A_MAAR2.  B_HoA1 is
   the address of the user B assigned by B_MAAR1.  B_HoA2 is the address
   of the user B assigned by B_MAAR2.When the user A moves from its
   current access, it associates to A_MAAR3 which delegates another IPv6
   address (A_HoA3).  Figure 1 illustrates this scenario.









Zhengming Ma & Xun Zhang  Expires July 7, 2012                  [Page 8]

Internet-Draft        A RO solution support for DMM         January 2012


 +----------+  +----------+ +-------+  +-------+   +-------+     +-----+
 |The user A|  |The user B| |A_MAAR2|  |B_MAAR2|   |A_MAAR3|     | AAA |
 +----------+  +----------+ +-------+  +-------+   +-------+     +-----+
      |             |           |          |           |             |
      |--------------1.RS(A_HoA1,B_HoA1)-------------->|             |
      |             |           |          |           |-2.request-->|
      |             |           |          |           |<-3.response-|
      |<-------------------4.RA(A_HoA3) ---------------|             |
      |             |           |          |           |             |
      |             |           |<-------5.sDBU -------|             |
      |             |           |------6. sDBA ------->|             |
      |             |           |          |<-7.dDBU --|             |
      |             |           |          |--8.dDBA ->|             |
      |             |           |          |           |             |


                     Figure 1:Signaling of MN handover

   (1) The user A sends a RS message to A_MAAR3 including A_HoA1 and
   B_HoA1;

   (2) A_MAAR3 sends a diameter request message to the AAA.

   (3) The AAA searches the dynamic information by using the ID of the
   user A for getting the address of A_MAAR2.  Then the AAA sends a
   diameter response message including the address of A_MAAR2, and
   updates the dynamic information of the user A including the address
   information of A_MAAR3 at same time.

   (4) A_MAAR3 delegates another IPv6 address (A_HoA3) to the user A. At
   the same time, A_MAAR3 establishes and maintains the external binding
   list which stores a binding of A_HoA1 and A_HoA3.Then A_MAAR3 sends a
   RA message to the user A including A_HoA3;

   (5) A_MAAR3 sends a sDBU message to A_MAAR2 including B_HoA1;

   (6) Now A_MAAR2 has two binding lists.  One is the internal binding
   list, and another is the external binding list.  The first one
   maintains a binding of B_HoA1 and the address of B_MAAR2.The second
   one maintains a binding of A_HoA1 and A_HoA2.  After receiving the
   sDBU message, A_MAAR2 searches the internal binding list by using the
   B_HoA1 for getting the address of B_MAAR2.Then A_MAAR2 sends a sDBA
   message including B_HoA1 and the address of B_MAAR2.After that,
   A_MAAR2 releases this two binding lists;

   (7) After receiving the sDBA message, A_MAAR3 establishes and
   maintains the internal binding list which maintains a binding of
   B_HoA1 and the address of B_MAAR2.  Then A_MAAR3 sends a dDBU message



Zhengming Ma & Xun Zhang  Expires July 7, 2012                  [Page 9]

Internet-Draft        A RO solution support for DMM         January 2012


   to B_MAAR2 including the address of A_MAAR3 and A_HoA1;

   (8) After receiving the dDBU message, B_MAAR2 replies a dDBA message
   and updates the internal binding list which maintains a binding of
   A_HoA1 and the address of A_MAAR2.After that, this list maintains a
   binding of A_HoA1 and the address of A_MAAR3.


5.  Forwarding Considerations

5.1.  Forwarding Packets Sent by the Mobile Node

   After receiving the packages sent by the MN, the MAAR will search the
   internal binding list by using the destination address of the
   packages for getting the address of the MAAR which the CN is
   currently attached to.  Then, the MAAR encapsulates the packages and
   routes the packages to the corresponding MAAR attached by the CN
   currently.

   After receiving the packages, the corresponding MAAR will do three
   things.  Firstly, the corresponding MAAR will remove the tunnel head.
   Secondly, the corresponding MAAR will check whether the destination
   address of the packages is assigned by this corresponding MAAR or
   not.  If the destination address of the packages is assigned by this
   corresponding MAAR, the corresponding MAAR will route the packages to
   the corresponding CN directly.  If the destination address of the
   packages is not assigned by this corresponding MAAR, the
   corresponding MAAR will search the external binding list by using the
   destination address of the packages for getting the CoA of the
   corresponding CN.  Finally, the corresponding MAAR will route the
   packages to the corresponding CN.  Figure 2 illustrates the
   transmission of data packets.



















Zhengming Ma & Xun Zhang  Expires July 7, 2012                 [Page 10]

Internet-Draft        A RO solution support for DMM         January 2012


      ________                          ________
     |The user|                        |The user|
     |   B    |----------move--------->|   B    |
     |________|                        |________|
                                          #  *
                                          #  *
                                          #  *
      +-------+                       +-------+
      |       |                       |       |
      |B_MAAR1|                       |B_MAAR2|
      |       |                     / |       |
      +-------+                    /  +-------+
                                  /  #  /| * |
                                 /  #  / | * |
                                /  #  /  | * |
                               /  #  /   | * |
                              /  #  /    | * |
                             /  #  /     | * |
    +-------+        +-------+ #  /    +-------+
    |       |        |       |   /     |       |
    |A_MAAR1|        |A_MAAR2|  /      |A_MAAR3|
    |       |        |       |         |       |
    +-------+        +-------+         +-------+
                        #                   *
                        #                   *
                        #                   *
    ________         ________             ________
   |The user|       |The user|           |The user|
   |   A    |-move->|   A    |---move--->|   A    |
   |________|       |________|           |________|


                 Figure 2:The transmission of data packets

   Upon the user A attaches to a MAAR, say A_MAAR1, the user A
   establishes the first communication with the user B. At the same
   time, the user B attaches to a MAAR, say B_MAAR1.After that, the user
   A moves from its current access and is now attached to A_MAAR2.  The
   user B moves from its current access and is now attached to
   B_MAAR2.A_HoA1 is the address of the user A assigned by A_MAAR1.
   A_HoA2 is the address of the user A assigned by A_MAAR2.  B_HoA1 is
   the address of the user B assigned by B_MAAR1.  B_HoA2 is the address
   of the user B assigned by B_MAAR2.When the MN moves from its current
   access link, it associates to A_MAAR3 which delegates another IPv6
   address (A_HoA3).

   At this time, the A_MAAR3 of the user A stores two binding lists.
   One is the internal binding list, and another is the external binding



Zhengming Ma & Xun Zhang  Expires July 7, 2012                 [Page 11]

Internet-Draft        A RO solution support for DMM         January 2012


   list.  The first list maintains a binding of B_HoA1 and the address
   of B_MAAR2.  The second one maintains a binding of A_HoA1 and A_HoA3.
   The B_MAAR2 of the user B stores two binding lists.  One is the
   internal binding list, and another is the external binding list.  The
   first list maintains a binding of A_HoA1 and the address of A_MAAR3.
   The second one maintains a binding of B_HoA1 and B_HoA2.

   If the user A sends the packages to the user B, the destination
   address of the packages must be B_HoA1, and the source address of the
   packages must be A_HoA1.  A_MAAR3 receives the packages and then
   searches the internal binding list by using the destination address
   of the packages (B_HoA1) for getting the address of B_MAAR2.  Then
   A_MAAR3 encapsulates the packages and routes to B_MAAR2.  The source
   address of the tunnel header is the address of A_MAAR3, and the
   destination address is the address of B_MAAR2.The format of the
   tunneled packet is shown below:

   IPv6 header (src= A_MAAR3's address, dst= B_MAAR2's address) /*
   Tunnel Header */

   IPv6 header (src= A_HoA1, dst= B_ HoA1 ) /* Packet Header */

   Upper layer protocols /* Packet Content*/

   After receiving the packages, B_MAAR2 removes the tunnel head and
   find the destination address of the packages (B_HoA1) is not assigned
   by B_MAAR2.Then B_MAAR2 searches the external binding list by using
   the destination address of the packages (B_HoA1) for getting the CoA
   of the user B. Finally, B_MAAR2 gets a binding of B_HoA1 and B_HoA2
   and routes the packages to the user B.

5.2.  Forwarding Packets to the Mobile Node

   After receiving the packages sent by the CN, the MAAR attached by the
   CN will search the internal binding list by using the destination
   address of the packages for getting the address of the MAAR which the
   MN is currently attached to.  Then, the MAAR encapsulates the
   packages and routes the packages to the corresponding MAAR which the
   MN is currently attached to.

   After receiving the packages, the corresponding MAAR will do three
   things.  Firstly, the corresponding MAAR will remove the tunnel head.
   Secondly, the corresponding MAAR will check whether the destination
   address of the packages is assigned by this corresponding MAAR or
   not.  If the destination address of the packages is assigned by this
   corresponding MAAR, the corresponding MAAR will route the packages to
   the corresponding MN directly.  If the destination address of the
   packages is not assigned by this corresponding MAAR, the



Zhengming Ma & Xun Zhang  Expires July 7, 2012                 [Page 12]

Internet-Draft        A RO solution support for DMM         January 2012


   corresponding MAAR will search the external binding list by using the
   destination address of the packages for getting the CoA of the
   corresponding MN.  Finally, the corresponding MAAR will route the
   packages to the corresponding MN.

   As shown in figure 2, if the user B sends the packages to the user A,
   the destination address of the packages must be A_HoA1, and the
   source address of the packages must be B_HoA1.B_MAAR2 receives the
   packages and then searches the internal binding list by using the
   destination address of the packages (A_HoA1) for getting the address
   of A_MAAR3.  Then B_MAAR2 encapsulates the packages and routes to
   A_MAAR3.  The source address of the tunnel header is the address of
   B_MAAR2, and the destination address is the address of A_MAAR3.The
   format of the tunneled packet is shown below:

   IPv6 header (src= B_MAAR2's address, dst= A_MAAR3's address) /*
   Tunnel Header */

   IPv6 header (src= B_HoA1, dst= A_ HoA1 ) /* Packet Header */

   Upper layer protocols /* Packet Content*/

   After receiving the packages, A_MAAR3 removes the tunnel head and
   find the destination address of the packages (A_HoA1) is not assigned
   by A_MAAR3.  Then A_MAAR3 searches the external binding list by using
   the destination address of the packages (A_HoA1) for getting the CoA
   of the user A. Finally, A_MAAR3 gets a binding of A_HoA1 and A_HoA3
   and routes the packages to the user A.


6.  Message Formats

   This section defines extensions to the Mobile IPv6 [RFC6275] protocol
   messages.

















Zhengming Ma & Xun Zhang  Expires July 7, 2012                 [Page 13]

Internet-Draft        A RO solution support for DMM         January 2012


6.1.  sDBU

       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|D|E|  Reserved     |            Lifetime           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Mobility Options                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                               Figure 3:sDBU

   A Binding Update message that is sent by the MAAR attached by MN
   currently to the MAAR attached by MN before the MN's movement is
   referred to as the "sDBU" message.  A new flag D and E are included
   in the Binding Update message.  The rest of the Binding Update
   message format remains the same as defined in [RFC6275] and with the
   additional (R) and (M) flags, as specified in [RFC3963] and
   [RFC4140], respectively.

   Distributed Flag (D)

   If the D is set to 0, this message is the BU message in the
   [RFC6275].  If the D is set to the value 1, this message is the
   Distributed Binding Update message (DBU).The flag MUST be set to the
   value of 1 in the draft.

   A new Flag (E)

   If the E is set to 0, this DBU message is the sDBU message.  This
   flag MUST be set to 0.

   Mobility Options

   The sDBU message is sent by the MAAR attached by the user A currently
   to the MAAR attached by the user A before its movement including the
   ID of the user A, A_HoA1 and B_HoA1.









Zhengming Ma & Xun Zhang  Expires July 7, 2012                 [Page 14]

Internet-Draft        A RO solution support for DMM         January 2012


6.2.  sDBA

       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|D|E|Reserved|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Sequence #             |            Lifetime           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Mobility Options                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                               Figure 4:sDBA

   A Binding Acknowledgement message that is sent by the MAAR attached
   by MN before the MN's movement to the MAAR attached by MN currently
   is referred to as the "sDBA" message.  A new flag D and E are
   included in the Binding Acknowledgement message.  The rest of the
   Binding Acknowledgement message format remains the same as defined in
   [RFC6275] and with the additional (R) as specified in [RFC3963].

   Distributed Flag (D)

   If the D is set to 0, this message is the BA message in the
   [RFC6275].  If the D is set to the value 1, this message is the
   Distributed Binding Acknowledgement message (DBA).The flag MUST be
   set to the value of 1 in the draft.

   A new Flag (E)

   If the E is set to 0, this DBA message is the sDBA message.  This
   flag MUST be set to 0.

   Mobility Options

   The sDBA message is sent by the MAAR attached by the user A before
   its movement to the MAAR attached by the user A currently including
   A_HoA1,B_HoA1 and the address of the MAAR attached by the user B
   currently.









Zhengming Ma & Xun Zhang  Expires July 7, 2012                 [Page 15]

Internet-Draft        A RO solution support for DMM         January 2012


6.3.  dDBU

       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|D|E|  Reserved     |            Lifetime           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Mobility Options                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                               Figure 5:dDBU

   A Binding Update message that is sent by the MN's MAAR attached by
   the MN currently to the CN's MAAR which the CN is currently attached
   to is referred to as the "dDBU" message.  A new flag D and E are
   included in the Binding Update message.  The rest of the Binding
   Update message format remains the same as defined in [RFC6275] and
   with the additional (R) and (M) flags, as specified in [RFC3963] and
   [RFC4140], respectively.

   Distributed Flag (D)

   If the D is set to 0, this message is the BU message in the
   [RFC6275].  If the D is set to the value 1, this message is the
   Distributed Binding Update message (DBU).The flag MUST be set to the
   value of 1 in the draft.

   A new Flag (E)

   If the E is set to the value of 1, this DBU message is the dDBU
   message.  This flag MUST be set to the value of 1.

   Mobility Options

   The dDBU message is sent by the MAAR attached by the user A currently
   to the MAAR which the user B is currently attached to including
   A_HoA1 and the address of the MAAR currently attached by the user A.









Zhengming Ma & Xun Zhang  Expires July 7, 2012                 [Page 16]

Internet-Draft        A RO solution support for DMM         January 2012


6.4.  dDBA

       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|D|E|Reserved|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Sequence #             |            Lifetime           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Mobility Options                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                               Figure 6:dDBA

   A Binding Acknowledgement message that is sent by the CN's MAAR
   currently attached by the CN to the MN's MAAR which the MN is
   currently attached to is referred to as the "dDBA" message.  A new
   flag D and E are included in the Binding Acknowledgement message.
   The rest of the Binding Acknowledgement message format remains the
   same as defined in [RFC6275] and with the additional (R) as specified
   in [RFC3963].

   Distributed Flag (D)

   If the D is set to 0, this message is the BA message in the
   [RFC6275].  If the D is set to the value 1, this message is the
   Distributed Binding Acknowledgement message (DBA).The flag MUST be
   set to the value of 1 in the draft.

   A new Flag (E)

   If the E is set to the value of 1, this DBA message is the dDBA
   message.  This flag MUST be set to the value of 1.

   Mobility Options

   The dDBA message is sent by the MAAR currently attached by the user B
   to the MAAR which the user A is currently attached to including
   A_HoA1 and B_HoA1.


7.  IANA Considerations

   TBD.




Zhengming Ma & Xun Zhang  Expires July 7, 2012                 [Page 17]

Internet-Draft        A RO solution support for DMM         January 2012


8.  Security Considerations

   TBD.


9.  References

9.1.  Normative References

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

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

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

   [RFC4140]  Soliman, H., Castelluccia, C., El Malki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 Mobility Management
              (HMIPv6)", RFC 4140, August 2005.

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

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

9.2.  Informative References

   [I-D.chan-distributed-mobility-ps]
              Chan, A., "Problem statement for distributed and dynamic
              mobility management", October  2011.

   [Net-basedDMM]
              Giust, F., de la Oliva, A., Bernardos, CJ., and RP.
              Ferreira Da Costa, "A Network-based Localized Mobility
              Solution for Distributed Mobility Management", 2011.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC5779]  Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
              and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
              Gateway and Local Mobility Anchor Interaction with
              Diameter Server", RFC 5779, February 2010.




Zhengming Ma & Xun Zhang  Expires July 7, 2012                 [Page 18]

Internet-Draft        A RO solution support for DMM         January 2012


Authors' Addresses

   Zhengming Ma
   SUN YAT-SEN UNIVERSITY
   Department of Electronics and Engineering,daxuecheng,210
   Zhongshan University,Guangzhou,   510006
   P.R. China

   Email: issmzm@mail.sysu.edu.cn


   Xun Zhang
   SUN YAT-SEN UNIVERSITY
   Department of Electronics and Engineering,daxuecheng,210
   Zhongshan University,Guangzhou,   510006
   P.R. China

   Email: zhangxunkuaile@yeah.net

































Zhengming Ma & Xun Zhang  Expires July 7, 2012                 [Page 19]