Internet DRAFT - draft-mccann-dmm-prefixcost
draft-mccann-dmm-prefixcost
IETF P. McCann, Ed.
Internet-Draft J. Kaippallimalil, Ed.
Intended status: Informational Huawei
Expires: October 13, 2016 April 11, 2016
Communicating Prefix Cost to Mobile Nodes
draft-mccann-dmm-prefixcost-03
Abstract
In a network implementing Distributed Mobility Management, it has
been agreed that Mobile Nodes (MNs) should exhibit agility in their
use of IP addresses. For example, an MN might use an old address for
ongoing socket connections but use a new, locally assigned address
for new socket connections. Determining when to assign a new
address, and when to release old addresses, is currently an open
problem. Making an optimal decision about address assignment and
release must involve a tradeoff in the amount of signaling used to
allocate the new addresses, the amount of utility that applications
are deriving from the use of a previously assigned address, and the
cost of maintaining an address that was assigned at a previous point
of attachment. As the MN moves farther and farther from the initial
point where an address was assigned, more and more resources are used
to redirect packets destined for that IP address to its current
location. The MN currently does not know the amount of resources
used as this depends on mobility path and internal routing topology
of the network(s) which are known only to the network operator. This
document provides a mechanism to communicate to the MN the cost of
maintaining a given prefix at the MN's current point of attachment so
that the MN can make better decisions about when to release old
addresses and assign new ones.
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."
McCann & Kaippallimalil Expires October 13, 2016 [Page 1]
Internet-Draft Prefix Cost April 2016
This Internet-Draft will expire on October 13, 2016.
Copyright Notice
Copyright (c) 2016 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Prefix Cost Sub-option . . . . . . . . . . . . . . . . . . . 5
4. Host Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Previous discussions on address agility in distributed mobility
management have focused on "coloring" prefixes with one of a small
number of categories, such as Fixed, Sustained, or Nomadic. The
assumption here is that the MN should use a permanent home address
for sessions that need a persistent IP address, and a local,
ephemeral address for short-lived sessions such as browsing.
However, a small set of address categories lacks expressive power and
leads to false promises being made to mobile nodes. For example, the
concept that a home address can be maintained permanently and offered
as an on-link prefix by any access router to which the MN may be
attached in future is simply not attainable in the real world. There
will always exist some access routers that do not have arrangements
in place with the home network to re-route (via tunneling or other
mechanisms) the home prefix to the current point of attachment.
McCann & Kaippallimalil Expires October 13, 2016 [Page 2]
Internet-Draft Prefix Cost April 2016
Conversely, the assumption that a Nomadic prefix will never be
available to an MN after it changes its current point of attachment
is too limiting. There is no reason why an MN should not be able to
keep a prefix that was assigned by a first network after it moves to
a second network, provided that measures are put in place to re-route
such prefixes to the new attachment point.
Rather, this document argues that there is in reality a continuum of
cost associated with an address as the MN moves from one attachment
point to another or from one network to another. The sources of the
cost are the increased latency, network bandwidth, and network state
being maintained by a network-based mobility management scheme to
route packets destined to the prefix to the MN's current point of
attachment. By communicating this cost to the MN every time its
attachment point changes, the MN can make intelligent decisions about
when to release old addresses and when to acquire new ones.
The cost should be communicated to the MN because of several
constraints inherent in the problem:
(1) The MN is the entity that must make decisions about allocating
new addresses and releasing old ones. This is because only the
MN has the information about which addresses are still in use by
applications or have been registered with other entities such as
DNS servers.
(2) Only the network has information about the cost of maintaining
the prefix in a network-based mobility management scheme,
because the MN cannot know the network topology that gives rise
to the inefficiencies.
If the cost of maintaining a prefix is not made available to the
mobile node, it may attempt to infer the cost through heuristic
mechanisms. For example, it can measure increased end-to-end latency
after a mobility event, and attribute the increased latency to a
longer end-to-end path. However, this method does not inform the MN
about the network bandwidth being expended or network state being
maintained on its behalf. Alternatively, a MN may attempt to count
mobility events or run a timer in an attempt to guess at which older
prefixes are more costly and in need of being released. However,
these methods fail because the number of mobility events is not an
indication of how far the MN has moved in a topological sense from
its original attachment point which is what gives rise to the costs
outlined above. Re-allocating an address upon expiration of a timer
may introduce uneccessary and burdensome signaling load on the
network and air interface.
McCann & Kaippallimalil Expires October 13, 2016 [Page 3]
Internet-Draft Prefix Cost April 2016
1.1. Requirements Language
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 RFC 2119 [1].
1.2. Abbreviations
ANDSF Access Network Discovery and Selection Function
MN Mobile Node
MPTCP Multi-Path Transmission Control Protocol
ND Neighbor Discovery
NGMN Next Generation Mobile Networks
NUD Neighbor Unreachability Detection
OMA-DM Open Mobile Alliance - Device Management
PIO Prefix Information Discovery
PGW Packet data network Gateway
SeND Secure Neighbor Discovery
SGW Serving Gateway
2. Motivation
The Introduction speaks in general terms about the cost of a prefix.
More specifically, we are talking about the aggregate amount of state
being maintained in the network on behalf of the mobile node in
addition to the transport resources being used (or wasted) to get
packets to the MN's current point of attachment.
In a non-mobile network, the addresses can be assigned statically in
a manner that is aligned with the topology of the network. This
means that prefix aggregation can be used for maximum efficiency in
the state being maintained in such a network. Nodes deep in the
network need only concern themselves with a small number of short
prefixes, and only nodes near the end host need to know longer more
specific prefixes. In the best case, only the last-hop router(s)
need to know the actual address assigned to the end host. Also,
routing protocols ensure that packets follow the least-cost path to
the end host in terms of number of routing hops or according to other
policies defined by the service provider, and these routing paths can
change dynamically as links fail or come back into service.
However, mobile nodes in a wide-area wireless network are often
handled very differently. A mobile node is usually assigned a fixed
gateway somewhere in the network, either in a fixed central location
or (better) in a location near where the MN first attaches to the
network. For example, in a 3GPP network this gateway is a PGW that
can be allocated in the home or visited networks. Initially, the
cost of such a prefix is the state entry in the fixed gateway plus
McCann & Kaippallimalil Expires October 13, 2016 [Page 4]
Internet-Draft Prefix Cost April 2016
any state entries in intermediate tunneling nodes (like SGWs) plus
whatever transport resources are being used to get the packet to the
MN's initial point of attachment.
When an MN changes its point of attachment, but keeps a fixed
address, the cost of the prefix changes (usually it increases). Even
if the fixed gateway was initially allocated very close to the
initial point of attachment, as the MN moves away from this point,
additional state must be inserted into the network and additional
transport resources must be provided to get the packets to the
current point of attachment. For example, a new SGW might be
allocated in a new network, and now the packets must traverse the
network to which the MN first attached before being forwarded to
their destination, even though there may be a better and more direct
route to communication peers from the new network. Whatever
aggregation was possible at the initial point of attachment is now
lost and tunnels must be contructed or holes must be punched in
routing tables to ensure continued connectivity of the fixed IP
address at the new point of attachment. Over time, as the MN moves
farther and farther from its initial point of attachment, these costs
can become large. When summed over millions of mobile nodes, the
costs can be quite large.
Obviously, the assignment of a new address at a current point of
attachment and release of the older, more costly prefix will help to
reduce costs and may be the only way to meet emerging more stringent
latency requirements [8]. However, the MN does not in general know
the current cost of a prefix because it depends on the network
topology and the number of handovers that have taken place and
whether these handovers have caused the MN to transition between
different topological parts of the network. It is the purpose of the
protocol extension defined in this document to communicate the
current cost of a prefix to the MN so that it can make intelligent
decisions about when to get a new address and when to release older
addresses. Only the MN can make a decision about when to release an
address, because it is the only entity that knows whether
applications are still listening waiting to receive packets at the
old address.
Section 4 describes MN behavior when Router Advertisements with
Prefix Cost is received.
3. Prefix Cost Sub-option
This document defines a prefix cost option to be carried in router
advertisements. It is a sub-option that carries meta-data as defined
by Korhonen et al. [7]
McCann & Kaippallimalil Expires October 13, 2016 [Page 5]
Internet-Draft Prefix Cost April 2016
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD1 | 1 |C| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Cost | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Prefix Cost suboption
The prefix cost is carried as a 16-bit, unsigned number in network
byte order. An higher number indicates an increased cost.
This sub-option is appended in Router Advertimsement messages that
are sent on a periodic basis. No additional signaling cost is
incurred to support this mechanism.
It should be noted that link layer events do not cause a change in
the prefix cost.
The prefix cost is for a connection segment. No end-to-end
congestion or flow control mechanisms are implied with this cost.
4. Host Considerations
Prefix Cost in a Router Advertisement PIO serves as a hint for the MN
to use along with application knowledge, MN policy configuration on
network cost and available alternative routes to determine the IP
addresses and routes used. For example, if the application is
downloading a large file, it may want to maintain an IP address and
route until the download is complete. On the other hand, some
applications may use multiple connections (e.g., with MPTCP) and may
not want to maintain an IP address above a configured cost. It could
also be the case that the MN maintains the IP address even at high
cost if there is no alternative route/address. These decisions are
made based on configured policy, and interaction with applications,
all of which are decided by the MN.
When the MN is ready to release an IP address, it may send a DHCPv6
[5] Release message. The network may also monitor the status of a
high cost connection with Neighbor Unreachability Detection (NUD)
[2], [6], and determine that an address is not used after the NUD
times out. The network should not continue to advertise this high
cost route following the explicit release of the address or NUD
timeout. It can initiate the release of network resources dedicated
to providing the IP address to the MN.
McCann & Kaippallimalil Expires October 13, 2016 [Page 6]
Internet-Draft Prefix Cost April 2016
The operator of the network or host's service provider can configure
policy that determines how the host should handle the prefix cost
values. In a 3GPP network, the subscription provider may configure
policies in the host via OMA-DM or S14 (ANDSF). For example, the
service provider may configure rules to state that prefix cost values
below 500 indicate low cost and ideal access network conditions,
values from 501 - 5000 indicate that the host should try to relocate
connections, and values above 5000 indicate a risk and impending loss
of connectivity. The policies themselves can be (re-)configured as
needed by the operator. Prefix cost information with each Router
Advertisement allows the host to interpet a simple number and
associated policies to (re-)select optimal routes. For networks
service providers, when this cost is associated with charging, it can
be a valuable tool in dynamically managing the utilization of network
resources.
This draft does not aim to provide definitive guidance on how an OS
or application process receives indications as a result of prefix
cost option being conveyed in Router Advertisements. Only high level
design options are listed here. New socket options or other APIs can
be used to communicate the cost of an address in use on a given
connnection. For example, a new "prefix-cost" socket option, if set,
can indicate that the application is interested in being notified
when there is a change in the prefix cost. The actual mechanisms
used to either notify or other means of busy polling on this change
of prefix cost information need to be specified in other drafts. An
alternative to the application discovering the changed prefix cost is
to use a model where a connection manager handles the interface
between the network and the application (e.g., Android Telephony
Manager [9]). In this case, the connection manager is responsible to
select and manage addresses based on policies (configured via OMA-DM
or S14) and prefix cost obtained from the Router Advertisements.
5. Security Considerations
Security of the prefix cost option in the PIO needs to be considered.
Neighbor Discovery (ND) and Prefix Information Option (PIO) security
are described in [2] and [3]. A malicious node on a shared link can
advertise a low cost route in the prefix cost option and cause the MN
to switch. Alternatively, an incorrect higher cost route in the
prefix cost option can result in the suboptimal use of network
resources. In order to avoid such on-link attacks, SeND [4] can be
used to reject Router Advertisements from nodes whose identities are
not validated.
McCann & Kaippallimalil Expires October 13, 2016 [Page 7]
Internet-Draft Prefix Cost April 2016
6. IANA Considerations
This memo defines a new Prefix Information Option (PIO) sub-option in
Section 3.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[3] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://www.rfc-editor.org/info/rfc4191>.
[4] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>.
[5] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[6] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
Detection Is Too Impatient", RFC 7048,
DOI 10.17487/RFC7048, January 2014,
<http://www.rfc-editor.org/info/rfc7048>.
7.2. Informative References
[7] Korhonen, J., Gundavelli, S., Seite, P., and D. Liu, "IPv6
Prefix Properties", draft-korhonen-dmm-prefix-
properties-05 (work in progress), February 2016.
[8] NGMN Alliance, "NGMN 5G Whitepaper", February 2015.
McCann & Kaippallimalil Expires October 13, 2016 [Page 8]
Internet-Draft Prefix Cost April 2016
[9] Android Telephony Developer's Forum,
http://developer.android.com/reference/android/telephony/
TelephonyManager.html, "Android Telephony Manager".
Authors' Addresses
Peter J. McCann (editor)
Huawei
400 Crossing Blvd, 2nd Floor
Bridgewater, NJ 08807
USA
Phone: +1 908 541 3563
Email: peter.mccann@huawei.com
John Kaippallimalil (editor)
Huawei
5340 Legacy Dr., Suite 175
Plano, TX 75024
USA
Email: john.kaippallimalil@huawei.com
McCann & Kaippallimalil Expires October 13, 2016 [Page 9]
