Internet DRAFT - draft-aliahmad-dmm-anchor-selection
draft-aliahmad-dmm-anchor-selection
DMM Working Group H. Ali-Ahmad (Ed.)
Internet-Draft Orange
Intended status: Informational D. Moses
Expires: January 12, 2014 H. Moustafa
Intel Corporation
P. Seite
Orange
T. Condexia
University of Aveiro
July 11, 2013
Mobility Anchor Selection in DMM: Use-case Scenarios
draft-aliahmad-dmm-anchor-selection-01.txt
Abstract
This document presents and discusses different use-case scenarios of
mobility anchor selection in Distributed Mobility Management (DMM).
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 January 12, 2014.
Copyright Notice
Copyright (c) 2013 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
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 1]
Internet-Draft Anchor Selection in DMM July 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Considered contexts . . . . . . . . . . . . . . . . . . . . . 5
3.1. Mobile node context . . . . . . . . . . . . . . . . . . . 5
3.2. Application context . . . . . . . . . . . . . . . . . . . 6
3.3. Network context . . . . . . . . . . . . . . . . . . . . . 8
4. Use-case scenarios . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Extremely mobile nodes without any typical location . . . 9
4.2. Mobile nodes with one or more typical locations . . . . . 10
4.3. Fairly stationary nodes . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 2]
Internet-Draft Anchor Selection in DMM July 2013
1. Terminology
IP-handover:
a handover of a mobile node at the IP level resulting in an IP
address change at the mobile node.
New flow:
a flow that did not undergo any IP-handover.
Handover flow:
a flow that did undergo one or more IP-handovers.
New traffic:
the data traffic of the new flows.
Handover traffic:
the data traffic of the handover flows.
Current access router:
the access router where the mobile node is currently attached at
the IP level.
DMM default mode of mobility anchor selection:
new flows are always anchored at the current access router which
acts as the mobility anchor for these flows after an IP-handover.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 3]
Internet-Draft Anchor Selection in DMM July 2013
2. Introduction
Distributed Mobility Management (DMM) aims at overcoming the
shortcomings of the existing IP mobility protocols, such as Mobile
IPv6 [RFC6275] and Proxy Mobile IPv6 [RFC5213], that are considered
centralized. It brings the mobility anchor closer to the mobile
node, down at the access routers level. This is the enabler of a
concept that is so-called dynamic mobility, where the mobile node
changes its mobility anchor for new flows. New flows are always
initiated using the mobile node's current IP address which is
configured using the prefix provided by the current access router.
The data traffic of these flows is then routed optimally until the
mobile node undergoes an IP-handover. However, upon an IP-handover,
tunneling mechanisms are needed with that access router, which is
then considered the mobility anchor of those flows initiated using
its prefix during the whole lifetime of those flows. In what
follows, this is considered the DMM default mode of mobility anchor
selection.
If most of the flows are short enough to not undergo one or more IP-
handovers, it is expected that most of the data traffic is routed
optimally. However, this assumption is not always valid and the
mobility anchor for new flows, when initiated, could be selected in a
more appropriate manner.
When a flow is initiated, it is assigned a mobility anchor that lasts
during its whole lifetime. Thus, selecting the most appropriate
mobility anchor for a flow when initiated can significantly enhance
the mobility management performance, e.g. less overhead, shorter end-
to-end delay. Thus, a DMM solution should allow selecting and using
the most appropriate mobility anchor among a set of distributed ones
[I-D.ietf-dmm-best-practices-gap-analysis]. In order to achieve
this, different metrics and contexts should be taken into
consideration. Distributing the mobility anchor functionalities at
the access routers level allows considering several contexts such as
the mobile node's mobility context, the application context, and the
network context.
Hereafter in this document, the considered contexts are presented and
then the different use-case scenarios are discussed.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 4]
Internet-Draft Anchor Selection in DMM July 2013
3. Considered contexts
3.1. Mobile node context
The mobile node's mobility has an important effect on the mobility
anchor selection. For example, a mobile node with high mobility
undergoes frequent IP-handovers. When considering DMM default mode
of mobility anchor selection, almost all the traffic of such mobile
node is handover traffic, moreover, the number of simultaneous
anchors and tunnels may increase. On the other hand, flows of mobile
nodes with low mobility are more likely to be initiated and
terminated before undergoing an IP-handover.
In addition, the mobile node's location with respect to the different
mobility anchors influences selecting one of them for new flows. For
example, locating the mobility anchor as close as possible to the
mobile node results in a shorter tunnel, and hence less tunneling
overhead, when tunneling mechanisms are required. The most
appropriate mobility anchor is the closest one to the mobile node
during the longer portion of the flow lifetime. At the instant of
initiating a new flow, the current access router is the closest one
to the mobile node. However, the mobile node may undergo an IP-
handover and attach to another access router. Whether the longer
portion of the flow is before or after the IP-handover has an effect
on selecting the most appropriate mobility anchor for this flow.
Moreover, a mobile node may have one or more "typical locations"
where it attaches to the network most of the time, e.g. at home.
This helps expecting the mobile node's location for relatively long
durations and, consequently, in selecting the most appropriate
mobility anchor by using information about typical location(s). Note
that some statistics show that users spend more than 60% of their
time at home and work [Cisco-VNI].
Finally, the mobile node's attachments history is needed in order to
take into consideration the mobile node's mobility and location as
described above.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 5]
Internet-Draft Anchor Selection in DMM July 2013
+---------+ +---------+ +---------+ +---------+
| AR/MA 1 | | AR/MA 2 | | AR/MA 3 | | AR/MA 4 |
+---------+ +---------+ +---------+ +---------+
|
|
+----+ AR: Access Router
---- movement ----> | MN | MA: Mobility Anchor
+----+ MN: Mobile Node
Figure 1: Mobile node's movement in DMM network
3.2. Application context
Based on the application, the need of IP continuity and the flow
characteristics can be estimated. While applications that require IP
continuity cause the establishment of tunnels in the access network
upon an IP-handover, applications that can tolerate an IP address
change at the application layer, e.g. SIP-based sessions, do not
[I-D.ietf-dmm-requirements]. The mobility anchor selection is less
important in the latter case due to the capability of changing the IP
address. In fact, there is no need for tunneling and hence no need
for a mobility anchor since the application can tolerate any change
in the IP address; hence, all the traffic is routed using standard
routing schemes.
In addition, the flow characteristics are highly dependent on the
application. Some applications generate in general long flows such
as multimedia (e.g. video streaming), online gaming, large files
downloading, etc. (see Table 1 below); others generate in general
short flows such as TCP connections for HTTP and SMTP sessions. Long
flows are more likely to undergo one or more IP-handovers and
therefore the mobility anchor selection can play an important role to
enhance the mobility management performance. On the other hand,
short flows are more likely to be initiated and terminated before an
IP-handover.
In the following table, we present some examples on different types
of applications. For each application, we mention the expected (or
probable) traffic and mobility characteristics as well as the
possible types of devices used for such application. The objective
of this list of applications is to show later some possible real
mapping(s) for the different use-case scenarios.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 6]
Internet-Draft Anchor Selection in DMM July 2013
+-------------+------------+------------+-------------+-------------+
| Application | Traffic | Mobility | User Device | Comments |
| | Type | Nature | | |
+-------------+------------+------------+-------------+-------------+
| RT Gaming | Long flows | Stationary | Laptop, | For game |
| | with IP | or mobile | tablet, | consoles, |
| | continuity | (depending | smartphone, | the device |
| | req | on game) | game | and traffic |
| | | | console | characteris |
| | | | | tics could |
| | | | | be easily |
| | | | | predicted |
| | | | | |
| Audio/Video | Long flows | Stationary | Smartphone, | |
| conferencin | with IP | or mobile | tablet, | |
| g | continuity | | laptop | |
| | req | | | |
| | | | | |
| Live | Long flows | Stationary | Large | If a large |
| streaming | with IP | or mobile | screen TV, | screen TV, |
| IPTV | continuity | | laptop, | client is |
| | req | | tablet, | stationary. |
| | | | smartphone | Otherwise, |
| | | | | client is |
| | | | | mobile |
| | | | | |
| Waze | Long flows | Mobile | Smartphone, | |
| | without IP | | dedicated | |
| | continuity | | car GPS | |
| | req | | (future) | |
| | | | | |
| GoPro | Long flows | Mobile | GoPro | A typical |
| | with IP | | camera | location |
| | continuity | | | (Ski |
| | req | | | resort) |
| | | | | |
| Video | Long flows | Stationary | Mobile | |
| Report | with IP | or mobile | surveillanc | |
| | continuity | | e, HD camer | |
| | req | | a | |
| | | | | |
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 7]
Internet-Draft Anchor Selection in DMM July 2013
| Video | Long flows | Mobile | Car TV, | If the car |
| streaming | with IP | | tablet, | is mainly |
| in vehicles | continuity | | smartphone | used in |
| | req | | | specific |
| | | | | neighborhoo |
| | | | | da typical |
| | | | | location i |
| | | | | srelevant |
| | | | | |
| Camcorder | Long flows | Stationary | Camcoder | |
| download | with IP | or mobile | | |
| | continuity | | | |
| | req | | | |
| | | | | |
| HTTP and | Short | Stationary | Smartphone, | |
| SMTP | flows with | or mobile | tablet, | |
| sessions | IP | | laptop | |
| | continuity | | | |
| | req | | | |
+-------------+------------+------------+-------------+-------------+
Table 1
3.3. Network context
When a mobility anchor is assigned to a flow (when the flow is
initiated), it acts as a mobility anchor for this flow the whole
flow's lifetime. It is responsible to forward the flow's data
packets if the mobile node is physically attached to it. It is
responsible, in addition, to encapsulate and de-capsulate the flow's
data packets if the mobile node is not attached to it and tunneling
mechanisms are used.
Even with distributed mobility anchors, the distribution of the
active mobile nodes in the network is not necessarily even. As a
result, some mobility anchors are overloaded more than others. It is
then reasonable to take into consideration the estimated (or
projected) level of load of the mobility anchors as well as the
access network characteristics/resources when selecting one of them
for a new flow (the metrics for measuring this level are left for
specific implementations).
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 8]
Internet-Draft Anchor Selection in DMM July 2013
4. Use-case scenarios
4.1. Extremely mobile nodes without any typical location
Extreme mobility could be due to either a high mobile node's
speed, or a small access router's coverage area, or both.
Scenario 1: running applications generating typically short flows
Short flows are more likely to be initiated and terminated before
the mobile node undergoes an IP-handover. Even if a flow
experiences an IP-handover, it is expected that the flow does not
last long after the IP-handover. In other words, most of the
mobile node's traffic is new traffic in this scenario. As a
result, the closest mobility anchor to the mobile node during the
longest portion of a flow is its current access router. It is
recommended then to always anchor new flows at the current access
router, which is the DMM default mode of mobility anchor
selection.
A well known example on short flows is the TCP connections for
HTTP and SMTP sessions.
Scenario 2: running applications generating typically long flows
For extremely mobile nodes, it is more likely that a flow
experiences an IP-handover soon after being initiated. And since
the flows are long-lived, it is expected that a flow lasts for a
long duration after the IP-handover(s). As a result, it could be
said that most of the traffic is handover traffic in this
scenario. Whatever is the mobility anchor selection criterion,
most of (almost all) the mobile node's data traffic needs
tunneling mechanisms. Thus, the mobility anchor selection cannot
play a significant role regarding the route optimization or the
tunneling overhead reduction.
However, there are number of consequences regarding the control
plane e.g. number of simultaneous anchors/tunnels for a mobile
node and the related contexts and signaling loads. First, let us
consider the DMM default mode of mobility anchor selection. Since
new flows are always anchored at the current access router, each
flow initiated between two consecutive IP-handovers is anchored at
a different mobility anchor. With extremely mobile node, long
flows are expected to experience several IP-handovers and their
mobility anchors are expected to be maintained for a long
duration. As a result, the number of simultaneous anchors/tunnels
for a mobile node may increase as well as the related contexts and
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 9]
Internet-Draft Anchor Selection in DMM July 2013
signaling loads. This affects the control plane negatively.
As the DMM default mode does not achieve data plane optimization
in the scenario described above, it is reasonable to consider a
more centralized approach for mobility anchor selection in order
to reduce the negative effects on the control plane. If data
packets are going to be tunneled in both cases, managing a single
tunnel to a single mobility anchor would be better than managing
several tunnels to several mobility anchors at the same time.
It is worth mentioning that the discussion above is considering
applications that require IP-address continuity. On the other
hand, there is no issue regarding the applications that allow an
IP address change and manage mobility at the application layer
since they do not need mobility anchors as mentioned before.
Some examples on this scenario are (cf. Table 1) RT gaming, audio/
video conferencing, live streaming IPTV, video report, video
streaming in vehicles, and camcorder download.
Scenario 3: running applications generating both long and short flows
In this case, short and long flows can be distinguished when
selecting a mobility anchor for a flow, based on scenario 1 and
scenario 2. Short flows are always anchored at the current access
router; long flows are anchored based on a more centralized
approach. In this way, data packets of short flows are generally
routed optimally and long flows do not introduce a large number of
simultaneous anchors/tunnels.
4.2. Mobile nodes with one or more typical locations
Scenario 4: running applications generating typically short flows
As the flows are short, there is no expected benefit from having a
typical location. If initiated when the mobile node is not at its
typical location, such flows are more likely to end quickly before
the mobile node goes back to its typical location. Otherwise,
they would be initiated and terminated when the mobile node is at
its typical location. As a result, the current access router is
always the best mobility anchor for new flows and hence the DMM
default mode of mobility anchor selection fits well this scenario.
When the car is used mainly for short distance usages, Waze (cf.
Table 1) could be an example on this scenario.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 10]
Internet-Draft Anchor Selection in DMM July 2013
Scenario 5: running applications generating typically long flows
In this scenario, having a typical location is expected to be
beneficial for the mobile node's mobility anchor selection. As
mentioned before, the best mobility anchor for a flow is the
closest one to the mobile node during the longer portion of this
flow. Then, the best mobility anchor for a flow could be in some
cases that of the typical location even if the flow is not
initiated there. For example, if the mobile node initiates a long
flow and then comes back (undergoing an IP-handover) quickly to
its typical location, the longer portion of the flow would be
after the IP-handover. Thus, it is reasonable to select the
typical location's mobility anchor for such flow when initiated.
This results in tunneling part of the flow's data traffic when
initiated but in routing optimally most of it afterwards.
The analysis described above would be still valid if the mobile
node has more than one typical location. However, the benefits
may not be in some cases as great as those of the one typical
location scenario, depending on the mobile node's movements. If
there is no clear benefit from selecting one out of the mobility
anchors, the network context (i.e. level of load on each mobility
anchor) comes into play leaning towards selecting the mobility
anchor that is less loaded. Another refinement is to add the time
of day to the statistics collection in the mobile node's
attachments history. If it is noticed that one of the typical
locations is more popular than the others, this helps in selecting
a mobility anchor according to the time of attachment.
Some examples on this scenario are (cf. Table 1) RT gaming, audio/
video conferencing, live streaming IPTV, GoPro, video report,
video streaming in vehicles, and camcorder download.
Scenario 6: running applications generating both long and short flows
If it is possible, the short and long flows should be
distinguished as follows. While short flows are assigned the
closest mobility anchor which is the current access router, long
flows are assigned the typical location's mobility anchor. In
this case, the mobile node uses several IP addresses
simultaneously e.g. the one related to the typical location for
all long flows and the current IP address for short flows. Hence,
the mobile node needs a source address selection mechanism in
order to distinguish between the different IP addresses when
initiating a flow.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 11]
Internet-Draft Anchor Selection in DMM July 2013
4.3. Fairly stationary nodes
Scenario 7: running similar or different applications
In fact, a fairly stationary node has one typical location for
almost all the time. The mobile node selects always the typical
location's mobility anchor, which is the current access router
most of the time.
Some examples on this scenario are (cf. Table 1) RT gaming, audio/
video conferencing, live streaming IPTV, video report, and
camcorder download.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 12]
Internet-Draft Anchor Selection in DMM July 2013
5. Security Considerations
TBD.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 13]
Internet-Draft Anchor Selection in DMM July 2013
6. IANA Considerations
This document has no actions for IANA.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 14]
Internet-Draft Anchor Selection in DMM July 2013
7. Acknowledgements
The authors would like to express their gratitude to Wu-Chi Feng and
Philippe Bertin for having discussions, sharing thoughts, or
providing reviews on anchor selection in DMM.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 15]
Internet-Draft Anchor Selection in DMM July 2013
8. References
8.1. Normative References
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
8.2. Informative References
[Cisco-VNI]
Cisco Systems Inc., "Cisco Visual Networking Index: Global
Mobile Data Traffic Forecast Update, 2009--2014", Cisco
VNI , February 2010.
[I-D.ietf-dmm-best-practices-gap-analysis]
Liu, D., Zuniga, J., Seite, P., Chan, A., and C.
Bernardos, "Distributed Mobility Management: Current
practices and gap analysis",
draft-ietf-dmm-best-practices-gap-analysis-01 (work in
progress), June 2013.
[I-D.ietf-dmm-requirements]
Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management",
draft-ietf-dmm-requirements-05 (work in progress),
June 2013.
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 16]
Internet-Draft Anchor Selection in DMM July 2013
Authors' Addresses
Hassan Ali-Ahmad (Editor)
Orange
Email: hassan.aliahmad@orange.com
Danny Moses
Intel Corporation
Email: danny.moses@intel.com
Hassnaa Moustafa
Intel Corporation
Email: hassnaa.moustafa@intel.com
Pierrick Seite
Orange
Email: pierrick.seite@orange.com
Tiago Condexia
University of Aveiro
Email: tscondeixa@ua.pt
Ali-Ahmad (Ed.), et al. Expires January 12, 2014 [Page 17]
