| NETEXT Working Group | Y. Cui |
| Internet-Draft | Tsinghua University |
| Intended status: Standards Track | X. Xu |
| Expires: February 07, 2014 | WD. Wang |
| Beijing University of Posts and Telecommunications | |
| GY. Liu | |
| CH. Zhu | |
| N. Zhou | |
| ZTE Corporation | |
| August 06, 2013 |
Localized Routing for Multi-Home Mobile Node in PMIPv6
draft-cui-netext-multihome-lr-00
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.
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 February 07, 2014.
Copyright (c) 2013 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 (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.
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.
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 [RFC2119].
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
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 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) 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 sub-interface 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.
+-----+ +-----+ +-- ---+ +------+ +------+ +------+
| 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
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. 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.
TBD
This document does not include an IANA request.
| [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. |
| [I-D.ietf-netext-logical-interface-support] | Melia, T. and S. Gundavelli, "Logical Interface Support for multi-mode IP Hosts", Internet-Draft draft-ietf-netext-logical-interface-support-06, October 2012. |