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]
