NETEXT Working Group Hong-Ke Zhang Internet Draft Zhi-Wei Yan Expires: December 2010 Hua-Chun Zhou Si-Dong Zhang Beijing Jiaotong University March 26, 2010 Address-option based multi-interface supporting in PMIPv6 draft-zhang-netext-ao-mulif-00.txt 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, 2010. Abstract The NetLMM WG has specified the Proxy Mobile IPv6 (PMIPv6) for network-based localized mobility management, taking basic support for registration, de-registration and handover of Mobile Node (MN) into account in the RFC 5213 [1]. However, when a MN configures with multiple interfaces, the corresponding supporting scheme is needed. This document proposes an easy extension of the basic PMIPv6 protocol with the address option. Then the MN can communicate with CN using anyone interface but always maintain the upper layer application with a fixed home address (HoA). Besides, the operation and extension is transparent to the MAG and compatible with the other specifications. Zhang et al. Expires December,2010 [Page 1] Internet-Draft Address option based mulif in PMIPv6 March 2010 Conventions used in this document 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 5213 [1]. Table of Contents 1. Introduction...................................................2 2. Address options in PMIPv6......................................3 2.1. Primary HoA option........................................3 2.2. Type2 routing header......................................4 3. Extended binding state.........................................4 4. Packet transmission............................................5 4.1. Incoming packets..........................................5 4.2. Outgoing packets..........................................6 5. Deployed in different scenarios................................6 5.1. Unique Prefix per Interface...............................7 5.2. Unique Address per Interface..............................8 5.3. Shared Address across Interfaces..........................9 6. Use cases......................................................9 6.1. Multihoming support......................................10 6.2. Inter-technology handover support........................11 6.3. Flow mobility support....................................12 7. Compatibility.................................................12 7.1. With RFC 5213............................................12 7.2. With RFC 3775............................................12 7.3. With RFC 5648............................................12 8. Security Considerations.......................................13 9. References....................................................13 Author's Addresses...............................................14 Intellectual Property Statement..................................14 Full Copyright Statement.........................................14 Acknowledgment...................................................15 1. Introduction As an important extension of basic PMIPv6 specification [1], the multi-interface supporting in PMIPv6 has attracted special attentions. Based on the multi-interface supporting scheme, the MN can support the multihoming, vertical handover and flow mobility. In the draft [2], the multi-interface deployment scenarios are proposed. Based on this study, many multi-interface supporting schemes are proposed in order to support the above mentioned features [3-6] in separated or integrated manner. However, some of them can support the multi- interface MN in special scenario, and some of them have to extend the basic PMIPv6 to a large degree. Zhang et al. Expires December,2010 [Page 2] Internet-Draft Address option based mulif in PMIPv6 March 2010 So in this document, we propose a light-weight multi-interface supporting scheme based on the extended address option in basic PMIPv6. We are aiming to support the multi-interface MN under every deployment scenario but be compatible with other specifications. 2. Address options in PMIPv6 In MIPv6 [7], the Home address option and Type2 routing header are used to support the optimized communication between MN and the corresponding node (CN). With these two options, the upper layer applications of MN always use the HoA even the corresponding traffic may be transmitted through the Care-of Address (CoA). Based on this scheme, we extend the PMIPv6 with the address option to support the multi-interface MN. 2.1. Primary HoA option In the multi-interface scenario, the first HoA configured by the MN is denoted by the primary HoA. Then all the upper layer applications are established based on the primary HoA. For all the packets transmitted from MN to LMA, the primary HoA option is used to carry the primary HoA if the MN wants to transmit the packets from the interface different from the interface corresponding to the primary HoA. The format of primary HoA option is illustrated in figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Primary HoA + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Format of primary HoA option Option Type TBD Option Length Zhang et al. Expires December,2010 [Page 3] Internet-Draft Address option based mulif in PMIPv6 March 2010 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. Primary HoA The primary HoA of the multi-interface MN. This address MUST be a unicast routable address. 2.2. Type2 routing header. We use the Type2 routing header defined in MIPv6 to allow the packet to be routed to the final destination (e.g., primary HoA). Once the packet arrives at the MN, the mobile node retrieves its primary HoA from this routing header and uses it as the final destination of the packet. Its format is shown in figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Primary HoA + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Format of Type2 routing header Option Type TBD Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. Primary HoA The primary HoA of the MN. 3. Extended binding state In order to support the multi-interface MN, the binding state in LMA should be extended. In order to differentiate the multiple paths to Zhang et al. Expires December,2010 [Page 4] Internet-Draft Address option based mulif in PMIPv6 March 2010 the MN, the LMA should maintain multiple sub-entries corresponding to one MN-ID. The newly defined information is: InterFace Priority (IFP): 8-bit unsigned integer. This value is an identification number used to distinguish multiple bindings registered for one MN. Assignment of distinct IFPs allows registering multiple binding cache entries for a given mobile node. Besides, the higher value of IFP means the priority of the corresponding interface is higher. The LMA must transmit the packets to MN through the path with the highest IFP value. P flag (P): 1-bit unsigned integer. This flag is used to denote whether the corresponding interface is that interface configured with primary HoA. The value of IFP and P can be set by the MN itself and transmitted to the MAG. Besides, they are contained in the PBU and PBA messages to notify the LMA. They can be contained in the Mobile Node Link-layer Identifier Option as shown in figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IFP |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Link-layer Identifier + . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Extended Mobile Node Link-layer Identifier Option 4. Packet transmission Based on the newly defined address option and routing header, the packet transmission in basic PMIPv6 has to be extended as follows. 4.1. Incoming packets For the incoming packets sent from CN to MN, they are firstly transmitted to the LMA according to the routing protocol. Then the LMA checks the destination address and finds if the primary HoA should be added (e.g., primary HoA has the highest IFP). If the IFP of primary HoA is the highest, the LMA directly encapsulates this packet into the LMA-MAG tunnel and sends this packet to MAG as the Zhang et al. Expires December,2010 [Page 5] Internet-Draft Address option based mulif in PMIPv6 March 2010 basic PMIPv6 specified. Finally, the packet can be transmitted through the MN's interface corresponding to the primary HoA. Otherwise, the LMA replaces the destination address with the HoA with the highest IFP and adds the Type2 routing header in the packet. Then the packet is encapsulated into the LMA-MAG tunnel. In the Type 2 routing header, the primary HoA is carried. When the MN receivers this packet finally and finds the existing of the Type2 routing header, the MN replaces the destination address with the address in the Type2 routing header. Then the packet is transferred to the upper layer and seems to be transmitted to the primary HoA. 4.2. Outgoing packets When the MN wants to send the packet from the interface corresponding to its primary HoA, it is sent out following the basic PMIPv6 procedure. However, when the MN wants to send it through a different interface, the Primary HoA option is added in the packet and its primary HoA is carried. When the LMA receivers this packet with Primary HoA option, it replaces the source address with the address in the primary HoA option and sends it to the destination. Finally, when the CN receives this packet, it seems that the packet is sent by the primary HoA of MN. 5. Deployed in different scenarios In this section, we illustrate our scheme based on the following three multi-interface scenarios [2]. +----+ |LMA | +----+ +---------//--\\-----------+ ( // \\ ) +------//--------\\--------+ PCoA1 // \\ PCoA2 +----+ +----+ |MAG1| |MAG2| +----+ +----+ \ / +----\---------/----+ |IF1|-----------|IF2| |-------------------| | MN | +-------------------+ Zhang et al. Expires December,2010 [Page 6] Internet-Draft Address option based mulif in PMIPv6 March 2010 Figure 4 Network architecture The network architecture is shown in figure 4. As shown in figure 4, the multi-interface MN is configured with interface 1 (IF1) and interface 2 (IF2), which connect to the MAG1 and MAG2 separately. In order to encapsulate the primary HoA of MN in the primary HoA option, the LMA should know the primary HoA of the MN firstly. When the stateless address configuration scheme is used, the LMA only allocate the HNP for the MN. However, when the LMA receives the PBU message containing the Mobile Node Link-layer Identifier Option, the LMA can also know the primary HoA of MN because the LMA can construct the HoA as the MN does. When the stateful address configuration scheme is adopted, the MAG can notify the HoA to the LMA. The actual implementation details are out of scope of this document. 5.1. Unique Prefix per Interface In this scenario, the MN receives different HNPs from different interfaces and configures different HoAs accordingly. The first HoA is denoted as primary HoA. And all the upper layer applications are established with the primary HoA. Then the binding state of LMA is shown in figure 5. LMA's binding state +----+ ------------------- |LMA | MN_ID, HNP1:IF1, IFP1, P=1 -> MAG1 +----+ MN_ID, HNP2:IF2, IFP2, P=0 -> MAG2 +---------//--\\-----------+ ( // \\ ) ( // \\ ) +------//--------\\--------+ // \\ PCoA1 // \\ PCoA2 +----+ +----+ |MAG1| |MAG2| +----+ +----+ \ / +----\---------/----+ HNP1:IF1 |IF1|-----------|IF2| HNP2:IF2 |-------------------| | MN | +-------------------+ Zhang et al. Expires December,2010 [Page 7] Internet-Draft Address option based mulif in PMIPv6 March 2010 Figure 5 The extended binding state in scenario1 As shown in figure 5, the MN configures two HoAs in the IF1 and IF2, according to the distinguished HNPs. The HNP1:IF1 is its primary HoA,, then its P flag is set to 1. If the IFP1 is bigger than IFP2, the basic PMIPv6 procedure is executed. If the IFP1 is smaller than IFP2, the packet should be sent through the MAG2 but the HNP1:IF1 is contained in the primary HoA option. If the IFP1 equals to the IFP2, the packet should be sent simultaneously though the MAG1 and MAG2, but the packet sent through MAG2 should contain the primary HoA option. 5.2. Unique Address per Interface In this scenario, the mobile node is assigned the same prefix across multiple interfaces, but with a unique address per interface. The first HoA is denoted as primary HoA. And all the upper layer applications are established with the primary HoA. Then the binding state of LMA is shown in figure 6. LMA's binding state +----+ ------------------- |LMA | MN_ID, HNP:IF1, IFP1, P=1 -> MAG1 +----+ MN_ID, HNP:IF2, IFP2, P=0 -> MAG2 +---------//--\\-----------+ ( // \\ ) ( // \\ ) +------//--------\\--------+ // \\ PCoA1 // \\ PCoA2 +----+ +----+ |MAG1| |MAG2| +----+ +----+ \ / +----\---------/----+ HNP:IF1 |IF1|-----------|IF2| HNP:IF2 |-------------------| | MN | +-------------------+ Figure 6 The extended binding state in scenario2 The operation of our scheme is similar with that in the first scenario and we will not explain it in detail. Zhang et al. Expires December,2010 [Page 8] Internet-Draft Address option based mulif in PMIPv6 March 2010 5.3. Shared Address across Interfaces In this scenario, the mobile node is assigned the same address across multiple interfaces. This scenario enables a mobile node to use different links, but make only one IP address visible to the applications. Figure 7 illustrates this scenario. LMA's binding state +----+ ------------------- |LMA | MN_ID, HoA, IFP1, P=1 -> MAG1 +----+ MN_ID, HoA, IFP2, P=0 -> MAG2 //\\ +---------//--\\-----------+ ( // \\ ) ( // \\ ) +------//--------\\--------+ // \\ PCoA1 // \\ PCoA2 +----+ +----+ |MAG1| |MAG2| +----+ +----+ \ / \ / \ / +----\---------/----+ HoA |IF1|-----------|IF2| HoA |-------------------| | MN | +-------------------+ Figure 7 The extended binding state in scenario1 As shown in figure 7, the MN configures the same addresses in different interfaces. When the LMA receives the packet sent to the MN, it only needs to judge which tunnel has the highest priority and then sends the packets to the MAG with the highest IFP. However, the address option and routing header are not needed because the HoA is just the primary HoA of the MN. 6. Use cases Based on the extension defined in this document, the MN can connect to the PMIPv6 network with multiple interfaces. In this section, the following three typical use cases are presented. For simplicity, we illustrate them in the Unique Prefix per Interface scenario. Zhang et al. Expires December,2010 [Page 9] Internet-Draft Address option based mulif in PMIPv6 March 2010 6.1. Multihoming support In this use case, the MN is configured with two interfaces (e.g., IF1 and IF2) and their corresponding MAGs are MAG1 and MAG2. The following signaling flow is the attachments of IF1 and IF2, and then the MN communicates using the two interfaces simultaneously. +-----+ +-----+ +-----+ +-----+ | MN | | MAG1| | LMA | | MAG2| +-----+ +-----+ +-----+ +-----+ IF1 IF2 | | | 1) |----- Rtr Sol------->| | | | (IF1 attachment) |------- PBU ----->| | 2) | | | Accept PBU | | | | (Allocate HNP1, Setup BCE and Tunnel1) | | |<------ PBA ------| | |<------ Rtr Adv -----| (HNP1) | | | | | | | 3) |<========data========|<=====data========| | | | | | | 4) | |------------- Rtr Sol ( IF2 attachment) --------------->| | | | |<----- PBU -------| | | | | | 5) | | | Accept PBU | | | (Allocate HNP2, Create and Update BCE and Setup Tunnel2) | | | | | | | | |------- PBA ----->| | | | | (HNP1) | | |<-------------------- Rtr Adv ------------------------- | 6) |<========data========|<=====data========| | | | | |===data==========>| | | | |(Type2 routing header) | |<=========================data(Type2 routing header)====| Figure 8 multihoming procedure The procedure is listed as follows: 1) the MN attaches to the MAG1 through the IF1; 2) after the PBU and PBA exchange between MAG1 and LMA, the bi- directional tunnel is established between them. Then the MAG1 send the allocated HNP1 to IF1; Zhang et al. Expires December,2010 [Page 10] Internet-Draft Address option based mulif in PMIPv6 March 2010 3) then the primary HoA is configured by HNP1. The upper layer application is established using the primary HoA. Because the MN only activates the IF1 at this moment, the packets to and from the MN are transmitted using the primary HoA directly 4) the MN attaches to the MAG2 using the IF2; 5) after the PBU and PBA exchange between MAG2 and LMA, the bi- directional tunnel is established between them. Then the MAG2 send the allocated HNP2 to IF2; 6) because the IFP1 equals to the value of IFP2 in the multihoming case. The IF1 and IF2 are used to transmit packets simultaneously. For the packets sent to IF1, they are sent following the basic PMIPv6 specification. However, for the packets sent to IF2, the primary HoA (e.g., HoA1) is carried in the Primary HoA option and Type2 routing header by MN and LMA, separately. 6.2. Inter-technology handover support During the inter-technology handover, the MN transfers the traffic from one interface to another one. Figure 6 shows the inter- technology handover procedure. +-----+ +-----+ +-----+ +-----+ | MN | | MAG1| | LMA | | MAG2| +-----+ +-----+ +-----+ +-----+ IF1 IF2 | | | 1) |<=================data==================|======data=======>| | | | |======data=======>| | | | |(Type2 routing header) | |<=================data(Type2 routing header)============| | | | | | 2) | |-- HI-------------------------------------------------->| | (IFP2>IFP1) | | | 3) | | | |<--- PBU ---------| | | | |-- PBA ---------->| 4) | | | |======data=======>| | | | |(Type2 routing header) | |<===============data(Type2 routing header)==============| Figure 9 Inter-technology handover procedure The procedure is listed as follows: 1) at the beginning, the MN communicates in the multihoming manner. Zhang et al. Expires December,2010 [Page 11] Internet-Draft Address option based mulif in PMIPv6 March 2010 2) when the vertical handover from IF1 to IF2 is triggered, the MN sends the Handover Indication (HI) message to the MAG2 from IF2. The format of this message is not confined in this document. It may be a neighbor advertisement (NA) message or other upper layer signaling message. However, the IFP settings should be contained in this HI signaling. In our example, we assume that the IFP2 is bigger than IFP1 in the HI message. 3) after the PBU and PBA exchange between MAG2 and LMA, the binding state is refreshed with the new IFP settings. 4) then the following packets are transmitted through the IF2, which has the higher IFP value. However, the HoA1 is carried in the extended option and routing header. 6.3. Flow mobility support For supporting flow mobility support, there is a need to support vertical handover scenario but setting the same IFP for a subset of interfaces. 7. Compatibility In order to make sure that our scheme can be deployed in any network architecture, its compatibility with other specifications must be considered. 7.1. With RFC 5213 When the MN is configured with only one interface, the HoA configured in that interface is just its primary HoA. Then all the packets to and from the MN are transmitted using this primary HoA and then the procedure is totally compatible with the RFC 5213. 7.2. With RFC 3775 When the MN enters the MIPv6 network, the mobility should be managed by itself. However, when the route optimization between CN is completed, the MN and CN can communicate with each other directly with the Home address option and Type2 routing header. The operations of the Home address option and Type2 routing header are just the same as in our scheme. 7.3. With RFC 5648 Based on the RFC 5648 [8], the multi-interface MN can register multiple care-of addresses (CoA) at the HA. For the packets Zhang et al. Expires December,2010 [Page 12] Internet-Draft Address option based mulif in PMIPv6 March 2010 transmission, the CoA with the highest priority is used. As specified in the RFC 5648, the MN can configure multiple addresses in multiple interfaces according to our scheme, and then the interface with the highest IFP is always used to transmit packets. However, the tunnel is used in RFC 5648 and the address-replacement is used in our scheme in order to guarantee that the packets arrive at the final destination of the MN (e.g., HoA in RFC 5648 and primary HoA in our scheme). In a word, they are two schemes to implement the multi- interface MN connectivity and just use the different packet transmission mechanisms. 8. Security Considerations In order to manage the multiple interfaces of the MN, the IFP and P should be synchronized between LMA and MN. Besides, the MN should actively set the values of IFP and P. Then the network must monitor the settings of the IFP and P in order to eliminate the malicious and unreasonable settings. 9. References [1] Gundavelli, et al., Proxy Mobile Ipv6, RFC5213, August 2008. [2] V. Devarapalli, et al., Multiple Interface Support with Proxy Mobile IPv6, draft-devarapalli-netext-multi-interface-support- 00.txt, March 2009. [3] M. Liebsch, et al., Transient Binding for Proxy Mobile IPv6, draft-ietf-mipshop-transient-bce-pmipv6-05.txt January 2010. [4] Y. Cui, et al., Simultaneous Multi-Access for PMIPv6 based on Single HNP Model, draft-cui-netext-sma-pmipv6-00.txt, October 2009. [5] Y. Han, et al., Network-controlled and Host-initiated Flow Management in PMIPv6, draft-han-netext-nchi-flowmngt-00.txt, December 2009. [6] M.Hui, et al., PMIPv6 Multihoming Extension and Synchronization in LMA and MAG, draft-hui-netext-multihoming-00.txt, October 2009. [7] David B. Johnson, Charles E. Perkins and Jari Arkko. Mobility Support in IPv6, RFC 3775, June 2004. [8] R. Wakikawa, V. Devarapalli, et al. Multiple Care-of Addresses Registration, RFC 5648, October 2009. Zhang et al. Expires December,2010 [Page 13] Internet-Draft Address option based mulif in PMIPv6 March 2010 Author's Addresses Hong-Ke Zhang, Zhi-Wei Yan, Hua-Chun Zhou, Si-Dong Zhang National Engineering Laboratory for NGIID Beijing Jiaotong University of China Phone: +861051685677 Email:hkzhang@bjtu.edu.cn 06120232@bjtu.edu.cn hchzhou@bjtu.edu.cn sdzhang@center.njtu.edu.cn Intellectual Property Statement 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. Full Copyright Statement Copyright (C) The IETF Trust (2010). 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 Zhang et al. Expires December,2010 [Page 14] Internet-Draft Address option based mulif in PMIPv6 March 2010 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang et al. Expires December,2010 [Page 15]