Network Working Group J. Park Internet-Draft H. Kim Intended status: Informational ETRI Expires: January 7, 2011 July 6, 2010 Multihoming extension of PMIPv6 using 2-level Prefix Model draft-park-multihoming-ext-pmipv6-2level-prefix-00 Abstract This document discusses the use of multiple interfaces in mobile host. Especially, Horizontal handover and flow handover in multiple prefix model are resolved. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). 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." This Internet-Draft will expire on January 7, 2011. Copyright Notice Copyright (c) 2010 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. Park & Kim Expires January 7, 2011 [Page 1] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Types of handover . . . . . . . . . . . . . . . . . . . . . . 3 3. New 2-level prefix model . . . . . . . . . . . . . . . . . . . 6 4. Usage scenarios for the 2-level prefix model . . . . . . . . . 7 4.1. Scenario 1 - simultaneous attachment . . . . . . . . . . . 7 4.1.1. Initial Stage in scenario 1 . . . . . . . . . . . . . 7 4.1.2. Second Stage in scenario 1 . . . . . . . . . . . . . . 8 4.2. Scenario 2 - Sequential attachment . . . . . . . . . . . . 12 4.2.1. Initial stage in scenario 2 . . . . . . . . . . . . . 12 4.2.2. Second stage in scenario 2 . . . . . . . . . . . . . . 13 4.2.3. Third stage in scenario 2 . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Park & Kim Expires January 7, 2011 [Page 2] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 1. Introduction Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol. In here, Mobile Host (MH) does not know the changes of network access caused by MH movement. That is, Mobile Access Gateways (MAGs) and Local Mobility Anchors (LMAs) support the whole mobiltiy management. However, they do not define the protocol procedures for supporting interface and flow handover for MH with multiple interfaces. This document clarifies the type of handover. and describes the protocol procedures about multihoming extensin of PMIPv6 in multiple prefix model. In addition, Layer 2 hints are figured out even though these hints are only considered in horizontal handover (ex. WLAN-to- WLAN handover). 2. Types of handover Even though this classification is not common, this document describes the types of handover to understand the protocol procedures easily. o Inter-access Handover o Inter-interface Handover o Partial Flow Handover o Full Flow Handover First, Inter-access Handover (IAHO) occurs between MAGs. That is, MN's interface is not changed. The attached MAG is only changed. Park & Kim Expires January 7, 2011 [Page 3] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 +----+ +----+ LMA Binding Cache (Before) |LMA | |LMA | ------------------------- +----+ +----+ MN:if1 [HNP_1] --> MAG1 //\\ //\\ +----//--\\----+ +----//--\\----+ LMA Binding Cache (After) ( // \\ ) ( // \\ ) ------------------------- ( // \\ ) ( // \\ ) MN:if1 [HNP_1] --> MAG2 +-//--------\\-+ +-//--------\\-+ // \\ // \\ // \\ // \\ +----+ +----+ +----+ +----+ |MAG1| |MAG2| |MAG1| |MAG2| +----+ +----+ +----+ +----+ | | | | | if1 if2 | if1 if2 +----[MN]---- +----[MN]---- Figure 1: Inter-access Handover(IAHO) Secondly, Inter-interface Handover (IIHO) considers the MH with multiple interfaces. IIHO occurs among multiple interfaces in the same MH. +----+ +----+ LMA Binding Cache (Before) |LMA | |LMA | ------------------------- +----+ +----+ MN:if1 [HNP_1,flow1]-->MAG1 //\\ //\\ +----//--\\----+ +----//--\\----+ LMA Binding Cache (After) ( // \\ ) ( // \\ ) ------------------------- ( // \\ ) ( // \\ ) MN:if2 [HNP_1,flow1]-->MAG2 +-//--------\\-+ +-//--------\\-+ // \\ // \\ // \\ // \\ +----+ +----+ +----+ +----+ |MAG1| |MAG2| |MAG1| |MAG2| +----+ +----+ +----+ +----+ | | | | | if1 if2 if1 if2 | +----[MN]---- ----[MN]----+ Figure 2: Inter-interface Handover(IIHO) Lastly, Paritial and Full Flow Handover (PFHO/FFHO) are used in case of simulteneous attachment between MAGs and multiple interfaces in MH. PFHO means partial transfer among application and service flows. FFHO means all flow transfer. The difference between IIHO and FFHO Park & Kim Expires January 7, 2011 [Page 4] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 is the policy of keeping the mobility session, which has been transfed all flows. FFHO keeps the mobility session because of the possibility of reverse flow handover. In this document, new prefix will be used to support the flow handover. The next section will describe in detain. +----+ +----+ LMA Binding Cache (Before) |LMA | |LMA | ------------------------- +----+ +----+ MN:if1 [HNP_1,flow1]-->MAG1 //\\ //\\ MN:if1 [HNP_1,flow2]-->MAG1 +----//--\\----+ +----//--\\----+ MN:if2 [HNP_2,flow3]-->MAG2 ( // \\ ) ( // \\ ) ( // \\ ) ( // \\ ) LMA Binding Cache (After) +-//--------\\-+ +-//--------\\-+ ------------------------- // \\ // \\ MN:if1 [HNP_1,flow1]-->MAG1 // \\ // \\ MN:if2 [HNP_1,flow2]-->MAG2 +----+ +----+ +----+ +----+ MN:if2 [HNP_2,flow3]-->MAG2 |MAG1| |MAG2| |MAG1| |MAG2| +----+ +----+ +----+ +----+ | | | | | | | | | if1 if2 | | if1 if2 | +----[MN]-----+ +----[MN]-----+ Figure 3: Partial Flow Handover(PFHO) +----+ +----+ LMA Binding Cache (Before) |LMA | |LMA | ------------------------- +----+ +----+ MN:if1 [HNP_1,flow1]-->MAG1 //\\ //\\ MN:if1 [HNP_1,flow2]-->MAG1 +----//--\\----+ +----//--\\----+ MN:if2 [HNP_2,flow3]-->MAG2 ( // \\ ) ( // \\ ) ( // \\ ) ( // \\ ) LMA Binding Cache (After) +-//--------\\-+ +-//--------\\-+ ------------------------- // \\ // \\ MN:if2 [HNP_1,flow1]-->MAG2 // \\ // \\ MN:if2 [HNP_1,flow2]-->MAG2 +----+ +----+ +----+ +----+ MN:if2 [HNP_2,flow3]-->MAG2 |MAG1| |MAG2| |MAG1| |MAG2| +----+ +----+ +----+ +----+ | | | | | | | | | if1 if2 | | if1 if2 | +----[MN]-----+ +----[MN]-----+ Figure 4: Full Flow Handover(FFHO) Park & Kim Expires January 7, 2011 [Page 5] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 3. New 2-level prefix model This document defines and uses 2-level prefix model like the following figure. In here, pref_AA and pref_AB are called by level 1 prefix. It is allocated and managed by LMA. Especially, pref_AA is a permanent prefix, which is indicated by flag(P). It is used to support inter-interface and inter-access handover. On the other hand, pref_AB is a temporal prefix, which is indicated by flag(T). It is used to support flow handover. pref_AB will be allocated by LMA to MAGs before initiation of mobility sessiion. Each MAG already knows the other's temporal prefixes. And then, pref_BA, called by level 2 prefix, will be allocated for MH. Pref_BA will be allocated and managed by each MAG or LMA. +---------+---------+------+ | For_LMA | For_MAG | Flag | +=========+=========+======+ | pref_AA | - | P | +---------+---------+------+ | pref_AB | pref_BA | T | +---------+---------+------+ Figure 5: 2-level Prefix Model In the following section, HNP_x(P) and HNP_x_y(T) notation will be used. In here, x means inteface identifer and y means level 2 prefix identifer and P/T is flag, which distinguishs the prefix. As mensioned before, P means permanent prefix and T means temporal prefix. The following examples will be used in this document. o HNP_1(P) = pref_AA_1 + alpha o HNP_1(T) = pref_AB_1 o HNP_1_1(T) = pref_AB_1 + pref_BA_1 + alpha o HNP_1_2(T) = pref_AB_1 + pref_BA_2 + alpha o HNP_2(P) = pref_AA_2 + alpha o HNP_2(T) = pref_AB_2 o HNP_2_1(T) = pref_AB_2 + pref_BA_1 + alpha Park & Kim Expires January 7, 2011 [Page 6] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 4. Usage scenarios for the 2-level prefix model This document considers the MH with multiple interface, each interface of whose has multiple prefixes. This section describes the simultaneous use and horizontal handover in multiple prefix model. 4.1. Scenario 1 - simultaneous attachment This scenario considers the nearly same attachement of multiple interfaces. 4.1.1. Initial Stage in scenario 1 Initial attachment procedures of each interface is operated independently. The following functions will be performed between MH and MAG or between MAG and LMA. o The mobility session for all interfaces in MH o Prefix allocation and maintenance in LMA and MAG o Flow id generation and Distribution in LMA LMA State +----+ --------- |LMA | MH:if1 [HNP_1(P),flow1,flow2] --> MAG1 +----+ MH:if2 [HNP_2(P),flow3] --> MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ MAG2 State |MAG1| |MAG2| ---------- +----+ +----+ MH: if2[HNP_2(P),flow3]-->MAG2 | | MH: if2[HNP_2_1(T),flow3]-->MAG2 | | | | MAG1 State | if1 if2 | ---------- +-----+-----+-----+ MH: if1[HNP_1(P),flow1,flow2]-->MAG1 | MH | MH: if1[HNP_1_1(T),flow1,flow2]-->MAG1 +--+--+ | |vi [HNP_1(P) or HNP_2(P)] Park & Kim Expires January 7, 2011 [Page 7] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 Figure 6: Scenario 1 - Initial Stage The initial attach procedures are following: 1. The if1 will be attached the network through MAG1. 2. MAG1 sends the PBU to the LMA. In here, HI option is 1 (initial attachment). 3. LMA allocates the HNP_1(P) for if1 of MH. LMA sends PBA with HNP_1(P) option. 4. MAG1 sends RA message with HNP_1(P) and HNP_1_1(T). In here, HNP_1(P) has been obtained from PBA message. HNP_1_1(T) will be allocated by MAG1 using HNP_1(T) prefix, which has been distributed from LMA. 5. MH configures the HNP_1(P) and HNP_1_1(T) to the if1. 6. The if2 also does the above preocedures. After then, MH configures the HNP_2(P) and HNP_2_1(T) to the if2. 7. MH allocates HNP Address for Virtual Interface (VI). HNP_1(P) or HNP_2(P) is randomly selected. 8. Application services will be started. VoIP and web services have been started through if1. IPTV service has been also started through if2. In here, VoIP service has been assigned to flow1 by LMA. The flow1 is flow identifier for VoIP service. flow2 for web service and flow3 for IPTV service is also assigned by LMA. 4.1.2. Second Stage in scenario 1 After initial stage, the following handover will be occured in according to network changes or user requirement. o Inter-access Handover from MAG1 to MAG2 * MH: if1 is attached to network through the MAG2. * L2 Hints: To support the fast handover, L2 entity uses over- the-DS Fast basic service set Transition (FT) protocol in an RSN or non-RSN. First, MN's L2 entity informs explicitly to MAG1 using the FT request/response protocol. if L2 entity want to inform MAG1 that this is the inter-access handover, it include explicitly Target AP address (ex. MAG2 address) in FT request message. And then, remote request/response procedures will be used between MAG1 and MAG2 in order to give the MH's Park & Kim Expires January 7, 2011 [Page 8] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 if1 information. Therefore, MAG2 easily know the current state(ex. inter-access handover). * MAG1: After receiving L2 hints, new tunnel is configured between MAG1 and MAG2. This tunnel is used to transfer the data, which are targeted to if1 through MAG1. * MAG2: MAG2 sends PBU with HI(3) to the LMA. * LMA: After receiving the PBU with HNP_1(P), all if1-related entries will be changed to the if2. In addtion, LMA sends the PBA with HNP_1(P). * MAG2: After receiving the PBA, new BCE with if1 will be added. o Inter-interface Handover from if1 and if2 * MH: No action. * L2 Hints: To support the fast handover, MN's L2 entity informs explicitly to MAG1 using the FT request/response protocol. if L2 entity is likely to inform MAG1 that this is the inter- interface handover, it include Null Target AP address (ex. MAG2 address) in FT request message. It is a signal that MH want to support the inter-interface handover. And then, remote request/response procedures will be used between MAG1 and MAG2 in order to give the MH's if1 information. Therefore, MAG2 easily know the current state(ex. inter-interface handover). * MAG1: After receiving L2 hints, new tunnel is configured between MAG1 and MAG2. This tunnel is used to transfer the data, which are targeted to if1 through MAG1. * MAG2: MAG2 sends PBU with HI(2) to the LMA. * LMA: After receiving the PBU with HNP_1(P) from MAG2, all if1- related entries will be changed to the if2. LMA sends the PBA with HNP_1(P). * MAG2: After receiving the PBA, new BCE with HNP_1(P) will be added. Park & Kim Expires January 7, 2011 [Page 9] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 LMA State (Before) --------- MH:if1 [HNP_1(P),HNP_1_1(T),HNP_1_2(T)]--> MAG1 MH:if2 [HNP_2(P),HNP_2_1(T)] --> MAG2 LMA State (After) --------- MH:if1 [HNP_1(P),HNP_1_1(T)] --> MAG1 MH:if2 [HNP_2(P),HNP_2_1(T),HNP_1_2(T)]--> MAG2 +----+ |LMA | +----+ //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ MAG2 State (Before) +----+ +----+ ---------- |MAG1| |MAG2| MH: if2[HNP_2(P)] -->MAG2 +----+ +----+ MH: if2[HNP_2_1(T)]-->MAG2 | | | | MAG2 State (After) | | ---------- | | MH: if2[HNP_2(P)] -->MAG2 | | MH: if2[HNP_2_1(T)]-->MAG2 | | MH: if2[HNP_1_2(T)]-->MAG2 | if1 if2 | +-----+-----+-----+ MAG1 State (Before) | MH | ---------- +--+--+ MH: if1[HNP_1(P)] -->MAG1 | MH: if1[HNP_1_1(T),HNP_1_2(T)]-->MAG1 |vi MAG1 State (After) ---------- MH: if1[HNP_1(P)] -->MAG1 MH: if1[HNP_1_1(T)] -->MAG1 Figure 7: Scenario 1 - Second Stage: PFHO o Partial Flow Handover using temporal prefixes * MH: VoIP service is using HNP_1_1(T) as flow identifier. HNP_1_2(T) for Web service and HNP_2_1(T) for IPTV service are used. In this scenario, Web service will be transfered from Park & Kim Expires January 7, 2011 [Page 10] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 if1 and if2. * L2 Hints: FT resource request, response, confirm and ack protocol may be used to support flow handover. Especially, Over-the-DS FT Resource Request Protocol in a RSN and non-RSN will be prfered. * MAG1: After receiving the L2 hints, MAG1 and MAG2 know the user requirement about the partial flow handover. * MAG2: MAG2 sends the PBU with HI(5). In addition, PBU has a HNP option. In HNP option, HNP_1_2(T) will be included in order to inform the flow handover. * LMA: After receiving the PBU(HI=5) with HNP option, LMA updates the BCE using HNP option. That is, LMA knows the change of web service flow. * MAG2: After receiving the PBA, MAG2's BCE will be changed. o Full Flow Handover using temporal prefixes * MH: HNP_1_1(T) for VoIP service, HNP_1_2(T) for Web service and HNP_2_1(T) for IPTV service are used as the flow identifier. In this scenario, all services from if1 will be transfered to if2. * L2 Hints: FT resource request, response, confirm and ack protocol may be used to support flow handover. Especially, Over-the-DS FT Resource Request Protocol in a RSN and non-RSN will be prfered. * MAG1: After receiving the L2 hints, MAG1 and MAG2 know the user requirement about the full flow handover. * MAG2: MAG2 sends the PBU with HI(5). In addition, PBU has the HNP options. In HNP options, HNP_1_1(T) and HNP_1_2(T) will be included in order to inform the full flow handover. * LMA: After receiving the PBU(HI=5) with HNP options, LMA updates the BCE using HNP options. That is, LMA knows the transfer of all service flows. In this case, original mobility session for if1 will be kept to support the reverse partial or full flow handover. * MAG2: After receiving the PBA, MAG2's BCE will be changed. Park & Kim Expires January 7, 2011 [Page 11] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 4.2. Scenario 2 - Sequential attachment This scenario considers the sequential attachement of multiple interfaces in MH. 4.2.1. Initial stage in scenario 2 A interface will be attached to the network. The following functions will be performed between MH and MAG and LMA. o The mobility session for one interface o Prefix Allocation and Maintenance in LMA and MAG o Flow id Generation and Distribution in LMA LMA State +----+ --------- |LMA | MH:if1 [HNP_1(P),flow1,flow2] --> MAG1 +----+ // +---------//-----------------+ ( // ) PMIPv6 domain ( // ) +------//--------------------+ // // +----+ +----+ MAG2 State |MAG1| |MAG2| ---------- +----+ +----+ | | | | | | MAG1 State | if1 if2 | ---------- +-----+-----+-----+ MH: if1 [HNP_1(P),flow1,flow2]--> MAG1 | MH | MH: if1 [HNP_1_1(T),flow1,flow2]--> MAG1 +--+--+ | |vi [HNP_1(P)] Figure 8: Scenario 2 - Initial Stage TBD. Park & Kim Expires January 7, 2011 [Page 12] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 4.2.2. Second stage in scenario 2 After initial stage, the other interfaces will be attached to the network. The following functions will be performed between MH and MAG and LMA. o Initial attachment of the other interface o Inter-access Handover o Partial Flow Handover o Full Flow Handover LMA State +----+ --------- |LMA | MH:if1 [HNP_1(P),flow1,flow2] --> MAG1 +----+ MH:if2 [HNP_1(P),flow3] --> MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ MAG2 State |MAG1| |MAG2| ---------- +----+ +----+ MH: if2 [HNP_1(P),flow3] --> MAG2 | | MH: if2 [HNP_2_1(T),flow3] --> MAG2 | | | | MAG1 State | if1 if2 | ---------- +-----+-----+-----+ MH: if1 [HNP_1(P),flow1,flow2]--> MAG1 | MH | MH: if1 [HNP_1_1(T),flow1,flow2]--> MAG1 +--+--+ | |vi [HNP_1(P)] Figure 9: Scenario 2 - Second Stage TBD. Park & Kim Expires January 7, 2011 [Page 13] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 4.2.3. Third stage in scenario 2 After second stage, Inter-interface handover will be occured generally. The other functions will be same alike that of the second state. o Inter-access Handover o Inter-interface Handover o Partial Flow Handover o Full Flow Handover TBD. 5. IANA Considerations IANA considerations are not required. 6. Security Considerations TBD. 7. References 7.1. Normative References [1] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 7.2. Informative References [4] Devarapalli, V., "Multiple Interface Support with Proxy Mobile IPv6, draft-devarapalli-netlmm-multihoming-03 (work in progress)", August 2008. [5] Jeyatharan, M. and C. Ng, "Multihoming Problem Statement in NetLMM, draft-jeyatharan-netext-multihoming-ps-01 (work in Park & Kim Expires January 7, 2011 [Page 14] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 progress)", March 2009. [6] Krishnan, S., Yokota, H., Melia, T., and C. Bernardos, "Issues with network based inter-technology handovers, draft-krishnan-netext-intertech-ps-02 (work in progress)", July 2009. [7] Tran, T. and Y. Hong, "Virtual interface for supporting multihoming and inter technology handover, draft-trung-netext-virtual-interface-01 (work in progress)", October 2009. [8] Hong, Y. and J. Youn, "Virtual network interface model for multiple network interfaces in a host, draft-hong-netext-dynamic-hnp-00 (work in progress)", February 2010. [9] Sarikaya, B. and F. Xia, "Local Mobility Anchor Initiated Flow Binding for Proxy Mobile IPv6, draft-sarikaya-netext-lma-init-flow-binding-00 (work in progress)", February 2010. [10] Xia, F., "Flow Binding in Proxy Mobile IPv6,draft-xia-netext-flow-binding-00 (work in progress)", February 2009. [11] Sarikaya, B. and F. Xia, "PMIPv6 Multihoming Support for Flow Mobility, draft-sarikaya-netext-fb-support-extensions-00 (work in progress)", February 2010. [12] IEEE Std 802.11r-2008, "IEEE Std Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: Fast Basic Service Set (BSS) Transition", July 2008. Authors' Addresses Jungsoo Park ETRI/SRC 161 Gajeong-dong, Yuseong-gu Daejeon, 305-700 Korea Phone: +82 42 860 6514 Email: fnumber@gmail.com Park & Kim Expires January 7, 2011 [Page 15] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 HyeongJun Kim ETRI/SRC 161 Gajeong-dong, Yuseong-gu Daejeon 305-350 Korea Phone: +82 42 860 6576 Email: khj@etri.re.kr Park & Kim Expires January 7, 2011 [Page 16]