NETEXT Working Group Y. Cui Internet-Draft Tsinghua University Intended status: Standards Track X. Xu Expires: November 17, 2013 WD. Wang Beijing University of Posts and Telecommunications GY. Liu CH. Zhu N. Zhou ZTE Corporation May 16, 2013 Localized Routing for Multi-Home Mobile Node in PMIPv6 draft-cui-netext-multihome-lr-00 Abstract In basic PMIPv6[RFC5213], Local Mobility Anchor (LMA) should forward all traffic for the registered MN. Localized Routing (LR) for PMIPv6 proposed in [RFC6705] allows MN to exchange data directly by using localized forwarding or tunnel between the MAGs. But in some multi- access scenarios, it is apparently suboptimal. The present document proposes two localized routing mechanisms that are compatible with RFC 6705 for multi-access MNs which have some interfaces attached to the same MAGs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on November 17, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Cui, et al. Expires November 17, 2013 [Page 1] Internet-DrLocalized Routing for Multi-Home Mobile Node in PM May 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction With the development of internet access technologies and mobile terminal equipment, more and more hosts are operating in multiple network interfaces, the situation that a terminal access to multiple heterogeneous network domains simultaneously has become more widespread. PMIPv6 is a protocol to provide IP mobility without MN participation. [RFC5213] proposes three kinds of Localized Routing schemes which allow MNs to route traffic by using localized forwarding or creating a direct tunnel between MAGs to improve routing and reduce the load of LMA. Those three Localized Routing schemes are focus on Single- access scenario, as for Multiple-access scenario those schemes may be suboptimal. This document develops the mechanisms of RFC6705, and proposes two other localized routing mechanisms which are compatible with RFC 6705 for multi-access MNs Attached to the same MAGs with some interfaces. The mentioned mechanisms optimize the traffic transport among the interfaces attached to the same MAG; consequently, reduce transport costs and traffic loads at the network side. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Cui, et al. Expires November 17, 2013 [Page 2] Internet-DrLocalized Routing for Multi-Home Mobile Node in PM May 2013 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Scenario In this scenario, at least one of the two Mobile Nodes involved in communication has multiple interface access in PMIPv6 domain, and both of the two MNs have interfaces attached to the same MAG, as shown in Figure 1. Both MN1 and MN2 access to PMIPv6 domain via two interfaces, both MN1-IF1 and MN2-IF1 are attached to MAG1. We assume MN implements logical interface as defined in[I-D.ietf-netext-logical-interface-support], so that MN can adjust the uplink traffic sending interface according to the interface that the downlink traffic was received. +----------+ | LMA | +----------+ | | +----------+ | Router | +----------+ / | \ / | \ / | \ / | \ +----------+ +---------+ +----------+ | MAG2 | | MAG1 | | MAG3 | +----------+ +---------+ +----------+ \ / \ / \ / \ / \ / \ / IF2 | | IF1 IF1 | | IF2 +-----------+ +-----------+ | MN1 | | MN2 | +-----------+ +-----------+ Figure 1 3.1. Case 1 The LMA initiates a localized routing session by detecting both of the transport interfaces attached to the MAG that not connect with Correspondent nodes. For example the traffic that is transported between MN1-IF2 and MN2-IF2 in Figure 1. The Localized Routing for Cui, et al. Expires November 17, 2013 [Page 3] Internet-DrLocalized Routing for Multi-Home Mobile Node in PM May 2013 Multiple-Access Mobile Node is illustrated in Figure 2 +-----+ +-----+ +-- ---+ +------+ +------+ +------+ | MN1 | | MN2 | | MAG1 | | MAG2 | | MAG3 | | LMA | +-----+ +-----+ +------+ +------+ +------+ +------+ IF1 IF2 IF1 IF2 | | | | | | | | | | | | | |<------------data --------->|<--------data--------->| | | | |<------------data----------->|<---data--->| | | | | | | | +-----------+ | | | | | | | |LR decision| | | | | | | | +-----------+ | | | | |<---------LRI(Opt1)--------------| | | | | | |<-----LRI(Opt2)--------| | | | | | | |<-LRI(Opt3)-| | | | | |----------LRA(Opt4)------------->| | | | | | |------LTA(Opt5)------->| | | | | | | |-LRA(Opt6)->| | |--------------data--------->| | | | | |<---data----|<--data--| | | | | | |------------data------------>| | |<----data-------------|<-----------data----| | +------+ +------+ | | | | |update| |update| | | | | +------+ +------+ | | | | | | |<---data--->| | | | |<-----data----------->| | | | Opt1:MN1-ID, MN1-HNP1, MN1-HNP2, MN2-ID, MN2-HNP1, MN2-HNP2 Opt2:MN1-ID, MN1-HNP2, MAG1-IPv6-Address Opt3:MN2-ID, MN2-HNP2, MAG1-IPv6-Address Opt4:U=0, MN1-ID, MN1-HNP1, MN1-HNP2, MN2-ID, MN2-HNP1, MN2-HNP2 Opt5:U=0, MN1-ID, MN1-HNP1, MAG1-IPv6-Address Opt6:U=0, MN2-ID, MN2-HNP2, MAG1-IPv6-Address Figure 2: Case 1 - Signaling Call Flow LMA construct three LRI messages which are used to signal the intent of initiating localized routing. As for the two LRIs sent to the MAGs(MAG2, MAG3) connect with the interface that the session transports on. it contains the Home Network Prefix(HNP) and MN- Identifier(MN-ID) of the transport interfaces attached to the MAG, and Both LRIs contain the IP address of the objective MAG (MAG1) that both MNs attached to. As for the LRI sent to the objective MAG, it contains HNPs and MN-ID of the MNs involved. After receiving the LRI message, MAG verifies the attachment status of the MNs by checking the binding cache. When MAG (MAG2 and MAG3) Cui, et al. Expires November 17, 2013 [Page 4] Internet-DrLocalized Routing for Multi-Home Mobile Node in PM May 2013 detects that the LRI contains MAG IP address option, it creates a local forwarding entry and forwards the session through a tunnel associated with the remote MAG. When the MAG detects that the LRI contains no MAG IP address option but MN-ID option and a HNP option, it just updates the local route policy and forwards the session to the associated MNs. For example MAG1 forwards the packets that its destination address Prefix contains MN1-HNP1 and MN1-HNP2 to MN1-IF1. When the local process is over, MAG sends an LRA message for responding the LRI. Then the packets sent from MN1 to MN2 will take the path of MN1-IF2->MAG2->MAG1-> MN2-IF1, and the packets sent from MN2 to MN1 will take the path of MN2-IF2->MAG3->MAG1-> MN1-IF1. As MN received a session on a sub-interface different from the one that the session had sent, it treats this event as a flow mobility trigger signal from the network. Then MN updates the local router policy rules, so that the session's uplink was sent by the sub- interface that its downlink was received. So the transport path between MN1 and MN2 is MN1-IF1<->MAG1<->MN2-IF1. 3.2. Case 2 +-----+ +-----+ +-- ---+ +------+ +------+ +------+ | MN1 | | MN2 | | MAG1 | | MAG2 | | MAG3 | | LMA | +-----+ +-----+ +------+ +------+ +------+ +------+ IF1 IF2 IF1 IF2 | | | | | | | | | | | | | |<---------- data ---------->|<---------data-------->| | | |<---data--->|<-------------data--------------->| | | | | | | | +-----------+ | | | | | | | |LR decision| | | | | | | | +-----------+ | | | | |<----------LRI(Opt1)--------------| | | | | |-----------LRA(Opt2)------------->| | |------------ data---------->|----------data-------->| | | |<--- data---|<-------------data----------------| | | |----------->| | | | |<----data------------| | | | +------+ | | | | | | |update| | | | | | | +------+ | | | | | | | | |<---data--->| | | | |<------data--------->| | | | Opt1:MN1-ID, MN1-HNP1, MN1-HNP2, MN2-ID, MN2-HNP1, MN2-HNP2 Opt2:U=0, MN1-ID, MN1-HNP1, MN1-HNP2, MN2-ID, MN2-HNP1, MN2-HNP2 Figure 3: Case 2 - Signaling Call Flow Cui, et al. Expires November 17, 2013 [Page 5] Internet-DrLocalized Routing for Multi-Home Mobile Node in PM May 2013 Assumed that there is a session between MN1-IF2 and MN2-IF1, after LMA decision, LMA just creates an LRI message to the objective MAG(MAG1) that both of MNs attached to as illustrated in Figure 3. The Options that included in this LRI are the same as the ones included in the LRI sent to objective MAG in case1. When MAG1 receives the LRI, as in case1, MAG1 just updates the local route policy and forwards the packets to the associated MNs. Then the transport path from MN1 to MN2 remains unchanged, but the path from MN2 to MN1 changes, it directly forwards packets to the MNs by MAG1 without Traversing the LMA. It means that the transport from MN2 to MN will take the path of MN2-IF1->MAG1->MN1-IF1. As case1, when MN1 identified the downlink session arriving on the sub-interface is changed, it updates the local router policy rules, and then the packets sent from MN1 to MN2 will take the path of MN1-IF1->MAG1->MN2-IF1. 4. Security Considerations TBD 5. IANA Considerations This document does not include an IANA request. 6. Normative References [I-D.ietf-netext-logical-interface-support] Melia, T. and S. Gundavelli, "Logical Interface Support for multi-mode IP Hosts", draft-ietf-netext-logical- interface-support-07 (work in progress), April 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 6705, September 2012. Authors' Addresses Cui, et al. Expires November 17, 2013 [Page 6] Internet-DrLocalized Routing for Multi-Home Mobile Node in PM May 2013 Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6260-3059 Email: yong@csnet1.cs.tsinghua.edu.cn Xin Xu Beijing University of Posts and Telecommunications Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Email: xuxin1988@gmail.com Wendong Wang Beijing University of Posts and Telecommunications Room 609, teaching building 3,BUPT Beijing 100876 P.R.China Email: wdwang@bupt.edu.cn GuoYan Liu ZTE Corporation No.68 Zijinghua Rd.,Yuhuatai District Nanjing 210012 P.R.China Email: liu.guoyan@zte.com.cn ChunHui Zhu ZTE Corporation No.68 Zijinghua Rd.,Yuhuatai District Nanjing 210012 P.R.China Email: zhu.chunhui@zte.com.cn Cui, et al. Expires November 17, 2013 [Page 7] Internet-DrLocalized Routing for Multi-Home Mobile Node in PM May 2013 Na Zhou ZTE Corporation No.68 Zijinghua Rd.,Yuhuatai District Nanjing 210012 P.R.China Email: zhou.na@zte.com.cn Cui, et al. Expires November 17, 2013 [Page 8]