One document matched: draft-ietf-dmm-requirements-05.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="no"?>
<rfc category="info" ipr="trust200902"
docName="draft-ietf-dmm-requirements-05">
<front>
<title abbrev="DMM-Reqs">
Requirements for Distributed Mobility Management
</title>
<author initials="H" surname="Chan (Ed.)"
fullname="H Anthony Chan (editor)">
<organization>Huawei Technologies (more co-authors on P. 17)</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 3, Plano, TX 75024, USA</street>
<street>Email: h.a.chan@ieee.org</street>
</postal>
</address>
</author>
<author initials="D" surname="Liu"
fullname="Dapeng Liu">
<organization>China Mobile</organization>
<address>
<postal>
<street>Unit2, 28 Xuanwumenxi Ave, Xuanwu District,
Beijing 100053, China</street>
<street>Email: liudapeng@chinamobile.com</street>
</postal>
</address>
</author>
<author initials="P" surname="Seite"
fullname="Pierrick Seite">
<organization>Orange</organization>
<address>
<postal>
<street>4, rue du Clos Courtel, BP 91226,
Cesson-Sevigne 35512, France</street>
<street>Email: pierrick.seite@orange.com</street>
</postal>
</address>
</author>
<author initials="H" surname="Yokota"
fullname="Hidetoshi Yokota">
<organization>KDDI Lab</organization>
<address>
<postal>
<street>2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan</street>
<street>Email: yokota@kddilabs.jp</street>
</postal>
</address>
</author>
<author initials="J" surname="Korhonen"
fullname="Jouni Korhonen">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Email: jouni.korhonen@nsn.com</street>
<street>-</street>
<street>Charles E. Perkins</street>
<street>Huawei Technologies</street>
<street>Email: charliep@computer.org</street>
<street>-</street>
<street>Melia Telemaco</street>
<street>Alcatel-Lucent Bell Labs</street>
<street>Email: telemaco.melia@alcatel-lucent.com</street>
<street>-</street>
<street>Elena Demaria</street>
<street>Telecom Italia</street>
<street>via G. Reiss Romoli, 274, TORINO, 10148, Italy</street>
<street>Email: elena.demaria@telecomitalia.it</street>
<street>-</street>
<street>Jong-Hyouk Lee</street>
<street>RSM Department, Telecom Bretagne</street>
<street>Cesson-Sevigne, 35512, France</street>
<street>Email: jh.lee@telecom-bretagne.eu</street>
<street>-</street>
<street>Kostas Pentikousis</street>
<street>Huawei Technologies</street>
<street>Carnotstr. 4 10587 Berlin, Germany</street>
<street>Email: k.pentikousis@huawei.com</street>
<street>-</street>
<street>Tricci So</street>
<street>ZTE</street>
<street>Email: tso@zteusa.com</street>
<street>-</street>
<street>Carlos J. Bernardos</street>
<street>Universidad Carlos III de Madrid</street>
<street>Av. Universidad, 30, Leganes, Madrid 28911, Spain</street>
<street>Email: cjbc@it.uc3m.es</street>
<street>-</street>
<street>Peter McCann</street>
<street>Huawei Technologies</street>
<street>Email: PeterMcCann@huawei.com</street>
<street>-</street>
<street>Seok Joo Koh</street>
<street>Kyungpook National University, Korea</street>
<street>Email: sjkoh@knu.ac.kr</street>
<street>-</street>
<street>Wen Luo</street>
<street>ZTE</street>
<street>No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China</street>
<street>Email: luo.wen@zte.com.cn</street>
<street>-</street>
<street>Sri Gundavelli</street>
<street>sgundave@cisco.com</street>
<street>-</street>
<street>Marco Liebsch</street>
<street>NEC Laboratories Europe</street>
<street>Email: liebsch@neclab.eu</street>
<street>-</street>
<street>Carl Williams</street>
<street>MCSR Labs</street>
<street>Email: carlw@mcsr-labs.org</street>
<street>-</street>
<street>Seil Jeon</street>
<street>Email: seiljeon@av.it.pt</street>
<street>-</street>
<street>Sérgio Figueiredo</street>
<street>Email: sfigueiredo@av.it.pt</street>
<street>-</street>
<street>Stig Venaas</street>
<street>Email: stig@venaas.com</street>
<street>-</street>
<street>Luis Miguel Contreras Murillo</street>
<street>Email: lmcm@tid.es</street>
<street>-</street>
<street>Juan Carlos Zuniga</street>
<street>Email: JuanCarlos.Zuniga@InterDigital.com</street>
<street>-</street>
<street>Alexandru Petrescu</street>
<street>Email: alexandru.petrescu@gmail.com</street>
<street>-</street>
<street>Georgios Karagiannis</street>
<street>Email: g.karagiannis@utwente.nl</street>
<street>-</street>
<street>Julien Laganier</street>
<street>jlaganier@juniper.net</street>
<street>-</street>
<street>Wassim Michel Haddad</street>
<street>Wassam.Haddad@ericsson.com</street>
<street>-</street>
<street>Dirk von Hugo</street>
<street>Dirk.von-Hugo@telekom.de</street>
<street>-</street>
<street>Ahmad Muhanna</street>
<street>amuhanna@awardsolutions.com</street>
<street>-</street>
</postal>
</address>
</author>
<date month="June" year="2013"></date>
<area></area>
<workgroup></workgroup>
<abstract>
<t>
This document defines the requirements
for Distributed Mobility Management (DMM)
in IPv6 deployments.
The hierarchical structure
in traditional wireless networks
has led to deployment models
which are in practice centralized.
Mobility management
with logically centralized mobility anchoring
in current mobile networks
is prone to suboptimal routing
and raises scalability issues.
Such centralized functions
can lead to single points of failure
and inevitably introduce longer delays
and higher signaling loads
for network operations related to mobility management.
The objective is to enhance mobility management
in order to meet the primary goals in network evolution,
i.e., improve scalability,
avoid single points of failure,
enable transparent mobility support to upper layers
only when needed, and so on.
Distributed mobility management must be secure
and may co-exist
with existing network deployments and end hosts.
</t>
</abstract>
<note title="Requirements Language">
<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 RFC 2119 <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
In the past decade a fair number of mobility protocols
have been standardized
<xref target="RFC6275"/>
<xref target="RFC5944"/>
<xref target="RFC5380"/>
<xref target="RFC6301"/>
<xref target="RFC5213"/>.
Although the protocols differ
in terms of functions and associated message formats,
we can identify a few key common features:
<list style="symbols">
<t>
a centralized mobility anchor
providing global reachability
and an always-on experience to the user;
</t>
<t>
extensions to the base protocols
to optimize handover performance
while users roam across wireless cells; and
</t>
<t>
extensions to enable
the use of heterogeneous wireless interfaces
for multi-mode terminals
(e.g. smartphones).
</t>
</list>
</t>
<t>
The presence of the centralized mobility anchor
allows a mobile node to remain reachable
after it has moved to a different network.
The anchor point, among other tasks,
ensures connectivity
by forwarding packets
destined to, or sent from, the mobile node.
In practice,
most of the deployed architectures today
have a small number of centralized anchors
managing the traffic of millions of mobile nodes.
Compared with a distributed approach,
a centralized approach
is likely to have several issues or limitations
affecting performance and scalability,
which require costly network engineering to resolve.
</t>
<t>
To optimize handovers from the perspective of mobile nodes,
the base protocols have been extended
to efficiently handle packet forwarding
between the previous and new points of attachment.
These extensions are necessary
when applications have stringent requirements
in terms of delay.
Notions of localization and distribution of local agents
have been introduced to reduce signaling overhead
at the centralized routing anchor point
[Paper-Distributed.Centralized.Mobility].
Unfortunately, today we witness difficulties
in getting such protocols deployed,
resulting in sub-optimal choices
for the network operators.
</t>
<t>
Moreover, the availability of multiple-interface host
and the possibility of
using several network interfaces simultaneously
have motivated the development
of even more protocol extensions
to add more capabilities
to the mobility management protocol.
In the end,
deployment is further complicated
with the multitude of extensions.
</t>
<t>
As an effective transport method
for multimedia data delivery,
IP multicast support,
including optimizations, have been introduced
but by "patching-up" procedure
after completing the design of
reference mobility protocol,
leading to network inefficiency and non-optimal routing.
</t>
<t>
Mobile users are, more than ever,
consuming Internet content;
such traffic imposes new requirements
on mobile core networks for data traffic delivery.
The presence of content providers
closer to
Internet Service Providers (ISP) network
requires taking into account
local Content Delivery Networks (CDNs)
while providing mobility services.
Moreover, when the traffic demand exceeds available capacity,
service providers need to implement new strategies
such as selective traffic offload
(e.g. 3GPP work items LIPA/SIPTO
[TS.23.401])
through alternative access networks (e.g. WLAN)
[Paper-Mobile.Data.Offloading].
A gateway selection mechanism
also takes the user proximity into account
within EPC [TS.29303].
These mechanisms were not pursued in the past
owing to charging and billing reasons.
Assigning a gateway anchor node
from a visited network in roaming scenario
has until recently been done and are limited
to voice services only.
Charging and billing
require solutions beyond the mobility protocol.
</t>
<t>
Both traffic offloading and CDN mechanisms
could benefit from the development of mobile architectures
with fewer levels of routing hierarchy
introduced into the data path
by the mobility management system.
This trend towards so-called "flat networks"
works best for direct communications among peers
in the same geographical area.
Distributed mobility management
in a truly flat mobile architecture
would anchor the traffic
closer to the point of attachment of the user.
</t>
<t>
Today's mobile networks present
service providers with new challenges.
Mobility patterns indicate that
mobile nodes often
remain attached to the same point of attachment
for considerable periods of time
[Paper-Locating.User].
Specific IP mobility management support
is not required for applications
that launch and complete their sessions
while the mobile node is connected
to the same point of attachment.
However, currently,
IP mobility support is designed for always-on operation,
maintaining all parameters of the context
for each mobile subscriber
for as long as they are connected to the network.
This can result in a waste of resources
and unnecessary costs for the service provider.
Infrequent node mobility
coupled with application intelligence
suggest that mobility support could be provided selectively,
thus reducing the amount of context maintained
in the network.
</t>
<t>
The distributed mobility management (DMM) charter
addresses two complementary aspects
of mobility management procedures:
the distribution of mobility anchors
towards a more flat network
and the dynamic activation/deactivation
of mobility protocol support
as an enabler to distributed mobility management.
The former aims at positioning mobility anchors
(e.g., HA, LMA)
closer to the user;
ideally,
mobility agents could be collocated
with the first-hop router.
The latter,
facilitated by the distribution of mobility anchors,
aims at identifying when mobility support must be activated
and identifying sessions
that do not require mobility management support
-- thus reducing the amount of state information
that must be maintained
in various mobility agents of the mobile network.
The key idea is that
dynamic mobility management relaxes
some of the constraints
of previously-standardized mobility management solutions and,
by doing so,
it can avoid the unnecessary establishment of mechanisms
to forward traffic from an old to a new mobility anchor.
</t>
<t>
This document compares distributed mobility management
with centralized mobility management in Section 3.
The problems that can be addressed with DMM
are summarized in Section 4.
The mandatory requirements as well as the optional requirements
are given in Section 5.
Finally, security considerations are discussed in Section 6.
</t>
<t>
The problem statement and the use cases
[I-D.yokota-dmm-scenario]
can be found in
[Paper-Distributed.Mobility.Review].
</t>
</section>
<section title="Conventions used in this document">
<section title="Terminology">
<t>All the general mobility-related terms and their acronyms used in this document are to be interpreted
as defined in the Mobile IPv6 base specification [RFC6275],
in the Proxy mobile IPv6 specification [RFC5213],
and in Mobility Related Terminology
<xref target="RFC3753"/>.
These terms include the following:
mobile node (MN), correspondent node (CN),
and home agent (HA) as per [RFC6275];
local mobility anchor (LMA)
and mobile access gateway (MAG) as per [RFC5213],
and context as per
<xref target="RFC3753"/>.
</t>
<t>
In addition, this draft introduces the following term.
</t>
<t>
<list style='hanging'>
<t hangText='Mobility context'>
<vspace blankLines="1" />
is the collection of information
required to provide mobility management support
for a given mobile node.
</t>
</list>
</t>
</section>
</section>
<section
title="Centralized versus distributed mobility management">
<t>
Mobility management functions
may be implemented at different layers
of the protocol stack.
At the IP (network) layer,
they may reside in the network or in the mobile node.
In particular,
a network-based solution resides in the network only.
It therefore enables mobility for existing hosts
and network applications
which are already in deployment but lack mobility support.
</t>
<t>
At the IP layer,
a mobility management protocol supporting session continuity
is typically based on the principle
of distinguishing between identifier and routing address
and maintaining a mapping between the two.
In Mobile IP,
the home address serves as an identifier of the device
whereas the care-of-address (CoA)
takes the role of the routing address.
The binding between these two
is maintained at the home agent (mobility anchor).
If packets can be continuously delivered
to a mobile node at its home address,
then all sessions using that home address
are unaffected
even though the routing address (CoA) changes.
</t>
<t>
The next two subsections explain centralized and distributed
mobility management functions in the network.
</t>
<section title="Centralized mobility management">
<t>
In centralized mobility management,
the mapping information
between the persistent node identifier
and the locator IP address of a mobile node (MN)
is kept at a single mobility anchor.
At the same time,
packets destined to the MN are routed via this anchor.
In other words,
such mobility management systems are centralized
in both the control plane and the data plane
(mobile node IP traffic).
</t>
<t>
Many existing mobility management deployments
make use of centralized mobility anchoring
in a hierarchical network architecture,
as shown in Figure 1.
Examples of such centralized mobility anchors
are the home agent (HA) and local mobility anchor (LMA)
in Mobile IPv6 <xref target="RFC6275"/>
and Proxy Mobile IPv6 <xref target="RFC5213"/>, respectively.
Current cellular networks
such as the Third Generation Partnership Project (3GPP)
GPRS networks, CDMA networks,
and 3GPP Evolved Packet System (EPS) networks
employ centralized mobility management too.
In particular,
the Gateway GPRS Support Node (GGSN),
Serving GPRS Support Node (SGSN)
and Radio Network Controller (RNC)
in the 3GPP GPRS hierarchical network,
and the Packet Data Network Gateway (P-GW)
and Serving Gateway (S-GW) in the 3GPP EPS network
all act as anchors in a hierarchy.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
3G GPRS 3GPP EPS MIP/PMIP
+------+ +------+ +------+
| GGSN | | P-GW | |HA/LMA|
+------+ +------+ +------+
/\ /\ /\
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
+------+ +------+ +------+ +------+ +------+ +------+
| SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG|
+------+ +------+ +------+ +------+ +------+ +------+
/\ /\
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
|RNC| |RNC| |RNC| |RNC|
+---+ +---+ +---+ +---+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 1. Centralized mobility management.
</t>
</section>
<section title="Distributed mobility management">
<t>Mobility management functions may also be distributed
to multiple networks
as shown in Figure 2,
so that a mobile node in any of these networks
may be served by a nearby mobility function (MF).
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
+------+ +------+ +------+ +------+
| MF | | MF | | MF | | MF |
+------+ +------+ +------+ +------+
|
+----+
| MN |
+----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 2. Distributed mobility management.
</t>
<t>
Mobility management may be partially or fully distributed.
In the former case only the data plane is distributed.
Fully distributed mobility management implies that
both the data plane and the control plane are distributed.
Such concepts of data and control plane separation
are not yet described
in the IETF developed mobility protocols so far
but are described in detail in
[I-D.yokota-dmm-scenario].
While mobility management can be distributed,
it is not necessary
for other functions
such as subscription management,
subscription database, and network access authentication to be similarly distributed.
</t>
<t>
A distributed mobility management scheme
for flat IP-based mobile network architecture
consisting of access nodes
is proposed in
[Paper-Distributed.Dynamic.Mobility].
Its benefits
over centralized mobility management
are shown through simulations in
[Paper-Distributed.Centralized.Mobility].
Moreover,
the (re)use and extension of existing protocols
in the design of both fully distributed mobility management
[Paper-Migrating.Home.Agents]
[Paper-Distributed.Mobility.SAE]
and partially distributed mobility management
[Paper-Distributed.Mobility.PMIP]
[Paper-Distributed.Mobility.MIP]
have been reported in the literature.
Therefore,
before designing new mobility management protocols
for a future flat IP architecture,
it is recommended to first consider
whether existing mobility management protocols
can be extended to serve a flat IP architecture.
</t>
</section>
</section>
<section
title="Problem Statement">
<t>
The problems that can be addressed with DMM are summarized in the following:
</t>
<t>
<list style='format PS%d:' counter="PS_count">
<!-- PS1 -->
<t>
Non-optimal routes
<vspace blankLines="1" />
Routing via a centralized anchor
often results in a longer route.
The problem is manifested, for example,
when accessing a local server or servers
of a Content Delivery Network (CDN),
or when receiving locally available IP multicast
or sending IP multicast packets.
</t>
<!-- PS2 -->
<t>
Divergence from other evolutionary trends in network architectures
such as distribution of content delivery.
<vspace blankLines="1" />
Centralized mobility management
can become non-optimal
with a flat network architecture.
</t>
<!-- PS3 -->
<t>
Low scalability of centralized tunnel management
and mobility context maintenance
<vspace blankLines="1" />
Setting up tunnels through a central anchor
and maintaining mobility context
for each MN
usually requires more concentrated resources
in a centralized design,
thus reducing scalability.
Distributing the tunnel maintenance function
and the mobility context maintenance function
among different network entities
with proper signaling protocol design
can increase scalability.
</t>
<!-- PS4 -->
<t>
Single point of failure and attack
<vspace blankLines="1" />
Centralized anchoring designs
may be more vulnerable
to single points of failures and attacks
than a distributed system.
The impact of a successful attack
on a system with centralized mobility management
can be far greater as well.
</t>
<!-- PS5 -->
<t>
Unnecessarily reserving resources to provide mobility support
to nodes that do not need such support
<vspace blankLines="1" />
IP mobility support is not always required,
and not every parameter of mobility context is always used.
For example,
some applications do not need a stable IP address
during a handover to maintain session continuity.
Sometimes, the entire application session runs
while the terminal does not change the point of attachment.
Besides, some sessions, e.g. SIP-based sessions,
can handle mobility at the application layer
and hence do not need IP mobility support;
it is then more efficient
to deactivate IP mobility support for such sessions.
</t>
<!-- PS6 -->
<t>
(Related problem)
Mobility signaling overhead
with peer-to-peer communication
<vspace blankLines="1" />
Wasting resources when mobility signaling
(e.g., maintenance of the tunnel, keep alive signaling, etc.)
is not turned off for peer-to-peer communication.
Peer-to-peer communications
have particular traffic patterns
that often do not benefit from mobility support
from the network.
Thus, the associated mobility support signaling
(e.g., maintenance of the tunnel, keep alive signaling, etc.)
wastes network resources for no application gain.
In such a case,
it is better to enable mobility support selectively.
</t>
<!-- PS7 -->
<t>
(Related problem)
Deployment with multiple mobility solutions
<vspace blankLines="1" />
There are already many variants and extensions of MIP.
Deployment of new mobility management solutions can be challenging,
and debugging difficult,
when they must co-exist with solutions already in the field.
</t>
<!-- PS8 -->
<t>
Duplicate multicast traffic
<vspace blankLines="1" />
IP multicast distribution over architectures
using IP mobility solutions
(e.g. RFC6224)
may lead to convergence
of duplicated multicast subscriptions
towards the downstream tunnel entity
(e.g. MAG in PMIPv6).
Concretely,
when multicast subscription
for individual mobile nodes
is coupled with mobility tunnels
(e.g. PMIPv6 tunnel),
duplicate multicast subscription(s)
is prone to be received
through different upstream paths.
This problem may also exist
or be more severe
in a distributed mobility environment.
</t>
</list>
</t>
</section>
<section title="Requirements">
<t>
After comparing distributed mobility management
against centralized deployment in Section 3,
this section identifies
the following requirements:
</t>
<!-- REQ1 -->
<section
title="Distributed processing">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Distributed processing
<vspace blankLines="1" />
IP mobility, network access and routing solutions
provided by DMM
MUST enable distributed processing
for mobility management of some flows
so that traffic
does not need to traverse centrally deployed
mobility anchors and thereby avoid non-optimal routes.
<vspace blankLines="1" />
Motivation:
This requirement is motivated by
current trends in network evolution:
(a) it is cost- and resource-effective
to cache and distribute content
by combining distributed mobility anchors
with caching systems
(e.g., CDN);
(b) the significantly larger number of mobile nodes
and flows
call for improved scalability;
(c) single points of failure are avoided
in a distributed system;
(d) threats against centrally deployed anchors,
e.g., home agent and local mobility anchor,
are mitigated in a distributed system.
</t>
</list>
</t>
<t>
This requirement addresses problems
PS1, PS2, PS3, and PS4 in Section 4.
(Existing route optimization
is only a host-based solution.
On the other hand,
localized routing with PMIPv6
addresses only a part of the problem
where both the MN and the CN
are located in the PMIP domain
and attached to a MAG,
and is not applicable
when the CN is outside the PMIP domain.)
</t>
</section>
<!-- REQ2 -->
<section
title="Transparency to Upper Layers when needed">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Transparency to Upper Layers when needed
<vspace blankLines="1" />
DMM solutions MUST provide
transparent mobility support above the IP layer
when needed.
Such transparency is needed,
for example, when,
upon change of point of attachment to the network,
an application flow cannot cope with a change
in the IP address.
However, it is not always necessary
to maintain a stable home IP address or prefix
for every application or at all times for a mobile node.
<vspace blankLines="1" />
Motivation:
The motivation of this requirement is to
enable more efficient use of network resources
and more efficient routing
by not maintaining context
at the mobility anchor
when there is no such need.
</t>
</list>
</t>
<t>
This requirement addresses the problem
PS5 as well as the related problem PS6 in Section 4.
</t>
</section>
<!-- REQ3 -->
<section
title="IPv6 deployment">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
IPv6 deployment
<vspace blankLines="1" />
DMM solutions SHOULD target IPv6
as the primary deployment environment
and SHOULD NOT be tailored specifically to support IPv4,
in particular in situations
where private IPv4 addresses and/or NATs are used.
<vspace blankLines="1" />
Motivation:
This requirement conforms
to the general orientation of IETF work.
DMM deployment is foreseen
in mid- to long-term horizon,
when IPv6 is expected
to be far more common than today.
</t>
</list>
</t>
<t>
This requirement avoids the unnecessarily complexity
in solving the problems in Section 4 for IPv4,
which will not be able to use
some of the IPv6-specific features.
</t>
</section>
<!-- REQ4 -->
<section
title="Existing mobility protocols">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Existing mobility protocols
<vspace blankLines="1" />
A DMM solution SHOULD
first consider reusing and extending
IETF-standardized protocols
before specifying new protocols.
<vspace blankLines="1" />
Motivation:
Reuse of existing IETF work
is more efficient and less error-prone.
</t>
</list>
</t>
<t>
This requirement attempts to avoid the need of
new protocols development
and therefore their potential problems
of being time-consuming and error-prone.
</t>
</section>
<!-- REQ5 -->
<section
title="Co-existence">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Co-existence with deployed networks and hosts
<vspace blankLines="1" />
The DMM solution MUST
be able to co-exist
with existing network deployments and end hosts.
For example,
depending on the environment in which DMM is deployed,
DMM solutions
may need to be compatible
with other deployed mobility protocols
or may need to co-exist
with a network or mobile hosts/routers
that do not support DMM protocols.
The mobile node may also move between different access networks,
where some of them may support neither DMM
nor another mobility protocol.
Furthermore,
a DMM solution SHOULD work across different networks,
possibly operated as separate administrative domains,
when allowed by the trust relationship
between them.
<vspace blankLines="1" />
Motivation:
(a) to preserve backwards compatibility
so that existing networks and hosts
are not affected
and continue to function as usual,
and
(b) enable inter-domain operation if desired.
</t>
</list>
</t>
<t>
This requirement addresses
the following related problem PS7 in Section 4.
</t>
</section>
<!-- REQ6 -->
<section
title="Security considerations">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Security considerations
<vspace blankLines="1" />
DMM protocol solutions
MUST consider security risks
introduced by DMM into the network.
Such considerations may include
authentication and authorization mechanisms
that allow a mobile host/router
to use the mobility support provided by the DMM solution;
measures against redirecting traffic to the wrong host
when providing DMM support;
signaling message protection
for authentication,
integrity and confidentiality.
<vspace blankLines="1" />
Motivation:
Various attacks such as impersonation,
denial of service, man-in-the-middle attacks,
and so on,
may become newly possible or easier to mount
due to the introduction of DMM.
Proof of possession of past and new IP addresses
may be needed.
<vspace blankLines="1" />
Signaling messages can be subject to various attacks
since they carry critical context information
about a mobile node/router.
For instance,
a malicious node can forge
a number of signaling messages
thus redirecting traffic from its legitimate path.
Consequently, the specific node is
under a denial of service attack,
whereas other nodes do not receive their traffic.
As signaling messages may travel over the Internet,
end-to-end security between communicating hosts must be required.
</t>
</list>
</t>
<t>
This requirement addresses the problems
of potentially insecure mobility management protocols
which make deployment infeasible
because platforms conforming to the protocols
are at risk for data loss and numerous other dangers,
including financial harm to the user.
</t>
</section>
<!-- REQ7 -->
<section
title="Multicast">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
DMM SHOULD enable multicast solutions in flexible distribution scenario.
This flexibility pertains to the preservation of IP multicast
nature from the perspective of a mobility entity
and transmission of multicast packets to/from
various multicast-enabled entities.
Therefore, this flexibility enables different IP multicast flows
with respect to a mobile host to be managed
(e.g., subscribed, received and/or transmitted)
using multiple multicast-enabled endpoints.
<vspace blankLines="1" />
Motivation:
to consider multicast early
so that solutions can be developed
to avoid network inefficiency issues
in multicast traffic delivery.
The multicast solution should therefore
avoid restricting the management
of all IP multicast traffic relative to a host
through a dedicated interface
on multicast-capable access routers.
</t>
</list>
</t>
<t>
This requirement addresses the problems
PS1 and PS8 in Section 4.
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
Distributed mobility management (DMM)
requires two kinds of security considerations.
The first consideration is on access network security
required between the mobile host/router
and the access network deploying DMM.
It allows only a legitimate mobile host/router to use DMM.
The second consideration is on end-to-end security
required between nodes that participate in the DMM protocol.
It protects the DMM signaling messages.
</t>
<t>
It is necessary to provide sufficient defense
against possible security attacks,
or to adopt existing security mechanisms
and protocols
to provide sufficient security protections.
For instance,
EAP-based authentication
can be used for access network security,
while IPsec can be used
for end-to-end security.
</t>
</section>
<section title="IANA Considerations">
<t>None</t>
</section>
<section title="Co-authors and Contributors">
<t>This problem statement document is a joint effort
among the numerous participants.
Each individual has made significant contributions
to this work
and have been listed as co-authors.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6275" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.5380" ?>
<?rfc include="reference.RFC.5944" ?>
<?rfc include="reference.RFC.6301" ?>
<?rfc include="reference.RFC.3753" ?>
<reference anchor="I-D.yokota-dmm-scenario">
<front>
<title>Use case scenarios
for Distributed Mobility Management</title>
<author initials="H" surname="Yokota"
fullname="Hidetoshi Yokota">
<organization />
</author>
<author initials="P" surname="Seite"
fullname="Pierrick Seite">
<organization />
</author>
<author initials="E" surname="Demaria"
fullname="Elena Demaria">
<organization />
</author>
<author initials="Z" surname="Cao" fullname="Zhen Cao">
<organization />
</author>
<date day="18" month="October" year="2010" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-yokota-dmm-scenario-00" />
<format type="TXT" target=
"http://www.ietf.org/internet-drafts/draft-yokota-dmm-scenario-00.txt"/>
</reference>
<reference anchor="TS.23.401">
<front>
<title>General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access</title>
<author><organization>3GPP</organization></author>
<date year="2013" month="March" day="07"/>
</front>
<seriesInfo value="23.401 10.10.0" name="3GPP TR"/>
<format target="http://www.3gpp.org/ftp/Specs/html-info/23401.htm" type="HTML"/> </reference>
<reference anchor="TS.29303">
<front>
<title>Domain Name System Procedures; Stage 3</title>
<author><organization>3GPP</organization></author>
<date year="2012" month="September" day="28"/>
</front>
<seriesInfo value="23.303 11.2.0" name="3GPP TR"/>
<format target="http://www.3gpp.org/ftp/Specs/html-info/29303.htm" type="HTML"/> </reference>
<reference anchor="Paper-Locating.User">
<front>
<title>Locating the User</title>
<author initials="G" surname="Kirby">
<organization />
</author>
<date year="1995" />
</front>
<seriesInfo name="" value="Communication International" />
</reference>
<reference anchor="Paper-Mobile.Data.Offloading">
<front>
<title>Mobile Data Offloading: How Much Can WiFi Deliver?</title>
<author initials="K" surname="Lee">
<organization />
</author>
<author initials="J" surname="Lee">
<organization />
</author>
<author initials="Y" surname="Yi">
<organization />
</author>
<author initials="I" surname="Rhee">
<organization />
</author>
<author initials="S" surname="Chong">
<organization />
</author>
<date year="2010" />
</front>
<seriesInfo name="" value="SIGCOMM 2010" />
</reference>
<reference anchor="Paper-Distributed.Dynamic.Mobility">
<front>
<title>A Distributed Dynamic Mobility Management Scheme
Designed for Flat IP Architectures</title>
<author initials="P" surname="Bertin">
<organization />
</author>
<author initials="S" surname="Bonjour">
<organization />
</author>
<author initials="J-M" surname="Bonnin">
<organization />
</author>
<date year="2008" />
</front>
<seriesInfo name=""
value="Proceedings of 3rd International Conference
on New Technologies, Mobility and Security (NTMS)" />
</reference>
<reference anchor="Paper-Distributed.Centralized.Mobility">
<front>
<title>A Distributed or Centralized Mobility</title>
<author initials="P" surname="Bertin">
<organization />
</author>
<author initials="S" surname="Bonjour">
<organization />
</author>
<author initials="J-M" surname="Bonnin">
<organization />
</author>
<date month="December" year="2009" />
</front>
<seriesInfo name=""
value="Proceedings of Global Communications Conference
(GlobeCom)" />
</reference>
<reference anchor="Paper-Migrating.Home.Agents">
<front>
<title>Migrating Home Agents
Towards Internet-scale Mobility Deployments</title>
<author initials="R" surname="Wakikawa">
<organization />
</author>
<author initials="G" surname="Valadon">
<organization />
</author>
<author initials="J" surname="Murai">
<organization />
</author>
<date month="December" year="2006" />
</front>
<seriesInfo name=""
value="Proceedings of the ACM 2nd CoNEXT Conference
on Future Networking Technologies" />
</reference>
<reference anchor="Paper-Distributed.Mobility.SAE">
<front>
<title>A Distributed IP Mobility Approach for 3G SAE</title>
<author initials="M" surname="Fisher">
<organization />
</author>
<author initials="F.U" surname="Anderson">
<organization />
</author>
<author initials="A" surname="Kopsel">
<organization />
</author>
<author initials="G" surname="Schafer">
<organization />
</author>
<author initials="M" surname="Schlager">
<organization />
</author>
<date year="2008" />
</front>
<seriesInfo name=""
value="Proceedings of the 19th International Symposium
on Personal, Indoor and Mobile Radio Communications (PIMRC)"
/>
</reference>
<reference anchor="Paper-Distributed.Mobility.Review">
<front>
<title>Distributed and Dynamic Mobility Management
in Mobile Internet: Current Approaches and Issues,
Journal of Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.
</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>
<seriesInfo name=""
value="Proceedings of GlobeCom Workshop
on Seamless Wireless Mobility" />
</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>
<reference anchor="Paper-Distributed.Mobility.MIP">
<front>
<title>Distributed Mobility Management with Mobile IP</title>
<author initials="H" surname="Chan">
<organization />
</author>
<date month="June" year="2012" />
</front>
<seriesInfo name=""
value="Proceedings of
IEEE International Communication Conference (ICC)
Workshop on Telecommunications:
from Research to Standards" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:20:46 |