idnits 2.17.1 draft-randriamasy-alto-cost-context-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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1508 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) == Missing Reference: 'TODO' is mentioned on line 665, but not defined -- Looks like a reference, but probably isn't: '10' on line 676 -- Looks like a reference, but probably isn't: '4' on line 677 -- Looks like a reference, but probably isn't: '6' on line 677 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO S. Randriamasy 3 Internet-Draft Nokia Bell Labs 4 Intended status: Standards Track March 9, 2020 5 Expires: September 10, 2020 7 ALTO Contextual Cost Values 8 draft-randriamasy-alto-cost-context-03 10 Abstract 12 The Application-Layer Traffic Optimization (ALTO) Service has defined 13 network and cost maps to provide basic network information, where the 14 cost maps allow only one JSON value for a requested metric. 16 This document introduces several protocol extensions to allow ALTO 17 clients to support use cases such as context based connection 18 selection in cellular networks and calendaring for unattended data. 19 This document refers to other extension proposals posted in the ALTO 20 WG that can support the present use cases as well. Likewise, some of 21 the proposed extensions may serve other ALTO use cases. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 10, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Use Case 1: conditional RF costs in cellular networks . . 4 66 2.2. Use case 2: access-aware endpoint selection . . . . . . . 5 67 3. Required ALTO extensions . . . . . . . . . . . . . . . . . . 6 68 4. Design options and examples . . . . . . . . . . . . . . . . . 7 69 4.1. Overview of context features . . . . . . . . . . . . . . 7 70 4.1.1. Applicable ALTO services . . . . . . . . . . . . . . 8 71 4.2. Example IRD . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. Use case 1: Example scenario for the FCM Service . . . . 10 73 4.4. Design option: Network Map with cells as PIDs . . . . . . 11 74 4.4.1. Example: FCM Request for contextual 'ARFcost' . . . . 11 75 4.4.2. Example: FCM Response for contextual ARFcost . . . . 12 76 4.5. Use case 2: example ALTO transactions for the ECS . . . . 13 77 4.5.1. Use case 2: example with logical context parameter 78 combinations . . . . . . . . . . . . . . . . . . . . 13 79 5. Deployment case: local ALTO Server cascaded with global ALTO 80 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 5.1. Cascaded ALTO Servers with one network map each . . . . . 16 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 9.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . 18 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 The IETF ALTO protocol specified in [RFC7285] provides guidance to 94 over the top applications which have to select one or several hosts 95 or endpoints from a set of candidates that are able to provide a 96 desired data resource, or which need some provider-centric insight on 97 the cost of application paths to these endhosts. The ALTO Service 98 has defined network and cost maps to provide basic network 99 information, where the cost maps allow only one JSON value for a 100 requested metric. 102 This draft brings a use case where providing different values for the 103 same cost metric can help in optimizing the application path 104 selection. Typically, when an end host can connect to the network 105 via multiple technologies or access points, the path performance for 106 a metric may be accordingly impacted. 108 The present draft proposes to extend the cost information specified 109 in [RFC7285] by providing, for the same cost metric, several possible 110 cost values. Which value to provide depends on qualitative criteria 111 as opposed to quantitative criteria such as time. The purpose is to 112 allow a finer grained decision on which application endpoint or sub 113 network to access. 115 Previous ALTO WG discussions have suggested introducing "the ability 116 to "name" cost maps so that a single Information Resource Directory 117 can link multiple cost maps with the same cost type to a single 118 network map." The goal was to provide, for a given cost metric, 119 multiple cost values depending on qualitative conditions named 120 "circumstance", where a circumstance reflects a given policy. 122 For applications such as video download or streaming, a user 123 equipment (UE) may use [RFC7285] to choose the best possible 124 application resource location. 126 Currently, the insight of ALTO information on the path between a UE 127 and a connection node (or say Endpoint) does not provide details 128 below IP hops. However the major QoE challenges of wireless network 129 users arise in the access network, that is, in the first hop between 130 the UE and its one or more serving packet data network gateway (PGW). 131 The path of a UE to its serving PGW(s) impacts the path to the 132 content and thus the related QoE. Therefore, it is necessary to 133 inform the UE, which could take the appropriate decisions w.r.t. the 134 utilized access path. The access technology in current ALTO 135 documents is accounted at the content location (last hop) side by 136 distinguishing whether the requested content is located in a fixed or 137 a wireless access network, as described in 138 [draft-ietf-alto-deployment] 139 This document introduces several protocol extensions to allow ALTO 140 clients to support use cases such as context-based connection 141 selection in cellular networks and calendaring for unattended data. 142 This document refers to other extension proposals posted in the ALTO 143 WG that can support the present use cases as well. Likewise, some of 144 the proposed extensions may serve other ALTO use cases. 146 2. Use cases 148 This section presents motivating use cases for contextual ALTO Costs 149 with a focus on conditional RF costs in cellular networks. In these 150 2 use cases, a terminal UE is located in a LTE network and associated 151 to a "local" ALTO Server(LAOS) that covers this access network, say 152 up to the Packet Data Network (PDN) Gateway PGW and can itself 153 connect to another ALTO Server having a more global view covering up 154 to the whole ISP network. Such a deployment is proposed in section 155 Section 5 of this draft. 157 2.1. Use Case 1: conditional RF costs in cellular networks 159 Let's assume a terminal UE located in a cellular network. An ALTO 160 Client (LAOC) associated to the UE queries the local ALTO Server in 161 order to know via which cell it should connect to the network. So in 162 a first place, LAOC will query the connection cost associated to 163 cells C1,.. CK. 165 The present example assumes that the connection cost conveyed by the 166 ALTO Server is a unitless value abstracting a non-real-time metric 167 reflecting traffic conditions, aggregated over time and space. This 168 metric aims at providing guidance to applications. It may integrate 169 abstractions by the network provider, of actual costs impacted by 170 other values such as congestion or available bandwidth are are 171 assumed to be not easily available to UEs or applications otherwise. 172 The ALTO Server does not aim at reporting accurate radio conditions 173 that indeed vary in time and space. 175 Let us call this metric: "ARF cost", standing for Abstracted RF cost. 177 Our example however includes 2 additional considerations: 179 - the ARF cost to a cell may be impacted by its load, 181 - a UE usually transmits a fair amount of "unattended data" (UD). 183 UD is considered in one of the key features for LTE enhancements in 184 Release 13 and defined in 3GPP TS22.101 as follows: "Unattended Data 185 Traffic : Data traffic of which the user is unaware he/she initiated, 186 e.g. based on the screen/keypad lock being activated, length of time 187 since the UE last received any input from the user, known type of app 188 (e.g. an application monitoring a user's health "mHealth" may need 189 its data never treated as Unattended Data Traffic.)". UD traffic is 190 often delay tolerant and it would be beneficial for the network if 191 the UE can schedule its transmission. To this end, the UE can use an 192 instant UD Indicator (UDI) sent by the LTE network. The UDI, 193 accepted for LTE Release 13 is a single bit sent to the UE indicating 194 whether UD in a cell is allowed (UDA) or not (UDNA). The status 195 change of a UDI from UDA to UDNA is presumably triggered when the 196 cell load exceeds a given threshold T(udna). The value of T(udna) 197 may change across cells and in time but is not provided to UEs. If 198 the UE had an ALTO calendar for either T(udna) or for the abstracted 199 cell load values, it could appropriately schedule the transmission of 200 its UD, that will have to occur anyway. The UE could combine this 201 calendar with the UDI it receives from the cellular network. The UDI 202 state may change within sub-seconds and impact the data exchange. 203 What is missing in the provided LTE information is: 205 - knowing whether the UDI threshold relates to downlink or uplink 206 congestion. 208 - knowing the level of congestion that triggers a change in UDI and 209 how it may evolve in time. 211 The UE thus can advantageously combine the non-real time ALTO 212 information with the real-time UDI provided by the LTE network. The 213 present draft illustrates how ALTO can fill these gaps with the 214 support of: 216 - ALTO Cost Calendars, 218 - the proposed protocol extension providing context-dependent ALTO 219 Cost values. 221 In this use case: ALTO calendars need to be requested via for the 222 ALTO Filtered Cost Map (FCM) Service, the context parameters 223 impacting the cost values are: "uda" (Unattended Data Allowed), 224 "udna" (Unattended Data Not Allowed), "uplink", "downlink". 226 2.2. Use case 2: access-aware endpoint selection 228 In a second use case, an end-system called UEP is located in a LTE 229 network and may connect via several access technologies, e.g. 230 Cellular or WiFi. UEP may also benefit from a given Service Level 231 Agreement SLA-m. Other parameters may characterize the UEP generated 232 traffic. 234 Currently the insight of ALTO information in the path between a UE 235 and a connection node (or say Endpoint) does not provide details 236 below IP hops. However the major QoE challenges of wireless network 237 users arise in the access network, that is, in the first hop between 238 the UE and its one or more associated packet data network gateway 239 (PGW). The path of a UE to its associated PGW(s) impacts the path to 240 the content and thus the related QoE. Therefore, it is necessary to 241 inform the UE, which could take the appropriate decisions w.r.t. the 242 utilized access path. The access technology in current ALTO 243 proposals is accounted at the content location (last hop) side by 244 distinguishing whether the requested content is located in a fixed or 245 a wireless access network, as described in [draft-ietf-alto- 246 deployments] that states: "For ISPs with mobile network and fixed 247 network, the traffic optimizing problems they focus will be 248 optimizing the mobile traffic, except problems on last hop section." 250 For Mobile Network Operators (MNO) and their users, being connected 251 via e.g. cellular or trusted Wifi can hugely impact the QoE and 252 routing cost. Sometimes a 4G connection is preferable for users than 253 a poor WiFi connection although potentially more expensive. 254 Sometimes, MNOs have spare data resources or offer them for given 255 SLAs. For both parties, access-aware Endpoint selection for Users is 256 thus beneficial. One way to achieve this is that ALTO provides cost 257 values depending on qualitative contextual parameters such as access 258 technology and the access technology and SLA. 260 3. Required ALTO extensions 262 The aforementioned use cases can be supported with a few simple 263 extensions to the ALTO protocol. A number of them have already been 264 discussed in other WG drafts and use cases. The proposed extensions 265 include: 267 - Cost value context parameters: a capability to allow exposing 268 several possible context-dependent values for one metric, as proposed 269 in the present document, 271 - Entities with associated domain and properties for cellular and 272 wireless networks, that could be added to 273 [draft-roome-alto-unified-props], 275 - Cost metrics for cellular and wireless networks: these features 276 would extend current proposals in the WG, that could be added to 277 [draft-ietf-alto-performance-metrics], 279 - Extended input for the Filtered Cost Map Service: to allow the 280 input to comprise several(source-array, destination-array) pairs, as 281 it has been proposed in [draft-yang-alto-path-vector]. 283 4. Design options and examples 285 Similarly to Multi-Cost and Cost Calendar ( 286 [draft-ietf-alto-cost-calendar]), this proposal does not introduce 287 new cost modes or new media-types. It ensures backwards 288 compatibility with legacy ALTO Clients, that is: "A legacy ALTO 289 Client must be able to send legacy requests to a Cost Context aware 290 ALTO Server and get legacy responses as specified in RFC7285". 292 "A Cost Context aware ALTO Server must be able to receive and process 293 requests sent by legacy ALTO Clients, as specified in RFC 7285". 295 Besides, the proposed extension is designed to be compatible with 296 Multi-Cost ALTO and ALTO Cost Calendars 297 ([draft-ietf-alto-cost-calendar]). 299 In the present draft version, the IRD indicates the supported context 300 attributes as values encoded in JSON strings. This design simplifies 301 the transactions, as it allows a limited number of context attributes 302 or their combinations, say 1 to 5. Context attributes taking 303 numerous or unpredictable values should be handled as values 304 properties or metrics expressed in constraints. 306 - A cost context aware ALTO Server MUST provide metric values, as 307 specified in RFC 7285, without any context consideration for all the 308 Cost Types indicated in its "meta". 310 4.1. Overview of context features 312 Cost context attributes are strings with values such as "wifi", 313 "cellular", "uda". 315 Cost context attributes are indicated in the IRD as capabilities of 316 an information resource. They are associated to cost type names. 318 - A cost context aware ALTO may indicate in its IRD capabilities, 319 whether and how context attributes may be combined in ALTO requests. 321 - A cost context aware ALTO Server MUST return metric values, without 322 any context consideration, as specified in RFC 7285, if the value for 323 a context attribute or a combination of attributes requested by the 324 client is not available. 326 - A cost context aware ALTO may indicate a maximum number of context 327 attributes ot their combinations authorised in context-aware Client 328 requests. 330 4.1.1. Applicable ALTO services 332 Draft [draft-bertz-alto-mobilitynets] proposes to identify network 333 points of attachment (PoA) such as cells to PIDs, as PoAs are 334 endpoint types not currently supported in ALTO. The current proposal 335 is to represent cellular PIDs in an ALTO Network Map with no routes. 336 PID properties as specified in [draft-roome-alto-unified-props] could 337 be used to indicate the type of the PoA, together with other 338 properties. ALTO properties are well suited for almost static 339 attributes such as access type. 341 To abstract and convey connection properties with frequently changing 342 values such as ARF Cost, load or congestion, the ALTO Filtered Cost 343 Map service can be used. Connection properties may also be conveyed 344 with the Endpoint property service or its extensions defined in 345 [draft-roome-alto-unified-props]. 347 Costs and properties with the extensions proposed in this document 348 may be conveyed with different values depending on the context 349 parameter. The present version of this draft focuses on context 350 parameters associated to costs. 352 4.2. Example IRD 354 The purpose of ALTO is to guide the behavior of the end systems or 355 applications without the need for networks to explicitly expose their 356 performance values. In this example, the IRD does not expose the 357 real load percentage of a cell to UE. Instead, it abstracts the cell 358 congestion by a metric called 'ARFcost' represented by a number 359 between 0 and 100, where the optimal value is 0. The values of 360 'ARFcost' are provided as an ALTO Calendar as specified in [draft- 361 ietf-alto-cost-calendar-00] in shorter time intervals. In addition 362 they differ, depending on the context values "uda" and "udna". 364 Besides, the IRD provides metric 'routingcost' as a MUST specified in 365 [RFC7285], that may represent a more administrative or monetary 366 access cost. 368 The IRD could publish the capability of a resource to provide context 369 dependent 'routingcost' values as expressed for resource "filtered- 370 cost-calendar-map". 372 HTTP/1.1 200 OK 373 Content-Length: [TODO] 374 Content-Type: application/alto-directory+json 376 { 377 "meta" : { 378 "cost-types": { 379 "num-routingcost": { 380 "cost-mode" : "numerical", 381 "cost-metric" : "routingcost" 382 }, 383 "num-ARFcost": { 384 "cost-mode" : "numerical", 385 "cost-metric": "ARFcost", 386 } 387 } 388 ... other meta ... 389 }, 390 "resources" : { 391 "filtered-cost-calendar-map" : { 392 "uri" : "http://alto.local.example.com/costmap/filtered/calendar/context", 393 "media-types" : [ "application/alto-endpointcost+json" ], 394 "accepts" : [ "application/alto-endpointcostparams+json" ], 395 "capabilities" : { 396 "cost-constraints" : true, 397 "cost-type-names" : [ "num-routingcost", 398 "num-ARFcost"],// ++NEW 399 "calendar-attributes" : [ 400 {"cost-type-names" : "num-routingcost", 401 "time-interval-size" : "1 hour", 402 "number-of-intervals" : 24}, // MAY ALSO BE SINGLE VALUE 403 {"cost-type-names" : "num-ARFcost", // ++NEW 404 "time-interval-size" : "5 minute", 405 "number-of-intervals" : 12} 406 ], 407 "cost-context" : [ // ++NEW 408 {"cost-type-names" : "num-ARFcost", 409 "context-params" : [["uda", "udna"], 410 ["uplink", "downlink"]] 411 } 412 ], // ++NEW 413 "max-context-attributes" : 10, 414 "uses": [ "my-default-network-map" ] 415 } // end FCM capab 416 ... other resources ... 417 } // end resources 418 } // end IRD 420 4.3. Use case 1: Example scenario for the FCM Service 422 We assume an example scenario where a UE has the choice to connect to 423 2 cells C1 and C2. 425 As suggested in [draft-bertz-alto-mobilitynets], we may represent the 426 cellular topology with an ALTO Network Map comprising PIDs 427 representing the cells and named "Cell1", "Cell2", ... "Celln". A 428 format for a cell identifier has been proposed in 429 [draft-rauschenbach-alto-wireless-access] and is not being discussed 430 here. 432 As a Network Map may cover a large number of cells, the Filtered Cost 433 Map Service can be used to reduce data exchange and get information 434 on a restricted number of cells. 436 We assume that the ALTO Client in the UE wants to get calendared 437 values for ALTO metric "ARFcost" in order to appropriately schedule 438 its unattended data transmission. The ALTO information resource 439 'ALTO Calendar' provides an array of time-dependent cost values and 440 is being specified in [draft-ietf-alto-cost-calendar]. In addition, 441 the ALTO Client wants these values for both the "uda" and "udna" 442 context. Last, we assume that the UE needs the Cost values for both 443 the uplink (UE to Cell-k) and downlink (Cell-k to UE) directions. We 444 assume that the UE is located in the PID called "Cell1". 446 In this scenario, Cell1 is limited by its uplink capacity and Cell2 447 is limited by its downlink capacity. ALTO can be used to convey the 448 following information: 450 At time interval T1 of the next Calendar: 452 - if Cell1 indicates "unattended data allowed" the downlink ARF cost 453 is 20, and the uplink ARF cost is 70 455 - if Cell1 indicates "unattended data NOT allowed", the downlink ARF 456 cost is 20, and the uplink ARF cost is 90 458 - if Cell2 indicates "unattended data allowed" the downlink ARF cost 459 is 70, and the uplink ARF cost is 20 461 - if Cell2 indicates "unattended data NOT allowed", the downlink ARF 462 cost is 90, in the uplink ARF cost is 20. 464 The ALTO Calendar provides values for the other 11 time intervals Ti. 466 4.4. Design option: Network Map with cells as PIDs 468 In this design, the cellular topology is represented with an ALTO 469 Network Map comprising PIDs named "Cell1", "Cell2", ... "Celln". The 470 UE is located in one of these PIDs. A Cost Map is associated to this 471 Network Map and conveys metrics indicated in the IRD. The Cost Map 472 can be to convey connection costs between firstly the UE to its 473 serving cell (that is the PID to itself) and secondly the UE and 474 neighboring cells (that is the PID to another one) and last, for both 475 uplink and downlink directions. 477 The ALTO Server can regularly update the Cost Map and send filtered 478 information to the ALTO Client. The proposed IRD design announces 479 additional context attributes "uplink", "downlink". In this case and 480 other potential cases, the context parameters need to be arranged 481 w.r.t. their possible combinations (to be further specified in the 482 IRD). For example, the IRD may announce that costs are provided for 483 contexts "uda" and "udna" and this in both contexts "uplink" and 484 "downlink". Or that costs are provided for contexts "uplink" and 485 "downlink" and this in both contexts "udna" and "uda". In such a 486 case, the IRD capability member may list the possible combinations in 487 the capabilities as follows: 489 "cost-context" : [ // ++NEW 490 { "cost-type-names" : "num-ARFcost", 491 "context-params" : [["uda", "uplink"], 492 ["uda", "downlink"], 493 ["udna", "uplink"], 494 ["udna", "downlink"]] // ++NEW 495 } 496 ] 498 This arrangement indicates that for the metric named "num-ARFcost", 499 the ALTO Server can provide 4 different values: v1 for ["uda" AND 500 "uplink"], ... v4 for ["udna" AND "downlink"]. 502 Further versions of this draft will specify more elaborated logical 503 combinations of context attribues, to moderate the length of the ALTO 504 request and support use cases as described in section 4.5.1. 506 4.4.1. Example: FCM Request for contextual 'ARFcost' 508 The ALTO Client can specify the desired cost value context parameters 509 in the request input. In particular, it can select one or more 510 combinations indicated in the IRD. Its input parameter "context- 511 params" is an array of all the desired combinations. In this 512 example, the ALTO Client wants to know the ALTO connection costs 513 within Cell1 and Cell2. For each cell, the Client wants the 4 514 values, corresponding to all the combinations indicated below. 516 POST /costmap/filtered/calendar/context HTTP/1.1 517 Host: alto.example.com 518 Accept: application/alto-costmap+json,application/alto-error+json 519 Content-Type: application/alto-costmapfilter+json 520 Content-Length: ### 522 { 523 "cost-type" : { "cost-mode": "numerical", "cost-metric": "ARFcost"}, 524 "calendared" : true, 525 "context-params" : [["uda", "uplink"], // ++NEW 526 ["uda", "downlink"], 527 ["udna", "uplink"], 528 ["udna", "downlink"]], 529 "pids" : [ 530 {"srcs" : [ "Cell1"], "dsts" : [ "Cell1"]}, 531 {"srcs" : [ "Cell2"], "dsts" : [ "Cell2"]} 532 ] 533 } 535 4.4.2. Example: FCM Response for contextual ARFcost 537 The ALTO response provides, for each requested ("src", "dest") pair, 538 a calendar of 12 JSON values, where each is an array of cost values 539 arranged as specified in the "meta" of the ALTO response. 541 HTTP/1.1 200 OK 542 Content-Type: application/alto-costmap+json 543 Content-Length: ### 545 { 546 "meta" : { 547 "dependent-vtags" : [ 548 {"resource-id": "my-default-network-map", 549 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 550 } 551 ], 552 "cost-type" : {"cost-mode": "numerical", "cost-metric": "ARFcost"}, 553 "calendar-response-attributes" : 554 { "calendar-start-time" : Tue, 1 Sept 2016 13:00:00 GMT, 555 "time-interval-size" : "5 minute", 556 "numb-intervals" : 12}, 557 "context-params" : [["uda", "uplink"], // ++NEW 558 ["uda", "downlink"], 559 ["udna", "uplink"], 560 ["udna", "downlink"]] 561 } // end meta 562 "cost-map" : { 563 "Cell1": { "Cell1": [[70, 20, 90, 20], ... ,[50, 20, 70, 20]], 564 "Cell2": { "Cell2": [[20, 70, 20, 90], ... ,[20, 50, 20, 70]] 565 } 566 } 568 4.5. Use case 2: example ALTO transactions for the ECS 570 In this use case, the UE requests the ECS to a local ALTO server for 571 the routingcost to the PGW and wants the metric values varying w.r.t. 572 the "access-type" and "SLA-id". Note that the "context" related 573 design feature can be easily transposed for the Cost Map Service. 575 4.5.1. Use case 2: example with logical context parameter combinations 577 This section proposes a design, allowing a Client to arrange input 578 context parameters in logical combinations. The purpose is to show 579 how such combinations of context parameters avoids specifying as many 580 metrics and moderates the amount of exchanged data. 582 In this example the ALTO Server indicates in its IRD that it can 583 provide endpoint cost maps for the example metrics "routingcost" and 584 "bandwidthscore". Values for metric "routingcost" are provided 585 w.r.t. 2 types of context parameters. The ALTO Client may query 586 values for metric "routingcost" for either of these types of 587 parameters or both or none. 589 For each type, the parameters are listed in an array. We have 2 590 arrays: 592 - ["cell", "wifi", "lan"] 594 - ["SLA-1", "SLA-2", "SLA-3"] 596 This indicates that in each array, the client can pick one or more 597 parameters and combine them with one or more parameters in the second 598 array. The ALTO Server will provide costs w.r.t. the AND combination 599 across and within arrays. 601 In the present example, if the Client requests cost values for the 602 combination: 604 [["cell", "wifi"], ["SLA-3"]] 606 The server will provide 2 values: one for ("cell" AND "SLA-3")and the 607 second one for ("wifi" and "SLA"-3"). 609 4.5.1.1. Example IRD with logical context parameter combinations 611 The IRD below specifies the possibility to combine parameters from 612 the two arrays of the example above. 614 "resources" : { 615 "filtered-cost-calendar-map" : { 616 "uri" : "http://alto.local.example.com/endpointcostmap/lookup/context", 617 "media-types" : [ "application/alto-endpointcost+json" ], 618 "accepts" : [ "application/alto-endpointcostparams+json" ], 619 "capabilities" : { 620 "cost-constraints" : true, 621 "cost-type-names" : [ "num-routingcost", 622 "num-bandwidthscore"], 623 "cost-context" : [// ++NEW 624 {"cost-type-names" : "num-routingcost", 625 "context-params" : [["cell", "wifi", "lan"], 626 ["SLA-1", "SLA-2", "SLA-3"]] 627 } 628 ] 629 } // end ECM capab 630 ... other resources ... 631 } // end resources 633 4.5.1.2. Use case 2: example ECS request with logical context parameter 634 combinations 636 The ALTO Client queries the ECS between 2 endpoints for the following 637 combinations: ("cell" AND "SLA-3")and ("wifi" and "SLA"-3") and thus 638 arranges its input context parameters as follows: 640 POST /endpointcost/lookup/context HTTP/1.1 641 Host: alto.local.example.com 642 Content-Length: [TODO] 643 Content-Type: application/alto-endpointcostparams+json 644 Accept: application/alto-endpointcost+json,application/alto-error+json 646 { 647 "cost-type" : {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, 648 "context-params" : [["cell", "wifi"], ["SLA-3"]], 649 "endpoints" : { 650 "srcs": [ "ipv4:192.0.2.2" ], 651 "dsts": [ 652 "ipv4:192.0.2.89", 653 "ipv6:2000::1:2345:6789:abcd" 654 ] 655 } 656 } 658 4.5.1.3. Use case 2: example ECS response with logical context 659 parameter combinations 661 Following the ALTO Client request of the above example, The ALTO 662 Server provides a response as follows: 664 HTTP/1.1 200 OK 665 Content-Length: [TODO] 666 Content-Type: application/alto-endpointcost+json 668 { 669 "meta" : { 670 "cost-type" : {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, 671 "context-params" : [["cell", "wifi"], ["SLA-3"]] 672 } // end meta 674 "endpoint-cost-map" : { 675 "ipv4:192.0.2.2": { 676 "ipv4:192.0.2.89" : [10, 4], 677 "ipv6:2000::1:2345:6789:abcd" : [4, 6] 678 } 679 } 680 } 682 5. Deployment case: local ALTO Server cascaded with global ALTO Server 684 To maintain scalability, the ALTO coverage network zone can be 685 decomposed in one "local" ALTO Server part covering a restricted 686 local network zone, for instance within the first IP hop range and 687 another "global" part covering the rest of the ISP network, similarly 688 to what is proposed in [draft-ietf-alto-deployments]. The local ALTO 689 server may include the guidance given by the ISP ALTO server and 690 compose it with the "global" guidance in its replies to its ALTO 691 clients. Recent ALTO WG discussions open the possibility for one IRD 692 to indicate multiple network maps having different levels of detail. 694 5.1. Cascaded ALTO Servers with one network map each 696 In the "cascaded" use case, the ALTO Service is preferably 697 distributed among two ALTO Servers as follows: 699 The ALTO Client serving the UE is referred to as the LAOC and can be 700 located either in the UE or in the network. 702 1. A Local ALTO Server (LAOS) 704 * Hosts the information on the local EPS network, covering the 705 paths between e.g. the UEs and the cells or the PGWs, 707 * Hosts an ALTO Client that sends an ALTO request to a "global" 708 ALTO Server, covering the zone beyond the PGW. It can 709 possibly get the global Server updates using the extensions 710 specified in [draft-ietf-alto-incr-update-sse]. 712 * receives the ALTO request issued by the ALTO Client associated 713 to the UE. 715 2. a "core" ALTO Server covers the whole ISP network view, as it 716 would if the "local ALTO Service" is not available or 717 deactivated. 719 6. IANA Considerations 721 This document makes no request of IANA. 723 Note to RFC Editor: this section may be removed on publication as an 724 RFC. 726 7. Security Considerations 728 8. Acknowledgements 730 Many thanks to Dawn Chan, Li Geng, Xin Wan, Yichen Qian for their 731 feedback on this draft. 733 9. References 735 9.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, 739 DOI 10.17487/RFC2119, March 1997, 740 . 742 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 743 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 744 Traffic Optimization (ALTO) Protocol", RFC 7285, September 745 2014. 747 9.2. Informative References 749 [draft-bertz-alto-mobilitynets] 750 Bertz, L., "Mobility Network Models in ALTO", October 751 2015. 753 [draft-ietf-alto-cost-calendar] 754 Randriamasy, S., Yang, Y., Wu, Q., Deng, L., and N. 755 Schwan, "ALTO Cost Calendar", February 2017. 757 [draft-ietf-alto-deployment] 758 Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 759 S. Previdi, "draft-ietf-alto-deployments-16", July 2016. 761 [draft-ietf-alto-incr-update-sse] 762 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 763 Server-Sent Events (SSE)", Septembre 2016. 765 [draft-ietf-alto-performance-metrics] 766 Wu, Q., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, 767 "ALTO Performance Cost Metrics", March 2017. 769 [draft-rauschenbach-alto-wireless-access] 770 Rauschenbach, U., "ALTO in wireless access networks", 771 October 2014. 773 [draft-roome-alto-unified-props] 774 Roome, W., "Extensible Property Maps for the ALTO 775 Protocol", July 2016. 777 [draft-yang-alto-path-vector] 778 Bernstein, G., Gao, K., Lee, Y., Roome, W., Scharf, M., 779 and Y. Yang, "ALTO Extension: Path Vector Cost Mode", July 780 2016. 782 Appendix A. An Appendix 784 Author's Address 786 Sabine Randriamasy 787 Nokia Bell Labs 788 Route de Villejust 789 Nozay 91460 790 FRANCE 792 Email: sabine.randriamasy@nokia-bell-labs.com