idnits 2.17.1 draft-mccann-dmm-prefixcost-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 11, 2016) is 2930 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (ref. '5') (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF P. McCann, Ed. 3 Internet-Draft J. Kaippallimalil, Ed. 4 Intended status: Informational Huawei 5 Expires: October 13, 2016 April 11, 2016 7 Communicating Prefix Cost to Mobile Nodes 8 draft-mccann-dmm-prefixcost-03 10 Abstract 12 In a network implementing Distributed Mobility Management, it has 13 been agreed that Mobile Nodes (MNs) should exhibit agility in their 14 use of IP addresses. For example, an MN might use an old address for 15 ongoing socket connections but use a new, locally assigned address 16 for new socket connections. Determining when to assign a new 17 address, and when to release old addresses, is currently an open 18 problem. Making an optimal decision about address assignment and 19 release must involve a tradeoff in the amount of signaling used to 20 allocate the new addresses, the amount of utility that applications 21 are deriving from the use of a previously assigned address, and the 22 cost of maintaining an address that was assigned at a previous point 23 of attachment. As the MN moves farther and farther from the initial 24 point where an address was assigned, more and more resources are used 25 to redirect packets destined for that IP address to its current 26 location. The MN currently does not know the amount of resources 27 used as this depends on mobility path and internal routing topology 28 of the network(s) which are known only to the network operator. This 29 document provides a mechanism to communicate to the MN the cost of 30 maintaining a given prefix at the MN's current point of attachment so 31 that the MN can make better decisions about when to release old 32 addresses and assign new ones. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 13, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Prefix Cost Sub-option . . . . . . . . . . . . . . . . . . . 5 72 4. Host Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 7.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 Previous discussions on address agility in distributed mobility 83 management have focused on "coloring" prefixes with one of a small 84 number of categories, such as Fixed, Sustained, or Nomadic. The 85 assumption here is that the MN should use a permanent home address 86 for sessions that need a persistent IP address, and a local, 87 ephemeral address for short-lived sessions such as browsing. 88 However, a small set of address categories lacks expressive power and 89 leads to false promises being made to mobile nodes. For example, the 90 concept that a home address can be maintained permanently and offered 91 as an on-link prefix by any access router to which the MN may be 92 attached in future is simply not attainable in the real world. There 93 will always exist some access routers that do not have arrangements 94 in place with the home network to re-route (via tunneling or other 95 mechanisms) the home prefix to the current point of attachment. 97 Conversely, the assumption that a Nomadic prefix will never be 98 available to an MN after it changes its current point of attachment 99 is too limiting. There is no reason why an MN should not be able to 100 keep a prefix that was assigned by a first network after it moves to 101 a second network, provided that measures are put in place to re-route 102 such prefixes to the new attachment point. 104 Rather, this document argues that there is in reality a continuum of 105 cost associated with an address as the MN moves from one attachment 106 point to another or from one network to another. The sources of the 107 cost are the increased latency, network bandwidth, and network state 108 being maintained by a network-based mobility management scheme to 109 route packets destined to the prefix to the MN's current point of 110 attachment. By communicating this cost to the MN every time its 111 attachment point changes, the MN can make intelligent decisions about 112 when to release old addresses and when to acquire new ones. 114 The cost should be communicated to the MN because of several 115 constraints inherent in the problem: 117 (1) The MN is the entity that must make decisions about allocating 118 new addresses and releasing old ones. This is because only the 119 MN has the information about which addresses are still in use by 120 applications or have been registered with other entities such as 121 DNS servers. 123 (2) Only the network has information about the cost of maintaining 124 the prefix in a network-based mobility management scheme, 125 because the MN cannot know the network topology that gives rise 126 to the inefficiencies. 128 If the cost of maintaining a prefix is not made available to the 129 mobile node, it may attempt to infer the cost through heuristic 130 mechanisms. For example, it can measure increased end-to-end latency 131 after a mobility event, and attribute the increased latency to a 132 longer end-to-end path. However, this method does not inform the MN 133 about the network bandwidth being expended or network state being 134 maintained on its behalf. Alternatively, a MN may attempt to count 135 mobility events or run a timer in an attempt to guess at which older 136 prefixes are more costly and in need of being released. However, 137 these methods fail because the number of mobility events is not an 138 indication of how far the MN has moved in a topological sense from 139 its original attachment point which is what gives rise to the costs 140 outlined above. Re-allocating an address upon expiration of a timer 141 may introduce uneccessary and burdensome signaling load on the 142 network and air interface. 144 1.1. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [1]. 150 1.2. Abbreviations 152 ANDSF Access Network Discovery and Selection Function 153 MN Mobile Node 154 MPTCP Multi-Path Transmission Control Protocol 155 ND Neighbor Discovery 156 NGMN Next Generation Mobile Networks 157 NUD Neighbor Unreachability Detection 158 OMA-DM Open Mobile Alliance - Device Management 159 PIO Prefix Information Discovery 160 PGW Packet data network Gateway 161 SeND Secure Neighbor Discovery 162 SGW Serving Gateway 164 2. Motivation 166 The Introduction speaks in general terms about the cost of a prefix. 167 More specifically, we are talking about the aggregate amount of state 168 being maintained in the network on behalf of the mobile node in 169 addition to the transport resources being used (or wasted) to get 170 packets to the MN's current point of attachment. 172 In a non-mobile network, the addresses can be assigned statically in 173 a manner that is aligned with the topology of the network. This 174 means that prefix aggregation can be used for maximum efficiency in 175 the state being maintained in such a network. Nodes deep in the 176 network need only concern themselves with a small number of short 177 prefixes, and only nodes near the end host need to know longer more 178 specific prefixes. In the best case, only the last-hop router(s) 179 need to know the actual address assigned to the end host. Also, 180 routing protocols ensure that packets follow the least-cost path to 181 the end host in terms of number of routing hops or according to other 182 policies defined by the service provider, and these routing paths can 183 change dynamically as links fail or come back into service. 185 However, mobile nodes in a wide-area wireless network are often 186 handled very differently. A mobile node is usually assigned a fixed 187 gateway somewhere in the network, either in a fixed central location 188 or (better) in a location near where the MN first attaches to the 189 network. For example, in a 3GPP network this gateway is a PGW that 190 can be allocated in the home or visited networks. Initially, the 191 cost of such a prefix is the state entry in the fixed gateway plus 192 any state entries in intermediate tunneling nodes (like SGWs) plus 193 whatever transport resources are being used to get the packet to the 194 MN's initial point of attachment. 196 When an MN changes its point of attachment, but keeps a fixed 197 address, the cost of the prefix changes (usually it increases). Even 198 if the fixed gateway was initially allocated very close to the 199 initial point of attachment, as the MN moves away from this point, 200 additional state must be inserted into the network and additional 201 transport resources must be provided to get the packets to the 202 current point of attachment. For example, a new SGW might be 203 allocated in a new network, and now the packets must traverse the 204 network to which the MN first attached before being forwarded to 205 their destination, even though there may be a better and more direct 206 route to communication peers from the new network. Whatever 207 aggregation was possible at the initial point of attachment is now 208 lost and tunnels must be contructed or holes must be punched in 209 routing tables to ensure continued connectivity of the fixed IP 210 address at the new point of attachment. Over time, as the MN moves 211 farther and farther from its initial point of attachment, these costs 212 can become large. When summed over millions of mobile nodes, the 213 costs can be quite large. 215 Obviously, the assignment of a new address at a current point of 216 attachment and release of the older, more costly prefix will help to 217 reduce costs and may be the only way to meet emerging more stringent 218 latency requirements [8]. However, the MN does not in general know 219 the current cost of a prefix because it depends on the network 220 topology and the number of handovers that have taken place and 221 whether these handovers have caused the MN to transition between 222 different topological parts of the network. It is the purpose of the 223 protocol extension defined in this document to communicate the 224 current cost of a prefix to the MN so that it can make intelligent 225 decisions about when to get a new address and when to release older 226 addresses. Only the MN can make a decision about when to release an 227 address, because it is the only entity that knows whether 228 applications are still listening waiting to receive packets at the 229 old address. 231 Section 4 describes MN behavior when Router Advertisements with 232 Prefix Cost is received. 234 3. Prefix Cost Sub-option 236 This document defines a prefix cost option to be carried in router 237 advertisements. It is a sub-option that carries meta-data as defined 238 by Korhonen et al. [7] 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | TBD1 | 1 |C| Reserved1 | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Prefix Cost | Reserved2 | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 1: Prefix Cost suboption 249 The prefix cost is carried as a 16-bit, unsigned number in network 250 byte order. An higher number indicates an increased cost. 252 This sub-option is appended in Router Advertimsement messages that 253 are sent on a periodic basis. No additional signaling cost is 254 incurred to support this mechanism. 256 It should be noted that link layer events do not cause a change in 257 the prefix cost. 259 The prefix cost is for a connection segment. No end-to-end 260 congestion or flow control mechanisms are implied with this cost. 262 4. Host Considerations 264 Prefix Cost in a Router Advertisement PIO serves as a hint for the MN 265 to use along with application knowledge, MN policy configuration on 266 network cost and available alternative routes to determine the IP 267 addresses and routes used. For example, if the application is 268 downloading a large file, it may want to maintain an IP address and 269 route until the download is complete. On the other hand, some 270 applications may use multiple connections (e.g., with MPTCP) and may 271 not want to maintain an IP address above a configured cost. It could 272 also be the case that the MN maintains the IP address even at high 273 cost if there is no alternative route/address. These decisions are 274 made based on configured policy, and interaction with applications, 275 all of which are decided by the MN. 277 When the MN is ready to release an IP address, it may send a DHCPv6 278 [5] Release message. The network may also monitor the status of a 279 high cost connection with Neighbor Unreachability Detection (NUD) 280 [2], [6], and determine that an address is not used after the NUD 281 times out. The network should not continue to advertise this high 282 cost route following the explicit release of the address or NUD 283 timeout. It can initiate the release of network resources dedicated 284 to providing the IP address to the MN. 286 The operator of the network or host's service provider can configure 287 policy that determines how the host should handle the prefix cost 288 values. In a 3GPP network, the subscription provider may configure 289 policies in the host via OMA-DM or S14 (ANDSF). For example, the 290 service provider may configure rules to state that prefix cost values 291 below 500 indicate low cost and ideal access network conditions, 292 values from 501 - 5000 indicate that the host should try to relocate 293 connections, and values above 5000 indicate a risk and impending loss 294 of connectivity. The policies themselves can be (re-)configured as 295 needed by the operator. Prefix cost information with each Router 296 Advertisement allows the host to interpet a simple number and 297 associated policies to (re-)select optimal routes. For networks 298 service providers, when this cost is associated with charging, it can 299 be a valuable tool in dynamically managing the utilization of network 300 resources. 302 This draft does not aim to provide definitive guidance on how an OS 303 or application process receives indications as a result of prefix 304 cost option being conveyed in Router Advertisements. Only high level 305 design options are listed here. New socket options or other APIs can 306 be used to communicate the cost of an address in use on a given 307 connnection. For example, a new "prefix-cost" socket option, if set, 308 can indicate that the application is interested in being notified 309 when there is a change in the prefix cost. The actual mechanisms 310 used to either notify or other means of busy polling on this change 311 of prefix cost information need to be specified in other drafts. An 312 alternative to the application discovering the changed prefix cost is 313 to use a model where a connection manager handles the interface 314 between the network and the application (e.g., Android Telephony 315 Manager [9]). In this case, the connection manager is responsible to 316 select and manage addresses based on policies (configured via OMA-DM 317 or S14) and prefix cost obtained from the Router Advertisements. 319 5. Security Considerations 321 Security of the prefix cost option in the PIO needs to be considered. 322 Neighbor Discovery (ND) and Prefix Information Option (PIO) security 323 are described in [2] and [3]. A malicious node on a shared link can 324 advertise a low cost route in the prefix cost option and cause the MN 325 to switch. Alternatively, an incorrect higher cost route in the 326 prefix cost option can result in the suboptimal use of network 327 resources. In order to avoid such on-link attacks, SeND [4] can be 328 used to reject Router Advertisements from nodes whose identities are 329 not validated. 331 6. IANA Considerations 333 This memo defines a new Prefix Information Option (PIO) sub-option in 334 Section 3. 336 7. References 338 7.1. Normative References 340 [1] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, 342 DOI 10.17487/RFC2119, March 1997, 343 . 345 [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 346 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 347 DOI 10.17487/RFC4861, September 2007, 348 . 350 [3] Draves, R. and D. Thaler, "Default Router Preferences and 351 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 352 November 2005, . 354 [4] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 355 "SEcure Neighbor Discovery (SEND)", RFC 3971, 356 DOI 10.17487/RFC3971, March 2005, 357 . 359 [5] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 360 C., and M. Carney, "Dynamic Host Configuration Protocol 361 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 362 2003, . 364 [6] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 365 Detection Is Too Impatient", RFC 7048, 366 DOI 10.17487/RFC7048, January 2014, 367 . 369 7.2. Informative References 371 [7] Korhonen, J., Gundavelli, S., Seite, P., and D. Liu, "IPv6 372 Prefix Properties", draft-korhonen-dmm-prefix- 373 properties-05 (work in progress), February 2016. 375 [8] NGMN Alliance, "NGMN 5G Whitepaper", February 2015. 377 [9] Android Telephony Developer's Forum, 378 http://developer.android.com/reference/android/telephony/ 379 TelephonyManager.html, "Android Telephony Manager". 381 Authors' Addresses 383 Peter J. McCann (editor) 384 Huawei 385 400 Crossing Blvd, 2nd Floor 386 Bridgewater, NJ 08807 387 USA 389 Phone: +1 908 541 3563 390 Email: peter.mccann@huawei.com 392 John Kaippallimalil (editor) 393 Huawei 394 5340 Legacy Dr., Suite 175 395 Plano, TX 75024 396 USA 398 Email: john.kaippallimalil@huawei.com