idnits 2.17.1 draft-randriamasy-alto-cost-context-01.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 9 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 13, 2017) is 2573 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 633, but not defined -- Looks like a reference, but probably isn't: '10' on line 644 -- Looks like a reference, but probably isn't: '4' on line 645 -- Looks like a reference, but probably isn't: '6' on line 645 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 13, 2017 5 Expires: September 14, 2017 7 ALTO Contextual Cost Values 8 draft-randriamasy-alto-cost-context-01 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 http://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 14, 2017. 46 Copyright Notice 48 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . 6 69 4.1. Overview of context features . . . . . . . . . . . . . . 7 70 4.1.1. Applicable ALTO services . . . . . . . . . . . . . . 7 71 4.2. Example IRD . . . . . . . . . . . . . . . . . . . . . . . 7 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. Network Map: FCM Request for contextual 'RFcost' . . 11 75 4.4.2. Network Map: FCM Response for contextual RFcost . . . 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 a 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 a 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 to introduce "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. This example assumes that this cost is a unitless 164 value abstracting a (RF) cost to a cell. Our example however 165 includes 2 additional considerations: 167 - the RF cost to a cell may be impacted by its load, 169 - a UE usually transmits a fair amount of "unattended data" (UD). 171 UD is considered in one of the key features for LTE enhancements in 172 Release 13 and defined in 3GPP TS22.101 as follows: "Unattended Data 173 Traffic : Data traffic of which the user is unaware he/she initiated, 174 e.g. based on the screen/keypad lock being activated, length of time 175 since the UE last received any input from the user, known type of app 176 (e.g. an application monitoring a user's health "mHealth" may need 177 its data never treated as Unattended Data Traffic.)". UD traffic is 178 often delay tolerant and it would be beneficial for the network if 179 the UE can schedule its transmission. To this end, the UE can use an 180 instant UD Indicator (UDI) sent by the LTE network. The UDI, 181 accepted for LTE Release 13 is a single bit sent to the UE indicating 182 whether UD in a cell is allowed (UDA) or not (UDNA). The status 183 change of a UDI from UDA to UDNA is presumably triggered when the 184 cell load exceeds a given threshold T(udna). The value of T(udna) 185 may change across cells and in time but is not provided to UEs. If 186 the UE had an ALTO calendar for either T(udna) or for the abstracted 187 cell load values, it could appropriately schedule the transmission of 188 its UD, that will have to occur anyway. The UE could combine this 189 calendar with the UDI it receives from the cellular network. The UDI 190 state may change within sub-seconds and impact the data exchange. 191 What is missing in the provided LTE information is: 193 - knowing whether the UDI threshold relates to downlink or uplink 194 congestion. 196 - knowing the level of congestion that triggers a change in UDI and 197 how it may evolve in time. 199 The UE thus can advatageously combine the non-real time ALTO 200 information with the real-time UDI provided by the LTE network. The 201 present draft illustrates how ALTO can fill these gaps with the 202 support of: 204 - ALTO Cost Calendars, 206 - the proposed protocol extension providing context-dependent ALTO 207 Cost values. 209 In this use case: ALTO calendars need to be requested via for the 210 ALTO Filtered Cost Map (FCM) Service, the context parameters 211 impacting the cost values are: "uda" (Unattended Data Allowed), 212 "udna" (Unattended Data Not Allowed), "uplink", "downlink". 214 2.2. Use case 2: access-aware endpoint selection 216 In a second use case, an end-system called UEP is located in a LTE 217 network and may connect via several access technologies, e.g. 218 Cellular or WiFi. UEP may also benefit from a given Service Level 219 Agreement SLA-m. Other parameters may characterize the UEP generated 220 traffic. 222 Currently the insight of ALTO information in the path between a UE 223 and a connection node (or say Endpoint) does not provide details 224 below IP hops. However the major QoE challenges of wireless network 225 users arise in the access network, that is, in the first hop between 226 the UE and its one or more serving packet data network gateway (PGW). 227 The path of a UE to its serving PGW(s) impacts the path to the 228 content and thus the related QoE. Therefore, it is necessary to 229 inform the UE, which could take the appropriate decisions w.r.t. the 230 utilized access path. The access technology in current ALTO 231 proposals is accounted at the content location (last hop) side by 232 distinguishing whether the requested content is located in a fixed or 233 a wireless access network, as described in [draft-ietf-alto- 234 deployments] that states: "For ISPs with mobile network and fixed 235 network, the traffic optimizing problems they focus will be 236 optimizing the mobile traffic, except problems on last hop section." 238 For Mobile Network Operators (MNO) and their users, being connected 239 via e.g. cellular or trusted Wifi can hugely impact the QoE and 240 routing cost. Sometimes a 4G connection is preferable for users than 241 a poor WiFi connection although potentially more expensive. 242 Sometimes, MNOs have spare data resources or offer them for given 243 SLAs. For both parties, access-aware Endpoint selection for Users is 244 thus beneficial. One way to achieve this is that ALTO provides cost 245 values depending on qualitative contextual parameters such as access 246 technology and the access technology and SLA. 248 3. Required ALTO extensions 250 The aforementionned use cases can be supported with a few simple 251 extensions to the ALTO protocol. A number of them have already been 252 discussed in other WG drafts and use cases. The proposed extensions 253 include: 255 - Cost value context parameters: a capability to allow exposing 256 several possible context-dependent values for one metric, as proposed 257 in the present document, 259 - Entities with associated domain and properties for cellular and 260 wireless networks, that could be added to 261 [draft-roome-alto-unified-props], 263 - Cost metrics for cellular and wireless networks: these features 264 would extend current proposals in the WG,that could be added to 265 [draft-ietf-alto-performance-metrics], 267 - Extended input for the Filtered Cost Map Service: to allow the 268 input to comprise several(source-array, destination-array) pairs, as 269 it has been proposed in [draft-yang-alto-path-vector]. 271 4. Design options and examples 273 Similarly to Multi-Cost and Cost Calendar ( 274 [draft-ietf-alto-cost-calendar]), this proposal does not introduce 275 new cost modes or new media-types. It ensures backwards 276 compatibility with legacy ALTO Clients, that is: "A legacy ALTO 277 Client must be able to send legacy requests to a Cost Context aware 278 ALTO Server and get legacy responses as specified in RFC7285". 280 "A Cost Context aware ALTO Server must be able to receive and process 281 requests sent by legacy ALTO Clients, as specified in RFC 7285". 283 Besides, the proposed extension is designed to be compatible with 284 Multi-Cost ALTO and ALTO Cost Calendars 285 ([draft-ietf-alto-cost-calendar]). 287 In the present draft version, the IRD indicates the supported context 288 parameters as values encoded in JSON strings. The idea is that this 289 design simplifies the transactions, as it applies to context 290 attributes that take a limited number of values, say 1 to 5. Context 291 attributes taking numerous or unpredictible values should be handled 292 as values properties or metrics expressed in constraints. 294 4.1. Overview of context features 296 Cost context attributes are strings with values such as "wifi", 297 "cellular", "uda". 299 Cost context attributes are indicated in the IRD as capabilities of 300 an information resource. They are associated to cost type names. 302 4.1.1. Applicable ALTO services 304 Draft [draft-bertz-alto-mobilitynets] proposes to identify network 305 points of attachment (PoA) such as cells to PIDs, as PoAs are 306 endpoint types not currently supported in ALTO. The current proposal 307 is to represent cellular PIDs in an ALTO Network Map with no routes. 308 PID properties as specified in [draft-roome-alto-unified-props] could 309 be used to indicate the type of the PoA, together with other 310 properties. ALTO properties are well suited for almost static 311 attributes such as access type. 313 To indicate connection properties with frequently changing values 314 such as RF Cost, load or congestion, the ALTO Filtered Cost Map 315 service can be used. Connection properties may also be conveyed with 316 the Endpoint property service or its extensions defined in 317 [draft-roome-alto-unified-props]. 319 Costs and properties with the extensions proposed in this document 320 may be conveyed with different values depending on the context 321 parameter. The present version of this draft focuses on context 322 patrameters associated to costs. 324 4.2. Example IRD 326 The purpose of ALTO is to guide the behavior of the end systems or 327 applications without the need for networks to explicitely expose 328 their performance values. In this example, the IRD does not expose 329 the real load percentage of a cell to UE. Instead, it abstracts the 330 cell congestion by a metric called 'RFcost' represented by a number 331 between 0 and 100. The values of 'RFcost' are provided as a an ALTO 332 Calendar as specified in [draft-ietf-alto-cost-calendar-00] in 333 shorter time intervals. In addition they differ, depending on the 334 the context values "uda" and "udna". 336 Besides, the IRD provides metric 'routingcost' as a MUST specfied in 337 [RFC7285], that may represent a more administrative or monetary 338 access cost. 340 The IRD could publish the capability of a resource to provide context 341 dependent 'routingcost' values as expressed for resource "filtered- 342 cost-calendar-map". 344 HTTP/1.1 200 OK 345 Content-Length: [TODO] 346 Content-Type: application/alto-directory+json 348 { 349 "meta" : { 350 "cost-types": { 351 "num-routingcost": { 352 "cost-mode" : "numerical", 353 "cost-metric" : "routingcost" 354 }, 355 "num-RFcost": { 356 "cost-mode" : "numerical", 357 "cost-metric": "RFcost", 358 } 359 } 360 ... other meta ... 361 }, 362 "resources" : { 363 "filtered-cost-calendar-map" : { 364 "uri" : "http://alto.local.example.com/costmap/filtered/calendar/context", 365 "media-types" : [ "application/alto-endpointcost+json" ], 366 "accepts" : [ "application/alto-endpointcostparams+json" ], 367 "capabilities" : { 368 "cost-constraints" : true, 369 "cost-type-names" : [ "num-routingcost", 370 "num-RFcost"],// ++NEW 371 "calendar-attributes" : [ 372 {"cost-type-names" : "num-routingcost", 373 "time-interval-size" : "1 hour", 374 "number-of-intervals" : 24}, // MAY ALSO BE SINGLE VALUE 375 {"cost-type-names" : "num-RFcost", // ++NEW 376 "time-interval-size" : "5 minute", 377 "number-of-intervals" : 12} 378 ], 379 "cost-context" : [ // ++NEW 380 {"cost-type-names" : "num-RFcost", 381 "context-params" : ["uda", "udna", "uplink", "downlink"] 382 } 383 ] // ++NEW 384 "uses": [ "my-default-network-map" ] 385 } // end ECM capab 386 ... other resources ... 387 } // end resources 388 } // end IRD 390 4.3. Use case 1: Example scenario for the FCM Service 392 We assume an example scenario where a UE has the choice to connect to 393 2 cells C1 and C2. 395 As suggested in [draft-bertz-alto-mobilitynets], we may represent the 396 cellular topology with an ALTO Network Map comprising PIDs 397 representing the cells and named "Cell1", "Cell2", ... "Celln". A 398 format for a cell identifier has been proposed in 399 [draft-rauschenbach-alto-wireless-access] and is not being discussed 400 here. 402 As a Network Map may cover a large number of cells, the Filtered Cost 403 Map Service can be used to reduce data exchange and get information 404 on a restricted number of cells, say PID1 and PID2. 406 We assume that the ALTO Client in the UE wants to get calendared 407 values for ALTO metric "RFcost" in order to appropriately schedule 408 its unattended data transmission. The ALTO information resource 409 'ALTO Calendar' provides an array of time-dependent cost values and 410 is being specified in [draft-ietf-alto-cost-calendar]. In addition, 411 the ALTO Client wants these values for both the "uda" and "udna" 412 context. Last, we assume that the UE needs the Cost values for both 413 the uplink (UE to Cell-k) and downlink (Cell-k to UE) directions. We 414 assume that the UE is located in the PID called "Cell1". 416 In this scenario, C1 is limited by its uplink capacity, C2 is limited 417 by its downlink capacity. ALTO can be used to convey the following 418 information: 420 At time interval T1 of the next Calendar: 422 - if C1 indicates "unattended data allowed" the downlink RF cost is 423 20, and the uplink RF cost is 70 425 - if C1 indicates "unattended data NOT allowed", the downlink RF cost 426 is 20, and the uplink RF cost is 90 428 - if C2 indicates "unattended data allowed" the downlink RF cost is 429 70, and the uplink RF cost is 20 431 - if C2 indicates "unattended data NOT allowed", the downlink RF cost 432 is 90, in the uplink RF cost is 20. 434 The ALTO Calendar provides values for the other 11 time intervals Ti. 436 4.4. Design option: Network Map with cells as PIDs 438 In this design, the cellular topology is represented with an ALTO 439 Network Map comprising PIDs named "Cell1", "Cell2", ... "Celln". The 440 UE is located in one of these PIDs. A Cost Map is associated to this 441 Network Map and conveys metrics indicated in the IRD. The Cost Map 442 is requested to convey connection costs between firstly the UE to its 443 serving cell (that is the PID to itself) and secondly the UE and 444 neighboring cells (that is the PID to another one) and last, for both 445 uplink and downlink directions. 447 The ALTO Server can regularly update the Cost Map and send filtered 448 information to the ALTO Client. The proposed IRD design announces 449 additional context attributes "uplink", "downlink". In this case and 450 other potential cases, the context parameters need to be arranged 451 w.r.t. their possible combinations (to be further specified in the 452 IRD). For example, the IRD may announce that costs are provided for 453 contexts "uda" and "udna" and this in both contexts "uplink" and 454 "downlink". Or that costs are provided for contexts "uplink" and 455 "downlink" and this in both contexts "udna" and "uda". In such a 456 case, the IRD capability member may list the possible combinations in 457 the capabilities as follows: 459 "cost-context" : [ // ++NEW 460 { "cost-type-names" : "num-RFcost", 461 "context-params"[["uda", "uplink"], 462 ["uda", "downlink"], 463 ["udna", "uplink"], 464 ["udna", "downlink"]] // ++NEW 465 } 466 ] 468 This arrangement indicates that for the metric named "num-RFcost", 469 the ALTO Server can provide 4 different values: v1 for ["uda" AND 470 "uplink"], ... v4 for ["udna" AND "downlink"]. 472 Further versions may specify more elaborated logical combinations of 473 context parameters. 475 4.4.1. Network Map: FCM Request for contextual 'RFcost' 477 The ALTO Client can specify the desired cost value context parameters 478 in the request input. In particular, it can select one or more 479 combinations indicated in the IRD. Its input parameter "cost- 480 context-params" is an array of all the desired combinations. In this 481 example, the ALTO Client wants 4 values, corresponding to all the 482 indicated combinations. 484 POST /costmap/filtered/calendar/context HTTP/1.1 485 Host: alto.example.com 486 Accept: application/alto-costmap+json,application/alto-error+json 487 Content-Type: application/alto-costmapfilter+json 488 Content-Length: ### 490 { 491 "cost-type" : { "cost-mode": "numerical", "cost-metric": "RFcost"}, 492 "calendared" : true, 493 "context-params" : [["uda", "uplink"], // ++NEW 494 ["uda", "downlink"], 495 ["udna", "uplink"], 496 ["udna", "downlink"]], 497 "pids" : [ 498 {"srcs" : [ "Cell1"], "dsts" : [ "Cell1", "Cell2"]}, 499 {"srcs" : [ "Cell2"], "dsts" : [ "Cell1", "Cell2"]} 500 ] 501 } 503 4.4.2. Network Map: FCM Response for contextual RFcost 505 The ALTO response provides, for each requested ("src", "dest") pair, 506 a calendar of 12 JSON values, where each is an array of cost values 507 arranged as specified in the "meta" of the ALTO response. 509 HTTP/1.1 200 OK 510 Content-Type: application/alto-costmap+json 511 Content-Length: ### 513 { 514 "meta" : { 515 "dependent-vtags" : [ 516 {"resource-id": "my-default-network-map", 517 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 518 } 519 ], 520 "cost-type" : {"cost-mode": "numerical", "cost-metric": "RFcost"}, 521 "calendar-response-attributes" : 522 { "calendar-start-time" : Tue, 1 Sept 2016 13:00:00 GMT, 523 "time-interval-size" : "5 minute", 524 "numb-intervals" : 12}, 525 "context-params" : [["uda", "uplink"], // ++NEW 526 ["uda", "downlink"], 527 ["udna", "uplink"], 528 ["udna", "downlink"]] 529 } // end meta 530 "cost-map" : { 531 "Cell1": { "Cell1": [[70, 20, 90, 20], ... ,[50, 20, 70, 20]], 532 "Cell2": { "Cell2": [[20, 70, 20, 90], ... ,[20, 50, 20, 70]] 533 } 534 } 536 4.5. Use case 2: example ALTO transactions for the ECS 538 In this use case, the UE requests the ECS to a local ALTO server for 539 the routingcost to the PGW and wants the metric values varying w.r.t. 540 the "access-type" and "SLA-id". Note that the "context" related 541 design feature can be easily transposed for the Cost Map Service. 543 4.5.1. Use case 2: example with logical context parameter combinations 545 This section proposes a design, allowing a Client to arrange input 546 context parameters in logical combinations. The purpose is to show 547 how such combinations of context parameters avoids specifying as many 548 metrics and moderates the amount of exchanged data. 550 In this example the ALTO Server indicates in its IRD that it can 551 provide endpoint cost maps for metrics "routingcost" and 552 "bandwidthscore". Values for metric "routingcost" are provided 553 w.r.t. 2 types of context parameters. The ALTO Client may query 554 values for metric "routingcost" for either of these types of 555 parameters or both or none. 557 For each type, the parameters are listed in an array. We have 2 558 arrays: 560 - ["cell", "wifi", "lan"] 562 - ["SLA-1", "SLA-2", "SLA-3"] 564 This indicates that in each array, the client can pick one or more 565 parameters and combine them with one or more parameters in the second 566 array. The ALTO Server will provide costs w.r.t. the AND combination 567 accross and within arrays. 569 In the present example, if the Client requests cost values for the 570 combination: 572 [["cell", "wifi"], ["SLA-3"]] 574 The server will provide 2 values: one for ("cell" AND "SLA-3")and the 575 second one for ("wifi" and "SLA"-3"). 577 4.5.1.1. Example IRD with logical context parameter combinations 579 The IRD below specifies the possibility to combine parameters from 580 the two arrays of the example above. 582 "resources" : { 583 "filtered-cost-calendar-map" : { 584 "uri" : "http://alto.local.example.com/endpointcostmap/lookup/context", 585 "media-types" : [ "application/alto-endpointcost+json" ], 586 "accepts" : [ "application/alto-endpointcostparams+json" ], 587 "capabilities" : { 588 "cost-constraints" : true, 589 "cost-type-names" : [ "num-routingcost", 590 "num-bandwidthscore"], 591 "cost-context" : [// ++NEW 592 {"cost-type-names" : "num-routingcost", 593 "context-params" : [["cell", "wifi", "lan"], 594 ["SLA-1", "SLA-2", "SLA-3"]] 595 } 596 ] 597 } // end ECM capab 598 ... other resources ... 599 } // end resources 601 4.5.1.2. Use case 2: example ECS request with logical context parameter 602 combinations 604 The ALTO Client queries the ECS between 2 endpoints for the following 605 combinations: ("cell" AND "SLA-3")and ("wifi" and "SLA"-3") and thus 606 arranges its input context parameters as follows: 608 POST /endpointcost/lookup/context HTTP/1.1 609 Host: alto.local.example.com 610 Content-Length: [TODO] 611 Content-Type: application/alto-endpointcostparams+json 612 Accept: application/alto-endpointcost+json,application/alto-error+json 614 { 615 "cost-type" : {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, 616 "context-params" : [["cell", "wifi"], ["SLA-3"]], 617 "endpoints" : { 618 "srcs": [ "ipv4:192.0.2.2" ], 619 "dsts": [ 620 "ipv4:192.0.2.89", 621 "ipv6:2000::1:2345:6789:abcd" 622 ] 623 } 624 } 626 4.5.1.3. Use case 2: example ECS response with logical context 627 parameter combinations 629 Following the ALTO Client request of the above example, The ALTO 630 Server provides a response as follows: 632 HTTP/1.1 200 OK 633 Content-Length: [TODO] 634 Content-Type: application/alto-endpointcost+json 636 { 637 "meta" : { 638 "cost-type" : {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, 639 "context-params" : [["cell", "wifi"], ["SLA-3"]] 640 } // end meta 642 "endpoint-cost-map" : { 643 "ipv4:192.0.2.2": { 644 "ipv4:192.0.2.89" : [10, 4], 645 "ipv6:2000::1:2345:6789:abcd" : [4, 6] 646 } 647 } 648 } 650 5. Deployment case: local ALTO Server cascaded with global ALTO Server 652 To maintain scalability, the ALTO coverage network zone can be 653 decomposed in one "local"ALTO Server part covering a restricted local 654 network zone, for instance within the first IP hop range and another 655 "global" part covering the rest of the ISP network, similarly to what 656 is proposed in [draft-ietf-alto-deployments]. The local ALTO server 657 may include the guidance given by the ISP ALTO server and compose it 658 with the "global" guidance in its replies to its ALTO clients. 659 Recent ALTO WG discussions open the possibility for one IRD to 660 indicate multiple network maps having different levels of detail. 662 5.1. Cascaded ALTO Servers with one network map each 664 In the "cascaded" use case, the ALTO Service is preferably 665 distributed among two ALTO Servers as follows: 667 The ALTO Client serving the UE is referred to as the LAOC and can be 668 located either in the UE or in the network. 670 1. A Local ALTO Server (LAOS) 672 * Hosts the information on the local EPS network, covering the 673 paths between e.g. the UEs and the cells or the PGWs, 675 * Hosts an ALTO Client that sends an ALTO request to a "global" 676 ALTO Server, covering the zone beyond the PGW. It can 677 possibly get the global Server updates using the extensions 678 specified in [draft-ietf-alto-incr-update-sse]. 680 * receives the ALTO request issued by the ALTO Client associated 681 to the UE. 683 2. a "core" ALTO Server covers the whole ISP network view, as it 684 would if the "local ALTO Service" is not available or 685 deactivated. 687 6. IANA Considerations 689 This document makes no request of IANA. 691 Note to RFC Editor: this section may be removed on publication as an 692 RFC. 694 7. Security Considerations 696 8. Acknowledgements 698 9. References 700 9.1. Normative References 702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, 704 DOI 10.17487/RFC2119, March 1997, 705 . 707 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 708 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 709 Traffic Optimization (ALTO) Protocol", RFC 7285, September 710 2014. 712 9.2. Informative References 714 [draft-bertz-alto-mobilitynets] 715 Bertz, L., "Mobility Network Models in ALTO", October 716 2015. 718 [draft-ietf-alto-cost-calendar] 719 Randriamasy, S., Yang, Y., Wu, Q., Deng, L., and N. 720 Schwan, "ALTO Cost Calendar", February 2017. 722 [draft-ietf-alto-deployment] 723 Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 724 S. Previdi, "draft-ietf-alto-deployments-16", July 2016. 726 [draft-ietf-alto-incr-update-sse] 727 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 728 Server-Sent Events (SSE)", Septembre 2016. 730 [draft-ietf-alto-performance-metrics] 731 Wu, Q., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, 732 "ALTO Performance Cost Metrics", March 2017. 734 [draft-rauschenbach-alto-wireless-access] 735 Rauschenbach, U., "ALTO in wireless access networks", 736 October 2014. 738 [draft-roome-alto-unified-props] 739 Roome, W., "Extensible Property Maps for the ALTO 740 Protocol", July 2016. 742 [draft-yang-alto-path-vector] 743 Bernstein, G., Gao, K., Lee, Y., Roome, W., Scharf, M., 744 and Y. Yang, "ALTO Extension: Path Vector Cost Mode", July 745 2016. 747 Appendix A. An Appendix 749 Author's Address 751 Sabine Randriamasy 752 Nokia Bell Labs 753 Route de Villejust 754 Nozay 91460 755 FRANCE 757 Email: sabine.randriamasy@nokia-bell-labs.com