One document matched: draft-ietf-dmm-requirements-17.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml2rfc.tools.ietf.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-17">
<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</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>Broadcom Communications</organization>
<address>
<postal>
<street>Porkkalankatu 24, FIN-00180 Helsinki, Finland</street>
<street>Email: jouni.nospam@gmail.com</street>
</postal>
</address>
</author>
<date month="June" year="2014"></date>
<area></area>
<workgroup></workgroup>
<abstract>
<t>
This document defines the requirements
for Distributed Mobility Management (DMM)
at the network layer.
The hierarchical structure
in traditional wireless networks
has led primarily to centrally deployed mobility anchors.
As some wireless networks are evolving away from the hierarchical structure,
it can be useful to have a distributed model for mobility management
in which traffic does not need to traverse
centrally deployed mobility anchors far from the optimal route.
The motivation
and the problems addressed by each requirement
are also described.
</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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
In the past decade a fair number of
network-layer mobility protocols
have been standardized
<xref target="RFC6275"/>
<xref target="RFC5944"/>
<xref target="RFC5380"/>
<xref target="RFC6301"/>
<xref target="RFC5213"/>.
Although these 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.
Such a mobility anchor may still have to reside
in the subscriber's provider network
even when the subscriber is roaming to a visited network,
in order that certain functions
such as charging and billing can be performed
more readily by the provider's network.
An example provider network
is a Third Generation Partnership Project (3GPP) network.
</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
including that of local Content Delivery Networks (CDNs).
Such traffic imposes new requirements
on mobile core networks for data traffic delivery.
To prevent exceeding the available core network capacity,
service providers need to implement new strategies
such as selective IPv4 traffic offload
(e.g.,
<xref target="RFC6909"/>,
3GPP work items Local IP Access (LIPA)
and Selected IP Traffic Offload
(SIPTO)
[TS.23.401])
through alternative access networks
such as Wireless Local Area Network (WLAN)
[Paper-Mobile.Data.Offloading].
In addition, a gateway selection mechanism
takes the user proximity into account
within the Evolved Packet Core (EPC) [TS.29303].
Yet these mechanisms were not pursued in the past
owing to charging and billing considerations
which require solutions beyond the mobility protocol.
Consequently, assigning a gateway anchor node
from a visited network when roaming to the visited network
has only recently been done and is limited
to voice services.
<vspace blankLines="1" />
Both traffic offloading and CDN mechanisms
could benefit from the development of mobile architectures
with fewer hierarchical levels
introduced into the data path
by the mobility management system.
This trend of "flattening" the mobile networks
works best for direct communications among peers
in the same geographical area.
Distributed mobility management
in the flattening mobile networks
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>
DMM may distribute the mobility anchors
in the data-plane
in flattening the mobility network
such that the mobility anchors are positioned
closer to the user;
ideally,
mobility agents could be collocated
with the first-hop router.
Facilitated by the distribution of mobility anchors,
it may be possible to selectively use or not use
mobility protocol support
depending on whether such support
is needed or not.
It can thus reduce 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
for network-layer distributed mobility management
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
far from the optimal route.
</t>
<t hangText='Hierarchical mobile network'>
<vspace blankLines="1" />
has a hierarchy of network elements
arranged into multiple hierarchical levels
which are introduced into the data path
by the mobility management system.
</t>
<t hangText='Flattening mobile network'>
<vspace blankLines="1" />
refers to the hierarchical mobile network
which is going through the trend
of reducing its number of hierarchical levels.
</t>
<t hangText='Flatter mobile network'>
<vspace blankLines="1" />
has fewer hierarchical levels
compared to a hierarchical mobile network.
</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 is needed because
the IP address of a mobile node
may change as the node moves.
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 a session identifier and a forwarding address
and maintaining a mapping between the two.
In Mobile IP,
the new IP address of the mobile node
after the node has moved
is the forwarding address,
whereas the original IP address
before the mobile node moves
serves as the session identifier.
The location management (LM) information
is kept by associating the forwarding address
with the session identifier.
Packets addressed to the session identifier
will first route to the original network
which re-directs them using the forwarding address
to deliver to the session.
Re-directing packets this way can result in long routes.
An existing optimization routes directly
using the forwarding address of the host,
and such is a host-based solution.
</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 location information in terms of a mapping
between the session identifier
and the forwarding address
is kept at a single mobility anchor,
and packets destined to the session identifier
are forwarded 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 are the home agent (HA)
and local mobility anchor (LMA)
serving as the anchors for the mobile node (MN)
and Mobile Access Gateway (MAG)
in Mobile IPv6
<xref target="RFC6275"/>
and
in Proxy Mobile IPv6
<xref target="RFC5213"/>
respectively.
Cellular networks
such as the 3GPP
General Packet Radio System (GPRS) networks
and 3GPP Evolved Packet System (EPS) networks
employ centralized mobility management too.
In the 3GPP GPRS network,
the Gateway GPRS Support Node (GGSN),
Serving GPRS Support Node (SGSN)
and Radio Network Controller (RNC)
constitute a hierarchy of anchors.
In the 3GPP EPS network,
the Packet Data Network Gateway (P-GW)
and Serving Gateway (S-GW)
constitute another hierarchy of anchors.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
3GPP 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
in the data plane to multiple networks
as shown in Figure 2,
so that a mobile node in any of these networks
may be served by a nearby function
with appropriate forwarding management (FM) capability.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
+------+ +------+ +------+ +------+
| FM | | FM | | FM | | FM |
+------+ +------+ +------+ +------+
|
+----+
| MN |
+----+
]]></artwork>
<postamble></postamble>
</figure>
<t>Figure 2. Distributed mobility management.
</t>
<t>
DMM is distributed in the data plane,
whereas the control plane may either be centralized or distributed
[I-D.yokota-dmm-scenario].
The former case implicitly assumes
separation of data and control planes
as described in
[I-D.wakikawa-netext-pmip-cp-up-separation].
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 flattening mobile network
consisting of access nodes is proposed in
[Paper-Distributed.Dynamic.Mobility].
Its benefits
over centralized mobility management
have been shown through simulations
[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" />
Forwarding 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 correspondent node (CN)
are attached to the same MAG,
and it is not applicable
when the CN 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" />
Mobile networks have generally been evolving
towards a flatter and flatter network.
Centralized mobility management,
which is non-optimal with a flatter network architecture,
does not support this evolution.
</t>
<!-- PS3 -->
<t>
Lack of 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 avoid increasing the concentrated resources
with an increasing number of MNs.
</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 clients that do not need it
<vspace blankLines="1" />
IP mobility support is usually provided to all MNs.
Yet it is not always required,
and not every parameter of mobility context is always used.
For example,
some applications or nodes do not need a stable IP address
during a handover to maintain session continuity.
Sometimes, the entire application session runs
while the MN 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 unnecessary
to provide IP mobility support for such sessions.
</t>
<!-- PS6 -->
<t>
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.
</t>
<!-- PS7 -->
<t>
Deployment with multiple mobility solutions
<vspace blankLines="1" />
There are already many variants and extensions of MIP
as well mobility solutions at other layers.
Deployment of new mobility management solutions can be challenging,
and debugging difficult,
when they co-exist with solutions already deployed 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
and describing the problems in Section 4,
this section identifies
the following requirements:
</t>
<!-- REQ1 -->
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Distributed mobility management
<vspace blankLines="1" />
IP mobility, network access and forwarding solutions
provided by DMM
MUST enable traffic
to avoid traversing single mobility anchor
far from the optimal route.
<vspace blankLines="1" />
This requirement on distribution is
in the data plane only.
It does not impose constraints
on whether the control plane should be distributed or centralized.
However, if the control plane is centralized
while the data plane is distributed,
it is implicit that
the control plane and data plane need to separate (Section 3.2).
<vspace blankLines="1" />
Motivation:
This requirement is motivated by
current trends in network evolution:
(a) it is cost- and resource-effective
to cache contents,
and the caching (e.g., CDN) servers are distributed
so that each user in any location
can be close to one of the servers;
(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.
<vspace blankLines="1" />
This requirement addresses the problems
PS1, PS2, PS3, and PS4 described in Section 4.
</t>
</list>
</t>
<!-- REQ2 -->
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Bypassable network-layer mobility support for each application session
<vspace blankLines="1" />
DMM solutions MUST enable network-layer mobility
but it MUST be possible
for any individual active application session (flow)
to not use it.
Mobility support is needed, for example,
when a mobile host moves and an application
cannot cope with a change in the IP address.
Mobility support is also needed
when a mobile router changes its IP address
as it moves together with a host
and, in the presence of ingress filtering,
an application in the host is interrupted.
However mobility support at the network-layer
is not always needed;
a mobile node can often be stationary,
and mobility support can also be provided
at other layers.
It is then not always necessary to maintain a
stable IP address or prefix
for an active application session.
<vspace blankLines="1" />
Different active sessions can also differ in
whether network-layer mobility support is needed.
IP mobility, network access
and forwarding solutions provided by
DMM MUST then enable
the possibility of independent handling for
each application session
of a user or mobile device.
<vspace blankLines="1" />
The handling of mobility management
to the granularity of an individual session
of a user/device
SHOULD need proper session identification
in addition to user/device identification.
<vspace blankLines="1" />
Motivation:
The motivation of this requirement is to
enable more efficient forwarding
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.
<vspace blankLines="1" />
This requirement addresses the problems
PS5 and PS6 described in Section 4.
</t>
</list>
</t>
<!-- REQ3 -->
<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.
<vspace blankLines="1" />
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>
</list>
</t>
<!-- REQ4 -->
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Existing mobility protocols
<vspace blankLines="1" />
A DMM solution MUST
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.
<vspace blankLines="1" />
This requirement attempts to avoid the need of
new protocols development
and therefore their potential problems
of being time-consuming and error-prone.
</t>
</list>
</t>
<!-- REQ5 -->
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Coexistence with deployed networks/hosts
and operability across different networks
<vspace blankLines="1" />
A DMM solution may require loose, tight
or no integration into existing mobility protocols
and host IP stack.
Regardless of the integration level,
DMM implementations MUST
be able to coexist
with existing network deployments,
end hosts and routers
that may or may not
implement existing mobility protocols.
Furthermore,
a DMM solution SHOULD work across different networks,
possibly operated as separate administrative domains,
when the needed mobility management
signaling, forwarding, and network access
are 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.
<vspace blankLines="1" />
This requirement addresses
the problem PS7 described in Section 4.
</t>
</list>
</t>
<!-- REQ6 -->
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Operation and Management considerations.
<vspace blankLines="1" />
A DMM solution needs to consider
configuring a device,
monitoring the current operational state of a device,
responding to events that impact the device,
possibly by modifying the configuration
and storing the data in a format
that can be analyzed later.
Different management protocols are available.
For example:
<list style='format (%c)' counter="REQ6_count1">
<t>
SNMP
<xref target="RFC1157"/>
with definition of standardized
management information base
MIB objects for DMM,
that allows monitoring traffic steering
in a consistent manner across different devices,
</t>
<t>
NETCONF
<xref target="RFC6241"/>
with definition of standardized YANG
<xref target="RFC6020"/>
modules for DMM
to achieve a standardized configuration,
</t>
<t>
syslog
<xref target="RFC3164"/>
which is a one-way protocol
allowing a device to report significant events
to a log analyzer in a network management system.
</t>
<t>
IP Flow Information Export (IPFIX) Protocol,
which serves as a means for transmitting
traffic flow information over the network
<xref target="RFC7011"/>,
with a formal description
of IPFIX Information Elements
<xref target="RFC7012"/>.
</t>
</list>
<vspace blankLines="1" />
It is not the goal of the requirements document
to impose which management protocol(s)
should be used.
An inventory of the management protocols
and data models is covered in RFC 6632.
<vspace blankLines="1" />
The following lists
the operation and management considerations
required for a DMM solution;
the list may not be exhaustive
and may be expanded
according to the needs of the solutions:
<vspace blankLines="1" />
A DMM solution MUST
describe in what environment and
how it can be scalably deployed and managed.
<vspace blankLines="1" />
A DMM solution MUST support mechanisms
to test if the DMM solution is working properly.
For example,
when a DMM solution employs traffic indirection
to support a mobility session,
implementations MUST support mechanisms to test
that the appropriate traffic indirection operations
are in place,
including the setup of traffic indirection
and the subsequent teardown of the indirection
to release the associated network resources
when the mobility session has closed.
<vspace blankLines="1" />
A DMM solution SHOULD
expose the operational state of DMM
to the administrators of the DMM entities.
For example,
when a DMM solution employs separation between
session identifier and forwarding address,
it should expose the association
between them.
<vspace blankLines="1" />
When flow mobility is supported by a DMM solution,
the solution SHOULD support means to correlate
the flow routing policies
and the observed forwarding actions.
<vspace blankLines="1" />
A DMM solution SHOULD support mechanisms
to check the liveness of forwarding path.
If the DMM solution sends periodic update
refresh messages to configure the forwarding path,
the refresh period SHOULD be configurable
and a reasonable default configuration value proposed.
Information collected can be logged
or made available with protocols
such as SNMP
<xref target="RFC1157"/>,
NETCONF
<xref target="RFC6241"/>,
IPFIX
<xref target="RFC7011"/>,
or syslog
<xref target="RFC3164"/>.
<vspace blankLines="1" />
A DMM solution MUST
provide fault management and monitoring mechanisms
to manage situations
where update of the mobility session
or the data path fails.
The system must also be able to handle situations
where a mobility anchor
with ongoing mobility sessions fails.
<vspace blankLines="1" />
A DMM solution SHOULD be able
to monitor usage of DMM protocol.
When a DMM solution uses an existing protocol,
the techniques already defined for that protocol
SHOULD be used to monitor the DMM operation.
When these techniques are inadequate,
new techniques MUST be developed.
<vspace blankLines="1" />
In particular,
the DMM solution SHOULD
<list style='format (%c)' counter="REQ6_count2">
<t>
be able to
monitor the number of mobility sessions per user
as well as their average duration.
</t>
<t>
provide indication on DMM performance
such as
<list style='format %d'>
<t>
the handover delay
which includes the time necessary to re-establish
the forwarding path
when the point of attachment changes,
</t>
<t>the protocol reactivity which is the time
between handover events
such as the attachment to a new access point
and the completion of the mobility session update.
</t>
</list>
</t>
<t>
provide means to measure
the signaling cost of the DMM protocol.
</t>
<t>
if tunneling is used for traffic redirection,
monitor
<list style='format %d'>
<t>
the number of tunnels,
</t>
<t>their transmission and reception information,
</t>
<t>the used encapsulation method and overhead
</t>
<t>the security used at a node level.
</t>
</list>
</t>
</list>
<vspace blankLines="1" />
DMM solutions SHOULD support
standardized configuration
with NETCONF
<xref target="RFC6241"/>,
using YANG
<xref target="RFC6020"/>
modules,
which SHOULD be created for DMM
when needed for such configuration.
However, if a DMM solution creates
extensions to MIPv6 or PMIPv6,
the allowed addition of
the definition of management information base
(MIB) objects
to MIPv6 MIB
<xref target="RFC4295"/>
or PMIPv6 MIB
<xref target="RFC6475"/>
needed
for the control and monitoring
of the protocol extensions
SHOULD be limited to
read-only objects.
<vspace blankLines="1" />
Motivation:
A DMM solution that is designed from the beginning
for operability and manageability
can avoid difficulty or incompatibility
to implement efficient operations and management solutions.
<vspace blankLines="1" />
These requirements avoid DMM designs
that make operations and management difficult or costly.
</t>
</list>
</t>
<!-- REQ7 -->
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Security considerations
<vspace blankLines="1" />
A DMM solution MUST support
any security protocols and mechanisms
needed to secure the network
and to make continuous security improvements.
In addition,
with security taken into consideration
early in the design,
a DMM solution MUST NOT introduce new security risks,
or amplify existing security risks,
that cannot be mitigated by
existing security protocols and mechanisms.
<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 or nodes to which the traffic is redirected
may be 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.
should be used to protect the DMM entities
as they are already used to protect
against existing networks
and existing mobility protocols defined in IETF.
Yet if a candidate DMM solution is such that
even the proper use of these existing security mechanisms/protocols
are unable to provide sufficient security protection,
that candidate DMM solution is causing uncontrollable security problems.
<vspace blankLines="1" />
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>
</list>
</t>
<!-- REQ8 -->
<t>
<list style='format REQ%d:' counter="R_count">
<t>
Multicast considerations
<vspace blankLines="1" />
DMM SHOULD enable multicast solutions
to be developed to avoid network inefficiency
in multicast traffic delivery.
<vspace blankLines="1" />
Motivation:
Existing multicast deployment have been introduced
after completing the design of the reference mobility protocol,
often leading to network inefficiency and non-optimal forwarding
for the multicast traffic.
Instead DMM should consider multicast early
so that the multicast solutions
can better consider efficiency nature
in the multicast traffic delivery
(such as duplicate multicast subscriptions
towards the downstream tunnel entities).
The multicast solutions should then
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" />
This requirement addresses the problems
PS1 and PS8 described in Section 4.
</t>
</list>
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
Please refer to the discussion
under Security requirement in Section 5.
</t>
</section>
<section title="IANA Considerations">
<t>None</t>
</section>
<section title="Contributors">
<t>This requirements document is a joint effort
among numerous participants working in a team.
Valuable comments and suggestions in various reviews
from the following area directors and IESG members
have also contributed to much improvements:
Russ Housley,
Catherine Meadows,
Adrian Farrel,
Barry Leiba,
Alissa Cooper,
Ted Lemon,
Brian Haberman,
Stephen Farrell,
Joel Jaeggli,
Alia Atlas,
and
Benoit Claise.
In addition to the authors,
each of the following
has made very significant and important contributions to the working group draft in this work:
</t>
<t>
Charles E. Perkins
<vspace blankLines="0" />
Huawei Technologies
<vspace blankLines="0" />
Email: charliep@computer.org</t>
<t>Melia Telemaco
<vspace blankLines="0" />
Alcatel-Lucent Bell Labs
<vspace blankLines="0" />
Email: telemaco.melia@googlemail.com</t>
<t>Elena Demaria
<vspace blankLines="0" />
Telecom Italia
<vspace blankLines="0" />
via G. Reiss Romoli, 274, TORINO, 10148, Italy
<vspace blankLines="0" />
Email: elena.demaria@telecomitalia.it</t>
<t>Jong-Hyouk Lee
<vspace blankLines="0" />
Sangmyung University, Korea
<vspace blankLines="0" />
Email: jonghyouk@smu.ac.kr</t>
<t>Kostas Pentikousis
<vspace blankLines="0" />
EICT GmbH
<vspace blankLines="0" />
Email: k.pentikousis@eict.de</t>
<t>Tricci So
<vspace blankLines="0" />
ZTE
<vspace blankLines="0" />
Email: tso@zteusa.com</t>
<t>Carlos J. Bernardos
<vspace blankLines="0" />
Universidad Carlos III de Madrid
<vspace blankLines="0" />
Av. Universidad, 30, Leganes, Madrid 28911, Spain
<vspace blankLines="0" />
Email: cjbc@it.uc3m.es</t>
<t>Peter McCann
<vspace blankLines="0" />
Huawei Technologies
<vspace blankLines="0" />
Email: Peter.McCann@huawei.com</t>
<t>Seok Joo Koh
<vspace blankLines="0" />
Kyungpook National University, Korea
<vspace blankLines="0" />
Email: sjkoh@knu.ac.kr</t>
<t>Wen Luo
<vspace blankLines="0" />
ZTE
<vspace blankLines="0" />
No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China
<vspace blankLines="0" />
Email: luo.wen@zte.com.cn</t>
<t>Sri Gundavelli
<vspace blankLines="0" />
Cisco
<vspace blankLines="0" />
sgundave@cisco.com</t>
<t>Hui Deng
<vspace blankLines="0" />
China Mobile
<vspace blankLines="0" />
Email: denghui@chinamobile.com</t>
<t>Marco Liebsch
<vspace blankLines="0" />
NEC Laboratories Europe
<vspace blankLines="0" />
Email: liebsch@neclab.eu</t>
<t>Carl Williams
<vspace blankLines="0" />
MCSR Labs
<vspace blankLines="0" />
Email: carlw@mcsr-labs.org</t>
<t>Seil Jeon
<vspace blankLines="0" />
Instituto de Telecomunicacoes, Aveiro
<vspace blankLines="0" />
Email: seiljeon@av.it.pt</t>
<t>Sérgio Figueiredo
<vspace blankLines="0" />
Universidade de Aveiro
<vspace blankLines="0" />
Email: sfigueiredo@av.it.pt</t>
<t>Stig Venaas
<vspace blankLines="0" />
Email: stig@venaas.com</t>
<t>Luis Miguel Contreras Murillo
<vspace blankLines="0" />
Telefonica I+D
<vspace blankLines="0" />
Email: lmcm@tid.es</t>
<t>Juan Carlos Zuniga
<vspace blankLines="0" />
InterDigital
<vspace blankLines="0" />
Email: JuanCarlos.Zuniga@InterDigital.com</t>
<t>Alexandru Petrescu
<vspace blankLines="0" />
Email: alexandru.petrescu@gmail.com</t>
<t>Georgios Karagiannis
<vspace blankLines="0" />
University of Twente
<vspace blankLines="0" />
Email: g.karagiannis@utwente.nl</t>
<t>Julien Laganier
<vspace blankLines="0" />
Juniper
<vspace blankLines="0" />
Email: julien.ietf@gmail.com</t>
<t>Wassim Michel Haddad
<vspace blankLines="0" />
Ericsson
<vspace blankLines="0" />
Email: Wassim.Haddad@ericsson.com</t>
<t>Dirk von Hugo
<vspace blankLines="0" />
Deutsche Telekom Laboratories
<vspace blankLines="0" />
Email: Dirk.von-Hugo@telekom.de</t>
<t>Ahmad Muhanna
<vspace blankLines="0" />
Award Solutions
<vspace blankLines="0" />
Email: asmuhanna@yahoo.com</t>
<t>Byoung-Jo Kim
<vspace blankLines="0" />
ATT Labs
<vspace blankLines="0" />
Email: macsbug@research.att.com</t>
<t>Hassan Ali-Ahmad
<vspace blankLines="0" />
Orange
<vspace blankLines="0" />
Email: hassan.aliahmad@orange.com</t>
<t>Alper Yegin
<vspace blankLines="0" />
Samsung
<vspace blankLines="0" />
Email: alper.yegin@partner.samsung.com</t>
<t>David Harrington
<vspace blankLines="0" />
Effective Software
<vspace blankLines="0" />
Email: ietfdbh@comcast.net</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
<?rfc include="reference.RFC.1157" ?>
<?rfc include="reference.RFC.4295" ?>
<?rfc include="reference.RFC.6475" ?>
<?rfc include="reference.RFC.3753" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.3164" ?>
<?rfc include="reference.RFC.6020" ?>
<?rfc include="reference.RFC.6241" ?>
<?rfc include="reference.RFC.6275" ?>
<?rfc include="reference.RFC.6632" ?>
<?rfc include="reference.RFC.7011" ?>
<?rfc include="reference.RFC.7012" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5380" ?>
<?rfc include="reference.RFC.5944" ?>
<?rfc include="reference.RFC.6301" ?>
<?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>
<author fullname="Charles Perkins" surname="Perkins" initials="C">
<organization/>
</author>
<date year="2014" day="26" month="April"/>
</front>
<seriesInfo value="draft-wakikawa-netext-pmip-cp-up-separation-03" name="Internet-Draft"/>
<format target="http://www.ietf.org/internet-drafts/draft-wakikawa-netext-pmip-cp-up-separation-03.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="10" 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</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="Journal of Communications, vol. 6, no. 1, pp. 4-15" />
</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:57:27 |