Internet DRAFT - draft-ma-mext-dmm-romip
draft-ma-mext-dmm-romip
Mobility EXTensions for IPv6 Zhengming Ma
Internet-Draft Xun Zhang
Intended status: Standards Track SUN YAT-SEN UNIVERSITY
Expires: July 7, 2012 January 4, 2012
A Route Optimization solution support for Distributed Mobility
Management
draft-ma-mext-dmm-romip-00.txt
Abstract
The mobile users and their traffic demands are expected to be ever-
increasing in future years, and this growth will impose a limitation
for deploying current mobility management schemes that are
intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. This
evolution in user traffic demand can be tackled by a different
approach for IP mobility, called Distributed Mobility Management,
which is focusing on moving the mobility anchors from the core
network and pushing them closer to the users, at the edge of the
network. Following this idea, in our proposal, the central anchor is
being deployed in the access router of the mobile node(MN). That is,
the first elements that provide IP connectivity to a set of MNs are
also the mobility managers for those MNs. In the following, we will
call MAAR (Mobility anchor and Access Router).
This draft strictly abides by the three principles:
(1) The MN doesn't participate in any mobility-related signaling.MAAR
and AAA are responsible for managing IP mobility on behalf of the
host.
(2) The MN's movement is transparent to the communication node
(CN).The Home Address (HoA) and Care-of address (CoA) are not for
users but for specific sessions in this draft.A MN initiates a
session by using the MN's address assigned by a MAAR which the MN is
registered as the HoA for this session.The MN's address assigned by a
new MAAR which the MN moves to its access link as the CoA for the
session.
(3) The MN can directly forward packages to the CN and the packages
don't need to pass the home mobility anchor. It can reduce the heavy
burdens on home mobility anchor and maintain all the continuity of
the conversation.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 1]
Internet-Draft A RO solution support for DMM January 2012
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 7, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 2]
Internet-Draft A RO solution support for DMM January 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5
2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. MAAR Operation . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Operation between MAAR and AAA . . . . . . . . . . . . . . 6
3.2. The assumptions about a session . . . . . . . . . . . . . 6
3.3. Binding list in MAAR . . . . . . . . . . . . . . . . . . . 7
3.4. Operation between MAARs . . . . . . . . . . . . . . . . . 7
4. Description of the solution . . . . . . . . . . . . . . . . . 8
5. Forwarding Considerations . . . . . . . . . . . . . . . . . . 10
5.1. Forwarding Packets Sent by the Mobile Node . . . . . . . . 10
5.2. Forwarding Packets to the Mobile Node . . . . . . . . . . 12
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. sDBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. sDBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. dDBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. dDBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 3]
Internet-Draft A RO solution support for DMM January 2012
1. Introduction
Mobile IPv6 [RFC6275] requires client functionality in the IPv6 stack
of a mobile node. Exchange of signaling messages between the mobile
node and home agent enables the creation and maintenance of a binding
between the mobile node's home address and its care-of address.
Mobility as specified in requires the IP host to send IP mobility
management signaling messages to the home agent, which is located in
the network.
Proxy Mobile IPv6 [RFC5213] is a network-based mobility to solving
the IP mobility challenge. It is possible to support mobility for
IPv6 nodes without host involvement by extending Mobile IPv6
signaling messages between a network node and a home agent. In order
to facilitate such network-based mobility, the PMIPv6 protocol
defines a Mobile Access Gateway (MAG), which acts as a proxy for the
Mobile IPv6 signaling, and the Local Mobility Anchor (LMA) which acts
similar to a Home Agent. The LMA and the MAG establish a
bidirectional tunnel for forwarding all data traffic belonging to the
Mobile Nodes.
Both the Mobile IPv6 and Proxy Mobile IPv6 offer mobility support at
the cost of handling operations at a cardinal point, the mobility
anchor, and burdening it with data forwarding and control mechanisms
for a great amount of users. As stated in [I-D.chan-distributed-
mobility-ps], centralized mobility solutions are prone to several
problems and limitations: longer (sub-optimal) routing paths,
scalability problems, signaling overhead (and most likely a longer
associated handover latency), more complex network deployment, higher
vulnerability due to the existence of a potential single point of
failure, and lack of granularity on the mobility management service
(i.e., mobility is offered on a per-node basis, not being possible to
define finer granularity policies, as for example per-application).
In the paper "A Network-based Localized Mobility Solution for
Distributed Mobility Management" [Net-basedDMM], the authors describe
two approaches: one is fully distributed approach and another is
partially distributed approach. The main issue in the first one is
how a Mobility Anchor and Access Router (MAAR) can differentiate
between the first attachment to the network and subsequent handovers.
This document describes MAAR and AAA supporting for managing IP
mobility on behalf of the host. This solution not only can settle
the issue that mobility entities can differentiate between the first
attachment to the network and subsequent handovers, but also reduce
the heavy burdens on home mobility anchor. The MN can directly
forward packages to the CN. The packages don't need to pass the home
mobility anchor. This document strictly abides by the two
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 4]
Internet-Draft A RO solution support for DMM January 2012
principles. The first one is that the MN's movement is transparent
to CN. Another one is the MN doesn't participate in any mobility-
related signaling.
2. Conventions used in this document
2.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
2.2. Terminology
The document also uses the terminology define in [RFC6275].The
following terminology is also used:
MAAR (Mobility anchor and Access Router). First hop routers where
the mobile nodes attach to. They can play the role of mobility
managers for the IPv6 prefixes they anchor, or can for the IPv6
addresses they anchor. In this draft, MAAR assigns the IPv6 address
for each currently registered MN. So that MAAR can performs mobility
management on behalf of a mobile node. Every MAAR is responsible for
detecting the mobile node's movements to and from the access link and
for initiating binding registrations.
AAA (Authentication, Authorization and Accounting ). AAA server
records the user's static and dynamic information. The dynamic
information includes the address information of MAAR which the MN is
registered right now.
DBU/DBA (Distributed BU/BA). A MAAR sends the DBU/DBA message to
another MAAR for establishing or updating corresponding binding list.
In this draft, we have two kinds of the DBU/DBA message. One is the
sDBU/sDBA message and another is the dDBU/dDBA message.
sDBU/sDBA. The MAAR attached by the MN currently to sends a sDBU
message to the MAAR attached by MN before the MN's movement. After
that, the MAAR attached by MN currently receives a sDBA message
including the address of CN's MAAR which the CN is currently attached
to. After that, the MAAR attached by the MN currently updates its
internal binding list.
dDBU/dDBA. The MAAR attached by the MN currently sends a dDBU
message to the MAAR attached by CN for refreshing the internal
binding list of the CN's MAAR which the CN is currently attached to.
After receiving the dDBU message, the CN's MAAR replies a dDBA
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 5]
Internet-Draft A RO solution support for DMM January 2012
message to the MN's MAAR.
3. MAAR Operation
In this draft, the packages sent by the MN or the CN don't need to go
by the home mobility anchor. In this solution, both of MN and CN
move to the MAARs' access links and get the corresponding addresses
assigned by corresponding MAARs. For example, a user A (this user A
can be thought as a MN) attaches to the A_MAAR1's access link, and
establishes the first communication with a user B (this user B can be
thought as a CN). At same time, the user B attaches to the B_MAAR1's
access link. After that, both the user A and B move and respectively
attach to the A_MAAR2's access link and the B_MAAR2's access link.
In this solution, the packages sent by the MN or the CN don't need to
pass the A_MAAR1 and the B_MAAR1.This section describes the
operational details.
3.1. Operation between MAAR and AAA
MAAR MUST send a diameter request message to the AAA when detects the
MN's movement to its access link. After receiving the message, the
AAA checks the dynamic information by using the MN's ID. If the AAA
finds the address information of the MAAR which attached by the MN
before its movement, then the AAA sends a diameter response message
with the address of the MAAR attached by the MN before its movement.
If the AAA can't find this information, then the MAAR receives the
diameter response message with the zero address. After that, the
MAAR will differentiate between the first attachment to the network
and subsequent handovers. Sending out the diameter response message,
the AAA MUST update the dynamic information including the address
information of MAAR which the MN is currently attached to.
3.2. The assumptions about a session
The Home Address (HoA) and Care-of address (CoA) is not for users but
also for specific sessions. For a user initiating a session or
accepting a session, no matter how it moves, the HoA for the session
is unchanged, while the CoA for the session is changed.
The MN (the user A) initiates a session with the CN (the user B) by
using the address (A_HoA1) assigned by A_MAAR1 which the user A is
registered as the HoA for the session. The user B accepts this
session by using the address (B_HoA1) assigned by B_MAAR1 which the
user B is registered as the HoA for this session.
When the user A moves from its current access link, it associates to
a new MAAR (A_MAAR2) which delegates another IPv6 address (A_HoA2).
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 6]
Internet-Draft A RO solution support for DMM January 2012
The A_HoA2 can be both thought as a CoA of the user A and a CoA of
the session. If the user A sends packages to the user B, the source
address must be A_HoA1, and the destination address must be
B_HoA1.The user A can initiate a new session with a new CN (for
example a user C) by using A_HoA2 which the user A can be registered
as the HoA for the new session. If the user A sends packages to the
user C, the source address must be A_HoA2.
When the user B moves from its current access link, it associates to
a new MAAR (B_MAAR2) which delegates another IPv6 address (B_HoA2).
The B_HoA2 can be both thought as a CoA of the user B and a CoA of
the session. If the user B sends packages to the user A, the source
address must be B_HoA1, and the destination address must be
A_HoA1.The user B can initiate a new session with a new MN (for
example a user D) by using the B_HoA2 which the user B can be
registered as the HoA for the new session. If the user B sends
packages to the user D, the source address must be B_HoA2.
3.3. Binding list in MAAR
Every MAAR must maintain two binding lists for each currently
registered mobile node. One is the internal binding list, and
another is the external binding list. The first one maintains a
binding of CN's HoA and the address of CN's MAAR. The CN's HoA is
the address which the CN accepting the session and registering as the
HoA of the session. The second one maintains a binding of MN's HoA
and MN's CoA. The MN's HoA is the address which the MN initiating
the session and registering as the HoA of the session. The MN's CoA
is assigned by the MAAR which the MN is currently attached to. The
external binding list is used to transmit packets to MN. The
internal binding list is used to transmit packets from MN.
For example, the A_MAAR2 of the user A stores two binding lists. One
is the internal binding list, and another is the external binding
list. The first list stores a binding of B_HoA1 and the address of
the MAAR attached by the user B currently. The second one stores a
binding of A_HoA1 and A_HoA2.The B_MAAR2 of the user B stores two
binding lists. One is the internal binding list, and another is the
external binding list. The first list stores a binding of A_HoA1 and
the address of the MAAR which the user A is currently attached to.
The second one stores a binding of B_HoA1 and B_HoA2.
3.4. Operation between MAARs
If the MAAR which the MN is currently attached to learns that the MN
is the handover attachment, the MAAR will send a sDBU message to the
MAAR attached by the MN before its movement. The address information
of the MAAR attached by the MN before its movement is included in the
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 7]
Internet-Draft A RO solution support for DMM January 2012
diameter response message. At this time, the MAAR attached by the MN
before its movement has two binding lists. One is the internal
binding list, and another is the external binding list. After
receiving the sDBU message, the MAAR searches the internal binding
list by using the CN's HoA and gets the address of the MAAR which the
CN is currently attached to. After that, the MAAR attached by the MN
before its movement will send a sDBA message including the MN's HoA,
the CN's HoA and the address of the MAAR which the CN is currently
attached to.
If the MAAR which the MN is currently attached to receives the sDBA
message, the MAAR sends a dDBU message to the MAAR attached by the CN
currently including the address of the MAAR attached by the MN
currently. After receiving the dDBU message, the MAAR attached by
the CN currently refreshes the internal binding list. The MN's MAAR
and the CN's MAAR establish a bidirectional tunnel for forwarding all
data traffic belonging to the MN.
4. Description of the solution
The purpose of Distributed Mobility Management approaches is to
overcome the limitations of the traditional centralized mobility
management by bringing the mobility anchor closer to the MN.
Following this idea, in our proposal, the central anchor is moved to
the edge of the network, being deployed in the access router of the
mobile node. That is, the first elements that provide IP
connectivity to a set of MNs are also the mobility managers for those
MNs. In the following, we will call MAAR (Mobility anchor and Access
Router).
Upon the user A attaches to a MAAR, say A_MAAR1, the user A
establishes the first communication with the user B. At the same
time, the user B attaches to a MAAR, say B_MAAR1.After that, the user
A moves from its current access and is now attached to A_MAAR2. The
user B moves from its current access and is now attached to
B_MAAR2.A_HoA1 is the address of the user A assigned by A_MAAR1.
A_HoA2 is the address of the user A assigned by A_MAAR2. B_HoA1 is
the address of the user B assigned by B_MAAR1. B_HoA2 is the address
of the user B assigned by B_MAAR2.When the user A moves from its
current access, it associates to A_MAAR3 which delegates another IPv6
address (A_HoA3). Figure 1 illustrates this scenario.
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 8]
Internet-Draft A RO solution support for DMM January 2012
+----------+ +----------+ +-------+ +-------+ +-------+ +-----+
|The user A| |The user B| |A_MAAR2| |B_MAAR2| |A_MAAR3| | AAA |
+----------+ +----------+ +-------+ +-------+ +-------+ +-----+
| | | | | |
|--------------1.RS(A_HoA1,B_HoA1)-------------->| |
| | | | |-2.request-->|
| | | | |<-3.response-|
|<-------------------4.RA(A_HoA3) ---------------| |
| | | | | |
| | |<-------5.sDBU -------| |
| | |------6. sDBA ------->| |
| | | |<-7.dDBU --| |
| | | |--8.dDBA ->| |
| | | | | |
Figure 1:Signaling of MN handover
(1) The user A sends a RS message to A_MAAR3 including A_HoA1 and
B_HoA1;
(2) A_MAAR3 sends a diameter request message to the AAA.
(3) The AAA searches the dynamic information by using the ID of the
user A for getting the address of A_MAAR2. Then the AAA sends a
diameter response message including the address of A_MAAR2, and
updates the dynamic information of the user A including the address
information of A_MAAR3 at same time.
(4) A_MAAR3 delegates another IPv6 address (A_HoA3) to the user A. At
the same time, A_MAAR3 establishes and maintains the external binding
list which stores a binding of A_HoA1 and A_HoA3.Then A_MAAR3 sends a
RA message to the user A including A_HoA3;
(5) A_MAAR3 sends a sDBU message to A_MAAR2 including B_HoA1;
(6) Now A_MAAR2 has two binding lists. One is the internal binding
list, and another is the external binding list. The first one
maintains a binding of B_HoA1 and the address of B_MAAR2.The second
one maintains a binding of A_HoA1 and A_HoA2. After receiving the
sDBU message, A_MAAR2 searches the internal binding list by using the
B_HoA1 for getting the address of B_MAAR2.Then A_MAAR2 sends a sDBA
message including B_HoA1 and the address of B_MAAR2.After that,
A_MAAR2 releases this two binding lists;
(7) After receiving the sDBA message, A_MAAR3 establishes and
maintains the internal binding list which maintains a binding of
B_HoA1 and the address of B_MAAR2. Then A_MAAR3 sends a dDBU message
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 9]
Internet-Draft A RO solution support for DMM January 2012
to B_MAAR2 including the address of A_MAAR3 and A_HoA1;
(8) After receiving the dDBU message, B_MAAR2 replies a dDBA message
and updates the internal binding list which maintains a binding of
A_HoA1 and the address of A_MAAR2.After that, this list maintains a
binding of A_HoA1 and the address of A_MAAR3.
5. Forwarding Considerations
5.1. Forwarding Packets Sent by the Mobile Node
After receiving the packages sent by the MN, the MAAR will search the
internal binding list by using the destination address of the
packages for getting the address of the MAAR which the CN is
currently attached to. Then, the MAAR encapsulates the packages and
routes the packages to the corresponding MAAR attached by the CN
currently.
After receiving the packages, the corresponding MAAR will do three
things. Firstly, the corresponding MAAR will remove the tunnel head.
Secondly, the corresponding MAAR will check whether the destination
address of the packages is assigned by this corresponding MAAR or
not. If the destination address of the packages is assigned by this
corresponding MAAR, the corresponding MAAR will route the packages to
the corresponding CN directly. If the destination address of the
packages is not assigned by this corresponding MAAR, the
corresponding MAAR will search the external binding list by using the
destination address of the packages for getting the CoA of the
corresponding CN. Finally, the corresponding MAAR will route the
packages to the corresponding CN. Figure 2 illustrates the
transmission of data packets.
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 10]
Internet-Draft A RO solution support for DMM January 2012
________ ________
|The user| |The user|
| B |----------move--------->| B |
|________| |________|
# *
# *
# *
+-------+ +-------+
| | | |
|B_MAAR1| |B_MAAR2|
| | / | |
+-------+ / +-------+
/ # /| * |
/ # / | * |
/ # / | * |
/ # / | * |
/ # / | * |
/ # / | * |
+-------+ +-------+ # / +-------+
| | | | / | |
|A_MAAR1| |A_MAAR2| / |A_MAAR3|
| | | | | |
+-------+ +-------+ +-------+
# *
# *
# *
________ ________ ________
|The user| |The user| |The user|
| A |-move->| A |---move--->| A |
|________| |________| |________|
Figure 2:The transmission of data packets
Upon the user A attaches to a MAAR, say A_MAAR1, the user A
establishes the first communication with the user B. At the same
time, the user B attaches to a MAAR, say B_MAAR1.After that, the user
A moves from its current access and is now attached to A_MAAR2. The
user B moves from its current access and is now attached to
B_MAAR2.A_HoA1 is the address of the user A assigned by A_MAAR1.
A_HoA2 is the address of the user A assigned by A_MAAR2. B_HoA1 is
the address of the user B assigned by B_MAAR1. B_HoA2 is the address
of the user B assigned by B_MAAR2.When the MN moves from its current
access link, it associates to A_MAAR3 which delegates another IPv6
address (A_HoA3).
At this time, the A_MAAR3 of the user A stores two binding lists.
One is the internal binding list, and another is the external binding
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 11]
Internet-Draft A RO solution support for DMM January 2012
list. The first list maintains a binding of B_HoA1 and the address
of B_MAAR2. The second one maintains a binding of A_HoA1 and A_HoA3.
The B_MAAR2 of the user B stores two binding lists. One is the
internal binding list, and another is the external binding list. The
first list maintains a binding of A_HoA1 and the address of A_MAAR3.
The second one maintains a binding of B_HoA1 and B_HoA2.
If the user A sends the packages to the user B, the destination
address of the packages must be B_HoA1, and the source address of the
packages must be A_HoA1. A_MAAR3 receives the packages and then
searches the internal binding list by using the destination address
of the packages (B_HoA1) for getting the address of B_MAAR2. Then
A_MAAR3 encapsulates the packages and routes to B_MAAR2. The source
address of the tunnel header is the address of A_MAAR3, and the
destination address is the address of B_MAAR2.The format of the
tunneled packet is shown below:
IPv6 header (src= A_MAAR3's address, dst= B_MAAR2's address) /*
Tunnel Header */
IPv6 header (src= A_HoA1, dst= B_ HoA1 ) /* Packet Header */
Upper layer protocols /* Packet Content*/
After receiving the packages, B_MAAR2 removes the tunnel head and
find the destination address of the packages (B_HoA1) is not assigned
by B_MAAR2.Then B_MAAR2 searches the external binding list by using
the destination address of the packages (B_HoA1) for getting the CoA
of the user B. Finally, B_MAAR2 gets a binding of B_HoA1 and B_HoA2
and routes the packages to the user B.
5.2. Forwarding Packets to the Mobile Node
After receiving the packages sent by the CN, the MAAR attached by the
CN will search the internal binding list by using the destination
address of the packages for getting the address of the MAAR which the
MN is currently attached to. Then, the MAAR encapsulates the
packages and routes the packages to the corresponding MAAR which the
MN is currently attached to.
After receiving the packages, the corresponding MAAR will do three
things. Firstly, the corresponding MAAR will remove the tunnel head.
Secondly, the corresponding MAAR will check whether the destination
address of the packages is assigned by this corresponding MAAR or
not. If the destination address of the packages is assigned by this
corresponding MAAR, the corresponding MAAR will route the packages to
the corresponding MN directly. If the destination address of the
packages is not assigned by this corresponding MAAR, the
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 12]
Internet-Draft A RO solution support for DMM January 2012
corresponding MAAR will search the external binding list by using the
destination address of the packages for getting the CoA of the
corresponding MN. Finally, the corresponding MAAR will route the
packages to the corresponding MN.
As shown in figure 2, if the user B sends the packages to the user A,
the destination address of the packages must be A_HoA1, and the
source address of the packages must be B_HoA1.B_MAAR2 receives the
packages and then searches the internal binding list by using the
destination address of the packages (A_HoA1) for getting the address
of A_MAAR3. Then B_MAAR2 encapsulates the packages and routes to
A_MAAR3. The source address of the tunnel header is the address of
B_MAAR2, and the destination address is the address of A_MAAR3.The
format of the tunneled packet is shown below:
IPv6 header (src= B_MAAR2's address, dst= A_MAAR3's address) /*
Tunnel Header */
IPv6 header (src= B_HoA1, dst= A_ HoA1 ) /* Packet Header */
Upper layer protocols /* Packet Content*/
After receiving the packages, A_MAAR3 removes the tunnel head and
find the destination address of the packages (A_HoA1) is not assigned
by A_MAAR3. Then A_MAAR3 searches the external binding list by using
the destination address of the packages (A_HoA1) for getting the CoA
of the user A. Finally, A_MAAR3 gets a binding of A_HoA1 and A_HoA3
and routes the packages to the user A.
6. Message Formats
This section defines extensions to the Mobile IPv6 [RFC6275] protocol
messages.
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 13]
Internet-Draft A RO solution support for DMM January 2012
6.1. sDBU
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|D|E| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mobility Options |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3:sDBU
A Binding Update message that is sent by the MAAR attached by MN
currently to the MAAR attached by MN before the MN's movement is
referred to as the "sDBU" message. A new flag D and E are included
in the Binding Update message. The rest of the Binding Update
message format remains the same as defined in [RFC6275] and with the
additional (R) and (M) flags, as specified in [RFC3963] and
[RFC4140], respectively.
Distributed Flag (D)
If the D is set to 0, this message is the BU message in the
[RFC6275]. If the D is set to the value 1, this message is the
Distributed Binding Update message (DBU).The flag MUST be set to the
value of 1 in the draft.
A new Flag (E)
If the E is set to 0, this DBU message is the sDBU message. This
flag MUST be set to 0.
Mobility Options
The sDBU message is sent by the MAAR attached by the user A currently
to the MAAR attached by the user A before its movement including the
ID of the user A, A_HoA1 and B_HoA1.
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 14]
Internet-Draft A RO solution support for DMM January 2012
6.2. sDBA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|D|E|Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mobility Options |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4:sDBA
A Binding Acknowledgement message that is sent by the MAAR attached
by MN before the MN's movement to the MAAR attached by MN currently
is referred to as the "sDBA" message. A new flag D and E are
included in the Binding Acknowledgement message. The rest of the
Binding Acknowledgement message format remains the same as defined in
[RFC6275] and with the additional (R) as specified in [RFC3963].
Distributed Flag (D)
If the D is set to 0, this message is the BA message in the
[RFC6275]. If the D is set to the value 1, this message is the
Distributed Binding Acknowledgement message (DBA).The flag MUST be
set to the value of 1 in the draft.
A new Flag (E)
If the E is set to 0, this DBA message is the sDBA message. This
flag MUST be set to 0.
Mobility Options
The sDBA message is sent by the MAAR attached by the user A before
its movement to the MAAR attached by the user A currently including
A_HoA1,B_HoA1 and the address of the MAAR attached by the user B
currently.
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 15]
Internet-Draft A RO solution support for DMM January 2012
6.3. dDBU
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|D|E| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mobility Options |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5:dDBU
A Binding Update message that is sent by the MN's MAAR attached by
the MN currently to the CN's MAAR which the CN is currently attached
to is referred to as the "dDBU" message. A new flag D and E are
included in the Binding Update message. The rest of the Binding
Update message format remains the same as defined in [RFC6275] and
with the additional (R) and (M) flags, as specified in [RFC3963] and
[RFC4140], respectively.
Distributed Flag (D)
If the D is set to 0, this message is the BU message in the
[RFC6275]. If the D is set to the value 1, this message is the
Distributed Binding Update message (DBU).The flag MUST be set to the
value of 1 in the draft.
A new Flag (E)
If the E is set to the value of 1, this DBU message is the dDBU
message. This flag MUST be set to the value of 1.
Mobility Options
The dDBU message is sent by the MAAR attached by the user A currently
to the MAAR which the user B is currently attached to including
A_HoA1 and the address of the MAAR currently attached by the user A.
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 16]
Internet-Draft A RO solution support for DMM January 2012
6.4. dDBA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|D|E|Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mobility Options |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6:dDBA
A Binding Acknowledgement message that is sent by the CN's MAAR
currently attached by the CN to the MN's MAAR which the MN is
currently attached to is referred to as the "dDBA" message. A new
flag D and E are included in the Binding Acknowledgement message.
The rest of the Binding Acknowledgement message format remains the
same as defined in [RFC6275] and with the additional (R) as specified
in [RFC3963].
Distributed Flag (D)
If the D is set to 0, this message is the BA message in the
[RFC6275]. If the D is set to the value 1, this message is the
Distributed Binding Acknowledgement message (DBA).The flag MUST be
set to the value of 1 in the draft.
A new Flag (E)
If the E is set to the value of 1, this DBA message is the dDBA
message. This flag MUST be set to the value of 1.
Mobility Options
The dDBA message is sent by the MAAR currently attached by the user B
to the MAAR which the user A is currently attached to including
A_HoA1 and B_HoA1.
7. IANA Considerations
TBD.
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 17]
Internet-Draft A RO solution support for DMM January 2012
8. Security Considerations
TBD.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
9.2. Informative References
[I-D.chan-distributed-mobility-ps]
Chan, A., "Problem statement for distributed and dynamic
mobility management", October 2011.
[Net-basedDMM]
Giust, F., de la Oliva, A., Bernardos, CJ., and RP.
Ferreira Da Costa, "A Network-based Localized Mobility
Solution for Distributed Mobility Management", 2011.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
Gateway and Local Mobility Anchor Interaction with
Diameter Server", RFC 5779, February 2010.
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 18]
Internet-Draft A RO solution support for DMM January 2012
Authors' Addresses
Zhengming Ma
SUN YAT-SEN UNIVERSITY
Department of Electronics and Engineering,daxuecheng,210
Zhongshan University,Guangzhou, 510006
P.R. China
Email: issmzm@mail.sysu.edu.cn
Xun Zhang
SUN YAT-SEN UNIVERSITY
Department of Electronics and Engineering,daxuecheng,210
Zhongshan University,Guangzhou, 510006
P.R. China
Email: zhangxunkuaile@yeah.net
Zhengming Ma & Xun Zhang Expires July 7, 2012 [Page 19]
