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]