One document matched: draft-liu-mext-distributed-mobile-ip-00.txt
MEXT Working group D. Liu (Ed.)
Internet-Draft China Mobile
Intended status: Informational March 7, 2011
Expires: September 8, 2011
Distributed Deployment of Mobile IPv6
draft-liu-mext-distributed-mobile-ip-00
Abstract
This document describes a distributed deployment approach of mobile
IPv6 protocol.
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 September 8, 2011.
Copyright Notice
Copyright (c) 2011 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
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.
Liu (Ed.) Expires September 8, 2011 [Page 1]
Internet-Draft Distributed Mobile IP March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Distributed Mobility Deployment Scenario . . . . . . . . . . . 3
4. Limitations of Centralized Approach . . . . . . . . . . . . . 4
4.1. Non-optimal Routes . . . . . . . . . . . . . . . . . . . . 4
4.2. Non-optimality in Evolved Network Architecture . . . . . . 6
4.3. Low Scalability of Centralized Route and Mobility
Context Maintenance . . . . . . . . . . . . . . . . . . . 6
4.4. Wasting Resources to Support Mobile Nodes Not Needing
Mobility Support . . . . . . . . . . . . . . . . . . . . . 7
4.5. Complicated Deployment with Too Many Variants and
Extensions of MIP . . . . . . . . . . . . . . . . . . . . 7
4.6. Mobility Signaling Overhead with Peer-to-Peer
Communications . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Single Point of Failure and Attack . . . . . . . . . . . . 8
5. Distributed Mobility Deployment Solution . . . . . . . . . . . 8
6. Distributed Mobility Deployment Considerations . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Co-authors and contributors . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Liu (Ed.) Expires September 8, 2011 [Page 2]
Internet-Draft Distributed Mobile IP March 2011
1. Introduction
Mobile IPv6 and its variations are based on the similar principles
where a given mobility agent (e.g. the Home Agent (HA) in Mobile IP)
maintains Mobile Nodes (MNs) bindings. Data traffic is then
encapsulated between the MN and its mobility agent. These approaches
lead to the implementation of centralised architectures where both MN
context and traffic encapsulation need to be maintained at a central
network entity, the mobility agent. Thus, when hundreds of thousands
of MNs are communicating in a given communicating in a given cellular
network, a centralized mobility anchoring point causes well-known
bottlenecks and single point of failure issues, which requires costly
network dimensioning and engineering to be fixed. In addition,
tunnelling encapsulations impact the overall network efficiency since
they require the maintenance of MN's specific contexts in each tunnel
end nodes and they incur delays in packet processing and transport
functions. This document introduces a distributed approach of
deployment mobile ipv6 and its variations in a more optimal way
especially for the flat network architecture.
2. Conventions used in this document
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].
3. Distributed Mobility Deployment Scenario
The rapid increasing of mobile data traffic giving much pressure to
the mobile operator's core network. To lower the cost, it is now
preferable to offload the traffic that are not generated by mobile
services from the IP core of the mobile network (e.g. Internet
traffic should be offloaded). On the other hand, IP communications
with mobile services are routed via a centralized anchor point (e.g.,
the PGW in 3GPP/EPS mobile network). In current proposals for
network evolution, a local traffic anchor (i.e. a local gateway,
L-GW), usually located near the access router, is in charge of
offloading the traffic (e.g. Internet and local traffic).
Liu (Ed.) Expires September 8, 2011 [Page 3]
Internet-Draft Distributed Mobile IP March 2011
+----+
,-'' |CN |. +----------+
,' +----+ \---------| central |
/ Packet \ | anchor |
| Data | +----------+
\ Network ,' |
`. _, |
`-..____,,' *****************
* IP network * __...._
* * ,' `-.
+---------+ +----+ +----+ / Internet \
| Local |__ |L-GW| |L-GW|--- | Access |
| Content | +----+ +----+ \ ,'
| Delivery| * * `-._ _,'
| Network | ****************** `'''
+---------+ || ||
+----+ +----+
|AR1 | |AR2 |
+----+ +----+
| | |
| | |
MN1 MN2 MN3
Figure 1: Scenario of L-GW deployment
In this scenario, mobile ip deployment is different from traditional
centralized way. Considerations should be made to deploy mobile ip
in a more optimal way in this architecture.
4. Limitations of Centralized Approach
This section describes the problems or limitations in a centralized
mobility approach and compares it against the distributed approach.
4.1. Non-optimal Routes
Routing via a centralized anchor often results in a longer route.
Figure 2 shows two cases of non-optimized routes.
Liu (Ed.) Expires September 8, 2011 [Page 4]
Internet-Draft Distributed Mobile IP March 2011
+------+
|HA/LMA|
+------+
/\ \ \ +---+
/ \ \ \ |CDN|
/ \ \ \ +---+
/ \ \ \ |
/ \ \ \ |
+------+ +------+ +------+ +------+
|FA/MAG| |FA/MAG| |FA/MAG| |FA/MAG|
+------+ +------+ +------+ +------+
| |
---- ----
| CN | | MN |
---- ----
Figure 2: Non-optimized route when communicating with CN and when
accessing local content.
In the first case, the MN and the CN are close to each other but are
both far from the mobility anchor. Packets destined to the MN need
to be routed via the mobility anchor, which is not in the shortest
path. The second case involves a content delivery network (CDN). A
user may obtain content from a server, such as when watching a video.
As such usage becomes more popular, resulting in an increase in the
core network traffic, service providers may relieve the core network
traffic by placing these contents closer to the users in the access
network in the form of cache or local CDN servers. Yet as the MN is
getting content from a local or cache server of a CDN, even though
the server is close to the MN, packets still need to go through the
core network to route via the mobility anchor in the home network of
the MN, if the MN uses the HoA as the session identifier. In a
distributed mobility management design, mobility anchors are
distributed in different access networks so that packets may be
routed via a nearby mobility anchor function, as shown in Figure 2.
Due to the above limitation, with the centralized mobility anchor
design, route optimization extensions to mobility protocols are
therefore needed. Whereas the location privacy of each MN may be
compromised when the CoA of an MN is given to the CN, those mobility
protocol deployments that lack such optimization extensions will
encounter non-optimal routes, which affect the performance. In
contrast, route optimization may be naturally an integral part of a
distributed mobility management design.
Liu (Ed.) Expires September 8, 2011 [Page 5]
Internet-Draft Distributed Mobile IP March 2011
4.2. Non-optimality in Evolved Network Architecture
Centralized mobility management is currently deployed to support the
existing hierarchical mobile data networks. It leverages on the
hierarchical architecture. However, the volume of wireless data
traffic continues to increase exponentially. The data traffic
increase would require costly capacity upgrade of centralized
architectures. It is thus predictable that the data traffic increase
will soon overload the centralized data anchor point, e.g., the P-GW
in 3GPP EPS. In order to address this issue, a trend in the
evolution of mobile networks is to distribute network functions close
to access networks. These network functions can be the content
servers in a CDN, and also the data anchor point. Mobile networks
have been evolving from a hierarchical architecture to a more
flattened architecture. In the 3GPP standards, the GPRS network has
the hierarchy GGSN - SGSN - RNC - NB (Node B). In 3GPP EPS networks,
the hierarchy is reduced to P-GW - S-GW - eNB (Evolved NB). In some
deployments, the P-GW and the S-GW are collocated to further reduce
the hierarchy. Reducing the hierarchy this way reduces the number of
different physical network elements in the network, contributing to
easier system maintenance and lower cost. As mobile networks become
more flattened, the centralized mobility management can become non-
optimal. Mobility management deployment with distributed
architecture is then needed to support the more flattened network and
the CDN networks.
4.3. Low Scalability of Centralized Route and Mobility Context
Maintenance
Special routes are set up to enable session continuity when a
handover occurs. Packets sent from the CN need to be tunneled
between the HA and FA in MIP and between the LMA and MAG in PMIP.
However, these network elements at the ends of the tunnel are also
routers performing the regular routing tasks for ordinary packets not
involving a mobile node. These ordinary packets need to be directly
routed according to the routing table in the routers without
tunneling. Therefore, the network must be able to distinguish those
packets requiring tunneling from the regular packets. For each
packet that requires tunneling owing to mobility, the network will
encapsulate it with a proper outer IP header with the proper source
and destination IP addresses. The network therefore needs to
maintain and manage the mobility context of each MN, which is the
relevant information needed to characterize the mobility situation of
that MN to allow the network to distinguish their packets from other
packets and to perform the required tunneling. Setting up such
special routes and maintaining the mobility context for each MN is
more difficult to scale in a centralized design with a large number
of MNs. Distributing the route maintenance function and the mobility
Liu (Ed.) Expires September 8, 2011 [Page 6]
Internet-Draft Distributed Mobile IP March 2011
context maintenance function among different networks can be more
scalable.
4.4. Wasting Resources to Support Mobile Nodes Not Needing Mobility
Support
The problem of centralized route and mobility context maintenance is
aggravated when the via routes are set up for many more MNs that are
not requiring IP mobility support. On the one hand, the network
needs to provide mobility support for the increasing number of mobile
devices because the existing mobility management has been designed to
always provide such support as long as a mobile device is attached to
the network. On the other hand, many nomadic users connected to a
network in an office or meeting room are not even going to move for
the entire network session. It has been studied that over two-thirds
of a user mobility is local. In addition, it is possible to have the
intelligence for applications to manage mobility without needing help
from the network. Network resources are therefore wasted to provide
mobility support for the devices that do not really need it at the
moment. It is necessary to dynamically set up the via routes only
for MNs that actually undergo handovers and lack higher-layer
mobility support. With distributed mobility anchors, such dynamic
mobility management mechanism may then also be distributed.
Therefore, dynamic mobility and distributed mobility may complement
each other and may be integrated.
4.5. Complicated Deployment with Too Many Variants and Extensions of
MIP
Mobile IP (MIP), which has primarily been deployed in a centralized
manner for the hierarchical mobile networks, already has numerous
variants and extensions including PMIP, Fast MIP (FMIP), Proxy-based
FMIP (PFMIP), hierarchical MIP (HMIP), Dual-Stack Mobile IP (DSMIP)
and there may be more to come. These different modifications or
extensions of MIP have been developed over the years owing to the
different needs that are found afterwards. Deployment can then
become complicated, especially if interoperability with different
deployments is an issue. While adaptations for MIP are being
proposed for the deployment in a distributed manner for more
flattened networks, it is desirable to also take a holistic view of
different networks and scenarios and integrate the different MIP
extensions. The result will then be a more comprehensive mobility
solution with options that can be turned on or off depending on
different scenarios. A desirable feature of mobility management is
to be able to work with network architectures of both hierarchical
networks and flattened networks, so that the mobility management
protocol possesses enough flexibility to support different networks.
In addition, one goal of dynamic mobility management is the
Liu (Ed.) Expires September 8, 2011 [Page 7]
Internet-Draft Distributed Mobile IP March 2011
capability to selectively turn on and off mobility support and
certain different mobility signaling. Such flexibility in the design
is compatible with the goal to integrate different mobility variants
as options. Some additional extensions to the base protocols may
then be needed to improve the integration.
4.6. Mobility Signaling Overhead with Peer-to-Peer Communications
In peer-to-peer communications, end users communicate by sending
packets directly addressed to each other's IP address. However, they
need to find each other's IP address first through signaling in the
network. While different schemes for this purpose may be used, MIP
already has a mechanism to locate an MN and may be used in this way.
In particular, MIPv6 Route Optimization (RO) mode enables a more
efficient data packets exchange than the bidirectional tunneling (BT)
mode. This RO mode is expected to be used whenever possible unless
the MN is not interested in disclosing its topological location,
i.e., the CoA, to the CN (e.g., for privacy reasons) or some other
network constraints are put in place. However, MIPv6 RO mode
requires exchanging a significant amount of signaling messages in
order to establish and periodically refresh a bidirectional security
association (BSA) between an MN and its CN. While the mobility
signaling exchange impacts the overall handover latency, the BSA is
needed to authenticate the binding update and acknowledgment messages
(note that the latter is not mandatory). In addition, the amount of
mobility signaling messages increases further when both endpoints are
mobile. A dynamic mobility management capability to turn off these
signaling when they are not needed will enable the RO mode between
two mobile endpoints at minimum or no cost. It will also reduce the
handover latency owing to the removal of the extra signaling. These
benefits for peer-to-peer communications will encourage the adoption
and large-scale deployment of dynamic mobility management.
4.7. Single Point of Failure and Attack
A centralized mobility anchoring architecture is generally more
vulnerable to a single point of failure or attack, requiring
duplication and backups of the support functions. On the other hand,
a distributed mobility management architecture has intrinsically
mitigated the problem to a local network which is then of a smaller
scope. In addition, the availability of such functions in
neighboring networks has already provided the needed architecture to
support protection.
5. Distributed Mobility Deployment Solution
One solution to deploy Mobile IP in a flat architecture is to
Liu (Ed.) Expires September 8, 2011 [Page 8]
Internet-Draft Distributed Mobile IP March 2011
implement the HA functionalities in the access routers, as shown on
Figure 2. Any given IP flow can be considered as implicitly anchored
on the current host's access router when set up.
In addition, dynamic mobility anchoring [I-D.kassi-mobileip-dmi]
could avoid data encapsulation for motionless nodes: until the host
does not move, the IP flow is delivered as for any standard IPv6
node. The anchoring function at the access router is acting only to
manage traffic indirection while the host moves to a new access
router. So, when the MN handoff, its current traffic is still
attached to the anchor access router which is responsible for
forwarding the IP flows to the MN.For example, let's consider an IP
flow, flow#1, initiated by the mobile node, MN, when attached to AR2.
Flow#1 will is routed in a standard way as long as the MN remain
attached to AR2. If the MN moves to AR3, flow#1 remains anchored to
AR2, which plays the role of HA. If MN starts a new IP
communication, flow#2, while attached to AR3; flow#2 will be routed
in a standard way as long as the MN remains attached to AR3. Then,
if the MN moves to AR1, flow#1 and flow#2 will be respectively
anchored to AR2/HA and AR3/HA.
+---+ +---+ +---+
|CN1| |CN2| |CN3|
+---+ +---+ +--,+
_.---------+----------. \
,----'' | `---'-.
,-' |flow#1 \ `-.
,' | ' `.
( IP Network| \
`. | ' ,'
`-. ; ,\'
;-----. ; _.----' '
,' `---------+----------'' |
/ | '
+---'---+ +---:---+ +-------+
| AR1 | | AR2`--|------------| AR3 |
| HA | | HA |------------|HA |
+-------+ +-------+ +-------+
flow#1 \\ \flow#2
tunnelled \\ '
+-----+ +--\--+
| MN | ----move-------> | MN |
+-----+ +-----+
Liu (Ed.) Expires September 8, 2011 [Page 9]
Internet-Draft Distributed Mobile IP March 2011
Figure 3: Distributed Client Based Mobility
6. Distributed Mobility Deployment Considerations
The following considerations should be applied in distributed mobile
ip deployment:
1. multiple home address handling
The mobile node will have multiple home agents associate with it.
Each home agent will assign a home address to the mobile node. The
applications on the mobile node need to select the right home address
to matain the session continuity. The sessions that established
before handover should use the home address which is allocated by the
previous home agent. The newly initiate session should use the home
address that newly allocated by the current home agent.
2. HA selection
The mobile node should select the nearest HA for its communication.
Mechanisms should be specified for the nearest HA selection.
3. CN initiate communication
Since the mobile node has multiple home addresses, the CN should
choose the proper home address to initate communication with the
mobile node. Mechanisms should be specified for CN to chose the
proper home address.
7. Security Considerations
TBD
8. IANA Considerations
None
9. Co-authors and contributors
The following people contributed to this document (in no specific
order):
Pierrick Seite: pierrick.seite@orange-ftgroup.com
Liu (Ed.) Expires September 8, 2011 [Page 10]
Internet-Draft Distributed Mobile IP March 2011
Hidetoshi Yokota: yokota@kddilabs.jp
Charles E. Perkins: charles.perkins@tellabs.com
Melia Telemaco: telemaco.melia@alcatel-lucent.com
Elena Demaria: elena.demaria@telecomitalia.it
Wassim Michel Haddad: Wassam.Haddad@ericsson.com
Jun Song: song.jun@zte.com.cn
Hui Deng: denghui@chinamobile.com
Zhen Cao: caozhen@chinamobile.com
other contributors and co-authors will be added in the update
version.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[I-D.chan-netext-distributed-lma]
Chan, H., Xia, F., Xiang, J., and H. Ahmed, "Distributed
Local Mobility Anchors",
draft-chan-netext-distributed-lma-03 (work in progress),
March 2010.
[I-D.ietf-mext-flow-binding]
Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
Basic Support", draft-ietf-mext-flow-binding-11 (work in
progress), October 2010.
[I-D.kassi-mobileip-dmi]
Kassi-Lahlou, M., "Dynamic Mobile IP (DMI)",
draft-kassi-mobileip-dmi-01 (work in progress),
January 2003.
[I-D.seite-netext-dma]
Seite, P. and P. Bertin, "Dynamic Mobility Anchoring",
Liu (Ed.) Expires September 8, 2011 [Page 11]
Internet-Draft Distributed Mobile IP March 2011
draft-seite-netext-dma-00 (work in progress), May 2010.
[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.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
Author's Address
Dapeng Liu
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: liudapeng@chinamobile.com
Liu (Ed.) Expires September 8, 2011 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 10:12:25 |