Internet DRAFT - draft-cui-netext-multihome-lr
draft-cui-netext-multihome-lr
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]
