One document matched: draft-ietf-dmm-requirements-09.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-09">
<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>Renesas Mobile</organization>
<address>
<postal>
<street>Porkkalankatu 24, FIN-00180 Helsinki, Finland</street>
<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>Sangmyung University</street>
<street>Email: hurryon@gmail.com</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>Cisco</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>Instituto de Telecomunicacoes, Aveiro</street>
<street>Email: seiljeon@av.it.pt</street>
<street>-</street>
<street>Sérgio Figueiredo</street>
<street>Universidade de Aveiro</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>Telefonica I+D</street>
<street>Email: lmcm@tid.es</street>
<street>-</street>
<street>Juan Carlos Zuniga</street>
<street>InterDigital</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>University of Twente</street>
<street>Email: g.karagiannis@utwente.nl</street>
<street>-</street>
<street>Julien Laganier</street>
<street>Juniper</street>
<street>jlaganier@juniper.net</street>
<street>-</street>
<street>Wassim Michel Haddad</street>
<street>Ericsson</street>
<street>Wassam.Haddad@ericsson.com</street>
<street>-</street>
<street>Dirk von Hugo</street>
<street>Deutsche Telekom Laboratories</street>
<street>Dirk.von-Hugo@telekom.de</street>
<street>-</street>
<street>Ahmad Muhanna</street>
<street>Award Solutions</street>
<street>amuhanna@awardsolutions.com</street>
<street>-</street>
<street>Byoung-Jo Kim</street>
<street>ATT Labs</street>
<street>macsbug@research.att.com</street>
<street>-</street>
<street>Hassan Ali-Ahmad</street>
<street>Orange</street>
<street>hassan.aliahmad@orange.com</street>
<street>-</street>
</postal>
</address>
</author>
<date month="September" year="2013"></date>
<area></area>
<workgroup></workgroup>
<abstract>
<t>
This document defines the requirements
for Distributed Mobility Management (DMM).
The hierarchical structure
in traditional wireless networks
has led primarily to centralized deployment models.
As some wireless networks are evolving away from the hierarchical structure,
such as in moving the content delivery servers closer to the users,
a distributed model for mobility management
can be useful to them.
</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,
they all employ a mobility anchor
to allow 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.
It is a centrally deployed mobility anchor
in the sense that the deployed architectures today
have a small number of these anchors
and the traffic of millions of mobile nodes
in an operator network are typically managed
by the same anchor.
</t>
<t>
Distributed mobility management (DMM) is an alternative
to the above centralized deployment.
The background behind the interests to study DMM
are primarily in the following.
</t>
<t>
<list style='format (%d)'>
<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 IPv4 traffic offload
(e.g.
<xref target="RFC6909"/>,
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.
<vspace blankLines="1" />
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
such as in [I-D.bhandari-dhc-class-based-prefix]
and [I-D.korhonen-6man-prefix-properties],
thus reducing the amount of context maintained
in the network.
</t>
</list>
</t>
<t>
In addition, considerations in the study of DMM are in the following.
</t>
<t>
<list style='format (%d)'>
<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, such protocols have not been deployed today.
</t>
<t>
Most existing mobility protocols
have not been designed for multiple-interface hosts
which are capable to use multiple interfaces simultaneously.
Retrofitting the required functionality
can result in an unnecessary increase in the protocol complexity.
</t>
<t>
IP multicast support,
including optimizations, have been introduced
as an effective transport method
for multimedia data delivery,
but by "patching-up" procedure
after completing the design of
reference mobility protocol,
leading to network inefficiency and non-optimal routing.
</t>
</list>
</t>
<t>
The distributed mobility management (DMM) charter
addresses two complementary aspects
of mobility management procedures:
the distribution of mobility anchors
in the data-plane
towards a more flat network
and the selective 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,
identifies when mobility support must be activated
and when sessions
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.
It can then 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
<xref target="RFC6275"/>,
in the Proxy mobile IPv6 specification
<xref target="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
<xref target="RFC6275"/>;
local mobility anchor (LMA)
and mobile access gateway (MAG) as per
<xref target="RFC5213"/>,
and context as per
<xref target="RFC3753"/>.
</t>
<t>
In addition, this draft introduces the following terms.
</t>
<t>
<list style='hanging'>
<t hangText='Centrally deployed mobility anchors'>
<vspace blankLines="1" />
refer to the mobility management deployments
in which there are very few mobility anchors
and the traffic of millions of mobile nodes
in an operator network
are managed by the same anchor.
</t>
<t hangText='Centralized mobility management'>
<vspace blankLines="1" />
makes use of centrally deployed mobility anchors.
</t>
<t hangText='Distributed mobility management'>
<vspace blankLines="1" />
is not centralized so that
traffic does not need to traverse
centrally deployed mobility anchors.
</t>
<t hangText='Flat mobile network'>
<vspace blankLines="1" />
has few levels of routing hierarchy
introduced into the data path
by the mobility management system.
</t>
<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,
mobility management can be client-based or network-based.
</t>
<t>
An IP-layer mobility management protocol
is typically based on the principle
of distinguishing between session identifier and routing address
and maintaining a mapping between the two.
In Mobile IP,
the home address serves as the session identifier
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 addressed to the home address
of a mobile node can be continuously delivered to the node,
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 session 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
[I-D.yokota-dmm-scenario].
In the former case only the data plane is distributed,
implicitly assuming separation of data and control planes
as described in
[I-D.wakikawa-netext-pmip-cp-up-separtion].
Fully distributed mobility management implies that
both the data plane and the control plane are distributed.
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 a flat mobile network
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 distributed architecture,
it is recommended to first consider
whether existing mobility management protocols
can be extended.
</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 non-optimal routes,
thereby increasing the end-to-end delay.
The problem is manifested, for example,
when accessing a nearby server or servers
of a Content Delivery Network (CDN),
or when receiving locally available IP multicast
or sending IP multicast packets.
(Existing route optimization
is only a host-based solution.
On the other hand,
localized routing with PMIPv6
<xref target="RFC6705"/>
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
or does not behave like an MN.)
</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>
Unnecessary mobility support
to nodes that do not need it
<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.
</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., <xref target="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
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 the problems
PS1, PS2, PS3, and PS4 described in Section 4.
</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 routing
and more efficient use of network resources
by selecting an IP address or prefix
according to
whether mobility support is needed
and 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 stated 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 related problem PS7 described 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" />
A DMM solution MUST not introduce new security risks
or amplify existing security risks
against which the existing security mechanisms/protocols
cannot offer sufficient protection.
<vspace blankLines="1" />
Motivation:
Various attacks such as impersonation, denial of service,
man-in-the-middle attacks, and so on,
may be launched in a DMM deployment.
For instance,
an illegitimate node
may attempt to access a network providing DMM.
Another example is that
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.
Accordingly,
security mechanisms/protocols providing access control,
integrity, authentication, authorization,
confidentiality, etc.
can be used to protect the DMM entities
as they are already used to protect
against existing networks
and existing mobility protocols defined in IETF.
In addition,
end-to-end security measures between communicating nodes
may already be used
when deploying existing mobility protocols
where the signaling messages travel over the Internet.
For instance,
EAP-based authentication
can be used for network access security,
while IPsec can be used for end-to-end security.
When the existing security mechanisms/protocols
are applied to protect the DMM entities,
the security risks that may be introduced by DMM
MUST be considered to be eliminated.
Else the security protection would be degraded
in the DMM solution versus in existing mobility protocols.
</t>
</list>
</t>
<t>
This requirement prevents a DMM solution
from introducing uncontrollable 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 users.
</t>
</section>
<!-- REQ7 -->
<section
title="Multicast">
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Multicast considerations
<vspace blankLines="1" />
DMM SHOULD consider multicast early
so that solutions can be developed
not only to provide IP mobility support
when it is needed,
but also to avoid network inefficiency issues
in multicast traffic delivery
(such as duplicate multicast subscriptions
towards the downstream tunnel entities).
The multicast solutions should therefore
avoid restricting the management of all IP multicast traffic
to a single host through a dedicated (tunnel) interface
on multicast-capable access routers.
<vspace blankLines="1" />
Motivation:
Existing multicast deployment have been introduced
after completing the design of the reference mobility protocol,
then optimization and extensions have been followed
by "patching-up" procedure,
thus leading to network inefficiency and non-optimal routing.
The multicast solutions
should therefore be required to consider efficiency nature
in multicast traffic delivery.
</t>
</list>
</t>
<t>
This requirement addresses the problems
PS1 and PS8 described in Section 4.
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
Please refer to the discussion
under Security requirement in Section 5.6.
</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" ?>
<?rfc include="reference.RFC.6909" ?>
<?rfc include="reference.RFC.6705" ?>
<?rfc include="reference.RFC.6224" ?>
<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="I-D.wakikawa-netext-pmip-cp-up-separation">
<front>
<title>Separation of Control and User Plane for Proxy Mobile IPv6</title>
<author fullname="Ryuji Wakikawa" surname="Wakikawa" initials="R">
<organization/>
</author>
<author fullname="Rajesh Pazhyannur" surname="Pazhyannur" initials="R">
<organization/>
</author>
<author fullname="Sri Gundavelli" surname="Gundavelli" initials="S">
<organization/>
</author>
<date year="2013" day="15" month="July"/>
</front>
<seriesInfo value="draft-wakikawa-netext-pmip-cp-up-separation-00" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-wakikawa-netext-pmip-cp-up-separation-00.txt" type="TXT"/>
</reference>
<reference anchor="I-D.korhonen-6man-prefix-properties">
<front>
<title>IPv6 Prefix Properties</title>
<author fullname="Jouni Korhonen" surname="Korhonen" initials="J">
<organization/>
</author>
<author fullname="Basavaraj Patil" surname="Patil" initials="B">
<organization/>
</author>
<author fullname="Sri Gundavelli" surname="Gundavelli" initials="S">
<organization/>
</author>
<author fullname="Pierrick Seite" surname="Seite" initials="P">
<organization/>
</author>
<author fullname="Dapeng Liu" surname="Liu" initials="D">
<organization/>
</author>
<date year="2013" day="9" month="July"/>
</front>
<seriesInfo value="draft-korhonen-6man-prefix-properties-02" name="Internet-Draft"/><format target="http://www.ietf.org/internet-drafts/draft-korhonen-6man-prefix-properties-02.txt" type="TXT"/>
</reference>
<reference anchor="I-D.bhandari-dhc-class-based-prefix">
<front>
<title>DHCPv6 class based prefix</title>
<author fullname="Shwetha Bhandari" surname="Bhandari" initials="S">
<organization/>
</author>
<author fullname="Gaurav Halwasia" surname="Halwasia" initials="G">
<organization/>
</author>
<author fullname="Sri Gundavelli" surname="Gundavelli" initials="S">
<organization/>
</author>
<author fullname="Hui Deng" surname="Deng" initials="H">
<organization/>
</author>
<author fullname="Laurent Thiebaut" surname="Thiebaut" initials="L">
<organization/>
</author>
<author fullname="Jouni Korhonen" surname="Korhonen" initials="J">
<organization/>
</author>
<author fullname="Ian Farrer" surname="Farrer" initials="I">
<organization/>
</author>
<date year="2013" day="15" month="July"/>
</front>
<seriesInfo value="draft-bhandari-dhc-class-based-prefix-05" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-bhandari-dhc-class-based-prefix-05.txt" type="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 06:47:57 |