Internet DRAFT - draft-ma-mext-dmm-armip

draft-ma-mext-dmm-armip






Mobility EXTensions for IPv6                                Zhengming.Ma
Internet-Draft                                                 Xun.Zhang
Intended status: Standards Track                  SUN YAT-SEN UNIVERSITY
Expires: June 29, 2012                                 December 27, 2011


    An AR-level solution support for Distributed Mobility Management
                     draft-ma-mext-dmm-armip-00.txt

Abstract

   The number of mobile users and their traffic demand is expected to be
   ever-increasing in future years, and this growth can represent 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 is 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.

   The work presented here copes with the distributed approach,
   describing a novel solution for distributed mobility management
   support in a flat architecture without central mobility anchors.
   This document strictly abides by the two principles:

   (a)The movement of MN is transparent to CN.

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

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 June 29, 2012.

Copyright Notice



Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                 [Page 1]

Internet-Draft          An AR-level DMM solution           December 2011


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

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
     2.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  MAAR Operation . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Operation between AMAAR and AAA  . . . . . . . . . . . . .  5
     3.2.  Binding list in MAAR . . . . . . . . . . . . . . . . . . .  5
     3.3.  Operation between AMAAR and FMAAR  . . . . . . . . . . . .  6
   4.  Description of the solution  . . . . . . . . . . . . . . . . .  6
   5.  Forwarding Considerations  . . . . . . . . . . . . . . . . . .  8
     5.1.  Forwarding Packets Sent by the Mobile Node . . . . . . . .  8
     5.2.  Forwarding Packets to the Mobile Node  . . . . . . . . . .  9
   6.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  pDBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  pDBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.3.  fDBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.4.  fDBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16












Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                 [Page 2]

Internet-Draft          An AR-level DMM solution           December 2011


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 support for managing IP mobility
   on behalf of the host.  This can settle the issue that mobility
   entities can differentiate between the first attachment to the
   network and subsequent handovers.  This document strictly abides by
   the two principles.  The first one is the movement of MN is
   transparent to CN.  Another one is the MN doesn't participate in any
   mobility-related signaling.



Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                 [Page 3]

Internet-Draft          An AR-level DMM solution           December 2011


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.  For the convenience of narrative, we call
   the MAAR which the user is currently attached to as the AMAAR, and
   call the MAAR which was previously visited by the user is FMAAR.
   Before the MN handover, the AMAAR becomes a FMAAR.  We call this
   FMAAR as a PMAAR.

   AMAAR (Accessing MAAR).  MAAR which the MN is currently attached to.
   Every ALMN MUST establish and maintain two binding lists for each
   currently registered mobile node.  One is the internal binding list,
   and another is the external binding list.  Every AMAAR configures the
   IPv6 address for the new users.  So that AMAAR can performs mobility
   management on behalf of a mobile node.  Every AMAAR is responsible
   for detecting the mobile node's movements to and from the access link
   and for initiating binding registrations.

   FMAAR (Forwarding MAAR).  MAAR which was previously visited by the MN
   and is still involved in an active flow using an IPv6 address it has
   advertised to the MN (i.e., MAAR where that IPv6 address is
   anchored).  The MN may have one or more FMAAR.

   AAA (Authentication, Authorization and Accounting ).  AAA server
   records the user's static and dynamic information, and 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 corresponding binding list.  In this
   draft, we have two kinds of the DBU/DBA message.  One is the pDBU/
   pDBA message and another is the fDBU/fDBA message.

   pDBU/pDBA.  A pDBU message is sent by the AMAAR to the PMAAR of the



Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                 [Page 4]

Internet-Draft          An AR-level DMM solution           December 2011


   MN for establishing the binding between the mobile node's AMAAR and
   PMAAR.  This message includes the address of the AMAAR.  After
   receiving the pDBU message, the PMAAR replies a pDBA message to the
   AMAAR including the addresses of the FMAARs and the addresses of the
   MN assigned by the FMAARs.

   fDBU/fDBA.  A fDBU message is sent by the AMAAR to the FMAAR (except
   PMAAR) of the MN for establishing the binding between the mobile
   node's AMAAR and FMAAR (except PMAAR).  This message includes the
   address of the AMAAR.  After receiving the fDBU message, the FMAAR
   replies a fDBA message to the AMAAR.


3.  MAAR Operation

   Upon the MN's attachment to a MAAR, say MAAR1, MN establishes the
   first communication with the CN1.After that, the MN moves and is now
   attached to MAAR2.The MN establishes the first communication with the
   CN2.  In this draft, the packages between the MN and the CN1 must go
   by the MAAR1 (now becomes the MN's FMAAR).This section describes the
   operational details.

3.1.  Operation between AMAAR and AAA

   AMAAR MUST send diameter request message to the AAA when detects the
   MN's movement to the access link.  After receiving the message, the
   AAA checks dynamic information using the MN's ID.  If the AAA finds
   the address information of the previous AMAAR, then the AAA sends the
   diameter response message with the address of the previous AMAAR.  If
   the AAA can!_t find this information, then AMAAR receives the
   diameter response message with the zero address.  After that, the
   AMAAR will differentiate between the first attachment to the network
   and subsequent handovers.  After sending out the diameter response
   message, the AAA MUST update the dynamic information including the
   address information of AMAAR.

3.2.  Binding list in MAAR

   Every AMAAR MUST establish and maintain two binding lists for each
   currently registered MN.  One is the internal binding list, and
   another is the external binding list.  The first list stores a
   binding of the MN's addresses assigned by FMAARs and the MN's FMAARs
   addresses.  The second list stores a binding of the MN's address
   assigned by AMAAR and the MN's addresses assigned by FMAARs.  The
   external binding list is used to transmit packets to MN.  The
   internal binding list is used to transmit packets from MN.

   Every FMAAR MUST maintain one binding list for each previously



Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                 [Page 5]

Internet-Draft          An AR-level DMM solution           December 2011


   registered MN.  This list stores a binding of the MN's address
   assigned by this FMAAR and the address of the MN's AMAAR.

3.3.  Operation between AMAAR and FMAAR

   If AMAAR learns that the MN is the handover attachment, AMAAR will
   send pDBU message to the PMAAR.  The PMAAR address information is
   included in diameter response message.  At this time, the PMAAR has
   two binding lists.  One is the Internal binding list, and another is
   the External binding list.  After receiving the pDBU message, the
   PMAAR will send a pDBA message including its Internal binding list,
   the IPv6 address assigned by PMAAR and the address of the PMAAR.  The
   AMAAR and the PMAAR establish a bidirectional tunnel for forwarding
   all data traffic belonging to the MN.

   If AMAAR gets the addresses of the FMAARs(besides the PMAAR),AMAAR
   will sends the fDBU message including the address of the AMAAR to the
   FMAAR(besides the PMAAR).After receiving the fDBU message, the FMAARs
   can refresh the binding list and response the fDBA message.  Now the
   FMAAR stores the MN's address assigned by this FMAAR and the address
   of the AMAAR.  After that, the AMAAR and the FMAARs (besides the
   PMAAR) 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 MN's attachment to a MAAR, say MAAR1, MN establishes the
   first communication with the CN1.After that, the MN moves and is now
   attached to MAAR2.The MN establishes the first communication with the
   CN2.HoA1 is the MN's address assigned by the MAAR1.  HoA2 is the MN's
   address assigned by the MAAR1.  When the MN moves from its current
   access, it associates to MAAR3 which delegates another IPv6 address
   (HoA3).  Figure 1 illustrates this scenario.







Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                 [Page 6]

Internet-Draft          An AR-level DMM solution           December 2011


        +-----+     +------+   +------+       +------+          +----+
        |  MN |     | MAAR1|   | MAAR2|       | MAAR3|          | AAA|
        +-----+     +------+   +------+       +------+          +----+
           |           |           |             |                 |
           |-----------1.RS(HoA1,HoA2)---------->|                 |
           |           |           |             |----2.request--->|
           |           |           |             |<---3.response---|
           |<----------4.RA(HoA3)--------------- |                 |
           |           |           |             |                 |
           |           |           |<--5.pDBU ---|                 |
           |           |           |--6. pDBA -->|                 |
           |           |<--------7.fDBU ---------|                 |
           |           |---------8.fDBA -------->|                 |
           |           |                         |                 |



                     Figure 1:Signaling of MN handover

   (1) The MN send RS message to the MAAR3 including the HoA1 and HoA2;

   (2) The MAAR3 sends the diameter request message to the AAA.

   (3) AAA has the address information of MAAR2.  AAA sends the diameter
   response message including the address of the MAAR2, and then AAA
   updates the MN's the dynamic information including the address
   information of MAAR3.

   (4) MAAR3 delegates another IPv6 address (HoA3) to the MN.  At the
   same time, MAAR3 establishes and maintain the external binding list
   which stores HoA1 and HoA3,HoA2 and HoA3 binding.MAAR3 sends the RA
   message to the MN including HoA3;

   (5) At the same time, the MAAR3 sends the pDBU message to the MAAR2
   including the address of the MAAR3;

   (6) Now MAAR2 has two binding lists.  One is the internal binding
   list, and another is the external binding list.  The first one stores
   the address of the MAAR1 and HoA1.The second one stores HoA1 and HoA2
   binding.  After receiving the pDBU message, the MAAR2 sends the pDBA
   message including the information of the internal binding list,HoA2
   and the address of the MAAR2.After that, the MAAR2 replaces this two
   binding lists with a binding list which stores HoA2 and the address
   of MAAR3;

   (7) After receiving the pDBA message, MAAR3 establishes and maintains
   the internal binding list which stores HoA1 and the address of the
   MAAR1 binding, and HoA2 and the address of the MAAR2 binding.  MAAR3



Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                 [Page 7]

Internet-Draft          An AR-level DMM solution           December 2011


   sends the fDBU message to the MAAR1 including the address of MAAR3;

   (8) After receiving the fDBU message, MAAR1 responses the fDBA
   message and updates the binding list which was previously stored HoA1
   and the address of the MAAR2.The list is now stored HoA1 and the
   address of the MAAR3.


5.  Forwarding Considerations

5.1.  Forwarding Packets Sent by the Mobile Node

   After receiving the packages sent by the MN, AMAAR will check the
   source address of the packages.  If the address is assigned by the
   AMAAR, the AMAAR will forward the packages to the CN according to the
   destination address of the packages.  If the address isn!_t assigned
   by the AMAAR, the AMAAR will search for the internal binding list
   according to the source address and then find the address of the
   corresponding FMAAR.  Then, AMAAR encapsulates the packages to the
   corresponding FMAAR.

   In this document, upon the MN's attachment to a MAAR, say MAAR1, MN
   establishes the first communication with the CN1.After that, the MN
   moves and is now attached to MAAR2.The MN establishes the first
   communication with the CN2.HoA1 is the MN's address assigned by the
   MAAR1.  HoA2 is the MN's address assigned by the MAAR2.  When the MN
   moves from its current access, it associates to MAAR3 which delegates
   another IPv6 address (HoA3).  MAAR3 has two binding lists.  One is
   the internal binding list, and another is the external binding list.
   The first one stores MN's HoA1 and the address of MAAR1, MN's HoA2
   and the address of MAAR2.  The second one stores MN's HoA1 and MN's
   HoA3, MN's HoA2 and MN's HoA3.

   If the MN sends the packages using the HoA3, then MAAR3 can directly
   forward to the corresponding CN.  If the MN sends the packages using
   the HoA1, then MAAR3 will search for the internal binding list
   according to HoA1 and find the address of MAAR1.  Then MAAR3
   encapsulates the packages to route to MAAR1.  The source address of
   the tunnel header is the address of MAAR3, and the destination
   address is the address of MAAR1.The format of the tunneled packet is
   shown below:

   IPv6 header (src= MAAR3's address, dst= MAAR1's address) /* Tunnel
   Header */

   IPv6 header (src= MN's HoA1, dst= CN's HoA ) /* Packet Header */

   Upper layer protocols /* Packet Content*/



Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                 [Page 8]

Internet-Draft          An AR-level DMM solution           December 2011


   If the MN sends the packages using the HoA2, then MAAR3 will search
   for the internal binding list according to HoA2 and find the address
   of MAAR2.  Then MAAR3 encapsulates the packages to route to MAAR2.
   The source address of the tunnel header is the address of MAAR3, and
   the destination address is the address of MAAR2.

5.2.  Forwarding Packets to the Mobile Node

   On receiving packets from a correspondent node with the destination
   address matching the mobile node's address assigned by FMAAR, then
   this FMAAR find the binding list.  The list stores the MN's address
   assigned by FMAAR and MN's address of the AMAAR.  Then FMAAR
   encapsulates the packages to route to AMAAR.  The source address of
   the tunnel header is the address of this FMAAR, and the destination
   address is the address of AMAAR.

   On receiving packets from the network but not through a tunnel, AMAAR
   will forward the packages according to the destination address.  If
   AMAAR receives the packets through a tunnel, AMAAR will remove the
   tunnel head.  AMAAR search for the external binding list and find the
   address assigned by AMAAR according to the destination address of the
   packets.  Then AMAAR forwards them to MN through link-layer.

   In this document, CN1 sends the packages to the MN.  The source
   address of the packages is the address of the CN1, and the
   destination address is HoA1.The packages arrive the MAAR1.MAAR1 has a
   binding list which stores HoA1 and the address of MAAR3.  Then MAAR1
   encapsulates the packages to route to MAAR3.  The source address of
   the tunnel header is the address of this MAAR1, and the destination
   address is the address of MAAR3.  MAAR3 receives the packets and
   removes the tunnel head.  Then MAAR3 searches for the external
   binding list according to the destination address of the packets.
   MAAR3 finds the binding of the HoA1 and HoA3, and then forwards the
   packets to the MN through Link-layer.

   CN2 sends the packages to the MN.  The source address of the packages
   is the address of the CN2, and the destination address is HoA2.The
   packages arrive the MAAR2.MAAR2 has a binding list which stores HoA2
   and the address of MAAR3.  Then MAAR2 encapsulates the packages to
   route to MAAR3.  The source address of the tunnel header is the
   address of this MAAR2, and the destination address is the address of
   MAAR3.  MAAR3 receives the packets and will remove the tunnel head.
   Then MAAR3 searches for the external binding list according to the
   destination address of the packets.  MAAR3 finds the binding of the
   HoA2 and HoA3, and then forwards the packets to the MN through link-
   layer.

   CN3 sends the packages to the MN.  The source address of the packages



Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                 [Page 9]

Internet-Draft          An AR-level DMM solution           December 2011


   is the address of the CN3, and the destination address is HoA3.  Then
   MAAR3 forwards them to MN through link-layer.  Figure 2 illustrates
   the transmission of data packets.

       _______         _______          _______
      |       |       |       |        |       |
      |  CN1  |       |  CN2  |        |  CN3  |
      |_______|       |_______|        |_______|
          '               *  Flow#2         .
   Flow#1 '               *                 | Flow#3
          '  ..... '''''''*''''''''''''..... .
        ..'''             *                 '''..
      .'  '            IP * network         .   '.
      :   '               *                 |    :
       '..'           +-------+             . ..'
          '''.......  |       |    ........'''
          '           | MAAR2 |\            .
          '           |       | \           |
          '           |       |* \          .
          '           +-------+\* \         |
    +-------+                   \* \ + ------+
    |       |                    \*  |       |
    | MAAR1 |------------------------| MAAR3 |
    |       |''''''''''''''''''''''''|       |
    |       |------------------------|       |
    +-------+                        +-------+
                                        ' * |
                                Flow#1  ' * . Flow#3
                                        ' * |
      +-----+                   Flow#2 +-----+
      | MN  | ----------move---------> | MN  |
      +-----+                          +-----+


                 Figure 2:The transmission of data packets


6.  Message Formats

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










Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                [Page 10]

Internet-Draft          An AR-level DMM solution           December 2011


6.1.  pDBU

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


                               Figure 3:pDBU

   A Binding Update message that is sent by the MN's AMAAR to the MN's
   PMAAR is referred to as the "pDBU" message.  A new flag D and H 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 (H)

   If the H is set to 0, this DBU message is the pDBU message.  This
   flag MUST be set to 0.

   Mobility Options

   The pDBU message is sent by the MN's AMAAR to the MN's PMAAR
   including the MN-Identifer and the address of AMAAR.











Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                [Page 11]

Internet-Draft          An AR-level DMM solution           December 2011


6.2.  pDBA

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


                               Figure 4:pDBA

   A Binding Acknowledgement message that is sent by the MN's PMAAR to
   the MN's AMAAR is referred to as the "pDBA" message.  A new flag D
   and H 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 (H)

   If the H is set to 0, this DBA message is the pDBA message.  This
   flag MUST be set to 0.

   Mobility Options

   The pDBA message is sent by the MN's PMAAR to the MN's AMAAR
   including the MN-Identifer, all of the addresses of the FMAARs and
   the MN's addresses assigned by the FMAARs.










Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                [Page 12]

Internet-Draft          An AR-level DMM solution           December 2011


6.3.  fDBU

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


                               Figure 5:fDBU

   A Binding Update message that is sent by the MN's AMAAR to the MN's
   FMAAR (besides the PMAAR) is referred to as the "fDBU" message.  A
   new flag D and H 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 (H)

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

   Mobility Options

   The fDBU message is sent by the MN's AMAAR to the MN's FMAAR (besides
   the PMAAR) including the MN-Identifer, the address of AMAAR and the
   MN's address assigned by AMAAR.










Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                [Page 13]

Internet-Draft          An AR-level DMM solution           December 2011


6.4.  fDBA

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


                               Figure 6:fDBA

   A Binding Acknowledgement message that is sent by the MN's FMAAR
   (besides the PMAAR) to the MN's AMAAR is referred to as the "fDBA"
   message.  A new flag D and H 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 (H)

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

   Mobility Options

   The fDBA message is sent by the MN's FMAAR(besides the PMAAR) to the
   MN's AMAAR including the MN-Identifer, the address of the FMAAR and
   the MN's addresses assigned by the FMAAR.


7.  IANA Considerations

   TBD.





Zhengming.Ma & Xun.Zhang  Expires June 29, 2012                [Page 14]

Internet-Draft          An AR-level DMM solution           December 2011


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]
              Internet draft, draft-chan-distributed-mobility-ps-05,
              "Problem statement for distributed and dynamic mobility
              management", October  2011.

   [Net-basedDMM]
              "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 June 29, 2012                [Page 15]

Internet-Draft          An AR-level DMM solution           December 2011


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 June 29, 2012                [Page 16]