One document matched: draft-cui-netext-multihome-lr-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-cui-netext-multihome-lr-00" ipr="trust200902">
<front>
<title abbrev="Localized Routing for Multi-Home Mobile Node in PMIPv6">Localized Routing for Multi-Home Mobile Node in PMIPv6</title>
<author fullname="Yong Cui" initials="Y." surname="Cui">
<organization>Tsinghua University</organization>
<address>
<postal>
<street>Department of Computer Science, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6260-3059</phone>
<email>yong@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author fullname="Xin Xu" initials="X." surname="Xu">
<organization>Beijing University of Posts and Telecommunications</organization>
<address>
<postal>
<street>Department of Computer Science, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<email>xuxin1988@gmail.com</email>
</address>
</author>
<author fullname="Wendong Wang" initials="WD" surname="Wang">
<organization>Beijing University of Posts and Telecommunications</organization>
<address>
<postal>
<street>Room 609, teaching building 3,BUPT</street>
<city>Beijing</city>
<code>100876</code>
<country>P.R.China</country>
</postal>
<email>wdwang@bupt.edu.cn</email>
</address>
</author>
<author fullname="GuoYan Liu" initials="GY." surname="Liu">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 Zijinghua Rd.,Yuhuatai District</street>
<city>Nanjing</city>
<code>210012</code>
<country>P.R.China</country>
</postal>
<email>liu.guoyan@zte.com.cn</email>
</address>
</author>
<author fullname="ChunHui Zhu" initials="CH." surname="Zhu">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 Zijinghua Rd.,Yuhuatai District</street>
<city>Nanjing</city>
<code>210012</code>
<country>P.R.China</country>
</postal>
<email>zhu.chunhui@zte.com.cn</email>
</address>
</author>
<author fullname="Na Zhou" initials="N." surname="Zhou">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.68 Zijinghua Rd.,Yuhuatai District</street>
<city>Nanjing</city>
<code>210012</code>
<country>P.R.China</country>
</postal>
<email>zhou.na@zte.com.cn</email>
</address>
</author>
<date year="2013"/>
<workgroup>NETEXT Working Group</workgroup>
<abstract>
<t>In basic PMIPv6<xref target="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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.
</t>
<t>PMIPv6 is a protocol to provide IP mobility without MN participation.
<xref target="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.
</t>
<t>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.
</t>
</section>
<section title = "Requirements Language">
<t>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 <xref target="RFC2119">
</xref>.</t>
</section>
<section title="Scenario">
<t>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<xref target="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.</t>
<figure anchor="table_ex0" title="">
<artwork><![CDATA[
+----------+
| LMA |
+----------+
|
|
+----------+
| Router |
+----------+
/ | \
/ | \
/ | \
/ | \
+----------+ +---------+ +----------+
| MAG2 | | MAG1 | | MAG3 |
+----------+ +---------+ +----------+
\ / \ /
\ / \ /
\ / \ /
IF2 | | IF1 IF1 | | IF2
+-----------+ +-----------+
| MN1 | | MN2 |
+-----------+ +-----------+
]]></artwork>
</figure>
<section title="Case 1">
<t>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
</t>
<figure anchor="table_ex1" title="Case 1 - Signaling Call Flow">
<artwork><![CDATA[
+-----+ +-----+ +-- ---+ +------+ +------+ +------+
| 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
]]></artwork>
</figure>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section title="Case 2">
<figure anchor="table_ex3" title="Case 2 - Signaling Call Flow">
<artwork><![CDATA[
+-----+ +-----+ +-- ---+ +------+ +------+ +------+
| 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
]]></artwork>
</figure>
<t> 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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>This document does not include an IANA request.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.6705" ?>
<?rfc include="reference.I-D.ietf-netext-logical-interface-support" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:30:59 |