NETEXT Working Group Y. Cui Internet Draft H. Wang Intended status: Standard Track T. Ma Expires: April 2010 Tsinghua University October 18, 2009 Simultaneous Multi-Access for PMIPv6 based on Single HNP Model draft-cui-netext-sma-pmipv6-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 18, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license- info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Cui, et al. Expires April 18, 2010 [Page 1] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 Abstract Simultaneous Multi-Access (SMA), originally designed for MIPv6, expects to be ported to PMIPv6 to achieve flow binding. However, there are a lot of problems to adapt SMA to PMIPv6 due to different mechanisms of two mobility management protocol. This document analyzes issues of SMA and different multihoming scenarios in PMIPv6. A PMIPv6 system which allows a MN to share HNP across its interfaces is proposed and a SMA solution is designed for the modified PMIPv6 system. The solution supports flow-based routing and address-based routing simultaneously. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................3 3. Overview.......................................................3 3.1. Issues of SMA Support in PMIPv6...........................3 3.2. Multihoming Scenarios of PMIPv6...........................5 3.2.1. Multiple HNP Model...................................5 3.2.2. Single HNP Model.....................................6 4. PMIPv6 based on Single HNP Model...............................6 4.1. HNP Allocation and Address Configuration..................6 4.2. Routing of LMA and MAG....................................7 5. SMA Operations.................................................8 5.1. Registration of Routing Rules.............................8 5.2. Data Transmission.........................................9 5.2.1. Sending Packet from MN..............................10 5.2.2. Sending Packet to MN................................10 5.3. Vertical Handoff.........................................11 6. Conclusion....................................................13 7. Security Considerations.......................................13 8. IANA Considerations...........................................13 9. References....................................................13 9.1. Normative References.....................................13 9.2. Informative References...................................13 10. Acknowledgments..............................................14 Cui, et al. Expires April 18, 2010 [Page 2] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 1. Introduction Proxy Mobile IPv6 (PMIPv6) [1] allows a multihoming mobile node to connect to a PMIPv6 domain via multiple interfaces simultaneously. With several paths available, flows could be bind to different path to achieve load-balance, high aggregated bandwidth and flow mobility. Simultaneous Multi-Access (SMA) [2], which is proposed to takes these advantages of multihoming in MIPv6, could be adapted to PMIPv6 to enable flow bindings. However, because of the fact that MN uses different Home Network Prefixes (HNPs) on different interfaces rather than a unique Home Address of MN in MIPv6, additional mechanism such as Primary Prefix is introduced into PMIPv6 to ensure packets can be routed to MN via a proper path [3]. As for the PMIPv6 specification, assigning different HNPs for different interfaces of one MN is regarded as lack of simultaneous usage support and therefore is difficult to provide flow binding support [4]. Besides this proposal, sharing the same HNPs across multiple interfaces of one MN in PMIPv6 is proposed as a solution for multihoming (different MNs are still assigned different HNPs). This model is able to provide convenience for some multihoming application, including flow-based routing [5]. This document describes a SMA solution for PMIPv6 based on Single HNP Model. In the rest of the document, the issues of SMA support in PMIPv6 and the advantages of sharing HNPs across interfaces are analyzed. Based on the modified PMIPv6 system, a SMA solution is proposed to support both address-based routing and flow-based routing. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3. Overview 3.1. Issues of SMA Support in PMIPv6 SMA, originally designed for MIPv6, aims to take advantages of multihoming. Its primary idea is to use policies to bind flow to a specified path based on different characteristics of multiple available paths (such as bandwidth, QoS, cost, etc.). In another word, MIPv6 system equipped with SMA function performs flow-based routing; both inbound packets and outbound packets are directed to a specified interface by either HA or MN according to policies. In MIPv6, each MN has a unique Home Address (HoA) which is always used as the source address of outbound packet and the destination Cui, et al. Expires April 18, 2010 [Page 3] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 address of inbound packet. Without regard to route optimization, tunnels from HA to MN ensures that packets can be routed to either MN or CN properly no matter which interface MN uses to transmit packets. Therefore, there is little difficulty in performing SMA in MIPv6. However, the situation is quite different in PMIPv6. First of all, unlike the unique HoA in MIPv6, MN is assigned different HNPs for each interface in PMIPv6 and consequently addresses of interfaces are different from each other. When communicating with CN, MN use the address on the outgoing physical interface so it could lead to troubles to bind an existing flow, which is usually identified by the source and destination addresses, to another interface. Flow-based routing might cause conflict with address- based routing for the address of bound interface might not match with the address of the flow. Second, additional mechanism is necessary to guarantee the validity of routing. Tunnels are built from LMA to MAGs rather than MN in PMIPv6. Therefore, even if LMA is able to perform flow- based routing to select a proper MAG to forward packets to, additional mechanisms are necessary to introduced to MAGs to ensure they are able to relay packets to MN. Take the scenario in Figure 1 as an example. MAG2 should have the information about HNP1 so as to forward Flow1 to MN via IF2. Otherwise, MAG2 cannot find a route match the destination of the packet; even if MAG2 is able to perform flow-based routing, it has to recognize which MN the flow belongs to by matching the destination address of the flow. Third, MN has to be extended to support SMA in PMIPv6. PMIPv6 is designed as a network-based mobility management protocol so that MN needs no extension to get mobility support in a PMIPv6 domain. However, to enable SMA function, MN has to be modified to support the generation and transmission of routing rules as well as flow binding operation. Moreover, owing to the above-mentioned two issues, existing proposal involves MN in mobility management to request Primary Prefix and to update Binding ID [3]. In short, flow-based routing of SMA relies on address-based routing because only address information of a packet can be used to identify the corresponding MN. With regard to PMIPv6, since there is no direct tunnel from LMA to MN, HNP allocation and conventional address-based routing of PMIPv6 should coordinate with SMA mechanism to achieve flow binding. Moreover, extension to MN is also necessary to make full use of multihoming. Cui, et al. Expires April 18, 2010 [Page 4] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 +----+ | CN | +----+ | +-------+ | LMA | Flow1 -> IF2 +-------+ / \ ----+ Flow1 / \ | Src Addr: CN / \ | Dst Addr: HNP1 / \ v +------+ +------+ | MAG1 | | MAG2 | +------+ +------+ \ / \ / \ / +-----------+ IF1: HNP1 | IF1 | IF2 | IF2: HNP2 +-----+-----+ | MN | +-----------+ Figure 1 Routing Problem of SMA in PMIPv6 3.2. Multihoming Scenarios of PMIPv6 Different scenarios of multihoming in PMIPv6 can be divided into two categories according to their HNP model. One is multiple HNP model that assign unique HNP to each interface; the other is single HNP model that assign the same HNP across interfaces of one MN. 3.2.1. Multiple HNP Model PMIPv6, defined in [1], use this model to assign HNP for MN. In this model, each interface is assigned a unique HNP so a multihoming MN always gets multiple HNPs; each binding tied to an interface of MN is considered as a separate mobility session; multiple interfaces are able to connect to PMIPv6 domain simultaneously and transmit data independently. However, some advanced multihoming application meets troubles in this model, including HNP allocation in vertical handoff, lack of simultaneous usage support [4], aforementioned SMA issues, etc. Cui, et al. Expires April 18, 2010 [Page 5] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 3.2.2. Single HNP Model In this model, a HNP is shared across different interfaces one MN. There are several forms for this model. One is to assign unique HNP to a MN and configure address for every interface of MN; another one is to allow some HNPs to be shared across different interfaces belonging to a MN; a third one is to configure the same address on every interface of a MN to emulate HoA of MIPv6. Despite varieties of this model, the primary feature of it is that the address of an interface has prefix in common with others and thus different MAGs are able to add general routing table entry for different interface addresses of one MN. However, this model causes problems for routing of LMA and MAG. As for conventional PMIPv6, prefix-based routing of LMA and MAG works well to forward packet for multihoming MN because prefixes of multiple interfaces are different from each other but this no longer work in Single HNP Model for prefix matching comes to ambiguous result. On the other hand, address-based routing is an alternative to prefix-based routing but it leads to troubles that are similar to problems of Multiple HNP Model. Yet, with the combination of prefix-based routing and address-based routing, Single HNP Model is able to provide a valid platform for SMA support, which will be described in the following sections. 4. PMIPv6 based on Single HNP Model This section describes a modified PMIPv6 system based on Single HNP Model. The PMIPv6 system SHOULD support multihoming and be able to forward a packet to a proper interface of MN based on the destination address. Moreover, it SHOULD support SMA function with the aid of routing rules management and flow-based routing extension. 4.1. HNP Allocation and Address Configuration The system is based on Single HNP Model so the same HNP is assigned to different interfaces of one MN. Yet, different HNPs MAY be assigned to different interfaces as that of conventional PMIPv6. However, for interfaces that are preparing for SMA usage, shared HNP SHOULD be assigned to them. Receiving HNP, MN SHOULD configure different addresses for different interfaces even if they share the same HNP. Although configuring the same address on different address emulates the HoA of MIPv6 to some degree, duplicated IPv6 global addresses on different physical interfaces might result in troubles such as address collision and some systems does not allow such operation. However, using the same prefix to configure different addresses is well supported so this approach is feasible. Cui, et al. Expires April 18, 2010 [Page 6] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 4.2. Routing of LMA and MAG LMA SHOULD add address-based routing table entries for each access interface that connects to the PMIPv6 domain. MAG SHOULD add both address-based and prefix-based routing table entries for each access interface that connects to the MAG itself. Address-based routing table entries of LMA and MAG ensure that packets can be routed to the interface with the destination address. The longest prefix matching of address-based routing make address-based entries selected to get the outgoing interface and next hop for each packet. On the other hand, prefix-based entries of MAG are used for simultaneous usage support and will come into handy in SMA function. To set up address-based entries, LMA and MAG SHOULD be aware of the addresses of access interface, which is different from original PMIPv6 for the prefix is enough to identify a routing path in Multiple HNP Model. This can be achieved by using Neighbor Discovery of IPv6. Since MN will send Neighbor Advertisement after configuring address on an interface, MAG can get the address of the access interface by receiving such messages. After that, MAG SHOULD inform LMA of the address. Thus, additional signaling is required to support address-based routing in Single HNP Model. Figure 2 shows the extended signaling call flow of MN attachment, in which extra PBU and PBA are added to transmit the address of access interface. Cui, et al. Expires April 18, 2010 [Page 7] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 +-----+ +-----+ +-----+ | MN | | MAG | | LMA | +-----+ +-----+ +-----+ | | | MN Attached | | | | | | MN Attached Event from MN/Network | | (Acquire MN-Id and Profile) | | | | |--- Rtr Sol --------->| | | | | | |--- PBU ------------->| | | | | | Accept PBU | | (Allocate HNP, Setup BCE & Tunnel) | | | | |<------------- PBA ---| | | | | Accept PBA | | (Set Up Tunnel) | | | | | |==== Bi-Dir Tunnel ===| | | | |<--------- Rtr Adv ---| | | | | IP Address | | Configuration | | | | | |----- Neigh Adv ----->| | | Accept NA | | (Set Up Routing) | | | | | |--- PBU ------------->| | | (Carrying address) | | | | | | Accept PBU | | (Set Up Routing) | | | | |<------------- PBA ---| | | | Figure 2 MN Attachment - Extended Signaling Call Flow 5. SMA Operations 5.1. Registration of Routing Rules A Routing Rule is a rule which specifies that traffic with certain characteristic is to be handled in a certain manner. Its main application is to bind a flow to a certain path. A Path Identifier Cui, et al. Expires April 18, 2010 [Page 8] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 (PID) is used to identify a path between a multihoming MN and its peers [2]. For MIPv6, the PID is identical to the Binding Identifier (BID) [6]. In PMIPv6, there is no BID for bindings but a Link-layer Identifier (LL-ID) is generated for each access interface and it can be used to identify a path. Routing Rules can be generated by either MN or LMA and should be transmitted to the other side by generator. The transmission of Routing Rules can be achieved by extended ICMP messages and mobility signaling defined in [3]. At LMA, Routing Rules are stored in the Binding Cache Entry for the LL-ID. 5.2. Data Transmission This section will explain how traffic is sent from and to a MN based on SMA function. Figure 3 shows a PMIPv6 multihoming scenario with the following assumptions: o MN has two active interfaces; IF1 connects to MAG1 and IF2 connects to MAG2. o IF1 and IF2 share the same HNP but they have respective addresses (ADDR1 and ADDR2). o Both MAG1 and MAG2 have set up address-based and prefix-based routing table entries for corresponding access interface. o LMA has set up address-based routing table entries for IF1 and IF2. o A set of Routing Rules with associated LL-IDs have been created and transmitted. They are stored in both MN and LMA. List of Routing Rules: Flow A <--> LL-ID1 Flow B <--> LL-ID2 o MN is communicating with a CN. Cui, et al. Expires April 18, 2010 [Page 9] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 +----+ Binding Cache: | CN | ============== +----+ MN-ID, HNP, LL-ID1, | Flow A <--> LL-ID1; | MN-ID, HNP, LL-ID2, | Flow B <--> LL-ID2; | +-------+ LMA RT (Routing Table): | LMA | ================== +-------+ ADDR1 -> MAG1 / \ ADDR2 -> MAG2 / \ / \ / \ MAG1 RT: +------+ +------+ MAG2 RT: ======== | MAG1 | | MAG2 | ======== ADDR1 -> MN +------+ +------+ ADDR2 -> MN HNP -> MN \ / HNP -> MN \ / \ / +-----------+ IF1: HNP1, ADDR1 | IF1 | IF2 | IF2: HNP, ADDR2 +-----+-----+ | MN | +-----------+ Routing Rules: ============== Flow A <--> LL-ID1 Flow B <--> LL-ID2 Figure 3 Scenario of SMA in PMIPv6 5.2.1. Sending Packet from MN When MN sends a packet to CN, it will match the packet with Routing Rules. If the packet matches one of the Routing Rules, the outgoing interface is selected according to the LL-ID in the Routing Rule. Otherwise, MN just looks up into routing table to get the outgoing interface by address-based routing. With the outgoing interface, MN transmits the packet on that interface. The MAG receiving the packet tunnels the packet to LMA. LMA decapsulates the packet and routes it towards CN. 5.2.2. Sending Packet to MN When LMA receives a packet from CN, it will search the Binding Cache for entries with HNP matches the destination address of the packet. Then it will check whether the packet matches one of the Routing Rules belong to those Binding Cache entries. Cui, et al. Expires April 18, 2010 [Page 10] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 If the packet matches one of the Routing Rules, the tunnel interface identifier of the corresponding binding cache is selected and LMA will use that tunnel to forward packet towards MAG. When MAG receive the packet, it decapsulates the packet and performs address-based routing to forward the packet to MN. If the address of access interface connecting to the MAG is not the same as the destination address of the packet, MAG can still route it based on the prefix-based routing table entry for ADDR1 and ADDR2 share the same prefix; if the two addresses are the same, MAG will route it based on the address-based entry: issues mentioned in Section 3.1 no longer troubles. Otherwise, if none of the Routing Rules is matched, LMA and MAG will just perform address-based routing. The address-based routing table entries set up in the registration procedure are enough to help to route the packet to MN. However, a problem arises when MN receives the packet. Although network side manages to route the packet to one of the interfaces of MN, MN has to be able to receive a packet aiming at one interface from another interface. Otherwise, when the destination address of the packet does not match the address of receiving interface, the packet would be discarded. Yet, weak End System Model, defined in [7] and supported by most of current systems, allows MN to do so. Therefore, MN is able to receive the packet as long as network side forwards the packet properly. 5.3. Vertical Handoff In SMA, moving flows across running interfaces could be achieved by changing routing rules but it cannot handle the condition where an interface disconnect from the network. For example, MN in Figure 3 starts a flow on IF1 with ADDR1. If IF1 disconnect from the network, the address configured on it is also gone. Thus, MN cannot receive the existing flow any longer even if network side route the flow to IF2. To solve the problem, additional mechanism is need to perform vertical handoff, i.e. the handoff between different interfaces. Both network side and MN are involved in vertical handoff. First, network side SHOULD be aware of the handoff event so as to launch a new proxy registration and modify routing entries. Second, MN SHOULD be able to configure ADDR1 on IF2 to receive the existing flow. As for the network side, although Handoff Indicator Option is defined in PMIPv6 [1] to implement such a handoff, no mechanism is designed for MAG to detect handoff event so it cannot set the value of the option properly. This document suggests that MN notify MAG of handoff event since only MN itself is aware of whether it would like to perform a handoff to move existing flow Cui, et al. Expires April 18, 2010 [Page 11] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 to IF2 or it just want to terminate IF1 as well as the flow on it. The notification could be done by sending an extended RS, just like that defined in [8], via IF2. After receiving the request, MAG2 will perform a new registration for ADDR1. Since IF1 and IF2 shares the same HNP, MAG and HNP just need to change their address-based routing entries as well as update binding cache and binding update list. When MN receives RA, it SHOULD be configure ADDR1 on IF2 so address configuration mechanism of MN need to be modified to meet such requirement. How to extend MN to support extended RS and the modified address configuration mechanism is out of scope of this document. Figure 4 shows the signaling call flow of vertical handoff. Notice that since LMA has already got ADDR1 and it could inform MAG2 of ADDR1 in PBA, it is not necessary for MAG2 to get the address by listening for Neighbor Advertisement. +-----+ +-----+ +-----+ | MN | | MAG | | LMA | +-----+ +-----+ +-----+ | | | Launch V. Handoff | | | | | | | | |--Extended Rtr Sol -->| | | (V. Handoff Req.) | | | |--- PBU ------------->| | | | | | Accept PBU | | | | | | | |<------------- PBA ---| | | (Carrying Address) | | | | | Accept PBA | | | | |<--------- Rtr Adv ---| | | | | IP Address | | Configuration | | | | | Figure 4 Vertical Handoff - Signaling Call Flow After the handoff operation, LMA and MAG are able to forward the existing flow to IF2 and MN is also able to receive the flow via IF2 for ADDR1 is configured on MN again. Cui, et al. Expires April 18, 2010 [Page 12] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 6. Conclusion This document describes a SMA solution for PMIPv6 based on Single HNP Model. The protocol performs flow-based routing based on Routing Rules to bind both inbound and outbound flow to a specified path while it performs address-based routing for packets that do not match any Routing Rules. Extra mobility signaling call is added to set up address-based routing. Both LMA and MAG are extended to be able to generate Routing Rules, transmit them and route packets according to them; however, the extension on MN is limited to SMA function and mobility management is still done by network side, which follows the idea of PMIPv6. 7. Security Considerations This document does not introduce any new security concerns on top of what is described in Security Considerations section of [1]. 8. IANA Considerations This document does not request any assignments from IANA. 9. References 9.1. Normative References [1] K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", RFC5213, August 2008. 9.2. Informative References [2] C. Larsson, M. Eriksson, K. Mitsuya, K. Tasaka and R. Kuntz, "Flow Distribution Rule Language for Multi-Access Nodes", draft-larsson-mext-flow-distribution-rules-01, July 2008. [3] C. Larsson, M. Eriksson and P. Arvidsson, "Simultaneous Multi-Access and Flow Mobility Support for PMIPv6", draft- larsson-netext-pmipv6-sma-flow-mobility-00, March 2009. [4] M. Jeyatharan, C. Ng, V. Devarapalli and J. Hirano, "Multiple Interfaced Mobile Nodes in NetLMM", draft- jeyatharan-netlmm-multi-interface-ps-03, October 2008. [5] M. Jeyatharan and C. Ng, "Multihoming Problem Statement in NetLMM", draft-jeyatharan-netext-multihoming-ps-01, March 2009. [6] M. Eriksson, C. Larsson and R. Kuntz, "Mobile IPv6 Flow Routing over Multiple Care-of Addresses", draft-eriksson- mext-mipv6-routing-rules-00, June 2008. Cui, et al. Expires April 18, 2010 [Page 13] Internet-Draft SMA for PMIPv6 based on Single HNP Model October 2009 [7] R. Braden, "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989. [8] T. Savolainen, D. Premec, "Inter-technology handover in PMIPv6 domain", draft-savolainen-netext-intertech-handover- 00, July 2009. 10. Acknowledgments The authors would like to thank Conny Larsson for his advice and the discussion on the topic. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Yong Cui Tsinghua University Tsinghua University FIT Building 4-104 Beijing 100084 P.R.China Email: cuiyong@tsinghua.edu.cn Hongyi Wang Tsinghua University Tsinghua University FIT Building 4-103 Beijing 100084 P.R.China Email: whynpc@gmail.com Tianze Ma Tsinghua University Tsinghua University FIT Building 4-104 Beijing 100084 P.R.China Email: frank0208@gmail.com Cui, et al. Expires April 18, 2010 [Page 14]