Network Working Group J. Park Internet-Draft H. Kim Intended status: Informational ETRI Expires: January 13, 2011 July 12, 2010 Multihoming extension of PMIPv6 using 2-level Prefix Model draft-park-multihoming-ext-pmipv6-2level-prefix-01 Abstract This document discusses the use of multiple interfaces in mobile host. Especially, Horizontal handover and flow handover in 2-level 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 13, 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 13, 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. New 2-level flow identifier model . . . . . . . . . . . . . . 8 5. Usage scenarios for the 2-level prefix model . . . . . . . . . 8 5.1. Scenario 1 - simultaneous attachment . . . . . . . . . . . 8 5.1.1. Initial Stage in scenario 1 . . . . . . . . . . . . . 9 5.1.2. Second Stage in scenario 1 . . . . . . . . . . . . . . 10 5.2. Scenario 2 - Sequential attachment . . . . . . . . . . . . 14 5.2.1. Initial stage in scenario 2 . . . . . . . . . . . . . 14 5.2.2. Second stage in scenario 2 . . . . . . . . . . . . . . 15 5.2.3. Third stage in scenario 2 . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Park & Kim Expires January 13, 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 multiple interfaces and flow handover in MH. This document clarifies the types of handover. and describes the protocol procedures about multihoming extensin of PMIPv6 in 2-level prefix model. 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 (IAHO) o Inter-interface Handover (IIHO) o Partial Flow Handover (PFHO) o Full Flow Handover (FFHO) 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 13, 2011 [Page 3] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 +----+ +----+ LMA Binding Cache (Before) |LMA | |LMA | ----------------------------- +----+ +----+ MN:if1[HNP_1,flow1] --> MAG1 //\\ //\\ +----//--\\----+ +----//--\\----+ LMA Binding Cache (After) ( // \\ ) ( // \\ ) ----------------------------- ( // \\ ) ( // \\ ) MN:if1[HNP_1,flow1] --> 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. In this case, original interface will be broken by some reasons. Therefore, all flow under control of original interface will be moved to the other interface. The IAHO and IIHO in LMA processing are same in case of the MH with logical interface. That is, the HNP is assigned to logical interface only. The MAC address of logical interface is informed to LMA. LMA does not know the existence of multiple interfaces. Park & Kim Expires January 13, 2011 [Page 4] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 +----+ +----+ 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| +----+ +----+ +----+ +----+ | | | | |flow1 flow1| +----[MN]---- ----[MN]----+ if1 if2 if1 if2 Figure 2: Inter-interface Handover(IIHO) Lastly, Paritial and Full Flow Handover (PFHO/FFHO) are used in case of simulteneous attachment between MAGs in MH with multiple interfaces. PFHO means partial transfer among application flows. FFHO means all flow transfer from one interface to the other. The difference between IIHO and FFHO is the policy of keeping the mobility session on the original interface. FFHO keeps the mobility session because of the possibility of reverse flow handover. So, original information in LMA or MAG will be kept for some time with idle(I) flag. In this document, new prefix model will be used to support the flow handover. The next section will describe in detailss. Park & Kim Expires January 13, 2011 [Page 5] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 +----+ +----+ LMA Binding Cache (Before) |LMA | |LMA | ------------------------- +----+ +----+ MN:if1 [HNP_1,flow1]-->MAG1[A] //\\ //\\ MN:if1 [HNP_1,flow2]-->MAG1[A] +----//--\\----+ +----//--\\----+ MN:if2 [HNP_2,flow3]-->MAG2[A] ( // \\ ) ( // \\ ) ( // \\ ) ( // \\ ) LMA Binding Cache (After) +-//--------\\-+ +-//--------\\-+ ------------------------- // \\ // \\ MN:if1 [HNP_1,flow1]-->MAG1[A] // \\ // \\ MN:if2 [HNP_1,flow2]-->MAG1[I] +----+ +----+ +----+ +----+ MN:if2 [HNP_1,flow2]-->MAG2[A] |MAG1| |MAG2| |MAG1| |MAG2| MN:if2 [HNP_2,flow3]-->MAG2[A] +----+ +----+ +----+ +----+ | | | | |flow1 flow3| |flow1 flow3| |flow2 | | flow2| +----[MN]-----+ +----[MN]-----+ if1 if2 if1 if2 Figure 3: Partial Flow Handover(PFHO) +----+ +----+ LMA Binding Cache (Before) |LMA | |LMA | ------------------------- +----+ +----+ MN:if1 [HNP_1,flow1]-->MAG1[A] //\\ //\\ MN:if1 [HNP_1,flow2]-->MAG1[A] +----//--\\----+ +----//--\\----+ MN:if2 [HNP_2,flow3]-->MAG2[A] ( // \\ ) ( // \\ ) ( // \\ ) ( // \\ ) LMA Binding Cache (After) +-//--------\\-+ +-//--------\\-+ ------------------------- // \\ // \\ MN:if2 [HNP_1,flow1]-->MAG2[A] // \\ // \\ MN:if2 [HNP_1,flow2]-->MAG2[A] +----+ +----+ +----+ +----+ MN:if2 [HNP_2,flow3]-->MAG2[A] |MAG1| |MAG2| |MAG1| |MAG2| MN:if2 [HNP_1,flow1]-->MAG1[I] +----+ +----+ +----+ +----+ MN:if2 [HNP_1,flow2]-->MAG1[I] |flow1 | | flow1| MN:if2 [HNP_2,flow3]-->MAG1[I] |flow2 | | flow2| |flow3 | | flow3| +----[MN]-----+ +----[MN]-----+ if1 if2 if1 if2 Figure 4: Full Flow Handover (FFHO) 3. New 2-level prefix model This document defines and uses 2-level prefix model like the following figure. In here, pref_A1 and pref_B1 are called by level 1 Park & Kim Expires January 13, 2011 [Page 6] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 prefix. It is allocated and managed by LMA. Especially, pref_A1 is a permanent prefix, which is indicated by flag(P). It is used to support inter-interface and inter-access handover. And logical interface will use the permanent prefix. On the other hand, pref_B1 is a temporal prefix, which is indicated by flag(T). If the distinguished prefix ranges are assigned for permanet and temporal prefixes in each, these flags may be not required. It is used to support flow handover. pref_B1 will be allocated by LMA to MAGs before initiation of mobility session. Each MAG already knows the other's temporal prefixes. And then, pref_01, called by level 2 prefix, will be allocated for MH. Pref_01 will be allocated and managed by each MAG or LMA. Basically MAG is better for distribution of load for flow management. +---------+---------+---------+------+ | 2-level | For_LMA | For_MAG | Flag | +=========+=========+=========+======+ | level 1 | pref_A1 | x | P | +---------+---------+---------+------+ | level 1 | pref_B1 | - | T | +---------+---------+---------+------+ | level 2 | pref_B1 | pref_01 | 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_A1 (e.g., 2002:1:1:0::/64) o HNP_2(P) = pref_A2 (e.g., 2002:1:2:0::/64) o HNP_1(T) = pref_B1 (e.g., 2002:2:1:0::/64) o HNP_2(T) = pref_B2 (e.g., 2002:2:2:0::/64) o o HNP_1_1(T) = pref_B1 + pref_01 (e.g.,2002:2:1:1::/64) o HNP_2_1(T) = pref_B2 + pref_01 (e.g.,2002:2:2:1::/64) In here, there are 2 types of prefixes: permanet and temporal. The Park & Kim Expires January 13, 2011 [Page 7] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 permanent prefix without the part of level 2 prefix will be allocated to the logical interface in order to support inter-technology handover. If we do not consider the logical interface concept, the type of services will be checked to use the proper prefix. Even though the quality of service will be decreased during MH movement, we do not want to support the handover and flow mobility. In that case, we will use the permanent prefixes. In other case, we will use the temporal prefixes. 4. New 2-level flow identifier model There are 2 types of flow identifier(FID). These flow ids are managed separately in MN, MAG and LMA. That is,the uniqueness of flow ids are satified just in each node. o Input FID (IFID) = level-1 flow id(IFID1) + level-2 flow id(IFID2) or none o output FID(OFID) = level-1 flow id(OFID1) + level-2 flow id(OFID2) or none After PBU and PBA exchange, level-1 input flow ids are exchanged between MAGs and LMA. And then, level-2 flow ids are allocated according to emerging each data flow. After the receiving RA messages, MH gets level-1 flow id from MAG. On the other hand, MAG makes level-1 flow id after the recognizing L2 attachment or the first data receiving form MH. And then level-2 flow ids are allocated during the data transmission. MH decides anf forwards the data from logical interface to physical interfaces by referring flow ids. And then, MAG and LMA just decides and forwards the service flow by using ouput flow ids. 5. Usage scenarios for the 2-level prefix model This document considers the MH with multiple interfaces, each interface of whose has multiple prefixes. This section describes the simultaneous use and horizontal handover in 2-level prefix model. 5.1. Scenario 1 - simultaneous attachment This scenario considers the nearly same attachment of multiple interfaces. Park & Kim Expires January 13, 2011 [Page 8] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 5.1.1. Initial Stage in scenario 1 Initial attachment procedures of each interface are 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(T)] -->MAG2 | | MH: if2[HNP_2_1(T)] -->MAG2 | | | | MAG1 State | if1 if2 | ---------- +-----+-----+-----+ MH: if1[HNP_1(P),flow1,flow2] -->MAG1 | MH | MH: if1[HNP_1(T)] -->MAG1 +--+--+ MH: if1[HNP_1_1(T),HNP_1_2(T)]-->MAG1 | | |vi [HNP_1(P) or HNP_2(P)] Figure 6: Scenario 1 - Initial Stage The initial attach procedures are following: 1. The if1 will be attached the network through MAG1. Park & Kim Expires January 13, 2011 [Page 9] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 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 had 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 procedures. After then, MH configures the HNP_2(P) and HNP_2_1(T) to the if2. 7. MH allocates HNP Address for logical Interface (LI). HNP_1(P) or HNP_2(P) is randomly selected. In here, we suppose that HNP_1(P) was selected. 8. Application services will be started. For example, 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. 9. If we have the policy that only LI has the HNPs, the procedure 5 and 6 are not required. And the HNP assigend in LI is shown to all application services. 5.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. * MAG1: After receiving L2 hints, new tunnel may be 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 MAG1-related entries will be changed to the MAG22. In addtion, LMA sends Park & Kim Expires January 13, 2011 [Page 10] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 the PBA to MAG2 with HNP_1(P). * MAG2: After receiving the PBA, new BULE with if1 will be added. o Inter-interface Handover from if1 and if2 * MH: No action. * MAG1: After receiving L2 hints, new tunnel may be 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 MAG1- related entries will be changed to the MAG2. LMA sends the PBA with HNP_1(P). * MAG2: After receiving the PBA, new BULE with HNP_1(P) will be added. Park & Kim Expires January 13, 2011 [Page 11] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 LMA State (Before) --------- MH:if1 [HNP_1(P),HNP_1(T)]--> MAG1 MH:if2 [HNP_2(P),HNP_2(T)]--> MAG2 LMA State (After) --------- MH:if1 [HNP_1(P),HNP_1(T)] --> MAG1 MH:if1 [HNP_1_1(T),HNP_1_2(T)]--> MAG1 MH:if2 [HNP_2(P),HNP_2(T)] --> MAG2 MH:if2 [HNP_2_1(T),HNP_2_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 MH: if1[HNP_1_2(T)] -->MAG1[Idle] Figure 7: Scenario 1 - Second Stage: PFHO Park & Kim Expires January 13, 2011 [Page 12] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 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 if1 and if2. * 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 BULE 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 transferred to if2. * MAG1: After receiving the L2 hints, MAG1 and MAG2 maybe 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. In here, the aggregated HNP_1(T) for HNP_1_1(T) and HNP_1_2(T) will be included in PBU. * 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 in order to support the reverse partial or full flow handover. * MAG2: After receiving the PBA, MAG2's BULE will be changed. Park & Kim Expires January 13, 2011 [Page 13] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 5.2. Scenario 2 - Sequential attachment This scenario considers the sequential attachment of multiple interfaces in MH. 5.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(T)] --> MAG1 +--+--+ MH: if1 [HNP_1_1(T),HNP_1_2(T)]--> MAG1 | |vi [HNP_1(P)] Figure 8: Scenario 2 - Initial Stage TBD. Park & Kim Expires January 13, 2011 [Page 14] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 5.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 --------- MH:if1 [HNP_1(P),flow1,flow2]--> MAG1 +----+ MH:if1 [HNP_1(T)] --> MAG1 |LMA | MH:if2 [HNP_1(P),flow3] --> MAG2 +----+ MH:if2 [HNP_2(T)] --> MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ MAG2 State |MAG1| |MAG2| ---------- +----+ +----+ MH: if2 [HNP_1(P),flow3]--> MAG2 | | MH: if2 [HNP_2(T)] --> MAG2 | | MH: if2 [HNP_2_1(T)] --> MAG2 | | | | MAG1 State | if1 if2 | ---------- +-----+-----+-----+ MH: if1 [HNP_1(P),flow1,flow2] --> MAG1 | MH | MH: if1 [HNP_1(T)] --> MAG1 +--+--+ MH: if1 [HNP_1_1(T),HNP_1_2(T)]--> MAG1 | |vi [HNP_1(P)] Figure 9: Scenario 2 - Second Stage TBD. Park & Kim Expires January 13, 2011 [Page 15] Internet-Draft PMIPv6 multihoming using 2-level prefixes July 2010 5.2.3. Third stage in scenario 2 After second stage, Inter-interface handover will be occurred 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. 6. IANA Considerations IANA considerations are not required. 7. Security Considerations TBD. 8. References 8.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. 8.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 13, 2011 [Page 16] 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 13, 2011 [Page 17] 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 13, 2011 [Page 18]