idnits 2.17.1 draft-ietf-alto-cost-calendar-10.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 7, 2019) is 1902 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 1288, but no explicit reference was found in the text -- 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) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 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 11, 2019 Yale University 6 Q. Wu 7 Huawei 8 L. Deng 9 China Mobile 10 N. Schwan 11 Thales Deutschland 12 February 7, 2019 14 ALTO Cost Calendar 15 draft-ietf-alto-cost-calendar-10 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 such that applications decide not only 'where' to connect, 22 but also 'when'. This is useful for applications that need to 23 perform bulk data transfer and would like to schedule these transfers 24 during an off-peak hour, for example. This extension introduces ALTO 25 Cost Calendars, with which an ALTO Server exposes ALTO cost values in 26 JSON arrays where each value corresponds to a given time interval. 27 The time intervals as well as other Calendar attributes are specified 28 in the Information Resources Directory and ALTO Server responses. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in 35 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 When the words appear in lower case, they are to be interpreted with 39 their natural language meanings. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on August 11, 2019. 58 Copyright Notice 60 Copyright (c) 2019 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Overview of ALTO Cost Calendars . . . . . . . . . . . . . . . 4 77 2.1. ALTO Cost Calendar information features . . . . . . . . . 5 78 2.2. ALTO Calendar design characteristics . . . . . . . . . . 6 79 2.2.1. ALTO Cost Calendar for all cost modes . . . . . . . . 7 80 2.2.2. Compatibility with legacy ALTO Clients . . . . . . . 7 81 3. ALTO Calendar specification: IRD extensions . . . . . . . . . 8 82 3.1. Calendar attributes in the IRD resources capabilities . . 8 83 3.2. Calendars in a delegate IRD . . . . . . . . . . . . . . . 9 84 3.3. Example IRD with ALTO Cost Calendars . . . . . . . . . . 10 85 4. ALTO Calendar specification: Service Information Resources . 13 86 4.1. Calendar extensions for Filtered Cost Maps (FCM) . . . . 14 87 4.1.1. Calendar extensions in Filtered Cost Map requests . . 14 88 4.1.2. Calendar extensions in Filtered Cost Map responses . 15 89 4.1.3. Use case and example: FCM with a bandwidth Calendar . 17 90 4.2. Calendar extensions in the Endpoint Cost Service . . . . 20 91 4.2.1. Calendar specific input in Endpoint Cost requests . 20 92 4.2.2. Calendar attributes in the Endpoint Cost response . . 20 93 4.2.3. Use case and example: ECS with a routingcost Calendar 21 94 4.2.4. Use case and example: ECS with a multi-cost calendar 95 for routingcost and owdelay . . . . . . . . . . . . . 24 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 99 7. Operational Considerations . . . . . . . . . . . . . . . . . 27 100 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 103 9.2. Informative References . . . . . . . . . . . . . . . . . 28 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 106 1. Introduction 108 The base Application-Layer Traffic Optimization (ALTO) protocol 109 specified in [RFC7285] provides guidance to overlay applications 110 needing to select one or several hosts from a set of candidates able 111 to provide a desired resource. This guidance is based on parameters 112 that affect performance and efficiency of the data transmission 113 between the hosts such as the topological distance. The goal of ALTO 114 is to improve the Quality of Experience (QoE) in the application 115 while optimizing resource usage in the underlying network 116 infrastructure. 118 The ALTO protocol in [RFC7285] specifies a network map which defines 119 groupings of endpoints in provider-defined network regions identified 120 by Provider-defined Identifiers (PIDs). The Cost Map Service, 121 Endpoint Cost Service (ECS) and Endpoint Ranking Service then provide 122 ISP-defined costs and rankings for connections among the specified 123 endpoints and PIDs and thus incentives for application clients to 124 connect to ISP preferred locations, e.g. to reduce their costs. ALTO 125 intentionally avoids provisioning realtime information as explained 126 in the ALTO Problem Statement [RFC5693] and ALTO Requirements 127 [RFC5693]. Thus the current Cost Map and Endpoint Cost Service are 128 providing, for a given Cost Type, exactly one path cost value. 129 Applications have to query one of these two services to retrieve the 130 currently valid cost values. They therefore need to plan their ALTO 131 information requests according to their own estimation of the 132 frequency of cost value change. 134 With [RFC7285], an ALTO client should interpret the returned costs as 135 those at the query moment. However, Network costs can fluctuate, 136 e.g. due to diurnal patterns of traffic demand or planned events such 137 as network maintenance, holidays or highly publicized events. 138 Providing network costs for only the current time thus may not be 139 sufficient, in particular for applications that can schedule their 140 traffic in a span of time, for example by deferring backups or other 141 background traffic to off-peak hours. 143 In case the ALTO Cost value changes are predictable over a certain 144 period of time and the application does not require immediate data 145 transfer, it can save time to get the whole set of cost values over 146 this period in one single ALTO response. Using this set to schedule 147 data transfers allows optimizing the network resources usage and QoE. 148 ALTO Clients and Servers can also minimize their workload by reducing 149 and accordingly scheduling their data exchanges. 151 This document extends [RFC7285] to allow an ALTO server to provide 152 network costs for a given duration of time. A sequence of network 153 costs across a time span for a given pair of network locations is 154 named an "ALTO Cost Calendar". The Filtered Cost Map Service and 155 Endpoint Cost Service are extended to provide Cost Calendars. In 156 addition to this functional ALTO enhancement, we expect to further 157 save network and storage resources by gathering multiple Cost Values 158 for one Cost Type into one single ALTO Server response. 160 In this draft an "ALTO Cost Calendar" is specified in terms of 161 information resources capabilities that are applicable to time- 162 sensitive ALTO metrics. An ALTO Cost Calendar exposes ALTO Cost 163 Values in JSON arrays, see [RFC8259], where each value corresponds to 164 a given time interval. The time intervals as well as other Calendar 165 attributes are specified in the Information Resources Directory (IRD) 166 and in the Server response to allow the ALTO Client to interpret the 167 received ALTO values. Last, the extensions for ALTO Calendars are 168 applicable to any Cost Mode and they ensure backwards compatibility 169 with legacy ALTO clients. 171 In the rest of this document, Section 2 provides the design 172 characteristics. Sections 3 and 4 define the formal specifications 173 for the IRD and the information resources. IANA, security and 174 operational considerations are addressed respectively in sections 175 Section 5, Section 6 and Section 7. 177 2. Overview of ALTO Cost Calendars 179 An ALTO Cost calendar provided by the ALTO Server provides 2 180 information items: 182 o an array of values for a given metric, where each value 183 corresponds to a time interval, where the value array can 184 sometimes be a cyclic pattern that repeats a certain number of 185 times. 187 o attributes describing the time scope of the calendar such as the 188 size and number of the intervals and the date of the starting 189 point of the calendar, allowing an ALTO Client to properly 190 interpret the values. 192 An ALTO Cost Calendar can be used like a "time table" to figure out 193 the best time to schedule data transfers and also to proactively 194 manage application traffic given predictable events such as crowded 195 events, traffic intensive holidays and network maintenance. It may 196 be viewed as a synthetic abstraction of, for example, real 197 measurements gathered over previous periods on which statistics have 198 been computed. However, like for any schedule, unexpected network 199 incidents may require the current ALTO Calendar to be updated and re- 200 sent to the ALTO Clients needing it. To this end, it is RECOMMENDED 201 that ALTO Servers providing ALTO Calendars also provide the "ALTO 202 Incremental Updates Using Server-Sent Events (SSE)" Service that is 203 specified in [draft-ietf-alto-incr-update-sse], and likewise, that 204 ALTO Clients capable of using ALTO Calendars also use the SSE 205 Service. 207 Most likely, the ALTO Cost Calendar would be used for the Endpoint 208 Cost Service, assuming that a limited set of feasible Endpoints for a 209 non-real time application is already identified, that they do not 210 need to be accessed immediately and that their access can be 211 scheduled within a given time period. The Filtered Cost Map Service 212 is also applicable as long as the size of the Map allows it. 214 2.1. ALTO Cost Calendar information features 216 The Calendar attributes are provided in the Information Resources 217 Directory (IRD) and in ALTO Server responses. The IRD announces 218 attributes with dateless values in its information resources 219 capabilities, where as attributes with time dependent values are 220 provided in the "meta" of Server responses. The ALTO Cost Calendar 221 attributes provide the following information: 223 o attributes to describe the time scope of the Calendar value array: 225 * generic time zone, 227 * applicable time interval size for each calendar value, defined 228 in seconds, that can cover a wide range of values. 230 * duration of the Calendar: e.g. the number of intervals provided 231 in the calendar. 233 o "calendar-start-date": specifying when the calendar starts, that 234 is to which date the first value of the cost calendar is 235 applicable. 237 o "repeated": an optional attribute indicating for how many 238 iterations the provided calendar will have the same values. The 239 server may use it to allow the client to schedule its next request 240 and thus save its own workload by avoiding to process useless 241 requests. 243 Attribute "repeated" may take a very high value if a Calendar 244 represents a cyclic value pattern that the Server considers valid for 245 a long period and hence will only update once this period has elapsed 246 or if an unexpected event occurs on the network, see in next 247 sections. 249 2.2. ALTO Calendar design characteristics 251 The extensions in this document and encode requests and responses 252 using JSON [RFC8259]. 254 Formally, the cost entries in an ALTO cost map can be any type of 255 JSON value [RFC8259], (see the DstCosts object in Section 11.2.3.6 of 256 [RFC7285]). However, that section also says that an implementation 257 of [RFC7285] SHOULD assume that the cost is a JSON number and fail to 258 parse if it is not, unless the implementation is using an extension 259 that signals a different data type. This document extends the 260 definition of a legacy cost map given in [RFC7285] to allow a cost 261 entry to be an array of values, one per time interval, instead of 262 just one number. 264 To realize an ALTO Calendar, this document extends: the IRD, the ALTO 265 requests and responses for Cost Calendars. 267 This extension is designed to be light and ensure backwards 268 compatibility with base protocol ALTO Clients and with other 269 extensions. As recommended, it relies on section 8.3.7 "Parsing of 270 Unknown Fields" of [RFC7285] that writes: "Extensions may include 271 additional fields within JSON objects defined in this document. ALTO 272 implementations MUST ignore unknown fields when processing ALTO 273 messages." 275 The calendar-specific capabilities are integrated in the information 276 resources of the IRD and in the "meta" member of ALTO responses to 277 Cost Calendars requests. A calendar and its capabilities are 278 associated with a given information resource and within this 279 information resource with a given cost type. This design has several 280 advantages: 282 o it does not introduce a new mode, 284 o it does not introduce new media types, 286 o it allows an ALTO Server to offer calendar capabilities on a cost 287 type, with attributes values adapted to each information resource. 289 The applicable calendared information resources are: 291 o the Filtered Cost Map, 293 o the Endpoint Cost Map. 295 The ALTO Server can choose in which frequency it provides cost 296 Calendars to ALTO Clients. It may either provide calendar updates 297 starting at the request date, or carefully schedule its updates so as 298 to take profit from a potential repetition/periodicity of calendar 299 values. 301 2.2.1. ALTO Cost Calendar for all cost modes 303 ALTO Calendars are well-suited for values encoded in the "numerical" 304 mode. Actually, Calendars can also represent metrics in other modes 305 considered as compatible with time-varying values. For example, 306 types of Cost values such as JSONBool can also be expressed as 307 calendars, as their value may be 'true' or 'false' depending on given 308 time periods or likewise, values represented by strings, such as 309 "medium", "high", "low", "blue", "open". 311 Note also that a Calendar is suitable as well for time-varying 312 metrics provided in the "ordinal" mode, if these values are time- 313 varying and the ALTO Server provides updates of cost value based 314 preferences. 316 2.2.2. Compatibility with legacy ALTO Clients 318 The ALTO protocol extensions for Cost Calendars have been defined so 319 as to ensure that Calendar capable ALTO Servers can provide legacy 320 ALTO Clients with legacy information resources as well. That is a 321 legacy ALTO Client can request resources and receive responses as 322 specified in [RFC7285]. 324 A Calendar-aware ALTO Server MUST implement the base protocol 325 specified in [RFC7285]. 327 As a consequence, when a metric is available as a Calendar array, it 328 MUST be available as a single value, as provided by [RFC7285] as 329 well. The Server, in this case provides the current value of the 330 metric to either Calendar-aware Clients not interested in future or 331 time-based values, or Clients implementing [RFC7285] only. 333 For compatibility with legacy ALTO Clients specified in [RFC7285], 334 calendared information resources are not applicable for full cost 335 maps for the following reason: a legacy ALTO client would receive a 336 calendared cost map via an HTTP 'GET' command. As specified in 337 section 8.3.7 of [RFC7285], it will ignore the Calendar Attributes 338 indicated in the "meta" of the responses. Therefore, lacking 339 information on calendar attributes, it will not be able to correctly 340 interpret and process the values of the received array of calendar 341 cost values. 343 Therefore, calendared information resources MUST be requested via the 344 Filtered Cost Map Service or the Endpoint Cost Service, using a POST 345 method. 347 3. ALTO Calendar specification: IRD extensions 349 The Calendar attributes in the IRD information resources capabilities 350 carry constant dateless values. A calendar is associated with an 351 information resource rather than a cost type. For example, a Server 352 can provide a "routingcost" calendar for the Filtered Cost Map 353 Service at a granularity of one day and a "routingcost" calendar for 354 the Endpoint Cost Service at a finer granularity but for a limited 355 number of endpoints. An example IRD with Calendar specific features 356 is provided in Section 3.3. 358 3.1. Calendar attributes in the IRD resources capabilities 360 When for an applicable resource, an ALTO Server provides a Cost 361 Calendar for a given Cost Type, it MUST indicate this in the IRD 362 capabilities of this resource, by an object of type 363 CalendarAttributes, that associates one or more Cost Types with these 364 Calendar Attributes and is specified below. 366 The capabilities of a Calendar-aware information resource entry have 367 a member named "calendar-attributes" which is an array of objects of 368 type CalendarAttributes. Each CalendarAttributes object applies to a 369 set of one or more Cost Types. Different Calendar Attributes may 370 apply to different Cost Types supported by this resource. 372 A Cost Type name MUST appear no more than once in the "calendar- 373 attributes" member of a resource entry. If, in a resource entry, a 374 Cost Type name appears more than one time in a CalendarAttributes 375 object of the "calendar-attributes" member, or in more than one 376 CalendarAttributes object of the "calendar-attributes" member, the 377 ALTO client MUST ignore any occurrence of this name beyond the first 378 one encountered. 380 It is RECOMMENDED for an ALTO Server that the time interval size 381 specified in the IRD is the smallest possible one that it can 382 provide. The Client can aggregate cost values on its own if it needs 383 a larger granularity. 385 The encoding format for object CalendarAttributes, using JSON 386 [RFC8259], is as follows: 388 CalendarAttributes calendar-attributes <1..*>; 390 object{ 391 JSONString cost-type-names <1..*>; 392 JSONNumber time-interval-size; 393 JSONNumber number-of-intervals; 394 } CalendarAttributes; 396 o "cost-type-names": 398 * An array of one or more elements indicating the cost-type-names 399 in the IRD entry to which the capabilities apply. 401 o "time-interval-size": 403 * is the duration of an ALTO calendar time interval in seconds. 404 A "time-interval-size" value contains a JSONNumber. ALTO 405 servers SHOULD use at least IEEE 754 double-precision floating 406 point [IEEE.754.2008] to store this value. Example values are: 407 300 , 7200, meaning that each calendar value applies on a time 408 interval that lasts respectively 5 minutes and 2 hours. 410 o "number-of-intervals": 412 * the integer number of values of the cost calendar array, at 413 least equal to 1. 415 - Attribute "cost-type-names" provides a better readability to the 416 calendar attributes specified in the IRD and avoids confusion with 417 calendar attributes of other cost-types. 419 - Multiplying 'time-interval-size' by 'number-of-intervals' provides 420 the duration of the provided calendar. For example an ALTO Server 421 may provide a calendar for ALTO values changing every 'time-interval- 422 size' equal to 5 minutes. If 'number-of-intervals' has the value 12, 423 then the duration of the provided calendar is "1 hour". 425 3.2. Calendars in a delegate IRD 427 One option to better sort out IRD resources w.r.t. for instance 428 supported extended services, is that a "root" ALTO Server 429 implementing base protocol resources delegates "specialized" 430 information resources such as the ones providing Cost Calendars to 431 another ALTO Server running in a subdomain specified with its URI in 432 the "root" ALTO Server. This option is described in Section 9.2.4 433 "Delegation using IRDs" of [RFC7285]. 435 This document provides an example, where a "root" ALTO Server runs in 436 a domain called "alto.example.com". It delegates the announcement of 437 Calendars capabilities to an ALTO Server running in a subdomain 438 called "custom.alto.example.com". The location of the "delegate 439 Calendar IRD" is assumed to be indicated in the "root" IRD by the 440 resource entry: "custom-calendared-resources". 442 Another advantage is that some Cost Types for some resources may be 443 more advantageous as Cost Calendars and it makes few sense to get 444 them as a single value. For example, Cost Types with predictable and 445 frequently changing values, calendared in short time intervals such 446 as a minute. 448 3.3. Example IRD with ALTO Cost Calendars 450 This section provides an example ALTO Server IRD that supports 451 various cost metrics and cost modes. In particular, since [RFC7285] 452 makes it mandatory, the Server uses metric "routingcost" in the 453 "numerical" mode. 455 For illustrative purposes, this section introduces 3 other fictitious 456 example metrics and modes that should be understood as examples and 457 should not be used or considered as normative. 459 The cost type names used in the example IRD as thus as follows: 461 o "num-routingcost": refers to metric "routingcost" in the numerical 462 mode as defined in [RFC7285] and registered at the IANA. 464 o "num-owdelay": refers to some fictitious performance metric 465 "owdelay" in the "numerical" mode,to reflect the one way packet 466 transmission delay on a path. A related performance metric is 467 currently under definition in 468 [draft-ietf-alto-performance-metrics]. 470 o "num-throughputrating": refers to some fictitious metric 471 "throughputrating" in the "numerical" mode, to reflect the 472 provider preference in terms of end to end throughput. 474 o "string-servicestatus": refers to some fictitious metric 475 "servicestatus" in some example mode "string", to reflect the 476 availability, defined by the provider, of for instance path 477 connectivity. 479 The example IRD includes 2 particular URIs providing calendars: 481 o "https://custom.alto.example.com/calendar/costmap/filtered": a 482 filtered cost map in which calendar capabilities are indicated for 483 cost type names: "num-routingcost", "num-throughputrating" and 484 "string-servicestatus", 486 o "https://custom.alto.example.com/calendar/endpointcost/lookup": an 487 endpoint cost map in which calendar capabilities are indicated for 488 cost type names: "num-routingcost", "num-owdelay", "num- 489 throughputrating", "string-servicestatus". 491 The design of the Calendar capabilities allows that some calendars on 492 a cost type name are available in several information resources with 493 different Calendar Attributes. This is the case for calendars on 494 "num-routingcost", "num-throughputrating" and "string-servicestatus", 495 available in both the Filtered Cost map and Endpoint Cost Service, 496 but with different time interval sizes for "num-throughputrating" and 497 "string-servicestatus". 499 GET /calendars-directory HTTP/1.1 500 Host: custom.alto.example.com 501 Accept: application/alto-directory+json,application/alto-error+json 502 --------------- 504 HTTP/1.1 200 OK 505 Content-Length: 2626 506 Content-Type: application/alto-directory+json 508 { 509 "meta" : { 510 "default-alto-network-map" : "my-default-network-map", 511 "cost-types": { 512 "num-routingcost": { 513 "cost-mode" : "numerical", 514 "cost-metric" : "routingcost" 515 }, 516 "num-owdelay": { 517 "cost-mode" : "numerical", 518 "cost-metric": "owdelay" 519 }, 520 "num-throughputrating": { 521 "cost-mode" : "numerical", 522 "cost-metric": "throughputrating", 523 }, 524 "string-servicestatus": { 525 "cost-mode" : "string", 526 "cost-metric": "servicestatus", 527 } 528 } 530 }, 531 "resources" : { 532 "filtered-cost-map-calendar" : { 533 "uri" : 534 "https://custom.alto.example.com/calendar/costmap/filtered", 535 "media-type" : "application/alto-costmap+json", 536 "accepts" : "application/alto-costmapfilter+json", 537 "capabilities" : { 538 "cost-constraints" : true, 539 "cost-type-names" : [ "num-routingcost", 540 "num-throughputrating", 541 "string-servicestatus" ], 542 "calendar-attributes" : [ 543 {"cost-type-names" : [ "num-routingcost", 544 "num-throughputrating" ], 545 "time-interval-size" : 7200, 546 "number-of-intervals" : 24 547 }, 548 {"cost-type-names" : [ "string-servicestatus" ], 549 "time-interval-size" : 1800, 550 "number-of-intervals" : 48 551 } 552 ] 553 } 554 "uses": [ "my-default-network-map" ] 555 }, 556 "endpoint-cost-calendar-map" : { 557 "uri" : 558 "https://custom.alto.example.com/calendar/endpointcost/lookup", 559 "media-type" : "application/alto-endpointcost+json", 560 "accepts" : "application/alto-endpointcostparams+json", 561 "capabilities" : { 562 "cost-constraints" : true, 563 "cost-type-names" : [ "num-routingcost", 564 "num-owdelay", 565 "num-throughputrating", 566 "string-servicestatus" ], 567 "calendar-attributes" : [ 568 {"cost-type-names" : [ "num-routingcost" ], 569 "time-interval-size" : 3600, 570 "number-of-intervals" : 24 571 }, 572 {"cost-type-names" : [ "num-owdelay" ], 573 "time-interval-size" : 300, 574 "number-of-intervals" : 12 575 }, 576 {"cost-type-names" : [ "num-throughputrating" ], 577 "time-interval-size" : 60, 578 "number-of-intervals" : 60 579 }, 580 {"cost-type-names" : [ "string-servicestatus" ], 581 "time-interval-size" : 120, 582 "number-of-intervals" : 30 583 } 584 ] 585 } 586 } 587 } 588 } 590 In this example IRD, for the Filtered Cost Map Service: 592 o the Calendar for "num-routingcost" and "num-throughputrating" is 593 an array of 12 values each provided on a time interval lasting 594 7200 seconds (2 hours). 596 o the Calendar for "string-servicestatus": "is an array of 48 values 597 each provided on a time interval lasting 1800 seconds (30 598 minutes). 600 For the Endpoint Cost Service: 602 o the Calendar for "num-routingcost": is an array of 24 values each 603 provided on a time interval lasting 3600 seconds (1 hour). 605 o the Calendar for "owdelay": is an array of 12 values each provided 606 on a time interval lasting 300 seconds (5 minutes). 608 o the Calendar for "num-throughputrating": is an array of 60 values 609 each provided on a time interval lasting 60 seconds (1 minute). 611 o the Calendar for "string-servicestatus": "is an array of 30 values 612 each provided on a time interval lasting 120 seconds (2 minutes). 614 4. ALTO Calendar specification: Service Information Resources 616 This section documents the individual information resources defined 617 to provide the calendared information services defined in this 618 document. 620 The reference time zone for the provided time values is UTC because 621 the option chosen to express the time format is the HTTP header 622 fields format specified in [RFC7231] where however timestamps are 623 still displayed with the acronym GMT: 625 Date: Tue, 15 Nov 2014 08:12:31 GMT 627 The value of a Calendar time interval size is expressed in seconds. 629 4.1. Calendar extensions for Filtered Cost Maps (FCM) 631 A legacy ALTO client requests and gets Filtered Cost Map responses as 632 specified in [RFC7285]. 634 4.1.1. Calendar extensions in Filtered Cost Map requests 636 The input parameters of a "legacy" request for a filtered cost map, 637 defined by object ReqFilteredCostMap in section 11.3.2 of [RFC7285], 638 are augmented with one additional member. 640 A Calendar-aware ALTO client requesting a Calendar on a given Cost 641 Type for a filtered cost map resource having Calendar capabilities 642 MUST add the following field to its input parameters: 644 JSONBoolean calendared<1..*>; 646 This field is an array of 1 to N boolean values, where N is the 647 number of requested metrics. Each entry corresponds to the requested 648 metric at the same array position. Each boolean value indicates 649 whether or not the ALTO Server should provide the values for this 650 Cost Type as a calendar. The array MUST contain exactly N boolean 651 values, otherwise the Server returns an error. 653 This field MUST NOT be included if no member "calendar-attributes" is 654 specified in this information resource. 656 If a value of field 'calendared' is 'true' for a cost type name for 657 which no calendar attributes have been specified: an ALTO Server, 658 whether it implements the extensions of this document or only 659 implements [RFC7285], MUST ignore it and return a response with a 660 single cost value as specified in [RFC7285]. 662 If this field is not present, it MUST be assumed to have only values 663 equal to 'false'. 665 A Calendar-aware ALTO client that supports requests for only one cost 666 type at a time and wants to request a Calendar MUST provide an array 667 of 1 element: 669 "calendared" : [true]; 671 A Calendar-aware ALTO client that supports requests for more than one 672 Cost Types at a time, as specified in [RFC8189] MUST provide an array 673 of N values set to 'true' or 'false', depending whether it wants the 674 applicable Cost Type values as a single or calendared value. 676 4.1.2. Calendar extensions in Filtered Cost Map responses 678 In a calendared ALTO Filtered Cost Map, a cost value between a source 679 and a destination is a JSON array of JSON values. An ALTO Calendar 680 values array has a number of values equal to the value of member 681 "number-of-intervals" of the Calendar attributes that are indicated 682 in the IRD. These attributes will be conveyed as metadata in the 683 Filtered Cost Map response. Each element of the array is valid for 684 the time-interval that matches its array position. 686 The FCM response conveys metadata among wich: 688 o some are not specific to Calendars and ensure compatibility with 689 [RFC7285] and [RFC8189] 691 o some are specific to Calendars. 693 The non Calendar specific "meta" fields of a calendared Filtered Cost 694 Map response MUST include at least: 696 o if the ALTO Client requests cost values for one Cost Type at a 697 time only: the "meta" fields specified in [RFC7285] for these 698 information service responses: 700 * "dependent-vtags ", 702 * "cost-type" field. 704 o if the ALTO Client implements the Multi-Cost ALTO extension 705 specified in [RFC8189] and requests cost values for several Cost 706 Types at a time: the "meta" fields specified in [RFC8189] for 707 these information service responses: 709 * "dependent-vtags ", 711 * "cost-type" field with value set to '{}', for backwards 712 compatibility with [RFC7285]. 714 * "multi-cost-types" field. 716 If the client request does not provide member "calendared" or if it 717 provides it with a value equal to 'false', for all the requested Cost 718 Types, then the ALTO Server response is exactly as specified in 719 [RFC7285] and [RFC8189]. 721 If the value of member "calendared" is equal to 'false' for a given 722 requested Cost Type, the ALTO Server MUST return, for this Cost Type, 723 a single cost value as specified in [RFC7285]. 725 If the value of member "calendared" is equal to 'true' for a given 726 requested Cost Type, the ALTO Server returns, for this Cost Type, a 727 cost value calendar as specified above in this section. In addition 728 to the above cited non Calendar specific "meta" members, the Server 729 MUST provide a Calendar specific metadata field. 731 The Calendar specific "meta" field that a calendared Filtered Cost 732 Map response MUST include is a member called "calendar-response- 733 attributes", that describes properties of the calendar and where: 735 o member "calendar-response-attributes" is an array of one or more 736 objects of type "CalendarResponseAttributes". 738 o each "CalendarResponseAttributes" object in the array is specified 739 for one or more Cost Types for which the value of member 740 "calendared" is equal to 'true' and for which a Calendar is 741 provided for the requested information resource. 743 o the "CalendarResponseAttributes" object that applies to a cost 744 type name has a corresponding "CalendarAttributes" object defined 745 for this cost type name in the IRD capabilities of the requested 746 information resource. The members of a 747 "CalendarResponseAttributes" object include all the members of the 748 corresponding "CalendarAttributes" object. 750 The format of member "CalendarResponseAttributes is defined as 751 follows: 753 CalendarResponseAttributes calendar-response-attributes <1..*>; 755 object{ 756 [JSONString cost-type-names <1..*>]; 757 JSONString calendar-start-time; 758 JSONNumber time-interval-size; 759 JSONNumber number-of-intervals; 760 [JSONNumber repeated;] 761 } CalendarResponseAttributes; 763 Object CalendarResponseAttributes has the following attributes: 765 o "cost-type-names": is an array of one or more cost-type-names to 766 which the capabilities apply and for which a Calendar has been 767 requested. The value of this member is a subset of the "cost- 768 type-names" array specified in the corresponding IRD Calendar 769 attributes. 771 o "calendar-start-time": indicates the date at which the first value 772 of the calendar applies. The value provided for the "calendar- 773 start-time" attribute SHOULD NOT be later than the request date. 775 o "time-interval-size": as specified in Section 3.1 and with the 776 same value. 778 o "number-of-intervals": as specified in Section 3.1 and with the 779 same value. 781 o "repeated": is an optional field provided for Calendars. It is an 782 integer N greater or equal to '1' that indicates how many 783 iterations of the calendar value array starting at the date 784 indicated by "calendar-start-time" have the same values. The 785 number N includes the provided iteration. 787 For example: suppose the "calendar-start-time" member has value "Mon, 788 30 Jun 2014 at 00:00:00 GMT", the "time-interval-size" member has 789 value '3600', the "number-of-intervals" member has value '24' and the 790 value of member "repeated" is equal to '4'. This means that the 791 calendar values are the same on Monday, Tuesday, Wednesday and 792 Thursday on a period of 24 hours starting at 00:00:00 GMT. The ALTO 793 Client thus may use the same calendar for the next 4 days starting at 794 "calendar-start-time" and will only need to request a new one for 795 Friday July 4th at 00:00:00 GMT. 797 Attribute "repeated" may take a very high value if a Calendar 798 represents a cyclic value pattern that the Server considers valid for 799 a long period and hence will only update once this period has elapsed 800 or if an unexpected event occurs on the network. In the latter case, 801 the client will be notified if it uses the "ALTO Incremental Updates 802 Using Server-Sent Events (SSE)" Service, specified in 803 [draft-ietf-alto-incr-update-sse]. See also discussion in Section 7 804 "Operational Considerations". 806 4.1.3. Use case and example: FCM with a bandwidth Calendar 808 An example of non-real time information that can be provisioned in a 809 'calendar' is the expected path throughput. While the transmission 810 rate can be measured in real time by end systems, the operator of a 811 data center is in the position of formulating preferences for given 812 paths, at given time periods for example to avoid traffic peaks due 813 to diurnal usage patterns. In this example, we assume that an ALTO 814 Client requests a calendar of network provider defined throughput 815 ratings, as specified in the IRD, to schedule its bulk data transfers 816 as described in the use cases. 818 In the example IRD, calendars for cost type name "num- 819 throughputrating" are available for the information resources: 820 "filtered-cost-calendar-map" and "endpoint-cost-calendar-map". The 821 ALTO Client requests a calendar for "num-throughputrating" via a POST 822 request for a filtered cost map. 824 We suppose in the present example that the ALTO Client sends its 825 request on Tuesday July 1st 2014 at 13:15 and, to calculate the 826 Content-Length in the server response, that the values for metric 827 "throughputrating" are encoded in 2 digits. The Server returns 828 Calendars with arrays of 12 numbers for each source and destination 829 pair. To lighten the text, the arrays in the provided example are 830 symbolized by expression "[v1,v2, ... v12]" that is otherwise not 831 valid in JSON. The same type of symbolization is used in the other 832 example Server responses. 834 POST /calendar/costmap/filtered HTTP/1.1 835 Host: alto.example.com 836 Content-Length: 218 837 Content-Type: application/alto-costmapfilter+json 838 Accept: application/alto-costmap+json,application/alto-error+json 840 { 841 "cost-type" : {"cost-mode" : "numerical", 842 "cost-metric" : "throughputrating"}, 843 "calendared" : [true], 844 "pids" : { 845 "srcs" : [ "PID1", "PID2" ], 846 "dsts" : [ "PID1", "PID2", "PID3" ] 847 } 848 } 850 HTTP/1.1 200 OK 851 Content-Length: 902 852 Content-Type: application/alto-costmap+json 854 { 855 "meta" : { 856 "dependent-vtags" : [ 857 {"resource-id": "my-default-network-map", 858 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 859 } 860 ], 861 "cost-type" : {"cost-mode" : "numerical", 862 "cost-metric" : "throughputrating"}, 863 "calendar-response-attributes" : [ 864 "calendar-start-time" : "Tue, 1 Jul 2014 13:00:00 GMT", 865 "time-interval-size" : 7200, 866 "number-of-intervals" : 12 867 ] 868 }, 869 "cost-map" : { 870 "PID1": { "PID1": [v1,v2, ... v12], 871 "PID2": [v1,v2, ... v12], 872 "PID3": [v1,v2, ... v12] }, 873 "PID2": { "PID1": [v1,v2, ... v12], 874 "PID2": [v1,v2, ... v12], 875 "PID3": [v1,v2, ... v12] } 876 } 877 } 879 4.2. Calendar extensions in the Endpoint Cost Service 881 This document extends the Endpoint Cost Service, as defined in 882 {11.5.1} of [RFC7285], by adding new input parameters and 883 capabilities, and by returning JSONArrays instead of JSONNumbers as 884 the cost values. The media type {11.5.1.1} and HTTP method 885 {11.5.1.2} are unchanged. 887 4.2.1. Calendar specific input in Endpoint Cost requests 889 The extensions to the requests for calendared Endpoint Cost Maps are 890 the same as for the Filtered Cost Map Service, specified in section 891 Section 4.1.1 of this draft. 893 The ReqEndpointCostMap object for a calendared ECM request will have 894 the following format: 896 object { 897 [CostType cost-type;] 898 [CostType multi-cost-types<1..*>;] 899 [JSONBoolean calendared<1..*>;] 900 EndpointFilter endpoints; 901 } ReqEndpointCostMap; 903 object { 904 [TypedEndpointAddr srcs<0..*>;] 905 [TypedEndpointAddr dsts<0..*>;] 906 } EndpointFilter; 908 4.2.2. Calendar attributes in the Endpoint Cost response 910 The "meta" field of a calendared Endpoint Cost response MUST include 911 at least: 913 o if the ALTO Client supports cost values for one Cost Type at a 914 time only: the "meta" fields specified in {11.5.1.6} of [RFC7285] 915 for the Endpoint Cost response: 917 * "cost-type" field. 919 o if the ALTO Client supports cost values for several Cost Types at 920 a time, as specified in [RFC8189] : the "meta" fields specified in 921 [RFC8189] for the the Endpoint Cost response: 923 * "cost-type" field with value set to '{}', for backwards 924 compatibility with [RFC7285]. 926 * "multi-cost-types" field. 928 If the client request does not provide member "calendared" or if it 929 provides it with a value equal to 'false', for all the requested Cost 930 Types, then the ALTO Server response is exactly as specified in 931 [RFC7285] and [RFC8189]. 933 If the ALTO client provides member "calendared" in the input 934 parameters with a value equal to 'true' for given requested Cost 935 Types, the "meta" member of a calendared Endpoint Cost response MUST 936 include, for these Cost Types, an additional member "calendar- 937 response-attributes", the contents of which obey the same rules as 938 for the Filtered Cost Map Service, specfied in Section 4.1.2. The 939 Server response is thus changed as follows, w.r.t [RFC7285] and 940 [RFC8189]: 942 o the "meta" member has one additional field 943 "CalendarResponseAttributes", as specified for the Filtered Cost 944 Map Service, 946 o the calendared costs are JSONArrays instead of JSONNumbers for the 947 legacy ALTO implementation. All arrays have a number of values 948 equal to 'number-of-intervals'. 950 If the value of member "calendared" is equal to 'false' for a given 951 requested Cost Type, the ALTO Server MUST return, for this Cost Type, 952 a single cost value as specified in [RFC7285]. 954 4.2.3. Use case and example: ECS with a routingcost Calendar 956 Let us assume an Application Client is located in an end system with 957 limited resources and having an access to the network that is either 958 intermittent or provides an acceptable quality in limited but 959 predictable time periods. Therefore, it needs to both schedule its 960 resources greedy networking activities and its ALTO transactions. 962 The Application Client has the choice to trade content or resources 963 with a set of Endpoints and needs to decide with which one it will 964 connect and at what time. For instance, the Endpoints are spread in 965 different time-zones, or have intermittent access. In this example, 966 the 'routingcost' is assumed to be time-varying, with values provided 967 as ALTO Calendars. 969 The ALTO Client associated with the Application Client queries an 970 ALTO Calendar on 'routingcost' and will get the Calendar covering the 971 24 hours time period "containing" the date and time of the ALTO 972 client request. 974 For Cost Type "num-routingcost", the solicited ALTO Server has 975 defined 3 different daily patterns each represented by a Calendar, to 976 cover the week of Monday June 30th at 00:00 to Sunday July 6th 23:59: 978 - C1 for Monday, Tuesday, Wednesday, Thursday, (week days) 980 - C2 for Saturday, Sunday, (week end) 982 - C3 for Friday (maintenance outage on July 4, 2014 from 02:00:00 GMT 983 to 04:00:00 GMT, or big holiday such as New Year evening). 985 In the following example, the ALTO Client sends its request on 986 Tuesday July 1st 2014 at 13:15. 988 To calculate the Content-Length in the server response, the 989 "routingcost" values are assumed to be encoded in 3 digits. 991 POST /calendar/endpointcost/lookup HTTP/1.1 992 Host: alto.example.com 993 Content-Length: 306 994 Content-Type: application/alto-endpointcostparams+json 995 Accept: application/alto-endpointcost+json,application/alto-error+json 997 { 998 "cost-type" : {"cost-mode" : "numerical", 999 "cost-metric" : "routingcost"}, 1000 "calendared" : [true], 1001 "endpoints" : { 1002 "srcs": [ "ipv4:192.0.2.2" ], 1003 "dsts": [ 1004 "ipv4:192.0.2.89", 1005 "ipv4:198.51.100.34", 1006 "ipv4:203.0.113.45", 1007 "ipv6:2001:db8::10" 1008 ] 1009 } 1010 } 1012 HTTP/1.1 200 OK 1013 Content-Length: 996 1014 Content-Type: application/alto-endpointcost+json 1016 { 1017 "meta" : { 1018 "cost-type" : {"cost-mode" : "numerical", 1019 "cost-metric" : "routingcost"}, 1020 "calendar-response-attributes" : [ 1021 {"calendar-start-time" : "Mon, 30 Jun 2014 00:00:00 GMT", 1022 "time-interval-size" : 3600, 1023 "number-of-intervals" : 24, 1024 "repeated": 4 1025 } 1026 ], 1027 }, 1028 "endpoint-cost-map" : { 1029 "ipv4:192.0.2.2": { 1030 "ipv4:192.0.2.89" : [v1, v2, ... v24], 1031 "ipv4:198.51.100.34" : [v1, v2, ... v24], 1032 "ipv4:203.0.113.45" : [v1, v2, ... v24], 1033 "ipv6:2001:db8::10" : [v1, v2, ... v24] 1034 } 1035 } 1036 } 1037 When the Client gets the Calendar for "routingcost", it sees that the 1038 "calendar-start-time" is Monday at 00h00 GMT and member "repeated" is 1039 equal to '4'. It understands that the provided values are valid 1040 until Thursday included and will only need to get a Calendar update 1041 on Friday. 1043 4.2.4. Use case and example: ECS with a multi-cost calendar for 1044 routingcost and owdelay 1046 In this example, it is assumed that the ALTO Server implements multi- 1047 cost capabilities, as specified in [RFC8189] . That is, an ALTO 1048 client can request and receive values for several cost types in one 1049 single transaction. An illustrating use case is a path selection 1050 done on the basis of 2 metrics: routing cost and owdelay. 1052 As in the previous example, the IRD indicates that the ALTO Server 1053 provides "routingcost" Calendars in terms of 24 time intervals of 1 1054 hour (3600 seconds) each. 1056 For metric "owdelay", the IRD indicates that the ALTO Server provides 1057 Calendars in terms of 12 time intervals values lasting each 5 minutes 1058 (300 seconds). 1060 In the following example transaction, the ALTO Client sends its 1061 request on Tuesday July 1st 2014 at 13:15. 1063 This example assumes that the values of metric "owdelay" are encoded 1064 in 3 digits. 1066 POST calendar/endpointcost/lookup HTTP/1.1 1067 Host: alto.example.com 1068 Content-Length: 391 1069 Content-Type: application/alto-endpointcostparams+json 1070 Accept: application/alto-endpointcost+json,application/alto-error+json 1072 { 1073 "cost-type" : {}, 1074 "multi-cost-types" : [ 1075 {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, 1076 {"cost-mode" : "numerical", "cost-metric" : "owdelay"} 1077 ], 1078 "calendared" : [true, true], 1079 "endpoints" : { 1080 "srcs": [ "ipv4:192.0.2.2" ], 1081 "dsts": [ 1082 "ipv4:192.0.2.89", 1083 "ipv4:198.51.100.34", 1084 "ipv4:203.0.113.45", 1085 "ipv6:2001:db8::10" 1086 ] 1087 } 1088 } 1090 HTTP/1.1 200 OK 1091 Content-Length: 1588 1092 Content-Type: application/alto-endpointcost+json 1094 { 1095 "meta" : { 1096 "multi-cost-types" : [ 1097 {"cost-mode" : "numerical", "cost-metric" : "routingcost"}, 1098 {"cost-mode" : "numerical", "cost-metric" : "owdelay"} 1099 ], 1100 "calendar-response-attributes" : [ 1101 {"cost-type-names" : "num-routingcost", 1102 "calendar-start-time" : "Mon, 30 Jun 2014 00:00:00 GMT", 1103 "time-interval-size" : 3600, 1104 "number-of-intervals" : 24, 1105 "repeated": 4 }, 1106 {"cost-type-names" : "num-owdelay" 1107 "calendar-start-time" : "Tue, 1 Jul 2014 13:00:00 GMT", 1108 "time-interval-size" : 300, 1109 "number-of-intervals" : 12} 1110 ], 1111 }, 1112 "endpoint-cost-map" : { 1113 "ipv4:192.0.2.2": { 1114 "ipv4:192.0.2.89" : [[r1, r2, ... r24], [o1, o2, ... o12]], 1115 "ipv4:198.51.100.34" : [[r1, r2, ... r24], [o1, o2, ... o12]], 1116 "ipv4:203.0.113.45" : [[r1, r2, ... r24], [o1, o2, ... o12]], 1117 "ipv6:2001:db8::10" : [[r1, r2, ... r24], 1118 [o1, o2, ... o12]] 1119 } 1120 } 1121 } 1123 When receiving the response, the client sees that the calendar values 1124 for 'routing cost' are repeated for 4 iterations. Therefore, in its 1125 next requests until the routing cost calendar is expected to change, 1126 the client will only need to request a calendar for "owdelay". 1128 Without the ALTO Calendar extensions, the ALTO client would have no 1129 clue on the dynamicity of the metric value change and would spend 1130 needless time requesting values at an inappropriate pace. In 1131 addition, without the Multi-Cost ALTO capabilities, the ALTO client 1132 would duplicate this waste of time as it would need to send one 1133 request per cost metric. 1135 5. IANA Considerations 1137 This document does not define any new media types or introduce any 1138 new IANA considerations. 1140 6. Security Considerations 1142 As an extension of the base ALTO protocol [RFC7285], this document 1143 fits into the architecture of the base protocol, and hence the 1144 Security Considerations (Section 15) of the base protocol fully apply 1145 when this extension is provided by an ALTO server. For example, the 1146 same authenticity and integrity considerations (Section 15.1 of 1147 [RFC7285] still fully apply; the same considerations for the privacy 1148 of ALTO users (Section 15.4 of [RFC7285]) also still fully apply. 1150 The calendaring information provided by this extension requires 1151 additional considerations on three security considerations discussed 1152 in the base protocol: potential undesirable guidance to clients 1153 (Section 15.2 of [RFC7285]), confidentiality of ALTO information 1154 (Section 15.2 of [RFC7285]), and availability of ALTO (Section 15.5 1155 of [RFC7285]). For example, by providing network information in the 1156 future in a calendar, this extension may improve availability of 1157 ALTO, when the ALTO server is unavailable but related information is 1158 already provided in the calendar. 1160 For confidentiality of ALTO information, an operator should be 1161 cognizant that this extension may introduce a new risk: an ALTO 1162 client may get information for future events that are scheduled 1163 through calendaring. Possessing such information, the client may use 1164 it to achieve its goal: (1) initiating connections only at 1165 advantageous network costs, leading to unexpected network load; (2) 1166 generating massive connections to the network at times where its load 1167 is expected to be high. 1169 To mitigate this risk, the operator should address the risk of ALTO 1170 information being leaked to malicious clients or third parties. As 1171 specified in Section 15.3.2 ("Protection Strategies") of [RFC7285], 1172 the ALTO server should authenticate ALTO clients and use the 1173 Transport Layer Security (TLS) protocol so that Man In The Middle 1174 (MITM) attacks to intercept an ALTO Calendar are not possible. 1175 [RFC7285] ensures the availability of such a solution in its 1176 Section 8.3.5. "Authentication and Encryption", which specifies 1177 that: "ALTO server implementations as well as ALTO client 1178 implementations MUST support the "https" URI scheme of [RFC2818] and 1179 Transport Layer Security (TLS) of [RFC5246]". 1181 [RFC8446] specifies TLS 1.3 and writes in its section 1: "While TLS 1182 1.3 is not directly compatible with previous versions, all versions 1183 of TLS incorporate a versioning mechanism which allows clients and 1184 servers to interoperably negotiate a common version if one is 1185 supported by both peers". So ALTO clients and servers MAY use newer 1186 versions (e.g., 1.3) of TLS as long as the negotiation process 1187 succeeds. To ensure backward compatibility with [RFC7285], it is 1188 RECOMMENDED for both Calendar-aware Clients and Servers to both 1189 support at least TLS 1.2, until it gets deprecated. 1191 To avoid malicious or erroneous guidance from ALTO information, an 1192 ALTO client should be cognizant that using calendaring information 1193 can have risks: (1) Calendar values, especially in "repeated" 1194 Calendars may be only statistical, and (2) future events may change. 1195 Hence, a more robust ALTO client should adapt and extend protection 1196 strategies specified in Section 15.2 of the base protocol: it should 1197 develop self check and also ensure information update, to reduce the 1198 impact of this risk. To address the risk of unexpected ALTO Values 1199 changes that the ALTO Client would be unaware of, it is RECOMMENDED 1200 that Servers supporting Calendars also support the "ALTO Incremental 1201 Updates Using Server-Sent Events (SSE)" Service, specified in 1202 [draft-ietf-alto-incr-update-sse]. Likewise, it is RECOMMENDED that 1203 Clients using Calendars also support the SSE Service. 1205 7. Operational Considerations 1207 Conveying ALTO Cost Calendars tends to reduce the on-the-wire data 1208 exchange volume compared to multiple single cost ALTO transactions, 1209 as an application has a set of time-dependent values upon which it 1210 can plan its connections in advance with no need for the ALTO Client 1211 to query information at each time. Additionally, the Calendar 1212 response attribute "repeated", when provided, saves additional data 1213 exchanges in that it indicates that the ALTO Client does not need to 1214 query Calendars during a period indicated by this attribute. 1215 Unexpected changes during this period can be handled by using the SSE 1216 Service as discussed in Section 6, if the Server and the Client 1217 support it. 1219 High resolution intervals may be needed when values change, sometimes 1220 during very small time intervals but in a significant manner. A way 1221 to avoid conveying too many entries is to leverage on the "repeated" 1222 feature. A server can smartly set the calendar start time and number 1223 of intervals so as to declare them "repeated" for a large number of 1224 periods, until the Calendar values change and are conveyed to 1225 requesting Clients. 1227 Clients and Servers supporting ALTO Calendars use [RFC8259]. 1228 [RFC7285] encodes its requests and responses using the JSON Data 1229 Interchange Format specified in [RFC7159]. The latter has been 1230 obsoleted by [RFC8259], that among others makes UTF-8 mandatory for 1231 text encoding to improve interoperability. Therefore, Clients and 1232 Servers implementations using UTF-{16,32} need to be cognizant of the 1233 subsequent interoperability risks and it is RECOMMENDED for them to 1234 switch to UTF-8 encoding. 1236 8. Acknowledgements 1238 The authors would like to thank Fred Baker, Li Geng, Diego Lopez, He 1239 Peng and Haibin Song for fruitful discussions and feedback on earlier 1240 draft versions. Dawn Chan, Kai Gao, Vijay Gurbani, Yichen Qian and 1241 Jensen Zhang provided substantial review feedback and suggestions to 1242 the protocol design. 1244 9. References 1246 9.1. Normative References 1248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1249 Requirement Levels", BCP 14, RFC 2119, 1250 DOI 10.17487/RFC2119, March 1997, 1251 . 1253 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1254 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1255 "Application-Layer Traffic Optimization (ALTO) Protocol", 1256 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1257 . 1259 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1260 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1261 May 2017, . 1263 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1264 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1265 DOI 10.17487/RFC8189, October 2017, 1266 . 1268 9.2. Informative References 1270 [draft-ietf-alto-incr-update-sse] 1271 W. Roome, Y. Yang, S. Chen, "ALTO Incremental Updates 1272 Using Server-Sent Events (SSE) (work in progress)", 1273 December 2018. 1275 [draft-ietf-alto-performance-metrics] 1276 Q. Wu, Y. Yang, Y. Lee, D. Dhody, S. Randriamasy, "ALTO 1277 Performance Cost Metrics (work in progress)", June 2018. 1279 [IEEE.754.2008] 1280 Institute of Electrical and Electronics Engineers, 1281 "Standard for Binary Floating-Point Arithmetic, IEEE 1282 Standard 754", August 2008. 1284 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1285 DOI 10.17487/RFC2818, May 2000, 1286 . 1288 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1289 (TLS) Protocol Version 1.2", RFC 5246, 1290 DOI 10.17487/RFC5246, August 2008, 1291 . 1293 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1294 Optimization (ALTO) Problem Statement", RFC 5693, 1295 DOI 10.17487/RFC5693, October 2009, 1296 . 1298 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1299 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1300 2014, . 1302 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1303 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1304 DOI 10.17487/RFC7231, June 2014, 1305 . 1307 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1308 Interchange Format", STD 90, RFC 8259, 1309 DOI 10.17487/RFC8259, December 2017, 1310 . 1312 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1313 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1314 . 1316 Authors' Addresses 1317 Sabine Randriamasy 1318 Nokia Bell Labs 1319 Route de Villejust 1320 NOZAY 91460 1321 FRANCE 1323 Email: Sabine.Randriamasy@nokia-bell-labs.com 1325 Richard Yang 1326 Yale University 1327 51 Prospect st 1328 New Haven, CT 06520 1329 USA 1331 Email: yry@cs.yale.edu 1333 Qin Wu 1334 Huawei 1335 101 Software Avenue, Yuhua District 1336 Nanjing, Jiangsu 210012 1337 China 1339 Email: sunseawq@huawei.com 1341 Lingli Deng 1342 China Mobile 1343 China 1345 Email: denglingli@chinamobile.com 1347 Nico Schwan 1348 Thales Deutschland 1349 Lorenzstrasse 10 1350 Stuttgart 70435 1351 Germany 1353 Email: nico.schwan@thalesgroup.com