Network Working Group Seil Jeon
Internet-Draft Younghan Kim
Intended status: Standards Track Soongsil University, Korea
Expires: January 11, 2012 July 11, 2011
NEMO Problem Statement in PMIPv6
draft-sijeon-netext-nemo-ps-pmip6-01.txt
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. 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."
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 11, 2012.
Jeon, et al. Expires January 11, 2012 [Page 1]
Internet-Draft NEMO Problem Statement in PMIPv6 July 11, 2011
Copyright Notice
Copyright (c) 2011 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Jeon, et al. Expires January 11, 2012 [Page 2]
Internet-Draft NEMO Problem Statement in PMIPv6 July 11, 2011
Abstract
This document summarizes the problem statement for network mobility
support in the Proxy Mobile IPv6 (PMIPv6) domain. Especially, when
applying the NEMO basic support protocol (NEMO-BSP) in PMIPv6 domain,
the applicability of NEMO support is examined. Then, problems and
requirements are also described.
Table of Contents
1. Introduction.....................................................4
2. Terminology......................................................4
3. Appllication of the NEMO-BSP into PMIPv6 domain..................5
4. Considerations for NEMO support in the PMIPv6....................6
4.1. Basic operation requirements.................................6
4.2. Requirements for performance improvement.....................7
5. IANA Considerations..............................................8
6. Security Considerations..........................................8
7. References.......................................................8
7.1. Normative References.........................................8
Authors' Addresses..................................................9
Jeon, et al. Expires January 11, 2012 [Page 3]
Internet-Draft NEMO Problem Statement in PMIPv6 July 11, 2011
1. Introduction
The recent rapid propagation of Wi-Fi handheld devices and increasing
demand for Internet access everywhere, even within moving vehicles,
have made network mobility (NEMO) technology much noticeable.
To provide NEMO support, the NEMO basic support protocol (NEMO-BSP)
has been specified [RFC3963]. The NEMO-BSP defines a mobile router
(MR), which is based on the Mobile IPv6 (MIPv6) client protocol, so
the MR needs to perform binding update to the home agent (HA)
[RFC6275].
With the advent of Proxy Mobile IPv6 (PMIPv6) providing network-based
IP mobility management and new attempts on PMIPv6 enhancement, the
research on NEMO support is being tried [NEMO-PPS]. PMIPv6
specification defines only host mobility case [RFC5213]. To
facilitate NEMO support within the PMIPv6 domain, as a first
approach, we need to check the applicability of NEMO-BSP as
representative well-known group mobility protocol into PMIPv6 domain
and confirm the issues and problem according to the applications.
Through checking the application of NEMO-BSP into PMIPv6, we then
describe issues and problems. In addition, we discuss requirements
for basic operation and performance improvement.
2. Terminology and Functional Components
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.
o Mobile Network Node (MNN) - The node that has an address
containing the MNP, as defined in [RFC3963].
o Mobile Router (MR) - It is extended from Mobile IPv6 client
protocol and in charge of mobility management on behalf of MNN
within a mobile network, as defined in [RFC3963].
o Mobile Network Prefix (MNP): An IPv6 prefix delegated to a moving
router and advertised in the mobile network.
Jeon, et al. Expires January 11, 2012 [Page 4]
Internet-Draft NEMO Problem Statement in PMIPv6 July 11, 2011
3. Application of the NEMO-BSP into PMIPv6 domain
In NEMO-BSP, the HA is used as anchor node to provide IP session
continuity for MNNs within mobile network while the LMA is used in
PMIPv6. To support NEMO in PMIPv6, two anchor nodes, e.g., HA and
LMA, are needed. Therefore, we describe two cases applicable where HA
is separated with LMA or collocated with it. Through the
applications, we check the issues and problems introduced from each
scenario.
|
+--------+ +--------------+ | +--------------+
| | | | | | |
| Mobile | | PMIPv6 | | | PMIPv6 |
| IPv6 | +--------+ | Domain | | | Domain |
| Network| | | | | | | |
| +----+ |==|Internet|==| +-----+ | | | +------+ |
| | HA | | | | | | LMA | | | | |HA+LMA| |
| +----+ | +--------+ | +-----+ | | | +------+ |
| | | // \\ | | | // \\ |
+--------+ | // \\ | | | // \\ |
| // \\ | | | // \\ |
| +---+ +---+ | | | +---+ +---+ |
| |MAG| |MAG| | | | |MAG| |MAG| |
| +---+ +---+ | | | +---+ +---+ |
| | | | |
+--------------+ | +--------------+
|
|
|
+-----+ | +-----+
+---| MR |----+ | +---| MR |----+
| +-----+ | | | +-----+ |
| | | | |
| MNN1, MNN2,..| | | MNN1, MNN2,..|
| | | | |
+--------------+ | +--------------+
|
(a) Separated HA with LMA (b) Collocated HA with LMA
Figure 1. Applications of NEMO-BSP into PMIPv6 Domain
Jeon, et al. Expires January 11, 2012 [Page 5]
Internet-Draft NEMO Problem Statement in PMIPv6 July 11, 2011
In former case, HA and LMA are separated in different networks but
they are connected through Internet. In perspective of MR entering
PMIPv6 domain, a MAG is regarded as one of access routers placed in
foreign networks therefore there is no need to extend or modify
PMIPv6 entities.
In latter case, the LMA needs to have HA function therefore
processing MR's BU signaling, performing double look-up processing,
and making IP tunnel header for the MR. Protocol operation is same as
the former case where LMA separated with HA.
Protocol operation is as follows. When a MR approaches to PMIPv6
domain, a MAG detects MR's movement, sends PBU message to LMA, and
receives a PBA message including HNP of MR from LMA. Then, it
delivers assigned HNP to the MR through router advertisement. The MR
newly configures its CoA (MR-CoA) based on assigned HNP then performs
binding update message to the its HA. The HA binds received MR-CoA
with MR-HoA and sends back binding acknowledgment message to the MR.
If the MR moves to another MAG within the same PMIPv6 domain,
reconfiguration of MR-CoA and additional BU signaling are not
required due to home emulation provided by the MAG.
The PMIPv6 supports only per-MN prefix model in [RFC5213] but all
MNNs share the MR's HNP assigned by the LMA. When a MNN enters or
goes out to/from mobile network, it receives a new HNP it used
therefore it SHOULD configure a new IP address based on received HNP.
Eventually, IP session continuity becomes broken and disrupted.
4. Considerations for NEMO support in the PMIPv6
This section presents considerations for NEMO support within the
PMIPv6 domain. It consists of two parts: the requirements for basic
operation and performance improvement.
4.1. Basic operation requirements
1) Prefix delegation support for an MNN: Within mobile network, a MNN
receives the MNP from MR but the method can be varied for
effective and secure delivery. As one possible way, a DHCPv6
prefix delegation method MAY be used [DHCPv6-PD].
Jeon, et al. Expires January 11, 2012 [Page 6]
Internet-Draft NEMO Problem Statement in PMIPv6 July 11, 2011
2) No host stack involvement: a NEMO SHOULD provide IP mobility
management of MR and MNNs without host stack involvement.
3) Node mobility support: as the NEMO scenario described in Section
3, the mobile network advertises its MNP to MNNs but the MNP is
different from the HNP assigned from LMA. A NEMO solution SHOULD
support IP session continuity for freely roaming MNN between a
mobile network and the fixed access of PMIPv6 domain.
4.2. Requirements for performance improvement
1) Resource-efficient handoff management: when a mobile network moves
to another MAG within the same PMIPv6 domain, network resources in
wired/wireless SHOULD be saved for location/handoff management.
2) Minimal packet overhead: to deliver data packet to a MNN, it may
need one or more IP packet tunneling to pass network entities in
charge of node anchoring. As the number of IP tunnel increases, it
makes packet overhead more severe per data packet. Ultimately, it
leads to energy-efficiency issue.
3) Minimal packet loss during handoff: packet loss caused by a
handoff event during a change in the attachment point SHOULD be
minimal.
4) Minimal end-to-end delay: IP tunneling is caused by anchoring
points as the number of encapsulated tunnel headers. Depending on
the location of anchor points, it may make data route much longer,
therefore it leads to increase end-to-end packet delay. This delay
SHOULD be minimized.
Jeon, et al. Expires January 11, 2012 [Page 7]
Internet-Draft NEMO Problem Statement in PMIPv6 July 11, 2011
5. IANA Considerations
TBD.
6. Security Considerations
TBD.
7. References
7.1. Normative References
[RFC3963] V. Devarapalli, R.Wakikawa, A. Petrescu, and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol," IETF
RFC 3963, January, 2005.
[RFC6275] C. Perkins, D. Johnson, and J. Arkko, "Mobility support in
IPv6," IETF RFC 6275, July 2011.
[RFC5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and
B. Patil, "Proxy Mobile IPv6," IETF RFC 5213, August
2008.
[NEMO-PPS] CJ. Bernardos, M. Calderon, and I. Soto, "PMIPv6 and
Network Mobility Problem Statement," draft-bernardos-
netext-pmipv6-nemo-ps-01.txt, October 2009.
[DHCPv6-PD] R. Droms, P. Thubert, F. Dupont, W. Haddad, and CJ.
Bernardos, "DHCPv6 Prefix Delegation for NEMO," draft-
ietf-mext-nemo-pd-07.txt, December 2010.
Jeon, et al. Expires January 11, 2012 [Page 8]
Internet-Draft NEMO Problem Statement in PMIPv6 July 11, 2011
Authors' Addresses
Seil Jeon
Soongsil University
4F Hyungnam Engineering Bldg. 424,
(156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea
Phone: +82-2-820-0841
E-mail: sijeon@dcn.ssu.ac.kr
Younghan Kim
Soongsil University
11F Hyungnam Engineering Bldg. 1107,
(156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea
Phone: +82-2-820-0904
E-mail: younghak@ssu.ac.kr
Jeon, et al. Expires January 11, 2012 [Page 9]