One document matched: draft-seite-mext-dma-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'>
]>
<rfc category="info" ipr="trust200902" docName="draft-seite-mext-dma-00.txt">
<?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" ?>
<front>
<title>Dynamic Mobility Anchoring</title>
<author initials="P." surname="Seite" fullname="Pierrick Seite">
<organization>France Telecom - Orange</organization>
<address>
<postal>
<street>4, rue du Clos Courtel, BP 91226</street>
<city>Cesson-Sevigne</city>
<code>35512</code>
<country>France</country>
</postal>
<email>pierrick.seite@orange.com</email>
</address>
</author>
<author initials="P." surname="Bertin" fullname="Philippe Bertin">
<organization>France Telecom - Orange</organization>
<address>
<postal>
<street>4, rue du Clos Courtel, BP 91226</street>
<city>Cesson-Sevigne</city>
<code>35512</code>
<country>France</country>
</postal>
<email>philippe.bertin@orange.com</email>
</address>
</author>
<date month="November" year="2011"/>
<abstract>
<t>
Most existing IP mobility solutions are derived from Mobile IP principles where a given mobility anchor
maintains Mobile Nodes (MNs) binding up-to-date. Data traffic is then encapsulated between the mobility anchor and the MN
or its Access Router.
These approaches are usually implemented on a centralised architectures where both MN context
and traffic encapsulation need to be processed at a central
network entity, i.e. the mobility anchor.
However, one of the trend in mobile network evolution is to "flatten" mobility architecture by confining mobility support
in the access network, e.g. at the access routers level,
keeping the rest of the network unaware of the mobility events and their support.
This document discusses the deployment of a Proxy Mobile IP approach in such a flat architecture.
The solution allows to dynamically distribute mobility functions among access routers.
The goal is also to dynamically adapt the mobility support of the MN’s needs by applying traffic redirection only to MNs’ flows
when an IP handover occurs.
</t>
</abstract>
</front>
<middle>
<section title="Terminology">
<t> Proxy Mobile IPv6 inherited terminology
<vspace blankLines="1" />
<list style='empty'>
<t>
The following terms used in this document are to be interpreted as defined in the Proxy Mobile IPv6 specification <xref target="RFC5213"/>; Mobile Node (MN), ome Network Prefix (HNP), Mobile Node Identifier (MN-Identifier), Proxy Binding Update (PBU),
and Proxy Binding Acknowledgement (PBA).
</t>
</list>
</t>
<t> Mobility capable Access Router (MAR)
<vspace blankLines="1" />
<list style='empty'>
<t> The Mobility capable Access Router is an access router which provides mobility management functions. It has both mobility anchoring and
location update functional capabilities. A Mobility capable Access Router can act
as a Home or as a Visited Mobility capable Access Router (respectively H-MAR and V-MAR). Any given MAR could act
both as H-MAR and V-MAR for a given mobile node having different HNPs, either allocated by this MAR
(H-MAR role) or another MAR on which the mobile node was previously attached (V-MAR role).
<vspace blankLines="1" />
<list style='symbols'>
<t> H-MAR: it allocates HNP for mobile nodes. Similarly to <xref target="RFC5213"/>, the H-MAR is the topological anchor point for
the mobile node's home network prefix(es) it has allocated. The H-MAR acts as a regular IPv6 router for
HNPs it has allocated, and when a mobile node has moved away and attached to a V-MAR, the H-MAR is responsible for:
tracking the mobile node location (i.e. the V-MAR where the mobile node is currently attached), and forwarding
packets to the V-MAR where the mobile node is attached.
</t>
<t> V-MAR: it manages the mobility-related signaling for a mobile node, using a HNP allocated by a MAR previously visited by the mobile node, that is
attached to its access link.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Introduction">
<t>
Most existing IP mobility solutions are derived from Mobile IP <xref target="RFC3775"/> principles where a given mobility agent (e.g. the Home Agent (HA)
in Mobile IP or the
Local Mobility Agent (LMA) in Proxy Mobile IPv6 <xref target="RFC5213"/>) maintains Mobile Nodes (MNs) bindings. Data traffic is then encapsulated between the MN
or its Access Router
(e.g. the Mobile Access Gateway (MAG) in PMIPv6) and its mobility agent.
These approaches lead to the implementation of centralised architectures where both MN context and traffic encapsulation need to be maintained at a central
network entity, the mobility agent. Thus, when hundreds of thousands of MNs are communicating in a given cellular network, such a centralised network entity causes
well-known bottlenecks and single point of failure issues, which requires costly network dimensioning and engineering to be fixed. In addition, tunnelling
encapsulations impact the overall network efficiency since they require the maintenance of MN's specific contexts in each tunnel end nodes and they incur delays
in packet processing and transport functions.
Such centralised approach provides the ability to route MN traffic whatever its localisation is, as well as to support handovers when it moves from
access router to access router.
</t>
<t>
It is however well established that a huge amount of mobile communications are set up while the user is not physically moving, i.e. its MN stays
in the same radio cell. For example, the user is being communicating at home, in his office, at a café... Applying the aforementioned centralised principles
leads then to aggregate user’s contexts and traffic at a central node in the network for the sake of mobility support whereas the MN remains motionless.
As this leads to the introduced scalability and performances issues, alternative approaches may consider a way to better adapt mobility support in the network
to cope with MN’s movements and its ongoing traffic flows’ requirements. Typically, one of the trend in the evolution of mobile networks is to go on flat architecture
with the distribution of network functions, including mobility functions <xref target="I-D.liu-distributed-mobility"/>.
According to this principle, <xref target="I-D.chan-netext-distributed-lma"/> proposes a deployment of Proxy Mobile IPv6 in a flat
architecture by splitting the location management and routing functions of the LMA.
</t>
<t>
In this document, we propose a slightly different approach by dynamically distributing mobility handling among terminals and access routers.
This document inherits from concepts introduced in <xref target="NTMS2008"/>. The goal is twofold:
<list style='symbols'>
<t>dynamically adapting mobility support to each of the MN’s needs by applying traffic redirection only to MNs’ flows that are already established when an IP handover occurs;</t>
<t>confining the mobility support at the access routers level, keeping the rest of the network unaware of mobility events and their support. </t>
</list>
</t>
</section>
<section title="Basics of Dynamic Mobility Anchoring">
<t>
In a standard IPv6 network without specific mobility support, any host is able to set up communications flows using a global IPv6 address
acquired with the support of its current access router <xref target="RFC4862"/>. When the host moves from this access router
to a new one, its ongoing IP sessions cannot be maintained without leveraging on IP mobility mechanisms.
</t>
<t>
However, once attached to the new access router, the host can again acquire a routable global IPv6 address to be used for any new communication flow
it sets up. Hence, a flow based mobility support may be restricted to provide traffic indirection to host’s flows that are already ongoing
during host’s handovers between access routers.
Any new flow being set up uses the new host’s global address acquired on the new link available after the handover.
</t>
<t>
When a multiple-interface host moves between access routers of different access technologies, such a simple approach can also be applied,
considering that each network interface provides dynamically global IPv6 addresses acquired on current access routers.
Flows mobility is then required only to support the necessary traffic indirection from the access router on which the flow
has been initially set up to the access router the host is currently attached.
Such IP based indirection can even be made independent from access technologies types, providing thus inherent inter-access mobility facilities.
</t>
<t>
Hence, any given IP flow can be considered as implicitly anchored on the current MN’s access router when being set up.
While the MN is attached to its initial access router, the IP flow is delivered as for any standard IPv6 node.
The anchoring function at the access router is thus needed only to manage traffic indirection if the MN moves to a new access router
(and for subsequent movements while the IP flow remains active), maintaining the flow communication until it ends up.
</t>
<t>
Any flow’s incoming packet toward the MN is routed in a standard way to the access router anchoring the flow as the packet contains the destination IP address issued from router prefix.
Then, if the MN is currently attached to the initial anchor access router, the incoming packet is directly delivered over the access link.
Otherwise, the anchoring access router needs to redirect the packet to the current (or one of the currents) MN’s access router(s).
</t>
<t>
Any flow’s outgoing packet from the MN is sent over either the initial anchor access router link or another access router link it
is currently using.
In the first case, the packet can be routed in a standard way, i.e., without requiring networks mobility support functions.
In the second case, we consider its redirection
to the initial flows’ anchor router, but it may be noticed that direct routing by the current access router may be also allowed
(yet this may lead to more stringent security and policy considerations).
</t>
</section>
<section title="Solution Overview">
<section anchor="sct.dma" title="Dynamic Mobility Anchoring">
<t>
The basic idea is to distribute mobility traffic management
with dynamic user's traffic anchoring in access network nodes. The solution relies on a very simple flat architecture outlined in
<xref target="fig.dma.archi"/> where the Mobility capable Access Router (MAR) supports both traffic anchoring and MN's location management functionalities. The architecture relies on a centralized database storing ongoing mobility sessions for the MNs (see <xref target="sect.call.flow"/> for details). This database stores the HNPs currently allocated to the MN and their respective anchoring point. This database could be an extension to the policy store used in <xref target="RFC5213"/>.
<figure anchor="fig.dma.archi" title="Architecture for Distributed Mobility Anchoring">
<artwork align="center">
<![CDATA[
+------------+
| session DB |
/ +------------+
+----------/--------|------\--+
( IP /Network | \ )
+--------/----------|------- \+
/ | \
+-------+ +-------+ + ------+
| MAR1 |___| MAR2 |____| MAR3 |
+-------+ +-------+ +-------+
|
+-----+
| MN1 |
+-----+
]]>
</artwork>
</figure>
Regular IPv6 routing applies when an IP communication is initiated. For instance, if the mobile node (e.g. MN1),
being attached to MAR1, initiates a communication with CN1, the traffic will be routed through MAR1 without requiring any specific mobility operation.
When MN1 moves away from MAR1 and attaches to MAR3, the traffic remains anchored to MAR1 and is tunneled between MAR1 and MAR3. MAR1 becomes the mobility anchor, but only for traffic initiated by MN1 when it was attached to MAR1.
</t>
<t>
Communications newly initiated, e.g. to CN2, while the mobile node is attached to MAR3 will be routed in a standard way via MAR3.
So, MAR3 is both the mobility
anchor, i.e. the H-MAR, for traffic newly initiated (i.e. when the mobile node is attached to MAR3) and the V-MAR for traffic initiated
while being attached to MAR1.
If the mobile node moves away from MAR3, while maintaining
communications with both CN1 and CN2, two mobility anchors come into play: the data traffic will be anchored in MAR1 for communication with CN1 and
in MAR3 for communication with CN2.
Summarizing , it is proposed to locate mobility anchoring depending on where the flow is
initially created. Accordingly, communications are expected to be initiated without requiring mobility anchoring and tunneling.
</t>
<t>
With this solution, even if a mobile node is moving across several MARs, the tunnel endpoints are always on
the initial H-MAR and on the current V-MAR. In the case the mobile node moves from MAR1 to MAR2 then to MAR3, a tunnel will be firstly established between MAR1 and MAR2 to forward HNP1; then a tunnel between MAR1 and MAR3 will be established.
</t>
<t>
However such an architecture leads to new requirement on the HNP prefix model.
Actually, because the HNP is anchored to its mobility anchor (i.e. H-MAR), a dynamic mobility anchoring requires that each MAR
must advertise different per-MN prefixes set.
For example, if MN1 is anchored to both MAR1 and MAR3, these two mobility capable access routers would
advertise respectively HNP1 and HNP3 for MN1.
</t>
<figure anchor="fig.dma" title="Distributed Mobility Anchoring">
<artwork align="center">
<![CDATA[
_______ _______
| | | |
| CN1 | | CN2 |
|_______| |_______|
'. Flow#2 .
Flow#1 ' '. | Flow#3
' '...'''''''''''''.... .
..''' '. '''..
.' ' '.IP network . '.
: ' '. | :
'..' +-------+ . ..'
'''... | | ....'''
' | MAR2 | \ .
MAR1 Forwarding Table ' | | \ |
+=====================+ ' | |'. \ .
HNP-1::/64 -> MAR3 ' +-------+\'. \ |
+-------+ \ '+ ------+
| | \ | |
| MAR1 |-----------------| MAR3 |
| |'''''''''''''''''| |
| |-----------------| |
+-------+ +-------+
' ' |
Flow#1 ' . . Flow#3
' ' |
+-----+ Flow#2 +-----+
| MN1 | -----move-------> | MN1 |
+-----+ +-----+
(single interface, IF1)
]]>
</artwork>
</figure>
</section>
<section anchor = "sect.call.flow" title="Protocol sequence for handover management">
<t>
An example of handover management for a single interface mobile node is depicted on <xref target="fig.callflowDMA"/>. The mobile node, MN1, is assumed
to move from MAR1 to MAR2. Following are the main steps of the handover management process:
<vspace blankLines="1" />
<list style="numbers">
<t>
The mobile node, MN1, attaches to MAR1 which is responsible for allocating the MN-HNP, e.g. HNP1 for MN1.
</t>
<t>
Hence, the mobile node can initiate and maintain data transport sessions (with CN1 in the picture), using IP addresses derived from HNP1,
in a standard way while it remains attached to MAR1, i.e. mobility functions do not come into play.
</t>
<t>
The MN handoffs to MAR2 which will thus acts as V-MAR for HNP1. Fistly, MAR2 retrieves the ongoing MN's mobility sessions from the centralized sessions database; here only one mobility session is ongoing: (MN::NHP1,MAR1). Then MAR2 proceeds to location update for HNP1 with MAR1 (H-MAR role), i.e., PBU/PBA exchange between MAR2 and MAR1.
</t>
<t>
MAR2 also allocates new HNPs for MN1; these HNPs are meant to be used by application flows initiated after the handoff.
</t>
<t>
MAR1, playing the H-MAR role for HNP1, encapsulates MN1's traffic and tunnels it to the V-MAR, i.e. MAR2, where packets are decapsulated and delivered
to the MN.
</t>
<t>
The mobile node can initiate and maintain new data transport sessions, e.g. with CN2, using IP addresses derived from HNP2. This traffic is routed
in a standard way while the mobile node remains attached to MAR2.
</t>
</list>
</t>
<figure anchor="fig.callflowDMA" title="Handover management with Distributed Mobility Anchoring">
<artwork align="center">
<![CDATA[
MN1 MAR2 MAR1 CN1 CN2
| | | | |
| | | | |
L2 Attach | | | |
| | | | |
|----------------RS---------->| | |
| | | MAR1 allocates |
| | | and advertises HNP1
| | | MAR1 updates MN's
| | | mobility session
|<---------------RA-----------| up to the database
| | | | |
comm. to CN1 using HNP1 | | |
|<----------------data-flow#1--------->| |
| | | | |
handover | | | |
to MA2 | | | |
|-----RS----->| MAR2 allocates| | |
| | HNP2 for new communications |
| | and retrieve the anchoring point
| | from the centralized database |
| |----pBU------->| | |
| | | | |
| |<---pBA--------| | |
|<---RA-------| | | |
| | | | |
handover | | | |
completed | | | |
| | | | |
|<---flow#1 --|<===tunnel====>|------->| |
| | | | |
comm. to CN2 using HNP2 | | |
| | | | |
|<-----------------data-flow#2----------------->|
| | | | |
| | | | |
]]>
</artwork>
</figure>
</section>
<section title="Difference with Proxy Mobile IPv6">
<t>
A V-MAR is required to advertise new per-MN HNP set for new IP communications to be initiated, while Proxy Mobile IPv6 advertises the same HNPs
when roaming from MAG to MAG.
So, while Proxy Mobile IPv6 is based on the per-MN prefix model, this proposal leverages on a per-MN and per-MAR prefix model.
It is not required to statically allocate different set of HNPs per MAR.
Actually, at a given time, only active MARs for an MN (i.e. access routers on which the mobile node is currently attached to) need to
share the per-MN HNPs set.
So, for the sake of scalability, per-MN HNPs should be dynamically shared out among MN's active MARs.
</t>
<t>
Since each MAR anchors the IP traffic initiated when the mobile node was attached to it, a mobile node may be served simultaneously by more than one mobility anchor at the same time.
</t>
</section>
<section title="IP flow mobility support">
<t>
The distribution of mobility functions can also apply in the context of multiple-interfaces terminals and IP flow mobility.
In such a case, any given IP flow can be considered as implicitly anchored on the current host’s access router when set up.
Until the host does not move from the initial access router (H-MAR), the IP flow is delivered as for any standard IPv6 node.
The anchoring function at the H-MAR is thus managing traffic indirection only if one, or several, IP flow(s) are moved
to another interface, and for subsequent movements while the initial anchored flows remain active.
This anchoring is performed on a per-flow basis and
each H-MAR needs to track all possible V-MARs for a given host on the move.
The H-MAR must also manage different tunnels for a given mobile node providing that the node is multihomed and it simultaneously
processes different IP flows on its interfaces.
</t>
<t>
In the following, it is assumed that flow mobility consists in transferring a subset of prefixes from one access to another
(i.e. a given prefix is associated to a given IP flow).
This scenario is described in <xref target="I-D.jeyatharan-netext-multihoming-ps"/> and implemented in
<xref target="I-D.yokota-netlmm-pmipv6-mn-itho-support"/>. However, providing specific extensions to mobility signalling (extensions to be defined),
the solution could also matches the scenario where a same prefix is shared across multiple interfaces (scenario described in
<xref target="I-D.jeyatharan-netext-multihoming-ps"/> ). In this case, a prefix is still anchored to one MAR but
redirected IP flows are routed by the H-MAR using flow filtering mechanism.
</t>
<t>
Lets consider a simple example to illustrate the dynamic per-flow mobility anchoring.
<xref target="fig.dmaFlow"/> depicts the IP flow mobility management for a mobile node with two interfaces.
The IP data flows, Flow#1 and Flow#2, have been initiated on if1. Thus, Flow#1 and Flow#2, using respecively prefixes HNP1 and HNP2,
are anchored to MAR1.
Referring to the picture, Flow#1 has not been moved; so Flow#1 is delivered in a standard IPv6 way.
Flow#2 has been transferred from If1 to If2, so the the Flow#2 packets, corresponding to HNP2, are tunneled from MAR1 to MAR2.
In other words, MAR1 and MAR2 are respectively the H-MAR anchor and the V-MAR for flow#2.
</t>
<figure anchor="fig.dmaFlow" title="Distributed IF flow Mobility Anchoring ">
<artwork align="center">
<![CDATA[
_______ _______
| | | |
| CN1 | | CN2 |
|_______| |_______|
' .
Flow#1 ' | Flow#2
' ...'''''''''''''.... .
..''' '''..
.' ' IP network . '.
: ' | :
'..' . ..'
'''.....................'|'
' .
' |
' .- . - . - . - . - . - .
' |
+-------+ Flow#2 + ------+
| | tunneled | |
| MAR1 |-----------------| MAR2 |
|(H-MAR)| -.-.-.-.-.-.-.-.|(V-MAR)|
| |-----------------| |
+-------+ +----|--+
' .
Flow#1 ' | Flow#2
' .
' If1 +-----+ If2 |
''''''''''| MN | - . - .
+-----+
]]>
</artwork>
</figure>
<t>
In case of the handover of an IP flow, initially adressed to one interface, the mobile node must be able to process that traffic
also on the target interface. In order to meet that requirement, the mobile node could support the weak host model, as per
<xref target="RFC1122"/>, <xref target="I-D.bernardos-mif-pmip"/>. By supporting the weak host model, the
mobile node can accept traffic, addressed to one IP address, on any of its interfaces.
</t>
<t>
Another solution for the host to support the handover from one interface to another, is to hide the inter-access handover to layers above IP.
The mobile node can support this scenario by using a virtual IP interface. The applicability of that approach is discussed on
<xref target="I-D.bernardos-netext-ll-statement"/> and <xref target="I-D.yokota-netlmm-pmipv6-mn-itho-support"/> describes a
solution.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
TBD.
</t>
</section>
<section title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
<section title="Acknowledgements">
<t>
The authors would like to acknowledge Philippe Quenard and Carole Bonan who have implemented the solution decribed here.
The authors would also like to express their gratitude to Hidetoshi Yokota, Telemaco Melia, Dapeng Liu, Anthony Chan, Julien Laganier, Lucian Suciu, Servane Bonjour, Karine Guillouard and many others for having shared thoughts on the concept of distributed mobility.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.4862" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1122" ?>
<?rfc include="reference.RFC.3775" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.3484" ?>
<?rfc include="reference.I-D.liu-distributed-mobility" ?>
<?rfc include="reference.I-D.chan-netext-distributed-lma" ?>
<?rfc include="reference.I-D.bernardos-netext-ll-statement" ?>
<?rfc include="reference.I-D.yokota-netlmm-pmipv6-mn-itho-support" ?>
<?rfc include="reference.I-D.bernardos-mif-pmip" ?>
<?rfc include="reference.I-D.jeyatharan-netext-multihoming-ps"?>
<reference anchor="NTMS2008" >
<front>
<title abbrev="NTMS2008">
A Distributed Dynamic Mobility Management Scheme designed for Flat IP Architectures.
</title>
<author initials="P." surname="Bertin" fullname="Philippe Bertin"> </author>
<date month="November" year="2008" />
</front>
<seriesInfo name="NTMS'2008" value='' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:24:49 |