idnits 2.17.1 draft-ietf-alto-cost-calendar-17.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 date (February 23, 2020) is 1524 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) == Unused Reference: 'RFC5246' is defined on line 1398, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-20 == Outdated reference: A later version (-28) exists of draft-ietf-alto-performance-metrics-08 == Outdated reference: A later version (-06) exists of draft-xiang-alto-multidomain-analytics-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Randriamasy 3 Internet-Draft Nokia Bell Labs 4 Intended status: Standards Track R. Yang 5 Expires: August 26, 2020 Yale University 6 Q. Wu 7 Huawei 8 L. Deng 9 China Mobile 10 N. Schwan 11 Thales Deutschland 12 February 23, 2020 14 ALTO Cost Calendar 15 draft-ietf-alto-cost-calendar-17 17 Abstract 19 This document is an extension to the base Application-Layer Traffic 20 Optimization (ALTO) protocol. It extends the ALTO cost information 21 service so that applications decide not only 'where' to connect, but 22 also 'when'. This is useful for applications that need to perform 23 bulk data transfer and would like to schedule these transfers during 24 an off-peak hour, for example. This extension introduces ALTO Cost 25 Calendar, with which an ALTO Server exposes ALTO cost values in JSON 26 arrays where each value corresponds to a given time interval. The 27 time intervals as well as other Calendar attributes, are specified in 28 the Information Resources Directory and ALTO Server responses. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 26, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Some recent known uses . . . . . . . . . . . . . . . . . 4 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 68 3. Overview of ALTO Cost Calendars and terminology . . . . . . . 5 69 3.1. ALTO Cost Calendar overview . . . . . . . . . . . . . . . 5 70 3.2. ALTO Cost Calendar information features . . . . . . . . . 6 71 3.3. ALTO Calendar design characteristics . . . . . . . . . . 7 72 3.3.1. ALTO Cost Calendar for all cost modes . . . . . . . . 8 73 3.3.2. Compatibility with legacy ALTO Clients . . . . . . . 8 74 4. ALTO Calendar specification: IRD extensions . . . . . . . . . 9 75 4.1. Calendar attributes in the IRD resource capabilities . . 9 76 4.2. Calendars in a delegate IRD . . . . . . . . . . . . . . . 11 77 4.3. Example IRD with ALTO Cost Calendars . . . . . . . . . . 11 78 5. ALTO Calendar specification: Service Information Resources . 15 79 5.1. Calendar extensions for Filtered Cost Maps (FCM) . . . . 15 80 5.1.1. Calendar extensions in Filtered Cost Map requests . . 15 81 5.1.2. Calendar extensions in Filtered Cost Map responses . 16 82 5.1.3. Use case and example: FCM with a bandwidth Calendar . 19 83 5.2. Calendar extensions in the Endpoint Cost Service . . . . 20 84 5.2.1. Calendar specific input in Endpoint Cost requests . . 20 85 5.2.2. Calendar attributes in the Endpoint Cost response . . 21 86 5.2.3. Use case and example: ECS with a routingcost Calendar 22 87 5.2.4. Use case and example: ECS with a multi-cost Calendar 88 for routingcost and owdelay . . . . . . . . . . . . . 24 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 91 8. Operational Considerations . . . . . . . . . . . . . . . . . 28 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 95 10.2. Informative References . . . . . . . . . . . . . . . . . 30 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 98 1. Introduction 100 The base Application-Layer Traffic Optimization (ALTO) protocol 101 specified in [RFC7285] provides guidance to overlay applications that 102 need to select one or several hosts from a set of candidates able to 103 provide a desired resource. This guidance is based on parameters 104 that affect performance and efficiency of the data transmission 105 between the hosts such as the topological distance. The goal of ALTO 106 is to improve the Quality of Experience (QoE) in the application 107 while optimizing resource usage in the underlying network 108 infrastructure. 110 The ALTO protocol in [RFC7285] specifies a network map which defines 111 groupings of endpoints in provider-defined network regions identified 112 by Provider-defined Identifiers (PIDs). The Cost Map Service, 113 Endpoint Cost Service (ECS) and Endpoint Ranking Service then provide 114 ISP-defined costs and rankings for connections among the specified 115 endpoints and PIDs and thus incentives for application clients to 116 connect to ISP preferred locations, for instance, to reduce their 117 costs. For the reasons outlined in the ALTO problem statement 118 [RFC5693] and requirement AR-14 of [RFC6708], ALTO does not 119 disseminate network metrics that change frequently. In a network, 120 the costs can fluctuate for many reasons having to do with 121 instantaneous traffic load or due to diurnal patterns of traffic 122 demand or planned events such as network maintenance, holidays or 123 highly publicized events. Thus, an ALTO application wishing to use 124 the Cost Map and Endpoint Cost Service at some future time will have 125 to estimate the state of the network at that time, a process that is, 126 at best, fragile and brittle since the application does not have any 127 visibility into the state of the network. Providing network costs 128 for only the current time thus may not be sufficient, in particular 129 for applications that can schedule their traffic in a span of time, 130 for example by deferring backups or other background traffic to off- 131 peak hours. 133 In case the ALTO Cost value changes are predictable over a certain 134 period of time and the application does not require immediate data 135 transfer, it can save time to get the whole set of cost values over 136 this period in one single ALTO response. Using this set to schedule 137 data transfers allows optimizing the network resources usage and QoE. 138 ALTO Clients and Servers can also minimize their workload by reducing 139 and accordingly scheduling their data exchanges. 141 This document extends [RFC7285] to allow an ALTO Server to provide 142 network costs for a given duration of time. A sequence of network 143 costs across a time span for a given pair of network locations is 144 named an "ALTO Cost Calendar". The Filtered Cost Map Service and 145 Endpoint Cost Service are extended to provide Cost Calendars. In 146 addition to this functional ALTO enhancement, we expect to further 147 save network and storage resources by gathering multiple Cost Values 148 for one Cost Type into one single ALTO Server response. 150 In this document, an "ALTO Cost Calendar" is specified in terms of 151 information resources capabilities that are applicable to time- 152 sensitive ALTO metrics. An ALTO Cost Calendar exposes ALTO Cost 153 Values in JSON arrays, see [RFC8259], where each value corresponds to 154 a given time interval. The time intervals as well as other Calendar 155 attributes are specified in the Information Resources Directory (IRD) 156 and in the Server response to allow the ALTO Client to interpret the 157 received ALTO values. Last, the extensions for ALTO Calendars are 158 applicable to any Cost Mode and they ensure backwards compatibility 159 with legacy ALTO Clients. 161 In the rest of this document, Section 2 provides the design 162 characteristics. Sections 3 and 4 define the formal specifications 163 for the IRD and the information resources. IANA, security and 164 operational considerations are addressed respectively in sections 165 Section 6, Section 7 and Section 8. 167 1.1. Some recent known uses 169 A potential use case is the SENSE project, see [SENSE-sdn-e2e-net], 170 who is implementing smart network services to dynamically build end- 171 to-end virtual guaranteed networks across administrative domains, 172 with no manual intervention. The initial SENSE services include 173 informing applications on the availability of bandwidth resources or 174 feasibility of some requested Time-Bandwidth-Product (TBP) during a 175 specific time period. ALTO Calendars can support these services if 176 the Calendar start date and duration cover the period of interest of 177 the requesting applications. 179 The need of future scheduling of large scale traffic that can be 180 addressed by the ALTO protocol is also motivated by Unicorn, a 181 unified resource orchestration framework for multi-domain, geo- 182 distributed data analytics, see 183 [I-D.xiang-alto-multidomain-analytics]. 185 1.2. Terminology 187 o ALTO transaction: A request/response exchange between an ALTO 188 Client and an ALTO Server. 190 o Client: When used with a capital "C", this term refers to an ALTO 191 Client. 193 o Calendar, Cost Calendar: When used with capitalized words, these 194 terms refer to an ALTO Cost Calendar. 196 o Endpoint (EP): An endpoint is defined as in Section 2.1 of 197 [RFC7285]. It can be, for example, a peer, a CDN storage 198 location, a physical server involved in a virtual server-supported 199 application, a party in a resource-sharing swarm such as a 200 computation grid, or an online multi-party game. 202 o Server: When used with a capital "S", this term refers to an ALTO 203 Server. 205 2. Requirements Language 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 209 "OPTIONAL" in this document are to be interpreted as described in BCP 210 14 [RFC2119] [RFC8174] when, and only when, they appear in all 211 capitals, as shown here. 213 When the words appear in lower case, they are to be interpreted with 214 their natural language meanings. 216 3. Overview of ALTO Cost Calendars and terminology 218 This section gives a non-normative overview of the design. It 219 assumes the reader is familiar with the ALTO protocol [RFC7285]. 220 Normative specifications are given in the following sections. 222 3.1. ALTO Cost Calendar overview 224 An ALTO Cost Calendar provided by the ALTO Server provides 2 225 information items: 227 o an array of values for a given metric, where each value specifies 228 the metric corresponding to a time interval, where the value array 229 can sometimes be a cyclic pattern that repeats a certain number of 230 times. 232 o attributes describing the time scope of the Calendar, including 233 the size and number of the intervals and the date of the starting 234 point of the Calendar, allowing an ALTO Client to interpret the 235 values properly. 237 An ALTO Cost Calendar can be used like a "time table" to figure out 238 the best time to schedule data transfers and also to proactively 239 manage application traffic given predictable events such as expected 240 spike in traffic due to crowd gathering (concerts, sports, etc.), 241 traffic-intensive holidays and network maintenance. A Calendar may 242 be viewed as a synthetic abstraction of, for example, real 243 measurements gathered over previous periods on which statistics have 244 been computed. However, like for any schedule, unexpected network 245 incidents may require the current ALTO Calendar to be updated and re- 246 sent to the ALTO Clients needing it. The "ALTO Incremental Updates 247 Using Server-Sent Events (SSE)" Service 248 [I-D.ietf-alto-incr-update-sse] can be used to update the calendar 249 faster if supported by both the server and the client. 251 Most likely, the ALTO Cost Calendar would be used for the Endpoint 252 Cost Service, assuming that a limited set of feasible Endpoints for a 253 non-real time application is already identified, that they do not 254 need to be accessed immediately and that their access can be 255 scheduled within a given time period. The Filtered Cost Map Service 256 is also applicable as long as the size of the Map allows it. 258 3.2. ALTO Cost Calendar information features 260 The Calendar attributes are provided in the Information Resources 261 Directory (IRD) and in ALTO Server responses. The IRD announces 262 attributes without date values in its information resources 263 capabilities, whereas attributes with time dependent values are 264 provided in the "meta" section of Server responses. The ALTO Cost 265 Calendar attributes provide the following information: 267 o attributes to describe the time scope of the Calendar value array: 269 * applicable time interval size for each Calendar value, defined 270 in seconds, that can cover a wide range of values. 272 * duration of the Calendar: e.g., the number of intervals 273 provided in the Calendar. 275 o "calendar-start-time": specifying when the Calendar starts, that 276 is to which date the first value of the Cost Calendar is 277 applicable. 279 o "repeated": an optional attribute indicating how many iterations 280 of the provided Calendar will have the same values. The server 281 may use it to allow the client to schedule its next request and 282 thus save its own workload by reducing processing of similar 283 requests. 285 Attribute "repeated" may take a very high value if a Calendar 286 represents a cyclic value pattern that the Server considers valid for 287 a long period. In this case, the Server will only update the 288 Calendar values once this period has elapsed or if an unexpected 289 event occurs on the network. See Section 8 for more discussion. 291 3.3. ALTO Calendar design characteristics 293 The extensions in this document encode requests and responses using 294 JSON [RFC8259]. 296 Formally, the cost entries in an ALTO cost map can be any type of 297 JSON value [RFC8259], (see the DstCosts object in Section 11.2.3.6 of 298 [RFC7285]). However, that section states that an implementation of 299 [RFC7285] SHOULD assume that the cost is a JSON number and fail to 300 parse if it is not, unless the implementation is using an extension 301 that signals a different data type. This document extends the 302 definition of a legacy cost map given in [RFC7285] to allow a cost 303 entry to be an array of values, one per time interval, instead of 304 just one number. 306 To realize an ALTO Calendar, this document extends: the IRD and the 307 ALTO requests and responses for Cost Calendars. 309 This extension is designed to be lightweight and to ensure backwards 310 compatibility with base protocol ALTO Clients and with other 311 extensions. It relies on section 8.3.7 "Parsing of Unknown Fields" 312 of [RFC7285] that writes: "Extensions may include additional fields 313 within JSON objects defined in this document. ALTO implementations 314 MUST ignore unknown fields when processing ALTO messages." 316 The Calendar-specific capabilities are integrated in the information 317 resources of the IRD and in the "meta" member of ALTO responses to 318 Cost Calendars requests. A Calendar and its capabilities are 319 associated with a given information resource and within this 320 information resource with a given cost type. This design has several 321 advantages: 323 o it does not introduce a new mode, 325 o it does not introduce new media types, 327 o it allows an ALTO Server to offer Calendar capabilities on a cost 328 type, with attributes values adapted to each information resource. 330 The applicable Calendared information resources are: 332 o the Filtered Cost Map, 333 o the Endpoint Cost Map. 335 The ALTO Server can choose in which frequency it provides cost 336 Calendars to ALTO Clients. It may either provide Calendar updates 337 starting at the request date, or carefully schedule its updates so as 338 to take profit from a potential repetition/periodicity of Calendar 339 values. 341 3.3.1. ALTO Cost Calendar for all cost modes 343 An ALTO Cost Calendar is well-suited for values encoded in the 344 "numerical" mode. Actually, a Calendar can also represent metrics in 345 other modes considered as compatible with time-varying values. For 346 example, types of Cost values such as JSONBool can also be 347 calendared, as their value may be 'true' or 'false' depending on 348 given time periods or likewise, values represented by strings, such 349 as "medium", "high", "low", "blue", "open". 351 Note also that a Calendar is suitable as well for time-varying 352 metrics provided in the "ordinal" mode, if these values are time- 353 varying and the ALTO Server provides updates of cost value based 354 preferences. 356 3.3.2. Compatibility with legacy ALTO Clients 358 The ALTO protocol extensions for Cost Calendars have been defined so 359 as to ensure that Calendar capable ALTO Servers can provide legacy 360 ALTO Clients with legacy information resources as well. That is, a 361 legacy ALTO Client can request resources and receive responses as 362 specified in [RFC7285]. 364 A Calendar-aware ALTO Server MUST implement the base protocol 365 specified in [RFC7285]. 367 As a consequence, when a metric is available as a Calendar array, it 368 also MUST be available as a single value as required by [RFC7285]. 369 The Server, in this case, provides the current value of the metric to 370 either Calendar-aware Clients not interested in future or time-based 371 values, or Clients implementing [RFC7285] only. 373 For compatibility with legacy ALTO Clients specified in [RFC7285], 374 calendared information resources are not applicable for full cost 375 maps for the following reason: a legacy ALTO Client would receive a 376 calendared cost map via an HTTP 'GET' command. As specified in 377 section 8.3.7 of [RFC7285], it will ignore the Calendar Attributes 378 indicated in the "meta" of the responses. Therefore, lacking 379 information on Calendar attributes, it will not be able to correctly 380 interpret and process the values of the received array of Calendar 381 cost values. 383 Therefore, calendared information resources MUST be requested via the 384 Filtered Cost Map Service or the Endpoint Cost Service, using a POST 385 method. 387 In the base protocol [RFC7285] section 11.2.3.6, an ALTO cost is 388 specified as a generic JSONValue, allow extensions. Implementations 389 of only the base protocol [RFC7285] can assume a cost is only a 390 JSONNumber, and the implementor of this extension SHOULD consider 391 that the cost in this extension can be an array. 393 4. ALTO Calendar specification: IRD extensions 395 The Calendar attributes in the IRD information resources capabilities 396 carry constant dateless values. A Calendar is associated with an 397 information resource rather than a cost type. For example, a Server 398 can provide a "routingcost" Calendar for the Filtered Cost Map 399 Service at a granularity of one day and a "routingcost" Calendar for 400 the Endpoint Cost Service at a finer granularity but for a limited 401 number of endpoints. An example IRD with Calendar specific features 402 is provided in Section 4.3. 404 4.1. Calendar attributes in the IRD resource capabilities 406 A Cost Calendar for a given Cost Type MUST be indicated in the IRD by 407 an object of type CalendarAttributes. A CalendarAttribute object is 408 represented by the "calendar-attributes" member of a resource entry. 409 Each CalendarAttributes object applies to a set of one or more cost 410 types. A Cost Type name MUST appear no more than once in the 411 "calendar-attributes" member of a resource entry; multiple 412 appearances of a Cost Type name in CalendarAttributes object of the 413 "calendar-attributes" member MUST cause the ALTO Client to ignore any 414 occurrences of this name beyond the first encountered occurrence. 416 It is RECOMMENDED for an ALTO Server that the time interval size 417 specified in the IRD is the smallest possible one that it can 418 provide. The Client can aggregate cost values on its own if it needs 419 a larger granularity. 421 The encoding format for object CalendarAttributes, using JSON 422 [RFC8259], is as follows: 424 CalendarAttributes calendar-attributes <1..*>; 425 object{ 426 JSONString cost-type-names <1..*>; 427 JSONNumber time-interval-size; 428 JSONNumber number-of-intervals; 429 } CalendarAttributes; 431 o "cost-type-names": 433 * An array of one or more elements indicating the cost-type-names 434 in the IRD entry to which the capabilities apply. 436 o "time-interval-size": 438 * is the duration of an ALTO Calendar time interval in seconds. 439 A "time-interval-size" value contains a non-negative 440 JSONNumber. Example values are: 300 and 7200, meaning that 441 each Calendar value applies on a time interval that lasts 5 442 minutes and 2 hours, respectively. Since the interval size can 443 be smaller than 1 second (e.g., 100 ms), the value specified 444 can also be a floating point (e.g., 0.1). Both ALTO clients 445 and servers should be aware of potential issues caused by the 446 precision issues caused by using floating point numbers. For 447 example, the server may have an internal, integer 448 representation in ms, and store 100 as an int (0.1 sec) in the 449 local storage; the sever sends "0.1" as the interval size to 450 the client; the client may use a float/double to store the JSON 451 number, which may not represent 0.1 precisely. To improve 452 interoperability, the server and the client SHOULD use IEEE 754 453 double-precision floating point [IEEE.754.2008] to store this 454 value, in unit of seconds. 456 o "number-of-intervals": 458 * is the positive integer number, at least equal to 1, to 459 indicate of number of values of the Cost Calendar array. 461 - Attribute "cost-type-names" provides a better readability to the 462 Calendar attributes specified in the IRD and avoids confusion with 463 Calendar attributes of other cost-types. 465 - Multiplying 'time-interval-size' by 'number-of-intervals' provides 466 the duration of the provided Calendar. For example, an ALTO Server 467 may provide a Calendar for ALTO values changing every 'time-interval- 468 size' equal to 5 minutes. If 'number-of-intervals' has the value 12, 469 then the duration of the provided Calendar is "1 hour". 471 4.2. Calendars in a delegate IRD 473 It may be useful to distinguish IRD resources supported by the base 474 ALTO protocol from resources supported by its extensions. To achieve 475 this, one option, is that a "root" ALTO Server implementing base 476 protocol resources delegates "specialized" information resources such 477 as the ones providing Cost Calendars, to another ALTO Server running 478 in a subdomain that is specified with its URI in the "root" ALTO 479 Server. This option is described in Section 9.2.4 "Delegation using 480 IRDs" of [RFC7285]. 482 This document provides an example, where a "root" ALTO Server runs in 483 a domain called "alto.example.com". It delegates the announcement of 484 Calendars capabilities to an ALTO Server running in a subdomain 485 called "custom.alto.example.com". The location of the "delegate 486 Calendar IRD" is assumed to be indicated in the "root" IRD by the 487 resource entry: "custom-calendared-resources". 489 Another advantage is that some Cost Types for some resources may be 490 more advantageous as Cost Calendars and it makes few sense to get 491 them as a single value. For example, Cost Types with predictable and 492 frequently changing values, calendared in short time intervals such 493 as a minute. 495 4.3. Example IRD with ALTO Cost Calendars 497 This section provides an example ALTO Server IRD that supports 498 various cost metrics and cost modes. In particular, since [RFC7285] 499 makes it mandatory, the Server uses metric "routingcost" in the 500 "numerical" mode. 502 For illustrative purposes, this section introduces 3 other fictitious 503 example metrics and modes that should be understood as examples and 504 should not be used or considered as normative. 506 The cost type names used in the example IRD as thus as follows: 508 o "num-routingcost": refers to metric "routingcost" in the numerical 509 mode as defined in [RFC7285] and registered with IANA. 511 o "num-owdelay": refers to fictitious performance metric "owdelay" 512 in the "numerical" mode,to reflect the one-way packet transmission 513 delay on a path. A related performance metric is currently under 514 definition in [I-D.ietf-alto-performance-metrics]. 516 o "num-throughputrating": refers to fictitious metric 517 "throughputrating" in the "numerical" mode, to reflect the 518 provider preference in terms of end to end throughput. 520 o "string-servicestatus": refers to fictitious metric 521 "servicestatus" containing a string, to reflect the availability, 522 defined by the provider, of for instance path connectivity. 524 The example IRD includes 2 particular URIs providing Calendars: 526 o "https://custom.alto.example.com/calendar/costmap/filtered": a 527 filtered cost map in which Calendar capabilities are indicated for 528 cost type names: "num-routingcost", "num-throughputrating" and 529 "string-servicestatus", 531 o "https://custom.alto.example.com/calendar/endpointcost/lookup": an 532 endpoint cost map in which Calendar capabilities are indicated for 533 cost type names: "num-routingcost", "num-owdelay", "num- 534 throughputrating", "string-servicestatus". 536 The design of the Calendar capabilities allows some Calendars with 537 the same cost type name to be available in several information 538 resources with different Calendar Attributes. This is the case for 539 Calendars on "num-routingcost", "num-throughputrating" and "string- 540 servicestatus", available in both the Filtered Cost map and Endpoint 541 Cost Service, but with different time interval sizes for "num- 542 throughputrating" and "string-servicestatus". 544 --- Client to Server request for IRD ---------- 546 GET /calendars-directory HTTP/1.1 547 Host: custom.alto.example.com 548 Accept: application/alto-directory+json,application/alto-error+json 550 --- Server response to Client ----------------- 552 HTTP/1.1 200 OK 553 Content-Length: 2542 554 Content-Type: application/alto-directory+json 556 { 557 "meta" : { 558 "default-alto-network-map" : "my-default-network-map", 559 "cost-types": { 560 "num-routingcost": { 561 "cost-mode" : "numerical", 562 "cost-metric" : "routingcost" 563 }, 564 "num-owdelay": { 565 "cost-mode" : "numerical", 566 "cost-metric": "owdelay" 567 }, 568 "num-throughputrating": { 569 "cost-mode" : "numerical", 570 "cost-metric": "throughputrating" 571 }, 572 "string-servicestatus": { 573 "cost-mode" : "string", 574 "cost-metric": "servicestatus" 575 } 576 } 577 }, 578 "resources" : { 579 "filtered-cost-map-calendar" : { 580 "uri" : 581 "https://custom.alto.example.com/calendar/costmap/filtered", 582 "media-type" : "application/alto-costmap+json", 583 "accepts" : "application/alto-costmapfilter+json", 584 "capabilities" : { 585 "cost-constraints" : true, 586 "cost-type-names" : [ "num-routingcost", 587 "num-throughputrating", 588 "string-servicestatus" ], 589 "calendar-attributes" : [ 590 {"cost-type-names" : [ "num-routingcost", 591 "num-throughputrating" ], 592 "time-interval-size" : 7200, 593 "number-of-intervals" : 12 594 }, 595 {"cost-type-names" : [ "string-servicestatus" ], 596 "time-interval-size" : 1800, 597 "number-of-intervals" : 48 598 } 599 ] 600 }, 601 "uses": [ "my-default-network-map" ] 602 }, 603 "endpoint-cost-calendar-map" : { 604 "uri" : 605 "https://custom.alto.example.com/calendar/endpointcost/lookup", 606 "media-type" : "application/alto-endpointcost+json", 607 "accepts" : "application/alto-endpointcostparams+json", 608 "capabilities" : { 609 "cost-constraints" : true, 610 "cost-type-names" : [ "num-routingcost", 611 "num-owdelay", 612 "num-throughputrating", 613 "string-servicestatus" ], 614 "calendar-attributes" : [ 615 {"cost-type-names" : [ "num-routingcost" ], 616 "time-interval-size" : 3600, 617 "number-of-intervals" : 24 618 }, 619 {"cost-type-names" : [ "num-owdelay" ], 620 "time-interval-size" : 300, 621 "number-of-intervals" : 12 622 }, 623 {"cost-type-names" : [ "num-throughputrating" ], 624 "time-interval-size" : 60, 625 "number-of-intervals" : 60 626 }, 627 {"cost-type-names" : [ "string-servicestatus" ], 628 "time-interval-size" : 120, 629 "number-of-intervals" : 30 630 } 631 ] 632 } 633 } 634 } 635 } 637 In this example IRD, for the Filtered Cost Map Service: 639 o the Calendar for "num-routingcost" and "num-throughputrating" is 640 an array of 12 values each provided on a time interval lasting 641 7200 seconds (2 hours). 643 o the Calendar for "string-servicestatus": "is an array of 48 values 644 each provided on a time interval lasting 1800 seconds (30 645 minutes). 647 For the Endpoint Cost Service: 649 o the Calendar for "num-routingcost": is an array of 24 values each 650 provided on a time interval lasting 3600 seconds (1 hour). 652 o the Calendar for "owdelay": is an array of 12 values each provided 653 on a time interval lasting 300 seconds (5 minutes). 655 o the Calendar for "num-throughputrating": is an array of 60 values 656 each provided on a time interval lasting 60 seconds (1 minute). 658 o the Calendar for "string-servicestatus": "is an array of 30 values 659 each provided on a time interval lasting 120 seconds (2 minutes). 661 5. ALTO Calendar specification: Service Information Resources 663 This section documents extensions to two basic ALTO information 664 resources (Filtered Cost Maps and Endpoint Cost Service) to provide 665 calendared information services for them. 667 Both extensions need to return calendar start time (calendar-start- 668 time, a point in time), which MUST be specified using the HTTP header 669 fields format specified in [RFC7231] where, however, timestamps are 670 still displayed with the acronym "GMT" rather than "UTC": 672 Date: Tue, 15 Nov 2014 08:12:31 GMT 674 5.1. Calendar extensions for Filtered Cost Maps (FCM) 676 A legacy ALTO Client requests and gets Filtered Cost Map responses as 677 specified in [RFC7285]. 679 5.1.1. Calendar extensions in Filtered Cost Map requests 681 The input parameters of a "legacy" request for a filtered cost map, 682 defined by object ReqFilteredCostMap in section 11.3.2 of [RFC7285], 683 are augmented with one additional member. 685 A Calendar-aware ALTO Client requesting a Calendar on a given Cost 686 Type for a filtered cost map resource having Calendar capabilities 687 MUST add the following field to its input parameters: 689 JSONBoolean calendared<1..*>; 691 This field is an array of 1 to N boolean values, where N is the 692 number of requested metrics. Each entry corresponds to the requested 693 metric at the same array position. Each boolean value indicates 694 whether or not the ALTO Server should provide the values for this 695 Cost Type as a Calendar. The array MUST contain exactly N boolean 696 values, otherwise, the Server returns an error. 698 This field MUST NOT be included if no member "calendar-attributes" is 699 specified in this information resource. 701 If a value of field 'calendared' is 'true' for a cost type name for 702 which no Calendar attributes have been specified: an ALTO Server, 703 whether it implements the extensions of this document or only 704 implements [RFC7285], MUST ignore it and return a response with a 705 single cost value as specified in [RFC7285]. 707 If this field is not present, it MUST be assumed to have only values 708 equal to 'false'. 710 A Calendar-aware ALTO Client that supports requests for only one cost 711 type at a time and wants to request a Calendar MUST provide an array 712 of 1 element: 714 "calendared" : [true]; 716 A Calendar-aware ALTO Client that supports requests for more than one 717 Cost Types at a time, as specified in [RFC8189] MUST provide an array 718 of N values set to 'true' or 'false', depending whether it wants the 719 applicable Cost Type values as a single or calendared value. 721 5.1.2. Calendar extensions in Filtered Cost Map responses 723 In a calendared ALTO Filtered Cost Map, a cost value between a source 724 and a destination is a JSON array of JSON values. An ALTO Calendar 725 values array has a number of values equal to the value of member 726 "number-of-intervals" of the Calendar attributes that are indicated 727 in the IRD. These attributes will be conveyed as metadata in the 728 Filtered Cost Map response. Each element of the array is valid for 729 the time-interval that matches its array position. 731 The FCM response conveys metadata among which: 733 o some are not specific to Calendars and ensure compatibility with 734 [RFC7285] and [RFC8189] 736 o some are specific to Calendars. 738 The non Calendar specific "meta" fields of a calendared Filtered Cost 739 Map response MUST include at least: 741 o if the ALTO Client requests cost values for one Cost Type at a 742 time only: the "meta" fields specified in [RFC7285] for these 743 information service responses: 745 * "dependent-vtags ", 747 * "cost-type" field. 749 o if the ALTO Client implements the Multi-Cost ALTO extension 750 specified in [RFC8189] and requests cost values for several Cost 751 Types at a time: the "meta" fields specified in [RFC8189] for 752 these information service responses: 754 * "dependent-vtags ", 756 * "cost-type" field with value set to '{}', for backwards 757 compatibility with [RFC7285]. 759 * "multi-cost-types" field. 761 If the client request does not provide member "calendared" or if it 762 provides it with a value equal to 'false', for all the requested Cost 763 Types, then the ALTO Server response is exactly as specified in 764 [RFC7285] and [RFC8189]. 766 If the value of member "calendared" is equal to 'false' for a given 767 requested Cost Type, the ALTO Server MUST return, for this Cost Type, 768 a single cost value as specified in [RFC7285]. 770 If the value of member "calendared" is equal to 'true' for a given 771 requested Cost Type, the ALTO Server returns, for this Cost Type, a 772 cost value Calendar as specified above in this section. In addition 773 to the above cited non Calendar specific "meta" members, the Server 774 MUST provide a Calendar specific metadata field. 776 The Calendar specific "meta" field that a calendared Filtered Cost 777 Map response MUST include is a member called "calendar-response- 778 attributes", that describes properties of the Calendar and where: 780 o member "calendar-response-attributes" is an array of one or more 781 objects of type "CalendarResponseAttributes". 783 o each "CalendarResponseAttributes" object in the array is specified 784 for one or more Cost Types for which the value of member 785 "calendared" is equal to 'true' and for which a Calendar is 786 provided for the requested information resource. 788 o the "CalendarResponseAttributes" object that applies to a cost 789 type name has a corresponding "CalendarAttributes" object defined 790 for this cost type name in the IRD capabilities of the requested 791 information resource. The members of a 792 "CalendarResponseAttributes" object include all the members of the 793 corresponding "CalendarAttributes" object. 795 The format of member "CalendarResponseAttributes is defined as 796 follows: 798 CalendarResponseAttributes calendar-response-attributes <1..*>; 799 object{ 800 [JSONString cost-type-names <1..*>]; 801 JSONString calendar-start-time; 802 JSONNumber time-interval-size; 803 JSONNumber number-of-intervals; 804 [JSONNumber repeated;] 805 } CalendarResponseAttributes; 807 Object CalendarResponseAttributes has the following attributes: 809 o "cost-type-names": is an array of one or more cost-type-names to 810 which the capabilities apply and for which a Calendar has been 811 requested. The value of this member is a subset of the "cost- 812 type-names" array specified in the corresponding IRD Calendar 813 attributes. 815 o "calendar-start-time": indicates the date at which the first value 816 of the Calendar applies. The value provided for the "calendar- 817 start-time" attribute SHOULD NOT be later than the request date. 819 o "time-interval-size": as specified in Section 4.1 and with the 820 same value. 822 o "number-of-intervals": as specified in Section 4.1 and with the 823 same value. 825 o "repeated": is an optional field provided for Calendars. It is an 826 integer N greater or equal to '1' that indicates how many 827 iterations of the Calendar value array starting at the date 828 indicated by "calendar-start-time" have the same values. The 829 number N includes the iteration provided in the returned response. 831 For example: suppose the "calendar-start-time" member has value "Mon, 832 30 Jun 2014 at 00:00:00 GMT", the "time-interval-size" member has 833 value '3600', the "number-of-intervals" member has value '24' and the 834 value of member "repeated" is equal to '4'. This means that the 835 Calendar values are the same on Monday, Tuesday, Wednesday and 836 Thursday on a period of 24 hours starting at 00:00:00 GMT. The ALTO 837 Client thus may use the same Calendar for the next 4 days starting at 838 "calendar-start-time" and will only need to request a new one for 839 Friday July 4th at 00:00:00 GMT. 841 Attribute "repeated" may take a very high value if a Calendar 842 represents a cyclic value pattern that the Server considers valid for 843 a long period and hence will only update once this period has elapsed 844 or if an unexpected event occurs on the network. In the latter case, 845 the client will be notified if it uses the "ALTO Incremental Updates 846 Using Server-Sent Events (SSE)" Service, specified in 848 [I-D.ietf-alto-incr-update-sse]. To this end, it is RECOMMENDED that 849 ALTO Servers providing ALTO Calendars also provide the "ALTO 850 Incremental Updates Using Server-Sent Events (SSE)" Service that is 851 specified in [I-D.ietf-alto-incr-update-sse]. Likewise, ALTO Clients 852 capable of using ALTO Calendars SHOULD also use the SSE Service. See 853 also discussion in Section 8 "Operational Considerations". 855 5.1.3. Use case and example: FCM with a bandwidth Calendar 857 An example of non-real time information that can be provisioned in a 858 Calendar is the expected path throughput. While the transmission 859 rate can be measured in real time by end systems, the operator of a 860 data center is in the position of formulating preferences for given 861 paths, at given time periods to avoid traffic peaks due to diurnal 862 usage patterns. In this example, we assume that an ALTO Client 863 requests a Calendar of network provider defined throughput ratings, 864 as specified in the IRD, to schedule its bulk data transfers as 865 described in the use cases. 867 In the example IRD, Calendars for cost type name "num- 868 throughputrating" are available for the information resources: 869 "filtered-cost-calendar-map" and "endpoint-cost-calendar-map". The 870 ALTO Client requests a Calendar for "num-throughputrating" via a POST 871 request for a filtered cost map. 873 We suppose in the present example that the ALTO Client sends its 874 request on Tuesday July 1st 2014 at 13:15. The Server returns 875 Calendars with arrays of 12 numbers for each source and destination 876 pair. The values for metric "throughputrating", in this example, are 877 assumed to be encoded in 2 digits. 879 POST /calendar/costmap/filtered HTTP/1.1 880 Host: alto.example.com 881 Content-Length: 208 882 Content-Type: application/alto-costmapfilter+json 883 Accept: application/alto-costmap+json,application/alto-error+json 885 { 886 "cost-type" : {"cost-mode" : "numerical", 887 "cost-metric" : "throughputrating"}, 888 "calendared" : [true], 889 "pids" : { 890 "srcs" : [ "PID1", "PID2" ], 891 "dsts" : [ "PID1", "PID2", "PID3" ] 892 } 893 } 895 HTTP/1.1 200 OK 896 Content-Length: 1013 897 Content-Type: application/alto-costmap+json 899 { 900 "meta" : { 901 "dependent-vtags" : [ 902 {"resource-id": "my-default-network-map", 903 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 904 } 905 ], 906 "cost-type" : {"cost-mode" : "numerical", 907 "cost-metric" : "throughputrating"}, 908 "calendar-response-attributes" : [ 909 {"calendar-start-time" : "Tue, 1 Jul 2014 13:00:00 GMT", 910 "time-interval-size" : 7200, 911 "number-of-intervals" : 12} 912 ] 913 }, 914 "cost-map" : { 915 "PID1": { "PID1": [ 1, 12, 14, 18, 14, 14, 916 14, 18, 19, 20, 11, 12], 917 "PID2": [13, 4, 15, 16, 17, 18, 918 19, 20, 11, 12, 13, 14], 919 "PID3": [20, 20, 18, 14, 12, 12, 920 14, 14, 12, 12, 14, 16] }, 921 "PID2": { "PID1": [17, 18, 19, 10, 11, 12, 922 13, 14, 15, 16, 17, 18], 923 "PID2": [20, 20, 18, 16, 14, 14, 924 14, 16, 16, 16, 14, 16], 925 "PID3": [20, 20, 18, 14, 12, 12, 926 14, 14, 12, 12, 14, 16] } 927 } 928 } 930 5.2. Calendar extensions in the Endpoint Cost Service 932 This document extends the Endpoint Cost Service, as defined in 933 {11.5.1} of [RFC7285], by adding new input parameters and 934 capabilities, and by returning JSONArrays instead of JSONNumbers as 935 the cost values. The media type {11.5.1.1} and HTTP method 936 {11.5.1.2} are unchanged. 938 5.2.1. Calendar specific input in Endpoint Cost requests 940 The extensions to the requests for calendared Endpoint Cost Maps are 941 the same as for the Filtered Cost Map Service, specified in section 942 Section 5.1.1 of this draft. 944 The ReqEndpointCostMap object for a calendared ECM request will have 945 the following format: 947 object { 948 [CostType cost-type;] 949 [CostType multi-cost-types<1..*>;] 950 [JSONBoolean calendared<1..*>;] 951 EndpointFilter endpoints; 952 } ReqEndpointCostMap; 954 object { 955 [TypedEndpointAddr srcs<0..*>;] 956 [TypedEndpointAddr dsts<0..*>;] 957 } EndpointFilter; 959 5.2.2. Calendar attributes in the Endpoint Cost response 961 The "meta" field of a calendared Endpoint Cost response MUST include 962 at least: 964 o if the ALTO Client supports cost values for one Cost Type at a 965 time only: the "meta" fields specified in {11.5.1.6} of [RFC7285] 966 for the Endpoint Cost response: 968 * "cost-type" field. 970 o if the ALTO Client supports cost values for several Cost Types at 971 a time, as specified in [RFC8189] : the "meta" fields specified in 972 [RFC8189] for the the Endpoint Cost response: 974 * "cost-type" field with value set to '{}', for backwards 975 compatibility with [RFC7285]. 977 * "multi-cost-types" field. 979 If the client request does not provide member "calendared" or if it 980 provides it with a value equal to 'false', for all the requested Cost 981 Types, then the ALTO Server response is exactly as specified in 982 [RFC7285] and [RFC8189]. 984 If the ALTO Client provides member "calendared" in the input 985 parameters with a value equal to 'true' for given requested Cost 986 Types, the "meta" member of a calendared Endpoint Cost response MUST 987 include, for these Cost Types, an additional member "calendar- 988 response-attributes", the contents of which obey the same rules as 989 for the Filtered Cost Map Service, specified in Section 5.1.2. The 990 Server response is thus changed as follows, w.r.t [RFC7285] and 991 [RFC8189]: 993 o the "meta" member has one additional field 994 "CalendarResponseAttributes", as specified for the Filtered Cost 995 Map Service, 997 o the calendared costs are JSONArrays instead of the JSONNumbers 998 format used by legacy ALTO implementations. All arrays have a 999 number of values equal to 'number-of-intervals'. 1001 If the value of member "calendared" is equal to 'false' for a given 1002 requested Cost Type, the ALTO Server MUST return, for this Cost Type, 1003 a single cost value as specified in [RFC7285]. 1005 5.2.3. Use case and example: ECS with a routingcost Calendar 1007 Let us assume an Application Client is located in an end system with 1008 limited resources and having access to the network that is either 1009 intermittent or provides an acceptable quality in limited but 1010 predictable time periods. Therefore, it needs to both schedule its 1011 resource-greedy networking activities and its ALTO transactions. 1013 The Application Client has the choice to trade content or resources 1014 with a set of Endpoints and needs to decide with which one it will 1015 connect and at what time. For instance, the Endpoints are spread in 1016 different time-zones, or have intermittent access. In this example, 1017 the 'routingcost' is assumed to be time-varying, with values provided 1018 as ALTO Calendars. 1020 The ALTO Client associated with the Application Client queries an 1021 ALTO Calendar on 'routingcost' and will get the Calendar covering the 1022 24 hours time period "containing" the date and time of the ALTO 1023 client request. 1025 For Cost Type "num-routingcost", the solicited ALTO Server has 1026 defined 3 different daily patterns each represented by a Calendar, to 1027 cover the week of Monday June 30th at 00:00 to Sunday July 6th 23:59: 1029 o C1 for Monday, Tuesday, Wednesday, Thursday, (weekdays) 1031 o C2 for Saturday, Sunday, (weekend) 1033 - C3 for Friday (maintenance outage on July 4, 2014 from 02:00:00 GMT 1034 to 04:00:00 GMT, or big holiday such as New Year evening). 1036 In the following example, the ALTO Client sends its request on 1037 Tuesday July 1st 2014 at 13:15. 1039 The "routingcost" values are assumed to be encoded in 3 digits. 1041 POST /calendar/endpointcost/lookup HTTP/1.1 1042 Host: alto.example.com 1043 Content-Length: 290 1044 Content-Type: application/alto-endpointcostparams+json 1045 Accept: application/alto-endpointcost+json,application/alto-error+json 1047 { 1048 "cost-type" : {"cost-mode" : "numerical", 1049 "cost-metric" : "routingcost"}, 1050 "calendared" : [true], 1051 "endpoints" : { 1052 "srcs": [ "ipv4:192.0.2.2" ], 1053 "dsts": [ 1054 "ipv4:192.0.2.89", 1055 "ipv4:198.51.100.34", 1056 "ipv4:203.0.113.45", 1057 "ipv6:2001:db8::10" 1058 ] 1059 } 1060 } 1062 HTTP/1.1 200 OK 1064 Content-Length: 1318 1065 Content-Type: application/alto-endpointcost+json 1067 { 1068 "meta" : { 1069 "cost-type" : {"cost-mode" : "numerical", 1070 "cost-metric" : "routingcost"}, 1071 "calendar-response-attributes" : [ 1072 {"calendar-start-time" : "Mon, 30 Jun 2014 00:00:00 GMT", 1073 "time-interval-size" : 3600, 1074 "number-of-intervals" : 24, 1075 "repeated": 4 1076 } 1077 ] 1078 }, 1079 "endpoint-cost-map" : { 1080 "ipv4:192.0.2.2": { 1081 "ipv4:192.0.2.89" : [100, 100, 100, 100, 100, 150, 1082 200, 300, 300, 300, 300, 250, 1083 250, 300, 300, 300, 300, 300, 1084 400, 250, 250, 200, 150, 150], 1085 "ipv4:198.51.100.34" : [ 80, 80, 80, 80, 150, 150, 1086 250, 400, 400, 450, 400, 200, 1087 200, 350, 400, 400, 400, 350, 1088 500, 200, 200, 200, 100, 100], 1090 "ipv4:203.0.113.45" : [300, 400, 250, 250, 200, 150, 1091 150, 100, 100, 100, 100, 100, 1092 100, 100, 100, 100, 100, 150, 1093 200, 300, 300, 300, 300, 250], 1094 "ipv6:2001:db8::10" : [200, 250, 300, 300, 300, 300, 1095 250, 300, 300, 300, 300, 350, 1096 300, 400, 250, 150, 100, 100, 1097 100, 150, 200, 250, 250, 300] 1098 } 1099 } 1100 } 1102 When the Client gets the Calendar for "routingcost", it sees that the 1103 "calendar-start-time" is Monday at 00h00 GMT and member "repeated" is 1104 equal to '4'. It understands that the provided values are valid 1105 until Thursday included and will only need to get a Calendar update 1106 on Friday. 1108 5.2.4. Use case and example: ECS with a multi-cost Calendar for 1109 routingcost and owdelay 1111 In this example, it is assumed that the ALTO Server implements multi- 1112 cost capabilities, as specified in [RFC8189] . That is, an ALTO 1113 Client can request and receive values for several cost types in one 1114 single transaction. An illustrating use case is a path selection 1115 done on the basis of 2 metrics: routing cost and owdelay. 1117 As in the previous example, the IRD indicates that the ALTO Server 1118 provides "routingcost" Calendars in terms of 24 time intervals of 1 1119 hour (3600 seconds) each. 1121 For metric "owdelay", the IRD indicates that the ALTO Server provides 1122 Calendars in terms of 12 time intervals values lasting each 5 minutes 1123 (300 seconds). 1125 In the following example transaction, the ALTO Client sends its 1126 request on Tuesday July 1st 2014 at 13:15. 1128 This example assumes that the values of metric "owdelay" and 1129 "routingcost" are encoded in 3 digits. 1131 POST calendar/endpointcost/lookup HTTP/1.1 1132 Host: alto.example.com 1133 Content-Length: 373 1134 Content-Type: application/alto-endpointcostparams+json 1135 Accept: application/alto-endpointcost+json,application/alto-error+json 1137 { 1138 "cost-type" : {}, 1139 "multi-cost-types" : [ 1140 {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, 1141 {"cost-mode" : "numerical", "cost-metric" : "owdelay"} 1142 ], 1143 "calendared" : [true, true], 1144 "endpoints" : { 1145 "srcs": [ "ipv4:192.0.2.2" ], 1146 "dsts": [ 1147 "ipv4:192.0.2.89", 1148 "ipv4:198.51.100.34", 1149 "ipv4:203.0.113.45", 1150 "ipv6:2001:db8::10" 1151 ] 1152 } 1153 } 1155 HTTP/1.1 200 OK 1156 Content-Length: 2111 1157 Content-Type: application/alto-endpointcost+json 1159 { 1160 "meta" : { 1161 "multi-cost-types" : [ 1162 {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, 1163 {"cost-mode" : "numerical", "cost-metric" : "owdelay"} 1164 ], 1165 "calendar-response-attributes" : [ 1166 {"cost-type-names" : "num-routingcost", 1167 "calendar-start-time" : "Mon, 30 Jun 2014 00:00:00 GMT", 1168 "time-interval-size" : 3600, 1169 "number-of-intervals" : 24, 1170 "repeated": 4 }, 1171 {"cost-type-names" : "num-owdelay", 1172 "calendar-start-time" : "Tue, 1 Jul 2014 13:00:00 GMT", 1173 "time-interval-size" : 300, 1174 "number-of-intervals" : 12} 1175 ] 1176 }, 1177 "endpoint-cost-map" : { 1178 "ipv4:192.0.2.2": { 1179 "ipv4:192.0.2.89" : [[100, 100, 100, 100, 100, 150, 1180 200, 300, 300, 300, 300, 250, 1181 250, 300, 300, 300, 300, 300, 1182 400, 250, 250, 200, 150, 150], 1183 [ 20, 400, 20, 80, 80, 90, 1184 100, 90, 60, 40, 30, 20]], 1185 "ipv4:198.51.100.34" : [[ 80, 80, 80, 80, 150, 150, 1186 250, 400, 400, 450, 400, 200, 1187 200, 350, 400, 400, 400, 350, 1188 500, 200, 200, 200, 100, 100], 1189 [ 20, 20, 50, 30, 30, 30, 1190 30, 40, 40, 30, 20, 20]], 1191 "ipv4:203.0.113.45" : [[300, 400, 250, 250, 200, 150, 1192 150, 100, 100, 100, 100, 100, 1193 100, 100, 100, 100, 100, 150, 1194 200, 300, 300, 300, 300, 250], 1195 [100, 90, 80, 60, 50, 50, 1196 40, 40, 60, 90, 100, 80]], 1197 "ipv6:2001:db8::10" : [[200, 250, 300, 300, 300, 300, 1198 250, 300, 300, 300, 300, 350, 1199 300, 400, 250, 150, 100, 100, 1200 100, 150, 200, 250, 250, 300], 1201 [ 40, 40, 40, 40, 50, 50, 1202 50, 20, 10, 15, 30, 40]] 1203 } 1204 } 1205 } 1207 When receiving the response, the client sees that the Calendar values 1208 for metric "routingcost" are repeated for 4 iterations. Therefore, 1209 in its next requests until the "routingcost" Calendar is expected to 1210 change, the client will only need to request a Calendar for 1211 "owdelay". 1213 Without the ALTO Calendar extensions, the ALTO Client would have no 1214 clue on the dynamicity of the metric value change and would spend 1215 needless time requesting values at an inappropriate pace. In 1216 addition, without the Multi-Cost ALTO capabilities, the ALTO Client 1217 would duplicate this waste of time as it would need to send one 1218 request per cost metric. 1220 6. IANA Considerations 1222 This document does not define any new media types or introduce any 1223 new IANA considerations. 1225 7. Security Considerations 1227 As an extension of the base ALTO protocol [RFC7285], this document 1228 fits into the architecture of the base protocol, and hence the 1229 Security Considerations (Section 15) of the base protocol fully apply 1230 when this extension is provided by an ALTO Server. For example, the 1231 same authenticity and integrity considerations (Section 15.1 of 1232 [RFC7285] still fully apply; the same considerations for the privacy 1233 of ALTO users (Section 15.4 of [RFC7285]) also still fully apply. 1235 The calendaring information provided by this extension requires 1236 additional considerations on three security considerations discussed 1237 in the base protocol: potential undesirable guidance to clients 1238 (Section 15.2 of [RFC7285]), confidentiality of ALTO information 1239 (Section 15.2 of [RFC7285]), and availability of ALTO (Section 15.5 1240 of [RFC7285]). For example, by providing network information in the 1241 future in a Calendar, this extension may improve availability of 1242 ALTO, when the ALTO Server is unavailable but related information is 1243 already provided in the Calendar. 1245 For confidentiality of ALTO information, an operator should be 1246 cognizant that this extension may introduce a new risk: an ALTO 1247 Client may get information for future events that are scheduled 1248 through Calendaring. Possessing such information, the client may use 1249 it to achieve its goal: (1) initiating connections only at 1250 advantageous network costs, leading to unexpected network load; (2) 1251 generating massive connections to the network at times where its load 1252 is expected to be high. 1254 To mitigate this risk, the operator should address the risk of ALTO 1255 information being leaked to malicious clients or third parties. As 1256 specified in Section 15.3.2 ("Protection Strategies") of [RFC7285], 1257 the ALTO Server should authenticate ALTO Clients and use the 1258 Transport Layer Security (TLS) protocol so that Man In The Middle 1259 (MITM) attacks to intercept an ALTO Calendar are not possible. 1260 [RFC7285] ensures the availability of such a solution in its 1261 Section 8.3.5. "Authentication and Encryption", which specifies 1262 that: "ALTO Server implementations as well as ALTO Client 1263 implementations MUST support the "https" URI scheme of [RFC2818] and 1264 Transport Layer Security (TLS) of [RFC5246]". 1266 [RFC8446] specifies TLS 1.3 and writes in its section 1: "While TLS 1267 1.3 is not directly compatible with previous versions, all versions 1268 of TLS incorporate a versioning mechanism which allows clients and 1269 servers to interoperably negotiate a common version if one is 1270 supported by both peers". So ALTO Clients and servers MAY use newer 1271 versions (e.g., 1.3) of TLS as long as the negotiation process 1272 succeeds. To ensure backward compatibility with [RFC7285], it is 1273 RECOMMENDED for both Calendar-aware Clients and Servers to both 1274 support at least TLS 1.2, until it gets deprecated. 1276 To avoid malicious or erroneous guidance from ALTO information, an 1277 ALTO Client should be cognizant that using calendaring information 1278 can have risks: (1) Calendar values, especially in "repeated" 1279 Calendars may be only statistical, and (2) future events may change. 1280 Hence, a more robust ALTO Client should adapt and extend protection 1281 strategies specified in Section 15.2 of the base protocol. For 1282 example, to be notified immediately when a particular ALTO value that 1283 the client depends on changes, it is RECOMMENDED that both the ALTO 1284 Client and ALTO Server using this extension support "ALTO Incremental 1285 Updates Using Server-Sent Events(SSE)" Service 1286 [I-D.ietf-alto-incr-update-sse]. 1288 8. Operational Considerations 1290 It is important that both the operator of the network and the 1291 operator of the applications consider both the feedback aspect and 1292 the prediction-based (uncertainty) aspect of using the cost calendar. 1294 First consider the feedback aspect and consider the cost calendar as 1295 a traffic-aware map service (e.g., Google map). Using the service 1296 without considering its own effect, a large fleet can turn a not- 1297 congested road into a congested one; a large number of individual 1298 cars each choosing a road with light traffic ("cheap link") can also 1299 result in congestion or result in a less optimal global outcome 1300 (e.g., the 's Paradox [Braess-paradox]). 1302 Next consider the prediction aspect. Conveying ALTO Cost Calendars 1303 tends to reduce the on-the-wire data exchange volume compared to 1304 multiple single cost ALTO transactions. An application using 1305 Calendars has a set of time-dependent values upon which it can plan 1306 its connections in advance with no need for the ALTO Client to query 1307 information at each time. Additionally, the Calendar response 1308 attribute "repeated", when provided, saves additional data exchanges 1309 in that it indicates that the ALTO Client does not need to query 1310 Calendars during a period indicated by this attribute. The preceding 1311 is true only when "accidents" do not happen. 1313 Although individual network operators and application operators can 1314 choose their own approaches to address the aforementioned issues, 1315 this document recommends the following considerations. First, a 1316 typical approach to reducing instability and handling uncertainty is 1317 to ensure timely update of information. The SSE Service as discussed 1318 in Section 7 can handle updates, if supported by both the Server and 1319 the Client. Second, Although there are theoretical analysis 1320 [Selfish-routing-Roughgarden-thesis] and Internet based evaluations 1321 [Selfish-routing-Internet-eval] showing that uncoordinated behaviors 1322 may not result in substantial sub-optimal results, when a network 1323 operator updates the cost calendar, and when an application reacts to 1324 the update, they should still consider the potential feedback 1325 effects. 1327 High-resolution intervals may be needed when values change, sometimes 1328 during very small time intervals but in a significant manner. A way 1329 to avoid conveying too many entries is to leverage on the "repeated" 1330 feature. A server can smartly set the Calendar start time and number 1331 of intervals so as to declare them "repeated" for a large number of 1332 periods, until the Calendar values change and are conveyed to 1333 requesting Clients. 1335 Clients and Servers supporting ALTO Calendars use [RFC8259]. 1336 [RFC7285] encodes its requests and responses using the JSON Data 1337 Interchange Format specified in [RFC7159]. In the meantime, 1338 [RFC7159] has been obsoleted by [RFC8259], that among others makes 1339 UTF-8 mandatory for text encoding to improve interoperability. 1340 Therefore, ALTO Clients and Servers implementations using UTF-{16,32} 1341 need to be cognizant of the subsequent interoperability risks and 1342 MUST switch to UTF-8 encoding, if they want to interoperate with 1343 Calendar-aware Servers and Clients. 1345 9. Acknowledgements 1347 The authors would like to thank Fred Baker, Li Geng, Diego Lopez, He 1348 Peng and Haibin Song for fruitful discussions and feedback on earlier 1349 draft versions. Dawn Chan, Kai Gao, Vijay Gurbani, Yichen Qian and 1350 Jensen Zhang provided substantial review feedback and suggestions to 1351 the protocol design. 1353 10. References 1355 10.1. Normative References 1357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1358 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1359 RFC2119, March 1997, . 1362 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1363 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 1364 10.17487/RFC7231, June 2014, . 1367 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1368 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1369 "Application-Layer Traffic Optimization (ALTO) Protocol", 1370 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1371 . 1373 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1374 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1375 May 2017, . 1377 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1378 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1379 DOI 10.17487/RFC8189, October 2017, . 1382 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1383 Interchange Format", STD 90, RFC 8259, DOI 10.17487/ 1384 RFC8259, December 2017, . 1387 10.2. Informative References 1389 [IEEE.754.2008] 1390 Institute of Electrical and Electronics Engineers, , 1391 "Standard for Binary Floating-Point Arithmetic, IEEE 1392 Standard 754", August 2008. 1394 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 1395 RFC2818, May 2000, . 1398 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1399 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1400 RFC5246, August 2008, . 1403 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1404 Optimization (ALTO) Problem Statement", RFC 5693, DOI 1405 10.17487/RFC5693, October 2009, . 1408 [RFC6708] Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R., 1409 and Y. Yang, "Application-Layer Traffic Optimization 1410 (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708, 1411 September 2012, . 1413 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1414 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1415 2014, . 1417 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1418 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1419 . 1421 [I-D.ietf-alto-incr-update-sse] 1422 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1423 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 1424 sse-20 (work in progress), February 2020. 1426 [I-D.ietf-alto-performance-metrics] 1427 WU, Q., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, 1428 "ALTO Performance Cost Metrics", draft-ietf-alto- 1429 performance-metrics-08 (work in progress), November 2019. 1431 [I-D.xiang-alto-multidomain-analytics] 1432 Xiang, Q., Le, F., Yang, Y., Newman, H., and H. Du, 1433 "Unicorn: Resource Orchestration for Multi-Domain, Geo- 1434 Distributed Data Analytics", draft-xiang-alto-multidomain- 1435 analytics-02 (work in progress), July 2018. 1437 [SENSE-sdn-e2e-net] 1438 project supported by the Department of Energy Office of 1439 Science Advanced Scientific Computing Research (ASCR) 1440 Program, , "SDN for End-to-End Networked Science at the 1441 Exascale (SENSE), http://sense.es.net/overview". 1443 [Braess-paradox] 1444 Steinberg, R. and W. Zangwill, "The Prevalence of Braess' 1445 Paradox", Transportation Science Vol. 17 No. 3, August 1446 1983. 1448 [Selfish-routing-Roughgarden-thesis] 1449 Roughgarden, T., "Selfish Routing", Dissertation Thesis, 1450 Cornell 2002, May 2002. 1452 [Selfish-routing-Internet-eval] 1453 Qiu, L., Yang, Y., Zhang, Y., and S. Shenker, "Selfish 1454 Routing in Internet-LIke Environments", Proceedings of ACM 1455 SIGCOMM 2001, August 2001. 1457 Authors' Addresses 1459 Sabine Randriamasy 1460 Nokia Bell Labs 1461 Route de Villejust 1462 NOZAY 91460 1463 FRANCE 1465 Email: Sabine.Randriamasy@nokia-bell-labs.com 1466 Richard Yang 1467 Yale University 1468 51 Prospect st 1469 New Haven, CT 06520 1470 USA 1472 Email: yry@cs.yale.edu 1474 Qin Wu 1475 Huawei 1476 101 Software Avenue, Yuhua District 1477 Nanjing, Jiangsu 210012 1478 China 1480 Email: sunseawq@huawei.com 1482 Lingli Deng 1483 China Mobile 1484 China 1486 Email: denglingli@chinamobile.com 1488 Nico Schwan 1489 Thales Deutschland 1490 Lorenzstrasse 10 1491 Stuttgart 70435 1492 Germany 1494 Email: nico.schwan@thalesgroup.com