NetLMM Working Group M. Jeyatharan Internet-Draft C. Ng Intended status: Informational Panasonic Expires: May 2, 2009 V. Devarapalli WiChorus J. Hirano Panasonic October 29, 2008 Multiple Interfaced Mobile Nodes in NetLMM draft-jeyatharan-netlmm-multi-interface-ps-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 May 2, 2009. Abstract The specific mechanism described in the current PMIPv6 draft to support multihoming is such that a unique prefix is given to each interface of a Mobile Node (MN) that is attached to the PMIPv6 domain. However, multihoming can also be provided using same unique prefix for all interfaces of MN similar to the MONAMI6 (Mobile Nodes and Multiple Interfaces in IPv6) concept. This memo explores and highlights lack of advanced multihoming support and other hand-off related issues where appropriate in three different mobility Jeyatharan, et al. Expires May 2, 2009 [Page 1] Internet-Draft Multiple Interfaces in NetLMM October 2008 management protocol models for multiple interfaced mobile nodes. Firstly, when single prefix is allocated for all interfaces of MN in the PMIPv6 domain. Secondly, when unique prefix is allocated for each interface as in PMIPv6 standard protocol model. Thirdly, when a multiple interfaced node uses different mobility management mechanisms for each of its interfaces. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multiple Interfaces Support Models in PMIPv6 . . . . . . . . . 4 2.1. Different Home Network Prefix for Each Interface . . . . . 5 2.2. Same Home Network Prefix for Each Interface . . . . . . . 7 3. Multiple Interface Problem Analysis for Single Prefix Model . 9 3.1. Problem Analysis for PMIPv6 with respect to Simultaneous Attachment Issues . . . . . . . . . . . . . . 9 3.2. Problem Analysis for Hand-off Scenarios . . . . . . . . . 14 3.3. Problem Analysis for Setting Filter Rule . . . . . . . . . 17 4. Multiple Interface Problem Analysis for Multiple Prefix Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Problem Analysis for Simultaneous Attachment . . . . . . . 19 4.2. Problem Analysis for Horizontal Hand-off . . . . . . . . . 20 4.3. Problem Analysis for Vertical Hand-off . . . . . . . . . . 22 5. PMIPv6/CMIPv6 Interaction Issues for Multiple Interfaced MN . 23 5.1. MuIf MN Simultaneous Attachment Issues in PMIPv6/CMIPv6 mixed Scenario . . . . . . . . . . . . . . . 25 5.2. MuIf MN PMIPv6/CMIPv6 signaling optimization . . . . . . . 28 5.3. PMIPv6 and CMIPv6 Prefix Processing at Home Domain . . . . 28 6. Single Interface Processing Multiple Prefixes . . . . . . . . 30 6.1. PMIPv6 and CMIPv6 Roaming Issues for Home Routed 3GPP Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.2. Multihoming Issues in Multiple LMA/HA Scenario . . . . . . 33 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 35 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 35 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 39 Jeyatharan, et al. Expires May 2, 2009 [Page 2] Internet-Draft Multiple Interfaces in NetLMM October 2008 1. Introduction Proxy Mobile Internet Protocol Version Six (PMIPv6) is a network based mobility management protocol which provides mobility management to all type of nodes including multiple interfaced (MuIf) mobile nodes (MNs) that may or may not have client MIPv6 (CMIPv6) functionality. Details of protocol operation and related terminologies are given in [1]. The PMIPv6 draft [1] highlight multihoming support for MuIf MNs by giving a unique prefix to each interface of MN. The base draft adopted such a unique prefix per MN interface model to provide basic multihoming support to an unmodified MN. The term basic multihoming refers to simultaneous "connection" support such that a MuIf MN can get connected to PMIPv6 domain and receive packets via all its interfaces. "Unmodified" MN is generally understood as nodes that do not have any software changes to obtain mobility support in the Proxy MIPv6 domain. Although the base PMIPv6 protocol assigns unique prefix for each interface of MN, multihoming can also be provided in PMIPv6 domain by using single unique prefix for all interfaces of MN. Assigning same unique prefix for all interfaces of MN in a PMIPv6 domain is conceptually similar to the multihoming model outlined in [2]. The multihoming support that is covered in the base PMIPv6 draft is simply simultaneous connection/attachment support for a multiple interfaced MN. However, there are many scenarios associated with multiple interface attachment such as simultaneous "usage" of multiple interfaces for a single IP flow, preference setting at an anchoring point to enable a certain flow to traverse via a certain interface or access technology type associated with MN, optimized vertical hand-off support when MN has two or more multiple interfaces connected to the network and MuIf MN performing roaming between home and foreign domains using one of its interfaces whereas another interface is still attached to the home domain. These advanced scenarios need additional mechanisms which require some enhancement/ modification to the current PMIPv6 base protocol. There are three objectives associated with this memo. The first objective is to analyze and highlight the problems in these above mentioned scenarios associated with a multiple interface node and to highlight the necessity of further enhancement to the basic PMIPv6 protocol. The second objective is to highlight the issues in the above mentioned multiple interface related scenarios when a single unique prefix is given to a MuIf mobile node in a PMIPv6 domain. By showing the operation of single unique prefix model, one can clearly compare which model of prefix assignment in PMIPv6 domain may be suited for a certain multiple interface related scenario. Thirdly, when a multiple interfaced node uses different mobility management mechanisms via each of its interfaces, different issues are Jeyatharan, et al. Expires May 2, 2009 [Page 3] Internet-Draft Multiple Interfaces in NetLMM October 2008 highlighted which requires further work irrespective of the PMIPv6 prefix assignment model. In all the issue analysis for MuIf MN, the need for terminal involvement when compared to a network based solution is highlighted where appropriate. There has been some work for single interface PMIPv6/CMIPv6 issues as outlined in [3]. However, in this memo the focus is on multihoming related issues when the interfaces uses heterogeneous mobility management protocols. For example, PMIPv6 mechanism via one interface and CMIPv6 mechanism via another interface. In addition to the above mentioned analysis for a MuIf MN, some issues for multiomed MN that uses a single interface is also highlighted. Many Standard Organizations (SDO) such as third generation partnership project (3GPP), third generation partnership project 2 (3GPP2) and WiMAX Forum are very much interested in adopting PMIPv6 as a mobility management protocol. We have done some study on the 3GPP architecture and thus in this memo, wherever appropriate, PMIPv6 multihoming problems pertaining towards the 3GPP service architecture evolution (SAE) network structure is highlighted. Nevertheless, it is important to understand that such problem analysis is also applicable to other SDO architectures as well. Some of the scenarios where PMIPv6 is considered to be used is clearly defined in [4]. In document [4], multiple interface related scenarios considered are only related to vertical hand-off between 3GPP access and non-3GPP access and vertical hand-off between non- 3GPP accesses. Nevertheless, in this memo, many futuristic multihoming scenarios that may well be adopted by 3GPP are considered due to the amount of interest for simultaneous usage support in service architecture two (SA2) WG activities in 3GPP. Basic concepts and usefulness of multihoming is already well defined in [5] and are thus omitted from this document. However, in this document, wherever possible, the benefits of each multihoming scenario being analyzed is highlighted. Moreover, the validity of each scenario is emphasized with respect to current 3GPP activities as outlined in [4] and possibly future 3GPP activities. 2. Multiple Interfaces Support Models in PMIPv6 In this section, the basic principle of two PMIPv6 multihoming models such as the same unique prefix across all interfaces and per interface unique prefix are given and the general merits and tradeoffs of these models are discussed. In addition to this, why the two models lack some of the advanced multihoming features such as simultaneous usage support as described in [2] and flow filtering features as given in [6] are explained. However, there are more optimization issues that are related to vertical hand-offs when MN Jeyatharan, et al. Expires May 2, 2009 [Page 4] Internet-Draft Multiple Interfaces in NetLMM October 2008 has multiple interfaces which will be detailed in other sections of this memo. 2.1. Different Home Network Prefix for Each Interface o Operation complexity at LMA/HA to support unique prefix per interface allocation In this model, each interface of MN is allocated a unique Home Network Prefix. To ensure that each interface of MN gets a unique prefix, the LMA/HA will use the MN interface identifier (ID) inserted in the Proxy Binding Update (PBU), a hand-off flag in PBU and its own binding cache entries to allocate such unique prefix per interface. This unique prefix per interface model is described in greater detail in [1]. If the interface ID (If-ID) in PBU is not available at the LMA/HA binding cache, and if the hand-off flag is set to "1" (implying new connection request), the LMA/HA will assign a new prefix for the interface. When the interface ID which is sent in the PBU is matched to an entry in LMA/HA, then the LMA/HA will treat it as horizontal hand-off (i.e. one interface disconnecting from a mobile access gateway (MAG) and connecting to another MAG) and assign the same prefix for session continuity. For advanced hand-off scenarios such as vertical hand-off (i.e. one interface shutting down and transferring flows to a newly powered on interface), the LMA/HA will use more information such as vertical hand-off flag inserted in the PBU and set to value "2" and in some cases the disconnected interface's If-ID, to assign the same prefix of the disconnected interface to the new interface. Suffice to say, the prefix allocation logic is pretty complex at LMA/HA for this multiple prefix model because correct prefixes needs to be assigned based on MN's state such as new connection, horizontal hand-off and vertical hand-off. In the base PMIPv6 draft, many modes of prefix allocation are described and all such variants are not described in this document to redce the complexity. o Lack of Simultaneous Usage Support Since unique prefix is assigned to each interface of MN, for practical purpose, this model can be treated as multiple MNs each having a single interface. Thus, in a general sense, LMA/HA will not be able to perform path switching for packets addressed to a particular interface. Moreover, from the description given in the base PMIPv6 draft, the bindings tied to a certain interface of MN will be considered as separate or independent mobility sessions and hence no IP flow switching is allowed. For example, if one considers MN's IF1 is assigned a prefix (P1) and MN's IF2 is assigned another prefix (P2). When LMA/HA receives a packet Jeyatharan, et al. Expires May 2, 2009 [Page 5] Internet-Draft Multiple Interfaces in NetLMM October 2008 addressed to an address configured using P1, LMA/HA would not route such packet via MN's IF2 path. In some use cases, it is preferred that an IP flow traverses via all interfaces of MN in order to achieve load sharing, load balancing and less cost (ex. flow traversing via cheaper access type) benefits. If MN is an IPv6 host using SHIM6 (Site Multihoming by IPv6 Intermediation) [7] or SCTP (Stream Control Transport Protocol) [8] or MN is a MONAMI6 (Mobile Nodes and Multiple Interfaces in IPv6) capable node as described in [2], then the MN can continue to enjoy simultaneous usage benefits such as an IP flow coming towards a MN address can be reached via one or more of MN interfaces. Unless some changes are done to PMIPv6 protocol, these external protocols are needed to achieve multihoming benefits in PMIPv6 domain. The important question is, whether it is beneficial to have these external protocols operate or use a mechanism that is more suited to PMIPv6 domain. Another important question that needs to be answered is, if 3GPP SDO enforces PMIPv6 mobility management mechanism for all interfaces of MN that are simultaneously attached to the 3GPP core network, then, a MN with MONAMI6 implementation cannot trigger the MONAMI6 stack since MONAMI6 stack is a derivative of CMIPv6. Under such circumstances, a simultaneous usage mechanism that is purely suited for PMIPv6 domain is deemed necessary. Moreover, this mechanism should be a derivative of the PMIPv6 mechanism. o Lack of Flow Filtering Support Setting filter rules (or preference setting) at the home agent (HA) to set preference of a certain flow to traverse via a certain care-of address (CoA), when roaming in foreign domain, is a well understood method and is described in [6]. However, in PMIPv6, the situation is slightly different. For example, if a MuIf MN is roaming in a local domain and PMIPv6 is used for mobility management, then MN will see different prefixes via its different interfaces and these prefixes will be used for session establishment with CNs (correspondent nodes). If MN wishes certain flows to be delivered via a certain access technology due to cost, quality of service (QoS), bandwidth, preference and security, then, such filter rules should be set at the local mobility anchor. However, MN operating in the PMIPv6 mode does not know its LMA/HA or the packet data network gateway (P-GW) address (P-GW is equivalent to LMA/HA in 3GPP architecture). In such a case, MN must pass its flow filtering rules to the MAG to which it is attached because only the MN can decide which flow is preferred via a certain access technology type. Such flow filtering support mechanisms are essential and currently not supported in PMIPv6 base specifications. If PMIPv6 does not support a mechanism to set filter rules, then the only way MN can Jeyatharan, et al. Expires May 2, 2009 [Page 6] Internet-Draft Multiple Interfaces in NetLMM October 2008 attain the preference setting or flow filtering is by setting the preference at CN. If the CNs are placed far away from MN, then setting such filters at CN increases the signaling cost or signaling load in the fixed infrastructure. Moreover, in order to establish such preference setting at LMA/HA in a pure PMIPv6 mode, simultaneous usage support should be enabled in the PMIPv6 system. As discussed before, flow filtering mechanism that is specifically designed for PMIPv6 is necessary, if 3GPP restricts PMIPv6 mechanism via all interfaces of MN. o Prefix Resource Usage Another general issue with this unique prefix per interface model is that, prefix resources are wasted. Due to such wastage, in some cases, a node may not get a prefix via a certain interface in PMIPv6 domain, if the PMIPv6 domain is supporting numerous MNs with many active interfaces. 2.2. Same Home Network Prefix for Each Interface In this model, each interface of MN will receive the same unique Home Network Prefix. In such a scenario, MN should accept or probably be configured to accept packets to be received by any interface as long as the destination address matches the Home Network Prefix regardless of the actual address configured (or assigned) for that interface. If PMIPv6 implements such single prefix model, there is no need for the MN to run separate multihoming enabling protocols (such as SHIM6, SCTP, MONAMI6) to enjoy benefits of multihoming. The main advantage of this model is that complex prefix allocation mechanism at LMA/HA can be avoided and prefix resources are not wasted. The single unique prefix model can be implemented using three different methods as mentioned in [9]. These different methods of implementing the single unique prefix method is next described in detail with respect to simultaneous usage support and flow filtering mechanism. The three methods are prefix-based caches at LMA/HA, different address based caches at LMA/HA and same address based caches at LMA/HA. o Prefix Based Caches at LMA/HA When prefix based caches are maintained at LMA/HA, since the prefixes are the same, to maintain separation in the cache entries, interface identifiers (If-ID) or binding identifiers (BIDs) needs to be used. Binding Identifiers are described in draft [2]. The main problem with this method of implementing the caches is that, routing is based on prefixes and there is a tendency for packets sent to a particular address being routed to Jeyatharan, et al. Expires May 2, 2009 [Page 7] Internet-Draft Multiple Interfaces in NetLMM October 2008 a wrong interface if the MN configures different addresses for its interfaces. When compared to the unique prefix per interface model, simultaneous usage can be easily achieved with such an implementation because, a flow can be routed via any of the MN interfaces. This is because the routing is based on prefix and there is only a single prefix assigned for all interfaces. However, to achieve simultaneous usage, the MAGs needs to be informed of MN other interface address or need to be configured in such a way that the layer two (L2) reachability of MN interface is tied to the prefix of MN rather than the IPv6 global address. From the brief description given above, it should be clear that to activate this model and achieve simultaneous usage, some terminal involvement is necessary because only the MN will know its different addresses across its interfaces. When setting filter rules, the flow identifier (FID) as described in [6] should be tied to the Interface identifier or BID rather than the prefix or address. This is because, the same prefix is assigned to all interfaces of MN and such variation in flow filtering support should be considered. o Different Address Based Caches at LMA/HA In this method of implementation, MN configures different addresses for its interfaces and the caches at the LMA/HA are address based rather than prefix based. When address based caches are used, interface identifiers need not be used to separate the bindings. The main drawback of this method is that the routing path at the LMA/HA cannot be set up until address configuration is complete and there is a slight delay in routing path set up. The problem of packets being routed wrongly as described previously in the prefix based cache method does not occur in this implementation. This is because, the routing at the LMA/HA is address based. However, to attain simultaneous usage benefits, proper mechanisms needs to be activated at the LMA/HA and the MAGs. For example, the LMA/HA need to identify all MN addresses belong to same MN and then tunnel packets of a certain address via other MAGs that have reachability state for MN other addresses. Furthermore, the MAGs need appropriate mechanisms to allow packets that are addressed to MN other interfaces that are not directly connected to it to be routed. In this address based mechanism, filter rules can be tied to the address associated with the interface itself similar to that described in the flow filtering Internet draft [6]. o Same Address Based Caches at LMA/HA In this method, all MN interfaces configures the same address. Thus the problems as to packets being routed wrongly or lack of Jeyatharan, et al. Expires May 2, 2009 [Page 8] Internet-Draft Multiple Interfaces in NetLMM October 2008 simultaneous usage support does not occur in this implementation. However, preference or filter rules needs to be set. Since the caches are separated probably using interface identifiers, the flow filtering setting needs to tie the flow to the interface identifier. 3. Multiple Interface Problem Analysis for Single Prefix Model In this section, problem analysis for multiple interfaced mobile nodes when PMIPv6 uses a single unique prefix per MN model is presented. The assumption in the analysis regarding which PMIPv6 functional entity is mapped to which 3GPP architectural entity is based on details provided in documents such as [4] and [10]. The issues discussed in this section are issues related to simultaneous attachment, horizontal and vertical handoff issues and flow filtering issue in foreign domain. Specifically, the issues discussed under simultaneous attachment are getting the simultaneous cache set up at LMA/HA using optimized methods in various types of access network link models, simultaneous attachment support for unmodified MN and simultaneous usage support for MN's that can be modified. 3.1. Problem Analysis for PMIPv6 with respect to Simultaneous Attachment Issues Jeyatharan, et al. Expires May 2, 2009 [Page 9] Internet-Draft Multiple Interfaces in NetLMM October 2008 +-------------+-----------+--------+-----------+ | Home Prefix | CoA | MN-ID | If-ID/BID | +---------------+ +-------------+-----------+--------+-----------+ | LMA/HA/(P-GW) | | MN.P1 | MAG1.Addr | NAI |If1-ID/BID1| +---------------+ | MN.P1 | MAG2.Addr | NAI |If2-ID/BID2| | +-------------+-----------+--------+-----------+ | BCEs at LMA/HA +--------------------------+ | | | Proxy Mobile IPv6 Domain | | | +--------------------------+ | | MAG2.Addr | | MAG1.Addr +--------------+ +-----------+ | SGW/MAG2 | | ePDG/MAG1 | +--------------+ +-----------+ \ / If2(3G) \ / If1(WLAN) +------+ | MN | +------+ Figure 1: Attaching Multiple Interfaces to PMIPv6 that deploys Single Prefix Model o Maintaining Simultaneous Bindings at LMA/HA in 3GPP Architecture Figure 1 shows a multiple interfaced MN, which is simultaneously attached to a PMIPv6 network (3GPP evolved packet core (EPC) network) via both its interfaces. It is considered that MN.If1 (i.e. Interface 1 of MN) is a wireless local area network (WLAN) type of interface and MN.If2 is a third generation cellular (3G) interface such as the evolved universal terrestrial radio access network (E-UTRAN) interface. MN.If1 is attached to the evolved packet data gateway (ePDG) via an IPSec tunnel and MN.If2 is attached to Serving Gateway S-GW/MAG2, which may be its first hop router. It is considered that the ePDG/MAG1 is not the first hop router for MN.If1. It is important to appreciate that MN accessing both 3G and WLAN services while moving can provide many multihoming benefits to the MN. Furthermore, having both interfaces on during inter access technology hand-off is also a possible optimization scenario for vertical hand-off and thus such simultaneous usage support is essential. As highlighted previously, if single prefix type of prefix allocation is supported at LMA/HA, then, there needs to be some parameter (If-ID, BID etc) in the LMA/HA cache to differentiate Jeyatharan, et al. Expires May 2, 2009 [Page 10] Internet-Draft Multiple Interfaces in NetLMM October 2008 the bindings from same MN, especially for prefix based caches. In this prefix allocation model, the interface IDs are merely used to differentiate the binding entries associated with multiple interfaces of MN. Interface IDs are not used in prefix assignment. Here, Network Access Identifier (NAI) will be used for prefix assignment because only a single prefix needs to be assigned to a multiple interfaced MN. In Figure 1 it is assumed that MN.If1 roams into the PMIPv6 domain first and gets attached to MAG1. The routing state created at LMA/HA due to attachment at MAG1 is shown by the first entry in the binding cache (BC). When MN.If2 detects 3G and does association, MAG2 will send a Proxy Binding Update (PBU) to the LMA/HA, requesting to bind the Home Network Prefix of MN to the proxy care-of address (CoA), which is MAG2.Addr (see 2nd BCE). It is further assumed that the PBU has If-ID or BID information embedded into a mobility option. Interface ID in PBU can be media access control (MAC) address or interface identifier that MN use to form global unicast IPv6 address. If latter type of interface identifiers are used, then it is essential that they are unique across MN interfaces. This may not be possible if DHCP is used for address configuration or interface identifiers are randomly generated. Thus, as mentioned in [1], the use of MAC addresses for interface IDs is highly favored, due to their uniqueness per interface and also they are usually shorter than If-ID associated with an IPv6 address. Such assumption about interface ID being MAC address is adopted in this memo. If the MAG is a first hop router with respect to MN, then, using interface ID for cache separation may be beneficial because MAC address can be readily obtained at the MAG by means of standard IPv6 neighbor discovery message exchanges, without any explicit signaling in the system to inform this to MAG. If MAG1 is collocated at ePDG as shown in Figure 1, MN needs to set up a virtual point-to-point link, which is an IPSec tunnel, to access the ePDG/MAG1 (ePDG is usually multiple hops away from MN). Moreover, in such virtual point-to- point link scenario, the MAG function at ePDG cannot obtain MN's MAC address by means of simple neighbor discovery messages. This is one area where some further work is required. Appropriate LMA/HA cache separation parameter (If-ID(MAC address) or BID) need to be conveyed to the target MAG, which is multihops away (at layer 3 (L3)) from MN. Furthermore, in such scenario, using BID is beneficial as opposed to If-ID(MAC address) to maintain multiple caches at LMA/HA. The reason being that, the BID field size is usually much smaller than the interface ID(MAC address). From the brief analysis given in this section, in the ePDG scenario, it is clear that some explicit signaling is essential to inform the MAG collocated at ePDG about the BID or If-ID(MAC Jeyatharan, et al. Expires May 2, 2009 [Page 11] Internet-Draft Multiple Interfaces in NetLMM October 2008 address) value, in order to create PMIPv6 binding at LMA/HA. If MN use MAC address to form the globally unique interface identifiers in the stateless mode of address auto configuration, the ePDG can obtain a unique interface identifier (MAC address) from the source address of the outer tunnel's IPv6 header. Here it is considered that the data packets are encapsulated in an IPSec tunnel from MN to ePDG where the source address (called the nomadic address) of the outer tunnel is obtained from the untrusted access network. However, in such a scenario, it is essential to notify ePDG that this nomadic address was configured using MAC address. Next, few approaches of ePDG getting a unique If-ID(MAC address)/ BID is explored. If ePDG does not know the If-ID/BID (assuming no explicit message from MN to notify), then ePDG in Figure 1 may generate a random If-ID/BID. If this randomly generated If-ID/BID is same as MN's some other interface If-ID/BID (ex. MN.If2 identifier or BID associated with MN.If2), then the PBU with the ePDG generated random If-ID/BID may overwrite an existing If-ID/ BID that is available at LMA/HA cache. Such overwriting at LMA/HA will cause a loss of a valid routing state and simultaneous connection support will be lost. Another way for getting If-ID/ BID for simultaneous attachment is for Authentication Authorization Accounting server (AAA) to generate unique If-IDs/ BIDs for initial attachments across MN interfaces and assume that If-IDs/BIDs can be transferred via context transfer for hand-off attachments. Yet another way is for the MAG/ePDG to query nearby routers for MN's If-IDs/BIDs and then generate a unique interface ID/BID. With so many approaches, some further analysis needs to be performed to select the best possible method. Especially, when one considers all possible scenarios in 3GPP such as home routed and chained scenarios described in [4], terminal informing the If- ID/BID to the ePDG via an explicit new message or as an option integrated with standard messages may be the most appropriate or efficient way. The above said home routed scenario and chained scenario as described in [4] is where the PMIPv6 prefix is seen when MN is roaming or attached to foreign network. In such a scenario, any network based solution may not be very efficient due to the long routing delay when network entities are involved in informing the If-ID/BID at the target ePDG/MAG. o Simultaneous Access Support for Unmodified MN Suppose MN is an unmodified host in Figure 1 and performs such a simultaneous attachment, and if it is given same address as MN.If1 for MN.If2 via statefull address auto configuration method, then MN.If2 cannot configure a global IPv6 address and that interface will not be used. This will be according to current Jeyatharan, et al. Expires May 2, 2009 [Page 12] Internet-Draft Multiple Interfaces in NetLMM October 2008 implementation of the IPv6 stack. In such a case, MN can only receive packets via MN.If1 and packets sent to MAG2 will be lost until MAG2 detects that MN.If2 is not attached and sends a deregistration PBU to LMA/HA. Thus, simultaneous attachment is not obtained. On the other hand, if MN configures different addresses on its interfaces using stateless address auto configuration, then successful simultaneous attachment can be obtained. However, packets arriving at LMA/HA to address of MN.If1 may be sent via MAG2 and MAG2 will drop the packets because it does not have a neighbor cache entry mapping address of MN.If1 to the layer two (L2) address of MN.If2. Although basic multihoming or simultaneous attachment support can be achieved when MN configures different addresses, when LMA/HA routes packets based on prefix, packets to one address to which a MAG does not have supporting neighbor cache entry will be lost. The MN cannot be involved in providing the other interface address to the MAG to solve the issue, as this is an unmodified host and cannot be involved in any protocol changes. From the description given above, it is clear that when an unmodifed MN is assigned same address to all its interfaces it is nearly impossible to achieve simultaneous attachment. Some changes can be done at the network side to prevent activation of stateful mode of address auto configuration for unmodified host and thus avoid same address being allocated for its interfaces. Another possible means is that, the dynamic host configuration protocol (DHCP) signal can be intercepted by MAGs and MAG could insert some interface specific options to the DHCP message so that the DHCP server assigns different addresses across MN interfaces. From the brief analysis it is clear that, although the problem of simultaneous attachment can be solved by network based mechanisms described, there is still the routing issue if prefix based caches are used at LMA/HA. This issue can be solved by using address based caches at LMA/HA. However, as described before, address based caches has its own set of disadvantages. From this analysis, it can be seen that basic multihoming or simultaneous attachment support can be achieved in the single prefix model for unmodified MN as well. However, when compared to the multiple prefix model, more care should be taken from the network side and address based cache structure may be necessary. Thus for unmodified MN, multiple prefix model or unique prefix per interface model is more suited. o Simultaneous Usage Support As explained before, simultaneous usage support can be achieved when an IP flow is allowed to traverse via all interfaces of MN. For this to happen, the addresses associated with all MN Jeyatharan, et al. Expires May 2, 2009 [Page 13] Internet-Draft Multiple Interfaces in NetLMM October 2008 interfaces needs to be available at all MAGs the MN is attached to. Which network entity informs this to the MAG, depends on which cache model is used at LMA/HA. If address based caches are used, LMA/HA can inform these addresses to MAG. Else, MN has to inform this to MAG. Such variable solutions needs further investigation to decide on an appropriate solution. 3.2. Problem Analysis for Hand-off Scenarios Hand-offs are generally classified as horizontal hand-offs and vertical hand-offs. The base PMIPv6 draft focuses on session continuity for a prefix assigned to an interface. However, in [1] there was no description on mechanisms to support hand-off optimizations during hand-offs. Hand-off optimization refers to reduction in delay, packet loss, jitters and reduced hand-off signaling during the hand-off process. Such optimizations are essential for next generation networks that wants to provide highly sophisticated and high quality services to end services. o Horizontal Hand-off for Multiple Interfaced MN Horizontal hand-off from L3 perspective means hand-off of a single interface from current access router(AR)/MAG to another access router/MAG which results in a change in the L3 routing path to the LMA/HA. This sub-section describes some additional features that are required in the system to achieve horizontal hand-off optimization for a multiple interfaced MN. In a scenario where one of the interface performs horizontal hand- off while the other interface is still attached, there are not many issues with respect to creating simultaneous attachment at LMA/HA. The reason being the new MAG only needs to know the If- ID/BID of the interface that is performing the horizontal hand-off to create the correct routing entry at LMA/HA. Again, the new MAG can get to know this If-ID/BID by various means. As described previously, new MAG can get to know If-ID/BID via context transfer from old MAG, from AAA, from the MN, or obtaining directly from MAC address. The horizontal hand-off of a certain interface can be optimized using another stable interface (i.e. interface that is not perfoming hand-off), if simultaneous usage support is available in the system. For example, during the time when there is no routing state at the LMA/HA associated with an interface (during horizontal hand-off time), such as the time between MN deregistration PBU has arrived from old MAG and the new PBU has not yet arrived from the new MAG, the packets can easily be routed via another stable interface. Such an optimisation can be easily Jeyatharan, et al. Expires May 2, 2009 [Page 14] Internet-Draft Multiple Interfaces in NetLMM October 2008 achieved using the single prefix per MN model and when simultaneous usage mechansim is deployed in the system. As mentioned previously, to achieve simultaneous usage support for the single prefix model, the MAGs can be configured to tie the L2 address of an interface to the MN prefix rather than the L3 address or the MN explicity notifies all its interface addresses (unicast global) to all the MAGs it is attached with. With such simultaneous usage support, during hand-off time, LMA/HA can easily utilize a stable interface to route packets until the hand- off has been completed. Such a scenario is a very probable scenario in future evolved 3GPP architecture, where a MuIf MN performs multiple horizontal hand-offs via the WLAN interface while still being connected to the 3G interface. In such a scenario, it can be seen that, using the stable interface and such simultaneous usage support, packet loss can be reduced. o Vertical Hand-off for Multiple Interfaced MN * Vertical Hand-off between two interfaces For the simplest vertical hand-off case (MN shutting down an interface and transferring flows to a newly powered on interface), the same prefix is given to the new interface (single prefix model and PMIPv6 mobility management mechanism is used). There need not be any specific mechanism as in multiple prefix model to get the same prefix via the newly powered on interface. Basically, if MN's interface 1 shuts down and there are flows addressed to MN.If1, then when MN.If2 powers on, these flows can be readily received at MAG2 after MAG2 has established the IP bearer or the routing path at LMA/HA. The only problem in the vertical hand-off case is that the address of MN.If2 may be different from address of MN.If1 and MAG2 may discard these packets that are addressed to MN.If1. Here again, if simultaneous usage support is available in the system as described previously, the packet loss issue can be solved. Another issue that needs to be tackled is that, if MN performs perform address auto configuration, then until the address is configured and neighbor discovery procedure are completed, the packets that are received at MAG2 may be dropped if sufficient buffering resources are not available. Such issue and solutions for these are described in the following documents [11] [12]. These above mentioned documents are looking at transient or secondary caches to solve the buffering issue mentioned previously and also handling uplink packet loss via the previous interface during inter technology hand-off. An alternate way of solving this buffering issue at the new MAG/target MAG is to use context transfer during vertical hand- Jeyatharan, et al. Expires May 2, 2009 [Page 15] Internet-Draft Multiple Interfaces in NetLMM October 2008 off where the MN unique prefix is informed via the context transfer message to the target MAG. The target MAG has some validated information (sent by context transfer) about the validity of the ownership of this prefix by MN. Thus, target MAG when it receives context transfer signaling, will advertise router advertisement (RA) and simultaneously send the signaling to set up the IP bearer path at LMA/HA. When the target MAG advertises the prefix early, address configuration for the new interface can be triggered early. When such vertical hand-off is performed across administrative domains for example in 3GPP, context transfer may not be efficient considering the routing delay associated with the context transfer message. In such scenarios, the MN can get some information from source MAG and pass it on to target MAG. This information may have the prefix probably cryptographically signed by a trusted network entity. * Vertical Hand-off when MN is attached via more than two interfaces In this subsection, an advanced vertical hand-off scenario is considered where MN is performing vertical hand-off involving two of its interfaces, while the third interface is still attached. The main advantage of this scenario is that, during vertical hand-off process, until new interface can get completely attached, the third non-roaming interface can be used to receive packets. Again, it is important to understand that such an optimization is possible only when simultaneous usage support is available in the system. In the vertical hand-off process, to combat the address configuration related buffering issues and hand-off latency, MN can use the third stable interface to achieve hand-off optimization. When there is a vertical hand-off in a stable interface scenario, the make before break kind of hand-off may not be necessary and the stable interface can be used for hand-off optimization. Make before make kind of hand-off may not be possible in all mobility conditions and furthermore it consumes more battery power and preferably be avoided if possible. Jeyatharan, et al. Expires May 2, 2009 [Page 16] Internet-Draft Multiple Interfaces in NetLMM October 2008 3.3. Problem Analysis for Setting Filter Rule +--------------------+ | LMA/HA/Home P-GW | Flow1: MN.If1 CoA1 +--------------------+ Flow2: MN.If2 CoA2 | | +--------------------------+ | LMA/HA/Foreign P-GW | +--------------------------+ | BCE at Foreign LMA/HA +---------------------+ +-------------+-----------+-------+------------+ | | | Home Prefix | CoA | MN-ID | If-ID/BID | | Proxy MIPv6 Domain| +----------------------------------------------+ | | | MN.P1 | MAG1.Addr | NAI | If1-ID/BID1| +---------------------+ | MN.P1 | MAG2.Addr | NAI | If2-ID/BID2| | | +----------------------------------------------+ MAG2.Addr | | MAG1.Addr +---------+ +-----------+ | 3G/MAG2 | | ePDG/MAG1 | +---------+ +-----------+ \ / If2(CoA2) \ / If1(CoA1) =>prefix from foreign LMA/HA +------+ | MN | +------+ Figure 2: Single Prefix Flow Filter Issue In this section it is assumed that MN has MONAMI6 type of multihoming capability. The specific scenario that is considered here is such that the MN is connected to a foreign domain via both its interfaces. In such a scenario, unless foreign domain and home domain interwork such that the home prefix can be seen always via a particular interface and mobility for home prefix is maintained by PMIPv6 mobility management mechanism, CMIPv6 mechanism is essential when MN moves to a foreign domain. If MN wants multihoming related advanced features in foreign domain and CMIPv6 mobility management is used to sustain session continuity due to mobility in foreign domain, it is appropriate to use the MONAMI6 type of functionality. It is further considered that the MN uses a prefix rooted at foreign P-GW as shown in Figure 2 to configure the care-of address when roaming in the foreign domain to achieve local mobility management benefits. When the MuIf MN sets filter rules at home agent and is currently attached to a foreign domain, there is a specific problem that needs to be tackled. This problem is explained in detail below. In Figure 2, MN sets filter rules at home LMA/HA which is the home Jeyatharan, et al. Expires May 2, 2009 [Page 17] Internet-Draft Multiple Interfaces in NetLMM October 2008 Packet Data Network Gateway (P-GW) in the 3GPP model. MN prefers flow1 to traverse the WLAN interface and flow2 to traverse the cellular/3G interface. Thus, MN sets filter rules accordingly at its MIPv6 home agent which is LMA/HA at home domain. However, due to LMA/HA/foreign P-GW implementing prefix based routing, flow1 can be routed wrongly and may arrive via the cellular MAG. This is certainly an issue as the filter rules are broken and hence, adequate mechanisms needs to be in place to rectify this. When MN's flow preference is broken, MN may need to appropriately set the filter rules at the correct entity (foreign LMA/HA) or MN should always adopt the practice of setting the filter rules at foreign LMA/HA (not at home agent) when roaming in foreign domain. In a general sense, the MN does not need to know the foreign P-GW address. Thus, to set the filter rule, the MN could set filter rules at foreign LMA/HA via the MAGs in foreign domain. However, if the foreign LMA/HA uses an address based LMA/HA cache, then such an issue of breaking of filter rules does not arise. 4. Multiple Interface Problem Analysis for Multiple Prefix Model In this section, problem analysis for multiple interfaced MNs when PMIPv6 uses a multiple prefixes per MN model is presented. This model of prefix allocation is identical to that outlined in document [1]. Similar to section 3, the issues analyzed in this section are lack of simultaneous usage support, lack of flow filtering support, horizontal and vertical hand-off optimization related issues. Jeyatharan, et al. Expires May 2, 2009 [Page 18] Internet-Draft Multiple Interfaces in NetLMM October 2008 4.1. Problem Analysis for Simultaneous Attachment +-------------+-----------+--------+------+ | Home Prefix | CoA | MN-ID | If-ID| +---------------+ +-------------+-----------+--------+------+ |LMA/HA/(P-GW) | | MN.P1 | MAG1.Addr | NAI |If1-ID| +---------------+ | MN.P2 | MAG2.Addr | NAI |If2-ID| | +-------------+-----------+--------+------+ | BCEs at LMA/HA +--------------------------+ | | | Proxy MIPv6 Domain | | | +--------------------------+ | | MAG2.Addr | | MAG1.Addr +---------+ +-----------+ | 3G/MAG2 | | ePDG/MAG1 | +---------+ +-----------+ \ / If2(P2) \ / If1(P1) +------+ | MN | +------+ Figure 3: Attaching Multiple Interfaces to PMIPv6 that deploys Multiple Prefix Model In Figure 3, it is considered that MN can be an IPv6 host or CMIPv6 enabled host. When MN does simultaneous attachment, MN receives different prefixes via each of its interfaces and the binding cache created by MAGs at LMA/HA is shown in Figure 3. The multiple prefix model does not create any confusion to an unmodified IPv6 host that does simultaneous attachment. This is because, as discussed before, there is no instance where the host has to configure same address to both its interfaces. However, if MN is having flows with multiple CNs and a certain CN1 sends packets to address of MN configured from prefix P1 and another CN2 sends packets to address of MN configured from prefix P2, simultaneous usage support for CN1 IP flow and CN2 IP flow cannot be achieved from normal PMIPv6 operation. Thus, as highlighted previously in section 2, some further work is required in this area. To achieve simultaneous usage support (i.e. enabling an IP flow to traverse via all MN interfaces), the MAGs attached to MuIf MN need to know all MN prefixes. In general, if MN has no preference regarding which IP flow has to be traversed via which access technology or interface, and MN and/or network wants this simultaneous usage feature, this feature can be triggered in the system. When comparing the simultaneous usage solution for the Jeyatharan, et al. Expires May 2, 2009 [Page 19] Internet-Draft Multiple Interfaces in NetLMM October 2008 multiple prefix model with the single prefix model, it is clear that for the former case, MN needs to give prefixes associated with it to all MAGs that the MN is directly attached to, with some security token proving the validity of these prefixes and owner ship of these prefixes by MN. It is important to understand that the MN prefixes can be given to the MAGs by the MN or LMA/HA. In most scenarios, it is beneficial for the MN to provide this information. Even in the event of LMA/HA notifying MN prefixes to MAGs, MN modification is essential to accept packets via one interface that are destined to other MN interfaces. Next the flow filtering related issues are briefly analyzed. If MN in Figure 3 wants P1 flow to traverse via MAG2, then it needs to set filter rules at LMA/HA to send P1 flow via MAG2. In such a case, the MN can inform MAG2 about the P1 prefix. If MN does not want simultaneous usage support for P1 and P2 flows, then it can only update MAG2 about the P1 prefix in order to only support flow filtering mechanism. The important difference in the multiple prefixes model when compared to single prefix model is that, in the multiple prefixes model, simultaneous usage support is not essential for routing. Moreover, to set filter rules in the multiple prefixes model, a full fledged simultaneous usage support is not essential. For example, as described here, when MN wants P1 to traverse via MAG2 but does not want any changes in routing to P2 flow, then it only needs to inform MAG2 about P1 prefix. However, this is not the case in the single prefix model that uses prefix based caches. In this single prefix model, as analyzed in section 2, to solve the routing issue, simultaneous usage support has to be available in the system irrespective of MN's preference. 4.2. Problem Analysis for Horizontal Hand-off +-------------------------------------------+ | | | Proxy Mobile IPv6 Domain | | | +-------------------------------------------+ | | | | MAG1.Addr | MAG2.Addr | MAG3.Addr +---------+ +-----------+ +-----------+ | 3G/MAG1 | | WLAN/MAG2 | | WLAN/MAG3 | +---------+ +-----------+ +-----------+ \ / / If1(P1) \ / If2(P2) / If2(P2) +-------------+ / Horizontal | MN |-----/ hand-off for If2 +-------------+ Jeyatharan, et al. Expires May 2, 2009 [Page 20] Internet-Draft Multiple Interfaces in NetLMM October 2008 Figure 4: Horizontal Hand-off in Multiple Prefix Model In Figure 4, it is assumed that MN has two interfaces. MN can be an IPv6 host or MIPv6 host. Initially, it is assumed that MN is connected to PMIPv6 network via If1 and If2 at MAG1 and MAG2 respectively. It is further assumed that MN.If1 is connected to 3G network and MN.If2 is connected to trusted WLAN network. In trusted WLAN network, the AR will have the MAG functionality and more information on trusted WLAN can be found in [10]. It is further considered that MN while still connected to 3G network via MN.If1, performs a horizontal hand-off for MN.If2. Basically, MN.If2 will detach from MAG2 and attach at a new MAG3. In such a scenario, the important operation is that the If-ID information in the PBU sent from MAG3 has to have If2-ID. This interface ID is essential for LMA/HA to allocate the correct prefix during horizontal hand-off. As discussed previously in section 3, various mechanisms are available for MAG3 to obtain If-ID of MN.If2. In the scenario shown in Figure 4, there is no major difficulty of getting this interface ID. This is because, MAG3 is the directly connected access router of MN and the MN.If2 MAC address can be readily obtained. If MAG3 does not have interface ID of If2 (in a scenario where MAG3 is not the first hop router) and it does not know the hand-off state of MN, then it may set the hand-off flag to "4" in the hand-off indication option meaning that the hand-off type is unknown. In such a worst case scenario, the LMA/HA may assign a new prefix for If2 and session continuity for P2 flows will be disrupted. Thus, these kind of issues needs to be prevented if multiple prefix model is deployed. From brief analysis, the main concern here is that, if MAG3 does not know If2-ID, then getting this information quickly needs to be explored to prevent horizontal hand-off establishment delay. Another area to be explored is the horizontal hand-off optimization related to delay, packet loss and jitter. As described in section 3, horizontal hand-off delay can possibly be optimized using the stable 3G interface. However, in the multiple prefix model to achieve this is more difficult. This is because, the prefix of the interface undergoing hand-off needs to be informed via a trusted entity to the 3G MAG. Furthermore, the LMA/HA also needs to be informed to route packets for interface undergoing horizontal hand-off via another interface. These signalings such as MN notifying stable interface of other interface prefix and notifying LMA/HA of hand-off event, needs to be done in a timely manner to achieve hand-off delay optimization. However, it is important to appreciate, if simultaneous usage support is operating in the PMIPv6 domain, then the horizontal hand-off optimization support is implicitly available in the system and the MN need not inform the LMA/HA about hand-off event. This another benefit of simultaneous usage support can be seen. Jeyatharan, et al. Expires May 2, 2009 [Page 21] Internet-Draft Multiple Interfaces in NetLMM October 2008 4.3. Problem Analysis for Vertical Hand-off +-------------------------------------------+ | | | Proxy Mobile IPv6 Domain | | | +-------------------------------------------+ | | | | MAG1.Addr | MAG2.Addr | MAG3.Addr +---------+ +------------+ +-----------+ | 3G/MAG1 | | WiMAX/MAG2 | | WLAN/MAG3 | +---------+ +------------+ +-----------+ \ / / If1(P1) \ /If2(P2) / If3(P2) +-------------+ /Vertical hand-off | MN |------/ for If2 +-------------+ Figure 5: Vertical Hand-off in Multiple Prefix Model In Figure 5, it is assumed that MN has three interfaces, such as MN.If1, MN.If2 and MN.If3. It is further assumed that initially MN has MN.If1 and MN.If2 connected to the PMIPv6 network. Then, after some time, MN shuts down MN.If2 and attaches via MN.If3 -- i.e., MN performs a vertical hand-off for MN.If2. From 3GPP point of view, this is a very probable scenario where the MN is attached via 3G and WiMAX and when it detects WLAN may want to transfer the WiMAX flows to WLAN. If such a vertical hand-off is performed, then what is desired from MN's point of view is that MN requires flows associated with prefix P2 to be sent via MN.If3. To achieve this requirement of session continuity, the LMA/HA should assign prefix P2 to MN.If3. In order for LMA/HA to process such vertical hand-off request and assign the desired prefix P2 in the above scenario, the PBU sent by MAG3 need to have If2-ID information in addition to If3-ID and the "HI" option set to value "2". In [1], there is description about the prefix (P2) sent in the new PBU from interface 3. However, there was no description of the interface ID of the shutting down interface being sent in the new PBU. There can be scenario where there are multiple prefixes associated with an interface, such as in 3GPP scenario where the MN is connected to multiple packet data networks via a single LMA/HA. In such a scenario, rather than sending all the prefixes associated with interface 2 in the PBU via interface 3 during the vertical hand-off preocess, sending the If2-ID is beneficial from optimization point of view. It is important to understand, when there are more than 2 interfaces and vertical hand- off is being performed, to identify the interface that has shut down, this interface ID information is useful and such support mechanism is Jeyatharan, et al. Expires May 2, 2009 [Page 22] Internet-Draft Multiple Interfaces in NetLMM October 2008 essential. Next a simple scenario where vertical hand-off is performed is looked into. In this scenario, it is assumed that MN only has two active interfaces such as MN.If2 and MN.If3. When MN performs a vertical hand-off from MN.If2 to MN.If3, If2-ID may not be required in the PBU sent via interface 3. Once LMA/HA sees the hand-off flag pointing to "2" (vertical hand-off), it will assign P2 to MN.If3. This is because, LMA/HA has no difficulty in identifying P2 cache since there are no other BC entries associated with MN at LMA/HA. Thus, one can appreciate that the vertical hand-off complexity is high when MN has more than two active interfaces. As highlighted previously, when MN does vertical hand-off in a complex scenario as shown in Figure 5, MAG3 needs If2-ID information in the PBU. There needs to be an efficient mechanism for MAG3 to know this. As described previously, MN can provide the If2-ID to MAG3 via link layer specific triggers or via a L3 message. Alternatively, MAG3 can get this information via context transfer from MAG2. If vertical hand-off is performed between heterogeneous access network types, context transfer via heterogeneous networks may take some time and contribute to vertical hand-off establishment delay. In 3GPP, inter access technology hand-off can take place between home public land mobile network (HPLMN) and visited public land mobile network (VPLMN). In such a case, getting the If-ID associated with the shutdown interface using purely network based mechanisms is not efficient and moreover, may not be possible if there is no interworking between the domains. Thus, some MN involvement is definitely useful in scenarios involving inter technology hand-off within an administrative domain and between administrative domains. In the event there is vertical hand-off, to optimize vertical hand- off delay, packet loss etc, make before break kind of mechanism with transient binding caches can be used. In the event of a stable interface available during vertical hand-off, a simultaneous usage support mechanism in the system can support in improving the hand-off related QoS parameters. This was explained previously with respect to horizontal hand-off related analysis and shall not be repeated again. 5. PMIPv6/CMIPv6 Interaction Issues for Multiple Interfaced MN In this section, PMIPv6 and CMIPv6 interaction scenarios are analyzed for MuIf MN that has MONAMI6 type of functionality. For the MuIf MN, the main interaction issue in a PMIPv6 and CMIPv6 mixed scenario arises when network takes care of mobility signaling for some Jeyatharan, et al. Expires May 2, 2009 [Page 23] Internet-Draft Multiple Interfaces in NetLMM October 2008 interface attachments of MN and the MN takes care of mobility signaling for certain other interface attachments. The main factor that causes the issue is that 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. This problem will be explained in greater detail in this section and where appropriate possible solution paths will be highlighted. When MN's mobility for one interface is handled by PMIPv6 and MN's mobility for another interface is handled by CMIPv6, both the PMIPv6 and CMIPv6 bindings need to coexist at the home agent (LMA/HA) to achieve simultaneous attachment. Currently, there are solutions to achieve simultaneous attachment when MN uses PMIPv6 mobility management mechanism via all MN's interfaces as outlined in [1]. Furthermore, as outlined in [2], there are mechanisms available to achieve simultaneous attachment when MuIf MN handles mobility for all its interfaces. However, there are no mechanisms available in such mixed PMIPv6/CMIPv6 scenario to achieve simultaneous attachment when the MN configures just one home address from a single home prefix across its interfaces. In 3GPP SAE framework, 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 (HPLMN) via both its interfaces and uses CMIPv6 via one interface and uses PMIPv6 via another interface. Another scenario could be that, MN is simultaneously attached to home (HPLMN) and foreign domains (VPLMN) and MN uses PMIPv6 via the home connected interface and CMIPv6 via the foreign connected interface. The other scenarios involved are, when one of the interface is connected while the other interface roams or performs a hand-off between domains in such a mixed mobility management framework. Jeyatharan, et al. Expires May 2, 2009 [Page 24] Internet-Draft Multiple Interfaces in NetLMM October 2008 5.1. MuIf MN Simultaneous Attachment Issues in PMIPv6/CMIPv6 mixed Scenario +----------+ BCEs at LMA/HA | HA/ | +-------------+---------+-------+-------------+ | LMA/P-GW | | MN prefix | MN.CoA | MN-ID | If-ID/BID | +----------+ +-------------+---------+-------+-------------+ | \ | HoA | CoA.AR | - | BID1 | | \ | home prefix | MAG2addr| NAI | BID2 | | \ +-------------+---------+-------+-------------+ | \ | \ HPLMN +--------------+ +--------------+ | 3G/MAG1/S-GW | |WLAN/ePDG/MAG2| +--------------+ +--------------+ | | | If1 | If2 +-------------------+ | MN | +-------------------+ Figure 6: MuIf MN attaching to HPLMN using PMIPv6/CMIPv6 Mobility Management Mechanisms The analysis and problems highlighted in this section applies to both single prefix per MN PMIPv6 model and multiple prefixes per MN PMIPv6 model. This scenario as shown in Figure 6 is a 3GPP specific scenario, where MN chooses CMIPv6 mobility management to be used via the 3G interface (MN.If1) and PMIPv6 mobility management via the WLAN interface. Current 3GPP specifications does not fully support CMIPv6 to be used via 3G interface. Nevertheless, for the analysis such an assumption is used. However, such a scenario may be valid in future releases of 3GPP (i.e. beyond release 8). MN will use the on-link prefix that is available in the 3G access network advertised by evolved node B (eNodeB), or advertised by S-GW that is placed in the core network, to configure a care-of address for MN.If1. The said on-link prefix will be topologically rooted at the eNodeB or the S-GW. MN will perform the CMIPv6 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, 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 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 Jeyatharan, et al. Expires May 2, 2009 [Page 25] Internet-Draft Multiple Interfaces in NetLMM October 2008 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. The reason for home prefix to be seen via PMIPv6 mechanism may be a static configuration that has been hard-coded in LMA/HA or it could be subscription specific operation which has been requested by MN. When the home prefix is advertised via MAG2 there are definite advantages that the MN can enjoy. It can enjoy PMIPv6 mobility management benefits for home prefix flows. Moreover, in certain configurations in 3GPP, if CMIPv6 is not allowed via WLAN access, then home prefix needs to be advertised. This is especially essential in single interface vertical hand-off scenario (vertical hand-off between CMIPv6 mode and PMIPv6 mode via different interfaces) for session continuity. In order to attain simultaneous attachment in such a scenario, the PBU sent by MAG2 needs to have some If-ID or BID2 that is different from BID1. If MAG2 does not have any knowledge about MN's other interface CMIPv6 binding or MN's some other CMIPv6 mobility binding, it will send a normal PBU without BID value or an If-ID value that can be used for cache separation. When such a PBU is sent, it will overwrite the CMIPv6 binding that has already been registered at LMA/HA (i.e. entry 1 in BC). Such overwriting without proper binding specific parameter is already described in [2] for the multiple interface scenario. Another assumption used in the analysis is that, a PMIPv6 mobility binding can be replaced by another CMIPv6 binding if these bindings correspond to the same binding identifier or they can replace each other when no such binding identifier is provided (i.e. single binding or single interface MN). If the PMIPv6 binding and CMIPv6 binding are different mobility bindings arriving from different interfaces as in Figure 6, then they need to separated by BID. As mentioned before, either BID or interface identifier fields can be used to separate the mobility bindings at LMA/HA as shown in Figure 6. It is assumed that BID/If-ID are used to separate binding caches belonging to the same prefix/home address in such PMIPv6/ CMIPv6 mixed scenario. As discussed peviously, BID for cache separation is also used for PMIPv6 single prefix model and the MONAMI6 model. When unique prefix per interface PMIPv6 model is used in such mixed PMIPv6/CMIPv6 scenario, another field in the binding cache such as the BID field is required in addition to the interface identifier field currently used in the base PMIPv6 specifications. 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 Jeyatharan, et al. Expires May 2, 2009 [Page 26] Internet-Draft Multiple Interfaces in NetLMM October 2008 to generate the BID that is different from BID1. Another possible solution can be that MN gives BID2 to ePDG/MAG2, where BID2 is different from BID1, so that MAG2 can create the correct PMIPv6 binding for interface 2. In another alternate scenario, if only the MN's WLAN interface in Figure 6 moves out of the home domain to a VPLMN and decides to switch to CMIPv6 mode, it needs to know the BID generated by LMA/HA for interface 2 for the PMIPv6 binding, in the event this BID2 was not provided by MN. If MN uses a BID when performing CMIPv6 BU for interface 2 that is different from BID2 that was created previously, then there is a possibility for three bindings to exist at home P-GW. Such as the interface 1 CMIPv6 binding, interface 2 PMIPv6 old binding and the interface 2 correct CMIPv6 binding. Ideally, after roaming, the second binding entry shown in Figure 6 should have been overwritten by the new CMIPv6 binding for interface 2. If interface 2 current binding does not overwrite the old PMIPv6 binding associated with interface 2, packet loss can take place if the LMA/HA decides to route packets using the second entry in BC shown in Figure 6. However, if MAG2 can detect MN detachment fast enough, then possibly it may send a deregistration PBU and solve the above said issue. However, in the most general case, there needs to be a way where MN gets the BID2 value before performing the new CMIPv6 binding for interface 2. There are many possible solutions that can be used. For example, MN could inform LMA/HA to generate the correct BID by giving information about the PMIPv6 binding that needs to be over written. Or, MN could query MAG2 about BID2 information before performing the binding update. In another variant scenario, it is considered that MN.If1 in Figure 6 is attached to HPLMN and CMIPv6 mobility management is used and MN.If2 has roamed to VPLMN and uses CMIPv6 mobility management mechanism. In such a case, bindings at LMA/HA will be MONAMI6 type of CMIPv6 bindings with BID1 used for interface 1 and BID2 used for interface 2. If MN.If2 roams back home (HPLMN), and PMIPv6 mobility management is performed via If2, again the BID2 information has to be sent to MAG2 by MN. If MN does not send the BID2 information to MAG2, and the LMA/HA has to generate the BID2 information, the roaming interface needs to be identified correctly by LMA/HA. Such information about the roaming interface has to be given by MAG2. Possibly the MN can provide some parameter to identify the binding that is undergoing the roaming. Possibly the previous care-of address can be sent to MAG2 to aid the LMA/HA to create the BID2. The analysis in this PMIPv6/CMIPv6 mixed scenario has focused mainly on achieving simultaneous attachment. However, in this mixed scenario, there is no issue on simultaneous usage support because it is implicitly obtained when simultaneous attachment support succeeds. Jeyatharan, et al. Expires May 2, 2009 [Page 27] Internet-Draft Multiple Interfaces in NetLMM October 2008 Since there are no multiple PMIPv6 caches present in the scenario described, the simultaneous usage issue that were discussed for pure PMIPv6 multihoming does not arise here. 5.2. MuIf MN PMIPv6/CMIPv6 signaling optimization In this section, a signaling optimization that can be performed in multiple interface scenario when one of the interface performs the CMIPv6 BU and the other interface performs the PMIPv6 BU is described. To further understand the optimization that can be performed, once again Figure 6 is looked into. If for example, MN's interface 2 does the initial attachment to the HPLMN, there is no necessity for the MN to know the home P-GW address because the MAG2 handles the PMIPv6 registration. However, since MN's interface 1 is in the CMIPv6 state, then it needs to know the home P-GW address in order to perform the CMIPv6 BU. The CMIPv6 BU process can be broken into steps such as performing Dynamic Home Agent Address Discovery (DHAAD) to identify the HA address, and then performing the CMIPv6 BU. Such steps are carried out in MN implementations where the home prefix is statically configured in the MN. To eliminate the DHAAD signaling and optimize the CMIPv6 BU process, MN can possibly configure the care-of address for interface 1 and perform the CMIPv6 BU via the interface 2. If such mechanism takes place, the discovery for home agent address need not be performed because, MAG2 knows the address of home P-GW which is also the home agent of MN. The MN possibly can trigger MAG2 via a new message and request MAG2 to perform the CMIPv6 binding. For such optimization to take place, MN needs to give the CMIPv6 binding contents to MAG2, so that a PBU with a new mobility option that carries the CMIPv6 contents can be generated by MAG2. Such PMIPv6 and CMIPv6 interaction scenarios where signaling optimization can be performed needs to be identified. The signaling optimization described in this section is applicable for both PMIPv6 multihoming models (i.e. single prefix model and multiple prefixes model). 5.3. PMIPv6 and CMIPv6 Prefix Processing at Home Domain In this section a multihoming issue is analyzed from the perspective of multiple care-of addresses configured for a certain interface of MN when a MuIf MN is in home domain or HPLMN. Furthermore, the analysis is performed in a system that uses single prefix per MN PMIPv6 multihoming model at LMA/HA for PMIPv6 binding entries. However, the problem highlighted in this section is applicable even if LMA/HA deploys the multiple prefixes per MN model. Jeyatharan, et al. Expires May 2, 2009 [Page 28] Internet-Draft Multiple Interfaces in NetLMM October 2008 +-------------+-----------+--------+-------+-----+ | Prefix/Addr | CoA | MN-ID | If-ID | Flag| +---------+ +-------------+-----------+--------+-------+-----+ | HA/LMA/ | | MN.P1 | MAG1.Addr | MN.NAI |If1-ID | - | | P-GW | | MN.P1 | MAG2.Addr | MN.NAI |If2-ID | - | +---------+ | MN.HoA | -- | MN.NAI |BID1 | "H" | | | MN.HoA | CoA.AR | MN.NAI |BID2 | - | | +-------------+-----------+--------+-------+-----+ | BCEs at LMA/HA +----------------------------+ | | | Proxy Mobile IPv6 Domain | | | +----------------------------+ | | MAG1.Addr | | MAG2.Addr +--------------+ +-----------+ | 3G S-GW/MAG1 | | ePDG/MAG2 | +--------------+ +-----------+ | | | +-------------------------+ | | Untrusted WLAN Access | | +-------------------------+ | | | +-------+ | | AP/AR | | +-------+ \ | If1 \ / If2 +----------+ | MN | +----------+ Figure 7: Multihomed MN configuring multiple care-of addresses when PMIPv6 is deployed in 3GPP In a 3GPP deployment that uses PMIPv6 protocol, there are many prefixes a particular interface of MN can receive especially if MN is connected to Untrusted WLAN. MN may want to configure different addresses from different prefixes for various reasons. In such a scenario shown in Figure 7, it is assumed that MN has multihoming support and can generate BIDs as in [2] and LMA/HA can support multihoming as well. Generally, when an interface of MN configures different addresses, MN may prefer to have reachability to all such configured addresses from the LMA/HA to obtain multihoming benefits. It is also assumed that this PMIPv6 domain is MN's home PMIPv6 domain and MN's single home address (MONAMI6/MIPv6 sense) is equal to MN.If1 address. The mechanism by which MN gets the MIPv6 home address can Jeyatharan, et al. Expires May 2, 2009 [Page 29] Internet-Draft Multiple Interfaces in NetLMM October 2008 be 3GPP specific or using dynamic bootstrapping mechanism. In Figure 7, it is considered that MN.If1 is attached to 3G MAG1. When MN attaches to PMIPv6 network, it is assumed that it connects first via MN.If1. When such a connection is successful, the first entry in the BC will appear. The If1-ID can be directly obtained by MAG1 assuming that the S-GW is the first hop router for the data plane. If the data packet has to be routed via eNodeB that also acts as a router as described in [13], then MAG1 may not be the first hop router. It is further considered that MN.If2 is connected to PMIPv6/ 3GPP network via Untrusted WLAN access network. MN.If2 is directly attached to AR/AP. When MN.If2 makes a successful IPSec tunnel to ePDG as disclosed in [4], the second entry in the binding cache will be created. Again, the If2-ID needs to be different from If1-ID to maintain simultaneous binding. Before establishing a tunnel to ePDG, MN.If2 will get a nomadic address in the Untrusted WLAN access network and this nomadic address prefix is directly associated with AR's prefix. As discussed previously, the cache separation parameters for single prefix model can be BID or interface ID. In this analysis, it is assumed that If-ID is used for cache separation. MN may configure another address from the home prefix (home2) for MN.If2 to get reachability or to set filter rules at LMA/HA without knowing that this is a PMIPv6 domain. MN may want to register these addresses (nomadic address/on-link CoA, home2) at LMA/HA. When MN performs multiple CoA binding at LMA/HA for home2 and on-link CoA, then these CMIPv6 registrations created at LMA/HA are as shown in the binding cache by the third and fourth entries respectively. When MN does CMIPv6 registrations, the BIDs generated must be different from the PMIPv6 registrations. For example, if MN uses If2-ID value as BID1 or BID2, then one of the CMIPv6 binding may overwrite the second PMIPv6 binding. Thus, some MN involvement and some added multihoming feature is necessary at MN in this scenario to have the desired binding cache entries at LMA/HA. Moreover, one can clearly see that when multiple PMIPv6 and CMIPv6 registrations are taking place at the common anchoring point, there is a signaling storm in the system although MN has only two physical interfaces. Thus, further work is required to solve some issues that may arise in this scenario. Basically, these CMIPv6 registrations via If2 can be combined with the PMIPv6 registration to reduce the signaling storm in the core network. 6. Single Interface Processing Multiple Prefixes Multihoming for a MN in a very generic sense refers to either a MN with multiple interfaces making simultaneous attachment or a MN that can process multiple prefixes via its single interface and configures multiple addresses per interface. Although the main focus of this Jeyatharan, et al. Expires May 2, 2009 [Page 30] Internet-Draft Multiple Interfaces in NetLMM October 2008 memo is to look into issues with respect to simultaneous attachment that a MN performs in pure PMIPv6 and PMIPv6/CMIPv6 scenarios, in this section, some multihoming related issues for a single interface node is looked into. In this section, a 3GPP specific scenario is looked into, where a single interface MN may possibly see its home and foreign prefixes via the same interface. Currently in 3GPP specifications, the mobility management mechanism for a MN is either network based or node based for a certain interface. However, it is very probable that a MN will see home and foreign prefixes via the same interface if the MN wants both mobility management mechanisms such as PMIPv6 and CMIPv6 mechanism for the same interface. In this section, some issues when the MN wants such dual mobility management mechanism is looked into. Another scenario that is analyzed is when MN sees multiple prefixes via its single interface when there are multiple LMA/HAs in the PMIPv6 domain. 6.1. PMIPv6 and CMIPv6 Roaming Issues for Home Routed 3GPP Scenario In this section a scenario where both PMIPv6 and CMIPv6 mobility management operations are performed when MN is in VPLMN is considered. Such a scenario occurs when the MN is in VPLMN and gets the home prefix from home P-GW which is placed in the HPLMN and gets the foreign prefix obtained from P-GW placed in the VPLMN. Basically, due to such simultaneous usage of home and foreign P-GWs, MN sees both home and foreign prefixes being advertised. The assumption here is that MN considers the prefix given by home P-GW as the MIPv6 home prefix. In the scenario discussed in this section, it is assumed that the MN prefers to process foreign prefix to achieve better QoS with some CN. Jeyatharan, et al. Expires May 2, 2009 [Page 31] Internet-Draft Multiple Interfaces in NetLMM October 2008 +-----------+ BCEs at home P-GW | HA/LMA/ | +-------------+----------+-------+--------+ | home P-GW | | MN prefix | MN.CoA | MN-ID | If-ID | +-----------+ +-------------+----------+-------+--------+ | | Home Prefix | MAG.Addr | NAI | If1-ID | PMIPv6.BCE | | HoA | CoA@AGW | - | - | CMIPv6.BCE | HPLMN +-------------+----------+-------+--------+ ------|------- | VPLMN | | +--------------+ | Foreign P-GW | +--------------+ | s2a(PMIPv6) +---------------+ | MAG/WiMax/AGW | +---------------+ | If1 (Home prefix, Foreign prefix) +------+ | MN | +------+ Figure 8: Simultaneously at Home and at Foreign for Home Routed 3GPP The above scenario shown in Figure 8 is a 3GPP scenario where MN gets to see both home and foreign prefixes via the same interface. The scenario description was given previously. MN is currently in VPLMN and connected to MAG which is placed in the WiMAX access network and the MAG functionality is collocated at the WiMAX access gateway (AGW). It is further considered that the MAG and the P-GW at HPLMN is connected via logical interface s2a where the PMIPv6 protocol is used for mobility management. The routing path for data packets for home routed case (i.e. packets whose source address obtained from home P-GW) may be via the foreign P-GW. When MN sees home and foreign prefixes, it is considered that the MAG would have performed the PMIPv6 signaling at home P-GW for this home prefix. The binding entry created at the home P-GW is shown by the first entry in the BC. However, if MN wishes to use the foreign prefix to communicate with CN assuming that it gets some information from the network that the path attained using the foreign prefix to configure source address gives better QoS, then the MN will generally perform the CMIPv6 BU at LMA/HA or home P-GW such that it binds the care-of address obtained from foreign prefix to the home address configured from home prefix. It is assumed that the MN wishes to manage its mobility fully. If such a decision is made by MN, then the second entry in the BC in Figure 8 is created. The second entry will overwrite the first entry. It can be clearly seen that there is double signaling done Jeyatharan, et al. Expires May 2, 2009 [Page 32] Internet-Draft Multiple Interfaces in NetLMM October 2008 (i.e. one by MAG and another by MN) for the same binding. This problem needs to be solved. A possible solution is that MN could request the MAG not to perform the PMIPv6 registration at home P-GW and also inform the MAG that it will handle the binding update to home P-GW and CN in a pure CMIPv6 mode. The description is this section highlights an issue where the MN has a specific preferred mobility management mode where as the network provides all types of mobility management mechanisms available to the MN and contributes to redundant signaling. The problem described in this section is present irrespective of whether single prefix per MN or multiple prefixes per MN model is deployed in the system and it is applicable to both the models. 6.2. Multihoming Issues in Multiple LMA/HA Scenario If there are multiple LMA/HAs in the same PMIPv6 network, then there is a possibility that a MN sees multiple prefixes being received at the same interface. In this section this scenario is briefly analyzed to see whether multihoming issue is present. Again, it is assumed that MN and HA have MONAMI6 functionality. Jeyatharan, et al. Expires May 2, 2009 [Page 33] Internet-Draft Multiple Interfaces in NetLMM October 2008 +-----+------------+------+ +----+ | HoA | CoA | BID | | HA | +-----+------------+------+ +----+ | HoA |LMA1pref.CoA| BID1 | | | HoA |LMA2pref.coA| BID2 | +----------+--------+-----+ +------------+ +-----+------------+------+ | prefix | MN.CoA |MN-ID| | Internet | BCEs at HA +----------+--------+-----+ +------------+ | LMA1pref | MAGAddr| NAI | / \ +----------+--------+-----+ / \ BCEs at LMA1 +------+ +------+ | LMA1 | | LMA2 | +------+ +------+ | | +----------+--------+-----+ +-----------------+ | prefix | MN.CoA |MN-ID| | foreign | +----------+--------+-----+ | PMIPv6 | | LMA2pref | MAGAddr| NAI | | domain | +----------+--------+-----+ +-----------------+ BCEs at LMA2 | +-----+ | MAG | +-----+ LMA1pref | LMA2pref +-----+ | MN | +-----+ Figure 9: PMIPv6 domain with multiple LMA/HAs Figure 9 shows a scenario where MN is attached to a foreign PMIPv6 domain with multiple LMA/HAs. Here, MN may receive two per-MN unique prefixes (LMA1pref and LMA2pref) and configure two care-of addresses using these prefixes. As MN is MONAMI6 capable, it will assign different BID for each of the care-of addresses when binding them to its home address at its home agent (HA). The binding caches of the LMA/HAs and the HA are shown in Figure 9. In this case, there is no forseeable issue and MN can enjoy multioming benefits. Basically, MN's flows associated with home address will reach MN via both the foreign LMA/HAs. 7. Conclusion In this memo, various issues that needs to be addressed when multihoming is supported in the PMIPv6 domain was analyzed. Issues were analyzed for single and multiple prefix models separately. MuIf PMIPv6/CMIPv6 related issues that are common to both the models were Jeyatharan, et al. Expires May 2, 2009 [Page 34] Internet-Draft Multiple Interfaces in NetLMM October 2008 analyzed separately. From the analysis as highlighted in this memo, irrespective of the model used, some further work is required to solve issues in: simultaneous usage, flow filtering, horizontal and vertical hand-offs and PMIPv6/CMIPv6 related simultaneous attachment. Finally, from the analysis done in this memo it can be concluded that multihoming can be provided by either PMIPv6 multihoming models. However, how these models are going to be used to achieve advanced multihoming benefits needs further work. Whether network based solutions or some terminal involvement deemed necessary has to be analyzed for each of the problem scenario that was highlighted in the memo. Considering that the PMIPv6 protocol is designed with the objective of reducing the signaling from MN, solution space analysis for these problems should consider solutions where MN involvement is minimal. 8. IANA Considerations This is an informational document and does not require any IANA action. 9. Security Considerations This document explores the problem of supporting mobile nodes with multiple interfaces connecting to a PMIPv6 domain. No additional security threat is identified as of the writing of this memo that is specific to multiple interfaces support. 10. References 10.1. Normative Reference [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18 (work in progress), May 2008. 10.2. Informative Reference [2] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-09 (work in progress), August 2008. [3] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-giaretta-netlmm-mip-interactions-02 (work in progress), November 2007. Jeyatharan, et al. Expires May 2, 2009 [Page 35] Internet-Draft Multiple Interfaces in NetLMM October 2008 [4] "Technical Specification Group Services and System aspects", 3GPP TR 23.402, December 2007. [5] 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. [6] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-soliman-monami6-flow-binding-05 (work in progress), November 2007. [7] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work in progress), February 2008. [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [9] Devarapalli, V., Kant, N., Lim, H., and C. Vogt, "Multiple Interface Support with Proxy Mobile IPv6", draft-devarapalli-netlmm-multihoming-03 (work in progress), August 2008. [10] "3GPP system architecture evolution (SAE)", 3GPP TR 23.882, January 2008. [11] Muhanna, A., Krishnan, S., Leung, K., and B. Patil, "Proxy MIPv6 Support of Transient Registration", draft-muhanna-netlmm-pmipv6-support-transient-coa-01 (work in progress), February 2008. [12] Blume, O. and R. Sigle, "Secondary Binding Cache entries for Proxy MIPv6", draft-blume-netlmm-secondary-bce-proxymip6ho-00 (work in progress), February 2008. [13] "Technical Specification Group Services and System aspects", 3GPP TS 23.401, March 2008. Appendix A. Change Log Jeyatharan, et al. Expires May 2, 2009 [Page 36] Internet-Draft Multiple Interfaces in NetLMM October 2008 o draft-jeyatharan-netlmm-multi-interface-ps-03: * Revised draft and focused more on pure PMIPv6 multihoming and PMIPv6/CMIPv6 multihoming. * Have split the PMIPv6/CMIPv6 interaction into two sections. MuIf PMIPv6/CMIP Interaction and Single Interface PMIPv6/CMIPv6 interaction. * Have removed previous appendix sections. Most of the contents in the Appendix has been merged with sections 5 and 6. o draft-jeyatharan-netlmm-multi-interface-ps-02: * Expanded the section 2 with more description on the multihoming models. * Expanded the draft with problem analysis focusing on current and future 3GPP multiple interface scenarios * Re-organized and expanded horizontal and vertical handoff analysis in sections 3 and 4. * Included a new section on PMIP/CMIP interaction issues for MuIF nodes * Removed section 5 from version 1 and included into PMIP/CMIP interaction section. o draft-jeyatharan-netlmm-multi-interface-ps-01: * Expanded the draft into problem analysis for two PMIPv6 multihoming models. * Expanded the draft with problem analysis focusing on 3GPP scenarios. * Modified the draft by cutting down on some appendix scenarios. * Modified the draft by generalizing the problem analysis for all types of nodes. * Included some similar multihoming problem scenario as highlighted by Vijay Devarapalli in his PMIPv6 multihoming draft. Jeyatharan, et al. Expires May 2, 2009 [Page 37] Internet-Draft Multiple Interfaces in NetLMM October 2008 o draft-jeyatharan-netlmm-multi-interface-ps-00: * Initial version. 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 Vijay Devarapalli WiChorus Inc. 3590 North First Street San Jose CA 95134 USA Email: vijay@wichorus.com Jun Hirano Panasonic Corporation 5-3 Hikarino-oka Yokosuka, Kanagawa 239-0847 JP Phone: +81 46 840 5123 Email: hirano.jun@jp.panasonic.com Jeyatharan, et al. Expires May 2, 2009 [Page 38] Internet-Draft Multiple Interfaces in NetLMM October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Jeyatharan, et al. Expires May 2, 2009 [Page 39]