One document matched: draft-chan-dmm-distributed-mobility-anchoring-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!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" ipr="trust200902" docName="draft-chan-dmm-distributed-mobility-anchoring-00">
<front>
<title abbrev="mobility anchor switching">Enhanced Mobility Anchoring</title>
<author initials="H" surname="Chan" fullname="H Anthony 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>
<date year="2015"></date>
<area></area>
<workgroup>DMM</workgroup>
<abstract>
<t>
This document defines
the mobility management protocol solutions
in the context of a distributed mobility management deployment.
Such solutions consider the problem of assigning a mobility anchor
and a gateway at the initiation of a session.
In addition, the mid-session switching of the mobility anchor
in a distributed mobility management environment is considered.
</t>
</abstract>
</front>
<middle>
<!-- Introduction -->
<section anchor="intro" title="Introduction">
<t>
A key requirement in distributed mobility management
<xref target="I-D.ietf-dmm-requirements"/>
is to enable traffic to avoid traversing single mobility anchor
far from the optimal route.
Recent developments in research and standardization
with respect to future deployment models
call for far more flexibility in network function operation and management.
For example,
the work on service function chaining at the IETF (SFC WG)
has already identified a number of use cases for data centers.
Although the work in SFC is not primarily concerned with mobile networks,
the impact on IP-based mobile networks is not hard to see
as by now most hosts connected to the Internet do so over a wireless medium.
For instance,
as a result of a dynamic re-organization of service chain
a non-optimal route between mobile nodes may arise
if pme relies solely on centralized mobility management.
As discussed earlier in the distributed mobility management working group
(DMM WG)
this may also occur when the mobile node has moved such that
both the mobile node and the correspondent node
are far from the mobility anchor
via which the traffic is routed.
</t>
<t>
Recall that distributed mobility management solutions
do not make use of centrally deployed mobility anchor.
As such, an application session SHOULD be able to have its traffic
passing from one mobility anchor to another
as the mobile node moves,
or when changing operation and management (OAM) requirements
call for mobility anchor switching,
thus avoiding non-optimal routes.
This draft proposes enhanced mobility anchoring.
</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='Anchoring Function (AF):'>
allocation to a mobile node of an IP address,
i.e., Home Address (HoA),
or prefix,
i.e., Home Network Prefix (HNP)
topologically anchored by the advertising node.
That is, the anchor node is able to advertise a connected route
into the routing infrastructure for the allocated IP prefixes.
This is a basic function of a mobility anchor.
With separation of control plane and data plane,
this function may reside in a control plane anchor.
Then the anchor function performs the IP prefix or address allocation
and the route advertisement for an IP anchor in the data plane.
<vspace blankLines="1" />
</t>
<t hangText='Session anchoring:'>
A session or a flow is anchored to a node or nodes
when the packets of the flow traverse at least one such nodes.
<vspace blankLines="1" />
</t>
<t hangText='IP anchoring:'>
An IP address or prefix is typologically anchored to a node
by an anchor function.
The IP packet will travel along a route
which traverses that node.
The packet will also traverse that node
if the IP address does not change.
Yet the IP address is changed at another node
before it reaches that node,
it will be redirected with the new IP address
along a new route which may not traverse the original node.
<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).
With separation of control plane and data plane,
this function may reside in a control plane anchor.
<vspace blankLines="1" />
</t>
<t hangText='Forwarding Management (FM) function:'>
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" />
With separation of control plane and data plane,
FM may split
into a FM part in the control plane (FM-CP)
which may be a function in a control plane anchor or mobility controller
and a FM part in the data plane (FM-DP)
which may be the function of a data plane anchor.
</t>
</list>
</t>
</section>
<!-- Anchor Selection and Switching (begin section) -->
<section title="Anchor Selection and Switching">
<t>
When an IP prefix or address is topologically anchored to a node
(data plane node),
the anchor function will advertise connected route for it.
Then an IP packet with this IP address as its destination address
will be forwarded along a path
that traverses through this IP anchoring node.
</t>
<t>
When a session or flow is anchored to a node
(data plane node),
the packets of the flow
will traverse at least one such session anchoring node.
</t>
<t>
A session anchoring node
may differ from an IP anchoring node
for an IP address of the session.
</t>
<!--
<t>
When a packet of a session/flow
with the IP address used by that session
enters a node of session anchoring,
the node may change the IP address of that packet
such as in IP header encapsulation or rewriting.
Then the packet will then leave with a different IP address
in its outer IP header.
Therefore the packet may not traverse the node
to which the IP address of the session is anchored.
When such a packet
is forwarded along a route towards the IP anchoring node,
it may first traverse a node of session anchoring.
There, it may be encapsulated
so that the packet will then leave with a different IP address
in its outer IP header.
It then may not traverse the IP anchoring node
of the original IP address of the session/flow
but is redirected with the different IP address.
</t>
-->
<!-- IP anchoring in network of attachment (begin section) -->
<section anchor="sec:af-in-net-attach"
title="IP anchoring in network of attachment">
<t>
An IP prefix or address
may be anchored to the access router
to which the MN is attached.
</t>
<t>
For example,
when an MN attaches to a network
or moves to a new network,
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 starts a new application session (an IP flow).
Packets to the MN in this flow
simply follows the forwarding table
for as long as the MN stays in that network.
</t>
<t>
In this example,
the flow may have terminated
before the MN moves to a new network.
Otherwise,
the flow may close
and then restart using a new IP address configured
in the new network.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net1 Net2
+--------------+ +--------------+
|node anchoring| |node anchoring|
| address IP1 | | address IP2 |
+--------------+ +--------------+
+--------------+
|MN(IP2) |
|running |
|session IP2 |
+--------------+
]]></artwork>
<postamble>Figure 1. IP anchoring in network of attachment.</postamble>
</figure>
<!-- IP anchoring in network of attachment (end section) -->
</section>
<!-- IP anchoring not in network of attachment (begin section) -->
<section title="IP anchoring not in network of attachment">
<t>
An IP prefix or address
may be anchored to an access router
in a different network
to which the MN is attached.
The anchor function is then in a network
different from the network of attachment.
</t>
<t>
An example is in using a static IP address
which does not belong to the network of attachment.
</t>
<t>
Another example
when an MN moves to a new network is as follows.
The MN has an ongoing session
which was initialized in a prior network of attachment
using an IP address
belonging to the network where it was initialized
as was described in
<xref target="sec:af-in-net-attach" />.
When the session is unable to change its IP address
it may continue to use its original IP address
which is anchored not in the current network of attachment
but in the network where the original IP address belongs.
Mobility support is needed
to enable the ongoing session to use this original IP address.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net1 Net2
+--------------+ +--------------+
|node anchoring| |node anchoring|
| address IP1 | | address IP2 |
+--------------+ +--------------+
+--------------+
|MN(IP2) |
|running |
|session IP1 |
+--------------+
]]></artwork>
<postamble>Figure 2. IP anchoring not in network of attachment.</postamble>
</figure>
<!-- IP anchoring not in network of attachment (end section) -->
</section>
<!-- Changing IP anchoring in mid-session (begin section) -->
<section title="Changing IP anchoring in mid-session">
<t>
With the MN in the example in
<xref target="sec:af-in-net-attach" />
it may be desirable that
the flow can change to the new IP address configured
in the new network.
The packets of this flow may then follow the forwarding table
without requiring IP layer mobility support.
Yet the 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>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net1 Net2
+--------------+ +--------------+
|node anchoring| |node anchoring|
| address IP1 | | address IP2 |
+--------------+ +--------------+
+--------------+ +--------------+
|MN(IP1) with | move |MN(IP2) with |
|session over | =======> |session IP1 |
|IP1 | |changed to IP2|
+--------------+ +--------------+
]]></artwork>
<postamble>Figure 3. Changing IP anchoring.</postamble>
</figure>
<!-- Changing IP anchoring in mid-session (end section) -->
</section>
<!-- Moving IP anchoring in mid-session (begin section) -->
<section title="Moving IP anchoring in mid-session">
<t>
The IP anchoring may move
without changing the IP address of the flow.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net1 Net2
+--------------+ +--------------+
|node anchoring| move |node anchoring|
| address IP1 | =======> | address IP1 |
+--------------+ +--------------+
+--------------+ +--------------+
|MN(IP1) | move |MN(IP2) |
|running | =======> |running |
|session IP1 | |session IP1 |
+--------------+ +--------------+
]]></artwork>
<postamble>Figure 4. Moving IP anchoring.</postamble>
</figure>
<t>
As an MN with an ongoing session
move to a new network,
the session may preserve session continuity
by moving the IP anchoring
of its original IP address to the new network.
Then the IP anchoring
which was advertising the prefix in the original network
will need to move to the new network.
As the IP anchoring in the new network
advertises the prefix of the session
in the new network,
the forwarding tables will be updated
so that packets of the ongoing session
will follow the updated forwarding tables.
</t>
<!-- Moving IP anchoring in mid-session (end section) -->
</section>
<!-- Anchoring a session (begin section) -->
<section title="Anchoring a session ">
<t>
As an MN with an ongoing session
move to a new network,
the session may use the original IP address for session continuity
by anchoring the session to some nodes
(data plane nodes)
and redirecting the packets of this session
to traverse through these session anchoring nodes.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net3
+--------------+
Net1 |node anchoring| Net2
+--------------+ /|address of CN | +--------------+
| anchoring| / +--------------+ | anchoring|
| session | / | session |
| identified | / +--------------+ | identified |
| with IP1 | / | CN | | with IP1 |
| | / +--------------+ | |
|session IP1 | / |session IP1 |
|--> addr AR2 | / |--> MN |
|--------------| / |--------------|
|node anchoring|<- |AR2 anchoring|
| address IP1 | ------------------------------------>| address IP2 |
+--------------+ +--------------+
+--------------+ +--------------+
|MN(IP1) | move |MN(IP2) |
|running | =======> |running |
|session IP1 | |session IP1 |
+--------------+ +--------------+
]]></artwork>
<postamble>Figure 5. Session anchoring.</postamble>
</figure>
<t>
For example,
a first node to anchor the session
may be at the IP anchoring
of the original IP address in the original network.
A second node to anchor the session
may be in the new network.
Then packets of this session traverse
the session anchoring
in both the original network
and the new network.
Forwarding management function at these nodes
may be used to direct the flow to traverse them.
</t>
<t>
The session's packets from the CN to the MN
will then first be forwarded to the IP anchoring node
in the original network
where it is intercepted by the first session anchoring node.
The session anchoring node
may possess fowarding management function
to forward the packets
to the second session anchoring node in the new network.
</t>
<t>
In host-based mobility management,
the session may be anchored in the new network
to the MN itself.
</t>
<t>
In network-based mobility management,
the session may be anchored to an access router
to which the MN is attached in the new network
The access router may then forward the packet to the MN at L2.
</t>
<!-- Anchoring a session (end section) -->
</section>
<!-- Changing session anchoring in mid-session (begin section) -->
<section title="Changing session anchoring in mid-session">
<t>
The route of the packets of an ongoing session
traversing the original network
and the MN's new network of attachment
is not necessarily optimal.
It can be unneccessarily long
especially when the session anchoring nodes
are far from each other
even when the MN and CN are close to each other.
A shorter route results
when the session is anchored
in both the CN's network and the MN's network.
An example to achieve this
is to move the session anchoring from the original network
to the CN's network.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
0123456789012345678901234567890123456789012345678901234567890123456789
Net3
+--------------+
| anchoring|
| session |
| identified |
| with IP1 |
| |
..>|session IP1 |
. |--> addr AR2 |
. |--------------|
Net1 . |node anchoring| Net2
+--------------+ . |address of CN |\ +--------------+
| anchoring| . +--------------+ \ | anchoring|
| session | . \ | session |
| identified | . +--------------+ \ | identified |
| with IP1 |. | CN | \ | with IP1 |
| | +--------------+ \ | |
|session IP1 | \ |session IP1 |
|--> addr AR2 | \ |--> MN L2 addr|
|--------------| \ |--------------|
|node anchoring| ->|AR2 anchoring|
| address IP1 | | address IP2 |
+--------------+ +--------------+
+--------------+ +--------------+
|MN(IP1) | move |MN(IP2) |
|running | =======> |running |
|session IP1 | |session IP1 |
+--------------+ +--------------+
]]></artwork>
<postamble>Figure 6. Changing session anchoring.</postamble>
</figure>
<!-- Changing session anchoring in mid-session (end section) -->
</section>
<!-- Anchor Selection and Switching (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>
</middle>
<back>
<references title="Normative References">
&rfc2119;
<?rfc include="reference.I-D.ietf-dmm-requirements.xml"?>
<?rfc include="reference.RFC.6275.xml" ?>
<?rfc include="reference.RFC.5213.xml" ?>
<?rfc include="reference.RFC.6241.xml" ?>
<?rfc include="reference.RFC.7429.xml" ?>
<?rfc include="reference.I-D.seite-dmm-dma.xml"?>
<?rfc include="reference.I-D.yokota-dmm-scenario.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.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:17:46 |