NetExt Working Group M. Jeyatharan Internet-Draft C. Ng Intended status: Informational Panasonic Expires: July 27, 2009 January 23, 2009 Multihoming Problem Statement in NetLMM draft-jeyatharan-netext-multihoming-ps-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 July 27, 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 (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. Abstract The base PMIPv6 protocol does not have adequate mechanisms to support advanced multihoming such as simultaneous usage of all interfaces of Jeyatharan & Ng Expires July 27, 2009 [Page 1] Internet-Draft Multihoming PS in NetLMM January 2009 a mobile node (MN) to receive and transmit data packets associated with a given prefix allocated to MN, and allow flow based routing according to preference, rules, and policies set by the MN or network entity. This memo highlights such advanced multihoming related issues when mobility of the multiple interfaced mobile node (MuIF MN) is purely managed by PMIPv6 mechanism. It also highlights the issue of lack of simultaneous attachment support when the mobility of the MuIF MN is managed by PMIPv6 and CMIPv6 mechanisms. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Advanced Multihoming Issues in PMIPv6 . . . . . . . . . . . . 3 3. Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario . . . . . . 7 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 11 7.2. Informative Reference . . . . . . . . . . . . . . . . . . 11 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Jeyatharan & Ng Expires July 27, 2009 [Page 2] Internet-Draft Multihoming PS in NetLMM January 2009 1. Introduction The multihoming support that is covered in the base Proxy Mobile IPv6 (PMIPv6) protocol [1] is simply simultaneous attachment support for multiple interfaced mobile nodes (MuIF MNs) such that a mobile node (MN) can use all its interfaces for data communication. Although using multiple interfaces for data communication is one aspect of multihoming, multihoming has many deeper motivations and scenarios attached to it as outlined in [2] and the base PMIPv6 protocol [1] does not have support for such advanced multihoming scenarios. There are many advanced multihoming scenarios associated with multiple interface attachment in PMIPv6 domain. One such scenario can be simultaneous "usage" of multiple interfaces for flows associated with a prefix given to the MN to achieve load sharing and load balancing benefits. Another scenario is preference or policy setting at the local mobility anchor (LMA) to enable a certain flow to traverse via an interface that is not allocated the prefix associated with the flow, so as to achieve the benefits of cost, preference, better quality of service (QoS) and/or security. Such transferring of flows via a preferred access type is generally referred as flow mobility. Another such advanced multihoming scenario can be transferring of certain flows associated with a group of prefixes from one interface to a newly powered on interface to satisfy user preference. Finally, one more scenario can be usage of simultaneous attachment in order to improve handoff performance. To implement such advanced multihoming scenarios that provides numerous benefits to data traffic of MN and the network operation and maintenance, there needs to be modification done to the PMIPv6 base protocol. In this memo, the advanced multihoming issues stated above are highlighted when the MuIF MN is connected to a domain in which only PMIPv6 is operated. In some network deployments the MuIF MN's mobility may be managed by different mechanisms such that the mobility of a certain interface will be managed by PMIPv6 mechanism and the mobility of another interface will be managed by CMIPv6 mechanism. Thus it is essential that PMIPv6 protocol has adequate support in such an environment to enable a Multiple Interfaced Mobile Node to be simultaneously attached to the network via its interfaces. In this memo, the lack of simultaneous attachment support in this mixed PMIPv6 and client MIPv6 (CMIPv6) environment is also highlighted. 2. Advanced Multihoming Issues in PMIPv6 In this section, three classes of issues will be looked into. They Jeyatharan & Ng Expires July 27, 2009 [Page 3] Internet-Draft Multihoming PS in NetLMM January 2009 are the simultaneous usage related issues, flow based routing related issues and issues related to transferring a sub-group of prefixes associated with an existing interface to a newly powered on interface. In addition to these, the issue associated with handoff performance when there is no advanced multihoming support is also briefly highlighted. o Issues Related to Simultaneous Usage of Interfaces The issues related to simultaneous usage of interfaces will be further split into three sub issues for deeper understanding of the problem. The first sub-issue occurs when the MuIF MN wants flows associated with an application to traverse via all its interfaces, the second sub-issue occurs when the MuIF MN wants flows associated with a given prefix of MN to traverse via all its interfaces and the third sub-issue occurs when the MuIF MN wants flows associated with a given group of prefixes of MN to traverse via all its interfaces. +-----+ +-----+ | 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 | +------+ Jeyatharan & Ng Expires July 27, 2009 [Page 4] Internet-Draft Multihoming PS in NetLMM January 2009 Figure 1: Simultaneous Usage in PMIPv6 Domain In Figure 1, it is assumed that the MN with two interfaces such as interface 1 (IF1) and interface 2 (IF2) are attached to Mobile Access Gateway 1 (MAG1) and MAG2 respectively. These MAGs and the LMA shown in Figure 1 are all attached to the same Proxy Mobile IPv6 domain. 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 P1 prefix of MN will traverse via the IF1 irrespective of which application that the flows belong to or to which CN the flows are associated with. However, if MN is having video conference with CN1 for example, then, MN may want the voice flows associated with the application to traverse via 3G interface for better Quality of Service (QoS) and want the video flows associated with the application to traverse via the wireless local area network (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 [3]. If the above mentioned voice and video flows have source or destination addresses associated with a certain interface such as interface 1 of MN, then according to standard PMIPv6 operation, the MN cannot enjoy its flows associated with video conference application to traverse via both its interfaces. This is because the standard PMIPv6 operation is such that routing is done only based on P1 prefix and nothing else. To fully enjoy the benefit of simultaneous usage, some rules needs to be set at LMA such that it is given instructions to route voice flows associated with P1 prefix via interface 2 and furthermore, the MAG2 should have additional support where such traversal of voice flow is possible. New functionality is essential in LMA, MAG and perhaps even in the MN to achieve simultaneous usage of its interfaces for traversal of the multimedia application flows. In an alternate scenario associated with Figure 1 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 P1 prefix 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 via both its interfaces and want Jeyatharan & Ng Expires July 27, 2009 [Page 5] Internet-Draft Multihoming PS in NetLMM January 2009 simultaneous usage service. As explained previously, base PMIPv6 protocol does not support this simultaneous usage scenario where simultaneous usage is preferred for a given prefix. For such simultaneous usage to happen, in case of downlink packets for example, MAG2 needs to be able to route packets sent to P1 prefix and LMA needs to be able to route packets sent to P1 prefix via MAG2 as well as MAG1. In another scenario associated with Figure 1 , MN may have started communication with CN1 using P1 and communication with say CN3 using P2. However, due to load balancing feature or function being implemented in the network, the LMA may send certain P2 flows 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, such simultaneous usage support where simultaneous usage of MN interfaces for flows associated with multiple prefixes of MN is not supported by the base PMIPv6 protocol. o Issues Related to Flow based Routing The MN in Figure 1 may want flows associated with P1 to be always routed via interface 2 and flows associated with P2 to be routed via interface 1. Such a scenario can happen when the MN decides to swap interfaces for flows based on dynamic state and user preference. In such a case, simultaneous usage is not activated but flow based routing needs to be implemented. Again, the current PMIPv6 protocol does not provide the required support. In such an environment, again, some modifications have to be done to the MAG, LMA and MN in order to provide flow based routing. o Issues Related to Handoff performance When all Interfaces are connected If the MN in Figure 1 is simultaneously attached to the PMIPv6 domain, one of the interface undergo handoff while the other interface remains attached to the same access router. For example, due to the coverage area differences, the MN may change its access router for the WLAN interface while the access router of its 3G interface remains unchanged. In such a case, until the WLAN interface's routing path is set up, packet loss and delay will be experience for P1 flows (P1 being assigned to WLAN Jeyatharan & Ng Expires July 27, 2009 [Page 6] Internet-Draft Multihoming PS in NetLMM January 2009 interface). To minimize such degradation during handoff, there needs to be mechanism allowing flows using the P1 prefix to be temporarily routed via the 3G interface. The base PMIPv6 protocol does not support this scenario of simultaneous usage during handoff. To enable such handoff enhancement, the MAG and the LMA needs to be able to route P1 flows via interface 2 while interface 1 is handing off. o Issues Related to Flow Mobility during Sudden Disconnection In Figure 1, it is considered that MN is attached to the PMIPv6 domain via both its interfaces. If suddenly, MN looses connection to the network via IF1, according to standard PMIPv6 operation, the MN needs to trigger vertical handoff at the 3G MAG to see P1 flows via IF2 and maintain session continuity. However, this cannot happen during disconnection, where the MN may not immediately know a disconnected state to correctly trigger vertical handoff at 3G MAG. Thus, there needs to be an appropriate mechanism available to handle this disconnection scenario as well. o Issues Related to transfering a sub-group of prefixes during Simultaneous Attachment Consider the case where the MN in Figure 1 initially has only its 3G interface active and assigned with multiple prefixes (eg. P1 and P2). When the MN subsequently discovers the WLAN access, it may want to use the WLAN interface simultaneously to achieve multihoming benefits. Later, when WLAN interface attaches to the PMIPv6 domain, according to standard PMIPv6 operation, a new prefix (say P3) will be assigned. However, MN already has two prefixes and may want to transfer flows using the prefix P2 to the WLAN interface due to preference, cost and/or bandwidth etc. Thus, some mechanisms need to be available such that the MN when attaching the WLAN interface can select a subset of prefixes assigned to 3G interface and request it to be assigned via the WLAN interface. Currently, the base PMIPv6 protocol does not support this. It only supports the vertical handoff case where all prefixes assigned to an old interface is transferred to a new interface when the old interface is shut down and the new interface turned on. 3. Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario In this section, PMIPv6 and CMIPv6 interaction scenarios are analyzed for MuIF MN that has MONAMI6 type of functionality. The MONAMI6 type of functionality is given in [4]. For the MuIF MN, the main issue in Jeyatharan & Ng Expires July 27, 2009 [Page 7] Internet-Draft Multihoming PS in NetLMM January 2009 a PMIPv6 and CMIPv6 mixed scenario arises when the network is not aware of the simultaneous attachment related parameters used by MN (i.e. CMIPv6 multihoming parameters) and MN 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 MN. In third generation partnership project service architecture evolution (3GPP SAE) framework as outlined in [5], the MN can select PMIPv6 or CMIPv6 (i.e. Dual stack MIPv6) when attaching via an interface or the network presets the allowed mobility management mechanism for certain interface of MN. There are many scenarios involved with such simultaneous attachments using different mobility management mechanisms. Some of the possible scenarios are next outlined. One possible scenario could be that MN (that 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 CMIPv6 for mobility management, while the other uses PMIPv6 for mobility management. Another scenario could be that MN is simultaneously attached to home (HPLMN) and foreign domains (in 3GPP terms, visited public land mobile network, or VPLMN). Again, MN could be using PMIPv6 for mobility management in its home domain, while using CMIPv6 for mobility management in the foreign domain. Although the problem is highlighted in a scenario that is used in 3GPP standard organization (SDO), this is applicable in similar scenarios that arises in other SDOs. +----------+ 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 2: MuIF MN attaching to HPLMN using PMIPv6/CMIPv6 Mobility Jeyatharan & Ng Expires July 27, 2009 [Page 8] Internet-Draft Multihoming PS in NetLMM January 2009 Management Mechanisms This scenario as shown in Figure 2 is a 3GPP specific scenario, where MN chooses CMIPv6 mobility management to be used via the WiMAX interface (MN.IF1) and PMIPv6 mobility management via the WLAN interface. 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 interface 1 of MN (MN.IF1). MN will perform the CMIPv6 binding update (BU) at LMA/HA binding the home address to the care-of address configured using the on-link prefix. When MN performs such CMIPv6 BU 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 MN is MONAMI6 capable and it is performing simultaneous attachment, it will use a binding identifier (BID) option with value BID1 in its BU. 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 and chooses PMIPv6 mobility management mechanism to manage mobility for this interface. It is further assumed that MN sees the home prefix (CMIPv6 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 MN can enjoy. It can enjoy PMIPv6 mobility management benefits for home prefix flows. In order to attain simultaneous attachment in such a scenario, the proxy binding update (PBU) sent by MAG2 needs to have some If-ID or BID2 that is different from BID1. Since such a support is not available in standard PMIPv6 mechanism, simultaneous attachment in such a mixed PMIPv6/CMIPv6 scenario is not possible. If MAG2 does not have any knowledge about MN's other interface CMIPv6 binding, it will send a normal PBU without BID value. When such a PBU is sent, it will invalidate the CMIPv6 binding that has already been registered at LMA/HA (i.e. entry 1 in BC). Such overwriting without proper binding specific parameter in the BU is already described in [4] for the multiple interface scenario. If the PMIPv6 binding and CMIPv6 binding are different mobility bindings arriving from different interfaces as in Figure 2, then they need to separated by BID. From the detail explanation, a mechanism by which MAG2 gets to know the correct value for BID2 needs to be supported by the system. For example, MAG2 may be informed by MN that it is performing simultaneous attachment so that the MAG2 may query the LMA/HA about interface 1 (BID1) and then perform the PBU at LMA/HA with a BID that is different from BID1. Alternatively, MAG2 may request the LMA/HA to generate the BID that is different from BID1. Another possible Jeyatharan & Ng Expires July 27, 2009 [Page 9] Internet-Draft Multihoming PS in NetLMM January 2009 solution can be that MN gives BID2 to MAG2, where BID2 is different from BID1, so that MAG2 can create the correct PMIPv6 binding for interface 2. In case the MN in Figure 2 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 Signaling with MN. Then, the MN will use this given BID1 for IF1 during the CMIPv6 signaling and achieve simultaneous connection. Alternatively, MN can inform LMA/HA via IF1 that it is simultaneously at home and away, so that LMA/HA can generate BID1 for the IF1's CMIPv6 binding. 4. Conclusion In this memo, we looked into two main cases of advanced multihoming scenario. One in pure PMIPv6 domain, and the other in a mixed PMIPv6 and CMIPv6 enviroment. In both cases, the base PMIPv6 protocol was found to be inadequate to support advanced multihoming so as to provide the full benefits of multihoming to a multiple interfaced mobile node. To summarize, base PMIPv6 protocol needs to be extended to support the following advanced multihoming scenarios: o Usage of MN Interfaces, to achieve "simultaneous usage" for flows associated with single or multiple prefixes given to MN. o Achieving flow based routing for particluar flows associated with a prefix given to a multiple interfaced MN. o Achieving improved handoff performance for multiple interfaced MN using simultaneous usage support. o Achieving vertical handoff and session continuity during to disconnection of one of the interfaces. o Achieving vertical handoff when a specific subset of prefixes needs to be transferred to the newly powered on interface. o Achieving simultaneous attachment for multiple interfaced MN in a PMIPv6 and CMIPv6 mixed mobility management scenario. 5. IANA Considerations This is an informational document and does not require any IANA action. Jeyatharan & Ng Expires July 27, 2009 [Page 10] Internet-Draft Multihoming PS in NetLMM January 2009 6. 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. 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. 7.2. Informative Reference [2] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6-multihoming-motivation-scenario-03 (work in progress), May 2008. [3] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-ietf-mext-flow-binding-00 (work in progress), May 2008. [4] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-11 (work in progress), January 2009. [5] "Technical Specification Group Services and System aspects", 3GPP TR 23.402, December 2007. Appendix A. Change Log o draft-jeyatharan-netext-multihoming-ps-00: * Initial version. Jeyatharan & Ng Expires July 27, 2009 [Page 11] Internet-Draft Multihoming PS in NetLMM 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 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 July 27, 2009 [Page 12]