idnits 2.17.1 draft-ietf-alto-cost-calendar-18.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 28, 2020) is 1518 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) ** 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 (~~), 4 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 31, 2020 Yale University 6 Q. Wu 7 Huawei 8 L. Deng 9 China Mobile 10 N. Schwan 11 Thales Deutschland 12 February 28, 2020 14 Application-Layer Traffic Optimization (ALTO) Cost Calendar 15 draft-ietf-alto-cost-calendar-18 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 https://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 31, 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 (https://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 . . . . . . . . . . . . . . . 10 77 4.3. Example IRD with ALTO Cost Calendars . . . . . . . . . . 11 78 5. ALTO Calendar specification: Service Information Resources . 14 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 - those that only support [RFC7285]. 161 In the rest of this document, Section 3 provides the design 162 characteristics. Sections Section 4 and Section 5 define the formal 163 specifications for the IRD and the information resources. IANA, 164 security and operational considerations are addressed respectively in 165 sections 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 In the base protocol [RFC7285] section 11.2.3.6, an ALTO cost is 297 specified as a generic JSONValue [RFC8259], to allow extensions. 298 However, that section 11.2.3.6 states: "An implementation of the 299 protocol in this document ([RFC7285]) SHOULD assume that the cost is 300 a JSONNumber and fail to parse if it is not, unless the 301 implementation is using an extension to this document that indicates 302 when and how costs of other data types are signaled". 304 The present document extends the definition of a legacy cost map 305 given in [RFC7285] to allow a cost entry to be an array of values, 306 with one value one per time interval, instead of being just one 307 number. Therefore the implementor of this extension MUST consider 308 that a cost entry is an array of values. 310 To realize an ALTO Calendar, this document extends: the IRD and the 311 ALTO requests and responses for Cost Calendars. 313 This extension is designed to be lightweight and to ensure backwards 314 compatibility with base protocol ALTO Clients and with other 315 extensions. It relies on section 8.3.7 "Parsing of Unknown Fields" 316 of [RFC7285] that writes: "Extensions may include additional fields 317 within JSON objects defined in this document. ALTO implementations 318 MUST ignore unknown fields when processing ALTO messages." 320 The Calendar-specific capabilities are integrated in the information 321 resources of the IRD and in the "meta" member of ALTO responses to 322 Cost Calendars requests. A Calendar and its capabilities are 323 associated with a given information resource and within this 324 information resource with a given cost type. This design has several 325 advantages: 327 o it does not introduce a new mode, 329 o it does not introduce new media types, 331 o it allows an ALTO Server to offer Calendar capabilities on a cost 332 type, with attributes values adapted to each information resource. 334 The applicable Calendared information resources are: 336 o the Filtered Cost Map, 338 o the Endpoint Cost Map. 340 The ALTO Server can choose in which frequency it provides cost 341 Calendars to ALTO Clients. It may either provide Calendar updates 342 starting at the request date, or carefully schedule its updates so as 343 to take profit from a potential repetition/periodicity of Calendar 344 values. 346 3.3.1. ALTO Cost Calendar for all cost modes 348 An ALTO Cost Calendar is well-suited for values encoded in the 349 "numerical" mode. Actually, a Calendar can also represent metrics in 350 other modes considered as compatible with time-varying values. For 351 example, types of Cost values such as JSONBool can also be 352 calendared, as their value may be 'true' or 'false' depending on 353 given time periods or likewise, values represented by strings, such 354 as "medium", "high", "low", "blue", "open". 356 Note also that a Calendar is suitable as well for time-varying 357 metrics provided in the "ordinal" mode, if these values are time- 358 varying and the ALTO Server provides updates of cost value based 359 preferences. 361 3.3.2. Compatibility with legacy ALTO Clients 363 The ALTO protocol extensions for Cost Calendars have been defined so 364 as to ensure that Calendar capable ALTO Servers can provide legacy 365 ALTO Clients with legacy information resources as well. That is, a 366 legacy ALTO Client can request resources and receive responses as 367 specified in [RFC7285]. 369 A Calendar-aware ALTO Server MUST implement the base protocol 370 specified in [RFC7285]. 372 As a consequence, when a metric is available as a Calendar array, it 373 also MUST be available as a single value as required by [RFC7285]. 374 The Server, in this case, provides the current value of the metric to 375 either Calendar-aware Clients not interested in future or time-based 376 values, or Clients implementing [RFC7285] only. 378 For compatibility with legacy ALTO Clients specified in [RFC7285], 379 calendared information resources are not applicable for full cost 380 maps for the following reason: a legacy ALTO Client would receive a 381 calendared cost map via an HTTP 'GET' command. As specified in 382 section 8.3.7 of [RFC7285], it will ignore the Calendar Attributes 383 indicated in the "meta" of the responses. Therefore, lacking 384 information on Calendar attributes, it will not be able to correctly 385 interpret and process the values of the received array of Calendar 386 cost values. 388 Therefore, calendared information resources MUST be requested via the 389 Filtered Cost Map Service or the Endpoint Cost Service, using a POST 390 method. 392 4. ALTO Calendar specification: IRD extensions 394 The Calendar attributes in the IRD information resources capabilities 395 carry constant dateless values. A Calendar is associated with an 396 information resource rather than a cost type. For example, a Server 397 can provide a "routingcost" Calendar for the Filtered Cost Map 398 Service at a granularity of one day and a "routingcost" Calendar for 399 the Endpoint Cost Service at a finer granularity but for a limited 400 number of endpoints. An example IRD with Calendar specific features 401 is provided in Section 4.3. 403 4.1. Calendar attributes in the IRD resource capabilities 405 A Cost Calendar for a given cost type MUST be indicated in the IRD by 406 an object of type CalendarAttributes. A CalendarAttributes object is 407 represented by the "calendar-attributes" member of a resource entry. 408 Each CalendarAttributes object applies to a set of one or more cost 409 types. A cost type name MUST NOT appear more than once in the 410 "calendar-attributes" member of a resource entry; multiple 411 appearances of a cost type name in the CalendarAttributes object of 412 the "calendar-attributes" member MUST cause the ALTO Client to ignore 413 any occurrences of this name beyond the first encountered occurrence. 415 An ALTO Server SHOULD specify the "time-interval-size" in the IRD as 416 the smallest it is able to provide. A Client that needs a longer 417 interval can aggregate multiple cost values to obtain it. 419 The encoding format for object CalendarAttributes, using JSON 420 [RFC8259], is as follows: 422 CalendarAttributes calendar-attributes <1..*>; 424 object{ 425 JSONString cost-type-names <1..*>; 426 JSONNumber time-interval-size; 427 JSONNumber number-of-intervals; 428 } CalendarAttributes; 429 o "cost-type-names": 431 * An array of one or more elements indicating the cost-type-names 432 in the IRD entry to which the capabilities apply. 434 o "time-interval-size": 436 * is the duration of an ALTO Calendar time interval in a unit of 437 seconds. A "time-interval-size" value contains a non-negative 438 JSONNumber. Example values are: 300 and 7200, meaning that 439 each Calendar value applies on a time interval that lasts 5 440 minutes and 2 hours, respectively. Since an interval size 441 (e.g., 100 ms) can be smaller than the unit, the value 442 specified may be a floating point (e.g., 0.1). Both ALTO 443 clients and servers should be aware of potential precision 444 issues caused by using floating point numbers; for example, the 445 floating number 0.1 cannot be represented precisely using a 446 finite number of binary bits. To improve interoperability and 447 be consistent with [RFC7285] on the use of float point numbers, 448 the server and the client SHOULD use IEEE 754 double-precision 449 floating point [IEEE.754.2008] to store this value. 451 o "number-of-intervals": 453 * is a strictly positive integer (greater or equal to 1), that 454 indicates the number of values of the Cost Calendar array. 456 - Providing attribute "cost-type-names" together with "time-interval- 457 size" and "number-of-intervals" improves the readability of the 458 Calendar attributes specified for an IRD resource and avoids 459 confusion with Calendar attributes of other cost types. 461 - Multiplying 'time-interval-size' by 'number-of-intervals' provides 462 the duration of the provided Calendar. For example, an ALTO Server 463 may provide a Calendar for ALTO values changing every 'time-interval- 464 size' equal to 5 minutes. If 'number-of-intervals' has the value 12, 465 then the duration of the provided Calendar is "1 hour". 467 4.2. Calendars in a delegate IRD 469 It may be useful to distinguish IRD resources supported by the base 470 ALTO protocol from resources supported by its extensions. To achieve 471 this, one option, is that a "root" ALTO Server implementing base 472 protocol resources and running at a given domain, delegates 473 "specialized" information resources such as the ones providing Cost 474 Calendars, to another ALTO Server running in a subdomain. The "root" 475 ALTO Server can provide a Calendar-specific resource entry where it 476 specifies the URI allowing to retrieve the location of a Calendar- 477 aware Server and relevant resources. This option is described in 478 Section 9.2.4 "Delegation using IRDs" of [RFC7285]. 480 This document provides an example, where a "root" ALTO Server runs in 481 a domain called "alto.example.com". It delegates the announcement of 482 Calendars capabilities to an ALTO Server running in a subdomain 483 called "custom.alto.example.com". The location of the "delegate 484 Calendar IRD" is assumed to be indicated in the "root" IRD by the 485 resource entry: "custom-calendared-resources". 487 Another benefit of delegation is that some cost types for some 488 resources may be more advantageous as Cost Calendars and it makes few 489 sense to get them as a single value. For example, if a cost type has 490 predictable and frequently changing values, calendared in short time 491 intervals such as a minute, it saves time and network resources to 492 track the cost values via a focused delegate Server rather than the 493 more general "root" Server. 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 are 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 623 }, 624 {"cost-type-names" : [ "num-throughputrating" ], 625 "time-interval-size" : 60, 626 "number-of-intervals" : 60 627 }, 628 {"cost-type-names" : [ "string-servicestatus" ], 629 "time-interval-size" : 120, 630 "number-of-intervals" : 30 631 } 632 ] 633 } 634 } 635 } 636 } 638 In this example IRD, for the Filtered Cost Map Service: 640 o the Calendar for "num-routingcost" and "num-throughputrating" is 641 an array of 12 values each provided on a time interval lasting 642 7200 seconds (2 hours). 644 o the Calendar for "string-servicestatus": "is an array of 48 values 645 each provided on a time interval lasting 1800 seconds (30 646 minutes). 648 For the Endpoint Cost Service: 650 o the Calendar for "num-routingcost": is an array of 24 values each 651 provided on a time interval lasting 3600 seconds (1 hour). 653 o the Calendar for "owdelay": is an array of 12 values each provided 654 on a time interval lasting 300 seconds (5 minutes). 656 o the Calendar for "num-throughputrating": is an array of 60 values 657 each provided on a time interval lasting 60 seconds (1 minute). 659 o the Calendar for "string-servicestatus": "is an array of 30 values 660 each provided on a time interval lasting 120 seconds (2 minutes). 662 5. ALTO Calendar specification: Service Information Resources 664 This section documents extensions to two basic ALTO information 665 resources (Filtered Cost Maps and Endpoint Cost Service) to provide 666 calendared information services for them. 668 Both extensions return calendar start time (calendar-start-time, a 669 point in time), which MUST be specified as an HTTP "Date" header 670 field using the IMF-fixdate format specified in Section 7.1.1.1 of 672 [RFC7231]. Note that the IMF-fixdate format uses "GMT", not "UTC", 673 to designate the time zone, as in this example: 675 Date: Tue, 15 Nov 2014 08:12:31 GMT 677 5.1. Calendar extensions for Filtered Cost Maps (FCM) 679 A legacy ALTO Client requests and gets Filtered Cost Map responses as 680 specified in [RFC7285]. 682 5.1.1. Calendar extensions in Filtered Cost Map requests 684 The input parameters of a "legacy" request for a filtered cost map, 685 defined by object ReqFilteredCostMap in section 11.3.2 of [RFC7285], 686 are augmented with one additional member. 688 A Calendar-aware ALTO Client requesting a Calendar on a given Cost 689 Type for a filtered cost map resource having Calendar capabilities 690 MUST add the following field to its input parameters: 692 JSONBoolean calendared<1..*>; 694 This field is an array of 1 to N boolean values, where N is the 695 number of requested metrics. Each entry corresponds to the requested 696 metric at the same array position. Each boolean value indicates 697 whether or not the ALTO Server should provide the values for this 698 cost type as a Calendar. The array MUST contain exactly N boolean 699 values, otherwise, the Server returns an error. 701 This field MUST NOT be included if no member "calendar-attributes" is 702 specified in this information resource. 704 If a value of field 'calendared' is 'true' for a cost type name for 705 which no Calendar attributes have been specified: an ALTO Server, 706 whether it implements the extensions of this document or only 707 implements [RFC7285], MUST ignore it and return a response with a 708 single cost value as specified in [RFC7285]. 710 If this field is not present, it MUST be assumed to have only values 711 equal to 'false'. 713 A Calendar-aware ALTO Client that supports requests for only one cost 714 type at a time and wants to request a Calendar MUST provide an array 715 of 1 element: 717 "calendared" : [true]; 719 A Calendar-aware ALTO Client that supports requests for more than one 720 cost types at a time, as specified in [RFC8189] MUST provide an array 721 of N values set to 'true' or 'false', depending whether it wants the 722 applicable cost type values as a single or calendared value. 724 5.1.2. Calendar extensions in Filtered Cost Map responses 726 In a calendared ALTO Filtered Cost Map, a cost value between a source 727 and a destination is a JSON array of JSON values. An ALTO Calendar 728 values array has a number of values equal to the value of member 729 "number-of-intervals" of the Calendar attributes that are indicated 730 in the IRD. These attributes will be conveyed as metadata in the 731 Filtered Cost Map response. Each element of the array is valid for 732 the time-interval that matches its array position. 734 The FCM response conveys metadata among which: 736 o some are not specific to Calendars and ensure compatibility with 737 [RFC7285] and [RFC8189] 739 o some are specific to Calendars. 741 The non Calendar specific "meta" fields of a calendared Filtered Cost 742 Map response MUST include at least: 744 o if the ALTO Client requests cost values for one cost type at a 745 time only: the "meta" fields specified in [RFC7285] for these 746 information service responses: 748 * "dependent-vtags ", 750 * "cost-type" field. 752 o if the ALTO Client implements the Multi-Cost ALTO extension 753 specified in [RFC8189] and requests cost values for several Cost 754 Types at a time: the "meta" fields specified in [RFC8189] for 755 these information service responses: 757 * "dependent-vtags ", 759 * "cost-type" field with value set to '{}', for backwards 760 compatibility with [RFC7285]. 762 * "multi-cost-types" field. 764 If the client request does not provide member "calendared" or if it 765 provides it with a value equal to 'false', for all the requested Cost 766 Types, then the ALTO Server response is exactly as specified in 767 [RFC7285] and [RFC8189]. 769 If the value of member "calendared" is equal to 'false' for a given 770 requested cost type, the ALTO Server MUST return, for this cost type, 771 a single cost value as specified in [RFC7285]. 773 If the value of member "calendared" is equal to 'true' for a given 774 requested cost type, the ALTO Server returns, for this cost type, a 775 cost value Calendar as specified above in this section. In addition 776 to the above cited non Calendar specific "meta" members, the Server 777 MUST provide a Calendar specific metadata field. 779 The Calendar specific "meta" field that a calendared Filtered Cost 780 Map response MUST include is a member called "calendar-response- 781 attributes", that describes properties of the Calendar and where: 783 o member "calendar-response-attributes" is an array of one or more 784 objects of type "CalendarResponseAttributes". 786 o each "CalendarResponseAttributes" object in the array is specified 787 for one or more cost types for which the value of member 788 "calendared" is equal to 'true' and for which a Calendar is 789 provided for the requested information resource. 791 o the "CalendarResponseAttributes" object that applies to a cost 792 type name has a corresponding "CalendarAttributes" object defined 793 for this cost type name in the IRD capabilities of the requested 794 information resource. The members of a 795 "CalendarResponseAttributes" object include all the members of the 796 corresponding "CalendarAttributes" object. 798 The format of member "CalendarResponseAttributes is defined as 799 follows: 801 CalendarResponseAttributes calendar-response-attributes <1..*>; 803 object{ 804 [JSONString cost-type-names <1..*>]; 805 JSONString calendar-start-time; 806 JSONNumber time-interval-size; 807 JSONNumber number-of-intervals; 808 [JSONNumber repeated;] 809 } CalendarResponseAttributes; 811 Object CalendarResponseAttributes has the following attributes: 813 o "cost-type-names": is an array of one or more cost-type-names to 814 which the capabilities apply and for which a Calendar has been 815 requested. The value of this member is a subset of the "cost- 816 type-names" array specified in the corresponding IRD Calendar 817 attributes. 819 o "calendar-start-time": indicates the date at which the first value 820 of the Calendar applies. The value provided for the "calendar- 821 start-time" attribute SHOULD NOT be later than the request date. 823 o "time-interval-size": as specified in Section 4.1 and with the 824 same value. 826 o "number-of-intervals": as specified in Section 4.1 and with the 827 same value. 829 o "repeated": is an optional field provided for Calendars. It is an 830 integer N greater or equal to '1' that indicates how many 831 iterations of the Calendar value array starting at the date 832 indicated by "calendar-start-time" have the same values. The 833 number N includes the iteration provided in the returned response. 835 For example: suppose the "calendar-start-time" member has value "Mon, 836 30 Jun 2014 00:00:00 GMT", the "time-interval-size" member has value 837 '3600', the "number-of-intervals" member has value '24' and the value 838 of member "repeated" is equal to '4'. This means that the Calendar 839 values are the same on Monday, Tuesday, Wednesday and Thursday on a 840 period of 24 hours starting at 00:00:00 GMT. The ALTO Client thus 841 may use the same Calendar for the next 4 days starting at "calendar- 842 start-time" and will only need to request a new one for Friday July 843 4th at 00:00:00 GMT. 845 Attribute "repeated" may take a very high value if a Calendar 846 represents a cyclic value pattern that the Server considers valid for 847 a long period and hence will only update once this period has elapsed 848 or if an unexpected event occurs on the network. In the latter case, 849 the client will be notified if it uses the "ALTO Incremental Updates 850 Using Server-Sent Events (SSE)" Service, specified in 851 [I-D.ietf-alto-incr-update-sse]. To this end, it is RECOMMENDED that 852 ALTO Servers providing ALTO Calendars also provide the "ALTO 853 Incremental Updates Using Server-Sent Events (SSE)" Service that is 854 specified in [I-D.ietf-alto-incr-update-sse]. Likewise, ALTO Clients 855 capable of using ALTO Calendars SHOULD also use the SSE Service. See 856 also discussion in Section 8 "Operational Considerations". 858 5.1.3. Use case and example: FCM with a bandwidth Calendar 860 An example of non-real time information that can be provisioned in a 861 Calendar is the expected path throughput. While the transmission 862 rate can be measured in real time by end systems, the operator of a 863 data center is in the position of formulating preferences for given 864 paths, at given time periods to avoid traffic peaks due to diurnal 865 usage patterns. In this example, we assume that an ALTO Client 866 requests a Calendar of network provider defined throughput ratings, 867 as specified in the IRD, to schedule its bulk data transfers as 868 described in the use cases. 870 In the example IRD, Calendars for cost type name "num- 871 throughputrating" are available for the information resources: 872 "filtered-cost-calendar-map" and "endpoint-cost-calendar-map". The 873 ALTO Client requests a Calendar for "num-throughputrating" via a POST 874 request for a filtered cost map. 876 We suppose in the present example that the ALTO Client sends its 877 request on Tuesday July 1st 2014 at 13:15. The Server returns 878 Calendars with arrays of 12 numbers for each source and destination 879 pair. The values for metric "throughputrating", in this example, are 880 assumed to be encoded in 2 digits. 882 POST /calendar/costmap/filtered HTTP/1.1 883 Host: alto.example.com 884 Content-Length: 208 885 Content-Type: application/alto-costmapfilter+json 886 Accept: application/alto-costmap+json,application/alto-error+json 888 { 889 "cost-type" : {"cost-mode" : "numerical", 890 "cost-metric" : "throughputrating"}, 891 "calendared" : [true], 892 "pids" : { 893 "srcs" : [ "PID1", "PID2" ], 894 "dsts" : [ "PID1", "PID2", "PID3" ] 895 } 896 } 898 HTTP/1.1 200 OK 899 Content-Length: 1013 900 Content-Type: application/alto-costmap+json 902 { 903 "meta" : { 904 "dependent-vtags" : [ 905 {"resource-id": "my-default-network-map", 906 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 907 } 908 ], 909 "cost-type" : {"cost-mode" : "numerical", 910 "cost-metric" : "throughputrating"}, 911 "calendar-response-attributes" : [ 912 {"calendar-start-time" : "Tue, 1 Jul 2014 13:00:00 GMT", 913 "time-interval-size" : 7200, 914 "number-of-intervals" : 12} 915 ] 916 }, 917 "cost-map" : { 918 "PID1": { "PID1": [ 1, 12, 14, 18, 14, 14, 919 14, 18, 19, 20, 11, 12], 920 "PID2": [13, 4, 15, 16, 17, 18, 921 19, 20, 11, 12, 13, 14], 922 "PID3": [20, 20, 18, 14, 12, 12, 923 14, 14, 12, 12, 14, 16] }, 924 "PID2": { "PID1": [17, 18, 19, 10, 11, 12, 925 13, 14, 15, 16, 17, 18], 926 "PID2": [20, 20, 18, 16, 14, 14, 927 14, 16, 16, 16, 14, 16], 928 "PID3": [20, 20, 18, 14, 12, 12, 929 14, 14, 12, 12, 14, 16] } 930 } 931 } 933 5.2. Calendar extensions in the Endpoint Cost Service 935 This document extends the Endpoint Cost Service, as defined in 936 {11.5.1} of [RFC7285], by adding new input parameters and 937 capabilities, and by returning JSONArrays instead of JSONNumbers as 938 the cost values. The media type {11.5.1.1} and HTTP method 939 {11.5.1.2} are unchanged. 941 5.2.1. Calendar specific input in Endpoint Cost requests 943 The extensions to the requests for calendared Endpoint Cost Maps are 944 the same as for the Filtered Cost Map Service, specified in section 945 Section 5.1.1 of this draft. 947 The ReqEndpointCostMap object for a calendared ECM request will have 948 the following format: 950 object { 951 [CostType cost-type;] 952 [CostType multi-cost-types<1..*>;] 953 [JSONBoolean calendared<1..*>;] 954 EndpointFilter endpoints; 955 } ReqEndpointCostMap; 957 object { 958 [TypedEndpointAddr srcs<0..*>;] 959 [TypedEndpointAddr dsts<0..*>;] 960 } EndpointFilter; 962 5.2.2. Calendar attributes in the Endpoint Cost response 964 The "meta" field of a calendared Endpoint Cost response MUST include 965 at least: 967 o if the ALTO Client supports cost values for one cost type at a 968 time only: the "meta" fields specified in {11.5.1.6} of [RFC7285] 969 for the Endpoint Cost response: 971 * "cost-type" field. 973 o if the ALTO Client supports cost values for several cost types at 974 a time, as specified in [RFC8189] : the "meta" fields specified in 975 [RFC8189] for the the Endpoint Cost response: 977 * "cost-type" field with value set to '{}', for backwards 978 compatibility with [RFC7285]. 980 * "multi-cost-types" field. 982 If the client request does not provide member "calendared" or if it 983 provides it with a value equal to 'false', for all the requested Cost 984 Types, then the ALTO Server response is exactly as specified in 985 [RFC7285] and [RFC8189]. 987 If the ALTO Client provides member "calendared" in the input 988 parameters with a value equal to 'true' for given requested Cost 989 Types, the "meta" member of a calendared Endpoint Cost response MUST 990 include, for these cost types, an additional member "calendar- 991 response-attributes", the contents of which obey the same rules as 992 for the Filtered Cost Map Service, specified in Section 5.1.2. The 993 Server response is thus changed as follows, with respect to [RFC7285] 994 and [RFC8189]: 996 o the "meta" member has one additional field 997 "CalendarResponseAttributes", as specified for the Filtered Cost 998 Map Service, 1000 o the calendared costs are JSONArrays instead of the JSONNumbers 1001 format used by legacy ALTO implementations. All arrays have a 1002 number of values equal to 'number-of-intervals'. 1004 If the value of member "calendared" is equal to 'false' for a given 1005 requested cost type, the ALTO Server MUST return, for this cost type, 1006 a single cost value as specified in [RFC7285]. 1008 5.2.3. Use case and example: ECS with a routingcost Calendar 1010 Let us assume an Application Client is located in an end system with 1011 limited resources and having access to the network that is either 1012 intermittent or provides an acceptable quality in limited but 1013 predictable time periods. Therefore, it needs to schedule both its 1014 resource-greedy networking activities and its ALTO transactions. 1016 The Application Client has the choice to trade content or resources 1017 with a set of Endpoints and needs to decide with which one it will 1018 connect and at what time. For instance, the Endpoints are spread in 1019 different time-zones, or have intermittent access. In this example, 1020 the 'routingcost' is assumed to be time-varying, with values provided 1021 as ALTO Calendars. 1023 The ALTO Client associated with the Application Client queries an 1024 ALTO Calendar on 'routingcost' and will get the Calendar covering the 1025 24 hours time period "containing" the date and time of the ALTO 1026 client request. 1028 For cost type "num-routingcost", the solicited ALTO Server has 1029 defined 3 different daily patterns each represented by a Calendar, to 1030 cover the week of Monday June 30th at 00:00 to Sunday July 6th 23:59: 1032 o C1 for Monday, Tuesday, Wednesday, Thursday, (weekdays) 1034 o C2 for Saturday, Sunday, (weekend) 1036 - C3 for Friday (maintenance outage on July 4, 2014 from 02:00:00 GMT 1037 to 04:00:00 GMT, or big holiday such as New Year evening). 1039 In the following example, the ALTO Client sends its request on 1040 Tuesday July 1st 2014 at 13:15. 1042 The "routingcost" values are assumed to be encoded in 3 digits. 1044 POST /calendar/endpointcost/lookup HTTP/1.1 1045 Host: alto.example.com 1046 Content-Length: 290 1047 Content-Type: application/alto-endpointcostparams+json 1048 Accept: application/alto-endpointcost+json,application/alto-error+json 1050 { 1051 "cost-type" : {"cost-mode" : "numerical", 1052 "cost-metric" : "routingcost"}, 1053 "calendared" : [true], 1054 "endpoints" : { 1055 "srcs": [ "ipv4:192.0.2.2" ], 1056 "dsts": [ 1057 "ipv4:192.0.2.89", 1058 "ipv4:198.51.100.34", 1059 "ipv4:203.0.113.45", 1060 "ipv6:2001:db8::10" 1061 ] 1062 } 1063 } 1065 HTTP/1.1 200 OK 1067 Content-Length: 1318 1068 Content-Type: application/alto-endpointcost+json 1070 { 1071 "meta" : { 1072 "cost-type" : {"cost-mode" : "numerical", 1073 "cost-metric" : "routingcost"}, 1074 "calendar-response-attributes" : [ 1075 {"calendar-start-time" : "Mon, 30 Jun 2014 00:00:00 GMT", 1076 "time-interval-size" : 3600, 1077 "number-of-intervals" : 24, 1078 "repeated": 4 1079 } 1080 ] 1081 }, 1082 "endpoint-cost-map" : { 1083 "ipv4:192.0.2.2": { 1084 "ipv4:192.0.2.89" : [100, 100, 100, 100, 100, 150, 1085 200, 300, 300, 300, 300, 250, 1086 250, 300, 300, 300, 300, 300, 1087 400, 250, 250, 200, 150, 150], 1088 "ipv4:198.51.100.34" : [ 80, 80, 80, 80, 150, 150, 1089 250, 400, 400, 450, 400, 200, 1090 200, 350, 400, 400, 400, 350, 1091 500, 200, 200, 200, 100, 100], 1093 "ipv4:203.0.113.45" : [300, 400, 250, 250, 200, 150, 1094 150, 100, 100, 100, 100, 100, 1095 100, 100, 100, 100, 100, 150, 1096 200, 300, 300, 300, 300, 250], 1097 "ipv6:2001:db8::10" : [200, 250, 300, 300, 300, 300, 1098 250, 300, 300, 300, 300, 350, 1099 300, 400, 250, 150, 100, 100, 1100 100, 150, 200, 250, 250, 300] 1101 } 1102 } 1103 } 1105 When the Client gets the Calendar for "routingcost", it sees that the 1106 "calendar-start-time" is Monday at 00h00 GMT and member "repeated" is 1107 equal to '4'. It understands that the provided values are valid 1108 until Thursday included and will only need to get a Calendar update 1109 on Friday. 1111 5.2.4. Use case and example: ECS with a multi-cost Calendar for 1112 routingcost and owdelay 1114 In this example, it is assumed that the ALTO Server implements multi- 1115 cost capabilities, as specified in [RFC8189] . That is, an ALTO 1116 Client can request and receive values for several cost types in one 1117 single transaction. An illustrating use case is a path selection 1118 done on the basis of 2 metrics: routing cost and owdelay. 1120 As in the previous example, the IRD indicates that the ALTO Server 1121 provides "routingcost" Calendars in terms of 24 time intervals of 1 1122 hour (3600 seconds) each. 1124 For metric "owdelay", the IRD indicates that the ALTO Server provides 1125 Calendars in terms of 12 time intervals values lasting each 5 minutes 1126 (300 seconds). 1128 In the following example transaction, the ALTO Client sends its 1129 request on Tuesday July 1st 2014 at 13:15. 1131 This example assumes that the values of metric "owdelay" and 1132 "routingcost" are encoded in 3 digits. 1134 POST calendar/endpointcost/lookup HTTP/1.1 1135 Host: alto.example.com 1136 Content-Length: 373 1137 Content-Type: application/alto-endpointcostparams+json 1138 Accept: application/alto-endpointcost+json,application/alto-error+json 1140 { 1141 "cost-type" : {}, 1142 "multi-cost-types" : [ 1143 {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, 1144 {"cost-mode" : "numerical", "cost-metric" : "owdelay"} 1145 ], 1146 "calendared" : [true, true], 1147 "endpoints" : { 1148 "srcs": [ "ipv4:192.0.2.2" ], 1149 "dsts": [ 1150 "ipv4:192.0.2.89", 1151 "ipv4:198.51.100.34", 1152 "ipv4:203.0.113.45", 1153 "ipv6:2001:db8::10" 1154 ] 1155 } 1156 } 1158 HTTP/1.1 200 OK 1159 Content-Length: 2111 1160 Content-Type: application/alto-endpointcost+json 1162 { 1163 "meta" : { 1164 "multi-cost-types" : [ 1165 {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, 1166 {"cost-mode" : "numerical", "cost-metric" : "owdelay"} 1167 ], 1168 "calendar-response-attributes" : [ 1169 {"cost-type-names" : "num-routingcost", 1170 "calendar-start-time" : "Mon, 30 Jun 2014 00:00:00 GMT", 1171 "time-interval-size" : 3600, 1172 "number-of-intervals" : 24, 1173 "repeated": 4 }, 1174 {"cost-type-names" : "num-owdelay", 1175 "calendar-start-time" : "Tue, 1 Jul 2014 13:00:00 GMT", 1176 "time-interval-size" : 300, 1177 "number-of-intervals" : 12} 1178 ] 1179 }, 1180 "endpoint-cost-map" : { 1181 "ipv4:192.0.2.2": { 1182 "ipv4:192.0.2.89" : [[100, 100, 100, 100, 100, 150, 1183 200, 300, 300, 300, 300, 250, 1184 250, 300, 300, 300, 300, 300, 1185 400, 250, 250, 200, 150, 150], 1186 [ 20, 400, 20, 80, 80, 90, 1187 100, 90, 60, 40, 30, 20]], 1188 "ipv4:198.51.100.34" : [[ 80, 80, 80, 80, 150, 150, 1189 250, 400, 400, 450, 400, 200, 1190 200, 350, 400, 400, 400, 350, 1191 500, 200, 200, 200, 100, 100], 1192 [ 20, 20, 50, 30, 30, 30, 1193 30, 40, 40, 30, 20, 20]], 1194 "ipv4:203.0.113.45" : [[300, 400, 250, 250, 200, 150, 1195 150, 100, 100, 100, 100, 100, 1196 100, 100, 100, 100, 100, 150, 1197 200, 300, 300, 300, 300, 250], 1198 [100, 90, 80, 60, 50, 50, 1199 40, 40, 60, 90, 100, 80]], 1200 "ipv6:2001:db8::10" : [[200, 250, 300, 300, 300, 300, 1201 250, 300, 300, 300, 300, 350, 1202 300, 400, 250, 150, 100, 100, 1203 100, 150, 200, 250, 250, 300], 1204 [ 40, 40, 40, 40, 50, 50, 1205 50, 20, 10, 15, 30, 40]] 1206 } 1207 } 1208 } 1210 When receiving the response, the client sees that the Calendar values 1211 for metric "routingcost" are repeated for 4 iterations. Therefore, 1212 in its next requests until the "routingcost" Calendar is expected to 1213 change, the client will only need to request a Calendar for 1214 "owdelay". 1216 Without the ALTO Calendar extensions, the ALTO Client would have no 1217 clue on the dynamicity of the metric value change and would spend 1218 needless time requesting values at an inappropriate pace. In 1219 addition, without the Multi-Cost ALTO capabilities, the ALTO Client 1220 would duplicate this waste of time as it would need to send one 1221 request per cost metric. 1223 6. IANA Considerations 1225 This document does not define any new media types or introduce any 1226 new IANA considerations. 1228 7. Security Considerations 1230 As an extension of the base ALTO protocol [RFC7285], this document 1231 fits into the architecture of the base protocol, and hence the 1232 Security Considerations (Section 15) of the base protocol fully apply 1233 when this extension is provided by an ALTO Server. For example, the 1234 same authenticity and integrity considerations (Section 15.1 of 1235 [RFC7285] still fully apply; the same considerations for the privacy 1236 of ALTO users (Section 15.4 of [RFC7285]) also still fully apply. 1238 The calendaring information provided by this extension requires 1239 additional considerations on three security considerations discussed 1240 in the base protocol: potential undesirable guidance to clients 1241 (Section 15.2 of [RFC7285]), confidentiality of ALTO information 1242 (Section 15.2 of [RFC7285]), and availability of ALTO (Section 15.5 1243 of [RFC7285]). For example, by providing network information in the 1244 future in a Calendar, this extension may improve availability of 1245 ALTO, when the ALTO Server is unavailable but related information is 1246 already provided in the Calendar. 1248 For confidentiality of ALTO information, an operator should be 1249 cognizant that this extension may introduce a new risk: a malicious 1250 ALTO Client may get information for future events that are scheduled 1251 through Calendaring. Possessing such information, the malicious 1252 Client may use it to generate massive connections to the network at 1253 times where its load is expected to be high. 1255 To mitigate this risk, the operator should address the risk of ALTO 1256 information being leaked to malicious Clients or third parties. As 1257 specified in Section 15.3.2 ("Protection Strategies") of [RFC7285], 1258 the ALTO Server should authenticate ALTO Clients and use the 1259 Transport Layer Security (TLS) protocol so that Man In The Middle 1260 (MITM) attacks to intercept an ALTO Calendar are not possible. 1261 [RFC7285] ensures the availability of such a solution in its 1262 Section 8.3.5. "Authentication and Encryption", which specifies 1263 that: "ALTO Server implementations as well as ALTO Client 1264 implementations MUST support the "https" URI scheme of [RFC2818] and 1265 Transport Layer Security (TLS) of [RFC5246]". 1267 [RFC8446] specifies TLS 1.3 and writes in its section 1: "While TLS 1268 1.3 is not directly compatible with previous versions, all versions 1269 of TLS incorporate a versioning mechanism which allows clients and 1270 servers to interoperably negotiate a common version if one is 1271 supported by both peers". ALTO Clients and Servers SHOULD support 1272 both TLS 1.3 [RFC8446] and TLS 1.2 [RFC5246], and MAY support and use 1273 newer versions of TLS as long as the negotiation process succeeds. 1275 The operator should be cognizant that the preceding mechanisms do not 1276 address all security risks. In particular, they will not help in the 1277 case of "malicious clients" possessing valid credentials to 1278 authenticate. The threat here can be that legitimate clients have 1279 become subverted by an attacker and are now 'bots' being asked to 1280 participate in a DDoS attack. The Calendar information would be 1281 valuable information for when to persecute a DDoS attack. A 1282 mechanism such as a monitoring system that detects abnormal behaviors 1283 may still be needed. 1285 To avoid malicious or erroneous guidance from ALTO information, an 1286 ALTO Client should be cognizant that using calendaring information 1287 can have risks: (1) Calendar values, especially in "repeated" 1288 Calendars may be only statistical, and (2) future events may change. 1289 Hence, a more robust ALTO Client should adapt and extend protection 1290 strategies specified in Section 15.2 of the base protocol. For 1291 example, to be notified immediately when a particular ALTO value that 1292 the client depends on changes, it is RECOMMENDED that both the ALTO 1293 Client and ALTO Server using this extension support "ALTO Incremental 1294 Updates Using Server-Sent Events(SSE)" Service 1295 [I-D.ietf-alto-incr-update-sse]. 1297 8. Operational Considerations 1299 It is important that both the operator of the network and the 1300 operator of the applications consider both the feedback aspect and 1301 the prediction-based (uncertainty) aspect of using the Cost Calendar. 1303 First consider the feedback aspect and consider the Cost Calendar as 1304 a traffic-aware map service (e.g., Google Maps). Using the service 1305 without considering its own effect, a large fleet can turn a not- 1306 congested road into a congested one; a large number of individual 1307 cars each choosing a road with light traffic ("cheap link") can also 1308 result in congestion or result in a less optimal global outcome 1309 (e.g., the Braess' Paradox [Braess-paradox]). 1311 Next consider the prediction aspect. Conveying ALTO Cost Calendars 1312 tends to reduce the on-the-wire data exchange volume compared to 1313 multiple single cost ALTO transactions. An application using 1314 Calendars has a set of time-dependent values upon which it can plan 1315 its connections in advance with no need for the ALTO Client to query 1316 information at each time. Additionally, the Calendar response 1317 attribute "repeated", when provided, saves additional data exchanges 1318 in that it indicates that the ALTO Client does not need to query 1319 Calendars during a period indicated by this attribute. The preceding 1320 is true only when "accidents" do not happen. 1322 Although individual network operators and application operators can 1323 choose their own approaches to address the aforementioned issues, 1324 this document recommends the following considerations. First, a 1325 typical approach to reducing instability and handling uncertainty is 1326 to ensure timely update of information. The SSE Service as discussed 1327 in Section 7 can handle updates, if supported by both the Server and 1328 the Client. Second, when a network operator updates the Cost 1329 Calendar and when an application reacts to the update, they should 1330 consider the feedback effects. This is the best approach even though 1331 there is theoretical analysis [Selfish-routing-Roughgarden-thesis] 1332 and Internet based evaluation [Selfish-routing-Internet-eval] showing 1333 that uncoordinated behaviors do not always cause substantial sub- 1334 optimal results. 1336 High-resolution intervals may be needed when values change, sometimes 1337 during very small time intervals but in a significant manner. A way 1338 to avoid conveying too many entries is to leverage on the "repeated" 1339 feature. A server can smartly set the Calendar start time and number 1340 of intervals so as to declare them "repeated" for a large number of 1341 periods, until the Calendar values change and are conveyed to 1342 requesting Clients. 1344 The newer JSON Data Interchange Format specification [RFC8259] used 1345 in ALTO Calendars replaces the older one [RFC7159] used in the base 1346 ALTO protocol [RFC7285]. The newer JSON mandates UTF-8 text encoding 1347 to improve interoperability. Therefore, ALTO Clients and Servers 1348 implementations using UTF-{16,32} need to be cognizant of the 1349 subsequent interoperability risks and MUST switch to UTF-8 encoding, 1350 if they want to interoperate with Calendar-aware Servers and Clients. 1352 9. Acknowledgements 1354 The authors would like to thank Fred Baker, Li Geng, Diego Lopez, He 1355 Peng and Haibin Song for fruitful discussions and feedback on earlier 1356 draft versions. Dawn Chan, Kai Gao, Vijay Gurbani, Yichen Qian, 1357 Juergen Schoenwaelder, and Brian Weis and Jensen Zhang provided 1358 substantial review feedback and suggestions to the protocol design. 1360 10. References 1362 10.1. Normative References 1364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1365 Requirement Levels", BCP 14, RFC 2119, 1366 DOI 10.17487/RFC2119, March 1997, 1367 . 1369 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1370 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1371 DOI 10.17487/RFC7231, June 2014, 1372 . 1374 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1375 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1376 "Application-Layer Traffic Optimization (ALTO) Protocol", 1377 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1378 . 1380 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1381 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1382 May 2017, . 1384 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1385 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1386 DOI 10.17487/RFC8189, October 2017, 1387 . 1389 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1390 Interchange Format", STD 90, RFC 8259, 1391 DOI 10.17487/RFC8259, December 2017, 1392 . 1394 10.2. Informative References 1396 [IEEE.754.2008] 1397 "Standard for Binary Floating-Point Arithmetic, IEEE 1398 Standard 754", August 2008. 1400 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1401 DOI 10.17487/RFC2818, May 2000, 1402 . 1404 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1405 (TLS) Protocol Version 1.2", RFC 5246, 1406 DOI 10.17487/RFC5246, August 2008, 1407 . 1409 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1410 Optimization (ALTO) Problem Statement", RFC 5693, 1411 DOI 10.17487/RFC5693, October 2009, 1412 . 1414 [RFC6708] Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R., 1415 and Y. Yang, "Application-Layer Traffic Optimization 1416 (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708, 1417 September 2012, . 1419 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1420 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1421 2014, . 1423 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1424 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1425 . 1427 [I-D.ietf-alto-incr-update-sse] 1428 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1429 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 1430 sse-20 (work in progress), February 2020. 1432 [I-D.ietf-alto-performance-metrics] 1433 WU, Q., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, 1434 "ALTO Performance Cost Metrics", draft-ietf-alto- 1435 performance-metrics-08 (work in progress), November 2019. 1437 [I-D.xiang-alto-multidomain-analytics] 1438 Xiang, Q., Le, F., Yang, Y., Newman, H., and H. Du, 1439 "Unicorn: Resource Orchestration for Multi-Domain, Geo- 1440 Distributed Data Analytics", draft-xiang-alto-multidomain- 1441 analytics-02 (work in progress), July 2018. 1443 [SENSE-sdn-e2e-net] 1444 "SDN for End-to-End Networked Science at the Exascale 1445 (SENSE), http://sense.es.net/overview". 1447 [Braess-paradox] 1448 Steinberg, R. and W. Zangwill, "The Prevalence of Braess' 1449 Paradox", Transportation Science Vol. 17 No. 3, August 1450 1983. 1452 [Selfish-routing-Roughgarden-thesis] 1453 Roughgarden, T., "Selfish Routing", Dissertation Thesis, 1454 Cornell 2002, May 2002. 1456 [Selfish-routing-Internet-eval] 1457 Qiu, L., Yang, Y., Zhang, Y., and S. Shenker, "Selfish 1458 Routing in Internet-LIke Environments", Proceedings of ACM 1459 SIGCOMM 2001, August 2001. 1461 Authors' Addresses 1463 Sabine Randriamasy 1464 Nokia Bell Labs 1465 Route de Villejust 1466 NOZAY 91460 1467 FRANCE 1469 Email: Sabine.Randriamasy@nokia-bell-labs.com 1470 Richard Yang 1471 Yale University 1472 51 Prospect st 1473 New Haven, CT 06520 1474 USA 1476 Email: yry@cs.yale.edu 1478 Qin Wu 1479 Huawei 1480 101 Software Avenue, Yuhua District 1481 Nanjing, Jiangsu 210012 1482 China 1484 Email: sunseawq@huawei.com 1486 Lingli Deng 1487 China Mobile 1488 China 1490 Email: denglingli@chinamobile.com 1492 Nico Schwan 1493 Thales Deutschland 1494 Lorenzstrasse 10 1495 Stuttgart 70435 1496 Germany 1498 Email: nico.schwan@thalesgroup.com