Network Working Group H. Yokota
Internet-Draft KDDI Lab
Intended status: Informational P. Seite
Expires: April 21, 2011 France Telecom - Orange
E. Demaria
Telecom Italia
Z. Cao
China Mobile
October 18, 2010
Use case scenarios for Distributed Mobility Management
draft-yokota-dmm-scenario-00.txt
Abstract
This document explores applicability of Distributed Mobility
Management (DMM) and use case scenarios for different parts of the
mobile network. DMM approaches and scenarios are divided into two
cases: partially and fully distributed. For each case, benefits and
issues are provided. It also refers to applicability of existing
protocols and necessity of development of new protocols in order to
provide a guideline for best suited solutions for the target
architecture.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Yokota, et al. Expires April 22, 2011 [Page 1]
Internet-Draft dmm-scenario October 2010
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Yokota, et al. Expires April 22, 2011 [Page 2]
Internet-Draft dmm-scenario October 2010
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicable networks for DMM . . . . . . . . . . . . . . . . . 6
3.1. Mobile core network . . . . . . . . . . . . . . . . . . . 6
3.2. Access network . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Host to host . . . . . . . . . . . . . . . . . . . . . . . 7
4. Approaches for DMM . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Partially distributed approach . . . . . . . . . . . . . . 8
4.1.1. Control/data plane separation . . . . . . . . . . . . 8
4.1.2. Dynamic mobility management . . . . . . . . . . . . . 9
4.2. Fully distributed approach . . . . . . . . . . . . . . . . 10
4.2.1. P2P type of network (search and delivery) . . . . . . 10
4.2.2. Broadcast/multicast type of network (multiple
delivery) . . . . . . . . . . . . . . . . . . . . . . 11
5. Analysis for applicability . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Yokota, et al. Expires April 22, 2011 [Page 3]
Internet-Draft dmm-scenario October 2010
1. Requirements notation
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 [RFC2119].
Yokota, et al. Expires April 22, 2011 [Page 4]
Internet-Draft dmm-scenario October 2010
2. Introduction
Rich content applications, emergence of smart-phones, USB dongles and
higher-speed radio access systems are all requiring an exorbitantly
high capacity mobile network. Mobility management has adopted a
centralized and often hierarchical architecture, for example, Home
Agent/Foreign Agent in Mobile IPv4[RFC3344], LMA/MAG in Proxy Mobile
IPv6[RFC5213], GGSN/SGSN in GPRS, PDN GW/Serving GW in EPC. However,
in order to accommodate ever increasing mobile data traffic, more
scalable and distributed architecture needs to be introduced.
Existing mobility management protocols, which are designed for a
centralized architecture, may need to be extended accordingly. Based
on the problem statement in [DMM-PS], this document explores
applicability of distributed mobility management and use case
scenarios to provide a guideline for best suited solutions.
Yokota, et al. Expires April 22, 2011 [Page 5]
Internet-Draft dmm-scenario October 2010
3. Applicable networks for DMM
Distributed mobility management can be applied at different parts of
the mobile network. This section introduces possible scenarios for
introducing DMM.
+----------+ +----------+ +----------+ \
| HA/LMA | | HA/LMA | ... | HA/LMA | Core-level |
+----+-----+ +-----+----+ +-----+----+ |
_____|_____________|________________|_____ | Mobile
(__________________________________________) > Core
| | | | Network
+----+-----+ +-----+----+ +-----+----+ |
| AR/FA/MAG| | AR/FA/MAG| ... | AR/FA/MAG| AR-level |
+----------+ +----------+ +----------+ /
_____|_____________|________________|_____
(__________________________________________)
| | | | \
+--+--+ +--+--+ +--+--+ +--+--+ |
| AP | | AP | | AP | ... | AP | Access-level > Access
+-----+ +-----+ +-----+ +-----+ | Network
| | | /
+--+ +--+ +--+
|MH|--->|MH| |MH| Host-level
+--+ +--+ +--+
Figure 1: Multiple level of distribution
3.1. Mobile core network
Conventional mobility management assumes a single mobility anchor per
MH (e.g., home agent), which has been regarded as a negative aspect
due to the cause of concentration of mobile data traffic and a single
point of failure. By topologically distributing mobility anchors,
mobile hosts can be managed in a decentralized way and mobile data
traffic can also be distributed ("Core-level" distribution in
Figure 1). If each mobility anchor covers specific geographical area
and a mobile host crosses this boundary, change of the mobility
anchor occurs, and this handover must be handled properly by, for
example, transferring the binding information of the mobile host from
the old to the new mobility anchor. When different mobility anchors
manage different blocks of IP addresses, packet delivery to/from the
mobile host must also be assured after handover.
If the mobile network adopts hierarchical architecture, such as home
agent and foreign agent in Mobile IPv4 or local mobility anchor and
mobile access gateway in PMIPv6, more flat architecture can be
considered by confining the mobility management within a specific
Yokota, et al. Expires April 22, 2011 [Page 6]
Internet-Draft dmm-scenario October 2010
region and directly exchanging mobile data at a specific level of
hierarchy ("AR-level" distribution in Figure 1). The former approach
is regarded as localized mobility management and the latter as route
localization. Several methods and protocols have been proposed, but
no universal and self-contained protocol exists. Moreover, there are
different possibilities to distribute mobility functions. The
mobility anchors may be confined to the first access router; but less
flat mobility architecture is also possible where a flatten mobility
anchor is meant to anchor the traffic of several access routers.
3.2. Access network
Location of information content is getting distributed and closer to
users. Consumer Generated Media (CGM) contributed by end users can
be innately located in a distributed manner. Content Delivery
Network, which has been constructed near the backbone network, is
getting more distributed along with cache technology and closer to
the access network for further efficient use of network resources.
As a wireless access method, WiFi is rapidly prevailing and its
access points are being more installed in residential and public
areas. As for the cellular system as well, picocell or femtocell are
gaining higher attention for more efficient spectrum usage and data
traffic offload (e.g., 3GPP LIPA/SIPTO). These access nodes
basically have layer 2 capability, but by adding layer 3 capability,
they can handle IP-level mobility management working as, for example,
a foreign agent or MAG ("Access-level" distribution in Figure 1).
The same protocol can be applied as in Section 3.1, but the number of
access nodes (i.e., WiFi APs or pico/femto-cells) is much larger to
the home agent and more frequent handover is likely to happen.
Therefore, scalability and signaling overhead need to be more
carefully considered.
3.3. Host to host
This is more peer-to-peer approach, whereby once the corresponding
host is found, both hosts directly communicate ("Host-level"
distribution in Figure 1). In order to discover the peer host,
information server such as DNS is required in the network, which can
be centralized or distributed. While MIPv6[RFC3775] is not a peer-
to-peer communication protocol, its route optimization mechanism can
provide a host-to-host communication leveraging the home agent.
Yokota, et al. Expires April 22, 2011 [Page 7]
Internet-Draft dmm-scenario October 2010
4. Approaches for DMM
4.1. Partially distributed approach
Distributed approach can be applied partially (1) by considering the
separation of control and data planes with taking advantage of
differences in traffic volume or host behavior, and/or (2) by
providing mobility only to the hosts who really need it, thereby
saving resources for mobility management.
4.1.1. Control/data plane separation
Conventional mobility management protocols such as Mobile IP or Proxy
Mobile IP combine the control and data planes, which means that all
signaling packets and data packets go through the home agent or local
mobility anchor (MIPv6 route optimization[RFC3775] is not
considered). The volume of data traffic is much higher than that of
control traffic, so by separating the control and data planes and
applying a distributed architecture to the data plane, effective
traffic distribution can be achieved without reallocating mobility
anchors during the session, as described in Section 3.1. This
simplifies the interaction between distributed mobility anchors
(MAs), but new signaling between the control and data plane
functional entities is required.
A partially distributed mobility management is depicted in Figure 2.
In this example, the routing function of the mobility anchor (MA) is
confined with the access router, but less flat deployment is also
possible (see Section 3.1). If the mobile host attaches to MA1 and
initiates an IP communication with a correspondent host (CH), the
traffic will be anchored to MA1. When performing handover to MA2,
the control function updates the routing state of MA1 in order to
forward packets to the new MH's location. Registration update to the
control function may be initiated by the host or controlled by the
network.
Yokota, et al. Expires April 22, 2011 [Page 8]
Internet-Draft dmm-scenario October 2010
+----------+ Registration
|Control |<-------------------+
| Function |------------------+ |
+----------+ Route Setup | |
^ | | |
Reg. V V |
+--|-------+ data +---|------+
| | *****************************| |
| | * MA1 | | *| MA2 |
+--|-*-----+ +--*|------+
| * *|
+|-*-+ +*|--+
| MH | | MH |
+----+ +----+
Figure 2: Control/data plane separation scenario
4.1.2. Dynamic mobility management
If the mobile host is nomadic meaning once attached, rarely moved, or
is idle in most of time, it should be enough to provide handover
capability only when it is really needed. This can save signaling
traffic and resources for maintaining mobility bindings. One
scenario, which is depicted in Figure 3, is that the mobile host
acquires an IP address (IP1) from the local access router (AR1) and
when this mobile host moves to another network, this local access
router plays a role of home agent to this mobile host and interacts
with the access router (AR2) in the new network for continuous packet
delivery.
Communications newly initiated with IP2 while the mobile host is
attached to AR2 will be routed in a standard way. In other words,
the mobile host plays with an IP flow to AR1 (the IP flow initiated
while attached to AR1) and an IP flow via AR2.
If the mobile node moves away from AR2, while maintaining
communications, two mobility anchors will come into play: the data
traffic will be anchored in AR1 for communication initiated via AR1
and in AR2 for communication initiated via AR2.
Yokota, et al. Expires April 22, 2011 [Page 9]
Internet-Draft dmm-scenario October 2010
data:IP1 +--------+
*************| | data:IP2
* **********| CH |oooooooooo
* * +--------+ o
*->* o
* * o
+--*--*----+ +----o-----+
| * * AR1| _______________ | o AR2|
| * *******)_______________)**** o |
+--*-------+ +--*-o-----+
*<--IP1 IP1-->* o<--IP2
+*---+ +*-o-+
| MH | -------------> | MH |
+----+ +----+
Figure 3: Dynamic mobility management
Dynamic mobility management can be combined with the approaches for
control/data plane distribution considered in this document (i.e.,
separation of control and data planes in Section 4.1.1 and fully
distributed approach in Section 4.2).
4.2. Fully distributed approach
This section describes the distribution schemes applied to both
control and data planes. One of the most significant issues of the
distributed control plane (e.g., distributed home agents), is that a
special mechanism is needed to identify the mobility anchor that
maintains the mobility binding of the mobile host.
In a fully distributed mobility management, the routing and control
functions of the mobility anchor (MA) are confined with an access
router, but less flat deployment is also possible (see Section 3.1).
If the mobile host attaches to a MA and initiates an IP communication
with a correspondent node, the traffic will be anchored to this MA.
When performing handover to another MA, this movement will be shared
by these two MAs or all MAs or may be handled independently. The
previous MA can forward packets to the new MH's location with this
information. Registration update to the control function can be
initiated by the host or controlled by the network.
The following subsections provide clues to fully distributed mobility
management schemes.
4.2.1. P2P type of network (search and delivery)
This approach searches for the correct mobility anchor before
delivering packets. Distributed Hash Table (DHT) is a popular
Yokota, et al. Expires April 22, 2011 [Page 10]
Internet-Draft dmm-scenario October 2010
mechanism for its efficiency. However, as the number of mobility
anchors increases, the number of hops increases and the search time
cannot be ignored. Also, when the mobile host moves to another
network, the location information needs to be updated and according
to the search scenario, this information may need to be disseminated
among distributed mobility anchors. The user data can be
continuously delivered to the MH in the new location by, for example,
the new MA's searching for the old MA and getting data forwarded from
it.
+----------+
Search | | Search
+--------->| MA |<-------+
| +----------+ |
| |
V V
+----------+ Search +----------+
| |<---------------->| |
| MA**************************** MA |
+--^--*----+ data +--*-^-----+
Reg.* * |Reg.
+|--*+ +*-|-+
| MH | | MH |
+----+ +----+
Figure 4: P2P type of network
4.2.2. Broadcast/multicast type of network (multiple delivery)
In this approach, packets are delivered to all or multiple mobility
anchors and only the corresponding mobility anchor delivers the
packets to the mobile host. This does not require the search
mechanism and the signaling between MAs is not mandatory when the MH
moves to a new location, but the use of the network resources is not
efficient since the packets are multiply delivered. This is
effective and feasible in relatively limited areas; from local to
metropolitan areas, but not suitable for the global area network.
Yokota, et al. Expires April 22, 2011 [Page 11]
Internet-Draft dmm-scenario October 2010
+----------+ +----------+
| | data | |
| MA | **************| MA |
+----------+ * +----------+
data * *
* *
+-----*----+ * +----------+
| *********** | |
| MA**************************** MA |
+--^--*----+ data +--*-^-----+
Reg.* * |Reg.
+|--*+ +*-|-+
| MH | | MH |
+----+ +----+
Figure 5: BC/MC type of network
Yokota, et al. Expires April 22, 2011 [Page 12]
Internet-Draft dmm-scenario October 2010
5. Analysis for applicability
In the case where the current hierarchical mobile network
architecture should be maintained, Core-level distribution is one
scenario and a new protocol is needed to handle the reallocation of
HA/LMA for an active session. If a more flat architecture is
desired, the role of the HA/LMA should be minimized and AR-level or
Access-level distribution is a more preferred scenario. Two
scenarios can be envisaged: only the routing functions of mobility
anchors can be distributed or the mobility management can be fully
distributed, meaning that both the control and routing functions of
mobility anchors are distributed closer to the access routers. In
the first scenario, the control/data plane separation is considered;
in this case, a new protocol between the control functional entity,
which maintains the mobility bindings, and the data functional
entity, which routes data packets to the corresponding peer entity,
is needed.
Distributing the mobility anchor close to the access would lead to
inter AR/MAG mobility. In this case, inter-AR/MAG communications
features of FMIPv4/v6[RFC4988][RFC5568] or PFMIPv6[RFC5949] can be
used. When PMIPv6 is used, Localized routing for PMIPv6[ID-PMIPv6LR]
can be considered for direct routing between MAGs. Note that the
scenario where the LMAs are distributed is not included in this work.
For Host-level distribution, MIPv6 route optimization mechanism can
be a candidate to support this scenario.
Distribution of mobility anchors facilitates the dynamic mobility
management since IP flows can be individually anchored close to the
access router on which the host was attached when initiating the IP
communication. Dynamic feature may not require specific support and
existing mobility protocols could be used. An example of fully
distributed and dynamic mobility management is described in [ID-DMA].
Depending on the mobility scenario, the mobile host may have two IP
addresses: one for direct communication and another for mobility,
which must be sustained before and after handover, in which case the
mobile host needs to be capable of distinguishing them (with the help
of the network).
If fully distributed approach is sought, a mechanism to find the
network node that holds the location of the mobile host needs to be
clarified. This document gives only clues for solutions but detailed
work in the area is clearly needed. The broadcast/multicast approach
is a simpler scenario and may not require a specific signaling
protocol This approach, however, will be more suitable for a limited
scope of network; for example, campus network, metropolitan area
network or data center network could benefit from this approach.
Yokota, et al. Expires April 22, 2011 [Page 13]
Internet-Draft dmm-scenario October 2010
6. Security Considerations
Security aspect is not considered in this document.
Yokota, et al. Expires April 22, 2011 [Page 14]
Internet-Draft dmm-scenario October 2010
7. IANA Considerations
This specification does not require any IANA Actions.
Yokota, et al. Expires April 22, 2011 [Page 15]
Internet-Draft dmm-scenario October 2010
8. Co-authors and Contributors
This document is a joint effort by the following participants as well
as those on the authors' list. Each individual has made significant
contributions to this work.
Dapeng Liu: liudapeng@chinamobile.com
H. Anthony Chan: h.a.chan@ieee.org
Charles E. Perkins: charles.perkins@tellabs.com
Telemaco Melia: telemaco.melia@alcatel-lucent.com
Hui Deng: denghui@chinamobile.com
Wassim Haddad: Wassam.Haddad@ericsson.com
Yokota, et al. Expires April 22, 2011 [Page 16]
Internet-Draft dmm-scenario October 2010
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
July 2009.
[RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
RFC 4988, October 2007.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
September 2010.
9.2. Informative References
[DMM-PS] Chan, H., Ed., "Problem statement for distributed and
dynamic mobility management",
draft-chan-distributed-mobility-ps-00, October 2010.
[ID-DMA] Seite, P., Ed. and P. Bertin, "Dynamic Mobility
Anchoring", draft-seite-netext-dma-00.txt , March 2010.
[ID-PMIPv6LR]
Krishnan, S., Ed., "Localized Routing for Proxy Mobile
IPv6", draft-krishnan-netext-pmip-lr-02 , July 2010.
Yokota, et al. Expires April 22, 2011 [Page 17]
Internet-Draft dmm-scenario October 2010
Authors' Addresses
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara, Fujimino
Saitama, 356-8502
Japan
Email: yokota@kddilabs.jp
Pierrick Seite
France Telecom - Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512
France
Email: pierrick.seite@orange-ftgroup.com
Elena Demaria
Telecom Italia
via G. Reiss Romoli, 274
TORINO, 10148
Italy
Email: elena.demaria@telecomitalia.it
Zhen Cao
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing, 100053
China
Email: zehn.cao@gmail.com
Yokota, et al. Expires April 22, 2011 [Page 18]