NETLMM Working Group Hong-Ke Zhang
Internet Draft Zhi-Wei Yan
Expires: September 2010 Hua-Chun Zhou
Jian-Feng Guan
Si-Dong Zhang
Beijing Jiaotong University
March 4, 2010
Consideration of Network Mobility in PMIPv6
draft-zhang-netlmm-nemo-01.txt
Abstract
The NetLMM WG is specifying Proxy Mobile IPv6 (PMIPv6) for network-
based localized mobility management (NetLMM), taking basic support
for registration, de-registration and handover of single Mobile Node
(MN) into account in the RFC 5213 [1]. When a whole subnet moves into
the PMIPv6 domain through the Mobile Router (MR), the scheme should
be considered to provide and maintain the connectivity for the Mobile
Network Node (MNN) in the mobile network (NEMO). This document
discusses the deployment consideration of NEMO support in PMIPv6
network and proposes the possible solution accordingly.
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 4, 2010.
Zhang et al. Expires September,2010 [Page 1]
Internet-Draft Consideration of NEMO in PMIPv6 March 2010
Copyright Notice
Copyright (c) 2010 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 BSD License.
Table of Contents
1. Introduction...................................................2
2. Conventions....................................................3
3. Problem statement..............................................3
3.1. Mobility of NEMO..........................................3
3.2. Mobility of nested NEMO...................................4
4. PMIPv6-NEMO....................................................4
4.1. Extensions of LMA and MAG.................................4
4.2. NEMO state table..........................................4
4.2.1. LMA..................................................4
4.2.2. MAG..................................................5
4.2.3. MR...................................................5
4.3. Procedure of PMIPv6-NEMO..................................5
5. Packet transmission............................................6
5.1. Incoming packets..........................................6
5.2. Outgoing packets..........................................7
6. Security Considerations........................................7
7. IANA Considerations............................................7
8. Acknowledgements...............................................7
9. References.....................................................7
Authors' Addresses................................................8
1. Introduction
As the extension of basic MIPv6 specification [2], NEMO [3] was
proposed to support the network mobility in MIPv6 network. The
protocol procedure of MIPv6-NEMO is compatible with basic MIPv6
protocol and the prefix of network is maintained by HA to support the
redirection of packets to and from the mobile network. However, the
mobility of MIPv6-NEMO is totally managed by the MR as the MN does in
basic MIPv6. Be different with MIPv6, the PMIPv6 was proposed to
Zhang et al. Expires September,2010 [Page 2]
Internet-Draft Consideration of NEMO in PMIPv6 March 2010
support the network-based mobility management. The entities in the
PMIPv6 have the responsibility to track the MN, update the location
of the MN and redirect the packets to and from the MN. However, the
basic PMIPv6 protocol only solves the mobility management for the
single MN. In order to deploy the NEMO in the PMIPv6 network, CJ.
Bernardos proposes the problems of NEMO support in the PMIPv6 network
when using current protocols [4].
This document discusses the deployment consideration of NEMO in
PMIPv6 network noted as PMIPv6-NEMO. As a default router of the whole
mobile network, a PMIPv6-MR should not only send and receive the
packets for MNN, but also manage the mobility of MNN. So we propose
the extension of basic PMIPv6 and add the NEMO state table for the
entities of the PMIPv6 domain. Then the Local Mobility Anchor (LMA),
Mobile Access Gateway (MAG) and MR can maintain the location
information of the MNNs in its lower subnet. Because the
authentication scheme is used, the mobility of the NEMO is still
managed in the network-based manner.
2. Conventions
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 [RFC-2119].
3. Problem statement
At least there are two problems should be considered when deploying
NEMO in PMIPv6 network. The first one is the mobility management of
the whole mobile subnet, including the MR, Local Fixed Node (LFN) and
Visited Mobile Node (VMN). The second one is the nested NEMO
supporting.
3.1. Mobility of NEMO
In the NEMO, the mobility of three types of nodes MUST be considered:
the MR itself, LFN and VMN. For the MR, it should be allocated a
particular Home Network Prefix (HNP) as the single MN in the PMIPv6
network and the HNP MUST not changes when the MR moves. For the LFN,
its address is configured using the Mobile Network Prefix (MNP) which
belongs to a special NEMO. In this case, the LMA MUST not only
intercept and redirect the packets for MR, but also intercept and
redirect the packets for the LFN belonging to the MNP. For the VMN,
it can roam between MR and MR, MR and MAG, MAG and MAG. And then the
VMN MUST be assigned a particular HNP and its address is configured
using the HNP and does not change during its movement.
Zhang et al. Expires September,2010 [Page 3]
Internet-Draft Consideration of NEMO in PMIPv6 March 2010
3.2. Mobility of nested NEMO
In the nested NEMO scenario, we should consider who manages the
mobility of NEMO. When the mobility of NEMO is managed by MR itself,
it can follow the procedure in RFC 3963 or P-NEMO [5]. And then the
advantages of network-based manner discounts. When the mobility of
NEMO is managed by the network, the MR should not involve in any
mobility related signaling with MAG or LMA. And then the NEMO support
can be manageable, controllable and secure.
4. PMIPv6-NEMO
4.1. Extensions of LMA and MAG
In order to manage the bindings of MR and MNN, the LMA and MAG MUST
be extended to include the following information:
o R flag: indicating whether or not this Binding Cache entry is
created for a mobile router or a single node. This flag is set to
value 1 for MRs and is set to value 0 for the single nodes.
o A list of IPv6 prefixes in the mobile network: these prefixes
include the MNP for the location update of LFNs and HNPs for the
location update of VMNs.
Besides, the MNP is also allocated and managed by the LMA. In thi
sway, the MNP related packets can be routed to the LMA.
4.2. NEMO state table
Besides, the packets to and from the MNN have to be transmitted
through the most optimized route. Then the NEMO state table should be
established and maintained by the entries.
4.2.1. LMA
The NEMO state table of LMA MUST contain the following information:
o MR's HNP: denotes the related MR.
o A list of IPv6 prefixes in the mobile network: these prefixes
include the MNP for the location update of LFNs and HNPs for the
location update of VMNs.
o Tunnel index: denotes the related tunnel to arrive at the MAG. And
the MR's HNP related MR locates at the MAG subnet currently.
Zhang et al. Expires September,2010 [Page 4]
Internet-Draft Consideration of NEMO in PMIPv6 March 2010
4.2.2. MAG
The NEMO state table of MAG MUST contain the following information:
o MR's HNP: denotes the related MR.
o A list of IPv6 prefixes in the mobile network: these prefixes
include the MNP for the location update of LFNs and HNPs for the
location update of VMNs.
o Link local address: denotes the next hop to arrive at the MR's HNP
related MR.
o Tunnel index: denotes the related tunnel to arrive at LMA.
4.2.3. MR
The NEMO state table of MR MUST contain the following information:
o MR's HNP: denotes the related MR.
o A list of IPv6 prefixes in the mobile network: these prefixes
include the MNP for the location update of LFNs and HNPs for the
location update of VMNs.
o Link local address: denotes the next hop to arrive at the MR's HNP
related MR.
4.3. Procedure of PMIPv6-NEMO
When another MR2 attaches to the MR1 whose connection has been
established, the attachment should be discovered by MR1 through the
link layer information. When the link layer connection is
successfully established, the MR2 sends the Authentication Request(AR)
message to the MR1 for the authentication.
The following information should be contained in the authentication
messages:
o R flag: its value is set to 1, indicating that it is a NEMO
attachment.
o A list of IPv6 prefixes in the mobile network: these prefixes
include the MNP for the location update of LFNs and HNPs for the
location update of VMNs.
Zhang et al. Expires September,2010 [Page 5]
Internet-Draft Consideration of NEMO in PMIPv6 March 2010
Then the MR1 redirects the Proxy Authentication Request (PAR) message
to the MAG. According to the PMIPv6 protocol, the Proxy Binding
Update (PBU) and Proxy Binding Acknowledgement (PBA) are exchanged
between MAG and LMA. After this process, the LMA updates its NEMO
state table and records the current MAG of MR2 and those VMNs' HNPs.
+------+ +-----+ +-----+ +-----+
| MR2 | | MR1 | | MAG | | LMA |
+------+ +-----+ +-----+ +-----+
|-- Attach ->| | |
|-----AR---->| | |
| |----PAR--->| |
| | |------PBU--->|
| | |<-----PBA----|
| |<----PAA---| |
|<----AA-----| | |
|-----data-->| | |
| |----data-->| |
| | |====data====>|
| | |<====data====|
| |<----data--| |
|<-----data--| | |
Figure 1: Message flow of PMIPv6-NEMO
When receiving the PBA message, the MAG also increases the entries of
MR2's HNP, MR2's MNP and VMNs' HNPs in its NEMO state table. Then the
MAG sends the Proxy Authentication Answer (PAA) message to the MR1
and MR1 records the related information as MAG does. Finally the MR2
receives the Authentication Answer (AA) message and sends the related
prefix to the related nodes. Because these MNNs always receive the
same related prefixes and their connectivity can be maintained.
5. Packet transmission
In the previous example, we assume that an VMN and an LFN are located
at the MR2 and communicate with the Corresponding Node(CN) during the
movement of MR2.
5.1. Incoming packets
For the incoming packets sent from CN to MNN, they are firstly
transmitted to the LMA according to the routing protocol. Then the
LMA checks the destination addresses and finds that the VMN's HNP and
LFN's MNP are binding with the MR2's HNP. So the LMA can send the
packets to the MAG through the correct tunnel. When the MAG receives
Zhang et al. Expires September,2010 [Page 6]
Internet-Draft Consideration of NEMO in PMIPv6 March 2010
the packets, it gets their next hop address and redirects them to the
MR1. In the same manner, the MR1 sends the packets to the MR2 and MR2
sends them to the LFN and VMN finally.
5.2. Outgoing packets
For the outgoing packets sent from MNN to CN, they are firstly
transmitted to the MR2 according to the default router configuration.
In the same manner, the MR2 sends them to the MR1 when the MR2 finds
that there is no state of the destination related prefix. When the
MR2 fins that the destination address is in accordance with a prefix
in its NEMO state table. MR2 will think these packets are intra-NEMO
communication and the packets can be redirected to the CN directly.
Otherwise, the packets are transmitted to the MAG, and then MAG finds
the correct tunnel and sends them to the LMA. Finally, the LMA
deencapsulates the packets and sends them to the CN.
6. Security Considerations
To eliminate the threats on the interface between the MAG and the MR,
this specification requires an established trust between the mobile
access gateway and the MR node and to authenticate and authorize the
MR before it is allowed to access the network.
7. IANA Considerations
This specification has no actions for IANA.
8. Acknowledgements
The authors would like to acknowledge the prior discussions on this
topic in netext and netlmm mailing lists.
9. References
[1] Gundavelli, et al., "Proxy Mobile IPv6", RFC5213, August 2008.
[2] David B. Johnson, Charles E. Perkins and Jari Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[3] Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, and
Pascal Thubert, "NEMO Basic Support Protocol", RFC 3963,
January 2005.
[4] CJ. Bernardos, M. Calderon and I. Soto, "PMIPv6 and Network
Mobility Problem Statement", draft-bernardos-netext-pmipv6-
nemo-ps-01, October 2009.
Zhang et al. Expires September,2010 [Page 7]
Internet-Draft Consideration of NEMO in PMIPv6 March 2010
[5] I. Soto, CJ. Bernardos, M. Calderon, A. Banchs and A. Azcorra,
"NEMO-Enabled Localized Mobility Support for Internet Access in
Automotive Scenarios", IEEE Communications Magazine, vol. 47,
no. 5, pp: 152-159, May 2009.
Authors' Addresses
Hong-Ke Zhang, Zhi-Wei Yan, Hua-Chun Zhou, Jian-Feng Guan, Si-Dong
Zhang
National Engineering Laboratory for NGIID
Beijing Jiaotong University of China
Phone: +861051685677
Email:hkzhang@bjtu.edu.cn
06120232@bjtu.edu.cn
hchzhou@bjtu.edu.cn
guanjian8632@163.com
sdzhang@center.njtu.edu.cn
Zhang et al. Expires September,2010 [Page 8]