Network Mobility Support in the Distributed Mobility Management
draft-xuan-dmm-nemo-dmm-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | xuan@dcn.ssu.ac.kr , Younghan Kim | ||
| Last updated | 2013-10-21 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xuan-dmm-nemo-dmm-01
<Distributed Mobility Management> Truong-Xuan Do
Internet Draft Younghan Kim
Intended status: Informational Soongsil University, Korea
Expires: April2014 October 21, 2013
Network Mobility Support in the Distributed Mobility Management
draft-xuan-dmm-nemo-dmm-01.txt
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), 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 21,2014.
Copyright Notice
Copyright (c) 2013 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.
<Lastname> Expires April21,2014 [Page 1]
Internet-Draft <NEMO support in the DMM> October 2013
Abstract
Network mobility (NEMO) provides session continuity for mobile nodes
(MN) while moving in vehicles without their involvement in signaling
process. NEMO Basic support protocol [RFC3963] is standardized to
provide network mobility support.
Current mobility management protocols, such as MIPv6 [RFC6275] and
PMIPv6 [RFC5213], rely on a central mobility anchor in order to
provide mobility support for the mobile nodes. These centralized
approaches show some big issues, such as a single point of failure,
non-optimal routing, and scalability. Ever-increasing demand for the
mobile traffic changes the network architecture from hierarchical to
flat architecture, and distributed mobility management (DMM)
approaches are being researched to adapt the new flat architecture
and overcome big above issues.
This document presents about detailed protocol operation to support
network mobility in the DMM domain.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................3
3. Protocol Operation.............................................4
3.1. The attachment procedure of PR............................4
3.2. The attachment procedure of MN............................5
3.3. The handover procedure of PR from p-MAR to n-MAR..........6
3.4. The handover procedure of MN from PR to outside network...7
3.5. Lifetime management for binding entries...................8
4. Considerations for fully distributed DMM.......................8
5. Binding Entry Information......................................9
5.1. Binding cache entry in MAR................................9
5.2. Cache entry in the CDB....................................9
6. Security Considerations.......................................10
7. IANA Considerations...........................................10
8. References....................................................10
8.1. Normative References.....................................10
8.2. Informative References...................................10
<Do, et al.> Expires April21,2014 [Page 2]
Internet-Draft <NEMO support in the DMM> October 2013
1. Introduction
Network mobility (NEMO) [RFC3963] is used to provide mobilitysupport
for a group of mobile nodes. This solution allows the mobile nodes
to access Internet from a device called mobile router. This router
is used to handle mobility signaling on behalf of mobile node
attached to it. However, this approach is host-based and causes high
signaling and packet delivery overhead.
Some other network mobility management approaches, such as PRNEMO
[Jeon2011] which are PMIPv6-based have been defined in the research
groups. These approaches have some advantages over host-based
network mobility management ones, such as not require host stack
involvement, handover delay improvement.
However, all of these approaches are centralized that means all
mobility management functions are centralized at a mobility anchor.
These centralized approaches suffer from major issues, such as a
single point of failure, wasting network resources and scalability,
as defined in [Chan2013]. New trend in the evolution of mobile
network is going toward flat architecture. In the flat architecture,
the distributed mobility management (DMM) which distributes mobility
management functions into access networks has been proposed to
overcome the big issues of the centralized approaches.
This document presents about detailed protocol operation to support
network mobility in the DMM domain. In our scheme, the proxy router
which is responsible for handling mobility related signaling will
cache the IDs and prefixes of the attached mobile nodes. When the
proxy router moves from one cell to another, it will get the new
network prefixes for all attached mobile nodes and distribute to
each mobile node via the router advertisement messages. This allows
our network mobility management scheme to take the advantages of
DMM. In this document, we use partially PMIPv6-based DMM approach
in [Seite2013] to enable network mobility support.
2. Conventions used in this document
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 RFC-2119 [RFC2119].
o Proxy router (PR) - It will detect the MN's movement and perform
mobility signaling on behalf of mobile nodes when moving from
one cell to another
<Do, et al.> Expires April21,2014 [Page 3]
Internet-Draft <NEMO support in the DMM> October 2013
o Previous Mobility Access Router (p-MAR) - It is an access router
which provide mobility management functions, such as location
management, location update, packet tunneling.
o Central database (CDB) - It is a central database which is used
to store mobility session information of the MN and the PR.
3. Protocol Operation
3.1. The attachment procedure of PR
PR p-MAR CDB
| | |
|--L2 Attach----->| |
| | |
|-------RS------->| |
| ('G', PR-ID) | |
| Update |
| Binding cache |
| | |
| |<--Session update-->|
|<------RA--------| |
| (pref1) | |
Configure
an IP address
(pref1::PR-ID)
Figure 1 The attachment procedure of the PR
When a proxy router (PR) approaches the DMM domain, the event is
detected by the p-MAR using the Layer 2 signals. Then, the PR sends
the router solicitation message (RS) containing the ID of the PR,
'G' flag set to 1 toward the p-MAR. In our scheme, in order to
distinguish between the RS messages of the PR and the mobile node
(MN), we use the 'G' flag. The PR sends the RS message with 'G' flag
set to 1, but the MN sends the RS message without 'G' flag. On
receiving the RS message, the p-MAR will make an binding cache
entry, including the ID of PR, the assigned network prefix, the
anchor point, the 'D' flag, and the group ID. In this binding cache,
'D' flag is used to know whether the PR or MN attach directly to the
mobility access router (MAR) or not. All mobile nodes and its proxy
router have the same group ID value. Then, the p-MAR performs the
mobility session update to the central database, as defined in
[Seite2013]. The p-MAR will assign a network prefix pref1 for the
<Do, et al.> Expires April21,2014 [Page 4]
Internet-Draft <NEMO support in the DMM> October 2013
PR and sends it back via the RA message. After receiving the pref1,
the PR can configure an IPv6 address.
3.2. The attachment procedure of MN
MN PR p-MAR CN1 CDB
| | | | |
|--L2 Attach----->| | | |
| | | | |
|-------RS------->| | | |
| (MN-ID) |------RS-------->| | |
| | ('P','G', MN-ID)| | |
| | Update | |
| | Binding cache | |
| | | | |
| |<------RA--------| | |
| | ('P', pref2) | | |
| Cache ID |<------Session update---->|
| and prefix | | |
| of MN | | |
| | | | |
|<------RA--------| | | |
| (pref2) | | | |
Configure | | | |
an IP address | | | |
(pref2::MN-ID) | | | |
| | | | |
|<----------------Data flow to pref2 ----------->| |
Figure 2 MN attachment to the DMM domain
When an MN attaches to the PR, it sends its ID to the PR via RS
message. The PR will forward this RS message with 'P' and 'G' flags
set to 1 to the p-MAR. 'P' flag means this RS is the proxy RS sent
by the PR on behalf of the MN. 'G' flag is used to request the p-MAG
to assign a group ID for the MN. After receiving this RS message,
the p-MAG will assign a network prefix pref2 for the MN and assign
the same group ID as the PR. 'D' flag is set to 0 means the MN
attaches to the PR not the p-MAR. Then, the p-MAG sends the network
prefix pref2 to the PR and at the same time performs session update
to the CDB. On receiving the RA message, the PR will cache the ID
and the prefix of the MN for later handover operation. After
<Do, et al.> Expires April21,2014 [Page 5]
Internet-Draft <NEMO support in the DMM> October 2013
receiving the pref2, the MN can configure an IPv6 address and
initiate and maintain the data session using this address. In this
case, the data packets which go to the IP address pref2::MN-ID will
be routed to the p-MAR. Then, the p-MAR will perform recursive
lookup in its binding cache, if the anchor point for this address is
the p-MAR, the data packets will be routed to the PR, finally to the
MN without adding any tunnel headers.
3.3. The handover procedure of PR from p-MAR to n-MAR
MN PR p-MAR n-MAR CN1 CN2 CDB
| | | | | | |
| Handover | | | | |
| |------------RS----------->| | | |
| | ('G', PR-ID, MN-ID) Update | | |
| | | Binding cache | | |
| | | | | | |
| |<-----------RA------------|<--Get previous MAR-->|
| | (pref3, pref4) | of PR |
| Cache new | | | | |
| prefix of MN | | | | |
|<----RA------| | | | | |
| (pref4) | |<----PBU----| | | |
Configure | |('G',PR-ID, | | | |
an IP address | | n-MAG) | | | |
(pref4::MN-ID) | |----PBA---->| | | |
| | Update | | | |
| | Binding cache | | | |
| | | | | | |
| | |<-Data flow to pref2(#1)->| | |
| | |<===(#1)===>| | | |
|<---(#1)---->|<=========(#1)===========>| | | |
| | | | | |
|<------------Data flow to pref4(#2)---->|<------(#2)----->| |
Figure 3 Handover operation
When the PR handovers from the p-MAR to the n-MAR, the PR will send
a RS message, including its ID and the IDs of all attached MN to the
n-MAR in order to request new network prefixes for the attached MNs.
On receiving this RS message, the n-MAG will make new binding cache
entries. When receiving a RS message with more than one ID, the n-
MAR will consider the first ID as the ID of the PR and also assign
the same group ID, new network prefixes: pref3, pref4. The 'D' flag
in the entry of the first ID is set to 1 and of other IDs are set to
<Do, et al.> Expires April21,2014 [Page 6]
Internet-Draft <NEMO support in the DMM> October 2013
0. Then, the n-MAR will query to the CDB to get the previous anchor
points of the PR. The n-MAR will send a PBU message, containing the
new location of the PR to the p-MAR to establish a tunnel. On
receiving new network prefixes from the RA message, the MN also
configure a new IP address pref4::MN-ID.
For the data delivery operation, the data flow to the old IP address
of the MN will be routed to the p-MAR. At the p-MAR, the data
packets will be added two tunnel headers, the outer header is the IP
address of the n-MAR and the inner header is the IP address of the
PR. The data packets will be de-capsulated at the n-MAR and the PR,
finally sent to the MN. The data flow to the new IP address of the
MN will be routed to the currently attached anchor point, i.e.
n-MAR, then to the PR, finally to the MN without adding any tunnel
headers.
3.4. The handover procedure of MN from PR to outside network
MN p-MAR n-MAR CN1 CN2 CDB
| | | | | |
Detachment | | | | |
from PR | | | | |
|----------L2 attachment-------------->| | | |
|---------------RS-------------------->| | | |
| (MN-ID) Update | | |
| Binding cache | | |
|<--------------RA---------------------|<---Session update--->|
| (pref4) | |<--Get previous MAR-->|
| | | of MN |
| |<-----PBU-------| | | |
| | (MN-ID, n-MAR) | | | |
| |-------PBA----->| | | |
| Update | | | |
| Binding cache | | | |
| |<----Data flow to pref2(#1)-->| | |
| |<====(#1)======>| | | |
|<----------------(#1)---------------->| | | |
|<-----------Data flow to pref4(#2)--->|<------(#2)----->| |
Figure 4 The MN handovers to outside network
After detaching from the PR, the MN attaches to the n-MAR. The MN
sends a RS message with 'G' flag set to 0 to the n-MAR. The n-MAR
will update the binding cache entry for the MN. The 'D' flag for
the binding entry of the MN set to 1 means the MN attaches directly
to the n-MAR and the group ID will be deleted. Next steps are
<Do, et al.> Expires April21,2014 [Page 7]
Internet-Draft <NEMO support in the DMM> October 2013
similar to the handover procedure of the PR. The n-MAR also queries
to the central database to get previous anchor points of the MN,
and then sends a PBU message to update the new location of the MN.
For the packet delivery operation, the data packets to the old IP
address of the MN will be routed to the p_MAR. At the p-MAR, data
packets will be added one tunnel header which is the IP address
of the n-MAR. These data packets will be de-capsulated at the n-MAR,
and sent to the MN. For the data packets to the new IP address of
the MN, the data packets will be routed to the n-MAR and to the MN
without adding any tunnel headers.
3.5. Lifetime management for binding entries
The number of binding entries in the binding caches in the MAR
and the CDB increases with the attachment of new mobile nodes. A
mechanism is needed to clean unused entries in these binding caches.
There are two solutions to do this task:
o A lifetime value is set for each binding entry. When this
lifetime value expires, the binding entry will be removed from
the cache of MAR or CDB.
o After receiving the PBU message of the MN, the previous MAR waits
until the data session toward the prefix assigned to the MN
finishes. Then, the previous MAR will remove the binding entry
related to the MN and the prefix of finished session. Then, the
previous MAR sends a de-registration message to the CDB to remove
the mobility session information of the MN from the binding cache
of the CDB.
4. Considerations for fully distributed DMM
In the fully distributed DMM, both data plane and control plane
are processed in the MARs. The central database becomes useless in
the full architecture. The information about mobility sessions is no
longer stored in the central database, but is exchanged between the
previous MAR and next MAR using control messages. Concretely, when
the previous MAR finishes assigning prefixes for the PR or the MN,
instead of updating these mobility sessions to the CDB, it can
broadcast the information to its neighboring MARs. The next MAR then
can receive this mobility session information of the PR or the MN
without going to the CDB. The mobility session information includes
the IP addresses of the previous MARs and the prefixes advertised to
the PR and the MN.
<Do, et al.> Expires April21,2014 [Page 8]
Internet-Draft <NEMO support in the DMM> October 2013
5. Binding Entry Information
5.1. Binding cache entry in MAR
In the p-MAR after handover procedure of the PR
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | Prefix | Anchor point | GID | D flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PR-ID | Pref1::/64 | n-MAR | GID1 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-ID | Pref2::/64 | PR | GID1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the n-MAR after handover procedure of the PR
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | Prefix | Anchor point | GID | D flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PR-ID | Pref3::/64 | n-MAR | GID2 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-ID | Pref4::/64 | PR | GID2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Cache entry in the CDB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | Prefix | Anchor point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PR-ID | Pref1::/64 | p-MAR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-ID | Pref2::/64 | p-MAR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PR-ID | Pref3::/64 | n-MAR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-ID | Pref4::/64 | n-MAR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Do, et al.> Expires April21,2014 [Page 9]
Internet-Draft <NEMO support in the DMM> October 2013
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
8. References
8.1. Normative References
[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support
in IPv6", IETF RFC 6275, July 2011.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol,"
IETFRFC 3963, January, 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.
and B. Patil, "Proxy Mobile IPv6", IETF RFC 5213,
Aug. 2008.
8.2. Informative References
[Jeon2011] Jeon, S. and Kim,Y., "Cost-efficient network mobility
scheme over proxy mobile IPv6 network", IET Commun.,
2011, 5, (18), pp. 2656-2661
[Chan2013] Chan, H., "Requirements for distributed mobility
management", draft-ietf-dmm-requirements-09, Sep. 2013
[Seite2013] Seite, P., Bertin, P.:'Distributed mobility anchoring',
draft-seite-dmm-dma-06, Jan. 2013.
<Do, et al.> Expires April21,2014 [Page 10]
Internet-Draft <NEMO support in the DMM> October 2013
Authors' Addresses
Truong-Xuan Do
Soongsil University
4F Hyungnam Engineering Bldg. 424,
(156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea
Phone: +82 10 4473 6869
Email: xuan@dcn.ssu.ac.kr
Younghan Kim
Soongsil University
4F Hyungnam Engineering Bldg. 424,
(156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea
Phone: +82-2-820-0904
Email: younghak@ssu.ac.kr
<Do, et al.> Expires April21,2014 [Page 11]