Network Mobility Support in the Distributed Mobility Management
draft-xuan-dmm-nemo-dmm-00
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-07-15 | ||
| 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-00
Distributed Mobility Management Truong-Xuan Do
Internet Draft Younghan Kim
Intended status: Informational Soongsil University, Korea
Expires: January 2014 July 2013
Network Mobility Support in the Distributed Mobility Management
draft-xuan-dmm-nemo-dmm-00.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/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 January 15, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
INFO (REMOVE): Choose ONE of the following two paragraphs and omit
the other (see BCP 78 for explanation):
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
<Do> Expires January 15, 2014 [Page 1]
Internet-Draft <NEMO support in the DMM> July 2013
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.
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...................................................2
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
4. Binding Entry Information......................................8
4.1. Binding cache entry in MAR................................8
4.2. Cache entry in the CDB....................................9
5. Security Considerations........................................9
6. IANA Considerations............................................9
7. References.....................................................9
7.1. Normative References......................................9
7.2. Informative References....................................9
1. Introduction
Network mobility (NEMO) [RFC3963] is used to provide mobility
support for a group of mobile nodes. This solution allows the mobile
<Do> Expires January 15, 2014 [Page 2]
Internet-Draft <NEMO support in the DMM> July 2013
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
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.
<Do> Expires January 15, 2014 [Page 3]
Internet-Draft <NEMO support in the DMM> July 2013
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
PR and sends it back via the RA message. After receiving the pref1,
the PR can configure an IPv6 address.
<Do> Expires January 15, 2014 [Page 4]
Internet-Draft <NEMO support in the DMM> July 2013
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 the 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
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
<Do> Expires January 15, 2014 [Page 5]
Internet-Draft <NEMO support in the DMM> July 2013
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
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
<Do> Expires January 15, 2014 [Page 6]
Internet-Draft <NEMO support in the DMM> July 2013
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
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,
<Do> Expires January 15, 2014 [Page 7]
Internet-Draft <NEMO support in the DMM> July 2013
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.
4. Binding Entry Information
4.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Do> Expires January 15, 2014 [Page 8]
Internet-Draft <NEMO support in the DMM> July 2013
4.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Security Considerations
TBD.
6. IANA Considerations
TBD.
7. References
7.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," IETF
RFC 3963, January, 2005.
[RFC5213]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.
and B. Patil, "Proxy Mobile IPv6", IETF RFC 5213,
Aug. 2008.
<Do> Expires January 15, 2014 [Page 9]
Internet-Draft <NEMO support in the DMM> July 2013
7.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-05, Jun. 2013
[Seite2013]
Seite, P., Bertin, P.:'Distributed mobility anchoring',
draft-seite-dmm-dma-06, Jan. 2013.
<Do> Expires January 15, 2014 [Page 10]
Internet-Draft <NEMO support in the DMM> July 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> Expires January 15, 2014 [Page 11]