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]