| Distributed Mobility Management(dmm) | Zhengming Ma |
| Internet-Draft | Xun Zhang |
| Intended status: Standards Track | SUN YAT-SEN UNIVERSITY |
| Expires: August 02, 2012 | February 2012 |
A Route Optimization solution support for Distributed Mobility Management
draft-ma-dmm-romip-00.txt
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.
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 August 02, 2012.
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.
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 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.
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].
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 message to the MN's MAAR.
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.
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.
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). 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.
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.
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 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.
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.
+----------+ +----------+ +-------+ +-------+ +-------+ +-----+
|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 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.
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.
________ ________
|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 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.
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 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.
This section defines extensions to the Mobile IPv6 [RFC6275] protocol messages.
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.
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.
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.
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.
TBD.
TBD.
| [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. |
| [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. |
| [RFC3775] | Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. |
| [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. |