DMM Working Group Zhengming Ma Internet-Draft Xun Zhang Intended status: Standards Track SUN YAT-SEN UNIVERSITY Expires: August 26, 2012 February 23, 2012 An AR-level solution support for Distributed Mobility Management draft-ma-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 August 26, 2012. Copyright Notice Zhengming Ma & Xun Zhang Expires August 26, 2012 [Page 1] Internet-Draft An AR-level DMM solution February 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. 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 August 26, 2012 [Page 2] Internet-Draft An AR-level DMM solution February 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 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 August 26, 2012 [Page 3] Internet-Draft An AR-level DMM solution February 2012 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 addresses for the new users. So that AMAAR 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 had 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 messages. 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 August 26, 2012 [Page 4] Internet-Draft An AR-level DMM solution February 2012 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 after detecting 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 to the AMAAR 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 one stores a binding of the MN's addresses assigned by FMAARs and the MN's FMAARs addresses. The second one 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 August 26, 2012 [Page 5] Internet-Draft An AR-level DMM solution February 2012 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 August 26, 2012 [Page 6] Internet-Draft An AR-level DMM solution February 2012 +-----+ +------+ +------+ +------+ +----+ | 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 sends a RS message to MAAR3 including the HoA1 and HoA2; (2) MAAR3 sends the diameter request message to AAA. (3) AAA has the address information of MAAR2. AAA sends the diameter response message including the address of the MAAR2, and then the 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 August 26, 2012 [Page 7] Internet-Draft An AR-level DMM solution February 2012 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 August 26, 2012 [Page 8] Internet-Draft An AR-level DMM solution February 2012 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 August 26, 2012 [Page 9] Internet-Draft An AR-level DMM solution February 2012 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 August 26, 2012 [Page 10] Internet-Draft An AR-level DMM solution February 2012 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 August 26, 2012 [Page 11] Internet-Draft An AR-level DMM solution February 2012 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 August 26, 2012 [Page 12] Internet-Draft An AR-level DMM solution February 2012 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 August 26, 2012 [Page 13] Internet-Draft An AR-level DMM solution February 2012 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 August 26, 2012 [Page 14] Internet-Draft An AR-level DMM solution February 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 August 26, 2012 [Page 15] Internet-Draft An AR-level DMM solution February 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 August 26, 2012 [Page 16]