One document matched: draft-chan-dmm-enhanced-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-enhanced-mobility-anchoring-00">

<front>
<title abbrev="mobility anchor switching">Enhanced mobility anchoring</title>

<author initials="H" surname="Chan, Ed." 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>

<author fullname="Kostas Pentikousis" initials="K.P." surname="Pentikousis, Ed.">
  <organization>EICT</organization>
  <address>
	  <postal>
		  <street>EUREF-Campus Haus 13</street>
		  <street>Torgauer Strasse 12-15</street>
		  <city>10829 Berlin</city>
		  <country>Germany</country>
	  </postal>
	  <email>k.pentikousis@eict.de</email>
  </address>
</author>

<date year="2014"></date>
<area></area>
<workgroup>DMM</workgroup>

<abstract>
<t>
This document initiates the discussion 
on enhanced mobility anchoring 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>
Motivated by the above-mentioned developments as well as 
<xref target="I-D.ietf-dmm-requirements"/>
we aim with this draft to initiate the discussion 
on enhanced mobility anchoring. 
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. 
</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" />
and in the Proxy Mobile IPv6 specification 
<xref target="RFC5213" />.
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)'> is 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.</t>
</list>
</t>

</section>



<!-- enhanced anchor switching -->

<section anchor="anchor-reloc" title="Enhanced anchor switching">

<t> 
In this section 
we consider mid-session mobility anchor switching for two cases. 
First we discuss the case 
where the mobile node moves from one subnet to another, 
and then we discuss the case where the node moves to a different network. 
Note that although the cases are described with traditional 
(read: physical) node mobility in mind, 
the proposed mechanism can be triggered for other operational reasons, 
such as the redefinition of a service chain graph, 
due to mechanisms which indicate that 
by relocating the mobility anchor for certain sessions 
energy and other operation expenditure can be reduced, 
or due to emergency situations, 
such as physical catastrophes. 
</t>

<section title="Anchor switching between subnets">

<t>
First we consider the situation illustrated in Fig. 1:
The mobile node (M) moves from Subnet 1 to Subnet 2. 
Each of the Network A Subnets (1, 2, and so on) owns a block of IP addresses.
In each subnet, the corresponding access router (AR1, AR2, ...) 
advertises the routes for the block of addresses of that subnet. 
</t>

<figure>
<preamble></preamble>
<artwork><![CDATA[
             +----------+
             | Network A|
             |Controller|
             +----------+
  +---+         +---+         +---+
  |AR1|         |AR2|         |AR3|
+--------+    +--------+    +--------+
|Subnet 1|    |Subnet 2|    |Subnet 3|  ....
+--------+    +--------+    +--------+

  +----+        +----+
  | M  | =====> | M  |
  |with|        |with|
  |IP1 |        |IP2 |
  |    |        |IP1 |
  +----+        +----+

]]></artwork>
<postamble>Figure 1. Movement of M from Subnet 1 to Subnet 2.</postamble>
</figure>

<t>
Before moving,
M is allocated an IP address IP1 from Subnet 1,
and it may run network applications using this IP address.
</t>

<t>
As M moves to Subnet 2,
it obtains a new IP address IP2 from Subnet 2.
The applications that can handle a change of IP address
will use the address IP2
<xref target="I-D.seite-dmm-dma"/>.

Other ongoing applications that cannot survive an IP address change
will need to continue using IP11 to maintain session continuity.
A mobility management protocol may be used
to enable M to use the address IP1 belonging to Subnet 1.
</t>

<t>
The AR1 access router in Subnet 1 may delegate the IP address (IP1)
to the access router AR2 in Subnet 2.
AR2 will then advertise IP1
so that the routing tables in Network A will be updated
and packets destined to IP1 will be routed to Subnet 2.
</t>

<t>
Relying on earlier routing table update mechanisms
with a distributed routing protocol
may not be fast enough to meet the requirement for a short handover delay.
In the case where a control and data plane separation model is followed,
a logically centralized mechanism 
can perform the forwarding table update faster.
For example, 
we can consider the use of I2RS mechanisms 
or the possibility to employ NETCONF 
<xref target="RFC6241"/>
for reconfiguring AR2.
</t>

<t>
Alternatively, 
a tunneling mobility management protocol such as MIPv6
<xref target="RFC6275"/> 
or PMIPv6 
<xref target="RFC5213"/>
may be used initially
[Paper-Distributed.Mobility.PMIP]
to enable M to use the IP address IP1 
while IP1 still belongs to Subnet 1.
The route may not be optimized initially,
but this is a good tradeoff so that anchor switching can take place.
After anchor switching 
and its subsequent forwarding table update have been completed,
packets destined to IP1 will be routed directly towards M.
</t>

<t>
The address delegation of IP1 from Subnet 1 to Subnet 2
may timeout unless there is request to renew it before it expires.
When all applications using IP1 in M have been terminated,
there will be no longer need for using IP1 in Subnet 2.
If there are still such applications running
when the address delegation is about to timeout,
the mobile node may signal with AR1 to request renewal of address delegation.
</t>

</section>


<section title="Anchor switching between networks">

<t> 
Fig. 2 illustrates the movement of a mobile node (M) 
from Subnet a1 of Network A to Subnet b2 of Network B. 
In this case,
each Network (A, B, and so on)
owns the aggregate of IP addresses blocks
for its subnets.
The corresponding gateway routers (GWa, GWb, ...) may run an IBGP among them,
and each advertises the aggregate of IP addresses for its subnets.
</t>

<figure>
<preamble></preamble>
<artwork><![CDATA[
   +---+           +---+           +---+
   |GWa|           |GWb|           |GWc|
+----------+    +----------+    +----------+
|Network A |    |Network B |    |Network C |   ....
|Controller|    |Controller|    |Controller|
+----------+    +----------+    +----------+

  +----+          +----+
  |ARa1|          |ARb2|
+---------+     +---------+
|Subnet a1|     |Subnet b2|     ....
+---------+     +---------+

  +-----+         +-----+
  |  M  |  =====> |  M  |
  | with|         | with|
  |IPa11|         |IPb21|
  |     |         |IPa11|
  +-----+         +-----+

]]></artwork>
<postamble>Figure 1. Movement of M from Subnet a1 of Network A 
to Subnet b2 of Network B.</postamble>
</figure>

<t>
Before moving,
M is allocated the IP address IPa11 from Subnet a1 of Network A,
and it may run network applications using this IP address.
</t>

<t>
As M moves to Subnet b2,
it obtains a new IP address IPb21 from Subnet b2 of Network B.
The applications that can handle a change of IP address
will use this new address IPb21.
Other applications with ongoing sessions 
that cannot survive an IP address change
will need to continue using IPa11 to maintain session continuity.
A mobility management protocol may be used
to enable M to use the address IPa11 belonging to Subnet a1 in Network A.
</t>

<t>
As the access router ARa1 in Subnet a1 may delegate the address IPa11
to the access router ARb2 in Subnet b2,
the gateways GWa, GWb, ...
also need to update the routing information
so that 
GWb will then advertise IPa11
so that the routing tables in GWa, GWb, ... will update
and packets destined to IPa11 will be routed to Network B.
</t>

<t>
The routing table update between the gateways
MAY be accomplished using IS-IS. 
In scenarios where the control plane and the data plane 
for these gateways are separate,
and there is a controller for these gateways,
a centralized routing protocol can also perform the forwarding table update
for these gateways.
</t>

<t>
Optionally, a tunneling mobility management protocol such as MIPv6
<xref target="RFC6275"/> 
or PMIPv6 
<xref target="RFC5213"/>
may be used 
to initially enable M to use the address IPa11 
while IPa11 still belongs to Subnet a1 of Network A.
Although such a route may not be optimized initially,
it enables anchor switching to take place.
After anchor switching 
and its subsequent forwarding table update have been completed,
the packets destined to IPa11 
will be routed directly towards M.
</t>

<t>
The address delegation of IPa11 from Subnet a1 to Subnet b2
may timeout unless there is request to renew it before it expires.
When the applications uisng IPa11 in M have all been terminated,
there will be no longer need for using IPa11 in Subnet b2.
If there are still such applications running
when the address delegation is about to timeout,
the mobile node may signal with ARa1 to request renewal of address delegation.
</t>

</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" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.6241" ?>
<?rfc include="reference.I-D.seite-dmm-dma"?>
<?rfc include="reference.I-D.yokota-dmm-scenario"?>

</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>