idnits 2.17.1 draft-randriamasy-alto-cost-calendar-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 98 has weird spacing: '...alendar to...' -- The document date (July 4, 2014) is 3581 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TODO' is mentioned on line 958, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5693 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Randriamasy, Ed. 3 Internet-Draft Alcatel-Lucent Bell Labs 4 Intended status: Standards Track R. Yang 5 Expires: January 5, 2015 Yale University 6 Q. Wu 7 Huawei 8 L. Deng 9 China Mobile 10 N. Schwan 11 Thales Deutschland 12 July 4, 2014 14 ALTO Cost Calendar 15 draft-randriamasy-alto-cost-calendar-01 17 Abstract 19 The goal of Application-Layer Traffic Optimization (ALTO) is to 20 bridge the gap between network and applications by provisioning 21 network related information in order to allow applications to make 22 informed decisions. The present draft proposes to extend the cost 23 information provided by the ALTO protocol. The purpose is to broaden 24 the decision possibilities of applications to not only decide 'where' 25 to connect to, but also 'when'. This is useful to applications that 26 have a degree of freedom on when to schedule data transfers, such as 27 non- instantaneous data replication between data centers or service 28 provisioning to end systems with irregular connectivity. ALTO 29 guidance to schedule application traffic can also efficiently help 30 for load balancing and resources efficiency. 32 The draft specifies a new Cost Mode, "Calendar" Mode, that is 33 applicable to time-sensitive ALTO metrics and allows Applications to 34 carefully schedule their connections or data transfers. In the 35 Calendar Mode, an ALTO Server exposes ALTO Cost Values in JSON arrays 36 where each value corresponds to a given time interval. The time 37 intervals as well as other Calendar attributes are specified in the 38 IRD. Besides the functional time-shift enhancement the ALTO Cost 39 Calendar also allows to schedule the ALTO requests themselves and 40 thus save a number of ALTO transactions. 42 Requirements Language 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at http://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on January 5, 2015. 65 Copyright Notice 67 Copyright (c) 2014 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 2. Motivating use cases for ALTO Cost Schedule . . . . . . . . . 4 84 2.1. Bulk Data Transfer scheduling . . . . . . . . . . . . . . 5 85 2.2. Endsystems with limited connectivity or access to 86 datacenters . . . . . . . . . . . . . . . . . . . . . . . 6 87 2.3. SDN Controller guided access to application endpoints . . 7 88 2.4. Large flow scheduling on extended ALTO topologies . . . . 8 89 2.5. Time-sensitve TE metrics Calendaring . . . . . . . . . . 9 90 3. Design considerations for an ALTO calendar . . . . . . . . . 10 91 3.1. Purpose of an ALTO calendar . . . . . . . . . . . . . . . 11 92 3.2. Design requirements for an ALTO calendar . . . . . . . . 12 93 4. ALTO extensions for a Cost Calendar . . . . . . . . . . . . . 13 94 4.1. ALTO Cost-Mode: Calendar . . . . . . . . . . . . . . . . 13 95 4.2. ALTO Calendar attributes in the IRD . . . . . . . . . . . 14 96 4.3. Example of calendared information resources in the IRD . 16 97 4.3.1. Example IRD with ALTO cost Calendars . . . . . . . . 17 98 4.3.2. Example transaction for a routingcost Calendar to 99 face intermittent connectivity . . . . . . . . . . . 19 100 4.3.3. Example transaction for a bandwidth calendar . . . . 20 101 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 102 5.1. Information for IANA on proposed Cost Types . . . . . . . 22 103 5.2. Information for IANA on proposed Endpoint Propeeries . . 22 104 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 105 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 107 7.2. Informative References . . . . . . . . . . . . . . . . . 22 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 110 1. Introduction 112 IETF is currently standardizing the ALTO protocol which aims for 113 providing guidance to overlay applications, that need to select one 114 or several hosts from a set of candidates that are able to provide a 115 desired resource. This guidance is based on parameters that affect 116 performance and efficiency of the data transmission between the 117 hosts, e.g., the topological distance. The goal of ALTO is to 118 improve the Quality of Experience (QoE) in the application while 119 simultaneously optimizing resource usage in the underlying network 120 infrastructure. 122 The ALTO protocol therefore [ID-alto-protocol] specifies a Network 123 Map, which defines groupings of endpoints in a network region (called 124 a PID) as seen by the ALTO server. The Endpoint Cost Service and the 125 Endpoint (EP) Ranking Service then provide rankings for connections 126 between the specified network regions and thus incentives for 127 application clients to connect to ISP preferred endpoints, e.g. to 128 reduce costs imposed to the network provider. Thereby ALTO 129 intentionally avoids the provisioning of realtime information as 130 explained in the ALTO Problem Statement [RFC5693] and ALTO 131 Requirements [RFC5693]) drafts that write "Such information is better 132 suited to be transferred through an in-band technique at the 133 transport layer instead". Thus the current Cost Map and Endpoint 134 Cost Service are providing, for a given Cost Type, exactly one rating 135 per link between two PIDs or to an Endpoint. Applications are 136 expected to query one of these two services in order to retrieve the 137 currently valid cost values. They therefore need to plan their ALTO 138 information requests according to the estimated frequency of cost 139 value change. In case these value changes are predicable over a 140 certain period of time and the application does not require immediate 141 data transfer, it would save time to get the whole set of cost values 142 over the period in one ALTO response and using these values to 143 schedule data transfers would allow to optimise the network resources 144 usage and QoE. 146 In this draft we introduce use cases that describe applications that 147 have a degree of freedom on scheduling data transfers over a period 148 of time, thus they do not need to start a transfer instantaneously on 149 a retrieved request. For this kind of applications we propose to 150 extend the Cost Map and Endpoint Cost Services by adding a calendar 151 on the cost values, allowing applications to time-shift data 152 transfers. 154 In addition to this functional ALTO enhancement, we expect to further 155 gain by gathering multiple Cost Values for one cost type as firstly 156 one Cost Map reporting on N Cost Values is less bulky than N Cost 157 Maps containing one Cost value each and secondly, this reduces N ALTO 158 transactions to a single one. This is valuable for both the storage 159 of these ALTO maps and their transfer. Similar gains can be obtained 160 for the ALTO Endpoint Cost Service. 162 In this draft an "ALTO Calendar" is presented as a Cost Mode that is 163 applicable to time-sensitive ALTO metrics and allows applications 164 using such metrics to carefully schedule their connections or data 165 transfers. In the Calendar Mode, an ALTO Server exposes ALTO Cost 166 Values in JSON arrays where each value corresponds to a given time 167 interval. The time intervals as well as other Calendar attributes 168 (the ones suggested by Richard) are specified in the IRD and allow 169 the ALTO Client to interpret the received ALTO values. This draft 170 proposes a set of Calendar attributes to be added to the IRD, for 171 discussion I n the ALTO WG. 173 The remainder of this draft first provides a variety of use cases 174 that motivate the need for a 'calendar' cost mode. It then specifies 175 the needed extensions to the ALTO protocol and details some example 176 messages. 178 2. Motivating use cases for ALTO Cost Schedule 180 This section introduces use cases showing the benefits of providing 181 ALTO Cost values in 'calendar' mode. Most likely, the ALTO Cost 182 Calendar would be used for the Endpoint Cost Service, assuming that a 183 limited set of feasible Endpoints for a non-real time application is 184 already identified, that they do not need to be accessed immediately 185 and that their access can be scheduled within a given time period. 186 The Cost Map service, filtered or not, is also applicable as long as 187 the size of the Map is manageable. 189 Last, the ALTO Cost calendar is beneficial to optimizing ALTO 190 transactions themselves. Indeed, let us assume that an Application 191 Client is located in an end sytem with limited resources and/or has 192 an access to the network that is either intermittent or provides an 193 acceptable QoE in limited but predictable time periods. In that 194 case, it needs to both schedule its resources demanding networking 195 activities and its ALTO requests. Instead of having to figure out 196 when the cost values may change and having to carefully schedule 197 multiple ALTO requests, it could aviod this by relying on Cost 198 Shedule attributes that indicate the time granularity, the validity 199 and time scope of the cost information, together with the time 200 related cost values themselves. 202 2.1. Bulk Data Transfer scheduling 204 Large Internet Content Providers (ICPs) like Facebook or YouTube, as 205 well as CDNs rely on data replication across multiple sites to 206 offload the core site and increase user experience through shorter 207 latency from a local site. Typically the usage pattern of these data 208 centers or caches follows a location dependent diurnal pattern. 210 In the examples above, data needs to be replicated across the various 211 locations of a Internet Content Provider (ICP), leading to bulk data 212 transfers between datacenters on a diurnal pattern. 214 In the mean time, there is a degree of freedom on when the content is 215 transmitted from the origin server to the caching node, or from the 216 core site to a local site. However, scheduling these data transfers 217 is a non-trivial task as the transfer should not infer with the user 218 peak demand to avoid degradation of user experience and to decrease 219 billing costs for the datacenter operator by leveraging off-peak 220 hours for the transfer. This peak demand typically follows a diurnal 221 pattern according to the geographic region of the datacenter. 223 As a result, it would be very helpful to let these ICPs to have a 224 good knowledge about the link utilization patterns between the 225 different datacenters from the networks before making a more 226 intelligent scheduling decision. While this usage data today already 227 is gathered and also used for the scheduling of data transfer, 228 provisioning this data gets increasingly complex with the number of 229 CDN nodes and in particular the number of datacenter operators that 230 are involved. For example, privacy concerns prevent that this kind 231 of data is shared across administrative domains. The ALTO Cost 232 Calendar specified later in this document avoids this problem by 233 presenting an abstracted view of time sensitive utilization maps 234 through a dedicated ALTO service to allow ICPs a coherent scheduling 235 of such data transfers across administrative domains. 237 2.2. Endsystems with limited connectivity or access to datacenters 239 Another use case that benefits from the availability of multi- 240 timeframe cost information is based on applications that are limited 241 by their connectivity either in time or resources or both. For 242 example applications running on devices in remote locations or in 243 developing countries that need to synchronize their state with a data 244 center periodically, in particular if sometimes there is no 245 connection at all. Example applications is enterprise database 246 update, remote learning, remote computation distributed on several 247 data center endpoints. 249 Wireless connections have a variable quality and may even be 250 intermittent. On the other hand, the wireless network conditions are 251 often predicable and have a rapid impact on applications. Non real 252 time applications and time-insensitive data transfers such as client 253 patching, archive syncing, etc. can benefit from careful scheduling. 254 It is thus desirable to provide ALTO clients with routing costs to 255 connection nodes (i.e. Application Endpoints) over different time 256 periods. This would allow end systems using ALTO aware application 257 clients to schedule their connections to application endpoints. 259 Another challenge arises with end systems using resources located in 260 datacenters and trading content and resources scattered around the 261 world. For non-real time applications, the interaction with 262 Endpoints can be scheduled at the time slots corresponding to the 263 best possible network conditions in order to improve the QoE. For 264 instance, resource Ra downloaded from Endpoint EPa at time t1, 265 Resource Rb uploaded to EPb at time t2, some batch computation 266 involving Ra and Rb done on EPc at time t3 and results R(A,B) 267 downloaded to EPd and EPe at time t4. Example applications are 268 similar to the ones cited in the previous paragraph. 270 +-----+ +-----+ 271 | EPa | | EPb | <----- Rb 272 +-----+ +-----+ (t2=50) 273 | +-------+ | 274 Ra --------------> | EPc | | 275 (time t1=10) | | | 276 |t3=100 | <----------------- Rb 277 +-------+ 278 | \ 279 | \ 280 R(Ra,Rb) 281 (t4=200) 282 | \ 283 | -------------------. 284 V V 285 +-----+ +-----+ 286 | EPd | | EPe | 287 +-----+ +-----+ 289 2.3. SDN Controller guided access to application endpoints 291 The Software Defined Networking (SDN), see [sdnrg], is a model that 292 attempts to manage and reconfigure networks in a more flexible way in 293 order to better cope with the traffic challenges posed by nowadays 294 resources greedy applications. To this end, one option is "moving 295 the control plane out of the network elements into "controllers", see 296 [SDN charter, http://www.1-4-5.net/~dmm/sdnrg/sdnrg.html], that 297 implements the network control and management. The SDN Controllers 298 are deemed to gather the network state information and provide it in 299 an abstracted form to SDN aware applications while gathering their 300 requirements in QoE and exchanging other application "management" 301 information and commands. 303 The relevance of ALTO to perform a number of SDN functions has been 304 recently highlighted. An ALTO Server can assist an SDN Controller by 305 hosting abstracted network information that can be provided to SDN 306 aware applications via an ALTO Client. It can also assist other SDN 307 Control operations using information in and outside the ALTO scope. 309 The SDN primitive "Get network resources" provides applications with 310 informations allowing them to evaluate the expected QoE. QoE related 311 information includes delay and bandwidth at the application endpoints 312 as well as on the network paths. Such information may be provided 313 via the ALTO Service by proposed extensions of the ALTO protocol that 314 define new ALTO Cost Types allowing to abstract and report QoE to 315 applications. 317 One key objective of an SDN controller is the ability to balance the 318 application traffic whenever possible. For non real time 319 applications, data and resources transfer can be time shifted, 320 resources availability may often be predicable and last, strong 321 incentives for applications to time shift their traffic may be given 322 by network operators appropriately setting routing cost values at 323 different time values, according to their policy to cope with network 324 occupation over time. 326 To achieve this objective, the SDN controller can: 328 1. get the network state history from its controlled network 329 elements through its southbound API 331 2. possibly derive an estimation or a prediction of these values 332 over given time frames 334 3. compute estimates and/or network provider preferences on end to 335 end paths and store their abstraction in an ALTO Server in the 336 form of ALTO Cost Calendar values defined for different time 337 periods 339 4. deliver these values to the SDN applications via the ALTO 340 Endpoint Cost Service, as estimations covering the past and/or 341 the future and/or preferences. 343 This way: 345 o On one hand, the applications get the best possible QoE, as they 346 can pick the best time for them to access one or more Endpoints, 348 o One the other hand the SDN controller achieves load balancing as 349 it may guide the application traffic so as to better distribute 350 the traffic over time, and thus optimize its resources usage. 352 2.4. Large flow scheduling on extended ALTO topologies 354 [draft-yang-alto-topology-00] presents initial thinking on extending 355 ALTO for topology exposure services, that would provide flexible 356 abstractions based on the raw network topology. Among other 357 features, an ALTO topology may expose several paths between a source 358 (src) and destination (dst), or topology details may be provided on 359 restricted parts. This work was presented to the ALTO WG at IETF88. 361 The presentation slides [slides-88-alto-5-topology] on 362 [draft-yang-alto-topology-00] expose a use case entitled "Large Flow 363 Scheduling". This case includes a "daylife example" where a Google 364 Map service proposes multiple routes between 2 points A and B, each 365 calculated w.r.t. length and estimated time. For each of these 366 selected paths, the map service exposes a time-sensitive qualitative 367 value taking 4 values between Slow and Fast. A user of this 368 application may thus organize its transfer w.r.t. metrics, paths and 369 time, provided s/he does not have to commute immediately. 371 The use case on Large flow scheduling on extended ALTO topologies in 372 the present section illustrates one modality of ALTO topology 373 service, that would expose several paths between end to end (src, 374 dst) pairs, computed w.r.t. one of more metrics, possibly under given 375 constraints. On top of this enriched topology service, non real-time 376 applications may also choose the time of data/resources transfer, 377 taking thus advantage of a richer set of decision variables. 379 The use case "Large Flow Scheduling" of presentation 380 [slides-88-alto-5-topology]can thus be adapted as follows: 382 o Step1 - obtain the set T transfer tasks {(src, dest, data)} 384 o Step2 - identify one or more paths for each (src, dst): several 385 information sources exist among which: 387 * (a) ALTO CostMap with a "path" metric, // not specified here 389 * (b) an ALTO Topology Service providing a path computation hint 390 (e.g. w.r.t. routingcost and/or other metrics) 392 o Step 3 - while T not empty: 394 * 1 - query for example values for some metric 'available 395 bandwidth' on paths: 397 + to this end, query the values in the ALTO 'calendar' Mode: 398 on the selected (src, dst) for a set of time intervals. 399 With this mode, the ALTO client will receive an array of 400 values, each applicable to a time slot . 402 * 2 - schedule data transfer at the time slots corresponding to 403 the preferred value. 405 2.5. Time-sensitve TE metrics Calendaring 407 Draft [draft-wu-alto-te-metrics] , proposes to extend the set of ALTO 408 metrics with 11 ALTO traffic engineering (TE) metrics to reflect 409 measurement on network delay, jitter, packet loss, hop count, and 410 bandwidth. ALTO TE metrics that are time-sensitive, either by nature 411 such as bandwidth and delay related metrics, or due to "normally" 412 changing network conditions or both. 414 The values of ALTO TE metrics are typically collected from routing 415 protocols and provided in a non-real time manner. In "normally" 416 changing network conditions, TE metric values remain uniformly 417 distributed over given time intervals and can be aggregated over 418 bigger time intervals of periodic patterns. For example, an ALTO 419 Server may collect values for e.g. delay from a routing protocol 420 produced by measurements done every second over a measurement period 421 of 30 seconds. The ALTO Server may then aggregate these values over 422 two measurement periods (i.e. 60 seconds) and repeat the operation as 423 it wishes. Then every hour, the ALTO Server provides these delay 424 values in 'calendar' mode, encoded as an array of 60 values, assumed 425 to estimate network performance statistics on each minute of this 426 hour. 428 Another example is Bandwidth Calendaring. Bandwidth Calendaring 429 allows network operators to reserve resources in advance according to 430 agreements with their customers, enabling them to transmit data with 431 specified starting time and duration, for example, for a scheduled 432 bulk data replication between data centers. Traditionally, this can 433 be supported by a Network Management System operation such as path 434 pre-establishment and activation on the agreed starting time. 435 However, this does not provide efficient network usage since the 436 established paths exclude the possibility of being used by other 437 services even when they are not used for undertaking any service. 439 A Cost calendar provided by an ALTO server can support the scheduled 440 bulk data replication application with better efficiency since it can 441 alleviate the burden of processing on network elements. This 442 requires the ALTO server to maintain the calendared TE cost metrics 443 on the end to end paths associated to data transfer. 445 To support cost calendaring for these time-sensitive ALTO TE metrics, 446 the network topology and the dynamicity of the traffic need to be 447 considered. For example, a small topology with low density and low 448 capacity that carries inpredictable, heavy and bursty traffic has few 449 chances to exhibit stationary TE metric value patterns over large 450 periods and would benefit to use the ALTO Calendar over smaller time 451 slots. Some ALTO TE metric values, even aggregated over time may 452 need to be updated at a frequency that would require doing ALTO 453 request at a pace that would be overload both the ALTO Client and the 454 Server. 456 3. Design considerations for an ALTO calendar 458 This section enumerates a set of challenges in designing the 459 calendaring specifications, and will be updated upon discussions in 460 the ALTO WG. 462 An ALTO Cost calendar provided by the ALTO Server is an array of 463 values for a given metric, where each value corresponds to a time 464 interval which length is specified for this metric in the IRD, 465 together with other attributes describing the time scope of the 466 calendar. Most likely, the ALTO Cost Calendar would be used for the 467 Endpoint Cost Service, assuming that a limited set of feasible 468 Endpoints for a non-real time application is already identified, that 469 they do not need to be accessed immediately and that their access can 470 be scheduled within a given time period. The Cost Map service, 471 filtered or not, is also applicable as long as the size of the Map is 472 manageable. 474 3.1. Purpose of an ALTO calendar 476 A calendar is used to schedule transfers of application data or 477 services and has several characteristics: 479 o the Calendar values are assumed to be stationary on each time 480 interval, 482 o the ALTO Server may provide values on past time periods that can 483 be interpreted as historical experience and used to anticipate 484 future cost values, 486 o the ALTO Server may provide stationary values on present or future 487 time periods that can be interpreted as predictions on cost 488 values, 490 o the ALTO Server may provide stationary values on time intervals 491 covering the past, and/or present and/or future. 493 o for metrics provided with units and claiming to be aggregated from 494 network measurements, the values can be interpreted as 495 estimations. 497 o For abstracted metrics provided with no units such as the 498 'routingcost' defined in the base ALTO protocol or abstracted 499 unitless scores on network performances such as some potential 500 'bandwidth score' or 'unreliability cost', the values can be 501 interpreted as network provider preferences. 503 Note that we distinguish between "estimates" that we see as value 504 aggregations represented with units such as bytes, seconds, 505 percentage and "preferences" that we see as abstracted costs or 506 scores w.r.t. a metric or state such as 'routingcost', 507 'bandwidthscore', 'link quality'. 509 The method used to generate the estimation and aggregation of 510 measured values is currently outside the scope of this draft and 511 expected to be documented in the applicable metric definition 512 document. 514 3.2. Design requirements for an ALTO calendar 516 TO BE COMPLETED IN FURTHER DRAFT VERSIONS 518 An ALTO Calendar can be seen as a cyclic value array pattern that is 519 valid for a certain time period with specified beginning date, 520 duration and number of time intervals. 522 o needs to convey cyclic network provider preferences expressed 523 w.r.t. given ALTO metric values (e.g., hourly, daily, weekly 524 measurement/prediction) 526 o needs to convey cyclic network status if the ALTO Server claims to 527 provide aggregated information on network status (e.g., hourly, 528 daily, weekly measurement/prediction) 530 o needs to be able to convey the result of a particular instance of 531 time (e.g., to convey predicted network status during a 532 maintenance outage on July 4, 2014 from 5-7pm) 534 o needs at least the following attributes to report on cyclic 535 patterns: 537 * generic time zone, 539 * applicable time interval for each calendar value (measurement 540 estimation with units or unitless preference value) : combining 541 and to reflect for example: 542 1hour, 2minutes, 1week, 1month 544 * date range of the Calendar, e.g. number of intervals allowing 545 to derive the calendar time range in terms of: year, month, 546 week, day, hour, min, secs 548 o needs to expose validity period of the calendar: indicating when 549 the next ALTO Calendar for this date range should be fetched if 550 needed, 552 o needs to provide time stamps: 554 * last-update-time: specifying when the metric values were last 555 computed , 557 * next-update-time: specifying when the calendar values will be 558 re-computed, indicating thus when an ALTO client should fetch 559 an update if it uses a Calendar. 561 * calendar-start-date: specifying when the current already 562 computed calendar starts, 564 * next-calendar-start-date: specifying when the already computed 565 calendar will have different values, indicating thus that the 566 ALTO client should fetch the next pre-computed calendar 568 It may be useful to keep a cyclic network status with date, in case 569 of exceptional predicted events such as New Year evening on a Tuesday 570 or any worldwide event generating a lot of traffic.Traffic calendars 571 may be particularly useful in such cases. 573 4. ALTO extensions for a Cost Calendar 575 The usage of a time-related ALTO Cost Calendar is rather proactive in 576 that it can be used like a "time table" to figure out the best time 577 to schedule data transfer and also anticipate predictable events 578 including predictable flash crowds. An ALTO Cost Calendar should be 579 viewed as a synthetic abstraction of real measurements that can be 580 historic or be a prediction for upcoming time periods. 582 Specifications on the cost "calendar" attributes are proposed here 583 and will be completed in further versions of this draft, upon 584 discussion with the ALTO WG. 586 The format of ALTO requests and responses will be specified in 587 further versions of this draft, as in particular it may be necessary 588 that the ALTO response indicates the computation and validity dates 589 of the provided ALTO Calendar. 591 4.1. ALTO Cost-Mode: Calendar 593 This draft introduces a new ALTO Cost Mode called "calendar". This 594 mode applies preferably to Costs that can be expressed in a single- 595 valued Cost Mode. In that sense, when the "numerical" mode is 596 available for a Cost-Type, the cost expressed in the "calendar" mode 597 is an extension of its expression from one value in the "numerical" 598 mode to an array of several values varying over time. 600 Types of Cost values such as JSONBool can also be expressed in the 601 "calendar" mode, as states may be "true" or "false" depending on 602 given time periods. They may be expressed as a single value which is 603 either "true" or "false" following a decision rule outside the ALTO 604 protocol. 606 4.2. ALTO Calendar attributes in the IRD 608 To ensure that the application client understands the provided 609 information in the cost calendar in an unambiguous way, we specify 610 the Calendar attributes in the ALTO IRD "meta" information, that 611 defines the time scope of the "calendared" cost values. The 612 reference time zone for the provided values is UTC. 614 o interval-unit: 616 * expresses the unit in which the duration of an ALTO calendar 617 time interval duration is expressed. The time unit, ranges 618 from "second" to "year". 620 o nb-int-units: 622 * the number of time units per interval. For example: interval- 623 unit=minute and nb-int-units=5 means that each calendar value 624 is provided on a time interval that lasts 5 minutes. 626 o calendar-start-date: 628 * the date corresponding to the first value in the array, 629 expressed with a 2 to 4 digits sequence 'mn/hh/dd/mo/yyyy' to 630 be interpreted as minute/hour/day/month/year 632 o next-start-date: SHOULD BE RENAMED "next-calendar-start-date" 634 * 'mn/hh/dd/mo/yyyy', the starting date of the next calendar. to 635 limit the number of provided calendars and schedule the next 636 ALTO Calendar query. For example, a daily calendar may have 637 the same values for the next 3 days. So the ALTO Client does 638 not need to fetch one every day. 640 o nb-intervals: 642 * the integer number of values of the cost calendar array, at 643 least equal to 1. 645 o calendar-time-zone: 647 * set to "UTC+hhmm", with hhmn quantifying the UTC time shift 648 where hh designates the hour and mn the minutes. 650 o 651 * next-calendar-update: the next date 'mn/hh/dd/mo/yyyy' at which 652 the ALTO Calendar values will be updated in the ALTO Server. 653 Must be later than 'next-start-date' 655 o last-calendar-update: 657 * the last date 'mn/hh/dd/mo/yyyy' at which ALTO Calendar values 658 were updated in the ALTO Server. Must be sooner than 659 'calendar-start-date'. 661 NOTES: 663 - another option to express the date format is tu use HTTP header 664 fields formats such as: 666 Date: Tue, 15 Nov 1994 08:12:31 GMT 668 - If the 'calendar-start-date' date is past, the application can also 669 use the information to compute statistics on values provided by ALTO 670 over time to guide applications. Besides some customized prediction 671 the ALTO Client may guess their reliability w.r.t. some measured QoE. 673 - The attributes 'last-calendar-update' and 'next-calendar-update' 674 reflect the update frequency and age of the ALTO Calendar 675 information. The difference between these two dates is not 676 necessarily constant. The ALTO Client should just consider that the 677 ALTO Server does not find it necessary to update the Calendar values 678 between these two dates. The ALTO Client may thus assume that the 679 ALTO Server considers the values as valid or stationary during this 680 period. 682 - Attribute 'next-start-date' is different and reflects the duration 683 of the provided calendar. For example an ALTO Server may provide a 684 calendar for ALTO values changing every 5 minutes. Each calendar is 685 "1 hour" long and thus has 12 values. The ALTO Server may decide to 686 update the 24 hourly calendars day. Note also that in this example, 687 a 5 minutes interval may cover the aggregation of real TE 688 measurements done every 30 seconds, but this latter aspect is outside 689 the scope of this draft as it is to be specified in the definition of 690 the ALTO metric. 692 - Attributes 'last-calendar-update' and 'next-calendar-update' 693 indicate when the calendar values are computed and available to the 694 ALTO Client. 696 - Attributes 'calendar-start-date' and 'next-start-date' indicate 697 when an already computed calendar has different values. 699 4.3. Example of calendared information resources in the IRD 701 This section describes an example IRD and related ALTO calendar 702 transaction in a scenario where an ALTO Server offers the Calendar 703 mode for several Cost Types that are either specified in the base 704 ALTO protocol, proposed in other drafts see 705 [draft-wu-alto-te-metrics] or suggested here as examples, like a cost 706 metric reporting on measured packet loss and called 'TEpktloss. The 707 provided example transactions are based on the use cases of section 708 2. 710 These examples describe situations where a client has the choice of 711 trading content or resources with several Endpoints and needs to 712 decide with which Endpoint it will trade and at what time. For 713 instance, one may assume that the Endpoints are spread over different 714 time-zones, or have intermittent access. The ALTO Calendar mode 715 specified below allows these clients to retrieve Endpoint cost maps 716 valid for a certain timeframe (e.g. 24 hours), and get a set of 717 values, each applicable on a (e.g. hourly) slot. Thus the 718 application can optimize the needed data transfer according to this 719 information. 721 In the scenario of the present draft, the available Endpoint Costs 722 metrics are: "routingcost", "AShopcount", 'TEpktloss' and 723 'Availbandwidth'. "routingcost" and "AShopcount" are available in the 724 "numerical" Cost Mode and 'TEpktloss' , 'Availbandwidth' and 725 "routingcost" as well are available in the "calendar" Cost Mode. 727 Last, we suppose that the ALTO Client GETs the IRD on Tuesday July 728 1st 2014 at 13:15 . 730 o The Calendar for 'TEpktloss'': an hourly pattern that consists of 731 12 values provided each on a time interval of 5 minutes, provided 732 on a per hour basis, and updated every day at midnight UTC+4. The 733 calendar is updated everyday at midnight. 735 o The Calendar for 'Availbandwidth': a daily pattern that consists 736 of 12 values. It is computed every day and updated at 0h00, for 737 24 hours, on time intervals lasting 2 hours, with the first 738 interval starting at 0h00. This information is then used to 739 enable applications to see which time intervals in a day are the 740 most favorable to operate, and which "busy " time intervals should 741 be avoided. 743 o The Calendar for 'routingcost': a daily pattern that consists of 744 an array of 24 time intervals lasting each 1 hour. The 745 routingcost calendar covers a 1 day period, starting at midnight. 746 It is updated every week on sunday. An ALTO Client can thus store 747 and use the needed routingcost calendars for maximum 1 week. This 748 may be applicable for networks with poor or intermittent 749 connectivity where the operator may integrate monetary as well as 750 network performance metrics in the provided 'routingcost' values. 752 4.3.1. Example IRD with ALTO cost Calendars 754 The example IRD given in this section includes 2 particular URIs: 756 o "http://alto.example.com/endpointcost/lookup", in which the ALTO 757 Server offers the numerical mode for metrics "routingcost" and 758 "AShopcount". 760 o "http://alto.example.com/endpointcost/calendar/lookup", in which 761 the ALTO Server provides "calendar" mode for metrics 'TEpktloss' 762 and 'Availbandwidth' and 'routingcost'. 764 For Cost Type 'calendar-routing', this example assumes that the ALTO 765 Server has defined 3 different daily patterns each represented by a 766 Calendar, to cover the week of Monday June 30th at 00:00 to Sunday 767 July 6th 23:59 : 769 - C1 for Monday, Tuesday, Wednesday, Thursday, (week days) 771 - C2 for Saturday, Sunday, (week end) 773 - C3 for Friday (maintenance outage on July 4, 2014 from 5-7pm) 775 Attributes 'calendar-start-date' and 'next-start-date' allow an ALTO 776 client to fetch 3 Calendars instead of 7 and thus to reduce the 777 volume of on-the-wire data exchange. 779 GET /directory HTTP/1.1 780 Host: alto.example.com 781 Accept: application/alto-directory+json,application/alto-error+json 783 HTTP/1.1 200 OK 784 Content-Length: [TODO] 785 Content-Type: application/alto-directory+json 787 { 788 "meta" : { 789 "cost-types": { 790 "num-routingcost": { 791 "cost-mode" : "numerical", 792 "cost-metric" : "routingcost" 793 }, 795 "num-AShopcount": { 796 "cost-mode" : "numerical", 797 "cost-metric" : "hopcount" 798 }, 799 "calendar-TEpktloss": { 800 "cost-mode" : "calendar", 801 "cost-metric": "TEpktloss", 802 "description": { 803 "interval-unit" : "minute", 804 "nb-int-units" : 5, 805 "calendar-start-date" : 00/13/01/07/2014, 806 "nb-intervals" : 12, 807 "calendar-time-zone" : UTC+4, 808 "next-start-date" : 00/14/01/07/2014, 809 "last-calendar-update" : 00/00/01/07/2014, 810 "next-calendar-update" : 00/00/02/07/2014 811 } 812 }, 813 "calendar-bw": { 814 "cost-mode" : "calendar", 815 "cost-metric": "Availbandwidth", 816 "description": { 817 "interval-unit" : "hour", 818 "nb-int-units" : 2, 819 "calendar-start-date" : 00/00/01/07/2014, 820 "nb-intervals" : 12, 821 "calendar-time-zone" : UTC+4, 822 "next-start-date" : 00/00/02/07/2014, 823 "last-calendar-update" : 23/59/29/06/2014, 824 "next-calendar-update" : 23/59/06/07/2014 825 } 826 }, 827 "calendar-routing": { 828 "cost-mode" : "calendar", 829 "cost-metric": "routingcost", 830 "description": { 831 "interval-unit" : "hour", 832 "nb-int-units" : 1, 833 "calendar-start-date" : 00/00/01/07/2014, 834 "nb-intervals" : 24, 835 "calendar-time-zone" : UTC+4, 836 "next-start-date" : 00/00/04/07/2014, 837 "last-calendar-update" : 00/00/29/06/2014, 838 "next-calendar-update" : 00/00/06/07/2014 839 } 840 ... other meta ... 841 }, 843 "resources" : { 845 ... usual ALTO resources such as Network Map, Cost Maps ... 847 "endpoint-cost" : { 848 "uri" : "http://alto.example.com/endpointcost/lookup", 849 "media-types" : [ "application/alto-endpointcost+json" ], 850 "accepts" : [ "application/alto-endpointcostparams+json" ], 851 "capabilities" : { 852 "cost-constraints" : true, 853 "cost-type-names" : [ "num-routingcost", "num-AShopcount" ] 854 } 855 }, 856 "endpoint-cost-calendar-map" : { 857 "uri" : "http://alto.example.com/endpointcost/calendar/lookup", 858 "media-types" : [ "application/alto-endpointcost+json" ], 859 "accepts" : [ "application/alto-endpointcostparams+json" ], 860 "capabilities" : { 861 "cost-constraints" : true, 862 "cost-type-names" : [ "calendar-routingcost", 863 "calendar-TEpktloss", 864 "calendar-bw"] 865 } 866 } 867 } 868 } 870 4.3.2. Example transaction for a routingcost Calendar to face 871 intermittent connectivity 873 Let us assume an Application Client located in an end sytem with 874 limited resources and having an access to the network that is either 875 intermittent or provides an acceptable quality in limited but 876 possibly predictable time periods. Therefore, it needs to both 877 schedule its resources demanding networking activities and minimize 878 its ALTO transactions. 880 The Application Client has the choice to trade content or resources 881 with a set of Endpoints of moderate 'routingcost', and needs to 882 decide with which Endpoint it will trade at what time. For instance, 883 one may assume that the Endpoints are spread on different time-zones, 884 or have intermittent access. In this example, the 'routingcost' is 885 assumed to be the time sentitive decision metric, with values 886 provided in the ALTO Calendar Mode. 888 The ALTO Client embedded in the Application Client queries an ALTO 889 Calendar on 'routingcost' and will get the Calendar covering the 24 890 hours time period "containing" the date and time of the ALTO client 891 request. 893 POST endpointcost/calendar/lookup HTTP/1.1 894 Host: alto.example.com 895 Content-Length: [TODO] 896 Content-Type: application/alto-endpointcostparams+json 897 Accept: application/alto-endpointcost+json,application/alto-error+json 899 { 900 "cost-type" : {"cost-mode" : "calendar", "cost-metric" : "routingcost"}, 901 "endpoints" : { 902 "srcs": [ "ipv4:192.0.2.2" ], 903 "dsts": [ 904 "ipv4:192.0.2.89", 905 "ipv4:198.51.100.34", 906 "ipv4:203.0.113.45" 907 ] 908 } 909 } 911 HTTP/1.1 200 OK 912 Content-Length: [TODO] 913 Content-Type: application/alto-endpointcost+json 915 { 916 "meta" : {}, 917 "cost-type" : {"cost-mode" : "calendar", "cost-metric" : "routingcost"}, 918 "endpoint-cost-calendar-map" : { 919 "ipv4:192.0.2.2": { 920 "ipv4:192.0.2.89" : [7, ... 24 values], 921 "ipv4:198.51.100.34" : [4, ... 24 values], 922 "ipv4:203.0.113.45" : [2, ... 24 values] 923 } 924 } 925 } 927 4.3.3. Example transaction for a bandwidth calendar 929 One example of non-real time information that can be provisioned in a 930 'calendar' is the expected path bandwidth. While the transmission 931 rate can be measured in real time by end systems, the operator of a 932 data center is in the position of formulating preferences for given 933 paths, at given time periods of given time scales, for example to 934 avoid hotspots due to diurnal usage patterns. In this example, we 935 assume that an ALTO Client requests a bandwidth calendar as specified 936 in the IRD to shedule its bulk data transfers as described in the use 937 cases of sections 2.1 and 2.5. 939 POST endpointcost/calendar/lookup HTTP/1.1 940 Host: alto.example.com 941 Content-Length: [TODO] 942 Content-Type: application/alto-endpointcostparams+json 943 Accept: application/alto-endpointcost+json,application/alto-error+json 945 { 946 "cost-type" : {"cost-mode" : "calendar", "cost-metric" : "Availbandwidth"}, 947 "endpoints" : { 948 "srcs": [ "ipv4:192.0.2.2" ], 949 "dsts": [ 950 "ipv4:192.0.2.89", 951 "ipv4:198.51.100.34", 952 "ipv4:203.0.113.45" 953 ] 954 } 955 } 957 HTTP/1.1 200 OK 958 Content-Length: [TODO] 959 Content-Type: application/alto-endpointcost+json 961 { 962 "meta" : {}, 963 "cost-type" : {"cost-mode" : "calendar", "cost-metric" : "Availbandwidth"}, 964 "endpoint-cost-calendar-map" : { 965 "ipv4:192.0.2.2": { 966 "ipv4:192.0.2.89" : [7, ... 12 values], 967 "ipv4:198.51.100.34" : [4, ... 12 values], 968 "ipv4:203.0.113.45" : [2, ... 12 values] 969 } 970 } 971 } 973 5. IANA Considerations 975 Information for the ALTO Endpoint property registry maintained by the 976 IANA and related to the new Endpoints supported by the acting ALTO 977 server. These definitions will be formulated according to the syntax 978 defined in Section on "ALTO Endpoint Property Registry" of 979 [ID-alto-protocol], 981 Information for the ALTO Cost Type Registry maintained by the IANA 982 and related to the new Cost Types supported by the acting ALTO 983 server. These definitions will be formulated according to the syntax 984 defined in Section on "ALTO Cost Type Registry" of 985 [ID-alto-protocol], 987 5.1. Information for IANA on proposed Cost Types 989 When a new ALTO Cost Type is defined, accepted by the ALTO working 990 group and requests for IANA registration MUST include the following 991 information, detailed in Section 11.2: Identifier, Intended 992 Semantics, Security Considerations. 994 5.2. Information for IANA on proposed Endpoint Propeeries 996 Likewise, an ALTO Endpoint Property Registry could serve the same 997 purposes as the ALTO Cost Type registry. Application to IANA 998 registration for Endpoint Properties would follow a similar process. 1000 6. Acknowledgements 1002 Thank you to D. Lopez, H. Peng and the ALTO WG for fruitful 1003 discussions. 1005 7. References 1007 7.1. Normative References 1009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1010 Requirement Levels", BCP 14, RFC 2119, March 1997. 1012 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1013 Optimization (ALTO) Problem Statement", RFC 5693, October 1014 2009. 1016 7.2. Informative References 1018 [ID-alto-protocol] 1019 R.Alimi, R. Penno, Y. Yang, Eds., "ALTO Protocol, draft- 1020 ietf-alto-protocol-27.txt", March 2014. 1022 [article-gslh-alto-sdn] 1023 V. Gurbani, M. Scharf, T.Lakshman, and V. Hilt, , 1024 "Abstracting network state in Software Defined Networks 1025 (SDN) for rendezvous services, IEEE International 1026 Conference on Communications (ICC) Workshop on Software 1027 Defined Networks (SDN)", June 2012. 1029 [draft-jenkins-alto-cdn-use-cases-01] 1030 B. Niven-Jenkins (Ed.), G. Watson, N. Bitar, J. Medved, S. 1031 Previdi, , "Use Cases for ALTO within CDNs, draft-jenkins- 1032 alto-cdn-use-cases-01", June 2011. 1034 [draft-randriamasy-multi-cost-alto] 1035 S. Randriamasy, Ed., W. Roome, N. Schwan, , "Multi-Cost 1036 ALTO (work in progress), draft-randriamasy-alto-multi- 1037 cost-07", October 2012. 1039 [draft-wu-alto-te-metrics] 1040 Q. Wu, Y. Yang, Y. Lee, D. Dhody, S. Randriamasy, , "ALTO 1041 Traffic Engineering Cost Metrics (work in progress)", June 1042 2014. 1044 [draft-xie-alto-sdn] 1045 H. Xie, T. Tsou, D. Lopez, H. Yin, , "Use Cases for ALTO 1046 with Software Defined Networks (work in progress), draft- 1047 xie-alto-sdn-extension-use-cases-01", January 2013. 1049 [draft-yang-alto-topology-00] 1050 Y. Yang, , "ALTO Topology Considerations (work in 1051 progress)", July 2013. 1053 [sdnrg] "Software Defined Network Research Group, 1054 http://trac.tools.ietf.org/group/irtf/trac/wiki/sdnrg", . 1056 [slides-88-alto-5-topology] 1057 G. Bernstein, Y. Lee, Y. Yang, , , "ALTO Topology Service: 1058 Use Cases, Requirements and Framework (presentation slides 1059 IETF88 ALTO WG session), 1060 http://tools.ietf.org/agenda/88/slides/ 1061 slides-88-alto-5.pdf", November 2013. 1063 Authors' Addresses 1064 Sabine Randriamasy (editor) 1065 Alcatel-Lucent Bell Labs 1066 Route de Villejust 1067 NOZAY 91460 1068 FRANCE 1070 Email: Sabine.Randriamasy@alcatel-lucent.com 1072 Richard Yang 1073 Yale University 1074 51 Prospect st 1075 New Haven, CT 06520 1076 USA 1078 Email: yry@cs.yale.edu 1080 Qin Wu 1081 Huawei 1082 101 Software Avenue, Yuhua District 1083 Nanjing, Jiangsu 210012 1084 China 1086 Email: sunseawq@huawei.com 1088 Lingli Deng 1089 China Mobile 1090 China 1092 Email: denglingli@chinamobile.com 1094 Nico Schwan 1095 Thales Deutschland 1097 Email: ietf@nico-schwan.de