One document matched: draft-chan-dmm-distributed-mobility-anchoring-02.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-02">
<front>
<title abbrev="mobility anchor switching">Distributed 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>
<author initials="J" surname="Lee" fullname="Jong-Hyouk 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 initials="S" surname="Jeon" fullname="Seil 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>
<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 flow.
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="RFC7333" />
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 one relies solely on centralized mobility management.
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, 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 (OAM) requirements
call for mobility anchor switching,
thus avoiding non-optimal routes.
This draft proposes distributed mobility anchoring solutions.
</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='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:'>
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 control plane (FM-CP),
which may be a function in a control plane anchor or mobility controller,
and a FM function in the data plane (FM-DP),
which may be the function of a data plane anchor.
<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, and mobile node.
</t>
<!-- sm function (end) -->
</list>
</t>
</section>
<!-- Anchor Initiation and Switching (begin section) -->
<section title="Anchor Initiation and Switching">
<!-- Anchoring function in network of attachment (begin section) -->
<section anchor="sec:af-in-net-attach"
title="Anchoring function in network of attachment">
<t>
The anchoring function of
the IP address at MN's side
of a flow
may be 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 starts a new flow.
Packets to the MN in this flow
are simply forwarded according to the forwarding table.
</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>
<!-- 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></preamble>
<artwork><![CDATA[
Net1 Net2
+--------------+ +--------------+
|AR1: | |AR2: |
|RA(IP1) | |RA(IP2) |
+--------------+ +--------------+
+--------------+ +--------------+
|MN(IP1): | or |MN(IP2): |
|flow(IP1,...) | |flow(IP2,...) |
+--------------+ +--------------+
]]></artwork>
<postamble>Figure 1. Anchoring function 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>
<!-- Anchoring Function in network of attachment (end section) -->
</section>
<!-- Anchoring Function not in network of attachment (begin section) -->
<section title="Anchoring Function not in network of attachment">
<t>
The anchoring function of
the IP address at MN's side
of a flow
may not be at the access router
to which the MN is attached.
</t>
<t>
An 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 (Net1) of attachment
using an IP address
belonging to the network where it was initialized
as described in
<xref target="sec:af-in-net-attach" />.
When the flow is unable to change its IP address
it may continue to use its original IP address
so that the anchoring function of the IP address
is not in the current network of attachment
but in the network where the original IP address belongs.
Mobility support is needed
to enable the flow to use this original IP address.
</t>
<!-- sm function (begin) -->
<t>
The security management function
in the anchoring node at a new network
must assign a valid IP prefix to a mobile node.
The security management function
must allow the mobile node to receive or send data packets
with an IP address
configured at a prior network of attachment of the mobile node.
Note that nowadays access networks deploy ingress filtering
so that the mobile node may not receive or send data packets
with the previously configured IP address
without the security management function's interaction
with ingress filtering.
</t>
<!-- sm function (end) -->
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net1 Net2
+--------------+ +--------------+
|AR1: | |AR2: |
|RA(IP1) | |RA(IP2) |
+--------------+ +--------------+
+--------------+
|MN(IP2): |
|flow(IP1,...) |
+--------------+
]]></artwork>
<postamble>Figure 2. Anchoring function not in network of attachment.
MN attached to AR2 in Net2 has a flow(IP1,...) using IP1,
which belongs to Net1.</postamble>
</figure>
<!-- Anchoring Function not in network of attachment (end section) -->
</section>
<!-- Keeping an IP address (begin section) -->
<section title="Keeping an IP address">
<t>
After the MN moves
with an ongoing session to the new network (Net2),
it obtains a new IP address or prefix from the new network.
However, the ongoing session
which was initialized in a prior network of attachment
is using an IP address belonging to the network
where it was initialized as described in Section 3.1.
IP mobility is needed
to use the original IP address for session continuity.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net1 Net2
+--------------+ +--------------+
|AR1: | |AR2: |
|RA(IP1) | |RA(IP2) |
+--------------+ +--------------+
+..............+ +--------------+
.MN(IP1): . move |MN(IP1,IP2): |
.flow(IP1,...) . =======> |flow(IP1,...) |
+..............+ +--------------+
]]></artwork>
<postamble>Figure 3. Keeping an IP address.
MN with ongoing flow using IP1 in Net1
has moved to Net2
and the flow needs to continue using IP1
to preserve session continuity.</postamble>
</figure>
<t>
The use of IP address belonging to the network of attachment
whenever a new flow is initiated
as described in
<xref target="sec:af-in-net-attach" />
and to keep the IP address
as the MN moves to a new network
are described in
<xref target="I-D.seite-dmm-dma" />.
</t>
<!-- Keeping an IP address (end section) -->
</section>
<!-- Changing the IP address (begin section) -->
<section title="Changing the IP address">
<t>
With the MN in the example in
<xref target="sec:af-in-net-attach" />
it may be desirable
to change to a flow using 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 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>
<!-- 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.
</t>
<!-- sm function (end) -->
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net1 Net2
+--------------+ +--------------+
|AR1: | |AR2: |
|RA(IP1) | |RA(IP2) |
+--------------+ +--------------+
+..............+ +--------------+
.MN(IP1): . move |MN(IP2): |
.flow(IP1,...) . =======> |flow(IP2,...) |
+..............+ +--------------+
]]></artwork>
<postamble>Figure 4. Changing the IP address.
MN running a flow using IP1 in Net1
changes to running a flow using IP2 in Net2.</postamble>
</figure>
<!-- Changing the IP address (end section) -->
</section>
<!-- Moving the IP address (begin section) -->
<section title="Moving the IP address">
<t>
The anchoring function may move
without changing the IP address of the flow.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net1 Net2
+..............+ +--------------+
. . move |AR2: |
.RA(IP1) . =======> |RA(IP2,IP1) |
+..............+ +--------------+
+..............+ +--------------+
.MN(IP1): . move |MN(IP2,IP1): |
.flow(IP1,...) . =======> |flow(IP1,...) |
+..............+ +--------------+
]]></artwork>
<postamble>Figure 5. Moving the IP address.
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 address 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" />.
Another example 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 anchoring function of the original IP prefix/address at AR1
moved to AR2 in the new network.
Then the anchoring function
which was advertising the prefix in the original network
will need to move to the new network.
As the anchoring function 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.
</t>
<t>
The security management function must allow that the anchoring function in the new network configures the original IP prefix/address used by the mobile node at the previous (original) network. As the configured original IP prefix/address is to be used in the new network, the security management function must allow the anchoring function 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>
<!-- Moving the IP address (end section) -->
</section>
<!-- Indirection of a flow (begin section) -->
<section title="Indirection of a flow">
<t>
As an MN with an ongoing session
moves to a new network,
the flow may use the original IP address for session continuity
by using indirection.
Here the location management information
may be kept as a binding of the original IP address
to a new forwarding address,
whereas the Forwarding management function may then use this binding
to forward the flow.
</t>
<t>
In Figure 6, the location management information
kept in the original network
is the binding of the original IP address
to an IP address in the new network.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net3
+--------------+
|AR3: |
/|RA(IPcn) |
/ +--------------+
Net1 / +--------------+ Net2
+--------------+ / |CN(IPcn): flow| +--------------+
|flow(IP1,...) | / |(IPcn,IP1,...)| |flow(IP1,...) |
|--> AR2 | / +--------------+ |-->MN |
| | / | |
|IP1<->IPar2 | / | |
|--------------| / |--------------|
|AR1: |<- |AR2(IPar2): |
|RA(IP1) | ------------------------------------>|RA(IP2) |
+--------------+ +--------------+
+..............+ +--------------+
.MN(IP1): . move |MN(IP1,IP2): |
.flow(IP1,...) . =======> |flow(IP1,...) |
+..............+ +--------------+
]]></artwork>
<postamble>Figure 6. Indirection of a flow.
After MN has moved from Net1 to Net2,
Location Information function in Net1 keeps a binding of IP1 to IP of AR2,
and Routing Management function in Net1
forwards the packets of the flow(IP1,...)
to Net2.</postamble>
</figure>
<t>
The packets of the flow(IP1, IPcn, ...) from the CN to the MN
will first be forwarded to AR1 in the original network.
Here, using the binding of IP1 to an IP address in the new network,
the forwarding management function
may forward these packets to the new network
such as by encapsulating them with a header destined to the new network.
</t>
<t>
In a host-based mobility management solution
such as
<xref target="I-D.bernardos-dmm-cmip" />
the address in the new network may be the MN itself.
</t>
<t>
In a network-based mobility management solution
such as
<xref target="I-D.bernardos-dmm-pmip" />,
<xref target="I-D.sarikaya-dmm-for-wifi" />,
and
<xref target="Paper-Distributed.Mobility.PMIP" />,
the address in the new network may be 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,
which may use Software-Defined Networking as described in
<xref target="I-D.sarikaya-dmm-for-wifi" />.
</t>
<t>
In general, indirection is invoked only when needed.
The flow can use the IP address belonging to the network of attachment
where the flow is initialized as described in
<xref target="I-D.seite-dmm-dma" />.
</t>
<!-- sm function (begin) -->
<t>
The security management function in the IP anchoring node must ensure that the forwarding management function establishes a secure session anchoring with a relevant node.
The security management function in the end communication nodes (i.e., mobile node and correspondent node) may be used to ensure a secure data plane between them.
For both cases (i.e., establishments of secure session anchoring and secure data plane), existing security protocols such as IKE, IPsec, TLS may be invoked by the security management function.
</t>
<!-- sm function (end) -->
<!-- Indirection of a flow (end section) -->
</section>
<!-- Changing the indirection of a flow (begin section) -->
<section title="Changing indirection of a flow">
<t>
Forwarding the packets of an ongoing session
from CN's network
via the original network
to MN's new network
is not necessarily optimal.
The route can be more direct
by forwarding these packets
directly from CN's network to MN's new network.
</t>
<t>
Here, the location information in the original network
may be copied to CN's network.
The packets of the flow(IP1, IPcn, ...) from the CN to the MN
are first intercepted at the access router of CN.
Then using the binding of IP1 to an IP address in the new network,
the forwarding management function in CN's network
may forward these packets directly to the new network
(<xref target="Paper-Distributed.Mobility.PMIP" />)
such as by encapsulating them with a header destined to the new network.
</t>
<t>
To change the indirection of a flow,
the relevant context with regard to MN
should be delivered from AR1 in Net1
to AR3 (CN's anchor) in Net3 (CN's network),
while AR2 should be notified of the change of indirection
to receive packets directly forwarded by AR3.
Existing IP mobility signaling messages such as Proxy Binding Update (PBU)
and Proxy Binding Acknowledgment (PBA)
can be used for the both communications
with as little option extensions as possible.
When a packet from the CN has reached AR3,
AR3 encapsulates the packet with a tunnel header
specified with IP address of CN's anchor as outer source IP
and AR2's IP address as outer destination IP.
For transparent packet delivery operation in the perspective od AR2,
CN's anchor needs to forward packets encapsulated with a tunnel header
specified with AR1's IP address as outer source IP
and AR2's IP address as outer destination IP.
</t>
<!-- sm function (begin) -->
<t>
The security management function in the IP anchoring node must ensure that the forwarding management function re-establishes a secure session anchoring with a relevant node during mid-session. The security management function in the end communication nodes may be used to ensure a secure data plane between them during mid-session.
For both cases (i.e., re-establishments of secure session anchoring and secure data plane), existing security protocols such as IKE, IPsec, TLS may be invoked by the security management function.
</t>
<!-- sm function (end) -->
<figure>
<preamble></preamble>
<artwork><![CDATA[
Net3
+--------------+
|flow(IP1,...) |
|--> AR2 |
y..>| |
p. |IP1<->IPar2 |
o. |--------------|
c. |AR3: |
. |RA(IPcn) |\
. +--------------+ \
Net1 . +--------------+ \ Net2
+--------------+ |CN(IPcn): flow| \ +--------------+
|flow(IP1,...) | |(IPcn,IP1,...)| \ |flow(IP1,...) |
|--> AR2 | +--------------+ \ |-->MN |
| | \ | |
|IP1<->IPar2 | \ | |
|--------------| \ |--------------|
|AR1: | ->|AR2(IPar2): |
|RA(IP1) | |RA(IP2) |
+--------------+ +--------------+
+..............+ +--------------+
.MN(IP1): . move |MN(IP1,IP2): |
.flow(IP1,...) . =======> |flow(IP1,...) |
+..............+ +--------------+
]]></artwork>
<postamble>Figure 7. Changing indirection of a flow.
Location Information function and Routing Management function in Net2
are copied to Net3,
so that the Location Information function in Net3
keeps a binding of IP1 to IP of AR2,
and the Routing Management function in Net3
forwards the packets of the flow(IP1,...)
to Net2.</postamble>
</figure>
<!-- Changing indirection of a flow (end section) -->
</section>
<!-- Anchor Initiation 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>
<section title="Contributors">
<t>This document is an attempt
to harmonize the different distributed mobility solutions
in a number of other drafts.
These drafts cited in this document
are the work of their many authors/co-authors.
While some of them have taken the work to jointly write this document,
others have contributed at least indirectly by writing these drafts.
The latter include
Carlos J. Bernardos,
Philippe Bertin,
Hui Deng,
Fabio Giust,
Dapeng Liu,
Satoru Matushima,
Peter McCann,
Antonio de la Oliva,
Behcet Sarikaya,
Pierrick Seite,
Li Xue,
and
Ryuji Wakikawa.
</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.6241.xml" ?>
<?rfc include="reference.RFC.7333.xml" ?>
<?rfc include="reference.RFC.7429.xml" ?>
<?rfc include="reference.I-D.seite-dmm-dma.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.mccann-dmm-flatarch.xml"?>
<?rfc include="reference.I-D.liu-dmm-deployment-scenario.xml"?>
<?rfc include="reference.I-D.matsushima-stateless-uplane-vepc.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:32 |