NetExt Working Group M. Jeyatharan Internet-Draft C. Ng Intended status: Standards Track Panasonic Expires: September 10, 2010 S. Gundavelli K. Leung Cisco V. Devarapalli Wichorus March 9, 2010 Partial Handoff Support in PMIPv6 draft-jeyatharan-netext-pmip-partial-handoff-02 Abstract Proxy Mobile IPv6 (PMIPv6) only supports session continuity for one basic scenario of vertical handoff -- the transfer of all prefixes assigned from one interface to another. However, there are some other advanced scenarios associated with vertical handoff that involves only transferring one (or some, but not all) of the prefixes that are allocated to an existing interface to a newly powered on interface. This draft outlines extensions to PMIPv6 protocol in order for a multiple interfaced mobile node to achieve such partial vertical handoff of selected prefix(es). 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 10, 2010. Jeyatharan, et al. Expires September 10, 2010 [Page 1] Internet-Draft Partial handoff March 2010 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases for Partial Handoff . . . . . . . . . . . . . . . . 4 3. Overview of Partial Handoff . . . . . . . . . . . . . . . . . 6 3.1. Partial Handoff to a New Interface . . . . . . . . . . . . 6 3.2. Partial Handoff to an Existing Interface . . . . . . . . . 8 3.3. Partial Handoff after Shutting Down an Interface . . . . . 10 4. Signaling Considerations . . . . . . . . . . . . . . . . . . . 12 4.1. Mobile Access Gateway Operation . . . . . . . . . . . . . 12 4.2. Local Mobility Anchor Operation . . . . . . . . . . . . . 14 4.3. Mobile Node Operation . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17 7.2. Informative Reference . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Jeyatharan, et al. Expires September 10, 2010 [Page 2] Internet-Draft Partial handoff March 2010 1. Introduction Inter-access technology handoff is performed in various environments and is one of the important handoff events in many standards development organizations, including the Third Generation Partnership Project (3GPP) mobility environment. In a generic sense, vertical handoff refers to handing off of flows from one interface to another interface. The most well known basic scenario associated with vertical handoff is the shutting down of an interface and transfer of flows from the shut down interface to a newly powered on interface. The Proxy Mobile IPv6 protocol (RFC-5213 [1]) allows a mobile node to perform a handoff by moving its address configuration from one interface to the other. The mobile access gateway attached to the access link where the mobile node is attached will provide this handoff hint to the local mobility anchor and the local mobility anchor will assign the same IPv6 home network prefix(es) and IPv4 home address to the currently attached interface that it previously assigned to the other interface prior to the handoff. This handoff will result in local mobility anchor changing the mobile node's IPv6 home network prefixes and the IPv4 home address association from one interface to a different interface and also the resulting data path adjustment. There can be many reasons for a mobile node (MN) to perform such basic vertical handoff. It can be due to discovery of a preferred access technology type that can give cheaper services or the need to transfer existing flows to the newly discovered access technology type to achieve better quality of service (QoS) to the existing flows. All mobility protocols has a requirement to support session continuity in such vertical handoff scenarios. For example, in Mobile IPv6 [3], a mobile node can send a binding update to the home agent via its newly powered on interface using the same home address used for the shut down interface in order to achieve vertical handoff. PMIPv6 [1] incorporates a network based session continuity mechanism to support the basic vertical handoff scenario. This mechanism is such that all the home network prefixes associated with the shut down interface are permanently transferred to the newly powered on interface, when appropriate vertical Handoff Indicator is inserted in the Proxy Binding Update (PBU) mobility signaling. In PMIPv6, when the mobile node shuts down an interface and performs a vertical handoff, the mobile access gateway (MAG) which the mobile node attaches to using the newly powered on interface will send a Proxy Binding Update with a Handoff Indication (HI) option that has a value of "2". When the local mobility anchor (LMA) receives the proxy binding update message, it will transfer all the prefixes previously assigned to the shut down interface to the newly powered Jeyatharan, et al. Expires September 10, 2010 [Page 3] Internet-Draft Partial handoff March 2010 on interface. However, there are other vertical handoff scenarios such as transferring a subset of prefixes from one interface to an alternate interface. A basic introduction to such requirement of transferring a subset of prefixes is given in ID-NETEXT-MULTI-PS [4]. Such selective transfers of one or more prefixes to a new interface (which we call a "partial vertical handoff", or simply "partial handoff") can take place due to mobile node's preference or network operations for load balancing purposes. In this draft, we highlight some use cases as given in Section 2 that are associated with the mobile node triggering such partial vertical handoff from a given interface to an alternate interface. In order to achieve such partial handoff, we proposes a few minor protocol extensions to RFC 5213. This is described in Section 3 and Section 4. 2. Use Cases for Partial Handoff Here, some use cases for partial vertical handoff are described in three different scenarios: o Partial Handoff to a New Interface The mobile node could be initially attached to the PMIPv6 domain via a cellular interface and at a later time may identify a wireless local area network (WLAN). In such an event, the mobile node may want only flows associated with a subset of prefixes that are best suited to the WLAN access technology type (example video flows) to be transferred to the WLAN interface when the mobile node attaches to the WLAN. In general, the mobile node may want the flows associated with a subset of prefixes to be transferred to the newly powered on interface, due to less cost via the access technology type, higher bandwidth provided, user preference, load balancing purpose and/or better QoS. If the mobile node cannot achieve flows tied to a certain group of prefixes to be transferred via a preferred access technology in PMIPv6 domain, it will impact on end user requirements and end user service experience. Furthermore, if such partial transfer of prefixes is not supported, the network unnecessarily needs to assign new prefix for the newly powered on interface and maintain mobility state for this prefix by means of Proxy Binding Update signaling. In 3GPP PDN connection establishment procedure as disclosed in [5] and [6], it is considered that multiple packet data network (PDN) connections can be made to the same service or access point name (APN). In such a case, when a new access type is discovered, some of the PDN connections or subset of prefixes belonging to the same APN can be transferred to the new access type. Jeyatharan, et al. Expires September 10, 2010 [Page 4] Internet-Draft Partial handoff March 2010 o Partial Handoff to an Existing Interface In another multihoming scenario in PMIPv6 domain, a mobile node may already be simultaneously attached to the network via multiple interfaces (e.g. via cellular and WLAN). In such scenario, due to either load balancing reason or to achieve better performance for flows via an interface, the mobile node may trigger partial handoff of a subset of prefixes from one connected interface to another connected interface. In ID-MEXT-FLOW-BIND [7], there is provided a mechanism for flow mobility in the granularity of a single data connection. However in this draft, we refer to flow mobility in the granularity of prefixes. If 3G access network is congested, the mobile node may want to keep the prefixes associated with flows that are ideal via 3G (e.g. Voice over IP) and transfer other prefixes associated with other type of flows to the WLAN access. Alternatively, if the access network is getting congested, for load balancing purpose, the mobile node may assist the network in identifying the flows that can be transferred to another access technology without impacting on end user service satisfaction. o Partial Handoff from a Shut Down Interface In some cases, a mobile node may shut down an interface and transfer only a subset of prefixes and the associated flows to a new interface or an existing interface. The use case to support such a scenario is when the mobile node discovers that session continuity for certain prefixes by means of PMIPv6 mobility management mechanism is not required via the alternate interface. This may be due to one or more prefixes are no longer being used, or session continuity for one or more prefixes is not required (e.g. only use for web browsing). We note that in most of these use cases, the decision to perform a partial handoff is purely based on mobile node's preference -- it could be due to consideration on cost, quality of service, available bandwidth and the types of flows associated with each prefix that the mobile node is currently assigned. Jeyatharan, et al. Expires September 10, 2010 [Page 5] Internet-Draft Partial handoff March 2010 3. Overview of Partial Handoff In this section, the partial handoff protocol operation is described for three different advanced vertical handoff scenarios mentioned in Section 2. We start off by first considering the initial scenario as illustrated in Figure 1, where the a mobile node MN with two interfaces IF1 (for 3G access) and IF2 (for WLAN access) is connected to the PMIPv6 domain. Initially, the mobile node has only interface IF1 connected to the PMIPv6 network, which is assigned with 3 prefixes: P1, P2 and P3. The binding cache entry created at the local mobility anchor LMA for IF1 is shown by the first entry in binding cache, which contains the home network prefixes, the proxy care-of address, the network access identifier of mobile node, the link layer identifier of the interface and the access technology type. +---------+ Binding Cache of LMA | LMA | +------------+-----------+-------+-------+------+ | | | HNP | Proxy CoA | MN-ID | LL-ID | ATT | +---------+ +------------+-----------+-------+-------+------+ / \ | P1, P2, P3 | MAG1 addr | NAI | IF1 | ATT1 | / \ +------------+-----------+-------+-------+------+ / \ / \ +------+ +------+ | MAG1 | | MAG2 | +------+ +------+ \ \ IF1(3G) \ / IF2(WLAN) +--------+ | MN | +--------+ Figure 1: Initial Scenario 3.1. Partial Handoff to a New Interface After some time, the mobile node detects the availability of WLAN access and wants to transfer all flows associated with P2 prefix to the WLAN interface IF2. Figure 2 describes the partial handoff process to achieve this. Jeyatharan, et al. Expires September 10, 2010 [Page 6] Internet-Draft Partial handoff March 2010 +-----+ +----------+ +------------+ +-----+ | MN | | MAG1(3G) | | MAG2(WLAN) | | LMA | +-----+ +----------+ +------------+ +-----+ | | | | |<-- RA(P1,P2,P3) --| | | | | | | MN discoveres WLAN and decides | | to transfer P2 to WLAN | | | | | | |------ L2 Attach & trigger for ----->| | | transferring P2 | | | | |--PBU(P2,HI=IANA-1)-->| | | | | | | |<--PBA(P2,HI=IANA-1)--| |<-------------- RA(P2) --------------| | | | |<=== Tunnel Est. ====>| | |<-- Remove P2 | | |<---- RA(P1,P3) ---| | | Figure 2: Message Sequence for Partial Handoff to a New Interface In Figure 2, mobile access gateway MAG1 initially advertises the three prefixes P1, P2, and P3 that are assigned to IF1 of the mobile node. When the mobile node MN detects the availability of WLAN access, it wishes to transfer the flows associated with prefix P2 to WLAN access. When the mobile node starts the first attachment via IF2, it will trigger a layer 2 (L2) attach message to MAG2 by means of access technology specific signaling. At the same time, the mobile node will inform MAG2 on the partial handoff of the prefix P2. How this is carried out is layer two specific and out of scope of this draft (as an example, the trigger may be embedded in the attach message, or sent by means of a new layer 2 message). When MAG2 receives the trigger for transfer of P2 from the mobile node, it will send a Proxy Binding Update message to the local mobility anchor with P2 in the Home Network Prefix option and a new value IANA-1 for the Handoff Indicator option. This new Handoff Indicator value IANA-1 indicates that this is a partial handoff to a new interface. When the local mobility anchor receives this Proxy Binding Update message, it will perform the following actions. The local mobility anchor will first locate an existing binding cache entry for mobile node with home network prefix P2. If the entry is present, the local mobility anchor will remove the prefix P2 from this entry, and create a new binding entry for interface IF2 with address of MAG2 as the proxy care-of address. Jeyatharan, et al. Expires September 10, 2010 [Page 7] Internet-Draft Partial handoff March 2010 MAG1 should also be informed to stop proxying for the prefix P2. This can be done by LMA sending a remove P2 notification to MAG1 (such as through the use of binding revocation [8]) or by MAG2 through the use of context transfer signalling between MAG1 and MAG2. After the partial handoff is completed, the new binding cache entry created for IF2 will have P2 assigned and the binding cache entry for IF1 will have prefixes P1 and P3 assigned. This is shown in Figure 3. Binding Cache of LMA +---------+ +------------+-----------+-------+-------+------+ | LMA | | HNP | Proxy CoA | MN-ID | LL-ID | ATT | | | +------------+-----------+-------+-------+------+ +---------+ | P1, P3 | MAG1 addr | NAI | IF1 | ATT1 | / \ +------------+-----------+-------+-------+------+ / \ | P2 | MAG2 addr | NAI | IF2 | ATT2 | / \ +------------+-----------+-------+-------+------+ / \ +------+ +------+ | MAG1 | | MAG2 | +------+ +------+ \ / \ / IF1(3G) \ / IF2(WLAN) +--------+ | MN | +--------+ Figure 3: After Partial Handoff of P3 3.2. Partial Handoff to an Existing Interface After a while, the mobile node finds that the bandwidth in WLAN is quite under-utilized, and decides to transfer flows associated with prefix P3 from IF1 (cellular) to IF2 (WLAN) as well. Jeyatharan, et al. Expires September 10, 2010 [Page 8] Internet-Draft Partial handoff March 2010 +-----+ +----------+ +------------+ +-----+ | MN | | MAG1(3G) | | MAG2(WLAN) | | LMA | +-----+ +----------+ +------------+ +-----+ | | | | |<-------------- RA(P2) --------------| | |<---- RA(P1,P3) ---| | | | | | | MN decides to transfer | | | P3 to WLAN as well | | | | | | | |--------- L2 trigger for ----------->| | | transferring P3 | | | | |--PBU(P3,HI=IANA-2)-->| | | | | | | |<--PBA(P3,HI=IANA-2)--| |<------------ RA(P2,P3) -------------| | | |<-- Remove P3 | | |<----- RA(P1) -----| | | Figure 4: Message Sequence for Partial Handoff to a New Interface Figure 4 shows the partial handoff of P3. As before, the mobile node sends a L2 trigger to the mobile access gateway MAG2 to request a transfer of prefix P3. MAG2 then sends a Proxy Binding Update message containing prefix P3 and Handoff Indicator value of IANA-2 to initiate the partial handoff of P3. This new HI value IANA-2 indicates that this is a partial handoff to an existing interface. Once the local mobility anchor receives this Proxy Binding Update message, it locates the existing binding cache entry for the mobile node with home network prefix P3 and removes P3 from this binding cache entry. Instead of creating a new entry for P3 (as is the case when handoff indicator is IANA-1), the local mobility anchor adds P3 to the binding cache entry for MAG2. MAG1 will also be notified that P3 is no longer assigned to IF1. The resulting binding cache is shown in Figure 5. Jeyatharan, et al. Expires September 10, 2010 [Page 9] Internet-Draft Partial handoff March 2010 Binding Cache of LMA +---------+ +------------+-----------+-------+-------+------+ | LMA | | HNP | Proxy CoA | MN-ID | LL-ID | ATT | | | +------------+-----------+-------+-------+------+ +---------+ | P1 | MAG1 addr | NAI | IF1 | ATT1 | / \ +------------+-----------+-------+-------+------+ / \ | P2, P3 | MAG2 addr | NAI | IF2 | ATT2 | / \ +------------+-----------+-------+-------+------+ / \ +------+ +------+ | MAG1 | | MAG2 | +------+ +------+ \ / \ / IF1(3G) \ / IF2(WLAN) +--------+ | MN | +--------+ Figure 5: After Partial Handoff of P3 3.3. Partial Handoff after Shutting Down an Interface After a while, the mobile node finishes all the sessions associated with prefix P3 (i.e. P3 is now unused). When the mobile node roams out of the coverage of WLAN, instead of performing a normal vertical handoff, it chooses to perform a partial vertical handoff to release P3. +-----+ +----------+ +------------+ +-----+ | MN | | MAG1(3G) | | MAG2(WLAN) | | LMA | +-----+ +----------+ +------------+ +-----+ | | | | |<------------ RA(P2,P3) -------------| | |<----- RA(P1) -----| | | | | | | MN roams out of WLAN | | | | | | | |--- L2 trigger --->| | | |for transferring P2| | | | |----------- PBU(P2,HI=IANA-2) --------->| | | | | | |<---------- PBA(P2,HI=IANA-2) ----------| |<--- RA(P1,P2) ----| | | Figure 6: Message Sequence for Partial Handoff after Shutting Down an Jeyatharan, et al. Expires September 10, 2010 [Page 10] Internet-Draft Partial handoff March 2010 Interface Figure 6 shows the partial handoff of P2. As before, the mobile node sends a layer 2 trigger to MAG1 to request a transfer of prefix P2. MAG1 then sends a Proxy Binding Update message containing prefix P2 and Handoff Indicator value of IANA-2 to initiate the partial handoff of P2. Once the local mobility anchor receives this Proxy Binding Update message, it adds prefix P2 to the binding cache entry for MAG1. The resulting binding cache is shown in Figure 7. +---------+ Binding Cache of LMA | LMA | +------------+-----------+-------+-------+------+ | | | HNP | Proxy CoA | MN-ID | LL-ID | ATT | +---------+ +------------+-----------+-------+-------+------+ / \ | P1, P2 | MAG1 addr | NAI | IF1 | ATT1 | / \ +------------+-----------+-------+-------+------+ / \ / \ +------+ +------+ | MAG1 | | MAG2 | +------+ +------+ \ \ IF1(3G) \ / IF2(WLAN) +--------+ | MN | +--------+ Figure 7: After Partial Handoff of P2 Jeyatharan, et al. Expires September 10, 2010 [Page 11] Internet-Draft Partial handoff March 2010 4. Signaling Considerations For supporting Partial Handoff feature, this specification defines two new Handoff Indicator values to be used in the Handoff Indicator option [1] carried in Proxy Binding Update and Proxy Binding Acknowledgement messages. Additionally, this specification defines the following considerations for the local mobility anchor and the mobile access gateway when using these Handoff Indicator values. 4.1. Mobile Access Gateway Operation The mobile access gateway when sending a Proxy Binding Update message to the local mobility anchor MUST follow the considerations specified in RFC5213 [1] and ID-PMIP-IPv4 [2]. However, if the request is for partial handoff support, the following additional considerations MUST be applied. o The specifics on how the mobile access gateway determines when to request partial handoff support, or how it learns what prefixes it chooses to handoff is out side the scope of this document. These triggers can be from any of the following: * In most cellular networks, handovers are controlled and the network provides the details to the mobile access gateway on what specific addresses or prefixes it needs to handover. * As part of the context transfer procedure initiated by the other mobile access gateway where the mobile node is currently attached over a different interface, the serving mobile access gateway can derive the partial handoff trigger. * A layer-2 trigger originating directly from the mobile node to the mobile access gateway on the list of prefixes or addresses it chooses to handoff from one interface to a different interface. o The mobile access gateway MUST apply the below considerations when choosing the value for the Handoff Indicator field. * The Handoff Indicator field MUST be set to a value of IANA-1 (Partial handoff to a newly attached interface), if the handoff is for moving addresses/prefixes from an existing attached interface of a mobile node to a newly attached interface. * The Handoff Indicator field MUST be set to a value of IANA-2 (Partial handoff to an existing attached interface), if the handoff is for moving addresses/prefixes between two mobile Jeyatharan, et al. Expires September 10, 2010 [Page 12] Internet-Draft Partial handoff March 2010 node's attached interfaces, for each of which there is a Binding Cache entry at the local mobility anchor. o When sending a Proxy Binding Update for initiating Partial Handoff request (Handoff Indicator field value set to a value of IANA-1 or IANA-2), the mobile access gateway MUST include exactly one Home Network Prefix option for each of the prefixes that are being handed to the current mobile node's interface attachment. o On receiving a Proxy Binding Acknowledgement message with the Status field value set to 0 (Proxy Binding Update accepted), the mobile access gateway MUST check the Handoff Indicator value specified in the Handoff Indicator option. * If the value in the option equals to IANA-1, the mobile access gateway MUST create a Binding Update List entry for the mobile node. * If the value in the option equals to IANA-2, the mobile access gateway MUST add the prefix(es) specified in each of the Home Network Prefix options to the mobile node's Binding Update List entry * The mobile access gateway MUST host each of the prefixes listed in the Home Network Prefix option(s), as on-link prefixes on the access link attached to the mobile node. It MUST include these prefixes in the Router Advertisements that it sends to the mobile node on that access link. * The mobile access gateway MUST enable routing for the traffic with the sources address of the packet set to these prefixes over the tunnel established with the local mobility anchor Jeyatharan, et al. Expires September 10, 2010 [Page 13] Internet-Draft Partial handoff March 2010 4.2. Local Mobility Anchor Operation The local mobility anchor on receiving a Proxy Binding Update message from the mobile access gateway MUST follow the considerations specified in RFC5213 [1] and ID-PMIP-IPv4 [2]. However, if the request is for partial handoff support, the following additional considerations MUST be applied. o If the value in the Handoff Indicator option is set to a value of IANA-1, the local mobility anchor MUST consider this request as a request for handoff of addresses/prefixes from one of the mobile node's mobility session for which there is an active Binding Cache entry to a new mobility session yet to be created and associated with the current mobile node's interface attachment. o If the value in the Handoff Indicator option is set to a value of IANA-2, the local mobility anchor MUST consider this request as a request for partial handoff of addresses/prefixes between two existing mobile node's mobility sessions for which there are existing Binding Cache entries. o The prefix(es) identified in the Home Network Prefix option(s) present in the request MUST be used for performing the Binding Cache entry lookup test . Considerations specified in Section 5.4.1.1 of [RFC-5213] MUST be applied for performing this Binding Cache entry existence test. If those checks specified in Section 5.4.1.1 result in associating the request to an existing mobility session, the local mobility anchor upon accepting the request MUST use this as a source mobility session for shifting the identified prefixes to the target mobility session. However, if there is no existing Binding Cache entry containing the identified prefixes, the local mobility anchor MUST send a response with a Proxy Binding Acknowledgement message with the Status code of "155 - NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX". o If the value in the Handoff Indicator option is set to a value of IANA-1, the local mobility anchor upon accepting the request MUST create a new Binding Cache entry and associate the request with the current mobile node's interface attachment. The local mobility anchor MUST use this as a target mobility session for shifting the identified prefixes. o If the value in the Handoff Indicator option is set to a value of IANA-2, the local mobility anchor MUST use either the Mobile Node's Interface Identifier option (if present) or the Proxy Care-of address of the current mobile access gateway that sent the request for performing Binding Cache entry lookup. The local mobility anchor MUST use this as a target mobility session for Jeyatharan, et al. Expires September 10, 2010 [Page 14] Internet-Draft Partial handoff March 2010 shifting the identified prefixes. o Upon performing the Partial handoff, the local mobility anchor MUST update the routes for forwarding the traffic to the current mobile access gateway that sent the request. o Upon accepting the request, the local mobility anchor SHOULD send a a Proxy Binding Acknowledgement message with a successful status code. The Proxy Binding Acknowledgement message MUST also contain the same Handoff Indicator option as in the corresponding Proxy Binding Update message. 4.3. Mobile Node Operation It is considered that the physical interfaces of the mobile node such as IF1 and IF2 in Figure 1, are hidden from the IP layer of the mobile node by means of the virtual interface abstraction layer implemented in the mobile node. The usage of virtual interface is to achieve partial handoff as described in Section 3 without any changes to the IP layer. The usage of virtual interface to hide interface switching in an application agnostic way and achieve seamless vertical handoff is highlighted in draft [9]). The mobile node is considered to use such virtual interface implementation as outlined in in draft [9]) when attaching to a PMIPv6 domain which can perform the partial handoff mechanism. o The decision to perform partial handoff via an access type can be controlled by mobile node's internal static policy or external policy given by an external entity. In scenarios where the mobile node initiates partial handoff, the mobile node's L2 will use the above mentioned policy to trigger partial handoff towards a network entity such as the MAG. o Irrespective of the physical interface via which the prefixes are received using the RA, all the prefixes are assigned to the virtual interface once the RA is processed by the IP layer. Thus prefix transfer from one access to another access is hidden from the IP layer. o When sending uplink data packets tied to a prefix associated with the mobile node, the virtual interface abstraction layer will route the data packet via an active interface through which the RA was obtained for the mentioned prefix. If there are multiple active interfaces for a given prefix of the mobile node (i.e. a given prefix was advertised in RA via multiple interfaces), then the virtual interface abstraction layer will route the packet via any of the active interface. Similarly when receiving a data packet with prefix of the mobile node, the virtual interface Jeyatharan, et al. Expires September 10, 2010 [Page 15] Internet-Draft Partial handoff March 2010 abstraction layer will check whether the interface via which the packet was received is active and attached to network and will further route the data packet to the IP layer after such checking process is successful. 5. IANA Considerations This draft introduces two new Handoff Indicator values that would require IANA assignment. These values needs to be assigned from the same numbering space as allocated for the Handoff Indicator option (RFC-5213 [1]): IANA-1: Partial handoff to a newly attached interface IANA-2: Partial handoff to an existing attached interface 6. Security Considerations All the security considerations from the base Proxy Mobile IPv6 protocol (RFC-5213 [1]) apply when using the extensions defined in this document. These considerations will ensure the signaling messages related to the partial handoff support specified in this document are properly secured and authorized. This document defines a new value for the handoff type, to be used in the Handoff Indicator option. The use of this value in the Handoff Indicator option, or the related processing considerations do not introduce any new security vulnerabilities. The mobile access gateway before initiating partial handoff request to the local mobility anchor on behalf of a mobile node needs to ensure that the mobile node is definitively notified of this partial handoff action and that it is able to perform such address movement between its interfaces. If this action is performed without proper coordination between the mobile node and the mobile access gateway, it may result in premature termination of certain sessions on the mobile node. 7. References Jeyatharan, et al. Expires September 10, 2010 [Page 16] Internet-Draft Partial handoff March 2010 7.1. Normative Reference [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [2] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-18 (work in progress), February 2010. 7.2. Informative Reference [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Jeyatharan, M. and C. Ng, "Multihoming Problem Statement in NetLMM", draft-jeyatharan-netext-multihoming-ps-02 (work in progress), March 2009. [5] "Technical Specification Group Services and System aspects", 3GPP TS 23.401, December 2009. [6] "Technical Specification Group Services and System aspects", 3GPP TS 23.402, December 2009. [7] Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic Support", draft-ietf-mext-flow-binding-06 (work in progress), March 2010. [8] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", draft-ietf-mext-binding-revocation-14 (work in progress), October 2009. [9] Yokota, H., Gundavelli, S., Trung, T., Hong, Y., and K. Leung, "Virtual Interface Support for IP Hosts", draft-yokota-netlmm-pmipv6-mn-itho-support-03 (work in progress), March 2010. Jeyatharan, et al. Expires September 10, 2010 [Page 17] Internet-Draft Partial handoff March 2010 Authors' Addresses Mohana Dahamayanthi Jeyatharan Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Phone: +65 65505494 Email: mohana.jeyatharan@sg.panasonic.com Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Phone: +65 65505420 Email: chanwah.ng@sg.panasonic.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: kleung@cisco.com Jeyatharan, et al. Expires September 10, 2010 [Page 18] Internet-Draft Partial handoff March 2010 Vijay Devarapalli Wichorus 3590 North First Street San Jose, CA 95134 USA Email: vijay@wichorus.com Jeyatharan, et al. Expires September 10, 2010 [Page 19]