Networking Working Group Sihun Park Internet-Draft Univ. of Soongsil, Korea Expires: 26 August 2007 Jennifer E. Lee SK Telecom,Korea Jaeyeon Choi TIMENetworks,Korea Younghan Kim Univ. of Soongsil, Korea February 26, 2007 Fast Localized Proxy Mobile IPv6 (FLPMIPv6) draft-park-netlmm-fastpmip-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 August 26, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Park, et al. Expires 26 August, 2007 [Page 1] Internet-Draft FLPMIPv6 February 2007 Abstract Proxy mobile ipv6 (PMIPv6) is designed to manage mobility of hosts that are not equipped with any mobility management protocol. But PMIPv6 has a handover latency because it is based on global mobility management protocols such as MIPv6. Handover latency sensitives impact on real-time application. This document describes Fast and Local Proxy Mobile IPv6 (FLPMIPv6) to reduce handover latency and packet loss ratio. The scheme is based on the fast mobile IP scheme and utilized some of messages defined in 802.21 and information coming from link layer. Table of Contents 1. Introduction.....................................................3 2. Terminology......................................................3 3. Protocol Detail..................................................5 4. Message Formats..................................................7 5. Security Considerations..........................................7 6. References.......................................................8 Author's Address....................................................9 Full Copyright Statement...........................................10 Intellectual Property..............................................10 Acknowledgment.....................................................10 Park, et al. Expires 26 August, 2007 [Page 2] Internet-Draft FLPMIPv6 February 2007 1. Introduction PMIPv6[1] is designed to avoid tunneling overhead over the air and to manage mobility of hosts that are not equipped with any mobility management software. However PMIPv6 leads to increasing signaling cost as mobile nodes move frequently because the protocol is based on the global mobility management protocol. In addition, handoff latency and packet loss incured when MN moves to a different PMA. Under the respect, we propose a mobility management scheme called Fast and Localized proxy Mobile IPv6 (FLPMIPv6) to reduce handover latency and ration of pakcet loss. We utilize the fast mobile IP scheme specified in [2] and information generated by link layer following to the 802.21 specification [3]. 2. Terminology The keywords "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 [4]. The basic terminology defined in [1],[2] is used in this document. In addition, the following terminology is used. Previous Proxy Mobile Agent (PPMA) It is used for the MN's default router prior to its handover. New Proxy Mobile Agent (NPMA) It is used for the MN's default router subsequent to its handover. Media Independent Handover Handover Initiate (MIH HO Init) A trigger from the link layer to MIHF layer to report that handover should be initiated. Media Independent Handover Handover Complete (MIH HO Com) A trigger from the link layer to MIHF layer to report that handover has been completed. Park, et al. Expires 26 August, 2007 [Page 3] Internet-Draft FLPMIPv6 February 2007 Link Going Down (LGD) A trigger from the link layer to MIHF layer to report that a link connectivity loss is imminent. Link UP (LUP) A trigger from the link layer to MIHF layer to report that a link connectivity is established. The following figure 2 describes the network architecture that this document consider. +-------+ | HA | +-------+ / \ / \ +-------------+ | IP Network | +-------------+ / \ / \ +------+ +------+ | LMA | | LMA | +------+ +------+ +------+ | AAA | / \ | +------+ / \ | +-----+ +-----+ +-----+ |PPMA | |NPMA | | PMA | +-----+ +-----+ +-----+ +--+ +--+ |MN|------------->|MN| +--+ +--+ |<- Local Mobility ->| |<-------- Global Mobility ------->| Figure 1: Network Architecture Park, et al. Expires 26 August, 2007 [Page 4] Internet-Draft FLPMIPv6 February 2007 3. Protocol Details The FLPMIPv6 protocol starts off by the time when a mobile node moves to a NPMA. FLPMIPv6 supports predictive handover that operates FLP- MIPv6 handover procedures prior to the finalizing handover procedures at layer 2. Figure 2 shows the Fast Localized PMIPv6 handover proce- dure. MN PPMA NPMA LMA | | | | 1 LGD ->| | | | |- 2 MIH HO Init ->| | | | |----- 3 HI ---->| | | | |--- 4 FBU --->| | | | | | | |<-- 5 FBack --| | |<--- 6 HAck ----| | | | | | Disconnect forward | | | packets ==========>| | | | buffering | connect | | | | | | | 7 LUP ->| | | | |-------- 8 MIH HO Com ------------>| | | | | | | forward packets | | |<==================================|<=============| | | | | Figure 2: Fast Localized PMIPv6 handover procedure The procedure is as follows. 1. Media Independent Handover Function (MIHF) of MN recives Link Going Down (LGD) indication from MIHF. 2. The MN's MIHF sends Media Independent Handover Handoff Initiate (MIH HO Init) command message to current PPMA. This message contains new PMA (NPMA)'s [AR-ID, AR-Info] tuples. 3. After the PPMA recives MIH HO Init, the PPMA sends Handover Park, et al. Expires 26 August, 2007 [Page 5] Internet-Draft FLPMIPv6 February 2007 Initiate (HI) message to NPMA where the HI message contains the MN's IP address (PCoA) and MN's identifier. The NPMA recives HI message, it SHOULD examine whether a tunnel to the LMA exists for PCoA or not. If the tunnel has been already estab- lished, it could mean one of two thing. The HI message from PPMA is, on one hand, spurious and NPMA had already setup a tunnel with LMA when it saw the L2 trigger earlier. On the other hand, it could also mean that there is already a node with the same PCoA address on the link. The NPMA verifies the MN's identifier to see whether it is the same node or not. If it is the same node, it returns failure indicating Duplicate Address. If NPMA successfully processes the HI message, it sends a Fast Binding Update message to the LMA to redirect the tunnel from the PPMA. The FBU message contains PCoA as the home address as well as it can optionally include the MN's unique identifier. 4. When LMA receives the FBU message, it examine whether or not there is a binding for the RCoA. If it does not exist, it creates a new binding entry. Otherwise, it examine if the MN's identifier in the FBU matches with the identifier in the binding. If it matches, then it updates the binding information. Otherwise, it fails the request. Once the LMA successfully processes the FBU, it sets (or updates) the tunnel to NPMA for sending and receiving packets from PCoA. Normally a host route will be added for PCoA pointing to the tunnel. If suc- cessful updates MN's RCoA then the LMA sends FBack mesage to NPMA. 5. When the NPMA receives a successful FBack message, it examine whether or not the FBU was processed successfully. If there is a failure, the HAck messagge indicates the failure. Otherwise, it cre- ates a tunnel to the LMA and sets up the forwarding in such a way where packets with source address as PCoA get forwarded into the tun- nel. It also maintains state, like the binding state, which can be used to verify duplication or spurious indications from PPMA or MN. It also creates a host route for forwarding packets to the MN. The NPMA sends a HAck message back to the PPMA indicating that it was successfully done the handover procedure. 6. When PPMA receives the HAck message, it forwards packet to NPMA. Park, et al. Expires 26 August, 2007 [Page 6] Internet-Draft FLPMIPv6 February 2007 When NPMA receves the tunneled MN's packet from PPMA then starts packet buffering. 7. When the MN connects to the new link, MN's MIHF recives Link UP(LGD) indication from MIHF. The MN sends MIH HO Com message to NPMA. 8. The NPMA recives MIH HO Com. The NPMA can use this indication to start forwarding packets to the MN, thereafter it forwards the buffered packets. 4. Message Formats All the messages between PPMA and NPMA are ICMPv6 mesages. This docu- ment initially follows the format defined in [2],[3] 5. Security Considerations This document does not discuss any special security concerns in detail. The protocol of this document is built on the assumption that all participating nodes are trusted each other as well as there is no adversary who modifies/injects false messages to corrupt the procedures. However, support of secure transaction is prerequisite for launching a secure communication in the presence of adversaries. In such an environment, most of all mobility management protocols including PMIPv6 may be vulnerable to many kinds of attacks. It is fairly easy to inject fake messages or modify legitimate ones so that network operation would be heavily disturbed. Therefore, it is necessary to find a means to authenticate/verify signaling messages for IP han- dover. Park, et al. Expires 26 August, 2007 [Page 7] Internet-Draft FLPMIPv6 February 2007 6. References [1] Gundavelli, S., "Proxy Mobile IPv6", draft-sgundave-mip6-prox- ymip6-01 (work in progress), January 2007. [2] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [3] Institute of Electrical and Electronics Engineer, "Draft IEEE Stan- dard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE P802.21 D00.05. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Park, et al. Expires 26 August, 2007 [Page 8] Internet-Draft FLPMIPv6 February 2007 Author's Addresses Sihun Park Ubiquitous Network Research Center 4F Hyungnam Engineering Bldg. 317, Sangdo-Dong, Dongjak-Gu, University of Soongsil, Seoul 156-743 Korea Phone: +82 2 820 0841 E-main: shpark@dcn.ssu.ac.kr Jennifer E. Lee SK Telecom 11,Eulgiro 2-ga, Jung-gu, Seoul 100-999, Korea Phone: +82 2-6100-2365 Email: jen_lee@sktelecom.com Jaeyeon Choi TIMENetworks 25-1 Jeongja-dong Bundang-gu,Korea Phone: +82 31-784-8383 E-mail: jychoi@timenetworks.co.kr Younghan Kim University of Soongsil in Seoul 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, Dongjak-Gu, Seoul 156-743 Korea Phone: +82 2 820 0904 E-main: yhkim@dcn.ssu.ac.kr Park, et al. Expires 26 August, 2007 [Page 9] Internet-Draft FLPMIPv6 February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assur- ances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgment Park, et al. Expires 26 August, 2007 [Page 10] Internet-Draft FLPMIPv6 February 2007 Funding for the RFC Editor function is provided by the IETF Adminis- trative Support Activity (IASA). Park, et al. Expires 26 August, 2007 [Page 11]