One document matched: draft-mccann-dmm-prefixcost-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use numeric references tags -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-mccann-dmm-prefixcost-03" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Prefix Cost">Communicating Prefix Cost to Mobile Nodes</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Peter J. McCann" initials="P.J." role="editor"
surname="McCann">
<organization>Huawei</organization>
<address>
<postal>
<street>400 Crossing Blvd, 2nd Floor</street>
<city>Bridgewater</city>
<region>NJ</region>
<code>08807</code>
<country>USA</country>
</postal>
<phone>+1 908 541 3563</phone>
<email>peter.mccann@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="John Kaippallimalil" initials="J.K." role="editor"
surname="Kaippallimalil">
<organization>Huawei</organization>
<address>
<postal>
<street>5340 Legacy Dr., Suite 175</street>
<city>Plano</city>
<region>TX</region>
<code>75024</code>
<country>USA</country>
</postal>
<email>john.kaippallimalil@huawei.com</email>
</address>
</author>
<date month="April" year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>IETF</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF.-->
<keyword>dmm</keyword>
<keyword>router advertisement</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<!-- changes in version 02:
1. What are these mechanisms optimizing? Are core network resources that
expensive? Add use cases and scenarios.
2. No additional signaling incurred in this mechanism: RA sends this repeatedly
3. Not responding to link layer /L2 events
4. No e2e proposed; that is for MPTCP and others.
5. what happens in the host/OS: polling vs. kernel notifications.
changes tagged inline as "version 02"
-->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="Introduction">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
The cost should be communicated to the MN because of several
constraints inherent in the problem:
<list style="format (%d)">
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
<t>
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.
</t>
<!-- Requirements language, RFC 2119 ********************* -->
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<!-- chapter 1.2 ********************* -->
<section title="Abbreviations">
<texttable style="none">
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<c>ANDSF</c><c>Access Network Discovery and Selection Function</c>
<c>MN</c><c>Mobile Node</c>
<c>MPTCP</c><c>Multi-Path Transmission Control Protocol</c>
<c>ND</c><c>Neighbor Discovery</c>
<c>NGMN</c><c>Next Generation Mobile Networks</c>
<c>NUD</c><c>Neighbor Unreachability Detection</c>
<c>OMA-DM</c><c>Open Mobile Alliance - Device Management</c>
<c>PIO</c><c>Prefix Information Discovery</c>
<c>PGW</c><c>Packet data network Gateway</c>
<c>SeND</c><c>Secure Neighbor Discovery</c>
<c>SGW</c><c>Serving Gateway</c>
</texttable>
</section>
</section> <!-- end of Introduction -->
<section anchor="motivation" title="Motivation">
<!-- version 2
1. Where is it needed? Add use cases and scenarios. -->
<t>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.
</t>
<t>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.
</t>
<t>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 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.
</t>
<t>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. </t>
<t>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 <xref target="NGMN"/>. 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. </t>
<!-- v2.1: how are cost values expressed, &what does host do with it -->
<t><xref target="host-considerations"/> describes MN behavior when
Router Advertisements with Prefix Cost is received.
</t>
<!-- end version 2 -->
</section> <!-- end of chapter - Motivation -->
<section anchor="prefix-cost" title="Prefix Cost Sub-option">
<t>
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.
<xref target="I-D.korhonen-dmm-prefix-properties"/>
</t>
<figure align="center" anchor="fig_prefixcostoption" title="Prefix
Cost suboption">
<artwork align="center"><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
The prefix cost is carried as a 16-bit, unsigned number in
network byte order. An higher number indicates an increased
cost.
</t>
<!-- v2.1 who would define prefix cost? what are the guidelines -->
<!-- version 2: Explanations
2. No additional signaling incurred in this mechanism
3. Not responding to link layer /L2 events -->
<t>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.
</t>
<t>It should be noted that link layer events do not cause a change in the
prefix cost.
</t>
<!-- 4. No e2e proposed; that is for MPTCP and others. -->
<t>The prefix cost is for a connection segment. No end-to-end
congestion or flow control mechanisms are implied with this cost.
</t>
<!-- end version 2 -->
</section> <!-- end of chapter Prefix Cost -->
<section anchor="host-considerations" title="Host Considerations">
<!-- prefix cost is a hint -->
<t>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.
</t>
<!-- outline of connection release, NUD -->
<t>When the MN is ready to release an IP address, it may send a DHCPv6 <xref
target="RFC3315"/> Release message. The network may also monitor
the status of a high cost connection with Neighbor Unreachability
Detection (NUD) <xref target="RFC4861"/>, <xref target="RFC7048"/>,
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.
</t>
<!-- v2.1: how are cost values expressed to host, &what does host do with it -->
<t>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.
</t>
<!-- version 2:
5. what happens in the host/OS: polling vs. kernel
notifications. -->
<t>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
<xref target="android-telephony"/>). 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.
</t>
</section> <!-- end of chapter - Host Considerations -->
<section anchor="Security" title="Security Considerations">
<t>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 <xref target="RFC4861"/> and <xref
target="RFC4191"/>. 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 <xref target="RFC3971"/> can be used to reject Router
Advertisements from nodes whose identities are not validated.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo defines a new Prefix Information Option (PIO) sub-option
in <xref target="prefix-cost"/>.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.4861.xml"?>
<?rfc include="reference.RFC.4191.xml"?>
<?rfc include="reference.RFC.3971.xml"?>
<?rfc include="reference.RFC.3315.xml"?>
<?rfc include="reference.RFC.7048.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.korhonen-dmm-prefix-properties.xml"?>
<reference anchor="NGMN">
<front>
<title>NGMN 5G Whitepaper
</title>
<author><organization>NGMN Alliance</organization></author>
<date day='17' month='February' year='2015' />
</front>
</reference>
<reference anchor="android-telephony">
<front>
<title>Android Telephony Manager
</title>
<author>
<organization>Android Telephony Developer's Forum,
http://developer.android.com/reference/android/telephony/TelephonyManager.html
</organization>
</author>
<date></date>
</front>
</reference>
</references>
<!-- Change Log
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:48:42 |