Distributed Mobility Anchoring
draft-seite-dmm-dma-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Pierrick Seite , Philippe Bertin | ||
| Last updated | 2012-02-03 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-seite-dmm-dma-00
Network Working Group P. Seite
Internet-Draft P. Bertin
Intended status: Informational France Telecom - Orange
Expires: August 6, 2012 February 3, 2012
Distributed Mobility Anchoring
draft-seite-dmm-dma-00.txt
Abstract
Most existing IP mobility solutions are derived from Mobile IP
principles where a given mobility anchor maintains Mobile Nodes (MNs)
binding up-to-date. Data traffic is then encapsulated between the
mobility anchor and the MN or its Access Router. These approaches
are usually implemented on a centralised architectures where both MN
context and traffic encapsulation need to be processed at a central
network entity, i.e. the mobility anchor. However, one of the trend
in mobile network evolution is to "flatten" mobility architecture by
confining mobility support in the access network, e.g. at the access
routers level, keeping the rest of the network unaware of the
mobility events and their support. This document discusses the
deployment of a Proxy Mobile IP approach in such a flat architecture.
The solution allows to dynamically distribute mobility functions
among access routers. The goal is also to dynamically adapt the
mobility support of the MN's needs by applying traffic redirection
only to MNs' flows when an IP handover occurs.
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 August 6, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Seite & Bertin Expires August 6, 2012 [Page 1]
Internet-Draft Distributed Mobility Anchoring February 2012
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.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basics of Dynamic Mobility Anchoring . . . . . . . . . . . . . 4
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Dynamic Mobility Anchoring . . . . . . . . . . . . . . . . 6
4.2. Protocol sequence for handover management . . . . . . . . 8
4.3. Difference with Proxy Mobile IPv6 . . . . . . . . . . . . 10
4.4. Multiple Interfaces support . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Seite & Bertin Expires August 6, 2012 [Page 2]
Internet-Draft Distributed Mobility Anchoring February 2012
1. Terminology
Proxy Mobile IPv6 inherited terminology
The following terms used in this document are to be interpreted as
defined in the Proxy Mobile IPv6 specification [RFC5213]; Mobile
Node (MN), home Network Prefix (HNP), Mobile Node Identifier (MN-
Identifier), Proxy Binding Update (PBU), and Proxy Binding
Acknowledgement (PBA).
Mobility capable Access Router (MAR)
The Mobility capable Access Router is an access router which
provides mobility management functions. It has both mobility
anchoring and location update functional capabilities. A Mobility
capable Access Router can act as a Home or as a Visited Mobility
capable Access Router (respectively H-MAR and V-MAR). Any given
MAR could act both as H-MAR and V-MAR for a given mobile node
having different HNPs, either allocated by this MAR (H-MAR role)
or another MAR on which the mobile node was previously attached
(V-MAR role).
* H-MAR: it allocates HNP for mobile nodes. Similarly to
[RFC5213], the H-MAR is the topological anchor point for the
mobile node's home network prefix(es) it has allocated. The
H-MAR acts as a regular IPv6 router for HNPs it has allocated,
and when a mobile node has moved away and attached to a V-MAR,
the H-MAR is responsible for: tracking the mobile node location
(i.e. the V-MAR where the mobile node is currently attached),
and forwarding packets to the V-MAR where the mobile node is
attached.
* V-MAR: it manages the mobility-related signaling for a mobile
node, using a HNP allocated by a MAR previously visited by the
mobile node, that is attached to its access link.
2. Introduction
Most existing IP mobility solutions are derived from Mobile IP
[RFC3775] principles where a given mobility agent (e.g. the Home
Agent (HA) in Mobile IP or the Local Mobility Agent (LMA) in Proxy
Mobile IPv6 [RFC5213]) maintains Mobile Nodes (MNs) bindings. Data
traffic is then encapsulated between the MN or its Access Router
(e.g. the Mobile Access Gateway (MAG) in PMIPv6) 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
Seite & Bertin Expires August 6, 2012 [Page 3]
Internet-Draft Distributed Mobility Anchoring February 2012
cellular network, such a centralised network entity 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. Such centralised approach provides the ability to route
MN traffic whatever its localisation is, as well as to support
handovers when it moves from access router to access router.
It is however well established that a huge amount of mobile
communications are set up while the user is not physically moving,
i.e. its MN stays in the same radio cell. For example, the user is
being communicating at home, in his office, at a cafe... Applying
the aforementioned centralised principles leads then to aggregate
user's contexts and traffic at a central node in the network for the
sake of mobility support whereas the MN remains motionless. As this
leads to the introduced scalability and performances issues,
alternative approaches may consider a way to better adapt mobility
support in the network to cope with MN's movements and its ongoing
traffic flows' requirements. Typically, one of the trend in the
evolution of mobile networks is to go on flat architecture with the
distribution of network functions, including mobility functions
[I-D.liu-distributed-mobility]. According to this principle,
[I-D.chan-netext-distributed-lma] proposes a deployment of Proxy
Mobile IPv6 in a flat architecture by splitting the location
management and routing functions of the LMA.
In this document, we propose a slightly different approach by
dynamically distributing mobility handling among terminals and access
routers. This document inherits from concepts introduced in
[NTMS2008]. The goal is twofold:
o dynamically adapting mobility support to each of the MN's needs by
applying traffic redirection only to MNs' flows that are already
established when an IP handover occurs;
o confining the mobility support at the access routers level,
keeping the rest of the network unaware of mobility events and
their support.
3. Basics of Dynamic Mobility Anchoring
In a standard IPv6 network without specific mobility support, any
host is able to set up communications flows using a global IPv6
address acquired with the support of its current access router
[RFC4862]. When the host moves from this access router to a new one,
its ongoing IP sessions cannot be maintained without leveraging on IP
mobility mechanisms.
Seite & Bertin Expires August 6, 2012 [Page 4]
Internet-Draft Distributed Mobility Anchoring February 2012
However, once attached to the new access router, the host can again
acquire a routable global IPv6 address to be used for any new
communication flow it sets up. Hence, a flow based mobility support
may be restricted to provide traffic indirection to host's flows that
are already ongoing during host's handovers between access routers.
Any new flow being set up uses the new host's global address acquired
on the new link available after the handover.
When a multiple-interface host moves between access routers of
different access technologies, such a simple approach can also be
applied, considering that each network interface provides dynamically
global IPv6 addresses acquired on current access routers. Flows
mobility is then required only to support the necessary traffic
indirection from the access router on which the flow has been
initially set up to the access router the host is currently attached.
Such IP based indirection can even be made independent from access
technologies types, providing thus inherent inter-access mobility
facilities.
Hence, any given IP flow can be considered as implicitly anchored on
the current MN's access router when being set up. While the MN is
attached to its initial access router, the IP flow is delivered as
for any standard IPv6 node. The anchoring function at the access
router is thus needed only to manage traffic indirection if the MN
moves to a new access router (and for subsequent movements while the
IP flow remains active), maintaining the flow communication until it
ends up.
Any flow's incoming packet toward the MN is routed in a standard way
to the access router anchoring the flow as the packet contains the
destination IP address issued from router prefix. Then, if the MN is
currently attached to the initial anchor access router, the incoming
packet is directly delivered over the access link. Otherwise, the
anchoring access router needs to redirect the packet to the current
(or one of the currents) MN's access router(s).
Any flow's outgoing packet from the MN is sent over either the
initial anchor access router link or another access router link it is
currently using. In the first case, the packet can be routed in a
standard way, i.e., without requiring networks mobility support
functions. In the second case, we consider its redirection to the
initial flows' anchor router, but it may be noticed that direct
routing by the current access router may be also allowed (yet this
may lead to more stringent security and policy considerations).
Seite & Bertin Expires August 6, 2012 [Page 5]
Internet-Draft Distributed Mobility Anchoring February 2012
4. Solution Overview
4.1. Dynamic Mobility Anchoring
The basic idea is to distribute mobility traffic management with
dynamic user's traffic anchoring in access network nodes. The
solution relies on a very simple flat architecture outlined in
Figure 1 where the Mobility capable Access Router (MAR) supports both
traffic anchoring and MN's location management functionalities. The
architecture relies on a centralized database storing ongoing
mobility sessions for the MNs (see Section 4.2 for details). This
database stores the HNPs currently allocated to the MN and their
respective anchoring point. This database could be an extension to
the policy store used in [RFC5213].
+------------+
| session DB |
/ +------------+
+----------/--------|------\--+
( IP /Network | \ )
+--------/----------|------- \+
/ | \
+-------+ +-------+ + ------+
| MAR1 |___| MAR2 |____| MAR3 |
+-------+ +-------+ +-------+
|
+-----+
| MN1 |
+-----+
Figure 1: Architecture for Distributed Mobility Anchoring
Regular IPv6 routing applies when an IP communication is initiated.
For instance, if the mobile node (e.g. MN1), being attached to MAR1,
initiates a communication with CN1, the traffic will be routed
through MAR1 without requiring any specific mobility operation. When
MN1 moves away from MAR1 and attaches to MAR3, the traffic remains
anchored to MAR1 and is tunneled between MAR1 and MAR3. MAR1 becomes
the mobility anchor, but only for traffic initiated by MN1 when it
was attached to MAR1.
Communications newly initiated, e.g. to CN2, while the mobile node is
attached to MAR3 will be routed in a standard way via MAR3. So, MAR3
is both the mobility anchor, i.e. the H-MAR, for traffic newly
Seite & Bertin Expires August 6, 2012 [Page 6]
Internet-Draft Distributed Mobility Anchoring February 2012
initiated (i.e. when the mobile node is attached to MAR3) and the
V-MAR for traffic initiated while being attached to MAR1. If the
mobile node moves away from MAR3, while maintaining communications
with both CN1 and CN2, two mobility anchors come into play: the data
traffic will be anchored in MAR1 for communication with CN1 and in
MAR3 for communication with CN2. Summarizing , it is proposed to
locate mobility anchoring depending on where the flow is initially
created. Accordingly, communications are expected to be initiated
without requiring mobility anchoring and tunneling.
With this solution, even if a mobile node is moving across several
MARs, the tunnel endpoints are always on the initial H-MAR and on the
current V-MAR. In the case the mobile node moves from MAR1 to MAR2
then to MAR3, a tunnel will be firstly established between MAR1 and
MAR2 to forward HNP1; then a tunnel between MAR1 and MAR3 will be
established.
However such an architecture leads to new requirement on the HNP
prefix model. Actually, because the HNP is anchored to its mobility
anchor (i.e. H-MAR), a dynamic mobility anchoring requires that each
MAR must advertise different per-MN prefixes set. For example, if
MN1 is anchored to both MAR1 and MAR3, these two mobility capable
access routers would advertise respectively HNP1 and HNP3 for MN1.
Seite & Bertin Expires August 6, 2012 [Page 7]
Internet-Draft Distributed Mobility Anchoring February 2012
_______ _______
| | | |
| CN1 | | CN2 |
|_______| |_______|
'. Flow#2 .
Flow#1 ' '. | Flow#3
' '...'''''''''''''.... .
..''' '. '''..
.' ' '.IP network . '.
: ' '. | :
'..' +-------+ . ..'
'''... | | ....'''
' | MAR2 | \ .
MAR1 Forwarding Table ' | | \ |
+=====================+ ' | |'. \ .
HNP-1::/64 -> MAR3 ' +-------+\'. \ |
+-------+ \ '+ ------+
| | \ | |
| MAR1 |-----------------| MAR3 |
| |'''''''''''''''''| |
| |-----------------| |
+-------+ +-------+
' ' |
Flow#1 ' . . Flow#3
' ' |
+-----+ Flow#2 +-----+
| MN1 | -----move-------> | MN1 |
+-----+ +-----+
(single interface, IF1)
Figure 2: Distributed Mobility Anchoring
4.2. Protocol sequence for handover management
An example of handover management for a single interface mobile node
is depicted on Figure 3. The mobile node, MN1, is assumed to move
from MAR1 to MAR2. Following are the main steps of the handover
management process:
1. The mobile node, MN1, attaches to MAR1 which is responsible for
allocating the MN-HNP, e.g. HNP1 for MN1.
2. Hence, the mobile node can initiate and maintain data transport
sessions (with CN1 in the picture), using IP addresses derived
from HNP1, in a standard way while it remains attached to MAR1,
Seite & Bertin Expires August 6, 2012 [Page 8]
Internet-Draft Distributed Mobility Anchoring February 2012
i.e. mobility functions do not come into play.
3. The MN handoffs to MAR2 which will thus acts as V-MAR for HNP1.
Fistly, MAR2 retrieves the ongoing MN's mobility sessions from
the centralized sessions database; here only one mobility session
is ongoing: (MN::NHP1,MAR1). Then MAR2 proceeds to location
update for HNP1 with MAR1 (H-MAR role), i.e., PBU/PBA exchange
between MAR2 and MAR1.
4. MAR2 also allocates new HNPs for MN1; these HNPs are meant to be
used by application flows initiated after the handoff.
5. MAR1, playing the H-MAR role for HNP1, encapsulates MN1's traffic
and tunnels it to the V-MAR, i.e. MAR2, where packets are
decapsulated and delivered to the MN.
6. The mobile node can initiate and maintain new data transport
sessions, e.g. with CN2, using IP addresses derived from HNP2.
This traffic is routed in a standard way while the mobile node
remains attached to MAR2.
Seite & Bertin Expires August 6, 2012 [Page 9]
Internet-Draft Distributed Mobility Anchoring February 2012
MN1 MAR2 MAR1 CN1 CN2
| | | | |
| | | | |
L2 Attach | | | |
| | | | |
|----------------RS---------->| | |
| | | MAR1 allocates |
| | | and advertises HNP1
| | | MAR1 updates MN's
| | | mobility session
|<---------------RA-----------| up to the database
| | | | |
comm. to CN1 using HNP1 | | |
|<----------------data-flow#1--------->| |
| | | | |
handover | | | |
to MA2 | | | |
|-----RS----->| MAR2 allocates| | |
| | HNP2 for new communications |
| | and retrieve the anchoring point
| | from the centralized database |
| |----pBU------->| | |
| | | | |
| |<---pBA--------| | |
|<---RA-------| | | |
| | | | |
handover | | | |
completed | | | |
| | | | |
|<---flow#1 --|<===tunnel====>|------->| |
| | | | |
comm. to CN2 using HNP2 | | |
| | | | |
|<-----------------data-flow#2----------------->|
| | | | |
| | | | |
Figure 3: Handover management with Distributed Mobility Anchoring
4.3. Difference with Proxy Mobile IPv6
A V-MAR is required to advertise new per-MN HNP set for new IP
communications to be initiated, while Proxy Mobile IPv6 advertises
the same HNPs when roaming from MAG to MAG. So, while Proxy Mobile
IPv6 is based on the per-MN prefix model, this proposal leverages on
a per-MN and per-MAR prefix model. It is not required to statically
Seite & Bertin Expires August 6, 2012 [Page 10]
Internet-Draft Distributed Mobility Anchoring February 2012
allocate different set of HNPs per MAR. Actually, at a given time,
only active MARs for an MN (i.e. access routers on which the mobile
node is currently attached to) need to share the per-MN HNPs set.
So, for the sake of scalability, per-MN HNPs should be dynamically
shared out among MN's active MARs.
Since each MAR anchors the IP traffic initiated when the mobile node
was attached to it, a mobile node may be served simultaneously by
more than one mobility anchor at the same time.
4.4. Multiple Interfaces support
The distribution of mobility functions can also apply in the context
of multiple-interfaces terminals. In such a case, any given IP flow
can be considered as implicitly anchored on the current host's access
router when set up. Until the host does not move from the initial
access router (H-MAR), the IP flow is delivered as for any standard
IPv6 node. The anchoring function at the H-MAR is thus managing
traffic indirection only if one, or several, IP flow(s) are moved to
another interface, and for subsequent movements while the initial
anchored flows remain active. This anchoring is performed on a per-
flow basis and each H-MAR needs to track all possible V-MARs for a
given host on the move. The H-MAR must also manage different tunnels
for a given mobile node providing that the node is multihomed and it
simultaneously processes different IP flows on its interfaces.
Lets consider a simple example to illustrate the dynamic per-flow
mobility anchoring. Figure 4 depicts the IP flow mobility management
for a mobile node with two interfaces. The IP data flows, Flow#1 and
Flow#2, have been initiated on if1. Thus, Flow#1 and Flow#2, using
respecively prefixes HNP1 and HNP2, are anchored to MAR1. Referring
to the picture, Flow#1 has not been moved; so Flow#1 is delivered in
a standard IPv6 way. Flow#2 has been transferred from If1 to If2, so
the the Flow#2 packets, corresponding to HNP2, are tunneled from MAR1
to MAR2. In other words, MAR1 and MAR2 are respectively the H-MAR
anchor and the V-MAR for flow#2.
Seite & Bertin Expires August 6, 2012 [Page 11]
Internet-Draft Distributed Mobility Anchoring February 2012
_______ _______
| | | |
| CN1 | | CN2 |
|_______| |_______|
' .
Flow#1 ' | Flow#2
' ...'''''''''''''.... .
..''' '''..
.' ' IP network . '.
: ' | :
'..' . ..'
'''.....................'|'
' .
' |
' .- . - . - . - . - . - .
' |
+-------+ Flow#2 + ------+
| | tunneled | |
| MAR1 |-----------------| MAR2 |
|(H-MAR)| -.-.-.-.-.-.-.-.|(V-MAR)|
| |-----------------| |
+-------+ +----|--+
' .
Flow#1 ' | Flow#2
' .
' If1 +-----+ If2 |
''''''''''| MN | - . - .
+-----+
Figure 4: Distributed IF flow Mobility Anchoring
In case of the handover of an IP flow between interfaces, the mobile
node must rely on the logical interface support, as per
[I-D.ietf-netext-logical-interface-support].
5. Security Considerations
TBD.
6. IANA Considerations
This document has no actions for IANA.
Seite & Bertin Expires August 6, 2012 [Page 12]
Internet-Draft Distributed Mobility Anchoring February 2012
7. Acknowledgements
The authors would also like to express their gratitude to Hidetoshi
Yokota, Telemaco Melia, Dapeng Liu, Anthony Chan, Julien Laganier,
Lucian Suciu, Servane Bonjour, Karine Guillouard and many others for
having shared thoughts on the concept of distributed mobility.
8. References
8.1. Normative References
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
8.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-netext-logical-interface-support]
Melia, T. and S. Gundavelli, "Logical Interface Support
for multi-mode IP Hosts",
draft-ietf-netext-logical-interface-support-04 (work in
progress), October 2011.
[I-D.liu-distributed-mobility]
Liu, D., Cao, Z., Seite, P., and H. Chan, "Distributed
mobility management", draft-liu-distributed-mobility-02
(work in progress), July 2010.
[NTMS2008]
Bertin, P., "A Distributed Dynamic Mobility Management
Scheme designed for Flat IP Architectures.", NTMS'2008 ,
November 2008.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Seite & Bertin Expires August 6, 2012 [Page 13]
Internet-Draft Distributed Mobility Anchoring February 2012
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
Authors' Addresses
Pierrick Seite
France Telecom - Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512
France
Email: pierrick.seite@orange.com
Philippe Bertin
France Telecom - Orange
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512
France
Email: philippe.bertin@orange.com
Seite & Bertin Expires August 6, 2012 [Page 14]