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


   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

   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
   ( 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",
   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

   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,

   [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,

   [3]        Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <>.

   [4]        Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971,
              DOI 10.17487/RFC3971, March 2005,

   [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, <>.

   [6]        Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
              Detection Is Too Impatient", RFC 7048,
              DOI 10.17487/RFC7048, January 2014,

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,
              TelephonyManager.html, "Android Telephony Manager".

Authors' Addresses

   Peter J. McCann (editor)
   400 Crossing Blvd, 2nd Floor
   Bridgewater, NJ  08807

   Phone: +1 908 541 3563

   John Kaippallimalil (editor)
   5340 Legacy Dr., Suite 175
   Plano, TX  75024


McCann & Kaippallimalil Expires October 13, 2016                [Page 9]