One document matched: draft-chan-dmm-distributed-mobility-anchoring-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="info"
docName="draft-chan-dmm-distributed-mobility-anchoring-06"
ipr="trust200902">
<front>
<title abbrev="mobility anchor switching">Distributed Mobility
Anchoring</title>
<author fullname="H Anthony Chan" initials="H" surname="Chan">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 3</street>
<city>Plano, TX 75024</city>
<country>USA</country>
</postal>
<email>h.a.chan@ieee.org</email>
</address>
</author>
<author fullname="Xinpeng Wei" initials="X" surname="Wei">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Xin-Xi Rd. No. 3, Haidian District</street>
<city>Beijing, 100095</city>
<country>P. R. China</country>
</postal>
<email>weixinpeng@huawei.com</email>
</address>
</author>
<author fullname="Jong-Hyouk Lee" initials="J" surname="Lee">
<organization>Sangmyung University</organization>
<address>
<postal>
<street>708 Hannuri Building</street>
<city>Cheonan 330-720</city>
<country>Korea</country>
</postal>
<email>jonghyouk@smu.ac.kr</email>
</address>
</author>
<author fullname="Seil Jeon" initials="S" surname="Jeon">
<organization>Instituto de Telecomunicacoes</organization>
<address>
<postal>
<street>Campus Universitario de Santiago</street>
<city>Aveiro 3810-193</city>
<country>Portugal</country>
</postal>
<email>seiljeon@av.it.pt</email>
</address>
</author>
<author fullname="Fred L. Templin" initials="F. L." surname="Templin">
<organization>Boeing Research and Technology</organization>
<address>
<postal>
<street>P.O. Box 3707</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>fltemplin@acm.org</email>
</address>
</author>
<date year="2015"/>
<area/>
<workgroup>DMM</workgroup>
<abstract>
<t>This document defines the solution
for mid-session switching of the IP prefix anchor
with distributed mobility anchoring. Without ongoing session requiring session continuity,
the IP prefix anchor can be moved to a new network of attachment by using the new IP prefix
allocated from the new network. With ongoing session,
the anchoring of the prior IP prefix may be relocated to the new network
to enable session continuity.</t>
</abstract>
</front>
<middle>
<!-- Introduction -->
<section anchor="intro" title="Introduction">
<t>A key requirement in distributed mobility management <xref
target="RFC7333"/> is to enable traffic to avoid traversing single
mobility anchor far from the optimal route. Recall that distributed
mobility management solutions do not make use of centrally deployed
mobility anchor <xref target="Paper-Distributed.Mobility"/>. As such, a
flow SHOULD be able to have its traffic changing from traversing one
mobility anchor to traversing another mobility anchor as the mobile node
moves, or when changing operation and management requirements call
for mobility anchor switching, thus avoiding non-optimal routes. This
draft proposes distributed mobility anchoring solutions.</t>
<t>The needs of IP-layer mobility support are diverse so that the use of
distributed anchoring may differ according to the needs.</t>
<t>A mobile node (MN) may be running a flow with its correspondent node
(CN) for which the source IP address of this flow belongs to MN's
network. That is, it is anchored to an access router (anchor) belonging
to MN's network. When there are multiple anchors, the flow may need to
select the anchor when it is initiated (<xref
target="sec:af-in-net-attach"/>). Using an anchor in MN's network has
the advantage that the packets can simply be forwarded according to the
forwarding table. The anchor may be in the MN's network when the flow
was initiated. As the MN moves from one network to another, IP address
no longer belongs to the new network. To order that the IP address of
the flow is in the new network different methods can be used dependent
on the needs of the flow. If the ongoing IP flow can cope with an IP
prefix/address change, the flow can be reiniated with a new IP address
anchored in the new network (<xref target="sec:changing-anchor"/>). On
the other hand, if the ongoing IP flow cannot cope with such change, the
IP address anchoring can be moved from the original network to the new
network (<xref target="sec:switching-anchor"/>).</t>
<!--
<t>
A mobile node (MN) may also be running a flow with its correspondent node (CN)
for which the source IP address of this flow does not belong to MN's network
(<xref target="sec:af-not-in-net-attach" />).
As the MN moves from one network to another,
an ongoing flow may continue to use the IP prefix/address of the original network
(<xref target="sec:keeping-anchor" />)
by routing the packets using indirection
(<xref target="sec:keeping-anchor-indirection" />).
It the route then becomes non-optimal,
the routes may be optimized
(<xref target="sec:keeping-anchor-indirection-optimization" />).
</t>
-->
</section>
<!-- Conventions and definitions -->
<section title="Conventions and Terminology">
<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"/>.</t>
<t>All general mobility-related terms and their acronyms used in this
document are to be interpreted as defined in the Mobile IPv6 base
specification <xref target="RFC6275"/>, the Proxy Mobile IPv6
specification <xref target="RFC5213"/>, and the DMM current practices
and gap analysis <xref target="RFC7429"/>. This includes terms such as
mobile node (MN), correspondent node (CN), home agent (HA), home address
(HoA), care-of-address (CoA), local mobility anchor (LMA), and mobile
access gateway (MAG).</t>
<t>In addition, this document uses the following term:</t>
<t><list style="hanging">
<t
hangText="Home network of an application session (or of an HoA):">the
network that has allocated the IP address (HoA) used for the session
identifier by the application running in an MN. An MN may be running
multiple application sessions, and each of these sessions can have a
different home network. <vspace blankLines="1"/></t>
<t hangText="IP prefix/address anchoring:">An IP prefix, i.e., Home
Network Prefix (HNP), or address, i.e., Home Address (HoA),
allocated to a mobile node is topologically anchored to a node when
the anchor node is able to advertise a connected route into the
routing infrastructure for the allocated IP prefix. <vspace
blankLines="1"/></t>
<t
hangText="Internetwork Location Management (LM) function:">managing
and keeping track of the internetwork location of an MN. The
location information may be a binding of the IP advertised
address/prefix, e.g., HoA or HNP, to the IP routing address of the
MN or of a node that can forward packets destined to the MN. It is a
control plane function. <vspace blankLines="1"/> In a client-server
protocol model, location query and update messages may be exchanged
between a Location Management client (LMc) and a Location Management
server (LMs). <vspace blankLines="1"/> With separation of control
plane and data plane, the LM function is in the control plane. It
may be a logical function at the control plane node, control plane
anchor, or mobility controller. <vspace blankLines="1"/> It may be
distributed or centralized. <vspace blankLines="1"/></t>
<t hangText="Forwarding Management (FM) function:">packet
interception and forwarding to/from the IP address/prefix assigned
to the MN, based on the internetwork location information, either to
the destination or to some other network element that knows how to
forward the packets to their destination. <vspace blankLines="1"/>
This function may be used to achieve indirection. With separation of
control plane and data plane, FM may split into a FM function in the
data plane (FM-DP) and a FM function in the control plane (FM-CP).
<vspace blankLines="1"/> FM-DP may be distributed with distributed
mobility management. It may be a function in a data plane anchor or
data plane node. <vspace blankLines="1"/> FM-CP may be distributed
or centralized. It may be a function in a control plane node,
control plane anchor or mobility controller. <vspace
blankLines="1"/></t>
<!-- sm function (begin) -->
<t hangText="Security Management (SM) function:">The security
management function controls security mechanisms/protocols providing
access control, integrity, authentication, authorization,
confidentiality, etc. for the control plane and data plane. <vspace
blankLines="1"/> This function resides in all nodes such as control
plane anchor, data plane anchor, mobile node, and correspondent
node.</t>
<!-- sm function (end) -->
</list></t>
</section>
<!-- IP prefix/address anchored in current network of attachment (begin section) -->
<section anchor="sec:af-in-net-attach"
title="IP prefix/address anchored in current network of attachment">
<t>The deployment models of mobility management functions in the cases
introduced through the subsections are referred from
<xref target="I-D.templin-aerolink"/>
<xref target="I-D.sijeon-dmm-deployment-models"/></t>
<t>The IP prefix/address at the MN's side of a flow may be anchored at
the access router to which the MN is attached.</t>
<t>For example, when an MN attaches to a network (Net1) or moves to a
new network (Net2), it is allocated an IP prefix from that network. It
configures from this prefix an IP address which is typically a dynamic
IP address. It then uses this IP address when it a flow is initiated.
Packets to the MN in this flow are simply forwarded according to the
forwarding table.</t>
<!-- sm function (begin) -->
<!--
<t>
The security management function in the IP anchoring node
at a new network must assign a valid IP prefix to a mobile node.
In the example,
the security management function
in the node anchoring address IP2
assigns the valid IP prefix for the mobile node.
</t>
-->
<!-- sm function (end) -->
<figure>
<preamble/>
<artwork><![CDATA[
Net1 Net2
+---------------+ +---------------+
|AR1 anchors IP1| |AR2 anchors IP2|
+---------------+ +---------------+
+---------------+ +---------------+
|MN(IP1): | |MN(IP2): |
|flow(IP2,...) | or |flow(IP2,...) |
+---------------+ +---------------+
]]></artwork>
<postamble>Figure 1. IP prefix/address anchored in network of
attachment. MN is attached to AR1 in Net1 where it has initiated a
flow using IP1 or has moved to AR2 in Net2 where it initiates a new
flow using IP2.</postamble>
</figure>
<t>There may be multiple IP prefixes/addresses to choose from. They may
be from the same access network or different access networks. The
network may advertise these prefixes with cost options <xref
target="I-D.mccann-dmm-prefixcost"/> so that the mobile node may choose
the one with the least cost. In addition, these IP prefixes/addresses
may be of different types regarding whether mobility support is needed
<xref target="I-D.dmm-ondemand-mobility-api"/>. A flow will need to
choose the appropriate one according to whether it needs IP mobility
support.</t>
<t>With on-demand mobility, IP mobility support is provided only when
needed instead of being provided by default.</t>
<!-- Changing to the new IP prefix/address (begin section) -->
<section anchor="sec:changing-anchor"
title="Changing to the new IP prefix/address">
<t>A straightforward choice of mobility anchoring is for a flow to use
the IP prefix of the network to which the MN is attached when the flow
is initiated <xref target="I-D.seite-dmm-dma"/>. This is shown in
Figure 2.</t>
<figure>
<preamble/>
<artwork><![CDATA[
Net1 Net2
+---------------+ +---------------+
|AR1 anchors IP1| |AR2 anchors IP2|
+---------------+ +---------------+
+...............+ move +---------------+
.MN(IP1): . =======> |MN(IP2): |
.flow(IP1,...) . |flow(IP2,...) |
+...............+ +---------------+
]]></artwork>
<postamble>Figure 2. Changing to the new IP prefix/address. MN
running a flow using IP1 in Net1 changes to running a flow using IP2
in Net2.</postamble>
</figure>
<t>When IP mobility is not provided to a specific flow, the flow may
use a new IP address acquired from a new network as the MN moves to
the new network.</t>
<t>Regardless of whether IP mobility is needed, if the flow has
terminated before the MN moves to a new network, the flow may
subsequently restart using the new IP address allocated from the new
network.</t>
<t>When session continuity is needed, even if a flow is ongoing as the
MN moves, it may still be desirable for the flow to change to using
the new IP prefix configured in the new network. The flow may then
close and then restart using a new IP address configured in the new
network. Yet such a change in flow may be using a higher layer
mobility support which is not in the scope of this document to change
the IP address of the flow.</t>
<t>In Figure 2, a flow initiated while the MN was in Net1 has
terminated before the MN moves to a new network Net2. After moving to
Net2, the MN uses the new IP prefix anchored in Net2 to start a new
flow. The packets may then be forwarded without requiring IP layer
mobility support.</t>
<t>The call flow is outlined in Figure 3.</t>
<figure>
<preamble/>
<artwork><![CDATA[
MN p-AR n-AR CN
|MN attaches to p-AR: | | |
|acquire MN-ID and profile | |
|--RS---------------->| | |
| | | |
|<----------RA(HNP1)--| | |
| | | |
Allocated prefix HNP1
IP1 address configuration
| | | |
|<-Flow(IP1,IPcn,...)-+--------------------------------------------->|
| | | |
|MN detach from p-AR | | |
|MN attach to n-AR | | |
| | | |
|--RS------------------------------>| |
| | | |
|<--------------RA(HNP2)------------| |
| | | |
Allocated prefix HNP2
IP2 address configuration
| | | |
|<-new Flow(IP2,IPcn,...)-----------+------------------------------->|
| | | |
]]></artwork>
<postamble>Figure 3. A flow uses the IP allocated from the network
at which the MN is attached when the flow is initiated.</postamble>
</figure>
<!-- sm function (begin) -->
<t>The security management function in the anchor node at a new
network must allow to assign a valid IP prefix/address to a mobile
node.</t>
<!-- sm function (end) -->
<t>When IP mobility is needed for a flow, the mobility support may be
provided by IP prefix anchor switching to the new network to be
described in <xref target="sec:switching-anchor"/> or by using other
mobility management methods (<xref
target="Paper-Distributed.Mobility.PMIP"/> and <xref
target="Paper-Distributed.Mobility.Review"/>) Then the flow may
continue to use the IP prefix from the prior network. Yet some time
later, the flow of a certain user application may be closed. If the
spplication is started again, the new flow may not need to use the
prior network address to avoid having to invoke IP mobility support.
This is the case when the use of a permanent IP prefix/address is not
needed. The flow may then use the new IP prefix in the network where
the flow is initiated. Routing is again kept simpler without employing
IP mobility and will remain so as long as the MN has not moved away
from that network.</t>
<t>The call flow in this case is outlined in Figure 4.</t>
<figure>
<preamble/>
<artwork><![CDATA[
MN p-AR n-AR CN
|MN attaches to p-AR: | | |
|acquire MN-ID and profile | |
|--RS---------------->| | |
| | | |
|<----------RA(HNP1)--| | |
| | | |
Allocated prefix HNP1
IP1 address configuration
| | | |
|<-Flow(IP1,IPcn,...)-+--------------------------------------------->|
| | | |
|MN detach from p-AR | | |
|MN attach to n-AR | | |
| | | |
|--RS------------------------------>| |
HNP2 anchor switching to n-AR to be described in next sub-section
|<--------------RA(HNP2,HNP1)---------| |
| | | |
|<-Flow(IP1,IPcn,...)---------------+------------------------------->|
| | | |
Allocated prefix HNP2
IP2 address configuration
| | | |
Flow(IP1,IPcn) teminates
| | | |
|<-new Flow(IP2,IPcn,...)-----------+------------------------------->|
| | | |
]]></artwork>
<postamble>Figure 4. A flow uses the IP allocated from the network
at which the MN is attached when the flow is initiated.</postamble>
</figure>
<!-- Changing to a new IP prefix/address (end section) -->
</section>
<!-- IP prefix/address anchor switching to the new network (begin section) -->
<section anchor="sec:switching-anchor"
title="IP prefix/address anchor switching to the new network">
<t>The IP prefix/address anchor may move without changing the IP
prefix/address of the flow.</t>
<figure>
<preamble/>
<artwork><![CDATA[
Net1 Net2
+---------------+ +---------------+
|LM:IP1<-->IPar2| |LM:IP1<-->IPar2|
|FM:DHCPv6-PD | | |
|---------------| move |---------------|
|AR1 anchors IP1| =======> |AR2 anc IP1,IP2|
+---------------+ +---------------+
+...............+ +---------------+
.MN(IP1): . move |MN(IP1,IP2): |
.flow(IP1,...) . =======> |flow(IP1,...) |
+...............+ +---------------+
]]></artwork>
<postamble>Figure 5. IP prefix/address anchor switching to the new
network. MN with flow using IP1 in Net1 continues to run the flow
using IP1 as it moves to Net2.</postamble>
</figure>
<t>As an MN with an ongoing session moves to a new network, the flow
may preserve session continuity by moving the original IP
prefix/address of the flow to the new network. An example is in the
use of BGP UPDATE messages to change the forwarding table entries as
described in <xref target="I-D.mccann-dmm-flatarch"/> and also for
3GPP Evolved Packet Core (EPC) network in <xref
target="I-D.matsushima-stateless-uplane-vepc"/>.</t>
<t>The security management function in the anchor node at a new
network must allow to assign the original IP prefix/address used by
the mobile node at the previous (original) network. As the assigned
original IP prefix/address is to be used in the new network, the
security management function in the anchor node must allow to
advertise the prefix of the original IP address and also allow the
mobile node to send and receive data packets with the original IP
address.</t>
<t>The security management function in the mobile node must allow to
configure the original IP prefix/address used at the previous
(original) network when the original IP prefix/address is assigned by
the anchor node in the new network. The security management function
in the mobile node also allows to use the original IP address for the
previous flow in the new network.</t>
<!-- Centralized control plane (begin section) -->
<section anchor="sec:switching-anchor-central-CP"
title="Centralized control plane">
<t>An example of IP prefix anchor switching is in the case where Net1 and
Net2 both belong to the same operator network with separation of
control and data planes (<xref
target="I-D.liu-dmm-deployment-scenario"/> and <xref
target="I-D.matsushima-stateless-uplane-vepc"/>), where the
controller may send to the switches/routers the updated information
of the forwarding tables with the IP addressing anchoring of the
original IP prefix/address at AR1 moved to AR2 in the new network.
That is, the IP address anchoring in the original network which was
advertising the prefix will need to move to the new network. As the
anchoring in the new network advertises the prefix of the original
IP address in the new network, the forwarding tables will be updated
so that packets of the flow will be forwarded according to the
updated forwarding tables. Figure 6 shows such a case where the
functions LM, FM-CP are centralized whereas the FM-DP's are
distributed.</t>
<figure>
<preamble/>
<artwork><![CDATA[
Net1 Net2
+----------------------------------------------------------------------+
| LM:IP1<-->IPar2 |
| FM-CP |
+----------------------------------------------------------------------+
+---------------+ +---------------+
|FM-DP:DHCPv6-PD| |FM-DP |
|---------------| move |---------------|
|AR1 anchors IP1| =======> |AR2 anc IP1,IP2|
+---------------+ +---------------+
+...............+ +---------------+
.MN(IP1): . move |MN(IP1,IP2): |
.flow(IP1,...) . =======> |flow(IP1,...) |
+...............+ +---------------+
]]></artwork>
<postamble>Figure 6. IP prefix/address anchor switching to the
new network and with LM and FM-CP in a centralized control plane
whereas the FM-DP's are distributed.</postamble>
</figure>
<t>The call flow in Figure 7 shows that MN is allocated HNP1 when it
attaches to the p-AR. A flow running in MN may or may not need IP
mobility. If it does, it may continue to use the previous IP prefix.
If it does not, it may use a new IP prefix allocated from the new
network.</t>
<figure>
<preamble/>
<artwork><![CDATA[
MN p-AR n-AR DHCP Servers CN
|MN attaches to p-AR: | | | |
|acquire MN-ID and profile | | |
|--RS---------------->| | | |
|<----------RA(HNP1)--| | | |
| | | Allocate MN-HNP1 |
IP addr config | | | |
| | | | |
|<-Flow(IP1,IPcn,...)-+--------------------------------------------->|
| | | | |
|MN detach from p-AR | | | |
|MN attach to n-AR | | | |
| | | | |
|--RS------------------------------>| | |
| | | | |
| |------DHCPv6 release-------------->| |
| | | | |
| | |--DHCPv6 PD request->| |
| | |<-DHCPv6 PD reply--->| |
| | | | |
| BGP route updates | |
| | | | |
|<--------------RA(HNP2,HNP1)-------| | |
| | | Allocate MN-HNP2 |
IP addr config | | | |
| | | | |
|<-Flow(IP1,IPcn,...)---------------+------------------------------->|
| | | | |
| Flow(IP1,IPcn,...) terminates | | |
| | | | |
| | DHCPv6-PD timeout | |
| | | | |
| BGP route updates | |
| | | | |
| | | | |
|<-new Flow(IP2,IPcn,...)-----------+------------------------------->|
| | | | |
]]></artwork>
<postamble>Figure 7. DMM solution. MN with flow using IP1 in Net1
continues to run the flow using IP1 as it moves to
Net2.</postamble>
</figure>
<t>As the MN moves from p-AR to n-AR, the p-AR as a DHCP client may
send a DHCP release message to release the HNP1. It is now necessary
for n-AR to learn the IP prefix of the MN from the previous network
so that it will be possible for Net2 to allocate both the previous
network prefix and the new network prefix. The network may learn
the previous prefix in different methods.
For example, the MN may provide its
previous network prefix information by including it to the RS
message <xref target="I-D.jhlee-dmm-dnpp"/>.</t>
<t>Knowing that MN is using HNP1, the n-AR sends to a DHCP server a
DHCPv6-PD request to move the HNP1 to n-AR. The server sends to n-AR
a DHCPv6-PD reply to move the HNP1. Then BGP route updates will take
place here.</t>
<t>In addition, the MN also needs a new HNP in the new network. The
n-AR may now send RA to n-AR, with prefix information that includes
HNP1 and HNP2. The MN may then continue to use IP1. In addition, the
MN is allocated the prefix HNP2 with which it may configure its IP
addresses. Now for flows using IP1, packets destined to IP1 will be
forwarded to the MN via n-AR.</t>
<t>As such flows have terminated and DHCP-PD has timed out, HNP1
goes back to Net1. MN will then be left with HNP2 only, which it
will use when it now starts a new flow.</t>
</section>
<!-- Centralized control plane (end section) -->
<!-- Hierarchical network (begin section) -->
<section anchor="sec:switching-anchor-hierarchical-network"
title="Hierarchical network">
<t>A hierarchy may also exist as shown the Figure 8. Here the IP
prefix allocated to the MN is anchored at an edge router (ER)
supporting multiple access routers to which the MN may be attached.
Mobility of the MN involving change of AR but not of ER may be
accomplished using tunneling between the ER and the AR or using some
other L2 mobility mechanism.</t>
<figure>
<preamble/>
<artwork><![CDATA[
Net1 Net2
+----------------------------------------------------------------------+
| LM:IP1<-->IPar2 |
| FM-CP |
+----------------------------------------------------------------------+
+---------------+
|FM-DP |
|---------------|
|ER1 anchors IP1|
+---------------+
+---------------+ +---------------+
|FM-DP | |FM-DP |
|---------------| move |---------------|
|AR1 | =======> |AR2 |
+---------------+ +---------------+
+...............+ +---------------+
.MN(IP1): . move |MN(IP1) |
.flow(IP1,...) . =======> |flow(IP1,...) |
+...............+ +---------------+
]]></artwork>
<postamble>Figure 8. Mobility without involving change of IP
anchoring in a network with hierarchy in which the IP prefix
allocated to the MN is anchored at an Edge Router supporting
multiple access routers to which the MN may connect
to.</postamble>
</figure>
<t>The mobility event shown in Figure 9 involves a change of the IP
prefix anchoring. ER1 acting as a DHCP-PD client may exchange
message with the DHCP server to release the prefix IP1. Meanwhile,
ER2 acting as a DHCP-PD client may exchange message with the DHCP
server to delegate the prefix IP1 to ER2.</t>
<figure>
<preamble/>
<artwork><![CDATA[
Net1 Net2
+----------------------------------------------------------------------+
| LM:IP1<-->IPar2 |
| FM-CP |
+----------------------------------------------------------------------+
+---------------+
|FM-DP |
|---------------|
|GW |
+---------------+
+---------------+ +---------------+
|FM-DP:DHCPv6-PD| |FM-DP |
|---------------| move |---------------|
|ER1 anchors IP1| =======> |ER2 anc IP1,IP2|
+---------------+ +---------------+
+---------------+ +---------------+
|FM-DP | |FM-DP |
|---------------| |---------------|
|AR1 | |AR2 |
+---------------+ +---------------+
+...............+ +---------------+
.MN(IP1): . move |MN(IP1,IP2): |
.flow(IP1,...) . =======> |flow(IP1,...) |
+...............+ +---------------+
]]></artwork>
<postamble>Figure 9. Mobility involving change of IP anchoring in
a network with hierarchy in which the IP prefix allocated to the
MN is anchored at an Edge Router supporting multiple access
routers. to which the MN may connect to.</postamble>
</figure>
</section>
<!-- Hierarchical network (end section) -->
<!-- IP prefix/address anchor switching to the new network (end section) -->
</section>
<!-- IP prefix/address anchored in current of attachment (end section) -->
</section>
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>This document presents no IANA considerations.</t>
</section>
<section title="Contributors">
<t>This document has benefited from other work on mobility solutions
using BGP update, on mobility support in SDN network,
on providing mobility support only when needed,
and on mobility support in enterprise network.
These work have been referenced.
While some of these authors have taken the work to jointly write this document,
others have
contributed at least indirectly by writing these drafts. The latter
include Philippe Bertin, Dapeng Liu, Satoru Matushima, Peter McCann,
and Pierrick Seite.</t>
<t>Valuable comments have also been received from John Kaippallimil,
ChunShan Xiong, and Dapeng Liu.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
<?rfc include="reference.RFC.6275.xml" ?>
<?rfc include="reference.RFC.5213.xml" ?>
<?rfc include="reference.RFC.7333.xml" ?>
<?rfc include="reference.RFC.7429.xml" ?>
<!--
<?rfc include="reference.RFC.6241.xml" ?>
-->
<?rfc include="reference.I-D.mccann-dmm-prefixcost.xml"?>
<?rfc include="reference.I-D.dmm-ondemand-mobility-api.xml"?>
<?rfc include="reference.I-D.jhlee-dmm-dnpp.xml"?>
<?rfc include="reference.I-D.seite-dmm-dma.xml"?>
<?rfc include="reference.I-D.mccann-dmm-flatarch.xml"?>
<?rfc include="reference.I-D.liu-dmm-deployment-scenario.xml"?>
<?rfc include="reference.I-D.sijeon-dmm-deployment-models.xml"?>
<?rfc include="reference.I-D.matsushima-stateless-uplane-vepc.xml"?>
<?rfc include="reference.I-D.templin-aerolink.xml"?>
<!--
<?rfc include="reference.I-D.bernardos-dmm-cmip.xml"?>
<?rfc include="reference.I-D.bernardos-dmm-pmip.xml"?>
<?rfc include="reference.I-D.sarikaya-dmm-for-wifi.xml"?>
<?rfc include="reference.I-D.yhkim-dmm-enhanced-anchoring.xml"?>
-->
</references>
<references title="Informative References">
<reference anchor="Paper-Distributed.Mobility.Review">
<front>
<title>Distributed and Dynamic Mobility Management in Mobile
Internet: Current Approaches and Issues</title>
<author initials="H" surname="Chan">
<organization/>
</author>
<author initials="H" surname="Yokota">
<organization/>
</author>
<author initials="J" surname="Xie">
<organization/>
</author>
<author initials="P" surname="Seite">
<organization/>
</author>
<author initials="D" surname="Liu">
<organization/>
</author>
<date month="February" year="2011"/>
</front>
</reference>
<reference anchor="Paper-Distributed.Mobility">
<front>
<title>Distributed IP Mobility Management from the Perspective of
the IETF: Motivations, Requirements, Approaches, Comparison, and
Challenges</title>
<author initials="J" surname="Lee">
<organization/>
</author>
<author initials="J" surname="Bonnin">
<organization/>
</author>
<author initials="P" surname="Seite">
<organization/>
</author>
<author initials="H" surname="Chan">
<organization/>
</author>
<date month="October" year="2013"/>
</front>
<seriesInfo name="" value="IEEE Wireless Communications"/>
</reference>
<reference anchor="Paper-Distributed.Mobility.PMIP">
<front>
<title>Proxy Mobile IP with Distributed Mobility Anchors</title>
<author initials="H" surname="Chan">
<organization/>
</author>
<date month="December" year="2010"/>
</front>
<seriesInfo name=""
value="Proceedings of GlobeCom Workshop on Seamless Wireless Mobility"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:16:49 |