idnits 2.17.1 draft-randriamasy-alto-multi-cost-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 4 instances of too long lines in the document, the longest one being 11 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 1168 has weird spacing: '...ostType mul...' == Line 1169 has weird spacing: '...NString const...' == Line 1170 has weird spacing: '...ONArray or-c...' == Line 1171 has weird spacing: '...DFilter pids...' == Line 1245 has weird spacing: '...NString cost...' == (5 more instances...) -- The document date (March 9, 2015) is 3335 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: 'O' is mentioned on line 572, but not defined -- Looks like a reference, but probably isn't: '100' on line 810 -- Looks like a reference, but probably isn't: '200' on line 806 -- Looks like a reference, but probably isn't: '6' on line 1331 -- Looks like a reference, but probably isn't: '20' on line 809 -- Looks like a reference, but probably isn't: '50' on line 809 -- Looks like a reference, but probably isn't: '30' on line 810 == Missing Reference: 'TODO' is mentioned on line 1509, but not defined == Missing Reference: 'OPTIONAL' is mentioned on line 1426, but not defined == Missing Reference: 'IEEE.754.2008' is mentioned on line 1214, but not defined -- Looks like a reference, but probably isn't: '1' on line 1526 -- Looks like a reference, but probably isn't: '5' on line 1376 -- Looks like a reference, but probably isn't: '23' on line 1376 -- Looks like a reference, but probably isn't: '10' on line 1376 -- Looks like a reference, but probably isn't: '0' on line 1377 -- Looks like a reference, but probably isn't: '7' on line 1526 -- Looks like a reference, but probably isn't: '3' on line 1527 -- Looks like a reference, but probably isn't: '2' on line 1527 == Unused Reference: 'RFC5693' is defined on line 1570, but no explicit reference was found in the text == Unused Reference: 'ID-alto-protocol' is defined on line 1575, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5693 -- Duplicate reference: RFC7285, mentioned in 'RFC7285', was also mentioned in 'ID-alto-protocol'. Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Randriamasy 3 Internet-Draft W. Roome 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: September 10, 2015 N. Schwan 6 Thales Deutschland 7 March 9, 2015 9 Multi-Cost ALTO 10 draft-randriamasy-alto-multi-cost-10 12 Abstract 14 IETF is designing a new service called ALTO (Application Layer 15 traffic Optimization) that includes a "Network Map Service", an 16 "Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and 17 thus incentives for application clients to connect to ISP preferred 18 Endpoints. These services provide a view of the Network Provider 19 (NP) topology to overlay clients. 21 The present draft proposes a simple way to extend the information 22 provided by the current ALTO protocol in two ways. First, including 23 information on multiple Cost Types in a single ALTO transaction 24 provides a better mapping of the Selected Endpoints to needs of the 25 growing diversity of Content and Resources Networking Applications 26 and to the network conditions. Second, one ALTO query and response 27 exchange on N Cost Types is faster and more efficient than N single 28 cost transactions. All this also helps producing a faster and more 29 robust choice when multiple Endpoints need to be selected. Last, the 30 draft proposes to enrich the filtering capabilities by allowing 31 constraints involving several metrics combined by several types of 32 logical operators. This allows the applications to set finer 33 requirements and above all to include compromises on those 34 requirements. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on September 10, 2015. 59 Copyright Notice 61 Copyright (c) 2015 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Application Scope And Terminology . . . . . . . . . . . . . . 5 78 3. Uses Cases For Using Multiple Costs . . . . . . . . . . . . . 6 79 3.1. Use Cases For Using Additional Costs . . . . . . . . . . 6 80 3.1.1. Delay Sensitive Overlay Applications . . . . . . . . 7 81 3.1.2. Selection Of Physical Servers Involved In Virtualized 82 Applications . . . . . . . . . . . . . . . . . . . . 7 83 3.1.3. CDN Surrogate Selection . . . . . . . . . . . . . . . 8 84 3.1.4. Some Proposed Additional Properties And Costs . . . . 9 85 3.2. Use Cases For Multi-Cost ALTO Transactions . . . . . . . 10 86 3.2.1. Optimized Endpoint Cost Service . . . . . . . . . . . 10 87 3.2.2. Optimized Filtered Cost Map Service . . . . . . . . . 11 88 3.2.3. Cases Of Unpredicable Endpoint Cost Value Changes . . 11 89 3.2.3.1. Case Of A Multi-Cost ALTO Query Upon A Route 90 Change . . . . . . . . . . . . . . . . . . . . . 12 91 3.2.3.2. Case Of A Multi-Cost ALTO Query Upon A Cost Value 92 Change . . . . . . . . . . . . . . . . . . . . . 13 93 4. ALTO Protocol Updates Needed To Support Multi-Cost 94 Transactions . . . . . . . . . . . . . . . . . . . . . . . . 14 95 4.1. List Of ALTO Protocol Updates Required And Recommended . 15 96 4.2. Updates Required In The Member Format Of Objects . . . . 16 97 4.2.1. Cost Value Encoded In array of JSON values . . . . . 16 98 4.2.2. Scalar 'cost-type' Member Replaced By Array 'multi- 99 cost-types' Member . . . . . . . . . . . . . . . . . 16 100 4.2.3. Rule On Cost Value Order In ALTO Reponses . . . . . . 17 101 4.3. Updates Recommended In The Object Structure . . . . . . . 17 102 5. Extended Constraints On Multi-Cost Values . . . . . . . . . . 17 103 5.1. Use Cases For Multi-Cost Multi-Operator Constraints . . . 18 104 5.2. Extended constraints in Multi-Cost ALTO . . . . . . . . . 19 105 6. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 19 106 6.1. Information Resources Directory . . . . . . . . . . . . . 20 107 6.1.1. Example of Multi-Cost specific resources in the IRD . 20 108 6.2. Multi-Cost Map Service . . . . . . . . . . . . . . . . . 23 109 6.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 23 110 6.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 23 111 6.2.3. Input Parameters . . . . . . . . . . . . . . . . . . 23 112 6.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 23 113 6.2.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 24 114 6.2.6. Response . . . . . . . . . . . . . . . . . . . . . . 24 115 6.2.7. Example . . . . . . . . . . . . . . . . . . . . . . . 25 116 6.3. Filtered Multi-Cost Map . . . . . . . . . . . . . . . . . 26 117 6.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 26 118 6.3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 26 119 6.3.3. Input Parameters . . . . . . . . . . . . . . . . . . 26 120 6.3.4. Capabilities . . . . . . . . . . . . . . . . . . . . 28 121 6.3.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 29 122 6.3.6. Response . . . . . . . . . . . . . . . . . . . . . . 29 123 6.3.7. Example 1 . . . . . . . . . . . . . . . . . . . . . . 30 124 6.3.8. Example 2 . . . . . . . . . . . . . . . . . . . . . . 31 125 6.4. Endpoint Multi-Cost Service . . . . . . . . . . . . . . . 32 126 6.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . 32 127 6.4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 32 128 6.4.3. Input Parameters . . . . . . . . . . . . . . . . . . 32 129 6.4.4. Capabilities . . . . . . . . . . . . . . . . . . . . 33 130 6.4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 33 131 6.4.6. Response . . . . . . . . . . . . . . . . . . . . . . 34 132 6.4.7. Example . . . . . . . . . . . . . . . . . . . . . . . 34 133 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 134 7.1. Information for IANA on proposed Cost Types . . . . . . . 35 135 7.2. Information for IANA on proposed Endpoint Properties . . 36 136 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 137 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 138 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 139 9.2. Informative References . . . . . . . . . . . . . . . . . 36 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 142 1. Introduction 144 IETF has designed a new service called ALTO that provides guidance to 145 overlay applications, which have to select one or several hosts from 146 a set of candidates that are able to provide a desired resource. 147 This guidance is based on parameters that affect performance and 148 efficiency of the data transmission between the hosts, e.g., the 149 topological distance. The purpose of ALTO is to improve Quality of 150 Experience (QoE) in the application while reducing resource 151 consumption in the underlying network infrastructure. The ALTO 152 protocol conveys the Internet View from the perspective of a Provider 153 Network region that spans from a region to one or more Autonomous 154 System (AS). Together with this Network Map, it provides the 155 Provider determined Cost Map between locations of the Network Map. 156 Last, it provides the Ranking of Endpoints w.r.t. their routing cost. 158 Current ALTO Costs and their modes provide values that are seen to be 159 stable over a longer period of time, such as hopcount and 160 administrative routing cost to reflect ISP routing preferences. 161 Recently, new use cases have extended the usage scope of ALTO to 162 Content Delivery Networks, Data centers and applications that need 163 additional information to select their Endpoints or handle their 164 PIDs. 166 Thus a multitude of new Cost Types that better reflect the 167 requirements of these applications are expected to be specified, in 168 particular cost values that change more frequently than previously 169 assumed. 171 The ALTO protocol [RFC7285] restricts ALTO Cost Maps and Endpoint 172 Cost services to only one Cost Type and Cost Mode per ALTO request. 173 To retrieve information for several Cost Types, an ALTO client must 174 send several separate requests to the server. 176 It would be far more efficient, in terms of RTT, traffic, and 177 processing load on the ALTO client and server, to get all costs with 178 a single query/response transaction. Vector costs provide a robust 179 and natural input to multi-variate path computation as well as robust 180 multi-variate selection of multiple Endpoints. In particular, one 181 Cost Map reporting on N Cost Types is less bulky than N Cost Maps 182 containing one Cost Type each. This is valuable for both the storage 183 of these maps and their transmission. Additionally, for many 184 emerging applications that need information on several Cost Types, 185 having them gathered in one map will save time. 187 Along with multi-cost values queries, the filtering capabilities need 188 to be extended to allow constraints on multiple metrics. The base 189 protocol allows optional constraints in the input parameters to a 190 request for a Filtered Cost Map or the Endpoint Cost Service. The 191 'constraints' member is an AND-combination of expressions that all 192 apply to the (single) requested Cost Type. It is therefore necessary 193 to allow constraints on multiple metrics. Beyond that, applications 194 that are sensitive to several metrics and struggle with complicated 195 network conditions may need to arbitrate between conflicting 196 objectives such as routing cost and network performance. To address 197 this issue, this draft proposes to extend the base protocol by both 198 allowing to combine constraints on multiple metrics and relating 199 these constraints with a logical 'AND' and a logical 'OR'. This 200 allows an application to make compromises such as: "select solutions 201 with either (moderate 'hopcount' AND high 'routingcost') OR (higher 202 'hopcount' AND moderate 'routingcost')". 204 This draft is organized as follows: section 3 exposes use cases 205 motivating the introduction of new Cost Types and why multi-cost 206 transactions are useful. Section 4 identifies the core ALTO protocol 207 extensions that are required or recommended to support requests and 208 responses on multiple Cost Types in one single transaction. 209 Section 5 specifies the extended constraints on mutli-cost values. 210 Section 6 specifies the protocol extensions for Multi-Cost ALTO 211 transactions and provides examples. 213 2. Application Scope And Terminology 215 This draft generalizes the case of a P2P client to include the case 216 of a CDN client, a client of an application running on a virtual 217 server, a GRID application client and any Client having the choice in 218 several connection points for data or resource exchange. To do so, 219 it uses the term "Application Client" (AC). 221 This draft focuses on the use case where the ALTO client is embedded 222 in the Application Client or in some Application Endpoint tracker in 223 the network, such as a P2P tracker, a CDN request router or a cloud 224 computing orchestration system implemented in a logically centralized 225 management system. 227 It is assumed that Applications likely to use the ALTO service have a 228 choice in connection endpoints as it is the case for most of them. 229 The ALTO service is managed by the Network Provider (NP) and reflects 230 its preferences for the choice of endpoints. The NP defines in 231 particular the network map, the routing cost among Network Locations, 232 the cost types used to reflect it, and which ALTO services are 233 available at a given ALTO server. 235 This draft uses terms defined as follows: 237 o Endpoint (EP): can be a Peer, a CDN storage location, a physical 238 server involved in a virtual server-supported application, a Party 239 in a resource sharing swarm such as a computation Grid or an 240 online multi-party game. 242 o Endpoint Discovery (EP Discovery) : this term covers the different 243 types of processes used to discover the eligible endpoints. 245 o Network Service Provider (NSP): includes both ISPs, who provide 246 means to transport the data, and Content Delivery Networks (CDNs) 247 who care for the dissemination, persistent storage and possibly 248 identification of the best/closest content copy. 250 o ALTO transaction: a request/response exchange between an ALTO 251 Client and an ALTO Server. 253 o Application Client (AC): this term generalizes the case of a P2P 254 client to include the case of a CDN client, a client of an 255 application running on a virtual server, a GRID application client 256 and any Client having the choice in several connection points for 257 data or resource exchange. 259 3. Uses Cases For Using Multiple Costs 261 The ALTO protocol specification in [RFC7285] focuses on the basic use 262 case of optimizing routing costs in NSP networks. Upcoming use cases 263 however will require both new Cost Types and new Endpoint Properties. 264 Recent ALTO use cases now extend to CDNs, Data centers and other 265 applications that need additional information to select their 266 Endpoints or handle their PIDs. The needed Cost Types depend on the 267 QoE requirements that are specific to the applications. Moreover, 268 the cost values that they may use may change more rapidly than 269 assumed up to now. 271 The goal of this section is to describe forward looking use case 272 scenarios that are likely to benefit from ALTO, in order to motivate 273 the introduction of new Cost Types and Endpoint Properties as well as 274 the ALTO Multi-Cost extension. 276 3.1. Use Cases For Using Additional Costs 278 ALTO Cost Types and Endpoint Properties are registered in two 279 registries maintained by IANA. The ALTO Cost Type registry ensures 280 that the Cost Types that are represented by an ALTO Cost Map are 281 unique identifiers, and it further contains references to the 282 semantics of the Cost Type. The ALTO specification registers 283 'routingcost' as a generic measure for routing traffic from a source 284 to a destination. In a similar way the ALTO Endpoint Property 285 Registry ensures uniqueness of ALTO Endpoint Property identifiers and 286 provides references to particular semantics of the allocated Endpoint 287 Properties. Currently the 'pid' identifier is registered, which 288 serves as an identifier that allows aggregation of network endpoints 289 into network regions. Both registries accept new entries after 290 Expert Review. New entries should conform to the respective 291 syntactical requirements, and must include information about the new 292 identifier, the intended semantics, and the security considerations. 293 One basic example advocating for multiple Cost Type transactions is 294 an Application Client looking for destination Endpoints or Source/ 295 Destination PID pairs yielding jointly the lowest 'routingcost' and 296 path delay. We hereby assume that 'routingcost' values report some 297 monetary cost and that the Application Client chooses to rely on the 298 hopcount to reflect the path delay. 300 3.1.1. Delay Sensitive Overlay Applications 302 The ALTO working group has been created to allow P2P applications and 303 NSPs a mutual cooperation, in particular because P2P bulk file- 304 transfer applications have created a huge amount of intra-domain and 305 congestion on low-speed uplink traffic. By aligning overlay 306 topologies according to the 'routingcost' of the underlying network, 307 both layers are expected to benefit in terms of reduced costs and 308 improved Quality-of-Experience. 310 Other types of overlay applications might benefit from a different 311 set of path metrics. In particular for real-time sensitive 312 applications, such as gaming, interactive video conferencing or 313 medical services, creating an overlay topology with respect to a 314 minimized delay is preferable. However it is very hard for an NSP to 315 give accurate guidance for this kind of realtime information, instead 316 probing through end-to-end measurements on the application layer has 317 proven to be the superior mechanism. Still, a NSP might give some 318 guidance to the overlay application, for example by providing 319 statistically preferable paths, possibly with respect to the time of 320 day. Also static information like hopcount can serve as an indicator 321 for the delay that can be expected. Thus a Cost Type that can 322 indicate latency, without the need for end-to-end measurements 323 between endpoints, is likely to be useful. 325 3.1.2. Selection Of Physical Servers Involved In Virtualized 326 Applications 328 Virtualized applications in large Datacenters are supported by 329 virtualized servers that actually gather resources distributed on 330 several physical servers. The federation of these resources is often 331 orchestrated by a centralized entity that needs to select the 332 physical servers from or to which it will take resources. This 333 entity can be co-located with an ALTO Client that will request and 334 get the ALTO information on the network formed by the physical 335 servers. The physical servers can be assimilated to endpoints with 336 which the orchestration entity trades application resources or 337 content. These resources include computation resources, storage 338 capacity and path bandwidth between the physical servers. 340 Here too, the applications that are ran are diverse and may have 341 different and specific QoE requirements. The Endpoint selection 342 typically needs to consider both the computational resources at the 343 Endpoints and the resources e.g. in bandwidth on the transmission 344 paths to or among Endpoints. Thus the application QoE requirements 345 drive the Endpoint selection with more or less weight on QoE specific 346 metrics such as hopcount/delay, bandwidth and other resources, that 347 are typically combined with the routing cost and need to jointly 348 integrate the Endpoint and transmission path perspective in the 349 decision process, which is difficult to do with one single Cost Type. 351 3.1.3. CDN Surrogate Selection 353 Another use case is motivated through draft 354 [draft-jenkins-alto-cdn-use-cases-01]. The request router in today's 355 CDNs makes a decision about the surrogate or cache node to which a 356 content request should be forwarded. Typically this decision is 357 based on locality aspects, i.e. the request router tries to select 358 the surrogate node losest to the client. By using the 'routingcost' 359 Cost Type, an ALTO server allows an NSP to guide the CDN in selecting 360 the best cache node. This is particularly important as CDNs place 361 cache nodes deeper into the network (i.e., closer to the end user), 362 which requires finer grained information. Finally the provisioning 363 of abstracted network topology information across administrative 364 boundaries gains importance for cache federations. 366 While distance today is the predominant metric used for routing 367 decisions, other metrics might allow sophisticated request routing 368 strategies. For example the load a cache node sees in terms of CPU 369 utilization, memory usage or bandwidth utilization might influence 370 routing decisions for load-balancing reasons. There exist numerous 371 ways of gathering and feeding this kind of information into the 372 request routing mechanism. 374 For example, information reporting on the occupation level of a cache 375 could be based on a cost reflecting: its remaining computation 376 resources, its remaining storage capacity w.r.t its capacity in 377 storage or computation resources. 379 As ALTO is likely to become a standardized interface to provide 380 network topology information, the ALTO server could also provide 381 other information that a request router needs. In the next 382 iterations of this draft we will analyse which of these metrics is 383 suitable as a Cost Type or Endpoint Property for CDN Surrogate 384 Selection, and propose to register them in the respective registries. 386 3.1.4. Some Proposed Additional Properties And Costs 388 In addition to CDN caches, Endpoint Properties and Costs can be 389 useful to report an Endpoint's load, given that an Endpoint can as 390 well be a physical server in a datacenter or any entity as defined in 391 Section 2 of this draft. 393 Proposed new Endpoint properties and costs include: 395 o an Endpoint Property called "EP-Capacity", reflecting the nominal 396 capacity of this endpoint. This capacity could be split into: 398 * EP-Nominal-Memory: the storage capacity of the Endpoint. 400 * EP-Nominal-Bandwidth: the capacity of the computation resources 401 of the Endpoint. 403 o an Endpoint Cost called "EP-Occupied-Capacity", reflecting the 404 currently available resources w.r.t. their nominal capacity. As 405 with EP-Capacity, this can be split into: 407 * EP-Occupied-Memory: the remaining storage capacity, 409 * EP-Occupied-Bandwidth: the remaining computation resources. 411 Likewise, new Cost Types are needed to describe the resources of the 412 network paths needed for content transport, in particular the 413 utilized network path bandwidth. 415 o A Cost Type named 'pathoccupationcost' (POC) can be used to 416 reflect the NP view of the utilized path bandwidth. Such an ALTO 417 Cost Type is likely to have values that change frequently. By no 418 means, as stated in the ALTO requirements, are ALTO Cost types 419 expected to reflect real-time values, as these can be gathered by 420 other mechanisms. Instead, a Cost Type such as 421 'pathoccupationcost' should be used as an abstraction that may be 422 represented by a statistical value, or be updated regularly at a 423 frequency lower than 'real-time', or be provided according to 424 different time periods or other parameters. A provision mode for 425 time dependent cost values is proposed in 426 [draft-randriamasy-alto-cost-schedule-01] 428 3.2. Use Cases For Multi-Cost ALTO Transactions 430 Different Cost Types are suitable for different applications. For 431 example, delay sensitive applications look for both low routing cost 432 and low delay, where as other applications, such as non real time 433 content download, look for moderate delay and minimal losses. On the 434 other hand, applications or entities managing application input 435 information may want, for various reasons to update their ALTO 436 information on several Cost Types. So an ALTO Client may want to mix 437 Cost Types in either 'numerical' and 'ordinal' mode, for Cost Types 438 values that can be represented by numerical values. 440 The Multi-Cost ALTO Services propose to: 442 o include several Cost Types (and/or Cost Modes) in an ALTO client's 443 Cost Map and Endpoint Cost request, 445 o provide several Cost Type values (and/or Cost Mode) in an ALTO 446 server's response, instead of one. 448 The primary reasons to use Multi-Cost ALTO are: 450 o Optimizing time and bandwidth: a single ALTO response with a 451 Multi-Cost cost map with three separate Cost Type values takes 452 much less network bandwidth, and fewer CPU cycles, than three 453 separate ALTO requests for three complete single-cost cost maps. 454 The motivation also holds for the Endpoint Cost Service. Multi- 455 Cost ALTO services can straightforwardly provide a more complete 456 set of cost information. 458 o Facing unpredictable and/or rapid value changes: an ALTO client 459 can get a consistent snapshot of several different rapidly-varying 460 Cost Type values. 462 3.2.1. Optimized Endpoint Cost Service 464 The Endpoint Cost Service (ECS) provides cost information about both 465 the application Endpoint resources and the networking resources used 466 to access those Endpoints. In addition, the ECS may be invoked in 467 "short term" situations, that is for frequent requests and/or 468 requests requiring fast responses. For the ECS, the server's 469 response is restricted to the requested Endpoints, and so is much 470 smaller than a complete Cost Map. Therefore the ECS can be invoked 471 for 'nearly-instant' information requests, and is particularly well 472 suited for multi-cost ALTO transactions, supporting requests and 473 responses on several Cost Type values simultaneously. 475 3.2.2. Optimized Filtered Cost Map Service 477 The set of ALTO Cost Types is not restricted to 'routingcost': ALTO 478 Servers may provide a broader set of metrics. One thing to consider 479 is that the frequency of updates can vary from a Cost Type to another 480 one. Additionally the volume of an entire cost map with values of 481 all available Cost Types, may get rapidly prohibitive for frequent 482 downloads. Given these considerations the Application Client may 483 take better advantage when: 485 o requesting multi-cost maps filtered w.r.t. Cost Types of 486 compatible update frequencies or dates, which is the 487 responsibility of the Application Client, 489 o requesting multi-cost maps filtered w.r.t. a restricted set of PID 490 pairs. 492 In such a case, as with the Endpoint Cost Service, the purpose of a 493 Multi-Cost transaction is to gain time with whatever future use of 494 the received ALTO information. In this case, the Client may mix Cost 495 Types in either 'numerical' and 'ordinal' mode, for Cost Type values 496 that can be represented by numerical values. 498 3.2.3. Cases Of Unpredicable Endpoint Cost Value Changes 500 Querying all Endpoint cost values simultaneously is always more time 501 and resources efficient than doing it sequentially. 503 It becomes a necessity in case of unpredictable and/or rapid value 504 changes on at least one of the ALTO Cost Types. The term 'rapid' 505 here means "Typical update intervals [that] may be several orders of 506 magnitude longer than the typical network-layer packet round-trip 507 time (RTT)", as described in [RFC6708], up to a couple of minutes. 509 This section provides two examples of a delay sensitive application 510 using 'routingcost' and 'hopcount' to select an Endpoint. The 511 application can choose between two candidate Endpoints, EP1 and EP2. 512 The initial choice at T=1 is EP1. It is assumed that at T=2 events 513 in the network occur that impact both 'routingcost' and 'hopcount'. 515 These examples illustrate the need to query 'hopcount' and 516 'routingcost' values at the same time in order to re-evaluate the EP 517 costs w.r.t. the QoE needs of the application. It is assumed that 518 the application triggers regular ALTO requests to get the latest cost 519 values for a list of candidate Endpoints. 521 In some cases the Application client wants to use the ALTO 522 information to perform multi-variate optimization on several Cost 523 Type values. In order for the optimization to be reliable, it is 524 recommended that the Cost Type values are provided in 'numerical' 525 Cost Mode. Therefore the requested Cost Mode for the applicable Cost 526 Types SHOULD be 'numerical'. 528 3.2.3.1. Case Of A Multi-Cost ALTO Query Upon A Route Change 530 In Figure 1, initially at time T=1, the application has chosen EP1 531 rather than EP2, despite the higher routing cost, because EP1 has a 532 "better" (lower) 'hopcount' value and despite the higher routing cost 533 and possibly because the application has set a higher weight to 534 'hopcount'. 536 At a time T=2, the route to EP1 changes. The ALTO Server information 537 is accordingly updated. The ALTO client makes its next request to 538 update the cost values for 'routingcost' and 'hopcount' on EP1 and 539 EP2. It appears that EP1 has now a hopcount value of 3, the same 540 than for EP2 while its routing cost is higher. 542 The application realizes that there is no more benefit in keeping 543 interacting with EP1 and therefore switches to EP2, that now has the 544 same hopcount but a lower routing cost. 546 T = 1 : EP1: routingcost = 40, hopcount = 2 547 EP2: routingcost = 30, hopcount = 3 549 EP1 is selected because application is time-sensitive and 550 metric 'hopcount' has a higher weight 552 .-----. 553 O ---------- O ------------- | EP2 | 554 / `-----' 555 / 556 / .-----. 557 Source ----------------------- O ---- | EP1 | 558 `-----' 560 T = 2 : EP1: routingcost = 40, hopcount = 3 561 EP2: routingcost = 30, hopcount = 3 563 - Route to EP1 has changed. Hopcount is now 3 565 ==> EP2 is selected because routingcost is lower than for 566 EP1, with the same hopcount value 567 .-----. 568 O ---------- O -------------| EP2 | 569 / \ `-----' 570 / `-----. 571 / `------. .-----. 572 Source ---------- X --------- [O] ---- | EP1 | 573 `-----' 575 Figure 1: Endpoint re-selection using Multi-Cost ALTO request on 576 updated cost values, upon a chnage in the route. 578 3.2.3.2. Case Of A Multi-Cost ALTO Query Upon A Cost Value Change 579 T = 1 : EP1: routingcost = 30, hopcount = 2 580 EP2: routingcost = 30, hopcount = 3 581 ==> EP1 is selected because application is time-sensitive and 582 hopcount metrics has higher weight 584 .-----. 585 O ---------- O ------------- | EP2 | 586 / `-----' 587 / 588 / .-----. 589 O ------------------------ O ---- | EP1 | 590 `-----' 592 T = 2 : EP1: routingcost = 40, hopcount = 2 593 EP2: routingcost = 30, hopcount = 3 594 Routingcost to EP1 has increased. Hopcount is the same. 595 ==> Delay sensitive applications willing to minimize hopcount 596 remain with EP1 while other applications may remain 597 with EP2, that now has a lower routingcost. 599 .-----. 600 O ---------- O -------------| EP2 | 601 / `-----' 602 / 603 / .-----. 604 O ------------------------ O ---- | EP1 | 605 `-----' 606 Figure 2: Endpoint selection using 2 Cost Types with joint request on 607 updated cost values and for delay sensitive applications. 609 4. ALTO Protocol Updates Needed To Support Multi-Cost Transactions 611 To allow running Multi-Cost ALTO Services some minor changes in the 612 base protocol are needed. The main updates consist of changing the 613 JSON type of the value taken by the costs and add a few members to 614 the objects describing the information resources, client requests and 615 server responses to Multi-Cost information services. 617 As written in the introduction, this section relies on 618 Section {11.2.3.6} of the ALTO protocol draft, see [RFC7285] , which 619 allows protocol extensions to encode cost values as the 'JSONValue' 620 data type. 622 4.1. List Of ALTO Protocol Updates Required And Recommended 624 The following updates to the ALTO protocol ([RFC7285]) are required 625 or recommended to support multi-cost ALTO transactions. The new 626 resulting JSON formats are specified in the next sections. 627 Section references ({##}) are to the ALTO protocol document. 629 The applicable ALTO information resources are: Cost Map, Filtrered 630 Cost Map and Endpoint Cost Map, becoming respectively Multi-Cost Map, 631 Filtered Multi-Cost Map and Endpoint Multicost Map provided with the 632 same media-type. 634 o Updates required in the format of objects member(s): 636 * Objects DstCosts (to destination PIDs, {11.2.3.6}) and 637 EndpointDstCosts (to destination Endpoints, {11.5.1.6}): the 638 cost value member evolves to an array of JSONValues. 640 * Object ReqFilteredCostMap {11.3.2.3} and ReqEndpointCostMap 641 {11.5.1.3}: a new member named "multi-cost-types" is 642 introduced. This member is an array of 1 or more cost types 643 for which a Multi-Cost ALTO Client requests values. Each cost 644 type of the array is encoded as specified in {10.7}. 646 o Updates recommended in the object structure: 648 * The capabilities for the Filtered Cost Map Service {11.3.2.4} 649 and the Endpoint Cost Map Service {11.5.1.4} need to be 650 extended with a new member entitled "max-cost-types" giving the 651 maximum number of Cost Types allowed in a Multi-Cost request 652 and response. 654 * The capabilities for the Multi Cost Map Service need to include 655 a new member named "multi-cost-type-names" and giving the list 656 of Cost Types that are provided in a Multi-Cost Map requested 657 via a GET method. 659 * The capabilities for the Cost Map Service, the Filtered Cost 660 Map Service {11.3.2.4} and the Endpoint Cost Map Service 661 {11.5.1.4} need to be extended with a new member named "multi- 662 cost-type-names" and giving the list of Cost Types that may be 663 included in the constraints member of a request. 665 * In a Server response to {11.3.2.6} filtered cost map request 666 and {11.5.1.6} and to filtered endpoint cost service request: a 667 new member named "multi-cost-types" and described above is 668 added to the "meta" field of the response. 670 o Rules required on object member description: 672 * Order in which the multiple cost values are provided in the 673 responses. 675 4.2. Updates Required In The Member Format Of Objects 677 This section specifies the changes in the object member format that 678 are required to enable multi-cost ALTO transactions. 680 The term Single Cost qualifies the items as they are specified in the 681 current ALTO protocol. 683 4.2.1. Cost Value Encoded In array of JSON values 685 The fundamental change to support multi-cost is to encode the cost 686 values as an array of JSONValues. This way, the cost between two 687 PIDs or two Endpoints can be represented in a generic way: 689 o with several Cost Types, 691 o with Cost Types whose value can each be encoded with any type of 692 JSON value. 694 For example, a multi-cost value represented with Cost Types (assuming 695 they are supported by the ALTO Server): 697 ["num-routingcost", "num-hopcount", "string-status"] 699 will be encoded in the following JSON Array in a Multi Cost ALTO 700 response: 702 [23, 6, "medium"] 704 The objects impacted by the encoding of ALTO Multi-Cost values in a 705 JSONArray are: DstCosts and EndpointDstCosts. Full specification 706 will be provided in later sections of this draft. 708 4.2.2. Scalar 'cost-type' Member Replaced By Array 'multi-cost-types' 709 Member 711 In the base protocol, the various single-cost-map services use a 712 scalar "cost-type" member in the "meta" section to indicate the cost 713 metric and cost mode of the returned values. 715 In Multi-Cost ALTO, the multi-cost-map services use an array member 716 named "cost-types" instead. The array elements are in the same 717 format as the "cost-type" member in single cost maps, and the order 718 corresponds to the order of values in the array values in the multi- 719 cost map. 721 Alternatively, we could use the same member name, but define it as an 722 array for multi-cost services. This would simplify some things for a 723 client, but complicate others. Overall, we believe it is easier for 724 a client to use a new member name than to overload the type of an 725 existing member name. 727 4.2.3. Rule On Cost Value Order In ALTO Reponses 729 The cost values each Source/Destination pair MUST be provided in the 730 same order as in the array of Cost Types. This way, the cost type 731 values are provided without any ambiguity on the Cost Type they 732 report on. 734 4.3. Updates Recommended In The Object Structure 736 Objects MultiCostMapCapability {11.2.3.4} and 737 FilteredMultiCostMapCapability {11.3.2.4}: are extended with: 739 o a new member a new member entitled "max-cost-types" giving the 740 maximum number of Cost Types allowed in a Multi-Cost request and 741 response and giving the maximum number of Cost Types in a 742 response. The default value is set to 1 to avoid a multi-cost 743 aware client requesting a multi-cost map from a server that does 744 not support them. 746 o a new member named "multi-cost-type-names" and giving the list of 747 Cost Types that are provided in a Multi-Cost Map requested via a 748 GET method. 750 5. Extended Constraints On Multi-Cost Values 752 This draft proposes to extend the constraint tests in the base 753 protocol to allow tests on the various costs in a request, and to 754 allow more general predicates. 756 NOTE: Constraint tests on multiple cost metrics are useful even when 757 retrieving single costs, and we expect there will be proposals to add 758 multi-cost constraint tests to the ALTO protocol, relating to the 759 extensions proposed in this draft. Draft 760 [draft-lee-alto-app-net-info-exchange] proposes in particular 761 extensions to query values on a metric M1 with constraints on other 762 metrics {M2, ... Mk}, that adds an interesting feature to extend ALTO 763 constraints. This motivates the need to augment the capabilities in 764 the IRD of the Filteredt Multi-Cost Map and Endpoint Multi-Cost Map 765 with the extensive list of Cost-Types that may be included in the 766 constraints of requests. 768 The base ALTO protocol allows optional contraints in the input 769 parameters to a request for a Filtered Cost Map or the Endpoint Cost 770 Service. The 'constraints' member is an array of expressions that 771 all apply to the (single) requested Cost Type. The encoding of 772 'constraints' member, is fully specified in Section 11.3.2.3 of the 773 base protocol as follows: 775 A constraint contains two entities separated by whitespace: 776 (1) an operator,'gt' for greater than, 'lt' for less than, 777 'ge' for greater than or equal to, 'le' for less than or equal to, 778 or 'eq' for equal to 779 (2) a target cost value. The cost value is a number that MUST be 780 defined in the same units as the Cost Type indicated by the costtype 781 parameter 782 ... 783 If multiple 'constraint' parameters are specified, they are 784 interpreted as being related to each other with a logical AND. 786 Such a specification covers multiple predicates on one metric such 787 as: 789 'routingcost' values belong to [6, 20) 791 5.1. Use Cases For Multi-Cost Multi-Operator Constraints 793 Suppose that an application uses information on the ALTO Cost Types 794 'hopcount' and 'routingcost'. This application may want to select 795 paths or Endpoints with bounds on values for both 'hopcount' and 796 'routingcost'. For instance solutions meeting a constraint like: 798 'hopcount' values in [6,20) OR 'routingcost' values in [100,200] 800 Moreover, this application may be ready to make compromises and to 801 select paths or Endpoints by bounding their cost values according to 802 two options: 804 1. either solutions with moderate 'hopcount' and high 'routingcost', 805 for instance: 'hopcount' values in [6,20] AND 'routingcost' 806 values in [100,200], 808 2. or solutions with higher 'hopcount' and moderate 'routingcost', 809 for instance: 'hopcount' values in [20,50] AND 'routingcost' 810 values in [30,100]. 812 5.2. Extended constraints in Multi-Cost ALTO 814 This draft proposes to support the two above mentioned use cases by 815 extending the scope of constraints in two ways: 817 o allow the 'constraint' member to be applicable to multiple Cost 818 Types, 820 o allow the multiple constraints to be related to each other by both 821 logical AND and logical OR. 823 The two options would be covered by a logical expression like: 825 [('hopcount' ge 6) AND ('hopcount' lt 20) AND 826 ('routingcost' ge 100) AND ('routingcost' le 200)] 827 OR 828 [('hopcount' ge 20) AND ('hopcount' le 50) AND 829 ('routingcost' ge 30) AND ('routingcost' le 100)] 831 A simple encoding of multi-cost constraints for such expressions is 832 specified in Section 5.3.3 of this draft, describing the input 833 parameters to request for Filtered Cost Map. This specification is 834 applicable to the EP Cost service as well. 836 6. Protocol Extensions for Multi-Cost ALTO Transactions 838 This section proposes extensions of the ALTO protocol to support 839 Multi Cost ALTO Services or provide additional ALTO information. It 840 integrates discussions on the ALTO mailing list. 842 If an ALTO client desires information on several Cost Types, then 843 instead of placing as many requests as costs, it may request and 844 receive all the desired Cost Types in one single transaction. 846 The ALTO server then, provided it supports the requested Cost Types, 847 and provided it supports multi-cost ALTO transactions, sends one 848 single response where for each {source, destination} pair, the cost 849 values are arranged in an array, where each component corresponds to 850 a specified Cost Type. The correspondence between the components and 851 the Cost Types is implicitly indicated in the ALTO response. Indeed, 852 the values in the Cost values MUST be provided in the same order as 853 in the array of cost types indicated in the response. 855 The following ALTO services have corresponding Multi-Cost extensions: 857 o Information Resources Directory: extended with multi-cost related 858 URIs and associated capabilities. 860 o Cost Map Service: extended with the Multi-Cost Map Service, 862 o Cost Map Filtering Service: extended with the Multi-Cost Map 863 Filtering Service, 865 o Endpoint Cost Lookup Service: extended with the Endpoint Multi- 866 Cost Lookup Service. 868 6.1. Information Resources Directory 870 When the ALTO server supports the provision of information on 871 multiple costs in a single transaction, the Information Resources 872 Directory will list the corresponding resources. The media type 873 remains the same as in the current ALTO protocol. 875 6.1.1. Example of Multi-Cost specific resources in the IRD 877 The following is an example Information Resource Directory returned 878 by an ALTO Server and containing Multi-Cost specific services: the 879 Multi-Cost Map Service, Filtered Multi-Cost Map and the Endpoint 880 Multi-Cost Service. It is assumed that the IRD contains usual ALTO 881 Services as described in the example IRD of the current ALTO 882 protocol. In this example, the ALTO Server can additionally provide 883 Multi-Cost Services in a specific folder of "alto.example.com" called 884 "multi". This folder contains the Multi-Cost Maps, Filtered Multi- 885 Cost Maps as well as the Endpoint Multi-Cost Service. 887 In this example, the ALTO IRD exposes Multi-Cost capabilities on cost 888 types "num-routingcost", "num-hopcount", "num-pathoccupationcost", 889 that can be combined in a request. The values on these metrics are 890 provided in numerical mode. Values provided for cost-type string are 891 in "string" mode. 893 For the "filtered-multicost-map" resource and the "endpoint- 894 multicost-map" resource, the IRD exposes in its capabilities a member 895 noted "testable-cost-types" that is the list of cost-types that are 896 allowed to be included in the constraints of a request. Note that 897 this set may be different than the set "multi-cost-type-names". The 898 "endpoint-multicost-map" resource provides cost-values for Cost Types 899 "num-routingcost", "num-hopcount" and "str-status" and supports 900 constraints on "num-routingcost", "num-hopcount", "num- 901 pathoccupationcost" where as it does not provide values on "num- 902 pathoccupationcost" and does not supports constraints on "str- 903 status". 905 GET /directory HTTP/1.1 906 Host: alto.example.com 907 Accept: application/alto-directory+json,application/alto-error+json 909 HTTP/1.1 200 OK 910 Content-Length: [TODO] 911 Content-Type: application/alto-directory+json 913 { 914 "meta" : { 915 "cost-types" : { 916 "num-pathoccupationcost" : { 917 "cost-mode" : "numerical", 918 "cost-metric" : "pathoccupationcost" 919 }, 920 "str-status" : { 921 "cost-mode" : "string", 922 "cost-metric" : "status" 923 }, 924 "num-routing" : { 925 "cost-mode" : "numerical", 926 "cost-metric" : "routingcost" 927 }, 928 "num-hopcount" : { 929 "cost-mode" : "numerical", 930 "cost-metric" : "hopcount" 931 }, 932 ..... 933 Other ALTO cost types as described 934 in current ALTO Protocol 935 ..... 936 }, 937 "default-alto-network-map" : "my-default-network-map" 938 }, 939 "resources" : { 940 "my-default-network-map" : { 941 "uri" : "http://alto.example.com/networkmap", 942 "media-type" : "application/alto-networkmap+json" 943 }, 944 "numerical-routing-cost-map" : { 945 ..... 946 Single-cost Services as described 947 in current ALTO Protocol 948 ..... 950 }, 951 "rc-hc-multicost-map" : { 952 "uri" : "http://alto.example.com/multi/costmap", 953 "media-types" : ["application/alto-costmap+json"], 954 "uses" : [ "my-default-network-map" ], 955 "capabilities" : { 956 "multi-cost-type-names" : [ "num-routing", "num-hopcount" ] 957 } 958 }, 959 "filtered-multicost-map" : { 960 "uri" : "http://alto.example.com/multi/costmap/filtered", 961 "media-types" : ["application/alto-costmap+json" ], 962 "accepts" : ["application/alto-costmapfilter+json" ], 963 "uses" : [ "my-default-network-map" ], 964 "capabilities" : { 965 "cost-constraints" : true, 966 "max-cost-types" : 3, 967 "cost-type-names" : [ "num-routingcost", 968 "num-hopcount", 969 "num-pathoccupationcost" ], 970 "testable-cost-types": ["num-routingcost", 971 "num-hopcount", 972 "num-pathoccupationcost" ] 973 } 974 }, 975 "endpoint-multicost-map" : { 976 "uri" : "http://alto.example.com/multi/endpointcost/lookup", 977 "media-types" : [ "application/alto-endpointcost+json" ], 978 "accepts" : [ "application/alto-endpointcostparams+json" ], 979 "uses" : [ "my-default-network-map" ], 980 "capabilities" : { 981 "cost-constraints" : true, 982 "max-cost-types" : 3, 983 "cost-type-names" : [ "num-routingcost", 984 "num-hopcount", 985 "str-status" ], 986 "multi-cost-type-names" : [ "num-routingcost", 987 "num-hopcount", 988 "str-status"], 989 "testable-cost-types": ["num-routingcost", 990 "num-hopcount", 991 "num-pathoccupationcost" ] 992 } 993 } 994 } 995 } 997 6.2. Multi-Cost Map Service 999 This section introduces a new media-type for the Multi-Cost map. For 1000 each source/destination pair of PIDs, it provides the values of the 1001 different Cost Types supported for the Multi-Cost map, in the same 1002 order as in the list of Cost Types specified in the capabilities. 1004 A Multi-Cost Map MAY be provided by an ALTO Server. 1006 Note that the capabilities specify implicitly the order in which the 1007 different Cost Type values will be listed in the Cost Map. 1009 The Cost Type values in the responses are encoded as a JSONArray of 1010 cost values for the different Cost Types. 1012 Note that values in a Multi-Cost map are arrays of values of the 1013 various Cost Types. If the ALTO server does not have the value for a 1014 particular Cost Type for a source/destination PID pair, the server 1015 MUST use 'null' (a reserved JSON symbol) for that location in the 1016 array. If the ALTO server does not have a value for any of the Cost 1017 Types for a given source/destination pair -- that is, if the array 1018 would be a list of nulls -- then the ALTO server MAY omit the array 1019 for that source/destination pair. 1021 6.2.1. Media Type 1023 The media type is "application/alto-costmap+json". 1025 6.2.2. HTTP Method 1027 This resource is requested using the HTTP GET method. 1029 6.2.3. Input Parameters 1031 None. 1033 6.2.4. Capabilities 1035 The capabilities of the URI providing this resource are defined by a 1036 JSON object of type FilteredCostMapCapabilities:: 1038 object { 1039 JSONString multi-cost-type-names<1..*>; 1040 } MultiCostMapCapabilities; 1042 with members 1044 multi-cost-type-names The Cost Type names returned by this map. 1046 An ALTO Server MUST support all of the Cost Types listed here. Note 1047 that an ALTO Server may provide multiple Cost Map Information 1048 Resources, each with different capabilities. 1050 An ALTO Server supporting the Multi-Cost Map service MUST support the 1051 Cost mode 'numerical' for all supported Cost Types encoded with the 1052 'JSONNumber' type. 1054 A full cost map resource capabilities has either "cost-type-names" or 1055 "multi-cost-type-names", but not both. The former means it returns a 1056 Single Cost Map, the latter means it returns a multi-cost Map. Since 1057 this resource is requested via the GET method, the Server returns 1058 what it returns and the client has no choice. 1060 6.2.5. Uses 1062 The Resource ID of the Network Map which defines the PIDs used in 1063 this Multi Cost Map. An ALTO Server MUST NOT define two Multi Cost 1064 Maps with the same Network Map and set of Cost Types. 1066 6.2.6. Response 1068 The "meta" field of a Cost Map response MUST include the "dependent- 1069 vtags" key, whose value is a single-element array to indicate the 1070 Version Tag of the Network Map used, where the Network Map is 1071 specified in "uses" of the IRD. 1073 The "meta" MUST also include the member "multi-cost-types", which is 1074 a JSONArray of the CostTypes in this Multi Cost Map. 1076 The data component of a Multi Cost Map response is named "cost-map", 1077 which is a JSON object of type CostMapData, as defined in {11.2.3.6} 1078 of the ALTO protocol. This is identical to the format of the ALTO 1079 Cost Map response, except that the JSONValues are arrays rather than 1080 numbers. The values in the arrays correspond to the Cost Type listed 1081 at the same place in the 'multi-cost-types' array. This array MUST 1082 have the same size as the 'multi-cost-types' array, and the provided 1083 values MUST be in the same order as in the 'multi-cost-types' array. 1085 The returned Multi Cost Map MUST include the required Path Costs for 1086 each pair of Source and Destination PID for which this information is 1087 available. If a cost value is not defined, the ALTO Server MUST 1088 replace that value in the array with the reserved JSON symbol 'null'. 1089 If no costs are defined for a pair of Source and Destination PIDs, so 1090 the Path Cost would be an array of nulls, the ALTO Server MAY omit 1091 the array for that pair. 1093 6.2.7. Example 1095 This example illustrates a 'static' multi-cost ALTO transaction, 1096 where the utilized Cost Types all have 'static' values. We assume 1097 here that the Cost Types available at the ALTO Server are 1098 "routingcost" and "hopcount" and the 'numerical' mode is available 1099 for both of them. The "routingcost" may be based on monetary 1100 considerations where as the "hopcount" is used to report on the path 1101 delay. We also assume that ALTO server does not know the value of 1102 the "routingcost" between PID2 and PID3, and hence uses 'null' for 1103 those costs. 1105 GET /multicostmap/num HTTP/1.1 1106 Host: alto.example.com 1107 Accept: application/alto-costmap+json,application/alto-error+json 1109 HTTP/1.1 200 OK 1110 Content-Length: [TODO] 1111 Content-Type: application/alto-costmap+json 1113 { 1114 "meta" : { 1115 "dependent-vtags" : [ 1116 {"resource-id": "my-default-network-map", 1117 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1118 } 1119 ], 1120 "multi-cost-types" : [ 1121 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1122 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1123 ] 1124 } 1125 "cost-map" : { 1126 "PID1": { "PID1":[1,0], "PID2":[5,23], "PID3":[10,5] }, 1127 "PID2": { "PID1":[null,5], "PID2":[1,0], "PID3":[15,9] }, 1128 "PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0] } 1129 } 1130 } 1132 6.3. Filtered Multi-Cost Map 1134 A Multi-Cost Map may be very large. In addition, an Application 1135 Client assisted by the ALTO Client does not necessarily need the Cost 1136 Types for all the source/destination PID pairs. 1138 Therefore applications may more likely use Cost Map information 1139 filtered w.r.t. the Cost types as well as the source/destination 1140 pairs of PIDs. This section specifies Filtered Multi-Cost Maps. 1142 A Filtered Multi Cost Map is a Cost Map Information Resource for 1143 which an ALTO Client may supply additional parameters limiting the 1144 scope of the resulting Cost Map. A Filtered Multi Cost Map MAY be 1145 provided by an ALTO Server. 1147 6.3.1. Media Type 1149 The media type is "application/alto-costmap+json". 1151 6.3.2. HTTP Method 1153 This resource is requested using the HTTP POST method. 1155 6.3.3. Input Parameters 1157 Input parameters are supplied in the entity body of the POST request. 1158 This document specifies the input parameters with a data format 1159 indicated by the media type "application/alto-costmapfilter+json", 1160 which is a JSON Object of type ReqFilteredMultiCostMap, where: 1162 object { 1163 PIDName srcs<0..*>; 1164 PIDName dsts<0..*>; 1165 } PIDFilter; 1167 object { 1168 CostType multi-cost-types<1..*>; 1169 JSONString constraints<0..*>; [OPTIONAL] - TO BE UPDATED 1170 JSONArray or-constraints<0..*>; [OPTIONAL] 1171 PIDFilter pids; [OPTIONAL] 1172 } ReqFilteredMultiCostMap; 1174 with members: 1176 multi-cost-type-names The array of requested Cost Types for the returned costs. 1177 Each listed Cost Type MUST be one of the supported Cost Types 1178 indicated in this resource's capabilities. 1180 constraints 1181 As specified in section {11.3.2.3} of RFC7285. 1182 The Client MUST specify this member in its requests for 1183 single cost services as specified in RFC7285. 1184 The Client MUST NOT specify this member in requests for 1185 multi-cost services. 1186 The Client MUST NOT specify both a 'constraint' and 1187 an 'or-constraints' parameter. 1188 NB: THIS TEXT ON SUPPORT OF BASE PROTOCOL SINGLE COST CONSTRAINTS 1189 WILL BE UPDATED IN NEXT VERSIONS 1191 or-constraints 1192 Defines an array of arrays of constraint strings. 1193 This parameter MUST NOT be specified if this resource's capabilities 1194 indicate that constraint support is not available. 1195 A constraint string is an array of additional constraints. 1196 That is the constraint strings of the array are related by 1197 logical ANDs. Each string in the 1198 constraint array MUST contain three entities separated by 1199 whitespace, in the following format: 1200 [index] op value 1201 'Index' is a number between 0 and the number of Testable Cost 1202 Types minus 1, and indicates the Cost Type to which this 1203 constraint applies. (The square brackets ([]) surrounding 1204 'index' are required syntactic sugar. They serve as a 1205 reminder that 'index' is an array index, not a value to test, 1206 and they avoid unusual-looking constraints such as "1 ge 5".) 1207 'Op' is an operator: 'gt' for greater than, 'lt' for less 1208 than, 'ge' for greater than or equal to, 'le' for less than 1209 or equal to, 'eq' for equal to, or 'ne' for not equal to. 1210 'Value' is a target cost value to compare against the 1211 indicated Cost Type. For numeric Cost Types, 'value' MUST be 1212 a number defined in the same units as the Cost Type indicated 1213 by 'index'. ALTO servers SHOULD use at least IEEE 754 1214 doubleprecision floating point [IEEE.754.2008] to store the 1215 cost value, and SHOULD perform internal computations using 1216 double-precision floating-point arithmetic. For string Cost 1217 Types, 'value' MUST be a string enclosed in single quotes ('). 1218 For array-valued Cost Types, 'eq' is true iff one of the 1219 Cost Type values is equal to 'value', and 'ne' is true iff 1220 none of the Cost Type values are equal to 'value'. The other 1221 operators are not defined for array-valued Cost Types. 1223 The "or-constraints" member defines an array of arrays of 1224 constraint strings in the format : [index] op value 1225 The ALSO server MUST return costs that satisfy all constraints 1226 in one or more of the inner lists, and no other costs. That is, 1227 'or-constraints' is the logical OR of ANDs. 1229 pids A list of Source PIDs and a list of Destination PIDs for which 1230 Path Costs are to be returned. If a list is empty, the ALTO 1231 Server MUST interpret it as the full set of currently-defined 1232 PIDs. The ALTO Server MUST interpret entries appearing in a list 1233 multiple times as if they appeared only once. If the "pids" 1234 member is not present, both lists MUST be interpreted by the ALTO 1235 Server as containing the full set of currently-defined PIDs. 1237 6.3.4. Capabilities 1239 The URI providing this resource supports all capabilities documented 1240 in Section 6.2.4 (with identical semantics), plus additional 1241 capabilities. In particular, the capabilities are defined by a JSON 1242 object of type FilteredMultiCostMapCapability: 1244 object { 1245 JSONString cost-type-names<1..*>; 1246 JSONString multi-cost-type-names<1..*>; 1247 JSONBool cost-constraints; 1248 JSONNumber max-cost-types; [OPTIONAL] 1249 } FilteredMultiCostMapCapability; 1251 with members: 1253 cost-type-names 1254 The array of cost types available from this service. 1256 multi-cost-type-names 1257 The array of cost types available from this service. 1258 Its resence means that this resource can return 1259 a multi-cost map. A filtered cost map resource can have 1260 either "cost-type-names" or "multi-cost-type-names" or both 1261 in its capabilities. The former means it can return a single 1262 cost map, the latter a multi cost. The Client selects which. 1264 max-cost-types Indicates the maximum number of cost values 1265 the ALTO Server can provide in a multi-cost array of a 1266 Multi-Cost Map. 1268 cost-constraints If true, then the ALTO Server allows cost 1269 constraints to be included in requests to the corresponding URI. 1270 If not present, this member MUST be interpreted as if it specified 1271 false. 1273 Note that a filtered cost map resource can have either "cost-type- 1274 names" or "multi-cost-type-names" or both in its capabilities. The 1275 former means it can return a single cost map, the latter a multi 1276 cost. The Client selects which one its wants. 1278 6.3.5. Uses 1280 The Resource ID of the Network Map which defines the PIDs used in 1281 this Filtered Multi Cost Map. 1283 6.3.6. Response 1285 The response is the same format as for the Multi Cost Map Service 1286 (Section 6.2.6). The returned Cost Map MUST NOT contain any source/ 1287 destination pair that was not indicated (implicitly or explicitly) in 1288 the input parameters. If the input parameters contain a PID name 1289 that is not currently defined by the ALTO Server, the ALTO Server 1290 MUST behave as if the PID did not appear in the input parameters. If 1291 any constraints are specified, Source/Destination pairs for which the 1292 Path Costs do not meet the constraints MUST NOT be included in the 1293 returned Cost Map. If no constraints were specified, then all Path 1294 Costs are assumed to meet the constraints. 1296 6.3.7. Example 1 1298 POST multi/multicostmap/filtered HTTP/1.1 1299 Host: alto.example.com 1300 Content-Type: application/alto-costmapfilter+json 1301 Accept: application/alto-costmap+json,application/alto-error+json 1303 { 1304 "multi-cost-types" : [ 1305 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1306 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1307 ], 1308 "pids" : { 1309 "srcs" : [ "PID1" ], 1310 "dsts" : [ "PID1", "PID2", "PID3" ] 1311 } 1312 } 1314 HTTP/1.1 200 OK 1315 Content-Length: [TODO] 1316 Content-Type: application/alto-costmap+json 1318 { 1319 "meta" : { 1320 "dependent-vtags" : [ 1321 {"resource-id": "my-default-network-map", 1322 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1323 } 1324 ], 1325 "multi-cost-types" : [ 1326 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1327 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1328 ] 1329 } 1330 "cost-map" : { 1331 "PID1": { "PID1": [1,6], "PID2": [5,23], "PID3": [10,5] } 1332 } 1333 } 1335 6.3.8. Example 2 1337 This is an example of using constraints to restrict returned source/ 1338 destination PID pairs to those with 'routingcost' between 5 and 10, 1339 or 'hopcount' equal to 0. 1341 POST multi/multicostmap/filtered HTTP/1.1 1342 Host: alto.example.com 1343 Content-Type: application/alto-costmapfilter+json 1344 Accept: application/alto-costmap+json,application/alto-error+json 1346 { 1347 "multi-cost-types" : [ 1348 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1349 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1350 ], 1351 "or-constraints" : [ ["[0] ge 5", "[0] le 10"], 1352 ["[1] eq 0"] ] 1353 "pids" : { 1354 "srcs" : [ "PID1", "PID2" ], 1355 "dsts" : [ "PID1", "PID2", "PID3" ] 1356 } 1357 } 1359 HTTP/1.1 200 OK 1360 Content-Length: [TODO] 1361 Content-Type: application/alto-costmap+json 1363 { 1364 "meta" : { 1365 "dependent-vtags" : [ 1366 {"resource-id": "my-default-network-map", 1367 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1368 } 1369 ], 1370 "multi-cost-types" : [ 1371 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1372 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1373 ] 1374 } 1375 "cost-map" : { 1376 "PID1": { "PID2": [5,23], "PID3": [10,5] } 1377 "PID2": { "PID2": [1,0] }, 1378 } 1379 } 1381 6.4. Endpoint Multi-Cost Service 1383 The Endpoint Multi-Cost Service provides information on several Cost 1384 Types between individual Endpoints. 1386 This service MAY be provided by an ALTO Server. It is important to 1387 note that although this resource allows an ALTO Server to reveal 1388 costs between individual endpoints, an ALTO Server is not required to 1389 do so. A simple alternative would be to compute the cost between two 1390 endpoints as the costs between the PIDs corresponding to the 1391 endpoints if these values are available for the requested Cost Types. 1393 When the cost values are requested to perform multi-variate numerical 1394 optimization and are each available in the 'numerical' mode, then the 1395 ALTO Client SHOULD request the 'numerical' mode in order to get a 1396 reliable result. Note that this consideration is outside the scope 1397 of the ALTO protocol as it relates to the responsibility of the ALTO 1398 Client and related entries. However common sense lead to warn that a 1399 necessary condition for vector ranking method to be reliable is that 1400 the components of the processed vectors are numerical and not ordinal 1401 values. 1403 6.4.1. Media Type 1405 The media type is "application/alto-endpointcost+json". 1407 6.4.2. HTTP Method 1409 This resource is requested using the HTTP POST method 1411 6.4.3. Input Parameters 1413 Input parameters are supplied in the entity body of the POST request. 1414 This document specifies input parameters with a data format indicated 1415 by media type "application/alto-endpointmulticostparams+json", which 1416 is a JSON Object of type ReqEndpointMultiCostMap: 1418 object { 1419 TypedEndpointAddr srcs<0..*>; [OPTIONAL] 1420 TypedEndpointAddr dsts<1..*>; 1421 } EndpointFilter; 1423 object{ 1424 CostType multi-cost-types<1..*>; 1425 JSONString constraints<0..*>; [OPTIONAL] // TO BE UPDATED 1426 JSONArray or-constraints<0..*>; [OPTIONAL] 1427 EndpointFilter endpoints; 1428 } ReqEndpointMultiCostMap; 1430 with members: 1432 multi-cost-types Defined equivalently to the "cost-types" 1433 input parameter of a Filtered Multi Cost Map. 1435 constraints Defined equivalently to the "constraints" 1436 input parameter of a Filtered Multi Cost Map. 1438 or-constraints Defined equivalently to the "or-constraints" 1439 input parameter of a Filtered Multi Cost Map. 1441 endpoints A list of Source Endpoints and Destination Endpoints for 1442 which Path multiple Costs are to be returned. If the list 1443 of Source Endpoints is empty (or not included), the ALTO Server 1444 MUST interpret it as if it contained the Endpoint Address 1445 corresponding to the client IP address from the incoming 1446 connection (see Section 10.3 for discussion and considerations 1447 regarding this mode). The list of destination Endpoints 1448 MUST NOT be empty. The ALTO Server MUST interpret entries 1449 appearing multiple times in a list as if they appeared only once. 1451 6.4.4. Capabilities 1453 The capabilities are the same as described in Section 6.3.4. 1455 6.4.5. Uses 1457 As with the ALTO Endpoint Cost Service, the Endpoint Multi Cost 1458 Service MUST NOT use a Network Map. 1460 6.4.6. Response 1462 The "meta" field of an Endpoint Multi Cost response MUST include the 1463 "multi-cost-types" key, to indicate the Cost Types used. 1465 The data component of an Endpoint Multi Cost response is named 1466 "endpoint-cost-map", which is a JSON object of type 1467 EndpointCostMapData, as defined in Section 11.5.1.6 of the ALTO 1468 protocol. This is identical to the format of the ALTO Cost Map 1469 response, except that the JSONValues are arrays rather than numbers. 1470 The values in the arrays correspond to the Cost Type listed at the 1471 same place in the 'multi-cost-types' array. This array MUST have the 1472 same size as the 'multi-cost-types' array, and the values in the MUST 1473 be in the same order as in the 'multi-cost-types' array. 1475 6.4.7. Example 1477 This is an example of requesting jointly cost values for 1478 "routingcost" and "hopcount" while using constraints to restrict the 1479 returned source/destination endpoints to those with 1480 'pathoccupationcost' between 5 and 10, or 'hopcount' equal to 0, 1481 where 'pathoccupationcost' and 'hopcount' respectively have index 2 1482 and 1 in the "testable-cost-types" member of the IRD capabilities of 1483 the "endpoint-multicost-map" resource. Only 2 of the 3 requested 1484 source/destination pairs meet the constraints. 1486 POST multi/endpointmulticost/lookup HTTP/1.1 1487 Host: alto.example.com 1488 Content-Length: [TODO] 1489 Content-Type: application/alto-endpoincostparams+json 1490 Accept: application/alto-endpointcost+json,application/alto-error+json 1492 { 1493 "multi-cost-types" : [ 1494 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1495 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1496 ], 1497 "or-constraints" : [ ["[2] ge 5", "[2] le 10"], 1498 ["[1] eq 0"] ], 1499 "endpoints" : { 1500 "srcs": [ "ipv4:192.0.2.2" ], 1501 "dsts": [ 1502 "ipv4:192.0.2.89", 1503 "ipv4:198.51.100.34", 1504 "ipv4:203.0.113.45" 1505 ] 1506 } 1507 } 1508 HTTP/1.1 200 OK 1509 Content-Length: [TODO] 1510 Content-Type: application/alto-endpointcost+json 1512 { 1513 "meta" : { 1514 "dependent-vtags" : [ 1515 {"resource-id": "my-default-network-map", 1516 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1517 } 1518 ], 1519 "multi-cost-types" : [ 1520 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1521 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1522 ] 1523 } 1524 "endpoint-cost-map" : { 1525 "ipv4:192.0.2.2": { 1526 "ipv4:192.0.2.89" : [1, 7], 1527 "ipv4:203.0.113.45" : [3, 2] 1528 } 1529 } 1530 } 1532 7. IANA Considerations 1534 Information for the ALTO Endpoint property registry maintained by the 1535 IANA and related to the new Endpoints supported by the acting ALTO 1536 server. These definitions will be formulated according to the syntax 1537 defined in Section on "ALTO Endpoint Property Registry" of [RFC7285], 1539 Information for the ALTO Cost Type Registry maintained by the IANA 1540 and related to the new Cost Types supported by the acting ALTO 1541 server. These definitions will be formulated according to the syntax 1542 defined in Section on "ALTO Cost Type Registry" of [RFC7285], 1544 7.1. Information for IANA on proposed Cost Types 1546 When a new ALTO Cost Type is defined, accepted by the ALTO working 1547 group and requests for IANA registration MUST include the following 1548 information, detailed in Section 11.2: Identifier, Intended 1549 Semantics, Security Considerations. 1551 7.2. Information for IANA on proposed Endpoint Properties 1553 Likewise, an ALTO Endpoint Property Registry could serve the same 1554 purposes as the ALTO Cost Type registry. Application to IANA 1555 registration for Endpoint Properties would follow a similar process. 1557 8. Acknowledgements 1559 The authors would like to thank Vijay Gurbani, Dave Mac Dysan, Dhruv 1560 Dhodi and Young Lee for fruitful discussions and comments on this 1561 draft and previous versions. 1563 9. References 1565 9.1. Normative References 1567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1568 Requirement Levels", BCP 14, RFC 2119, March 1997. 1570 [RFC5693] "Application Layer Traffic Optimization (ALTO) Problem 1571 Statement", October 2009. 1573 9.2. Informative References 1575 [ID-alto-protocol] 1576 ""ALTO Protocol" RFC 7285", September 2014. 1578 [RFC6708] "Application-Layer Traffic Optimization (ALTO) 1579 Requirements", February 2012. 1581 [RFC7285] R. Alimi, R. Yang, R. Penno (Eds.), , "ALTO Protocol", 1582 September 2014. 1584 [draft-jenkins-alto-cdn-use-cases-01] 1585 ""Use Cases for ALTO within CDNs" draft-jenkins-alto-cdn- 1586 use-cases-01", June 2011. 1588 [draft-lee-alto-app-net-info-exchange] 1589 "Information Exchange for High Bandwidth Applications in 1590 TE networks", October 2013. 1592 [draft-randriamasy-alto-cost-schedule-01] 1593 "ALTO Cost Schedule", July 2012. 1595 [draft-randriamasy-alto-multi-cost-05] 1596 "Multi-Cost ALTO", October 2011. 1598 Authors' Addresses 1600 Sabine Randriamasy 1601 Alcatel-Lucent/Bell Labs 1602 Route de Villejust 1603 NOZAY 91460 1604 FRANCE 1606 Email: Sabine.Randriamasy@alcatel-lucent.com 1608 Wendy Roome 1609 Alcatel-Lucent/Bell Labs 1610 600 Mountain Ave, Rm 3B-324 1611 Murray Hill, NJ 07974 1612 USA 1614 Phone: +1-908-582-7974 1615 Email: w.roome@alcatel-lucent.com 1617 Nico Schwan 1618 Thales Deutschland 1619 Lorenzstrasse 10 1620 Stuttgart 70435 1621 Germany 1623 Email: nico.schwan@thalesgroup.com