NetLMM Working Group M. Jeyatharan Internet-Draft C. Ng Expires: December 19, 2008 J. Hirano Panasonic June 17, 2008 Multiple Interfaced Mobile Nodes in NetLMM draft-jeyatharan-netlmm-multi-interface-ps-02 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 December 19, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). 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 (multiple unique prefixes per MN) that is attached to the PMIPv6 domain. However, multihoming can also be provided using same unique prefix for all interfaces of MN (single unique prefix per MN). This memo explores and highlights some issues associated with multihoming support in PMIPv6: using single unique Jeyatharan, et al. Expires December 19, 2008 [Page 1] Internet-Draft Multiple Interfaces in NetLMM June 2008 prefix per MN method or unique prefix per each interface of MN method. 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 . . . . . . . 6 3. Multiple Interface Problem Analysis for Single Prefix Model . 8 3.1. Problem Analysis for Simultaneous Attachment . . . . . . . 9 3.2. Problem Analysis for Handoff Scenarios . . . . . . . . . . 12 3.3. Problem Analysis for Setting Filter Rule . . . . . . . . . 15 4. Multiple Interface Problem Analysis for Multiple Prefix Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Problem Analysis for Simultaneous Attachment . . . . . . . 16 4.2. Problem Analysis for Horizontal Handoff . . . . . . . . . 17 4.3. Problem Analysis for Vertical Handoff . . . . . . . . . . 18 5. PMIPv6/CMIPv6 Interaction issues for Multihomed MN . . . . . . 19 5.1. Single Interface Processing Multiple Prefixes . . . . . . 20 5.1.1. PMIPv6 and CMIPv6 prefix processing at home domain . . 20 5.1.2. PMIPv6 and CMIPv6 roaming issues for home routed 3GPP Scenario . . . . . . . . . . . . . . . . . . . . 22 5.2. MuIf MN PMIPv6/CMIPv6 roaming issues . . . . . . . . . . . 24 5.3. MuIf MN PMIP/CMIP signaling optimization . . . . . . . . . 26 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 28 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 28 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 Appendix B. Multihoming Issues in PMIPv6 Single LMA Roaming Scenario . . . . . . . . . . . . . . . . . . . . . . 30 Appendix C. Multihoming Issues in Multiple LMA Scenario . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 34 Jeyatharan, et al. Expires December 19, 2008 [Page 2] Internet-Draft Multiple Interfaces in NetLMM June 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 where a unique prefix is given to each interface of MN. The base draft adopted such a multiple unique prefixes per MN model or unique prefix per MN interface model to provide basic multihoming support and connectivity to an unmodified MN. "Unmodified" MN is generally understood as mobile nodes that do not have any software changes to attain network based mobility management. However, multihoming can also be provided using single unique prefix for all interfaces of MN and one need not restrict to unique prefix per interface type of allocation. The multihoming support that is covered in the base PMIPv6 draft is simply simultaneous 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 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, vertical hand-off support when MN has two or more multiple interfaces connected to the network, 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 specific solutions which require some enhancement/modification to the current PMIPv6 protocol. In this memo we also analyze a case where MN sees multiple prefixes via a single interface and configures different addresses and requires both PMIPv6 and CMIPv6 states at the anchoring point. We also analyze a case where MN sees both home and foreign prefixes via its single interface and chooses a preferred prefix, and, as a result, requires some changes to the PMIPv6 protocol operation. The main objective of this memo is to analyze and highlight the problems in these above mentioned advanced multihoming scenarios and to highlight the necessity of further work that is required for the basic PMIPv6 protocol to support the above described multihoming scenarios. We perform scenario analysis for two different type of PMIPv6 multihoming models which are the single unique prefix per MN model and multiple unique prefixes per MN model so that one can understand the problems and also one can see which model is preferred for a certain multihoming scenario. In addition to the above mentioned analysis, how to support multihoming for an unmodified MN when PMIPv6 deploys a single unique prefix per MN model. Finally, in Jeyatharan, et al. Expires December 19, 2008 [Page 3] Internet-Draft Multiple Interfaces in NetLMM June 2008 Appendix B and Appendix C, the multihoming problem analysis is focused on an advanced scenario such as roaming and multiple local mobility anchors (LMAs). It is considered that the LMA can also operate as a MIPv6 home agent. Thus LMA/HA or LMA will denote a collocated PMIPv6 and CMIPv6 anchoring point. 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, we are highlighting PMIPv6 multihoming problems pertaining towards the 3GPP service architecture evolution (SAE) network structure. Nevertheless, we would not exclude such problem analysis for other SDO architectures that will adopt the PMIPv6 protocol for multihoming purposes. Some of the scenarios where PMIPv6 is considered to be used is clearly defined in [2]. In document [2], 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, we have considered many futuristic multihoming scenarios that may well be adapted by 3GPP and other SDOs. Basic concepts and usefulness of multihoming is already well defined in [3] 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 [2] and possibly future 3GPP activities. 2. Multiple Interfaces Support Models in PMIPv6 When a node with multiple interfaces is roaming in a PMIPv6 domain, there are various benefits it can enjoy if the PMIPv6 domain allows more than one interfaces to be used simultaneously. As mentioned previously, these benefits can be found in other documents [3]. It should be noted that some benefits could be enjoyed by the PMIPv6 domain or the operator as well. For instance, when the LMA receives a packet destined for a multiple interfaced MN, the LMA may be able to choose amongst the multiple routes to better utilize the network resources of the PMIPv6 domain or to avoid congested region of the PMIPv6 domain. In this section, a brief analysis and principle of the two PMIPv6 multihoming models (same unique prefix across all interfaces and per interface unique prefix) are given. Furthermore for each of the models, the lack of support for simultaneous usage of all interfaces for a certain flow and the lack of support for setting filter rules are outlined. These are issues related to classic multihoming. Jeyatharan, et al. Expires December 19, 2008 [Page 4] Internet-Draft Multiple Interfaces in NetLMM June 2008 However, there are more issues that are related to vertical hand-offs when MN has multiple interfaces which will be detailed in other sections. 2.1. Different Home Network Prefix for Each Interface o Operation complexity at LMA/HA to support unique prefix per interface allocation In this case, each interface of MN is allocated a unique Home Network Prefix. To ensure that each interface of MN gets a unique prefix, the LMA will use a 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 multiple prefix model is described in greater detail in [1]. If the interface ID (If-ID) in PBU is not available at the LMA binding cache, and if the hand-off flag is set to "1" (implying new connection request), the LMA 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, then the LMA 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 will use more information such as vertical hand-off flag inserted in the PBU, as well as 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 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. 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 will not be able to perform path switching for packets addressed to a particular interface. For example, MN's IF1 is assigned a prefix (P1) and MN's IF2 is assigned another prefix (P2). When LMA receives a packet addressed to an address configured using P1, LMA would not route such packet via MN's IF2 path. In some use cases, it is preferred that a flow traverses via all interfaces of MN for example to achieve load sharing and load balancing benefits and where possible using a less costly wireless access for the flows whenever simultaneous access via different interfaces can be Jeyatharan, et al. Expires December 19, 2008 [Page 5] Internet-Draft Multiple Interfaces in NetLMM June 2008 achieved (ex. hierarchical cell structures). If MN is an IPv6 host using SHIM6 (Site Multihoming by IPv6 Intermediation) [4] or SCTP (Stream Control Transport Protocol) [5] or MN is a MONAMI6 capable node [6], then the MN can continue to enjoy simultaneous usage benefits such as a 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. o Lack of Flow Filtering Support Setting filter rules 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 [7]. 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 needs to pass its flow filtering rules to the MAG to which it is attached. As described, such flow filtering support mechanisms are essential even when PMIPv6 is used and currently not supported in PMIPv6. If PMIPv6 does not support a mechanism to set filter rules, then the only way MN can attain the preference setting 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. o Prefix Resource Usage Another general issue with this multiple prefixes model is that prefix resources are wasted and in some cases, a node may not get a prefix 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 case, each interface will receive the same 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 Jeyatharan, et al. Expires December 19, 2008 [Page 6] Internet-Draft Multiple Interfaces in NetLMM June 2008 of the actual address configured (or assigned) for that interface. When PMIPv6 implements this 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 prefix model can be implemented using three different mechanisms. We next briefly describe these methods and discuss the merits and drawbacks of each of these methods and furthermore compare against the multiple prefixes model. o Prefix Based Caches 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 [6]. The main problem with this method is that, routing is based on prefixes and there is a tendency for packets sent to a particular address being routed to a wrong interface if the MN configures different addresses for its interfaces. When compared to the multiple prefixes model, simultaneous usage can be easily achieved 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. Furthermore, when setting filter rules, the flow parameters can be tied with the interface identifier or BID that is available in the cache. o Different Address Based Caches Here the 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 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 does not occur since the routing at the LMA/HA is address based. However, to attain simultaneous usage benefits proper mechanisms needs to be in place 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. Jeyatharan, et al. Expires December 19, 2008 [Page 7] Internet-Draft Multiple Interfaces in NetLMM June 2008 Furthermore, the MAGs need appropriate mechanisms to allow packets that are addressed to 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. Basically, MN will set filter rules by tying the flow parameters to the address of the interface. o Same Address Based Caches In this method, all MN interfaces configures the same address. Thus the problems described as to packets being routed wrongly or the simultaneous usage issue 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 multihomed nodes such as multiple interfaced nodes when PMIPv6 uses a single unique prefix per MN model is presented. The assumption in the analysis regarding to which PMIPv6 functional entity is mapped to which entity in 3GPP architecture is based on details provided in documents such as [8] and [2]. Jeyatharan, et al. Expires December 19, 2008 [Page 8] Internet-Draft Multiple Interfaces in NetLMM June 2008 3.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.P1 | MAG2.Addr | NAI |If2-ID | | +-------------+-----------+--------+-------+ | BCEs at LMA/HA +--------------------------+ | | | Proxy Mobile IP Domain | | | +--------------------------+ | | MAG2.Addr | | MAG1.Addr +--------------+ +-----------+ | 3G(SGW)/MAG2 | | ePDG/MAG1 | +--------------+ +-----------+ \ / If2 \ / If1 +------+ | MN | +------+ Figure 1: Attaching multiple interfaces to PMIPv6 that deploys single prefix model o Maintaining simultaneous bindings at LMA/HA in 3GPP architecture We first explore some fundamental issues if PMIPv6 uses single prefix per MN type of multihoming support. Figure 1 shows a multiple interfaced MN, which is simultaneously attached to a PMIPv6 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. It is further assumed that PMIPv6 protocol is deployed in 3GPP evolved packet core (EPC) network where MN.If1 is attached to the evolved packet data gateway (ePDG) via a IPSec tunnel and MN.If2 is attached to Serving Gateway (S-GW)/MAG2 which is its first hop router. It is considered that the ePDG/MAG1 is not the first hop router for MN.If1. More information on 3GPP architectural entities and their roles can be obtained from 3GPP technical specifications [8] and [2]. 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 Jeyatharan, et al. Expires December 19, 2008 [Page 9] Internet-Draft Multiple Interfaces in NetLMM June 2008 access technolgy hand-off is also a possible optimization scenario for vertical hand-off. If such single prefix type of multihoming is supported, then there needs to be some parameter (If-ID, BID etc) in the LMA/HA cache to differentiate the bindings from same MN. It is important to appreciate that in the single prefix model, as shown in Figure 1, 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. In such single prefix model, the Network Access Identifier (NAI) will be used for prefix assignment because only a single prefix needs to be assigned to a multiple interface 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 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 new 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 information in an option. Basically these interface IDs can be media access control (MAC) addresses or these can be interface identifiers that MN use to form global unicast address. If the latter type of interface identifiers are used, then it is extremely important that they are unique across MN interfaces. Thus, as advised in [1], the use of MAC addresses are preferred for interface IDs, due to their uniqueness per interface. These interface IDs (assuming MAC address) can be readily obtained by MAGs if they are first hop routers. Since MAG1 is an ePDG as shown in Figure 1, then, using simple MAC addresses may not work as the MAC address cannot be obtained from IPSec tunnel establishment signal. In such a problematic case of an ePDG being a MAG, proper mechanisms should be in place to get the correct If-ID. There can be a case where ePDG in Figure 1 does not know If-ID and generates a random If-ID. If this If-ID is same as MN's some other interface If-ID (ex. MN.If2 identifier), then this may overwrite an existing If-ID that is available at LMA/HA cache. Such overwriting at LMA/HA will cause a loss of a valid routing state. In such a scenario where MAG is an ePDG, one possible way is for MN to generate an If-ID and explicitly inform the ePDG during IPSec tunnel establishment. Alternatively, MN can simply inform ePDG its MAC address during tunnel establishment. Another way is for Authentication Authorization Accounting server (AAA) to generate If-IDs for initial attachments and assume that If-IDs can be transferred via context transfer for hand-off attachments. Yet Jeyatharan, et al. Expires December 19, 2008 [Page 10] Internet-Draft Multiple Interfaces in NetLMM June 2008 another way is for the MAG/ePDG to query nearby routers for MN's If-IDs and then generate a unique interface ID. With so many approaches, some further analysis needs to be performed to select the best possible method. We feel some MN involvement may be required to attain this objective because only the MN will know its unique interfaces and its identifiers in all scenarios (initial attacment, hand-off and bootup). o Simultaneous access support for unmodified MN Suppose we consider 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 configuration method, then MN.If2 may not be able to configure a global address (perhaps a Duplicate Address Detection (DAD failure)) and that interface will not be used. 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, ideal multihoming is not obtained. On the other hand, if MN configures different addresses on its interfaces using stateless address configuration (assuming different interface identifier for each interface), 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 neighbour cache entry mapping address of MN.If1 to the layer two (L2) address of MN.If2. Thus, it can be clearly seen that, although multihoming support is available at LMA/HA, when LMA/HA routes packets based on prefix, packets to one address to which a MAG does not have supporting neighbour cache entry will be lost. To solve the above mentioned problem for an unmodified host when it configures same address for both its interfaces may be difficult. We feel that some changes can be done at the network side to prevent activation of stateful mode of address configuration for unmodified host and thus avoid same address being configured 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. Or, as discussed in the NetLMM mailing list, the unmodified host can be configured with a single virtual interface at layer three (L3) to mitigate this issue. Jeyatharan, et al. Expires December 19, 2008 [Page 11] Internet-Draft Multiple Interfaces in NetLMM June 2008 3.2. Problem Analysis for Handoff Scenarios o Horizontal Handoff for Multiple Interfaced MN Handoffs are generally classified as horizontal handoff and vertical handoff. Horizontal handoff from L3 perspective means handoff 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. In this sub-section, for a multiple interfaced MN involved in horizontal handoff, we focus on MuIf MN creating the correct routing state at LMA/HA during horizontal handoff and horizontal handoff optimization by means of using multiple interfaces. In a multiple interface scenario using the single prefix model, when one of the interface performs horizontal handoff while the other interface is still attached, the problem is not very complex. The reason being the new MAG only needs to know the If-ID of the interface that is performing the horizontal handoff to create the correct routing entry at LMA/HA. Again, the new MAG can get to know this If-ID by various means. New MAG can get to know If-ID via context transfer from old MAG, from AAA, from the MN, or obtaining directly from MAC address. For horizontal hand- off case, we do not foresee any issue as long as there are appropriate mechanisms in the system for the new MAG to know the If-ID. Another area of interest is horizontal handoff delay optimization and thus preventing packet loss during handoff. In the multiple interface case, the horizontal handoff of a certain interface can be optimized using another stable interface (i.e. interface that is not perfoming handoff). For example, during the time when there is no routing state at the LMA/HA associated with an interface, such as the time between MN dereg PBU has arrived from old MAG and the new PBU has not arrived from the new MAG, the packets can easily be routed via another stable interface. Such an optimisation can be easily achieved using the single prefix per MN model. This is because all the routing states associated with MN is based on a single prefix. Thus LMA can easily utilize a stable interface to route packets during horizontal handoff. Probably the only change that has to be done in the system is that the MN needs to notify the address of the interface that is undergoing handoff to the MAG that is attached to its stable interface. Horizontal handoff event that will result in access router change should be detected using L2 specific mechanisms and notified to the L3 of the protocol stack of MN. Once such triggers received at L3, MN should perform such triggering to the stable MAG. Such a scenario is a very probable scenario in 3GPP Jeyatharan, et al. Expires December 19, 2008 [Page 12] Internet-Draft Multiple Interfaces in NetLMM June 2008 where a MN can be roaming in such a manner where one interface is connected to 3G interface and the other interface is connected to WLAN. Since WLAN cells are smaller, MN will go through many horizontal handoffs for the WLAN interface while still being attached to the same cellular cell. Thus, by using the stable interface, packet loss can be reduced and this scenario very clearly shows that horizontal handoff optimization can be obtained using the single prefix model and multiple interface usage. In some cases, the MN may want all its data flows to come via WLAN interface due to cost consideration, but may want to keep the cellular interface active just to achieve horizontal handoff optimization just described. Alternatively, when MN moves through WLAN cells, then MN way want to power on 3G interface for horizontal handoff optimization. o Vertical Handoff for Multiple Interfaced MN * Vertical Handoff between two interfaces First we will analyse vertical handoff between two interfaces. For the vertical handoff 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 MM 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 handoff 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. In such a case, appropriate mechanism should be in place. For example, the MN may need to inform MAG2 about address of MN.If1, so that MAG2 can transfer packets to MN.If2 without dropping the packets. Again, to solve the above mentioned issue, some terminal involvement may be required. Perhaps a link layer (L2) trigger from MN may be sufficient if MAG2 is directly attached to MN. This said L2 trigger could be such that MN informs the address of MN.If1 to MAG2. Alternatively, MN.If2 can configure the same address as MN.If1 to solve this issue. Another issue that needs to be tackled is that, if MN is going to perform address autoconfiguration, then until the address is configured and neighbour discovery procedure are completed, the packets that are received at MAG2 may be dropped if sufficient buffering resources are not available. Such issues are being looked into in the following Jeyatharan, et al. Expires December 19, 2008 [Page 13] Internet-Draft Multiple Interfaces in NetLMM June 2008 documents [9] [10]. These said 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 handoff. One way of solving this buffering issue at the new MAG can be using context transfer during vertical handoff where the 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 signalling, will advertise router advertisement (RA) and simultaneously send the signaling to set up the IP bearer path at LMA/HA. * Vertical Handoff when MN is attached via more than two interfaces Here we consider a scenario where vertical handoff is associated with two interfaces, while there is still a connection available via a third stable interface. The main advantage of this scenario is that, during vertical handoff process until new interface address configuration is complete, the third non-romaing interface can be used to receive packets. Since in vertical hand-off, the address configuration delay is present, the MN can use the third stable interface for this purpose. Basically, the MN can inform LMA about the address configuring state and use the third interface rather than performing the make before break kind of handoff for the interface that is performing the vertical handoff. This scenario highlights some further work that may be done for MuIf terminals involved in vertical handoff. Jeyatharan, et al. Expires December 19, 2008 [Page 14] Internet-Draft Multiple Interfaces in NetLMM June 2008 3.3. Problem Analysis for Setting Filter Rule +--------------------+ | HA/LMA/Home P-GW | Flow1: MN.If1 CoA1 +--------------------+ Flow2: MN.If2 CoA2 | | +--------------------------+ | Foreign LMA/Foreign P-GW | +--------------------------+ | BCE at Foreign LMA +-----------------------+ +-------------+-----------+-------+--------+ | | | Home Prefix | CoA | MN-ID | If-ID | | Proxy MIPv6 Domain | +------------------------------------------+ | | | MN.P1 | MAG1.Addr | NAI | If1-ID | +-----------------------+ | MN.P1 | MAG2.Addr | NAI | If2-ID | | | +------------------------------------------+ MAG2.Addr | | MAG1.Addr +---------+ +-----------+ | 3G/MAG2 | | ePDG/MAG1 | +---------+ +-----------+ \ / If2 \ / If1 +------+ | MN | +------+ Figure 2: Single Prefix Flow Filter Issue In this section we assume that MN has multihoming capability. In the single prefix multiple interface scenario, there is a specific problem that needs to be tackled when MN sets filter rules at home agent and is currently attached to a foreign domain. This is explained in detail below. In Figure 2, MN sets filter rules at HA which is the 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 HA. However, due to foreign LMA/foreign P-GW implementing prefix based routing, flow1 can be routed wrongly and may arrive via the cellular MAG. This is certainly an issue and 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). It is further assumed that in Figure 2, MN gets the foreign prefix (local breakout prefix in 3GPP jargon) in the foreign domain. Foreign prefix can be used for route optimization without trading off the advantage of network based mobility management PMIPv6 Jeyatharan, et al. Expires December 19, 2008 [Page 15] Internet-Draft Multiple Interfaces in NetLMM June 2008 offers. If in another scenario, MN is directly connected to home PMIPv6 domain, then MN may need to set filter rules at HA. 4. Multiple Interface Problem Analysis for Multiple Prefix Model In this section, problem analysis for multihomed nodes when PMIPv6 uses a multiple prefixes per MN model is presented. 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. It is also considered that MN is attached to PMIPv6 domain and wants PMIPv6 MM mechanism via both its access technology type using 3GPP specific mobility selection mechanism. MN receives different prefixes via each of its interfaces. Basically, when MN.If1 attaches to PMIPv6 network, the first BC entry will be created. When MN.If2 attaches to PMIPv6 network, the second BC entry will be created. The prefixes are sufficient to separate the caches. However, these If-IDs are required for prefix assignment purposes. The multiple prefix model does not create any confusion to an unmodified IPv6 host that does simultaneous attachment because there Jeyatharan, et al. Expires December 19, 2008 [Page 16] Internet-Draft Multiple Interfaces in NetLMM June 2008 is no possibility that a multi-link subnet will be experienced by the MN. However, if MN is having flows with multiple CNs and a certain CN sends packets to address of MN configured from prefix P1 and another CN sends packets to address of MN configured from prefix P2, then multihoming benefits such as these said flows coming via all MN interfaces cannot be achieved. Thus, some further work is required in this area. For example, LMA/HA can identify using the NAI that both entries belong to the same MN. But the MAGs are not aware of MN other interface prefixes. Thus, if LMA/HA decides to send packets configured from P1 to MAG2, MAG2 will drop it. If a MAG has knowledge of MN's other interface(interfaces not attached to MAG) prefixes, then definitely, MN can enjoy some advanced multihoming benefits. 4.2. Problem Analysis for Horizontal Handoff +-------------------------------------------+ | | | Proxy Mobile IPv6 Domain | | | +-------------------------------------------+ | | | | MAG1.Addr | MAG2.Addr | MAG3.Addr +---------+ +-----------+ +-----------+ | 3G/MAG1 | | WLAN/MAG2 | | WLAN/MAG3 | +---------+ +-----------+ +-----------+ \ / / If1(P1) \ / If2(P2) / If2(P2) +-------------+ / Horizontal | MN |-----/ handoff for If2 +-------------+ Figure 4: Horizontal Handoff 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 [8]. It is further considered that MN while still connected to 3G network via MN.If1, performs a horizontal handoff for MN.If2. Basically, MN.If2 will detach from MAG2 and attach at a new MAG3. In such a scenario, the important thing is that the If-ID information in the PBU sent from MAG3 has to have If2-ID. This interface ID is essential for LMA to allocate the correct prefix during horizontal handoff. As discussed Jeyatharan, et al. Expires December 19, 2008 [Page 17] Internet-Draft Multiple Interfaces in NetLMM June 2008 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 big problem of getting this interface ID because MAG3 is the directly connected access router of MN and the MN.If2 MAC address can be readily obtained (assuming MAC address is used as MN If-ID). The only danger in this scenario is that, if MAG3 does not have interface ID of If2 (for some reason) and it does not know the handoff state of MN, then it may set the handoff flag to "4" in the handoff indication option saying that the handoff is unknown. In such a worst case scenario, the LMA may assign a new prefix for If2 and session continuity for prefix P2 flows will be disrupted. Thus, these kind of issues needs to be prevented if multiple prefix model is deployed. The main concern is that if MAG3 does not know If2-ID, then getting this information quickly needs to be explored to prevent horizontal handoff establishment delay. Alternatively, the handoff state has to be explicitly informed to MAG3. Another area to be explored is the handoff delay optimization. As described in section 3, horizontal handoff delay can possibly be optimized using the stable 3G interface. However, in the multiple prefix model to achieve this is more difficult because the prefix of the interface undergoing handoff needs to be informed via a trusted entity to the 3G MAG. The LMA also needs to be informed to route packets for interface undergoing handoff via another interface. These signalings need to be done in a timely manner to achieve the benefits of handoff delay optimization. 4.3. Problem Analysis for Vertical Handoff +-------------------------------------------+ | | | Proxy Mobile IPv6 Domain | | | +-------------------------------------------+ | | | | MAG1.Addr | MAG2.Addr | MAG3.Addr +---------+ +------------+ +-----------+ | 3G/MAG1 | | WiMAX/MAG2 | | WLAN/MAG3 | +---------+ +------------+ +-----------+ \ / / If1(P1) \ /If2(P2) / If3(P2) +-------------+ /Vertical handoff | MN |------/ for If2 +-------------+ Figure 5: Vertical Handoff in Multiple Prefix Model Jeyatharan, et al. Expires December 19, 2008 [Page 18] Internet-Draft Multiple Interfaces in NetLMM June 2008 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 handoff 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 handoff is performed, then what is desired by vertical handoff from MN's point of view is that MN requires flows for prefix P2 to be sent via MN.If3. To achieve this, the LMA should assign prefix P2 to MN.If3. For LMA to process such vertical handoff request information and assign the desired prefix P2 in the above scenario, the PBU sent by MAG3 need to have If2-ID in addition to If3-ID. Moreover, as mentioned in [1], the handoff flag in the handoff indication option should specify that this is a vertical handoff. Thus one can clearly see the complexity involved in getting the correct prefix for vertical handoff in the multiple prefix model. Let us consider another scenario where MN did not have MN.If1 but only had MN.If2 and MN.If3. When MN performs a vertical handoff from MN.If2 to MN.If3, If2-ID may not be required in the PBU. Once LMA sees the handoff flag pointing to "2" (vertical hand-off), it will assign P2 to MN.If3. This is because LMA has no difficulty in identifying P2 cache since there are no other entries associated with MN. Thus, one can appreciate that the vertical handoff complexity is high when MN has more than two interfaces. As highlighted previously, when MN does vertical handoff in a complex scenario as shown in Figure 5, MAG3 needs If2-ID information in the PBU. The question is how such information can be obtained by MAG3. Suppose MAG3 is ePDG. Then, as mentioned previously, MN can supply the If2-ID to MAG3. Another option is that MAG3 can get it via context transfer from MAG2. If vertical handoff is performed between heterogeneous access network types, context transfer via heterogeneous networks may take some time and other fast mechanisms may need to taken into consideration to prevent vertical handoff establishment delay. In 3GPP inter access technology handoff 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 of the shutdown interface using purely network based mechanisms is not efficient and may not be possible. Thus, some terminal involvement is definitely useful in this scenario. 5. PMIPv6/CMIPv6 Interaction issues for Multihomed MN In this section, PMIPv6 and CMIPv6 interaction scenarios are analyzed Jeyatharan, et al. Expires December 19, 2008 [Page 19] Internet-Draft Multiple Interfaces in NetLMM June 2008 for MuIf terminal and also for a single interface terminal that is capable of processing different prefixes as a result of being capable of multihoming. In 3GPP SAE framework, the MN can select PMIPv6 or CMIPv6 (i.e. Dual stack MIPv6) when connecting to a network of a particular access technology. Thus, there are many scenarios where such heterogeneous mobility management mechanisms will be used for a MuIf terminal considering that a MN can be attached to home, foreign or simultaneously at home and foreign. PMIPv6/CMIPv6 interaction issues for a single interface terminal can be found in the document [11]. However, for futuristic use cases in 3GPP where the MN is attached via multiple interfaces, these advanced scenarios need to be looked into in depth. 5.1. Single Interface Processing Multiple Prefixes In this section, we look at a 3GPP specific scenario where the 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 we look at specific multihoming related issues when the MN wants such dual mobility management mechanisms, in two different scenarios. The first scenario is when MN is in the home domain or HPLMN and wants such dual mobility management operation. The second scenario is when MN is in the foreign or VPLMN and wants such dual mobility management operation. 5.1.1. PMIPv6 and CMIPv6 prefix processing at home domain In this section multihoming is analyzed from the perspective of multiple care-of addresses configured for a certain interface of MN when MN is in the HPLMN. Furthermore, the analysis is performed in a system that uses single prefix multihoming model at LMA/HA. We would like to highlight that the problem highlighted in this section is applicable even if LMA/HA deploys the multiple prefixes per MN model. Jeyatharan, et al. Expires December 19, 2008 [Page 20] Internet-Draft Multiple Interfaces in NetLMM June 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 6: Multihomed MN processing multiple 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 6, it is assumed that MN has multihoming support and can generate BIDs as in [6] 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 home address (MONAMI6/MIPv6 sense) is equal to MN.If1 address. The mechanism by which MN gets the MIPv6 home address can be 3GPP Jeyatharan, et al. Expires December 19, 2008 [Page 21] Internet-Draft Multiple Interfaces in NetLMM June 2008 specific or using dynamic bootstrapping mechanism. In Figure 6, 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, then 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 evolved node B (eNodeB) that also acts as a router as described in [12], 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 [2], 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. 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. 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 ot reduce the signaling storm in the core network. 5.1.2. PMIPv6 and CMIPv6 roaming issues for home routed 3GPP Scenario In this section we consider a scenario where both PMIPv6 and CMIPv6 mobility management operations are performed when MN is in VPLMN. 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. The assumption here is that MN Jeyatharan, et al. Expires December 19, 2008 [Page 22] Internet-Draft Multiple Interfaces in NetLMM June 2008 considers the prefix given by home P-GW as the MIPv6 home prefix. Usually, from MIPv6 point of view, when a node sees the home and foreign prefixes via a certain interface it will not engage in mobility related signaling. However, in the specific scenario, we assume that the MN can process foreign prefix although it sees home prefix and in that sense it is multihomed. +-----------+ 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 7: Simultaneously at home and at foreign for home routed 3GPP The above scenario shown in Figure 7 is the 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, then 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 Jeyatharan, et al. Expires December 19, 2008 [Page 23] Internet-Draft Multiple Interfaces in NetLMM June 2008 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. This is shown by the second entry in the BC in Figure 7. The second entry will overwrite the first entry. It can be clearly seen that there is double signaling done (i.e. one by MAG and another by MN) for the same binding. This problem needs to be solved. MN could possibly decide to use the PMIPv6 binding created by MAG to get reachability for the home prefix and then only use the care-of address configured from foreign P-GW to communicate with CN directly (i.e. dual mobility management mode). Another 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 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. 5.2. MuIf MN PMIPv6/CMIPv6 roaming issues In this section, the focus is on analyzing the issues when a MuIf MN does a simultaneous attachment via heterogeneous mobility management modes such as PMIPv6 and CMIPv6 to the common anchoring point. As described in [2], even when MN (assuming two interfaces) is in the HPLMN, the MN mobility management for the first interface can be performed via PMIPv6 mechanism and the mobility management for the second interface can be performed by CMIPv6 mechanism. In 3GPP roaming scenarios where the MN moves away from HPLMN, there can be specific intermediate scenarios where the MN has one interface attached to home domain (HPLMN) and the other interface attached to foreign domain (VPLMN). In such intermediate roaming scenarios also, MN may again be involved in different management mechanisms via its different interfaces. In this section, such scenarios are analyzed and some issues are highlighted that definitely need some MN involvement and some modifications to PMIPv6 protocol to support simultaneous usage in a PMIPv6 and CMIPv6 mixed mobility management environment as considered in the 3GPP framework. Jeyatharan, et al. Expires December 19, 2008 [Page 24] Internet-Draft Multiple Interfaces in NetLMM June 2008 +----------+ 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 8: MuIf MN attaching to HPLMN by using PMIPv6/CMIPv6 Mobility Management mechanisms This scenario as shown in Figure 8 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. Basically, MN will use the on-link prefix that is available in the 3G access network advertised by eNodeB or advertised by S-GW which is placed in the core network to configure a care-of address. 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. It is further considered that the home address is obtained from a prefix that is topologically rooted at the home P-GW. It is assumed that MN is attached 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 same home prefix when MAG2 performs the PMIPv6 binding at the LMA/HA. To maintain such simultaneous attachment, the PBU sent by MAG2 needs to have some If-ID or BID2 that is different from BID1. The mechanism by which MAG2 gets to know the correct value for BID2 needs to be supported by the system. Otherwise, MAG2 may use a BID that is of same value as BID1 and may overwrite the CMIPv6 entry and delete the reachability to cellular interface. There can be many mechanisms by which this problem can be solved. 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 Jeyatharan, et al. Expires December 19, 2008 [Page 25] Internet-Draft Multiple Interfaces in NetLMM June 2008 the LMA/HA to generate the BID that is different from BID1. For MAG2 to make such a request it needs to know that MN other interface is attached to the LMA/HA and this information needs to be given by MN. 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 so that simultaneous binding using CMIPv6 and PMIPv6 can be obtained. The problem and solution described in this section is applicable to either PMIPv6 multihoming models (i.e. the single prefix per MN and multiple prefixes per MN model). In another alternate scenario, if only the MN's WLAN interface in Figure 8 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, 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. It is important to understand that since the interface 2 PMIPv6 prefix and the home address prefix are the same, only when the BIDs are the same the old PMIPv6 entry can be overwritten by the new CMIPv6 entry for the same interface. Ideally, the second binding entry shown in Figure 8 should have been overwritten by the CMIPv6 binding for interface 2 due to roaming. If interface 2 current binding does not overwrite the old PMIPv6 binding for interface 2, packet loss can take place if the LMA/HA decides to route packets using the second entry in BC shown in Figure 8. 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 CMIPv6 binding. 5.3. MuIf MN PMIP/CMIP signaling optimization In this section, we consider a signaling optimization that can be performed in multiple interface case when one of the interface performs the CMIPv6 BU and the other interface performs the PMIPv6 BU. To further understand the optimization issue we again consider Figure 8. 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. 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. Basically, the CMIPv6 BU can be broken into steps such as bootstrapping to identify the HA address and then performing the CMIPv6 BU. To optimize the bootstrapping signaling part, if MN knows that the PMIPv6 binding is via HPLMN, then it can possibly configure the care-of address for interface 1 and perform Jeyatharan, et al. Expires December 19, 2008 [Page 26] Internet-Draft Multiple Interfaces in NetLMM June 2008 the CMIPv6 BU via the interface 2. In such a case, the discovery for home agent address need not be performed because, the MAG2 knows the address of home P-GW. The MN possibly can trigger MAG2 and request the MAG2 to perform the CMIPv6 binding. The MN needs to give the CMIPv6 binding contents to MAG2 so that PMIPv6 and CMIPv6 signaling optimization can be achieved. Such signaling optimization issues needs to be identified for PMIPv6 and CMIPv6 interaction scenarios. again we would like to highlight that the issue described in this section is applicable for both PMIPv6 multihoming models(i.e. single prefix and multiple prefixes) 6. 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 seperately. MuIf PMIP/CMIP related issues that are common to both the models were analyzed seperately. From the analysis as highlighted in the draft, irrespective of the model used, some further work is required to solve issues in: simultaneous attachment, flow filtering, horizontal and vertical hand-offs and PMIPv6/CMIPv6 related issues. Finally, we would like to conclude 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, we suggest that solution space analysis for these problems should consider solutions where MN involvement is minimal. 7. IANA Considerations This is an informational document and does not require any IANA action. 8. 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. 9. References Jeyatharan, et al. Expires December 19, 2008 [Page 27] Internet-Draft Multiple Interfaces in NetLMM June 2008 9.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. 9.2. Informative Reference [2] "Technical Specification Group Services and System aspects", 3GPP TR 23.402, December 2007. [3] 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. [4] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work in progress), February 2008. [5] 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. [6] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008. [7] 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. [8] "3GPP system architecture evolution (SAE)", 3GPP TR 23.882, January 2008. [9] 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. [10] Blume, O. and R. Sigle, "Secondary Binding Cache entries for Proxy MIPv6", draft-blume-netlmm-secondary-bce-proxymip6ho-00 (work in progress), February 2008. [11] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios Jeyatharan, et al. Expires December 19, 2008 [Page 28] Internet-Draft Multiple Interfaces in NetLMM June 2008 and related issues", draft-giaretta-netlmm-mip-interactions-02 (work in progress), November 2007. [12] "Technical Specification Group Services and System aspects", 3GPP TS 23.401, March 2008. Appendix A. Change Log 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. o draft-jeyatharan-netlmm-multi-interface-ps-00: * Initial version. Jeyatharan, et al. Expires December 19, 2008 [Page 29] Internet-Draft Multiple Interfaces in NetLMM June 2008 Appendix B. Multihoming Issues in PMIPv6 Single LMA Roaming Scenario +-----+ BCEs at LMA/HA for single prefix model | HA/ | +---------+---------+-------+----------+------+ | LMA | |MN prefix| MN.CoA | MN-ID | If-ID |Flag | +-----+ +---------+---------+-------+----------+------+ | | prefix | MAGaddr | NAI | If1-ID | | +----------------+ | HoA | CoA | NAI | BID2 |"H" | | Home PMIP | +---------+---------+-------+----------+------+ | domain | +----------------+ | +-----+ | MAG | MAG Address +-----+ | | +-----------+ | | foreign | | | domain | | +-----------+ | | HoA | If1 | +--------------+ If2 +-----+ | Monami6 MN |-------------| AR | +--------------+ CoA +-----+ Figure 9: Simultaneously at home and at foreign In this section some issues associated with MN when it roaming away from home domain is analyzed. In Figure 9, it is assumed that MN can be a MONAMI6 node. It is assumed that MN.If1 is attached to home domain, which is also a PMIPv6 domain. The entry created at LMA/HA due to MN.If1 attachment is shown by the first entry. If MN.If2 is attached to foreign domain, MN will configure a CoA for MN.If2 and will want to send a CMIPv6 binding to LMA/HA either using a "H" flag or will send a CMIPv6 binding using BID2 in the binding update. If such an action is performed by MONAMI6 MN, then the binding cache created is shown by the second entry. The important point here is that, if 'H" flag is used, then there is no problem because both MN interfaces reachability states are available at LMA/HA. However, if MONAMI6 nodes decides to put BID2, instead of "H" flag, and if BID2 sent in CMIPv6 BU is same as If1-ID, then there is a danger of overwriting the first PMIPv6 entry and thus loosing the simultaneous at home and away benefits. Furthermore, if MN is a MIPv6 node in Figure 9, then MN may not insert BID or "H" flag in CMIPv6 BU and this CMIPv6 BU will overwrite the first PMIPv6 PBU and multihoming benefits will be lost. Jeyatharan, et al. Expires December 19, 2008 [Page 30] Internet-Draft Multiple Interfaces in NetLMM June 2008 If multiple prefix model is active in the scenario shown in Figure 9, then such a roaming scenario does not pose any issue for a MIPv6 host that has two home addresses (one for each interface configured from 2 different home prefixes). This is because, the first entry in BCE will have P1 prefix (PMIPv6 entry) and the second entry will have a CMIPv6 entry tying MN HoA(configured from P2 prefix) to a care-of address configured in foreign domain. Thus, the caches from both interfaces are clearly separated by means of prefixes. In this multiple prefix roaming case, If-ID need not be attached in the CMIPv6 BU to separate the bindings. Thus, roaming is not a issue for an unmodified MIPv6 host. Appendix C. Multihoming Issues in Multiple LMA Scenario If there are multiple LMAs 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 December 19, 2008 [Page 31] Internet-Draft Multiple Interfaces in NetLMM June 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 10: PMIPv6 domain with multiple LMAs Figure 10 shows a scenario where MN is attached to a foreign PMIPv6 domain with multiple LMAs. 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 LMAs and the HA are shown in Figure 10. In this case, MN can enjoy multioming benefits. Jeyatharan, et al. Expires December 19, 2008 [Page 32] Internet-Draft Multiple Interfaces in NetLMM June 2008 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 Jun Hirano Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3 Hikarino-oka Yokosuka, Kanagawa 239-0847 JP Phone: +81 46 840 5123 Email: hirano.jun@jp.panasonic.com Jeyatharan, et al. Expires December 19, 2008 [Page 33] Internet-Draft Multiple Interfaces in NetLMM June 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jeyatharan, et al. Expires December 19, 2008 [Page 34]