Internet DRAFT - draft-zhang-dmm-rpmipdmm
draft-zhang-dmm-rpmipdmm
DMM Working Group Hong-Ke Zhang
Internet Draft Li-Li Wang
Expires: September 2012 Bo-Hao Feng
Shuai Gao
Beijing Jiaotong University
March 26, 2012
A Robust Solution for PMIPv6-based Distributed Mobility Management
draft-zhang-dmm-rpmipdmm-00.txt
Abstract
Proxy Mobile IPv6 (PMIPv6) is a network-based centralized mobility
management protocol, which has many disadvantages for utilizing the
centralized anchor LMA. As networks are moving towards flat
architectures, a distributed approach is needed to PMIPv6. This
document defines a robust solution for PMIPv6-based distributed
mobility management which ensures the robustness by organizing the
distributed anchors (MAARs) into a Chord ring.
Requirements Language
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].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September, 2012.
Zhang et al. Expires September,2012 [Page 1]
Internet-Draft A Robust solution for PMIPv6-based DMM March 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.
Table of Contents
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Description of the solution ................................. 4
4. Format of signaling messages ................................ 7
4.1. M-PBU .................................................. 7
4.2. M-PBA .................................................. 8
5. Security Considerations ..................................... 9
6. References .................................................. 9
Acknowledgment ................................................ 10
1. Introduction
The current IP mobility protocols, which are either host-based like
Mobile IPv6 [1] or network-based like Proxy Mobile IPv6 [2], support
the mobility management via centralized anchors. In order to maintain
the IP session when MNs handover, the anchors are mainly responsible
for allocating home network prefixes to MNs, managing their locations
and intercepting as well as forwarding packets that are from or to
MNs. However, such centralized anchors lead to some obvious
shortcomings like sub-optimal routing, scalability problem,
considerable signaling cost and delay and so on.
As the networks are moving towards flat architecture, a distributed
approach is needed to avoid those disadvantages of centralized
mobility protocols. In this distributed scheme, there is no need for
any centralized anchors in the network while only distributed anchors
are deployed. Besides, it is not necessary to identify MNs by the
fixed home addresses or home network prefixes. Some related drafts
have been proposed, but there are not any schemes to guarantee the
Zhang et al. Expires September,2012 [Page 2]
Internet-Draft A Robust solution for PMIPv6-based DMM March 2012
robustness for the distributed mobility management. In this document,
we propose a robust solution for PMIPv6-based distributed mobility
management. This solution ensures the robustness by organizing the
distributed anchors (MAARs) into a Chord ring.
2. Terminology
The following terms used in this document are defined in the Proxy
Mobile IPv6 specification [RFC5213]:
Local Mobility Anchor (LMA)
Mobile Access Gateway (MAG)
Mobile Node (MN)
Corresponding Node (CN)
Proxy Binding Update (PBU)
Proxy Binding Acknowledgment (PBA)
The following terms are defined and/or used in this document:
MAAR (Mobility Anchor and Access Router). First IP hop routers
where the mobile nodes attach to. They provide an IPv6 prefix
(topologically anchored at the MAAR) to each attaching mobile node.
They also play the role of mobility managers for the IPv6 prefixes
they anchor.
M-MAAR (Managed Mobility Anchor and Access Router). The MAAR that
manages all the path of the MN which is distributed assigned in the
Chord ring.
M-PBU (Managed PBU). The signaling message sent by MAAR to the M-MAAR.
It is used to register to M-MAAR for MN recording the MN's path.
M-PBA (Managed PBA). The signaling message sent back by M-MAAR to the
MAAR. It is used to register to M-MAAR for MN recording the MN's path.
Zhang et al. Expires September,2012 [Page 3]
Internet-Draft A Robust solution for PMIPv6-based DMM March 2012
3. Description of the solution
The purpose of this solution is to provide robust distributed
mobility management based on PMIPv6. For this, it is assumed that
there are many MAARs in the management domain and that every MAAR has
a MAAR identifier that is similar to an MN-identifier specified in
RFC 4283 [3]. And every MAAR in this solution functions as both an
LMA for those MNs that are attached to it at the first hop, and a MAG
for those MNs that are connected to it while not attached at the
first hop. Therefore, there are not any centralized anchors in the
architecture of this solution. In addition, all MAARs in this
distributed management domain are organized into a Chord circle using
consistent hashing over MAAR identifiers [4][5]. Given the fact that
the Chord system distributes the information of value among nodes on
the ring, the failure of a MAAR only affects a very limited number of
MAARs in the Chord system, which indicate that this solution for
distributed mobility management based on PMIPv6 is robust. Moreover,
for a given MN, the M-MAAR that manages all the path of this MN in
the distributed management domain is configured by the network
administrator of the domain or by some algorithm and does not change
as long as the MN roams within the domain. The architecture of this
solution is shown in Figure 1.
o @ N1(MAAR)
o o
@ @ N8
o o
@ @ N14
@ o
o @ N21
@ o
o o
@ @ N32
N38 o o
Figure 1: Architecture of the distributed mobility management based
on PMIPv6 using Chord ring
Zhang et al. Expires September,2012 [Page 4]
Internet-Draft A Robust solution for PMIPv6-based DMM March 2012
As stated above, which M-MAAR is configured and responsible for an MN
is unknown to other MAARs when this MN attaches to them. In order to
deal with this issue, we store (key, value) pairs at the MAARs by
using consistent hashing algorithm, where the key is the hash value
of an MN-identifier and the value is the IPv6 address of the M-MAAR
serving the corresponding MN. For a given MN, the IPv6 address of its
M-MAAR should be stored at the MAAR that is the successor of the MN-
identifier. For ease of description, we define QServer(MN) as the
MAAR that stores the (key, value) pair for an MN. Also for simplicity,
we will use MN-id and M-MAAR or the tuple (MN-id, M-MAAR) to
represent both the original and hash value of the MN-identifier and
the IPv6 address of its M-MAAR.
Whenever a new MAAR detects the attachment of an MN, it may not know
the MN's M-MAAR. In this case, it sends a query message including the
MN-identifier, the new MAAR's identifier and IPv6 address to the
Chord system in order to find the MN's M-MAAR. The other MAARs in the
Chord system forward the query message according to their finger
tables until it reaches QServer(MN). When the MAAR that serves as the
QServer of the MN receives the query message, it sends the IPv6
address of the MN's M-MAAR which is defined in the tuple (MN-id, M-
MAAR) back to the new MAAR. When the new MAAR receives the IPv6
address of the MN's M-MAAR, it stores the M-MAAR's IPv6 address into
a table for the attached MN locally.
After knowing the M-MAAR's IPv6 address, the new MAAR (MAAR1) sends
an M-PBU message to the M-MAAR. If the cache about the MN in M-MAAR
is empty, this MAAR1 will also serve as LMA assigning HNP1 for MN as
specified in PMIPv6. And also, the M-MAAR should record one item
including MN-identifier, HNP1 and the IPv6 address of the MAAR1.
However, if there is one item (MN-id, HNP0, the MAAR0's IPv6 address)
in the cache about the MN in M-MAAR, the M-MAAR will return an M-PBA
message containing the corresponding information to the MAAR1 after
receiving the M-PBU message. That is, MAAR1 is not the first hop
router to which the MN accesses. And then MAAR1 sends a register
message (PBU) to the MAAR0 and establishes the bi-directional tunnel
between the MAAR0 and the MAAR1 after receiving the PBA message from
the MAAR0. Besides, in this case the MN could also use the HNP1
allocated by MAAR1 to start a new IP session.
As shown in Figure 2, the paths among the MAARs and the M-MAAR
represented by lines ("/" and "\") indicate registrations between
MAARs and the M-MAAR, while the path depicted with stars ("*")
denotes the query procedure of MAARs for the address of the M-MAAR of
the MN-id in chord ring, and the path pictured with circles ("o" and
"#") shows the data flow from CN1 and CN2 respectively. In Figure 2,
the MN moves from the MAAR1 to the MAAR2. And the MN starts a new
Zhang et al. Expires September,2012 [Page 5]
Internet-Draft A Robust solution for PMIPv6-based DMM March 2012
session with the CN2 when it moves to the MAAR2 and also continues
the session with the CN1 through the MAAR1. The detailed procedure is
described in Figure 3.
+---+ +------+ +----------+ +---+
|CN1| |M-MAAR| |Chord Ring| |CN2|
+---+ +------+ +----------+ +---+
o | * #
o / \ * * #
o / \ * * #
o / \ * * #
o / \ * * #
o / \ * * #
o / * \ * #
o / * \ * #
o / * \ * #
o / * \ * #
o | * | * #
o +-----+ +-----+ #
oooo|MAAR1|(oooooooooo) |MAAR2|#######################
+-----+ tunnel +-----+
o| o|#
+---+ +---+
|MN |-------------->|MN |
+---+ +---+
Figure 2: Scenario after a handover and the data flow
MN MAAR1 MAAR2 M-MAAR MAARs(Chord ring) CN1 CN2
| | | | | | |
|-L2 Attachment->| | | | | |
| |----------------------------->| | |
| (Query for the address of M-MAAR of the MN-id) | |
| | | | | | |
| |<-Reply the address of M-MAAR-| | |
|<-Allocate HNP1-| | | | | |
|(Configure IP address) | | | | |
| | | | | | |
| |-------M-PBU------>| | | |
| (Register to the M-MAAR with address of MAAR1, HNP1 and MN-id) |
| | | | | | |
| |<-------M-PBA------| | | |
Zhang et al. Expires September,2012 [Page 6]
Internet-Draft A Robust solution for PMIPv6-based DMM March 2012
| | | | | | |
|<---------------|<-----------IP Packets with HNP1-----------| |
| | | | | | |
|--------Handover-------->| | | | |
| | | | | | |
|-----L2 Attachment------>| | | | |
| | |-------------------->| | |
| (Query for the address of M-MAAR of the MN-id) | |
| | | | | | |
| | |<-Reply the address--| | |
|<-----Allocate HNP2------| | | | |
| (Configure IP address) | | | | |
| | | | | | |
| | |--------M-PBU------->| | |
| (Register to the M-MAAR with address of MAAR2, HNP2 and MN-id) |
| | | | | | |
| | |<--------M-PBA-------| | |
| | (Reply the address of MAAR1 and HNP1) | |
| | | | | | |
| |<--PBU--| | | | |
| |--PBA-->| | | | |
| (Establish the Tunnel) | | | |
| | | | | | |
| |<------------IP Packets with HNP1----------| |
| |=======>| | | | |
|<------------------------| | | | |
| | | | | | |
|<------------------------|<---------IP Packets with HNP2---------|
| | | | | | |
Figure 3: The detailed procedure of the solution
4. Format of signaling messages
4.1. M-PBU
The format of the M-PBU message is shown in Figure 4.
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhang et al. Expires September,2012 [Page 7]
Internet-Draft A Robust solution for PMIPv6-based DMM March 2012
|A|H|L|K|M|R|P|D| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mobility options |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D flag
1-bit "Distributed" flag is used to identify whether this PBU is from
the MAAR to the M-MAAR. When this flag is set to "0", this message is
the PBU message in the [RFC5213]. If the flag is set to "1", this
message is the M-PBU. The flag MUST be set to the value of 1 in this
draft.
4.2. M-PBA
The format of the M-PBA message is shown in Figure 5.
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|P|D|Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mobility options |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D flag
1-bit "Distributed" flag is used to identify whether this PBA is from
the M-MAAR to the MAAR. When this flag is set to "0", this message is
the PBA message in the [RFC5213]. If the flag is set to "1", this
message is the M-PBA. The flag MUST be set to the value of 1 in this
draft.
Zhang et al. Expires September,2012 [Page 8]
Internet-Draft A Robust solution for PMIPv6-based DMM March 2012
5. Security Considerations
This document does not introduce any security considerations.
6. References
[1] C.Perkins, D.Johnson, and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[2] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B.
Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[3] A. Patel, K. Leung, M. Khalil, H. Akhtar, and K. Chowdhury,
"Mobile node identifier option for mobile IPv6 (MIPv6)", RFC
4283, November 2005.
[4] I. Stoica, R. Morris, D. Liben-Nowell, D. Karger, M. Kaashoek,
F.Dabek, and H. Balakrishnan, "Chord: a scalable peer-to-peer
lookup protocol for Internet applications," IEEE/ACM
Transactions on Networking, vol.11, no.1, pp: 17-32, February
2003.
[5] D. R. Karger, E. Lehman, F. Leighton, M. Levine, D. Lewin, and
R. Panigrahy, "Consistent hashing and random trees: distributed
caching protocols for relieving hot spots on theWorldWideWeb,"
in Proc. 29th Annu. ACM Symp. Theory of Computing, May 1997, pp.
654-663.
Zhang et al. Expires September,2012 [Page 9]
Internet-Draft A Robust solution for PMIPv6-based DMM March 2012
Authors' Addresses
Hong-Ke Zhang, Li-Li Wang, Bo-Hao Feng, Shuai-Gao
National Engineering Lab for NGI Interconnection Devices
Beijing Jiaotong University, China
Phone: +861051684274
Email:hkzhang@bjtu.edu.cn
liliwang@bjtu.edu.cn
11111021@bjtu.edu.cn
shgao@bjtu.edu.cn
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang et al. Expires September,2012 [Page 10]
