idnits 2.17.1 draft-rauschenbach-alto-wireless-access-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 333 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (October 27, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Working Group U. Rauschenbach 3 Internet-Draft Nokia Networks 4 Intended status: Standards Track October 27, 2014 5 Expires: April 30, 2015 7 ALTO in wireless access networks 8 draft-rauschenbach-alto-wireless-access-00 10 Abstract 12 The Application-Layer Traffic Optimization (ALTO) specification 13 defines the concept of Provider-defined Identifiers (PIDs) as the 14 aggregation of network endpoints for network nodes. Each PID can be 15 associated with a set of endpoint addresses, e.g. aggregating 16 endpoints that use the same network access point. 18 This document focuses on mobile networks and introduces proposes the 19 toidea of using use cells of cellular access networks as an 20 aggregation points. This allows applications to make decisions based 21 on the path cost of using the current cell as a network attachment 22 point, or to even choose which network access points network 23 attachment point to select. Use cases are described which can 24 benefit from this. The draft elaborates on possible ALTO 25 modifications enabling such use cases. The intent of the draft is to 26 start discussion on the topic. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 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." 49 This Internet-Draft will expire on April 30, 2015. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction 69 2. Problem statement 70 3. Use cases 71 3.1. Cell as aggregation point 72 3.2. Passive reaction to handovers 73 3.2.1. Cost calendar to extend battery life for background 74 tasks 75 3.2.2. Cost calendar to optimize application sessions 76 3.3. Connection management and traffic offload 77 4. Requirements and solution ideas 78 5. References 79 Author's Address 81 1. Introduction 83 The Application-Layer Traffic Optimization (ALTO) [RFC7285] 84 specification allows providing information about a network to support 85 applications in making decisions regarding the most optimal use of 86 the network. Originally geared towards supporting peer-to-peer 87 applications in IP networks, the ALTO WG has recently broadened its 88 scope. 90 ALTO defines the concept of Provider-defined Identifiers (PIDs) to 91 aggregate network endpoints. Each PID can be associated with a set 92 of endpoint addresses. The concept of PIDs is generic and 93 potentially allows many types of endpoint addresses - the ALTO 94 specification mentions IP addresses, overlay IDs and MAC addresses. 95 However, RFC 7285 only defines address types for IPv4 and IPv6 96 addresses and leaves it to additional documents to define additional 97 types. 99 This document introduces a number of use cases occurring in wireless 100 networks which benefit from associating a cell or access point with a 101 PID. In such scenarios, the cell or access point through which 102 network attachment occurs or may occur in the future needs to be 103 identifiable by the ALTO client. Wireless access points provide 104 information such as cell ID to identify them. However, currently 105 ALTO provides only IP addresses for endpoints, and arbitrary strings 106 as PID values. Allowing an ALTO map to provide information about an 107 actual cell or access point can benefit use cases when the terminal 108 needs metrics describing the path cost of using a particular cell or 109 access point before the terminal attaches to the network via that 110 cell or access point, as well as for using a cell ID to aggregate 111 information about all endpoints attached to that cell or access 112 point. 114 2. Problem statement 116 ALTO defines the concept of PIDs which can be used to aggregate 117 network nodes. A PID can aggregate e.g. cover all nodes connected to 118 the network via a particular POP. It is assumed that in fixed 119 networks, the actual POP via which an endpoint is connected to the 120 network rarely changes. In cellular wireless networks, the situation 121 is different. Network access happens through cells. Nodes 122 frequently change cells when they move. Traffic conditions and other 123 costs may vary widely from cell to cell. Therefore, it makes sense 124 to include information about actual cells through which network 125 attachment happens in the ALTO maps. However, currently this is not 126 possible in the ALTO data entities. Similarly, access to WiFi 127 networks happens through wireless access points which are currently 128 also not considered in ALTO. 130 3. Use cases 132 3.1. Cell as aggregation point 134 Wireless terminals connect to a cellular network through different 135 cells, and to Wi-Fi networks through different wireless access 136 points. The quality of network access may vary greatly from 137 connection point to connection point, e.g. due to congestion or the 138 differing capacity of backhaul (connection point is used to refer to 139 both cells and access points from now on). In particular in cellular 140 networks, the connection point actually used frequently changes. 142 If the ALTO information model would be able to identify the 143 connection point with a PID, then different costs could be provided 144 for different map paths to the connection points. Also, there may 145 potentially be a large number of cellular subscribers connected to a 146 typical cell. It may not matter which endpoint addresses they use, 147 but only via which connection point they are attached to the network. 148 Exploiting this may greatly reduce map size as numerous endpoints 149 under a connection point can be aggregated into a PID, and also 150 reduce the number of map updates as endpoints move so that they can 151 be attached via different connection points due to endpoint movement 152 or handovers. 154 3.2. Passive reaction to handovers 156 Applications can benefit from knowledge or assumption about the cells 157 a terminal is connected to or will with some probability be connected 158 to in the near future. 160 Applications may know which cells a terminal typically connects 161 throughout a day e.g. from observing daily commute patterns. They 162 may also be provided candidate cells with favorable conditions by 163 including in the ALTO response a set of non-congested cells in the 164 vicinity of a queried cell. Once the terminal connects to such a 165 cell while moving, the application can execute tasks which require 166 e.g. higher throughput. 168 Also, if non-congested and congested cells overlap (such as e.g. a 169 non-congested small cell or WiFi hotspot and a congested macro cell) 170 and the terminal is in motion, an application can make assumptions 171 about future congestion and prepare / react accordingly. 173 Finally, applications may obtain candidate cells by accessing 174 information about neighboring cells through the APIs provided by 175 modern smartphones. 177 Based on such knowledge, the following two classes of use cases can 178 be distinguished. 180 3.2.1. Cost calendar to extend battery life for background tasks 182 Large fractions of Internet traffic today occur over wireless 183 systems. Not all traffic is real-time and many tasks can be 184 performed in the background. In particular, clients that download 185 large volumes of data (e.g., mail applications or social network 186 clients) can choose the time when they will actually download large 187 items such as attachments or video clips. 189 If a cost calendar does include information that a client can use to 190 compute the achievable throughput of a service via different cells 191 (e.g. based on information about available bandwidth or congestion 192 information per cell), it can initiate or schedule large downloads to 193 take place when it can connect to a cell that currently allows high 194 throughput. 196 If a high throughput cell is used for background downloads, the 197 battery life can be extended as the terminal spends less time in 198 battery-consuming states with the processor busy and the radio on and 199 instead spends more time in battery-conserving idle modes. 201 3.2.2. Cost calendar to optimize application sessions 203 Cost and other metrics usually fluctuate over time e.g. based on the 204 day of week. Such knowledge can be used to provide hints to 205 applications how to adapt proactively. For instance, during (or 206 prior to) user mobility (e.g. a commute), an application may make use 207 of such heuristic information to prefetch farther in advance (beyond 208 just in time) more items within an ongoing streaming session at times 209 of low congestion, prior to it entering time intervals or cells with 210 higher congestion etc. Such knowledge can also contribute to picking 211 a suitable video rate in progressive streaming. In a video telephony 212 session, applications may proactively switch to audio-only calls in 213 congested areas. This use case is somewhat related to the previous 214 one; however, it focuses on optimizing the user experience of 215 foreground tasks, rather than on scheduling background tasks. 217 3.3. Connection management and traffic offload 219 The previouis use cases have focussed on the application reacting on 220 a change in network access point. However, often various connection 221 points of different wireless networks are available to which an 222 endpoint may actively attach. As mobile endpoints get more 223 intelligent, functions for connection management and traffic offload 224 can consider not only the quality of the radio connection when doing 225 access selection and traffic offload, but also other properties such 226 as cost parameters and additional metrics provided by ALTO. Also, 227 when multiple different wireless access options are available, 228 traffic may be distributed between these options based on ALTO cost 229 maps so the network can be used more optimally. However, this 230 requires that the wireless terminal can associate ALTO map entries 231 with actual cell identifiers in the wireless networks. 233 4. Requirements and solution ideas 235 This section elaborates solution ideas as a starting point for the 236 technical discussion. 238 Aggregation in ALTO is modeled by a PID which represents a group of 239 nodes. A PID is identified by a provider-defined string with no 240 general meaning, and an endpoint is identified by its IP address. 242 Cellular networks use a cell identifier (cell ID) to identify the 243 cells through which network attachment happens. In Public Land 244 Mobile Networks (PLMNs) based on E-UTRAN [TS36.311], the Cell ID is 245 composed of the PLMN ID and the ECI, which in turn are composite 246 identifiers. The PLMN ID (Public Land Mobile Network IDentifier) 247 identifies a wireless communications system. It consists of the 3 248 digit Mobile Country Code (MCC) and the 3 digit Mobile Network Code 249 (MNC). ECI is the E-UTRAN Cell Identifier which identifies a Cell 250 within a PLMN. An ECI is composed of eNB ID and Cell ID. The eNB ID 251 (20 bits) is the eNodeB IDentifier which identifies an eNB within a 252 PLMN. The Cell ID (8 bits) identifies a (sub)cell within a 253 particular eNodeB. 255 WiFi-based wireless networks provide data such as SSID, access point 256 MAC address and other values that allow to identify the network 257 access point. Note that the Hotspot 2.0 specification [HS2.0] allows 258 a terminal querying a number of parameters prior to connecting to an 259 access point (such as Venue Name, Roaming Consortium, IP Address Type 260 Availability, 3GPP Cellular Network, Domain Name, Hotspot Query List, 261 Hotspot Capability List and others). The terminal searching for a 262 particular network access can retrieve the information elements 263 through the IEEE 802.11 ANQP from the access point prior to 264 connection establishment. However, once connected to an access 265 point, the terminal has to retrieve the information of other access 266 points in the area by virtually detaching from the access point and 267 running access network discovery over the air to the other access 268 points. It would be beneficial when the terminal would be able to 269 retrieve the information of adjacent access points and access 270 networks by way of e.g. an ALTO query over the existing connection. 272 In order to enable the use cases defined above in ALTO, the IDs which 273 identify the wireless connection point would have to be added to the 274 ALTO data model. 276 To support the use cases above, two things are required: 278 1. To enable querying properties of a certain cell such as bandwidth 279 or degree of congestion. Such queries could be supported through 280 the mechanism of endpoint property queries (RFC7285 section 281 11.4). Possible solutions are: 283 * Solution A: The cellular access point would need to be defined 284 as an additional endpoint inside the group aggregated by a 285 PID, i.e. a new address type that represents a cell ID would 286 be required. 288 * Solution B: A property query would be needed for the PID, plus 289 a property that represents the cell identifier. 291 2. To enable cells as identifiable aggregation points, the notion of 292 a PID (which is now just a string) would need to be extended by 293 including cell identification. Assigning different PIDs to 294 different cells would then allow to create different cost map 295 sections for paths of access through different cells (e.g., costs 296 would be higher for access through congested cells than for 297 access through non-congested cells). 299 * Solution: A PID would need to be extended by a cell identifier 300 (related to Solution B above) 302 5. References 304 [HS2.0] The WiFi Alliance, "Hotspot 2.0 (Release 2) Technical 305 Specification, Version 1.0.0", August 2014. 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 311 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 312 Traffic Optimization (ALTO) Protocol", RFC 7285, September 313 2014. 315 [TS36.311] 316 Third Generation Partnership Project, "3GPP TS 36.331 V12: 317 Technical Specification Group Radio Access Network; 318 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio 319 Resource Control (RRC); Protocol specification (Release 320 12)", September 2014. 322 Author's Address 324 Uwe Rauschenbach 325 Nokia Networks 327 Email: uwe.rauschenbach@nsn.com