NetExt Working Group M. Jeyatharan Internet-Draft C. Ng Intended status: Standards Track Panasonic Expires: September 5, 2009 S. Gundavelli K. Leung Cisco V. Devarapalli Wichorus March 4, 2009 Partial Handoff Support in PMIPv6 draft-jeyatharan-netext-pmip-partial-handoff-00 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 5, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Jeyatharan, et al. Expires September 5, 2009 [Page 1] Internet-Draft Partial handoff March 2009 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). 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 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 16 7.2. Informative Reference . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Jeyatharan, et al. Expires September 5, 2009 [Page 2] Internet-Draft Partial handoff March 2009 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 5, 2009 [Page 3] Internet-Draft Partial handoff March 2009 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 this, 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. 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 Jeyatharan, et al. Expires September 5, 2009 [Page 4] Internet-Draft Partial handoff March 2009 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 [5], 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 5, 2009 [Page 5] Internet-Draft Partial handoff March 2009 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 5, 2009 [Page 6] Internet-Draft Partial handoff March 2009 +-----+ +----------+ +------------+ +-----+ | 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 5, 2009 [Page 7] Internet-Draft Partial handoff March 2009 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 [6]) 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 5, 2009 [Page 8] Internet-Draft Partial handoff March 2009 +-----+ +----------+ +------------+ +-----+ | 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 5, 2009 [Page 9] Internet-Draft Partial handoff March 2009 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 5, 2009 [Page 10] Internet-Draft Partial handoff March 2009 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 5, 2009 [Page 11] Internet-Draft Partial handoff March 2009 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 5, 2009 [Page 12] Internet-Draft Partial handoff March 2009 node's attached interfaces, for each of which there is a Binding Cache entry at the local mobility anchor. * The mobile access gateway can initiate Partial Handoff request (handoff value set to either IANA-1 or IANA-2), only if it is certain that the mobile node is aware of this partial handoff and has removed the addresses associated with these prefixes that are being handed off from the other interface. Otherwise, it MUST NOT initiate partial handoff request. 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 5, 2009 [Page 13] Internet-Draft Partial handoff March 2009 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 5, 2009 [Page 14] Internet-Draft Partial handoff March 2009 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. 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. Jeyatharan, et al. Expires September 5, 2009 [Page 15] Internet-Draft Partial handoff March 2009 7. References 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-09 (work in progress), January 2009. 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-00 (work in progress), January 2009. [5] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-ietf-mext-flow-binding-01 (work in progress), February 2009. [6] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", draft-ietf-mext-binding-revocation-03 (work in progress), January 2009. 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 Jeyatharan, et al. Expires September 5, 2009 [Page 16] Internet-Draft Partial handoff March 2009 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 Vijay Devarapalli Wichorus 3590 North First Street San Jose, CA 95134 USA Email: vijay@wichorus.com Jeyatharan, et al. Expires September 5, 2009 [Page 17]