One document matched: draft-patil-dmm-issues-and-approaches2dmm-00.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'>
<!ENTITY RFC4861 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>
<!ENTITY RFC4862 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>
<!ENTITY RFC6275 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml'>
<!ENTITY RFC3776 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3776.xml'>
<!ENTITY RFC5213 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml'>
<!ENTITY RFC3963 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3963.xml'>
<!ENTITY RFC5380 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5380.xml'>
<!ENTITY RFC5555 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5555.xml'>
<!ENTITY RFC5568 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5568.xml'>
<!ENTITY RFC6088 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6088.xml'>
<!ENTITY RFC6089 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6089.xml'>
<!ENTITY RFC5014 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5014.xml'>
<!ENTITY RFC5142 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5142.xml'>
<!ENTITY RFC4433 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4433.xml'>
<!ENTITY LMAREDIR PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netext-redirect.xml'>
<!ENTITY PMIPMIP PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netlmm-mip-interactions.xml'>
<!ENTITY PMIPLR PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netext-pmip6-lr-ps.xml'>
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocappendix="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
docName="draft-patil-dmm-issues-and-approaches2dmm-00"
ipr="trust200902"
>
<front>
<title abbrev="DMM with MIP6">Approaches to Distributed mobility
management using Mobile IPv6 and its extensions</title>
<author role ="editor" fullname="Basavaraj Patil" initials="B" surname="Patil">
<organization>Nokia</organization>
<address>
<postal>
<street>6021 Connection drive</street>
<city>Irving</city>
<region>TX</region>
<code>75039</code>
<country>USA</country>
</postal>
<email>basavaraj.patil@nokia.com</email>
</address>
</author>
<author initials="C" surname="Williams"
fullname="Carl Williams">
<organization>MCSR Labs</organization>
<address>
<postal>
<street></street>
<city>Palo Alto</city>
<region>CA</region>
<code>94306</code>
<country>USA</country>
</postal>
<email>carlw@mcsr-labs.org</email>
</address>
</author>
<author initials="J" surname="Korhonen"
fullname="Jouni Korhonen">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<code>FI-02600 Espoo</code>
<country>FINLAND</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<date year="2012" />
<area>Internet</area>
<workgroup>Individual Submission</workgroup>
<keyword>Mobility</keyword>
<keyword>Mobile IPv6</keyword>
<keyword>Distributed Mobility</keyword>
<keyword>HMIP</keyword>
<keyword>DSMIP6</keyword>
<keyword>Home Agent</keyword>
<abstract>
<t>
Mobility solutions at the IP layer have been specified in the
IETF for IPv4 and IPv6. These solutions include host and
network based mobility. All of the mobility protocols enable IP
session continuity by providing the mobile host with an IP
address or prefix that remains constant even as the host moves
and attaches to different access networks and points of
attachment. Mobile hosts are anchored at a gateway via
a tunnel and the address/prefix provided to the host via the
gateway remains unchanged across mobility events. All IP
sessions initiated or terminated at a mobile host are anchored
via the gateway. A gateway centric approach such as Mobile IP, raises certain
concerns in terms of cost and efficiency. A mobility model
wherein the network entities enabling mobility are
distributed is a way of alleviating the concerns of a gateway
centric approach. This document considers ways to
alleviate anchored mobility issues with approaches that could
be considered in a deployment.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Mobility solutions at the IP layer have been specified in the
IETF for IPv4 and IPv6. These solutions include host and
network based mobility. All of the mobility protocols enable IP
session continuity by providing the mobile host with an IP
address or prefix that remains constant even as the host moves
and attaches to different access networks and points of
attachment. Mobile hosts are anchored at a gateway via
a tunnel and the address/prefix provided to the host via the
gateway remains unchanged across mobility events. All IP
sessions initiated or terminated at a mobile host are anchored
via the gateway. There are issues and concerns with such a
mobility model which are discussed in this
document. A mobility model wherein the mobility functions that
reside in the network are
distributed, is a way of alleviating the concerns of a gateway
centric approach. This document also considers ways to
alleviate anchored mobility issues with approaches that could
be considered in a deployment.
</t>
<t>
Mobile IPv6 as specified in <xref target="RFC6275"/>
<xref target="RFC3776"/> is a host
based mobility protocol. It requires the MN to be anchored at a
home agent. The home agent assigns the MN an IPv6 address or
prefix that is static for the duration of the registration
period. Similarly Proxy Mobile IPv6 <xref target="RFC5213"/> is
a network based mobility protocol in which the mobility access
gateway (MAG) assigns the MN a prefix provided by the local
mobility anchor (LMA) for the duration of a valid
registration. This prefix does not change across mobility
events. The home agent and LMA entities can be viewed as
centralized gateways. These gateways generally serve a large
number of mobile hosts. All traffic to/from mobile hosts
associated with an HA/LMA is routed through these
gateways and as a result raises concerns such as :
</t>
<t>
<list style="numbers">
<t> single point of failure, </t>
<t> backhauling traffic to the gateway, </t>
<t> latency as a result of backhauling and additional
processing,</t>
<t> cost and complexity, etc. </t>
</list>
</t>
<t>
These issues are discussed in further detail in the document. It should also be
noted that in addition to mobility for hosts, there is also
specifications that deal with networks that are mobile. Network
mobility is specified in <xref target="RFC3963"/>
</t>
<t>
The mobility working groups in the IETF have extended the basic
protocols to address various issues and concerns. Hierarchical
Mobile IP <xref target="RFC5380"/> and flow mobility
<xref target="RFC6088"/>, <xref target="RFC6089"/> are just a
few examples. Many of these extensions can be utilized in
deployments to alleviate the issues that arise from an anchored
mobility solution. A few approaches to how a distributed
mobility model could be deployed using current protocols and
extensions are also discussed in this document.
</t>
</section>
<section title="Terminology">
<t>
<list style="hanging">
<t hangText="Distributed Mobility">
<vspace blankLines="1"/>
The term distributed mobility refers to an architecture in
which the mobility function (entitie(s) in the network that
are responsible for IP mobility) is distributed across multiple
levels of hierarchy in a deployment. The mobility function(s) could be
provided by an access point or base-station, or it could be
a part of the access network. Distributed mobility would
enable session continuity for hosts while not requiring
that they be anchored at a single gateway (such as a home
agent or Local Mobility Agent) all the time.
</t>
</list>
</t>
</section>
<section title="Problem statement">
<t>
The lack of support for mobility at the IP layer has been
addressed in IPv6 with the specification of Mobile IPv6
<xref target="RFC6275"/>. Various extensions to the protocol
such as support for multiple care-of-addresses as well as the
ability to operate while attached to an IPv4 network using
Dual-stack Mobile IPv6 <xref target="RFC5555"/> have been
specified. The protocol has not been widely implemented or
deployed as of date for various reasons.
</t>
<t>
The Internet has evolved to support real-time applications such
as voice, multimedia streaming etc. These applications require
low latency as well as no (or minimal) interruptions when
switching interfaces or networks. Current IP mobility solutions
based on Mobile IPv6 are well suited for non-real-time
applications which are able to handle the delay which is caused
by a mobile node doing a handover between networks or switching
interfaces. Optimizations to support real time applications
have also been specified such as FMIPv6
<xref target="RFC5568"/>. The centralized gateway approach of
Mobile IPv6 has multiple issues and raises concerns that are
captured in this document. One of the ideas is to move the
mobility gateway closer to the actual point of attachment. This
has benefits in terms of reduced latency but it also causes
other issues such as the ability to support mobility when the
MN moves to a different access network or the ability to do
charging at a central node. Distributed mobility is an approach
that has some merit and worth studying further. At the same
time the issues that are driving the mobility solutions towards
a different model can be addressed by existing protocols with
various extensions. The problems of a centralized gateway
approach and reasons for considering distributed mobility need
to be deeply analyzed and understood before beginning work on
entirely new protocols for solving IP mobility.
</t>
</section>
<section title="Issues with current mobility models">
<t>
Current mobility protocols have been designed with a stable
topologically correct anchoring gateway in mind.
They just do not tolerate mid-session anchor relocation. HMIP6,
HA Switch, HA-reliability and LMA Redirect are attempts in that
direction but fail or fall short.
</t>
<t>
In addition, one of the key deployment considerations of Mobile IPv6 is the
location of each of the home agents or gateways, both initially
and over time. Each operator has unique requirements;
therefore, no single deployment model will suit all operators.
The operator's own organizational structure could also influence
the mobility architecture. Some operators have network OAM
responsibilities that are assigned geographically, while others use a
more centralized model. The deployment architecture that has
been traditionally put forth is to have centralized gateway elements
where all mobility control and data traffic is routed through them.
</t>
<section title="Backhauling all traffic to a centralized GW">
<t>
A centralized home agent/gateway approach leads to backhauling all
traffic to the node which has unfavorable operational consequences.
</t>
<t>
The sheer volume of the aggregated throughput traffic to backhaul all user data
from a local aggregation anchor to centralized data centers with
home gateways can be expensive in many scenarios. With high
density deployments, the centralized architecture leads to heavy
backhaul utilization, and the inability to distribute load quickly
manifests unfavorably. In addition, local user traffic does not
remain local. User traffic must travel all the way to the
centralized gateway and back, even if the corresponding peer is
topologically closer.
</t>
<t>
In addition, a centralized gateway model increases the cost of
backhaul by preventing the off-loading of high-bandwidth
services locally. Instead high-bandwidth services have their
traffic backhauled to a centralized gateway in a data
center. This will increase the distances and possibly the
capacity associated with any backhaul.
</t>
</section>
<section title="Latency Considerations">
<t>
While the support for Internet offload of user data can
significantly reduce the core network backhaul, the mobility
management element may be strategically positioned deeper in
the network to efficiently set-up and process the signaling
and control including optional policies. Such a hybrid
architecture can provide for supporting a mix of real-time and
non-real-time broadband services. Real-time applications can
benefit from lower latencies by having data closer to the
subscriber and peers and not backhauled. Non-real-time
applications (such as e-mail) derive no such performance
benefit and may have a more centralized traffic approach.
</t>
<t>
Current mobility models handle offload cases poorly.
A consideration may be to clearly make a working toolbox for applications to select
a prefix with anchored mobility and a prefix without anchoring.
</t>
</section>
<section title="Inefficient Routing and signaling overhead">
<t>
Inefficient routing mechanism of a completely centralized
mobility deployment approach causes QoS deterioration and may
lead to heavy network congestion in the core.
</t>
<t>
In the centralized approach only the HA and the CNs manage a
nodes mobility. Mobility signaling occurs each time a
mobile node changes its point-of-attachment regardless of
the locality and amplitude of its movement. As a
consequence, the same level of signaling load is
introduced independently of the user's mobility pattern.
For example, if the HA and/or CNs are far from the MN,
even if the MNs movement is small, the mobility signaling
messages travel across several IP networks, the latencies
of which reduce handover speed. Furthermore, route
optimization which supports direct routing from CNs to the
mobile node, generates excessive mobility messages and
adds a significant extra load to the network.
</t>
</section>
<section title="Scalability and cost">
<t>
In a completely centralized Mobile IPv6-based deployment
approach, the home agent becomes a single point of failure.
Also, a distributed deployment approach may provide better
overall capacity and performance, but this must be weighed
against the increase in capital costs for deployment of local
distributed gateways. In addition, a completely centralized
deployment model makes it difficult to scale with a large
number of mobile nodes. Scalability costs are weighted from
many perspectives such as the number of nodes in the overall
system, the geographic distance of the traffic, the number of
autonomous parties in the deployment approach and others.
</t>
</section>
</section>
<section title="Enhancements to improve mobility">
<t>
Enhancements to the Mobile IPv6 protocol have been done to improve
mobile communications in certain scenarios so that mobility
operations are efficient and optimized.. A key area of
enhancements is in reducing the delays
in the data path redirection operation that is defined in Mobile
IPv6 operations. Mobile IPv6 has adopted route optimization and
HMIPv6 to reduce the traversal of data traffic to the mobile nodes
new location changes in its point of attachment. Delays in data
traffic redirection will depend upon the location of the anchor
agent that performs the redirection. As such enhancements focus on
moving these anchor agents closer to the mobile node.
</t>
<section title="HMIPv6">
<t>
Using Mobile IPv6, a mobile node sends location updates to any
node it corresponds with each time it changes its location, and
at intermittent intervals otherwise. This involves a lot of
signaling and processing, and requires a lot of resources.
Furthermore, although it is not necessary for external hosts to
be updated when a mobile nodes moves locally, these updates
occur for both local and global moves. Hierarchical Mobile IPv6
(HMIPv6)is designed to enhance mobility support in MIPv6 and
micro-mobility management. The benefit of the HMIPv6
enhancement is to reduce the amount of signaling required and to
improve handoff speed.
</t>
<t>
The key concept behind HMIPv6 is to locally handle handovers by
the usage of an entity called the Mobility Anchor Point (MAP)
located at any level in a hierarchical network of routers. The
major issue on HMIPv6 is designing the MAP selection scheme that
can reduce frequent handover mobility signaling and improve
handover performance.
</t>
</section>
<section title="Dynamic assignment of HA">
<t>
Dynamic assignment of HA is an enhancement to reduce both the
signaling traffic and the data traffic to the home network. The
dynamic HA assignment may take into account the geographical
proximity of the HA to the mobile node. It may also consider
performance factors such as HA load-balancing or other criteria.
</t>
</section>
<section title="Route Optimization">
<t>
Mobile IPv6 Route optimization is an enhancement to optimize the
data path between two communicating nodes despite changes in
the IP connectivity on the mobile node side. The data
path reduction between the communicating nodes helps to reduce
one way packet delay when both nodes are under the same
localized domain and the mobility gateway is far away. The
process of reducing data path is referred to as route
optimization. Route optimization helps reduce the delay and
thus important for real-time applications. An enhanced version
of route optimization may also enable continued communications
during periods of temporary home-agent unavailability.
</t>
</section>
</section>
<section title="Distributed mobility - What does it imply">
<t>
Mobility is a service that provides significant value to a network
operator. The ability to offer connectivity and services that work
seamlessly across mobility events such as the switching of an
access network type etc. creates a much superior end-user
experience and thereby a demand for such service. Cellular
networks have offered mobility for voice and messaging (short
message service) since the late 80s and early 90s. These networks
have been evolving and are now offering broadband data services
and Internet connectivity. The network architectures are also
using Internet protocols and technologies to a significant
extent. Traditionally the architectures of these networks has been
hierarchical in nature. While such an architecture served
operators well in the past, it has limitations when it comes to
offering data services and Internet connectivity. There is an
effort to distribute functionality that generally has resided in
centralized gateways much more closer to the edge of the
network. The line between the access and core network is fading
and hence a need to rethink how mobility service is affected in
such an evolving architecture.
</t>
<t>
Distributed mobility is a way to deploy existing mobility
solutions that do not require a mobile host to be anchored at a
gateway all the time but instead be attached to different mobility
agents/gateways in the network depending on the access, location
and other factors. Session continuity via distributed mobility is
expected to be on par with that provided by an anchored mobility
solution.
</t>
<t>
Does it require an entirely new approach to mobility architectures
that would be based on the goal of distributing mobility related
functions? It is an easy option to consider redesigning on a clean
sheet of paper. However this is not a pragmatic approach. It is
much more optimal to consider what are the issues that are created
as a result of a centralized gateway architecture and then develop
extensions to the protocols and, deployment models, that can address
those issues. The implications of distributed mobility
architectures on access and core networks needs to be also
considered in any design.
</t>
</section>
<section title="Approaches using current protocols for distributed mobility">
<t>
We believe that most of the needed basic protocol functionality
for distributed mobility management is already there. What is
missing seem to be related to general system level design and lack
of mobility aware APIs for application developers. One of the
simple approaches for distributed mobility management is to avoid
traditional "anchored mobility" like Mobile IPv6 when possible and
rather use local (care-of) addresses for the communication. Use of
local addressing also implies less mobility related signaling load
in the network. For example <xref target="RFC5014"/> already
provides means for an application to explicitly request for a
prefix that has mobility characteristics (IPV6_PREFER_SRC_HOME) or
a prefix that is local to the current access network
(IPV6_PREFER_SRC_COA). It is not guaranteed that the IP stack in
the MN would always respect the suggestion received from the
application. In general it is also important that possible
solutions in distributed mobility management space requires
minimal changes in mobile hosts.
</t>
<t>Another aspect that is in interest of distributed mobility
management concentrates on allocating mobility anchors that are
topologically close to the MN. Existing protocols such as HMIPv6
<xref target="RFC5380"/> provide a solution that is close what is
needed. What might be needed in addition is a mechanism to "chain"
multiple MAP-domain to extend the micro-mobility area, or provide
another RFC5014 like prefix type (IPV6_PREFER_SRC_MAP). We could
also consider Mobile IPv6 + Proxy Mobile IPv6 interactions Scenario
A.1 in <xref target="I-D.ietf-netlmm-mip-interactions"/> a similar
solution. Finally, yet another approach for exploiting locality are
Proxy Mobile IPv6 localized routing solutions
<xref target="I-D.ietf-netext-pmip6-lr-ps"/> which allows bypassing
the remote central Local Mobility Anchor when ever possible and have
a direct communication via closer to MNs Mobile Access Gateways.
</t>
<t>Home Agent Switch <xref target="RFC5142"/> extension to Mobile
IPv6, Runtime LMA assignment
<xref target="I-D.ietf-netext-redirect"/> extension to Proxy Mobile
IPv6 and Mobile IPv4 Dynamic HA Assignment <xref target="RFC4433"/>
all provide solutions to dynamically assign a mobility anchor to the
MN. What is missing from these solutions, is a protocol or rather a
system level solution for a "seamless mobility anchor relocation"
during an existing mobility session. However, that would be rather
challenging due the fact that a mobility anchor relocation usually
implies topological location chance in the network, which would also
mean different prefixes/subnetworks for home addresses from the IP
routing point of view. Within a reasonably small autonomous
system or otherwise restricted area maybe some kind of interior
routing solution could be used to assist mobility anchor relocation.
</t>
</section>
<section title="Potential future work">
<t>
As the MEXT working group evolves and transitions to one that is
focused on dealing with distributed mobility, there is a need to
clearly understand the drivers for such an approach and whether
these could be dealt with via a framework that uses existing
mobility protocols and extensions and can be applied in a manner
that deals with those concerns.
</t>
<t>
One of the key efforts could be in understanding the key concerns
driving the need for a distributed mobility solution and
identifying various approaches using existing protocols and
extensions to overcome them.
</t>
<t>
<list style="numbers">
<t> Work on the generic solution for anchor relocation. This
might be a architecture describing work, rather than protocol
work. I believe we have most protocols already in place but not
glued together.</t>
<t>Work on address selection beyond RFC 5014 (with coloring i.e. the
end host stack knows properties of the prefix it got) and rapid
deprecation/renumbering of prefixes (needed when CoAs change and
applications try to use CoA for something local). This could
potentially be new protocol work an containers for coloring
prefixes (RA and DHCPv6) and how to handle local prefix deprecation
during handovers.</t>
<t>Work on localized mobility that does not involve signaling with
gateways or "mobility signaling". This could lead to work below
the IP layer, e.g. intra-AS mobility is handled
using some interior routing protocol enhancement.</t>
</list>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document has no requests to IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
This document is a discussion of distributed mobility
solutions. Some of the approaches that are considered for
deployment do have security implications. However since the
approaches being discussed are based on existing mobility
specifications developed within the IETF, they have already been
reviewed for security. This document does not raise any new
security concerns.
</t>
</section>
<section anchor="Summary" title="Summary and Conclusion">
<t>
Distributed mobility is a way of deploying mobility protocols that
minimise the issues that arise from a centralized gateway centric
approach that comes from a hierarchical model. As the amount of
traffic in a network grows, operators are less willing to
transport all the traffic to a centralized gateway just for the
sake of enabling mobility. The mobility models have to evolve to
meet the changing environment of mobile networks and traffic
patterns.
</t>
<t>
Using many of the extensions and protocols that have been defined
for Mobile IPv6 it is possible to deploy a mobility solution that
meets the criteria of distributed mobility architecture. The
concerns fo a centralized gateway approach can be addressed using
deployment techniques effectively.
</t>
</section>
</middle>
<back>
<references title="Informative References">
&RFC6275;
&RFC3776;
&RFC5213;
&RFC3963;
&RFC5380;
&RFC5555;
&RFC5568;
&RFC6088;
&RFC6089;
&RFC5014;
&RFC5142;
&RFC4433;
&LMAREDIR;
&PMIPMIP;
&PMIPLR;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:43:35 |