NetExt Working Group M. Jeyatharan Internet-Draft C. Ng Intended status: Informational Panasonic Expires: September 10, 2009 March 9, 2009 Multihoming Problem Statement in NetLMM draft-jeyatharan-netext-multihoming-ps-01 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, 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. Abstract The Proxy Mobile Internet Protocol version 6 (PMIPv6) supports multihoming whereby a mobile node (1) gets assigned prefixes by the local mobility anchor which are associated with an interface of a Jeyatharan & Ng Expires September 10, 2009 [Page 1] Internet-Draft Multihoming PS in NetLMM March 2009 mobile node and are managed by the PMIPv6 elements as a single IP mobility session, and (2) can connect to a Proxy Mobile IPv6 domain through multiple interfaces for simultaneous access and get assigned a different set of prefix(es) per interface, since being each interface managed via an independent mobility session. However, PMIPv6 needs multihoming enhancements such that it needs the ability to instantiate additional IP mobility sessions associated with an already active interface or a secondary interface of the mobile node which has an established IP mobility session at a local mobility anchor (LMA), the ability to selectively share home network prefix(es) across access technology types and extended support for multiple IP mobility sessions in a scenario where multiple interfaces of the mobile node are connected to a single mobile access gateway (MAG). This memo highlights such required enhancements to PMIPv6 multihoming with respect to improved operations and extended applicability to different deployment scenarios. Jeyatharan & Ng Expires September 10, 2009 [Page 2] Internet-Draft Multihoming PS in NetLMM March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Needed Enhancement to Create Dynamic Mobility Sessions . . . . 4 2.1. Needed Enhancement to Create Dynamic Mobility Sessions via an Interface . . . . . . . . . . . . . . . . . . . . . 4 2.2. Needed Enhancement to Create Dynamic Mobility Sessions Between Interfaces . . . . . . . . . . . . . . . . . . . . 5 3. Using the Same HNPs across Multiple Interfaces . . . . . . . . 6 4. Enhanced Support to Attach Interfaces to a Single MAG . . . . 7 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 10 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 10 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Use Case analysis if simultaneous usage and PMIPv6 Flow filering . . . . . . . . . . . . . . . . 10 Appendix C. Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario . 13 Appendix D. Multihoming Issues with Respect to Handoff . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Jeyatharan & Ng Expires September 10, 2009 [Page 3] Internet-Draft Multihoming PS in NetLMM March 2009 1. Introduction The Proxy Mobile Internet Protocol version 6 (PMIPv6) [1] supports three different multihoming operations. Firstly, a mobile node (MN) can receive home network prefix(es) via a certain interface and all assigned prefixes are managed under a single mobility session. Secondly, the mobile node is able to attach multiple interfaces to the PMIPv6 domain and receive different home network prefixes via each interface. Hence, the mobile node is able to communicate using all interfaces. Thirdly, the mobile node is able to transfer all its home network prefixes from a mobility session associated with an interface to a new mobility session created for a newly attached interface (i.e. vertical handoff). However, these multihoming operations need further enhancements -- either to increase their efficiency in operations or to be applicable to different deployment scenarios. This memo highlights such multihoming enhancements required, the need for such enhancements, and where applicable, the possible solution approaches. The required enhancements to PMIPv6 protocol with respect to multihoming support are described in three main sections. Section 2 describes the enhancement required with respect to the ability to dynamically create mobility sessions associated with an interface. Section 2 describes dynamically modifying the set of prefixes allocated to an interface, either by adding new prefixes or by transferring some prefixes from one interface to another. Section 3 describes multihoming enhancement needed to use the same home network prefix(es) across multiple interfaces to achieve benefits such as load sharing, load balancing, aggregated bandwidth and flow based routing. Section 4 highlights enhancement needed to PMIPv6 protocol operations and some optimizations that can be done to the PMIPv6 protocol, when applied to a scenario where multiple interfaces of a mobile node are attached to the PMIPv6 domain via a single MAG. In addition, other multihoming related issues that may need to be considered as part of PMIPv6 extensions in the future are described in Appendix C and Appendix D. 2. Needed Enhancement to Create Dynamic Mobility Sessions 2.1. Needed Enhancement to Create Dynamic Mobility Sessions via an Interface o Problem In PMIPv6 protocol, all the home network prefixes assigned to an interface are established when the mobility session is first created for a given interface. There is no support for adding Jeyatharan & Ng Expires September 10, 2009 [Page 4] Internet-Draft Multihoming PS in NetLMM March 2009 home network prefix(es) to the same interface in a dynamic manner. Thus, creating multiple mobility sessions or binding cache entries for a given interface is not possible according to the PMIPv6 protocol. o Motivation Such support is required especially in the cases where a mobile node wants to get appropriate home network prefixes to access services from the packet data networks (PDNs) in a 3GPP evolved packet core at different points in time rather than getting all the home network prefixes to access services at the same time. For example, a mobile node may want prefixes P1 and P2 to access services from packet data networks PDN1 and PDN2 respectively at time instance T1. Later at time instance T2, it needs to access services from PDN3 (thus requiring a prefix P3 to be assigned). o Possible Approaches To support this use case, PMIPv6 mechanism should be extended to support multiple mobility sessions associated with a given interface, each having a different group of prefixes assigned and may have different binding lifetime attached. 2.2. Needed Enhancement to Create Dynamic Mobility Sessions Between Interfaces o Problem In PMIPv6 protocol, when a mobile node powers on a new interface, the new mobile access gateway sets the handoff indication option value to '2'. All the prefixes that are assigned to the previously attached interface are then transferred to the new interface. When such transfer takes place, the binding cache entry of one interface is updated with the new binding cache entry created for the new interface. This is inflexible, as it cannot support the case where only some (but not all) prefixes that are assigned to one interface are transferred to a newly powered on interface, or transferred to an already connected interface. o Motivation Such dynamic management of mobility sessions whereby a subset of prefixes are removed from one interface and transferred to another interface is useful to support load balancing of flows across different interfaces of the mobile node. It also enable the flows tied to the transferred prefixes to traverse via a preferred or suitable access technology type for want of a better quality of Jeyatharan & Ng Expires September 10, 2009 [Page 5] Internet-Draft Multihoming PS in NetLMM March 2009 service (QoS) or cheaper service. o Possible Approaches To support this type of prefix transfer, new signalling mechanisms may be required in PMIPv6 to allow (a) the removal of one or more (but not all) home network prefixes from an interface of the mobile node, (b) the addition of one or more home network prefixes to a connected interface of the mobile node, and (c) the handoff of one or more (but not all) home network prefixes from an existing interface to a newly connected interface. 3. Using the Same HNPs across Multiple Interfaces o Problem PMIPv6 protocol operation is such that different home network prefixes are assigned to different interfaces of the mobile node. PMIPv6 does not support selectively using the same home network prefix across multiple interfaces of the mobile node. Benefits of doing this is thus not enjoyed with RFC5213. o Motivation If the flows associated with home network prefix(es) are allowed to traverse via multiple interfaces of the mobile node by allowing the same home network prefix to be assigned to multiple interfaces of the mobile node, then the mobile node can achieve higher aggregated bandwidth for flows tied to the home network prefix as well as achieve load balancing of traffic across its interfaces. Additionally, it is not only the mobile node that will enjoy benefits from sharing the same prefix among multiple interfaces, the network side can also benefit from it as well. For instance, when the local mobility anchor receives a packet destined for a home network prefix, it can choose among multiple routes to different interfaces of the mobile node to forward the packet. Such choice allows better utilization of the network resources and the network can avoid congested region of the local network domain. Furthermore, with the same home network prefix assigned to multiple interfaces, flow based routing can be achieved. For instance, the mobile node can choose to install filters on the network to route packets of realtime interactive application through its cellular interface which offers QoS assurance, and packets of other non-realtime application through other interfaces. A 3GPP operator can also have routing policy which route VoIP packets over the cellular radio network, while file transfer packets are routed over the WLAN network. Jeyatharan & Ng Expires September 10, 2009 [Page 6] Internet-Draft Multihoming PS in NetLMM March 2009 o Possible Approaches There are two requisites associated with selective usage of same home network prefix across multiple interfaces of the mobile node. The first requisite is being able to selectively use the same home network prefix across multiple interfaces and being able to receive flows tied to the home network prefix via any interface of the mobile node. This allows improved load balancing and aggregated bandwidth. The second requisite is is to be able to specify which flows are expected to traverse via which selected or preferred interface(es). This allows flow filtering in PMIPv6 based on user's preference or operator policy. To achieve the first requisite, it might be necessary for the mobile access gateway to be informed of which home network prefixes are shared between multiple interfaces. This can be informed by the mobile node or the local mobility anchor. It is also necessary for multiple routing paths to be enabled for a shared home network prefix among the affected mobile access gateways and the local mobility anchor. The mobile node should also accepts data packet sent to a shared home network prefix via any of its connected interfaces. To achieve the second requisite, it should be possible for the local mobility anchor to route packets based on explicitly specified flow filters. Such filters may be dynamically installed (and modified) by the network operator or the mobile node. To further understand the different simultaneous usage scenario and flow filtering scenarios more elaborate explanation is given in Appendix B. 4. Enhanced Support to Attach Interfaces to a Single MAG o Problem The PMIPv6 protocol supports simultaneous attachment to PMIPv6 network via multiple interfaces of a mobile node but with the assumption that each of the interfaces is attached to different mobile access gateways. However, in some deployment scenarios, a mobile access gateway may be handling different access technology types and may results in the mobile node attaching to the same mobile access gateway via multiple interfaces, such as illustrated in Figure 1. In section 5.3.1 of RFC5213, it is mentioned that if the Proxy-CoA in the binding cache entry matches the source address of the binding cache entry update request, considerations associated with binding lifetime extension (No handoff) MUST be applied. Thus it is clear that the PMIPv6 protocol does not Jeyatharan & Ng Expires September 10, 2009 [Page 7] Internet-Draft Multihoming PS in NetLMM March 2009 handle inter technology handoff where the mobile node is connected simultaneously to the same mobile access gateway. In addition, since the same mobile access gateway will be sending multiple PBU messages for the same mobile node, it will be desirable if these can be combined into one PBU message. +---------------+-----------+--------+ | Home Prefix | CoA | IF-ID | +--------+ +---------------+-----------+--------+ | LMA | | MN.Prefix1(P1)| MAG1.Addr | IF-ID1 | +--------+ | MN.Prefix2(P2)| MAG1.Addr | IF-ID2 | | +---------------+-----------+--------+ | +--------------------------+ | | | Proxy Mobile IPv6 Domain | | | +--------------------------+ | MAG1 Address | (MN.IF2/MN.IF1 proxy CoA) | +-------------+ | MAG1 | +-------------+ \ / IF2(3G) \ / IF1(WLAN) +------+ | MN | +------+ Figure 1: Multiple Interfaces attaching to same MAG o Motivation There are valid scenarios in some standard organizations where a single mobile access gateway may handle multiple attachments of a mobile node. For instance in 3GPP, it is possible for a Serving Gateway (S-GW) to be serving as the mobile access gateway for both the cellular and wireless-LAN access of a mobile node (e.g. the LTE access and the I-WLAN access are both connected to the same S-GW). In such scenarios, the PMIPv6 operation needs to be extended such that inter access technology handoff can be correctly and efficiently performed. o Possible Approaches In order to be able to support a scenario where the same mobile access gateway is proxying for multiple attachments of a single Jeyatharan & Ng Expires September 10, 2009 [Page 8] Internet-Draft Multihoming PS in NetLMM March 2009 mobile node, operation of the local mobility anchor should be modified. For instance, the local mobility anchor should rely only on the proxy care-of address when updating the binding cache entries. Other factors, such as the hand off indication option, should also be taken into account. To improve signalling efficiency, one possible approach is to allow the mobile access gateway to send a single PBU message when creating (or refreshing) multiple mobility sessions for the mobile node. well. 5. Conclusion In this memo, we highlighted additional work that has to be done with respect to multihoming for the PMIPv6 protocol. The main categories of additional work is dynamically creating mobility sessions tied to an interface, ability to use same home network prefixes across multiple interfaces of a mobile node, and extended ability to support a scenario where a mobile node attaches to the same mobile access gateway via multiple interfaces. 6. IANA Considerations This is an informational document and does not require any IANA action. 7. Security Considerations This document explores the problem of providing advanced multihoming for mobile nodes with multiple interfaces connecting to a single PMIPv6 domain. No additional security threat is identified as of the writing of this memo that is specific to multiple interfaces support. 8. Acknowledgements The authors would like to express their gratitude to (in alphabetical order) Carlos Jesus Bernados Cano, Basavaraj Patil, Yungui Wang and Hidetoshi Yokota for their gracious comments which have helped improve this draft. 9. References Jeyatharan & Ng Expires September 10, 2009 [Page 9] Internet-Draft Multihoming PS in NetLMM March 2009 9.1. Normative Reference [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 9.2. Informative Reference [2] 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. [3] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-11 (work in progress), January 2009. [4] "Technical Specification Group Services and System aspects", 3GPP TR 23.402, December 2007. Appendix A. Change Log o draft-jeyatharan-netext-multihoming-ps-01: * Added two new sections: One about dynamic creation of mobility sessions and another about supporting multiple interfaces via a single MAG. * Improved the same HNP usage across multiple interfaces by highlighting mor on solution space. * Moved the PMIP/CMIP interaction section and some scenarios that are more tied to handoff to appendix. o draft-jeyatharan-netext-multihoming-ps-00: * Initial version. Appendix B. Use Case analysis if simultaneous usage and PMIPv6 Flow filering To further understand the need for having the same home network prefix across multiple interfaces of the mobile node, consider the scenario depicted in Figure 2. Jeyatharan & Ng Expires September 10, 2009 [Page 10] Internet-Draft Multihoming PS in NetLMM March 2009 +-----+ +-----+ | CN2 |....| CN3 | +-----+ +-----+ | | +---------------+-----------+--------+ | | Home Prefix | CoA | IF-ID | +-----+ +--------+ +---------------+-----------+--------+ | CN1 |-----| LMA | | MN.Prefix1(P1)| MAG1.Addr | IF-ID1 | +-----+ +--------+ | MN.Prefix2(P2)| MAG2.Addr | IF-ID2 | | +---------------+-----------+--------+ | +--------------------------+ | | | Proxy Mobile IPv6 Domain | | | +--------------------------+ | | MAG2 Address | | MAG1 Address (MN.IF2 proxy CoA) | | (MN.IF1 proxy CoA) +------+ +------+ | MAG2 | | MAG1 | +------+ +------+ \ / IF2(3G) \ / IF1(WLAN) +------+ | MN | +------+ Figure 2: Simultaneous Usage in PMIPv6 Domain In Figure 2, it is assumed that the mobile node MN has two interfaces IF1 (3G cellular) and IF2 (WLAN) which are attached to mobile access gateway MAG1 and MAG2 respectively. According to PMIPv6 operation, it is considered that the IF1 will be assigned prefix P1 and IF2 will be assigned prefix P2. Thus, all flows addressed to prefix P1 will traverse via IF1 only and all flows addressed to prefix P2 will traverse only via IF2. Suppose MN is having video conference with correspondent node CN1, then MN may want the audio flows to traverse via 3G interface for better quality of service and the video flows to traverse via WLAN interface to get a higher bandwidth. The media flows associated with an application can be uniquely identified by a combination of parameters such as flow label, transport protocol numbers and port numbers as outlined in [2]. Normally, the audio and video flows of the same application will have the same pair of endpoint addresses. Thus, with current PMIPv6 as specified in RFC5213, the mobile node MN cannot split the video conference flows to traverse via different interfaces. This is Jeyatharan & Ng Expires September 10, 2009 [Page 11] Internet-Draft Multihoming PS in NetLMM March 2009 because the prefix P1 is tied to IF1 only and there is no mechanism available to set PMIPv6 filter or flow based routing. To fully enjoy the benefit of simultaneous usage of interfaces for such video conference application, it must be possible for prefix P1 to be used by multiple interfaces. LMA should have support such that same home network prefix or P1 should be tied to multiple interfaces, MAG2 should be aware of other interface prefix P1 and some filter rules needs to be set at LMA such that it is given instructions to route above mentioned voice flows associated with prefix P1 via interface 2 only and above mentioned video flows associated with prefix P1 via IF1 only. The requirement for same home network prefix usage across MN interfaces and filter rule setting may need MN involvement. It is clear that new functionality is essential in LMA, MAG and even in the MN to achieve simultaneous usage of MN interfaces for traversal of such multimedia application flows. This use case specifically highlights a need for a HNP being used via multiple interfaces and the need to set filter rules in the PMIPv6 network. In an alternate scenario associated with Figure 2 it is considered that MN is downloading some data files and also performing some web browsing and the CNs from which the MN is getting such data are CN1 and CN2 respectively. It is further considered that the prefix associated with MN to communicate with CN1 and CN2 is P1 and all the data packets associated with file transfer and web browsing will traverse via IF1. However, when the 3G interface is not used much by the MN for other flows, the MN may want all the data flows sent to prefix P1 from CN1 and CN2 to be sent to both interfaces of MN to achieve higher bandwidth for web browsing and file transfer applications. The MN can inform the LMA via the MAG that it needs P1 flows associated with above mentioned applications via both its interfaces. In this use case for same HNP(es) across MN interfaces, MN does not specify flow based routing preference. Instead MN needs to indicate to LMA that any interface can be used for the flows associated with the above mentioned web browsing and file transfer applications. As explained previously, PMIPv6 protocol does not support same home network prefix(es) usage across its interfaces. For such same home network prefix usage to happen, in case of downlink packets for example, MAG2 needs to be able to route packets sent to prefix P1, LMA needs to be able to route packets sent to prefix P1 via MAG2 as well as MAG1 and MN needs to know that this is PMIPv6 network and be able to configure prefix P1 for IF2 or be able to accept packet addressed to IF1 via IF2. All these changes needs to be done to get the benefits attached to this use case. In another scenario associated with Figure 2, MN may have started communication with CN1 using prefix P1 and communication with say CN3 using P2. However, due to load balancing feature or function being implemented in the PMIPv6 network, the LMA may send certain P2 flows Jeyatharan & Ng Expires September 10, 2009 [Page 12] Internet-Draft Multihoming PS in NetLMM March 2009 via IF1 and certain P1 flows via IF2. Such network initiated load balancing is essential in order to take some measures to prevent the network segments from being overloaded. In some cases, the MN may give its preference such as inform the network which P1 flows it does not mind being sent via interface 2 and which P2 flows it does not mind being sent via interface 1. Thus in such a scenario, both MAG1 and MAG2 need to know MN other interface prefixes and flow parameters and also the LMA need to send some P1 flows via MAG2 and some P2 flows via MAG1. Again, this use case highlights the need to support same multiple home network prefixes P1 and P2 across MN interfaces and be able to set flow based routing rules associated with multiple prefixes at LMA. Appendix C. Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario One other potential problem which should be consider in the future is when there are PMIPv6 and CMIPv6 interactions for a mobile node with Monami6 capability as described in [3]. The main issue in a PMIPv6 and CMIPv6 mixed scenario arises when the network is not aware of the simultaneous attachment related parameters used by the mobile node (i.e. CMIPv6 multihoming parameters) and mobile node is not aware of the network parameters (i.e. PMIPv6 multihoming parameters) used for simultaneous attachment. Such synchronization mismatch between network entities and terminal entities leads to lack of multihoming or simultaneous attachment support for the mobile node. This is illustrated with a specific example below. In third generation partnership project service architecture evolution (3GPP SAE) framework as outlined in [4], the mobile node can select PMIPv6 or DSMIPv6 (i.e. Dual stack MIPv6) when attaching via an interface or the network presets the allowed mobility management mechanism for certain interfaces of the mobile node. There are many scenarios involved with such simultaneous attachments using different mobility management mechanisms. One possible scenario could be that the mobile node (which has two active interfaces) is connected to home domain (in 3GPP terms, home public land mobile network, or HPLMN) via both its interfaces. One interface may be using DSMIPv6 for mobility management, while the other uses PMIPv6 for mobility management. Another scenario could be that the mobile node is simultaneously attached to home (HPLMN) and foreign domains (in 3GPP terms, visited public land mobile network, or VPLMN). Again, the mobile node could be using PMIPv6 for mobility management in its home domain, while using DSMIPv6 for mobility management in the foreign domain. Although the problem is highlighted using a 3GPP-specific deployment scenario, this is applicable in other similar scenarios as well. Jeyatharan & Ng Expires September 10, 2009 [Page 13] Internet-Draft Multihoming PS in NetLMM March 2009 +----------+ BCEs at LMA/HA | LMA/HA | +-------------+---------+-------+-----------+ | (P-GW) | | MN prefix | MN.CoA | MN-ID | If-ID/BID | +----------+ +-------------+---------+-------+-----------+ | \ | HoA | CoA.AR | - | BID1 | | \ | home prefix | MAG2addr| NAI | BID2 | | \ +-------------+---------+-------+-----------+ | \ | \ +-------------+ +---------------+ | MAG1 (AGW) | | MAG2 (ePDG) | +-------------+ +---------------+ | | IF1 | (WiMAX) IF2 | (WLAN) +-------------------+ | MN | +-------------------+ Figure 3: MuIF MN attaching to HPLMN using PMIPv6/CMIPv6 Mobility Management Mechanisms Figure 3 shows a 3GPP specific scenario, where the mobile node MN chooses DSMIPv6 mobility management to be used via the WiMAX interface (IF1) and PMIPv6 mobility management via the WLAN interface (IF2). MN will use the on-link prefix that is available in the WiMAX access network advertised by Access Gateway (AGW) to configure a care-of address for IF1. MN will perform the DSMIPv6 binding update at LMA/HA binding the home address to the care-of address configured using the on-link prefix. When MN performs such DSMIPv6 binding at the LMA/HA (implemented in 3GPP as a packet data network gateway, P-GW), the binding created is shown by the first entry in the cache. As mentioned, since this mobile node is MONAMI6 capable and it is performing simultaneous attachment, it will use a binding identifier (BID) option with value BID1 in its binding update. It is further considered that the home address is obtained from a prefix that is topologically rooted at the home P-GW. It is also assumed that MN is attaching to WLAN access via its second interface IF2 and chooses PMIPv6 mobility management mechanism to manage mobility for this interface. It is further assumed that MN sees the home network prefix (same as the DSMIPv6 home prefix) when MAG2 performs the PMIPv6 binding at the LMA/HA. When the home prefix is advertised via MAG2 (which may be an evolved packet data network gateway, ePDG, in 3GPP) there are definite advantages that the mobile node can enjoy, such as ability to direct flows to either of its interfaces. In order to attain simultaneous attachment in such a scenario, the proxy binding update sent by MAG2 needs to have an identifier to differentiate it from the BID of IF1. Since such a support is not Jeyatharan & Ng Expires September 10, 2009 [Page 14] Internet-Draft Multihoming PS in NetLMM March 2009 available in standard PMIPv6, simultaneous attachment in this mixed PMIPv6/CMIPv6 scenario is not possible. If MAG2 does not have any knowledge about the other interface of the mobile node, it will send a normal Proxy Binding Update without BID value. This will invalidate the DSMIPv6 binding that has already been registered at LMA/HA (i.e. entry 1 in binding cache). To avoid this, the PMIPv6 binding and CMIPv6 binding updates need to be differentiated by using different BID values. For example, MAG2 may be informed by the mobile node that it is performing simultaneous attachment so that the MAG2 may query the LMA/HA about interface 1 (which uses BID1). MAG2 can then use a different BID value when sending Proxy Binding Updates. Alternatively, MAG2 may request the LMA/HA to generate a BID value that is different from BID1. Another possible solution is for the mobile node to inform MAG2 what BID value to use for the PMIP binding. In case the mobile node in Figure 3 attaches to the network first via IF2 and the LMA/HA generates the BID2 for IF2's PMIPv6 binding, it is essential that BID1 needs to be different from BID2 to achieve simultaneous attachment. In such a scenario, the LMA/HA can provide a BID1 for IF1 during Internet Key Exchange (IKE) Signaling with the mobile node. Then, the mobile node will use this given BID1 for IF1 during the DSMIPv6 signaling and achieve simultaneous connection. Alternatively, the mobile node can inform LMA/HA via IF1 that it is simultaneously at home and away, so that LMA/HA can generate a BID1 for the IF1's DSMIPv6 binding. Appendix D. Multihoming Issues with Respect to Handoff In Figure 2, it is considered that the mobile node MN is attached to the PMIPv6 domain via both its interfaces. When one of the interface undergo handoff, the other interface might still be attached to the same access router. For example, due to the coverage area differences, the mobile node may change its access router for the WLAN interface while the access router of its 3G interface remains unchanged. If the mobile node suddenly loses connection to the network via the WLAN interface, according to standard PMIPv6 operation, the mobile node needs to trigger vertical handoff at the 3G MAG so as to maintain session continuity via its cellular interface. However, in some cases of disconnection, the mobile node may not have enough time to trigger vertical handoff at 3G MAG without suffering packet loss. Thus, there should be a fast handover binding mechanism to re-route flows to another interface when one interface has lost its connection with the shortest possible delay. Such fast handover binding can be installed beforehand in the mobile Jeyatharan & Ng Expires September 10, 2009 [Page 15] Internet-Draft Multihoming PS in NetLMM March 2009 access gateways, but remains dormant until a trigger activates it (such as when disconnection takes place). 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 Jeyatharan & Ng Expires September 10, 2009 [Page 16]