idnits 2.17.1 draft-randriamasy-alto-cost-schedule-03.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. ** The abstract seems to contain references ([RFC5693]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3717 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TODO' is mentioned on line 669, but not defined == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-13 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-25 -- Duplicate reference: draft-ietf-alto-protocol, mentioned in 'ID-alto-protocol', was also mentioned in 'ID-alto-protocol-13'. Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: Experimental N. Schwan 5 Expires: August 18, 2014 6 February 14, 2014 8 ALTO Cost Schedule 9 draft-randriamasy-alto-cost-schedule-03 11 Abstract 13 The goal of Application-Layer Traffic Optimization (ALTO) is to 14 bridge the gap between network and applications by provisioning 15 network related information. This allows applications to make 16 informed decisions, for example when selecting a target host from a 17 set of candidates. The ALTO problem statement [RFC5693] considers 18 typical applications as file sharing, real-time communication and 19 live streaming peer-to-peer networks. Recently other use cases 20 focused on Content Distribution Networks and Data Centers have 21 emerged. 23 The present draft proposes to extend the cost information provided by 24 the ALTO protocol. The purpose is to broaden the decision 25 possibilities of applications to not only decide 'where' to connect 26 to, but also 'when'. This is useful to applications that have a 27 degree of freedom on when to schedule data transfers, such as non- 28 instantaneous data replication between data centers or service 29 provisioning to end systems with irregular connectivity. The draft 30 therefore specifies a new cost mode, called the "schedule" mode. In 31 this mode the ALTO server offers cost maps that contain path ratings 32 that are valid for a given timeframe (e.g. hourly) for a period of 33 time (e.g. a day). Besides the functional time-shift enhancement 34 providing multi-timeframe cost values, the ALTO Cost Schedule also 35 allows to save a number of ALTO transactions and thus resources on 36 the ALTO server and clients. Last, guidance to schedule application 37 traffic can also efficiently help for load balancing and resources 38 efficiency. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on August 18, 2014. 63 Copyright Notice 65 Copyright (c) 2014 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Use cases for ALTO Cost Schedule . . . . . . . . . . . . . . 4 82 2.1. Bulk Data Transfer scheduling . . . . . . . . . . . . . . 5 83 2.2. Endsystems with limited connectivity or access to 84 datacenters . . . . . . . . . . . . . . . . . . . . . . . 5 85 2.3. SDN Controller guided access to application endpoints . . 7 86 2.4. Large flow scheduling on extended ALTO topologies . . . . 9 87 2.5. Providing values for time-sensitve TE metrics . . . . . . 10 88 3. ALTO Cost Schedule extension . . . . . . . . . . . . . . . . 10 89 3.1. Cost Schedule Attributes . . . . . . . . . . . . . . . . 11 90 3.1.1. ALTO Cost-Mode: Schedule . . . . . . . . . . . . . . 11 91 3.2. ALTO Capability: Cost-Scope . . . . . . . . . . . . . . . 11 92 3.2.1. Example of time scope for a cost schedule . . . . . . 12 93 3.3. Example of scheduled information resources in the IRD . . 12 94 3.3.1. Example scenario and ALTO transaction with a Cost 95 Schedule . . . . . . . . . . . . . . . . . . . . . . 15 96 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 97 4.1. Information for IANA on proposed Cost Types . . . . . . . 17 98 4.2. Information for IANA on proposed Endpoint Propeeries . . 17 99 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 100 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 102 6.2. Informative References . . . . . . . . . . . . . . . . . 17 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 105 1. Introduction 107 IETF is currently standardizing the ALTO protocol which aims for 108 providing guidance to overlay applications, that need to select one 109 or several hosts from a set of candidates that are able to provide a 110 desired resource. This guidance is based on parameters that affect 111 performance and efficiency of the data transmission between the 112 hosts, e.g., the topological distance. The goal of ALTO is to 113 improve the Quality of Experience (QoE) in the application while 114 simultaneously optimizing resource usage in the underlying network 115 infrastructure. 117 The ALTO protocol therefore [ID-alto-protocol] specifies a Network 118 Map, which defines groupings of endpoints in a network region (called 119 a PID) as seen by the ALTO server. The Endpoint Cost Service and the 120 Endpoint (EP) Ranking Service then provide rankings for connections 121 between the specified network regions and thus incentives for 122 application clients to connect to ISP preferred endpoints, e.g. to 123 reduce costs imposed to the network provider. Thereby ALTO 124 intentionally avoids the provisioning of realtime information (cmp. 125 ALTO Problem Statement [RFC5693] and ALTO Requirements [RFC5693]), as 126 "Such information is better suited to be transferred through an in- 127 band technique at the transport layer instead". Thus the current 128 Cost Map and Endpoint Cost Service are providing, for a given Cost 129 Type, exactly one rating per link between two PIDs or to an Endpoint. 130 Applications are expected to query one of these two services in order 131 to retrieve the currently valid cost values. They therefore need to 132 plan their ALTO information requests according to the estimated 133 frequency of cost value change. In case these value changes are 134 predicable over a certain period of time and the application does not 135 require immediate data transfer, it would save time to get the whole 136 set of cost values over the period in one ALTO response and using 137 these values to schedule data transfers would allow to optimise the 138 network resources usage and QoE. 140 In this draft we introduce use cases that describe applications that 141 have a degree of freedom on scheduling data transfers over a period 142 of time, thus they do not need to start a transfer instantaneously on 143 a retrieved request. For this kind of applications we propose to 144 extend the Cost Map and Endpoint Cost Services by adding a schedule 145 on the cost values, allowing applications to time-shift data 146 transfers. 148 In addition to this functional ALTO enhancement, we expect to further 149 gain by gathering multiple Cost Values for one cost type as firstly 150 one Cost Map reporting on N Cost Values is less bulky than N Cost 151 Maps containing one Cost value each and secondly, this reduces N ALTO 152 transactions to a single one. This is valuable for both the storage 153 of these ALTO maps and their transfer. Similar gains can be obtained 154 for the ALTO Endpoint Cost Service. 156 The remainder of this draft first provides use cases that motivate 157 the need for a 'schedule' cost mode. It then specifies the needed 158 extensions to the ALTO protocol and details some example messages. 159 Note that the example ALTO transactions are provided with the ALTO 160 syntax as specified in previous ALTO protocol draft versions, see 161 [ID-alto-protocol-13]. The syntax will be updated when the base ALTO 162 protocol will be finalized. 164 2. Use cases for ALTO Cost Schedule 166 This section introduces use cases showing the benefits of providing 167 ALTO Cost values in 'schedule' mode. Most likely, the ALTO Cost 168 Schedule would be used for the Endpoint Cost Service where a limited 169 set of feasible non real time application Endpoints is already 170 identified, they need to be accessed neither simultaneously nor 171 immediately and their access can be scheduled within a given time 172 period. The Filtered Cost Map service is also applicable as long as 173 the size of the Map is manageable. An ALTO Cost schedule can be used 174 in several ways: 176 o the ALTO Server may provide values on past time periods that can 177 be interpreted as historical experience and used to anticipate 178 future cost values in order to schedule transfers of application 179 data or services, 181 o the ALTO Server may provide stationary values on present or future 182 time periods that can be interpreted as predictions on cost values 183 and used to schedule transfers of application data or services, 185 o the ALTO Server may provide stationary values on time periods 186 covering the past, present and future and logically be all 187 interpreted as predictions and used to schedule transfers of 188 application data or services. 190 2.1. Bulk Data Transfer scheduling 192 Some CDNs are prepopulating caches with content before it actually 193 gets available for the user and thus there is a degree of freedom on 194 when the content is transmitted from the origin server to the caching 195 node. Other applications like Facebook or YouTube rely on data 196 replication across multiple sites for several reasons, such as 197 offloading the core network or increasing user experience through 198 short latency. Typically the usage pattern of these data centers or 199 caches follows a location dependent diurnal pattern. 201 In the examples above, data needs to be replicated across the various 202 locations of a CDN provider, leading to bulk data transfers between 203 datacenters. Scheduling these data transfers is a non-trivial task 204 as the transfer should not infer with the user peak demand to avoid 205 degradation of user experience and to decrease billing costs for the 206 datacenter operator by leveraging off-peak hours for the transfer. 207 This peak demand typically follows a diurnal pattern according to the 208 geographic region of the datacenter. One precondition to schedule 209 transfers however is to have a good knowledge about the demand and 210 link utilization patterns between the different datacenters and 211 networks. 213 While this usage data today already is gathered and also used for the 214 scheduling of data transfer, provisioning this data gets increasingly 215 complex with the number of CDN nodes and in particular the number of 216 datacenter operators that are involved. For example, privacy 217 concerns prevent that this kind of data is shared across 218 administrative domains. The ALTO Cost Schedule specified later in 219 this document avoids this problem by presenting an abstracted view of 220 time sensitive utilization maps through a dedicated ALTO service to 221 allow CDN operators a mutual scheduling of such data transfers across 222 administrative domains. 224 2.2. Endsystems with limited connectivity or access to datacenters 226 Another use case that benefits from the availability of multi- 227 timeframe cost information is based on applications that are limited 228 by their connectivity either in time or resources or both. For 229 example applications running on devices in remote locations or in 230 developing countries that need to synchronize their state with a data 231 center periodically, in particular if sometimes there is no 232 connection at all. Example applications is enterprise database 233 update, remote learning, remote computation distributed on several 234 data center endpoints. 236 Wireless connectivity has a variable quality or may even be 237 intermittent. On the other hand, the connectivity conditions are 238 often predicable. For non real time applications, it is thus 239 desirable to provide ALTO clients with routing costs to connection 240 nodes (i.e. Application Endpoints) over different time periods. 241 This would allow end systems using ALTO aware application clients to 242 schedule their connections to application endpoints. 244 Another challenge arises with end systems using resources located in 245 datacenters and trading content and resources scattered around the 246 world. For non-real time applications, the interaction with 247 Endpoints can be scheduled at the time slots corresponding to the 248 best possible QoE. For instance, resource Ra downloaded from 249 Endpoint EPa at time t1, Resource Rb uploaded to EPb at time t2, some 250 batch computation involving Ra and Rb done on EPc at time t3 and 251 results R(A,B) downloaded to EPd and EPe at time t4. Example 252 applications are similar to the ones cited in the previous paragraph. 254 +-----+ +-----+ 255 | EPa | | EPb | <----- Rb 256 +-----+ +-----+ (t2=50) 257 | +-------+ | 258 Ra --------------> | EPc | | 259 (time t1=10) | | | 260 |t3=100 | <----------------- Rb 261 +-------+ 262 | \ 263 | \ 264 R(Ra,Rb) 265 (t4=200) 266 | \ 267 | -------------------. 268 V V 269 +-----+ +-----+ 270 | EPd | | EPe | 271 +-----+ +-----+ 273 These examples describe situations where a client has the choice of 274 trading content or resources with several Endpoints and needs to 275 decide with which Endpoint it will trade and at what time. For 276 instance, one may assume that the Endpoints are spread over different 277 time-zones, or have intermittent access. The ALTO Schedule mode 278 specified below allows these clients to retrieve Endpoint cost maps 279 valid for a certain timeframe (e.g. 24 hours), and get a set of 280 values, each applicable on a (e.g. hourly) slot. Thus the 281 application can optimize the needed data transfer according to this 282 information. 284 Last, the ALTO Cost schedule is beneficial to optimizing ALTO 285 transactions themselves. Indeed, let us assume that an Application 286 Client is located in an end sytem with limited resources and/or has 287 an access to the network that is either intermittent or provides an 288 acceptable QoE in limited but predictable time periods. In that 289 case, it needs to both schedule its resources demanding networking 290 activities and its ALTO requests. Instead of having to figure out 291 when the cost values may change and having to carefully schedule 292 multiple ALTO requests, it could aviod this by relying on Cost 293 Shedule attributes that indicate the time granularity, the validity 294 and time scope of the cost information, together with the time 295 related cost values themselves. 297 Suppose that for some Cost Types, the ALTO cost values are available 298 in the "schedule" mode. If the values of Cost type 'routingcost' and 299 /or another time-sensitive Cost Type named for example 300 'pathoccupationcost' are available in the "schedule" mode for the 24 301 hours following the last update, the ALTO Client embedded in the 302 Application Client may query ALTO information on 'routingcost' or 303 'pathoccupationcost' for these 24 hours, and get a set of values, 304 each applicable to an hour slot. If appropriate Cost Attributes are 305 provided together with the cost values, the Application client also 306 knows the date of their last update. An example ALTO transaction is 307 provided later in this draft. 309 2.3. SDN Controller guided access to application endpoints 311 The Software Defined Networking (SDN), see [sdnrg], is a model that 312 attempts to manage and reconfigure networks in a more flexible way in 313 order to better cope with the traffic challenges posed by nowadays 314 resources greedy applications. To this end, one option is "moving 315 the control plane out of the network elements into "controllers", see 316 [SDN charter, http://www.1-4-5.net/~dmm/sdnrg/sdnrg.html], that 317 implements the network control and management. The SDN Controllers 318 are deemed to gather the network state information and provide it in 319 an abstracted form to SDN aware applications while gathering their 320 requirements in QoE and exchanging other application "management" 321 information and commands. 323 The relevance of ALTO to perform a number of SDN functions has been 324 recently highlighted. An ALTO Server can assist an SDN Controller by 325 hosting abstracted network information that can be provided to SDN 326 aware applications via an ALTO Client. It can also assist other SDN 327 Control operations using information in and outside the ALTO scope. 329 In particular, [article-gslh-alto-sdn] identifies SDN Controller 330 functions that ALTO is well suited to perform: the primitives of 331 Abstraction, Get network topology, Get network resources and Event 332 notification. Additonally, the interaction between ALTO and SDN has 333 been investigated in [draft-xie-alto-sdn] to provide applications 334 with a path selection meeting QoS requirements on bandwidth and 335 delay. 337 Currently, the base ALTO protocol allows to perform the following SDN 338 services, see [article-gslh-alto-sdn]: 340 1. Abstraction: through aggregation into PIDs, ranking and a generic 341 cost type. 343 2. Get network topology: through the Map and the Cost Map Services 345 3. Get device capabilities: through the Endpoint Property Service. 347 Another SDN primitive "Get network resources" provides applications 348 with informations allowing them to evaluate the expected QoE. QoE 349 related information includes delay and bandwidth at the application 350 endpoints as well as on the network paths. Such information may be 351 provided via the ALTO Service by proposed extensions of the ALTO 352 protocol that define new ALTO Cost Types allowing to abstract and 353 report QoE to applications. 355 One key objective of an SDN controller is the ability to balance the 356 application traffic whenever possible. For non real time 357 applications, data and resources transfer can be time shifted, 358 resources availability may often be predicable and last, strong 359 incentives for applications to time shift their traffic may be given 360 by network operators appropriately setting routing cost values at 361 different time values, according to their policy to cope with network 362 occupation over time. 364 To achieve this objective, the SDN controller can: 366 1. get the network state history from its controlled network 367 elements through its southbound API 369 2. possibly derive an estimation or a prediction of these values 370 over given time frames 372 3. store their abstraction in an ALTO Server in the form of ALTO 373 Cost Schedule values defined for different time periods 375 4. deliver these values to the SDN applications via the ALTO 376 Endpoint Cost Service, either as history or prediction or as 377 estimations covering both the past and the future. 379 This way: 381 o One one hand, the applications get the best possible QoE, as they 382 can pick the best time for them to access one or more Endpoints, 384 o One the other hand the SDN controller achieves load balancing as 385 it may guide the application traffic so as to better distribute 386 the traffic over time, and thus optimize its resources usage. 388 2.4. Large flow scheduling on extended ALTO topologies 390 [draft-yang-alto-topology-00] presents initial thinking on extending 391 ALTO for topology exposure services, that would provide flexible 392 abstractions based on the raw network topology. Among other 393 features, an ALTO topology may expose several paths between a source 394 (src) and destination (dst), or topology details may be provided on 395 restricted parts. This work was presented to the ALTO WG at IETF88. 397 The presentation slides [slides-88-alto-5-topology] on 398 [draft-yang-alto-topology-00] expose a use case entitled "Large Flow 399 Scheduling". This case includes a "daylife example" where a Google 400 Map service proposes multiple routes between 2 points A and B, each 401 calculated w.r.t. length and estimated time. For each of these 402 selected paths, the map service exposes a time-sensitive qualitative 403 value taking 4 values between Slow and Fast. A user of this 404 application may thus organize its transfer w.r.t. metrics, paths and 405 time, provided s/he does not have to commute immediately. 407 The use case on Large flow scheduling on extended ALTO topologies in 408 the present section illustrates one modality of ALTO topology 409 service, that would expose several paths between end to end (src, 410 dst) pairs, computed w.r.t. one of more metrics, possibly under given 411 constraints. On top of this enriched topology service, non real-time 412 applications may also choose the time of data/resources transfer, 413 taking thus advantage of a richer set of decision variables. 415 The use case "Large Flow Scheduling" of presentation 416 [slides-88-alto-5-topology]can thus be adapted as follows: 418 o Step1 - obtain the set T transfer tasks {(src, dest, data)} 420 o Step2 - identify one or more paths for each (src, dst): several 421 information sources exist among which: 423 * (a) ALTO CostMap with a "path" metric, // not specified here 425 * (b) an ALTO Topology Service providing a path computation hint 426 (e.g. w.r.t. routingcost and/or other metrics) 428 o Step 3- while T not empty: 430 * 1 - query for example values for some metric 'available 431 bandwidth' on paths: 433 + to this end, query the values in the ALTO 'schedule' Mode: 434 on the selected (src, dst) for a set of time intervals. 435 With this mode, the ALTO client will receive an array of 436 values, each applicable to a time slot . 438 * 2 - schedule data transfer at the time slots corresponding to 439 the preferred value. 441 2.5. Providing values for time-sensitve TE metrics 443 Draft [draft-wu-alto-te-metrics-01], proposes to extend the set of 444 ALTO metrics with traffic engineering (TE) metrics, in order to 445 closely meet applications requirementsand under appropriate trust 446 agreements. This draft exposes a number of TE metrics that are time- 447 sensitive, either by nature such as bandwidth and delay related 448 metrics, or due to "normally" changing network conditions or both. 450 The draft assumes that the values of ALTO TE metrics are typically 451 collected from routing protocols and provided in a non-real time 452 manner. In "normally" changing network conditions TE metric values 453 remain uniformly distributed over given time intervals and can be 454 aggregated over bigger sample intervals of periodic patterns. For 455 instance an ALTO Server may collect values from a routing protocol 456 produced by measurements done every second over a period of 30 457 seconds. The ALTO Server may then aggregate these values over ALTO 458 Sample intervals of 60 seconds and every hour, provide the values in 459 'schedule' mode endcoded as an array of 60 values. 461 All time sensitive ALTO TE metrics are potentially applicable to a 462 cost schedule. The real applicability actually depend on the network 463 topology and structure. A small topology with low density and 464 capacity that carries inpredictable heavy and bursty traffic has few 465 chances to exhibit stationary TE metric value patterns over large 466 periods and would benefit to use the ALTO Schedule over smaller time 467 slots. 469 3. ALTO Cost Schedule extension 471 One example of non-real time information that can be provisioned in a 472 'schedule' is the expected path bandwidth. While the transmission 473 rate can be measured in real time by end systems, the operator of a 474 data center is in the position of formulating preferences for given 475 paths, at given time periods of given time scales, for example to 476 avoid hotspots due to diurnal usage patterns. The entity managing 477 the ALTO Server values can decide to integrate path bandwidth in the 478 ALTO 'routingcost' metric. However to better highlight the purpose 479 of the cost schedule the remainder of this document will use a Cost 480 Type named 'pathoccupationcost' and assumed to report an abstracted 481 form of available bandwidth. A definition and usage of such a Cost- 482 Type is proposed in [draft-randriamasy-multi-cost-alto]. 484 The usage of a time related cost is rather proactive in that it can 485 be used like a "time table" to figure out the best time to schedule 486 data transfer and also anticipate predictable events including 487 predictable flash crowds. An ALTO Cost Schedule should be viewed as 488 a synthetic abstraction of real measurements that can be historic or 489 be a prediction for upcoming time periods. 491 3.1. Cost Schedule Attributes 493 Specifications on the cost "schedule" are proposed here and will be 494 completed in further versions of this draft. 496 3.1.1. ALTO Cost-Mode: Schedule 498 The "schedule" mode applies to Costs that are eligible for a single- 499 valued Cost Mode and can also be expressed as such. In that sense, 500 when the "numerical" mode is available for a Cost-Type, the cost 501 expressed in the "schedule" mode is an extension of its expression 502 from one value in the "numerical" mode to an array of several values 503 varying over time. 505 Types of Cost values such as JSONBool can also be expressed in the 506 "schedule" mode, as states may be "true" or "false" depending on 507 given time periods. It may be expressed as a single value which is 508 either "true" or "false" following a decision rule outside the ALTO 509 protocol. 511 3.2. ALTO Capability: Cost-Scope 513 To ensure that the application client uses the NP provided 514 information in the cost schedule in an unambiguous way we define the 515 Cost Scope capability, which defines the validity of the "scheduled" 516 cost values. 518 For Cost Types whose values are provided in a mode different than 519 'schedule', the Cost Scope capability is specified by the string 520 "permanent". The Cost Scope attributes provided for the 'schedule' 521 mode are listed below. The reference time zone for the provided 522 values is UTC. 524 o Unit: expresses the time interval applicable to each value. A two 525 element array where the first element is the time unit, ranging 526 from "second" to "year", and the second one the number of units of 527 this duration. For example: '["minute", 5]' means that each value 528 is provided on a time interval lasting 5 minutes. 530 o Size: the number of values of the cost schedule array, 532 o Begin: the index of the first unit in the array, 534 o Reference time zone: set to "UTC", 536 o Next update: the date at which the sample will be re-computed, 538 o Last update: the last re-computation date. 540 The reference time zone is UTC. 542 Attributes 'Last update 'and 'Next update' report on the update 543 frequency and age of the information. 545 3.2.1. Example of time scope for a cost schedule 547 Let us assume that the metric 'pathoccupationcost' (POC for short) is 548 computed for 24 hours, on time intervals lasting 2 hours, with the 549 first interval starting at 0h00. The ALTO Server thus provides an 550 array 12 values. This information is then used to enable 551 applications to see which time intervals in a day are the most 552 favorable to operate, and which "busy " time intervals should be 553 avoided. If the "Begin" date is past, the application can also use 554 the information to compute statistics or infer a some customized 555 prediction. 557 3.3. Example of scheduled information resources in the IRD 559 The example IRD given in this Section includes 2 particular URIs: 561 o "http://alto.example.com/endpointcost/lookup", in which the ALTO 562 Server offers several Endpoint Cost Types, including a Cost called 563 "pathoccupationcost" for which the "schedule" Cost Mode is 564 available. The Endpoint Costs available are the "hopcount", 565 "routingcost" and "pathoccupationcost" Cost Types, with the two 566 first ones in the "numerical" Cost Mode and "pathoccupationcost" 567 in the "schedule" Cost Mode. 569 o "http://custom.alto.example.com/endpointcost/schedule/lookup", in 570 which the ALTO Server provides the 'routingcost' in both 571 "numerical" and "schedule" modes. This resource is accessible via 572 a separate subdomain called "custom.alto.example.com". The ALTO 573 Client may either get the last update of the 'routingcost' value 574 or request for a previsonal sample of 24 values established each 575 for 1 hour. An ALTO Client can discover the services available at 576 "custom.alto.example.com" by successfully performing an OPTIONS 577 request to "http://custom.alto.example.com/endpointcost". 579 GET /directory HTTP/1.1 580 Host: alto.example.com 581 Accept: application/alto-directory+json,application/alto-error+json 583 HTTP/1.1 200 OK 584 Content-Length: [TODO] 585 Content-Type: application/alto-directory+json 587 { 589 ... usual ALTO resources ... 591 "resources" : [ 592 { 593 "uri" : "http://alto.example.com/endpointcost/lookup", 594 "media-types" : [ "application/alto-endpointcost+json" ], 595 "accepts" : [ "application/alto-endpointcostparams+json" ], 596 "capabilities" : { 597 "cost-constraints" : true, 598 "cost-modes" : [ "numerical", "numerical", "schedule" ], 599 "cost-types" : [ "routingcost", "hopcount", "pathoccupationcost" ], 600 "cost-scope": [ "permanent", "permanent", 601 {"unit": ["hour", 1], "size": 24, "begin": 0, 602 "time zone": "UTC", 603 "lastupdate": mm/hh/dd/mm/yyyy, 604 "nextupdate": mm/hh/dd/mm/yyyy} 605 ] 606 }, 607 { 608 "uri" : "http://custom.alto.example.com/endpointcost/schedule/lookup", 609 "media-types" : [ "application/alto-endpointcost+json" ], 610 "accepts" : [ "application/alto-endpointcostparams+json" ], 611 "capabilities" : { 612 "cost-constraints" : true, 613 "cost-modes" : [ "numerical", "schedule" ], 614 "cost-types" : [ "routingcost", "routingcost" ], 615 "cost-scope": [ "permanent", 616 {"unit": ["hour", 1], "size": 24, "begin": 0, 617 "time zone": "UTC", 618 "lastupdate": mm/hh/dd/mm/yyyy, 619 "nextupdate": mm/hh/dd/mm/yyyy} 620 ] 621 } 622 } 623 ] 624 } 626 3.3.1. Example scenario and ALTO transaction with a Cost Schedule 628 Let us assume an Application Client located in an end sytem with 629 limited resources and having an access to the network that is either 630 intermittent or provides an acceptable quality in limited but 631 possibly predictable time periods. Therefore, it needs to both 632 schedule its resources demanding networking activities and minimize 633 its ALTO transactions. 635 The Application Client has the choice to trade content or resources 636 with a set of Endpoints of moderate 'routingcost', and needs to 637 decide with which Endpoint it will trade at what time. For instance, 638 one may assume that the Endpoints are spread on different time-zones, 639 or have intermittent access. In this example, the 'routingcost' is 640 assumed constant for the scheduling period and the time sentitive 641 decision metric is the path bandwidth reflected by a Cost type called 642 'pathoccupationcost'. 644 The ALTO Client embedded in the Application Client queries ALTO 645 information on 'pathoccupationcost' for the 24 hours following 646 (implicitely) the date of "lastupdate", as this resource is listed in 647 the IRD. 649 POST /endpointcost/lookup HTTP/1.1 650 Host: alto.example.com 651 Content-Length: [TODO] 652 Content-Type: application/alto-endpointcostparams+json 653 Accept: application/alto-endpointcost+json,application/alto-error+json 655 { 656 "cost-type" : ["pathoccupationcost"], 657 "cost-mode" : ["schedule"], 658 "endpoints" : { 659 "srcs": [ "ipv4:192.0.2.2" ], 660 "dsts": [ 661 "ipv4:192.0.2.89", 662 "ipv4:198.51.100.34", 663 "ipv4:203.0.113.45" 664 ] 665 } 666 } 668 HTTP/1.1 200 OK 669 Content-Length: [TODO] 670 Content-Type: application/alto-endpointcost+json 672 { 673 "meta" : {}, 674 "data" : { 675 "cost-type" : ["pathoccupationcost"], 676 "cost-mode" : ["schedule"], 677 "map" : { 678 "ipv4:192.0.2.2": { 679 "ipv4:192.0.2.89" : [7, ... 24 values], 680 "ipv4:198.51.100.34" : [4, ... 24 values], 681 "ipv4:203.0.113.45" : [2, ... 24 values] 682 } 683 } 684 } 685 } 687 4. IANA Considerations 689 Information for the ALTO Endpoint property registry maintained by the 690 IANA and related to the new Endpoints supported by the acting ALTO 691 server. These definitions will be formulated according to the syntax 692 defined in Section on "ALTO Endpoint Property Registry" of 693 [ID-alto-protocol], 694 Information for the ALTO Cost Type Registry maintained by the IANA 695 and related to the new Cost Types supported by the acting ALTO 696 server. These definitions will be formulated according to the syntax 697 defined in Section on "ALTO Cost Type Registry" of 698 [ID-alto-protocol], 700 4.1. Information for IANA on proposed Cost Types 702 When a new ALTO Cost Type is defined, accepted by the ALTO working 703 group and requests for IANA registration MUST include the following 704 information, detailed in Section 11.2: Identifier, Intended 705 Semantics, Security Considerations. 707 4.2. Information for IANA on proposed Endpoint Propeeries 709 Likewise, an ALTO Endpoint Property Registry could serve the same 710 purposes as the ALTO Cost Type registry. Application to IANA 711 registration for Endpoint Properties would follow a similar process. 713 5. Acknowledgements 715 Thank you to D. Lopez, R. Yang, H. Peng, Q. Wu and the ALTO WG for 716 fruitful discussions. 718 6. References 720 6.1. Normative References 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 726 Optimization (ALTO) Problem Statement", RFC 5693, October 727 2009. 729 6.2. Informative References 731 [ID-alto-protocol-13] 732 R.Alimi, R. Penno, Y. Yang, Eds., "ALTO Protocol, draft- 733 ietf-alto-protocol-13.txt", September 2012. 735 [ID-alto-protocol] 736 R.Alimi, R. Penno, Y. Yang, Eds., "ALTO Protocol, draft- 737 ietf-alto-protocol-25.txt", January 2014. 739 [article-gslh-alto-sdn] 740 V. Gurbani, M. Scharf, T.Lakshman, and V. Hilt, , 741 "Abstracting network state in Software Defined Networks 742 (SDN) for rendezvous services, IEEE International 743 Conference on Communications (ICC) Workshop on Software 744 Defined Networks (SDN)", June 2012. 746 [draft-jenkins-alto-cdn-use-cases-01] 747 B. Niven-Jenkins (Ed.), G. Watson, N. Bitar, J. Medved, S. 748 Previdi, , "Use Cases for ALTO within CDNs, draft-jenkins- 749 alto-cdn-use-cases-01", June 2011. 751 [draft-randriamasy-multi-cost-alto] 752 S. Randriamasy, Ed., B. Roome, N. Schwan, , "Multi-Cost 753 ALTO, draft-randriamasy-alto-multi-cost-07", October 2012. 755 [draft-wu-alto-te-metrics-01] 756 Q. Wu, Y. Yang, Y. Lee, D. Dhody, S. Randriamasy, , "ALTO 757 Traffic Engineering Cost Metrics (work in progress)", 758 February 2014. 760 [draft-xie-alto-sdn] 761 H. Xie, T. Tsou, D. Lopez, H. Yin, , "Use Cases for ALTO 762 with Software Defined Networks, draft-xie-alto-sdn- 763 extension-use-cases-00", June 2012. 765 [draft-yang-alto-topology-00] 766 Y. Yang, , "ALTO Topology Considerations (work in 767 progress)", July 2013. 769 [sdnrg] "Software Defined Network Research Group, 770 http://trac.tools.ietf.org/group/irtf/trac/wiki/sdnrg", . 772 [slides-88-alto-5-topology] 773 G. Bernstein, Y. Lee, Y. Yang, , , "ALTO Topology Service: 774 Use Cases, Requirements and Framework (presentation slides 775 IETF88 ALTO WG session), http://tools.ietf.org/agenda/88/ 776 slides/slides-88-alto-5.pdf", November 2013. 778 Authors' Addresses 780 Sabine Randriamasy (editor) 781 Alcatel-Lucent Bell Labs 782 Route de Villejust 783 NOZAY 91460 784 FRANCE 786 Email: Sabine.Randriamasy@alcatel-lucent.com 787 Nico Schwan 789 Email: ietf@nico-schwan.de