Network Working Group Seil Jeon
Internet-Draft Younghan Kim
Intended status: Standards Track Yonghyuck Kim
Expires: September 7, 2011 Soongsil University, Korea
March 7, 2011
NEMO Problem Statement in PMIPv6
draft-sijeon-netext-nemo-ps-pmip6-00.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.
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 7, 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
Jeon, et al. Expires September 7, 2011 [Page 1]
Internet-Draft NEMO Problem Statement in PMIPv6 March 7, 2011
(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 September 7, 2011 [Page 2]
Internet-Draft NEMO Problem Statement in PMIPv6 March 7, 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,
NEMO support scenarios are examined and problems are presented for
those scenarios.
Table of Contents
1. Introduction.....................................................4
2. Terminology......................................................4
3. Applying NEMO-BSP to PMIPv6 domain...............................5
3.1. An MR-HA outside the PMIPv6..................................5
3.2. An MR-HA on LMA..............................................6
4. Considerations of NEMO support in the PMIPv6.....................7
4.1. Basic functional requirements................................7
4.2. Requirements for performance improvement.....................7
5. IANA Considerations..............................................8
6. Security Considerations..........................................8
7. References.......................................................8
Author's Address....................................................9
Jeon, et al. Expires September 7, 2011 [Page 3]
Internet-Draft NEMO Problem Statement in PMIPv6 March 7, 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 realize NEMO support, the NEMO basic support protocol (NEMO-BSP)
has been specified [NEMO-BSP]. The NEMO-BSP defines a mobile router
(MR), which is based on the Mobile IPv6 (MIPv6) client protocol, so
the MR needs to update the binding information to the home agent (HA)
[MIPv6].
The Proxy Mobile IPv6 (PMIPv6) [PMIPv6] protocol provides network-
based IP mobility management to a mobile host without requiring host
stack involvement and IP reconfiguration within same PMIPv6 domain.
However, it defines only the host mobility case. To facilitate NEMO
support in the PMIPv6 domain, as a first approach, applicable methods
using NEMO-BSP need to be discussed.
This document is a problem statement for NEMO support within the
PMIPv6 domain. Specifically, it describes NEMO support scenarios by
using the NEMO-BSP, which is a standard protocol designed by IETF,
within the PMIPv6 where the MR's HA is located at a local mobility
anchor (LMA) or outside the PMIPv6 domain. We then summarize issues
and problems occurring in these scenarios. Moreover, we discuss
requirements for improving NEMO.
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 [RFC 3963].
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 [RFC 3963].
Jeon, et al. Expires September 7, 2011 [Page 4]
Internet-Draft NEMO Problem Statement in PMIPv6 March 7, 2011
3. Protocol Operation
An MR, as defined in NEMO-BSP, is required to perform a binding
update (BU) to an MR-HA for a newly configured MR's care-of-address
(CoA) based on the prefix of the attached network. Depending on the
location of the MR-HA, the NEMO support might vary. Therefore, we
consider two scenarios for NEMO-BSP support in the PMIPv6 domain
where the MR-HA is located at an LMA or outside the PMIPv6 domain.
The MNN is assumed to have no mobility protocol stack.
3.1. An MR-HA outside the PMIPv6
In this case, a PMIPv6 domain is used as a delivery network between
the MR-HA and MR. The mobile access gateway (MAG) detecting the MR's
attachment receives a home network prefix (HNP) from an LMA. Then,
the HNP is delivered to the MR through a router advertisement (RA)
message, and a PMIPv6 tunnel is established between the MAG and the
LMA. The MR configures its MR-CoA based on the received HNP and then
performs BU for the MR-HA. A MAG emulates the MR's home network
regardless of its access link. So additional BU procedures are not
required when the MR moves to another MAG within same PMIPv6 domain.
Mobile networks and outside the PMIPv6 domain have different mobility
anchor. All MNNs configure their IP addresses based on the prefix of
the MR's HA. When the MNN moves out of the PMIPv6 domain, this node
configures its address based on the HNP assigned by the LMA, breaking
session continuity. This procedure is also applied in the opposite
case.
Packets are delivered to the final MNN via several mobility agents,
like the HA, LMA, MAG, and MR. The HA encapsulates packets with
tunnel headers, and then they traverse the PMIPv6 tunnel between the
LMA and MAG. So triple tunneling overhead occurs, which can easily
lead to large bandwidth consumption for the wireless network. This
overhead may severely impact the 3G or WiMAX access link, which has a
relatively narrow bandwidth compared to Wi-Fi access networks.
Jeon, et al. Expires September 7, 2011 [Page 5]
Internet-Draft NEMO Problem Statement in PMIPv6 March 7, 2011
3.2. An MR-HA on LMA
To take charge of the HA's function, an LMA needs to process the MR's
BU signaling message. Then, it performs double look-up processing and
makes an IP tunnel header for the MAG and MR. If the MR moves to
another MAG within the same PMIPv6 domain, reconfiguration of MR-CoA
and additional BU signaling are not required. The PMIPv6 supports
only the per-MN prefix model in [PMIPv6], but all MNNs share the MR's
HNP, assigned by the LMA. In this case, multi-link subnet issues may
occur [MULTI-ISSUES]. The prefix the MNN uses is assigned and
registered for the MR, but the prefix can be shared with other MNNs.
So, when this node travels outside the PMIPv6 domain, it SHOULD
receive a new HNP and configure a new IP address. Packet overhead
also happens due to the triple tunneling header.
Jeon, et al. Expires September 7, 2011 [Page 6]
Internet-Draft NEMO Problem Statement in PMIPv6 March 7, 2011
4. Considerations of 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
functioning and performance improvement.
4.1. Basic functional requirements
1) Prefix delegation support for an MNN: An MNN needs a unique prefix
for freely roaming support. Therefore, an appropriate prefix
delegation method SHOULD be considered. As one solution, a DHCPv6
prefix delegation method MAY be used [DHCPv6-PD-NEMO].
2) No host stack involvement: A NEMO SHOULD be supported to
attach/detach an MR and engage in mobility management without host
stack involvement
3) Node mobility support: A NEMO solution SHOULD support session
continuity for mobile nodes that roam freely between a mobile
network and the outer part of a 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, wired/wireless
network resources SHOULD be saved during handoff. Individual
signaling for an MNN is not desirable.
2) Minimal packet overhead: When packets are delivered from an LMA
and MNN, packet overhead SHOULD be minimized. This overhead is
generated by routing, tunneling, and additional signaling between
network entities.
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: Multiple tunneling is caused by
anchoring points as the number of encapsulated tunnel headers.
This increases end-to-end packet delay. This delay SHOULD be
minimized.
Jeon, et al. Expires September 7, 2011 [Page 7]
Internet-Draft NEMO Problem Statement in PMIPv6 March 7, 2011
5. IANA Considerations
TBD.
6. Security Considerations
TBD.
7. References
[RFC 3963] V. Devarapalli, R.Wakikawa, A. Petrescu, and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol," IETF
RFC 3963, January, 2005.
[RFC 3775] D. Johnson, C. Perkins, and J. Arkko, "Mobility support
in IPv6," IETF RFC 3775, June 2004.
[RFC 5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury,
and B. Patil, "Proxy Mobile IPv6," IETF RFC 5213, August
2008.
[RFC 4903] D. Thanler, "Multi-Link Subnet Issues," IETF RFC 4903,
June 2007.
[PROB-STAT] CJ. Bernardos, M. Calderon, and I. Soto, "PMIPv6 and
Network Mobility Problem Statement," draft-bernardos-
netext-pmipv6-nemo-ps-01.txt, October 2009.
Jeon, et al. Expires September 7, 2011 [Page 8]
Internet-Draft NEMO Problem Statement in PMIPv6 March 7, 2011
Author's 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, Donajak-Gu, Seoul, Korea
Phone: +82-2-820-0904
E-mail: younghak@ssu.ac.kr
Yonghyuck Kim
Soongsil University
4F Hyungnam Engineering Bldg. 424,
(156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea
Phone: +82-2-820-0841
E-mail: idid@dcn.ssu.ac.kr
Jeon, et al. Expires September 7, 2011 [Page 9]