Internet Area M.Hui Internet Draft H.Deng Intended status: Informational China Mobile Expires: April 19, 2010 October 19, 2009 PMIPv6 Multihoming Extension and Synchronization in LMA and MAG draft-hui-netext-multihoming-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 19, 2010. 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. Hui&Deng Expire April, 2010 [Page 1] Internet-Draft PMIP multihoming extension October 2009 Abstract Proxy Mobile IPv6 is standardized to provide network-based mobility management for a regular IPv6 mobile node. This document introduces an extension to Proxy Mobile IPv6 for multihoming MN. Through extending the binding relationship between HNP and MAG in BCE, and synchronizing this information between LMA and MAGs, LMA can deliver data having the same HNP through multiple MAGs. Thus the MN attaching in a PMIPv6 domain can receive data packets with the same destination through its multiple network interfaces attaching to different MAGs simultaneously. Hui&Deng Expire April, 2010 [Page 2] Internet-Draft PMIP multihoming extension October 2009 Table of Contents 1. Problem Statement ........................................... 4 2. Scenario of the multihoming extension ........................6 3. Protocol Operation .......................................... 7 4. PMIPv6 Multihoming Extension................................. 9 4.1. Binding Cache and Binding Update list Extension..........9 4.2. Data Forwarding Operation.............................. 10 5. Security Considerations..................................... 12 6. IANA Considerations ........................................ 12 7. References ................................................. 12 7.1. Normative References................................... 12 7.2. Informative References................................. 12 Author's Addresses ............................................ 13 Hui&Deng Expire April, 2010 [Page 3] Internet-Draft PMIP multihoming extension October 2009 1. Problem Statement Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 MN without requiring its participation in any mobility-related signaling [1]. If the MN has multiple interfaces, it is hoped that these interface can work coordinately, so that a proper interface can be chosen to deliver the data. In PMIP domain, the LMA is responsible for assigning the MN's home network prefix(es) and managing the MN's binding state. LMA will assign different HNPs to multiple interfaces of the MN, and it will be several Binding Cache Entries for the MN based on the HNPs in LMA. The problem is if LMA receives data with HNP1 as the destination, according to the BCE of HNP1, it will send the data to IF1 through MAG1, although IF2 of MN can also deliver the data, see figure 1. In that case, the multihoming MN cannot benefit from its multiple interfaces. +-----+ | CN | +-----+ | LMA Binding Cache | ===================== | MN: HNP1 ---> MAG1 +-----+ : HNP2 ---> MAG2 | LMA | +-----+ //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | IF1 IF2 | +------[MN]------+ Figure 1 Multihoming Scenario Hui&Deng Expire April, 2010 [Page 4] Internet-Draft PMIP multihoming extension October 2009 To solve this problem, it is proposed to extend BCE to bind the HNP to several proxy-CoA related to the same MN, and synchronize this information between LMA and MAGs, then the data can be transferred through all of the interfaces. Several benefits can be achieved by doing that multihoming extension: 1) Enable the flow mobility. That means the flow aiming a certain IF can be transferred to other IFs because of the user preference, operator policy, network load, etc. 2) Enable the load sharing. The traffic to a certain IF of MN can be separated among different Ifs, and less loaded IFs can be selected. And when the bandwidth of an IF is limited, other IFs can be used to help deliver the data together. Hui&Deng Expire April, 2010 [Page 5] Internet-Draft PMIP multihoming extension October 2009 2. Scenario of the multihoming extension As shown in Figure 2, the multihoming MN has two network interfaces IF1 and IF2, attaching to the MAG1 (IF1) and MAG2 (IF2) respectively. +-----+ | CN | +-----+ | LMA Binding Cache | ===================== | MN: HNP1 ---> {MAG1, MAG2} +-----+ : HNP2 ---> MAG2 | LMA | +-----+ //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | IF1 IF2 | +------[MN]------+ Figure 2 Scenario of the multihoming extension Assuming the IF1 of the MN which attaches to MAG1 turns on first, the LMA assigns the HNP1 to the IF1. The MN initiates a video telephony call with the CN, sending and receiving traffic addressed to HNP1 via IF1. Then the performance of IF1 degrades significantly, and the IF2 becomes available which attaches to MAG2. The bandwidth of any of IF1 or IF2 is not enough to maintain the video telephony traffic, so a possible solution is to enable the MN to send and receive the traffic addressed to HNP1 via IF1 and IF2 simultaneously. Such a solution would make best use of the multiple interfaces of the MN and improve the user's experience. Hui&Deng Expire April, 2010 [Page 6] Internet-Draft PMIP multihoming extension October 2009 3. Protocol Operation This section introduces the multiple interface attach procedures for multi-homing MN with two interfaces (IF1 and IF2) in a PMIPv6 domain with extended BCE . +-----+ +-----+ +-----+ +-----+ | MN | | MAG1| | LMA | | MAG2| +-----+ +-----+ +-----+ +-----+ IF1 IF2 | | | | | | | | | | | | | 1) |----- Rtr Sol------->| | | | (IF1 attachment) |------- PBU ----->| | | | | | | | | | | | 2) | | | Accept PBU | | | | (Allocate HNP1, Setup BCE and Tunnel1) | | | | | | | | | | | | |<------ PBA ------| | 3) |<------ Rtr Adv -----| (MN-HNP1) | | | | | | | | | | | | |<========data========|<=====data========| | | | | | | | | | | | 4) | |------------- Rtr Sol ( IF2 attachment) --------------->| | | | |<----- PBU -------| | | | | | | | | | | 5) | | | Accept PBU | | | (Allocate HNP2, Create and Update BCE and Setup Tunnel2) | | | | | | | | | | 6) | | | |------- PBA ----->| | | | | (HNP1 & HNP2) | | |<-------------------- Rtr Adv ------------------------- | | | | | | | | | | | 7) |<=================data(HNP1)============|======data=======>| | |<============================data(HNP1 & HNP2)==========| | | | | | Figure 3 Multiple Interfaces Attach Procedure Hui&Deng Expire April, 2010 [Page 7] Internet-Draft PMIP multihoming extension October 2009 Figure 2 shows the signaling call flow of the multiple interface attach procedures. The detailed explanations of the signaling procedures are as follows. 1)-4) It is the standard procedure defined in RFC5213. 5) Upon receiving the PBU message from the MAG2, the LMA does a lookup in MN's the binding cache. If a binding cache entry exists with MN-ID field matching the identifier in the received MN-ID option, MN-LL-ID field not matching the identifier in the received MN-LL-ID option, the LMA will assign the new HNP2 to the IF2.The LMA creates the new binding cache entry including the MN-ID, MN- LL-ID (for IF2), HNP2 field with additional "Quantity of MAG" field set to 1.The LMA also updates the existing binding cache entry of HNP1 with "Quantity of MAG" field increased to 2, default Proxy-CoA for MAG1 and standby Proxy-CoA for MAG2. 6) The LMA returns a PBA message including HNP1 and HNP2 for IF2 to the MAG2. 7) The bi-directional tunnel2 between MAG2 and LMA is set up to forward the traffic addressed to HNP1 and HNP2. Thus, the MN could receive the traffic addressed to HNP1 via IF1 and IF2, and only receive the traffic addressed to HNP2 via IF2. The mapping between IP flow and MAG can be based on Service Flow Identifier specified in draft-hui-netext-service-flow-identifier , and the binding policy is out of the scope of this document. Hui&Deng Expire April, 2010 [Page 8] Internet-Draft PMIP multihoming extension October 2009 4. PMIPv6 Multihoming Extension This section introduces PMIPv6 multihoming extensions that are necessary for supporting data transmission through multiple MAGs, and then interfaces, simultaneously. 4.1. Binding Cache and Binding Update list Extension The binding is conceptually stored in the binding cache entry and binding update list entry of the local mobility anchor and mobile access gateway. Besides the standard field (HNP, MN-ID, etc), it should be extended to include the following parameters: O Quantity of MAG: an additional field, an integer indicating the number of the MAGs that the home network prefix is associated with. O MAG Parameter Sets: modified field sets, each of which is associated with a MAG that the home network prefix is associated with. The following parameters are included in a set: 1) Service Flow Identifier, an additional sub-field. A service flow identifier is used to indicate one of the flows binding to the MAG associated with the set. When flows are binding to the MAG, the sub-field would include multiple flow identifiers. The detailed format of service flow Identifier is out of the scope of this document, more information can be found in [draft-hui-netext-service- flow-identifier]. 2) The link-layer identifier of the mobile node's connected interface on the access link, described in Section 5.1 of [RFC5213]. 3) The link-local address of the mobile access gateway on the point-to-point link shared with the mobile node, described in Section 5.1 of [RFC5213]. 4) The tunnel interface identifier (tunnel-if-id) of the bi- directional tunnel between the local mobility anchor and the mobile access gateway where the mobile node is currently anchored, described in Section 5.1 of [RFC5213]. 5) The access technology type, by which the mobile node is currently attached, described in Section 5.1 of [RFC5213]. Hui&Deng Expire April, 2010 [Page 9] Internet-Draft PMIP multihoming extension October 2009 6) The 64-bit timestamp value of the most recently accepted Proxy Binding Update message sent for this mobile node, described in Section 5.1 of [RFC5213]. 4.2. Data Forwarding Operation In order to receive the traffic addressed to specific interface at any other interfaces, the MN MUST follows the Weak host model [2]. LMA lookup: When the LMA receives data packet from a CN, it makes a lookup in its binding cache with the lookup key - the destination address of the data packet. Case 1. If there exists a binding cache entry, with the HNP field matching the destination address, and the Quantity of MAG is set to 1, then the corresponding bi-directional tunnel will be used to forward the data packets to the MAG. Case 2. If there exists a binding cache entry, with the HNP field matching the destination address, and the Quantity of MAG is greater than 1, then the LMA will select the most suitable MAG based on service flow identifier which is binding to the MAG and matches the data packet. If there doesn't exist such a service flow identifier, the LMA should select the MAG corresponding to the first parameter set in the entity, which is named as preferred MAG and the others as reserved MAG(s). In both cases, the corresponding bi-directional tunnel will be used to forward the data packets to the selected MAG. Synchronization of binding status between LMA and MAG The extend BCE in LMA stores the information binding the HNP to several proxy-CoAs related to the same MN. And according to RFC 5213, LMA sends one HNP or multiple HNPs in a PBA message to MAG. Thus LMA can insert HNP(s) into PBA message to indicate that the data packets with any of the HNPs should be forwarded to the MN through the MAG. Hui&Deng Expire April, 2010 [Page 10] Internet-Draft PMIP multihoming extension October 2009 The MAGs do not need to perceive the existence of the multihoming extension of PMIPv6 and the detailed information of binding status about any of HNPs and MAGs. The MAGs make all the operations based on RFC 5213 when receiving a PBA message. MAG operation of data forwarding There is no changes for MAGs when to forward data packets. The detailed process of forwarding data in MAG can be found in Section 6.10.5 of [RFC5213]. Hui&Deng Expire April, 2010 [Page 11] Internet-Draft PMIP multihoming extension October 2009 5. Security Considerations Since this document doesn't propose any new protocol, it uses the same security as the proxy binding update operation in RFC 5213. 6. IANA Considerations This document makes no request of IANA. 7. References 7.1. Normative References [1] S. Gundavelli, Ed., "Proxy Mobile IPv6", RFC 5213, August 2008. [2] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [3] M.Hui,"Service Flow Identifier in Proxy Mobile IPv6", draft-hui- netext-service-flow-identifier(work in progress), June 2009. 7.2. Informative References Hui&Deng Expire April, 2010 [Page 12] Internet-Draft PMIP multihoming extension October 2009 Author's Addresses Min Hui China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: huimin.cmcc@gmail.com Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui02@gmail.com Hui&Deng Expire April, 2010 [Page 13]