idnits 2.17.1 draft-randriamasy-alto-multi-cost-09.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 7 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1136 has weird spacing: '...ostType cos...' == Line 1137 has weird spacing: '...NString const...' == Line 1138 has weird spacing: '...ONArray or-c...' == Line 1139 has weird spacing: '...DFilter pids...' == Line 1208 has weird spacing: '...ostType cost...' == (4 more instances...) -- The document date (October 27, 2014) is 3467 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: '2' on line 1475 -- Looks like a reference, but probably isn't: '5' on line 1323 -- Looks like a reference, but probably isn't: '4' on line 691 -- Looks like a reference, but probably isn't: '1' on line 1474 -- Looks like a reference, but probably isn't: '100' on line 787 -- Looks like a reference, but probably isn't: '200' on line 783 -- Looks like a reference, but probably isn't: '6' on line 1278 -- Looks like a reference, but probably isn't: '20' on line 786 -- Looks like a reference, but probably isn't: '50' on line 786 -- Looks like a reference, but probably isn't: '30' on line 787 == Missing Reference: 'TODO' is mentioned on line 1457, but not defined == Missing Reference: 'OPTIONAL' is mentioned on line 1373, but not defined == Missing Reference: 'IEEE.754.2008' is mentioned on line 1171, but not defined -- Looks like a reference, but probably isn't: '23' on line 1323 -- Looks like a reference, but probably isn't: '10' on line 1323 -- Looks like a reference, but probably isn't: '0' on line 1324 -- Looks like a reference, but probably isn't: '7' on line 1474 -- Looks like a reference, but probably isn't: '3' on line 1475 == Unused Reference: 'RFC5693' is defined on line 1518, but no explicit reference was found in the text == Unused Reference: 'ID-alto-protocol' is defined on line 1523, 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 (==), 17 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: April 30, 2015 N. Schwan 6 Thales Deutschland 7 October 27, 2014 9 Multi-Cost ALTO 10 draft-randriamasy-alto-multi-cost-09 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 April 30, 2015. 59 Copyright Notice 61 Copyright (c) 2014 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 . . . . 15 97 4.2.1. Cost Value Encoded In JSONArray . . . . . . . . . . . 16 98 4.2.2. Scalar 'cost-type' Member Replaced By Array 'cost- 99 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 . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . . . 23 114 6.2.6. Response . . . . . . . . . . . . . . . . . . . . . . 24 115 6.2.7. Example . . . . . . . . . . . . . . . . . . . . . . . 24 116 6.3. Filtered Multi-Cost Map . . . . . . . . . . . . . . . . . 25 117 6.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 25 118 6.3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 26 119 6.3.3. Input Parameters . . . . . . . . . . . . . . . . . . 26 120 6.3.4. Capabilities . . . . . . . . . . . . . . . . . . . . 27 121 6.3.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 28 122 6.3.6. Response . . . . . . . . . . . . . . . . . . . . . . 28 123 6.3.7. Example 1 . . . . . . . . . . . . . . . . . . . . . . 28 124 6.3.8. Example 2 . . . . . . . . . . . . . . . . . . . . . . 29 125 6.4. Endpoint Multi-Cost Service . . . . . . . . . . . . . . . 30 126 6.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . 31 127 6.4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 31 128 6.4.3. Input Parameters . . . . . . . . . . . . . . . . . . 31 129 6.4.4. Capabilities . . . . . . . . . . . . . . . . . . . . 32 130 6.4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 32 131 6.4.6. Response . . . . . . . . . . . . . . . . . . . . . . 32 132 6.4.7. Example . . . . . . . . . . . . . . . . . . . . . . . 33 133 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 134 7.1. Information for IANA on proposed Cost Types . . . . . . . 34 135 7.2. Information for IANA on proposed Endpoint Properties . . 34 136 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 137 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 138 9.1. Normative References . . . . . . . . . . . . . . . . . . 35 139 9.2. Informative References . . . . . . . . . . . . . . . . . 35 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 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. A set of multi-cost specific media-types 613 is introduced and the main updates consist of changing the JSON type 614 of the value taken by a few members of the objects describing the 615 information resources. 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 o Updates required in the format of objects member(s): 631 * Objects DstCosts (to destination PIDs, {11.2.3.6}) and 632 EndpointDstCosts (to destination Endpoints, {11.5.1.6}): JSON 633 type of cost value member evolves from JSONNumber to JSONArray. 635 * Object ReqFilteredCostMap {11.3.2.3} and ReqEndpointCostMap 636 {11.5.1.3}: member cost-type be redefined as an array of 637 CostMode values, rather than a single value. 639 o Updates recommended in the object structure: 641 * The capabilities for the Filtered Cost Map Service {11.3.2.4} 642 and the Endpoint Cost Map Service {11.5.1.4} need to be 643 extended with a new member giving the maximum number of Cost 644 Types allowed in a request. 646 * The capabilities for the Filtered Cost Map Service {11.3.2.4} 647 and the Endpoint Cost Map Service {11.5.1.4} need to be 648 extended with a new member giving the list of Cost Types that 649 may be included in the constraints member of a request. 651 o Rules required on object member description: 653 * Order in which the multiple cost values are provided in the 654 responses, 656 * Number of values in member 'cost-types' of objects 657 InfoResourceCostMap, InfoResourceEndpointCostMap, 658 ReqFilteredCostMap, ReqEndpointCostMap. 660 o Rule recommended on the cost value mode: 662 * when the mode 'numerical' is available or applicable. 664 4.2. Updates Required In The Member Format Of Objects 666 This section specifies the changes in the object member format that 667 are required to enable multi-cost ALTO transactions. 669 The term Single Cost qualifies the items as they are specified in the 670 current ALTO protocol. 672 4.2.1. Cost Value Encoded In JSONArray 674 The fundamental change to support multi-cost is to encode the cost 675 values with the type JSONArray. This way, the cost between two PIDs 676 or two Endpoints can be represented in a generic way: 678 o with several Cost Types, 680 o with Cost Types whose value can each be encoded with any type of 681 JSON value. 683 For example, a multi-cost value represented with Cost Types (assuming 684 they are supported by the ALTO Server): 686 ["num-routingcost", "num-hopcount", "calendar-quarterlyvalue", "string-status"] 688 will be encoded in the following JSON Array in a Multi Cost ALTO 689 response: 691 [23, 6, [2, 5, 4, 1], "medium"] 693 The objects impacted by the encoding of ALTO Multi-Cost values in a 694 JSONArray are: DstCosts and EndpointDstCosts. Full specification 695 will be provided in later sections of this draft. 697 4.2.2. Scalar 'cost-type' Member Replaced By Array 'cost-types' Member 699 In the base protocol, the various single-cost-map services use a 700 scalar "cost-type" member in the "meta" section to indicate the cost 701 metric and cost mode of the returned values. 703 In Multi-Cost ALTO, the multi-cost-map services use an array member 704 named "cost-types" instead. The array elements are in the same 705 format as the "cost-type" member in single cost maps, and the order 706 corresponds to the order of values in the array values in the multi- 707 cost map. 709 Alternatively, we could use the same member name, but define it as an 710 array for multi-cost services. This would simplify some things for a 711 client, but complicate others. Overall, we believe it is easier for 712 a client to use a new member name than to overload the type of an 713 existing member name. 715 4.2.3. Rule On Cost Value Order In ALTO Reponses 717 The cost values each Source/Destination pair MUST be provided in the 718 same order as in the array of Cost Types. This way, the cost type 719 values are provided without any ambiguity on the Cost Type they 720 report on. 722 4.3. Updates Recommended In The Object Structure 724 Objects MultiCostMapCapability and FilteredMultiCostMapCapability: 725 new member giving the maximum number of Cost Types in a response. 727 5. Extended Constraints On Multi-Cost Values 729 This draft proposes to extend the constraint tests in the base 730 protocol to allow tests on the various costs in a request, and to 731 allow more general predicates. 733 NOTE: Constraint tests on multiple cost metrics are useful even when 734 retrieving single costs, and we expect there will be proposals to add 735 multi-cost constraint tests to the ALTO protocol, relating to the 736 extensions proposed in this draft. Draft 737 [draft-lee-alto-app-net-info-exchange] proposes in particular 738 extensions to query values on a metric M1 with constraints on other 739 metrics {M2, ... Mk}, that adds an interesting feature to extend ALTO 740 constraints. This motivates the need to augment the capabilities in 741 the IRD of the Filteredt Multi-Cost Map and Endpoint Multi-Cost Map 742 with the extensive list of Cost-Types that may be included in the 743 constraints of requests. 745 The base ALTO protocol allows optional contraints in the input 746 parameters to a request for a Filtered Cost Map or the Endpoint Cost 747 Service. The 'constraints' member is an array of expressions that 748 all apply to the (single) requested Cost Type. The encoding of 749 'constraints' member, is fully specified in Section 11.3.2.3 of the 750 base protocol as follows: 752 A constraint contains two entities separated by whitespace: 753 (1) an operator,'gt' for greater than, 'lt' for less than, 754 'ge' for greater than or equal to, 'le' for less than or equal to, 755 or 'eq' for equal to 756 (2) a target cost value. The cost value is a number that MUST be 757 defined in the same units as the Cost Type indicated by the costtype 758 parameter 759 ... 760 If multiple 'constraint' parameters are specified, they are 761 interpreted as being related to each other with a logical AND. 763 Such a specification covers multiple predicates on one metric such 764 as: 766 'routingcost' values belong to [6, 20) 768 5.1. Use Cases For Multi-Cost Multi-Operator Constraints 770 Suppose that an application uses information on the ALTO Cost Types 771 'hopcount' and 'routingcost'. This application may want to select 772 paths or Endpoints with bounds on values for both 'hopcount' and 773 'routingcost'. For instance solutions meeting a constraint like: 775 'hopcount' values in [6,20) OR 'routingcost' values in [100,200] 777 Moreover, this application may be ready to make compromises and to 778 select paths or Endpoints by bounding their cost values according to 779 two options: 781 1. either solutions with moderate 'hopcount' and high 'routingcost', 782 for instance: 'hopcount' values in [6,20] AND 'routingcost' 783 values in [100,200], 785 2. or solutions with higher 'hopcount' and moderate 'routingcost', 786 for instance: 'hopcount' values in [20,50] AND 'routingcost' 787 values in [30,100]. 789 5.2. Extended constraints in Multi-Cost ALTO 791 This draft proposes to support the two above mentioned use cases by 792 extending the scope of constraints in two ways: 794 o allow the 'constraint' member to be applicable to multiple Cost 795 Types, 797 o allow the multiple constraints to be related to each other by both 798 logical AND and logical OR. 800 The two options would be covered by a logical expression like: 802 [('hopcount' ge 6) AND ('hopcount' lt 20) AND 803 ('routingcost' ge 100) AND ('routingcost' le 200)] 804 OR 805 [('hopcount' ge 20) AND ('hopcount' le 50) AND 806 ('routingcost' ge 30) AND ('routingcost' le 100)] 808 A simple encoding of multi-cost constraints for such expressions is 809 specified in Section 5.3.3 of this draft, describing the input 810 parameters to request for Filtered Cost Map. This specification is 811 applicable to the EP Cost service as well. 813 6. Protocol Extensions For Multi-Cost ALTO Transactions 815 This section proposes extensions of the ALTO protocol to support 816 Multi Cost ALTO Services or provide additional ALTO information. It 817 integrates discussions on the ALTO mailing list. 819 If an ALTO client desires information on several Cost Types, then 820 instead of placing as many requests as costs, it may request and 821 receive all the desired Cost Types in one single transaction. 823 The ALTO server then, provided it supports the requested Cost Types, 824 and provided it supports multi-cost ALTO transactions, sends one 825 single response where for each {source, destination} pair, the cost 826 values are arranged in an array, where each component corresponds to 827 a specified Cost Type. The correspondence between the components and 828 the Cost Types is implicitly indicated in the ALTO response. Indeed, 829 the values in the Cost values MUST be provided in the same order as 830 in the array of cost types indicated in the response. 832 The following ALTO services have corresponding Multi-Cost extensions: 834 o Information Resources Directory: extended with multi-cost related 835 URIs and associated capabilities. 837 o Cost Map Service: extended with the Multi-Cost Map Service, 839 o Cost Map Filtering Service: extended with the Multi-Cost Map 840 Filtering Service, 842 o Endpoint Cost Lookup Service: extended with the Endpoint Multi- 843 Cost Lookup Service. 845 6.1. Information Resources Directory 847 When the ALTO server supports the provision of information on 848 multiple costs in a single transaction, the Information Resources 849 Directory will list the corresponding resources. The media type 850 remains the same as in the current ALTO protocol. 852 6.1.1. Example of Multi-Cost specific resources in the IRD 854 The following is an example Information Resource Directory returned 855 by an ALTO Server and containing Multi-Cost specific services: the 856 Multi-Cost Map Service, Filtered Multi-Cost Map and the Endpoint 857 Multi-Cost Service. It is assumed that the IRD contains usual ALTO 858 Services as described in the example IRD of the current ALTO 859 protocol. In this example, the ALTO Server additionally provides 860 Multi-Cost Services in a specific folder of "alto.example.com" called 861 "multi". This folder contains the Multi-Cost Maps, Filtered Multi- 862 Cost Maps as well as the Endpoint Multi-Cost Service. 864 In this example, the ALTO IRD exposes Multi-Cost capabilities on cost 865 types "num-routingcost", "num-hopcount", "num-pathoccupationcost", 866 that can be combined in a request. The values on these metrics are 867 provided in numerical mode. Values provided for cost-type string are 868 in "string" mode. 870 For the "filtered-multicost-map" resource and the "endpoint- 871 multicost-map" resource, the IRD exposes in its capabilities a member 872 noted "testable-cost-types" that is the list of cost-types that are 873 allowed to be included in the constraints of a request. Note that 874 this set may be different than the set "cost-type-names". The 875 "endpoint-multicost-map" resource provides cost-values for Cost Types 876 "num-routingcost", "num-hopcount" and "str-status" and supports 877 constraints on "num-routingcost", "num-hopcount", "num- 878 pathoccupationcost" where as it does not provide values on "num- 879 pathoccupationcost" and does not supports constraints on "str- 880 status". 882 GET /directory HTTP/1.1 883 Host: alto.example.com 884 Accept: application/alto-directory+json,application/alto-error+json 886 HTTP/1.1 200 OK 887 Content-Length: [TODO] 888 Content-Type: application/alto-directory+json 890 { 891 "meta" : { 892 "cost-types" : { 893 "num-pathoccupationcost" : { 894 "cost-mode" : "numerical", 895 "cost-metric" : "pathoccupationcost" 896 }, 897 "str-status" : { 898 "cost-mode" : "string", 899 "cost-metric" : "status" 900 }, 901 "num-routing" : { 902 "cost-mode" : "numerical", 903 "cost-metric" : "routingcost" 904 }, 905 "num-hopcount" : { 906 "cost-mode" : "numerical", 907 "cost-metric" : "hopcount" 908 }, 909 ..... 910 Other ALTO cost types as described 911 in current ALTO Protocol 912 ..... 913 }, 914 "default-alto-network-map" : "my-default-network-map" 915 }, 916 "resources" : { 917 "my-default-network-map" : { 918 "uri" : "http://alto.example.com/networkmap", 919 "media-type" : "application/alto-networkmap+json" 920 }, 921 "numerical-routing-cost-map" : { 922 ..... 923 Single-cost Services as described 924 in current ALTO Protocol 925 ..... 926 }, 927 "routingcost-hopcount-multicost-map" : { 928 "uri" : "http://alto.example.com/multi/costmap", 929 "media-types" : ["application/alto-multicostmap+json"], 930 "uses" : [ "my-default-network-map" ], 931 "capabilities" : { 932 "cost-type-names" : [ "num-routing", "num-hopcount" ] 933 } 934 }, 935 "filtered-multicost-map" : { 936 "uri" : "http://alto.example.com/multi/costmap/filtered", 937 "media-types" : ["application/alto-multicostmap+json" ], 938 "accepts" : ["application/alto-multicostmapfilter+json" ], 939 "uses" : [ "my-default-network-map" ], 940 "capabilities" : { 941 "cost-constraints" : true, 942 "max-cost-types" : 3, 943 "cost-type-names" : [ "num-routingcost", 944 "num-hopcount", 945 "num-pathoccupationcost" ], 946 "testable-cost-types": ["num-routingcost", 947 "num-hopcount", 948 "num-pathoccupationcost" ] 949 } 950 }, 951 "endpoint-multicost-map" : { 952 "uri" : "http://alto.example.com/multi/endpointmulticost/lookup", 953 "media-types" : [ "application/alto-endpointmulticost+json" ], 954 "accepts" : [ "application/alto-endpointmulticostparams+json" ], 955 "uses" : [ "my-default-network-map" ], 956 "capabilities" : { 957 "cost-constraints" : true, 958 "max-cost-types" : 2, 959 "cost-type-names" : [ "num-routingcost", 960 "num-hopcount", 961 "str-status" ], 962 "testable-cost-types": ["num-routingcost", 963 "num-hopcount", 964 "num-pathoccupationcost" ] 965 } 966 } 967 } 968 } 970 6.2. Multi-Cost Map Service 972 This section introduces a new media-type for the Multi-Cost map. For 973 each source/destination pair of PIDs, it provides the values of the 974 different Cost Types supported for the Multi-Cost map, in the same 975 order as in the list of Cost Types specified in the capabilities. 977 A Multi-Cost Map MAY be provided by an ALTO Server. 979 Note that the capabilities specify implicitly the order in which the 980 different Cost Type values will be listed in the Cost Map. 982 The Cost Type values in the responses are encoded as a JSONArray of 983 cost values for the different Cost Types. 985 Note that values in a Multi-Cost map are arrays of values of the 986 various Cost Types. If the ALTO server does not have the value for a 987 particular Cost Type for a source/destination PID pair, the server 988 MUST use 'null' (a reserved JSON symbol) for that location in the 989 array. If the ALTO server does not have a value for any of the Cost 990 Types for a given source/destination pair -- that is, if the array 991 would be a list of nulls -- then the ALTO server MAY omit the array 992 for that source/destination pair. 994 6.2.1. Media Type 996 The media type is "application/alto-multicostmap+json". 998 6.2.2. HTTP Method 1000 This resource is requested using the HTTP GET method. 1002 6.2.3. Input Parameters 1004 None. 1006 6.2.4. Capabilities 1008 The capabilities of the URI providing this resource are defined by a 1009 JSON object of type FilteredCostMapCapabilities:: 1011 object { 1012 JSONString cost-type-names<1..*>; 1013 } MultiCostMapCapabilities; 1015 with members 1017 cost-type-names The Cost Type names returned by this map. 1019 An ALTO Server MUST support all of the Cost Types listed here. Note 1020 that an ALTO Server may provide multiple Cost Map Information 1021 Resources, each with different capabilities. 1023 An ALTO Server supporting the Multi-Cost Map service MUST support the 1024 Cost mode 'numerical' for all supported Cost Types encoded with the 1025 'JSONNumber' type. 1027 6.2.5. Uses 1029 The Resource ID of the Network Map which defines the PIDs used in 1030 this Multi Cost Map. An ALTO Server MUST NOT define two Multi Cost 1031 Maps with the same Network Map and set of Cost Types. 1033 6.2.6. Response 1035 The "meta" field of a Cost Map response MUST include the "dependent- 1036 vtags" key, whose value is a single-element array to indicate the 1037 Version Tag of the Network Map used, where the Network Map is 1038 specified in "uses" of the IRD. 1040 The "meta" MUST also include the member "cost-types", which is a 1041 JSONArray of the CostTypes in this Multi Cost Map. 1043 The data component of a Multi Cost Map response is named "multi-cost- 1044 map", which is a JSON object of type CostMapData, as defined in 1045 {11.2.3.6} of the ALTO protocol. This is identical to the format of 1046 the ALTO Cost Map response, except that the JSONValues are arrays 1047 rather than numbers. The values in the arrays correspond to the Cost 1048 Type listed at the same place in the 'cost-types' array. This array 1049 MUST have the same size as the 'cost-types' array, and the values in 1050 the MUST be in the same order as in the 'cost-types' array. 1052 The returned Multi Cost Map MUST include the required Path Costs for 1053 each pair of Source and Destination PID for which this information is 1054 available. If a cost value is not defined, the ALTO Server MUST 1055 replace that value in the array with the reserved JSON symbol 'null'. 1056 If no costs are defined for a pair of Source and Destination PIDs, so 1057 the Path Cost would be an array of nulls, the ALTO Server MAY omit 1058 the array for that pair. 1060 6.2.7. Example 1062 This example illustrates a 'static' multi-cost ALTO transaction, 1063 where the utilized Cost Types all have 'static' values. We assume 1064 here that the Cost Types available at the ALTO Server are 1065 "routingcost" and "hopcount" and the 'numerical' mode is available 1066 for both of them. The "routingcost" may be based on monetary 1067 considerations where as the "hopcount" is used to report on the path 1068 delay. We also assume that ALTO server does not know the value of 1069 the "routingcost" between PID2 and PID3, and hence uses null for 1070 those costs. 1072 GET /multicostmap/num HTTP/1.1 1073 Host: alto.example.com 1074 Accept: application/alto-multicostmap+json,application/alto-error+json 1076 HTTP/1.1 200 OK 1077 Content-Length: [TODO] 1078 Content-Type: application/alto-multicostmap+json 1080 { 1081 "meta" : { 1082 "dependent-vtags" : [ 1083 {"resource-id": "my-default-network-map", 1084 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1085 } 1086 ], 1087 "cost-types" : [ 1088 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1089 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1090 ] 1091 } 1092 "multi-cost-map" : { 1093 "PID1": { "PID1":[1,0], "PID2":[5,23], "PID3":[10,5] }, 1094 "PID2": { "PID1":[null,5], "PID2":[1,0], "PID3":[15,9] }, 1095 "PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0] } 1096 } 1097 } 1099 6.3. Filtered Multi-Cost Map 1101 A Multi-Cost Map may be very large. In addition, an Application 1102 Client assisted by the ALTO Client does not necessarily need the Cost 1103 Types for all the source/destination PID pairs. 1105 Therefore applications may more likely use Cost Map information 1106 filtered w.r.t. the Cost types as well as the source/destination 1107 pairs of PIDs. This section specifies Filtered Multi-Cost Maps. 1109 A Filtered Multi Cost Map is a Cost Map Information Resource for 1110 which an ALTO Client may supply additional parameters limiting the 1111 scope of the resulting Cost Map. A Filtered Multi Cost Map MAY be 1112 provided by an ALTO Server. 1114 6.3.1. Media Type 1116 The media type is "application/alto-multicostmap+json". 1118 6.3.2. HTTP Method 1120 This resource is requested using the HTTP POST method. 1122 6.3.3. Input Parameters 1124 Input parameters are supplied in the entity body of the POST request. 1125 This document specifies the input parameters with a data format 1126 indicated by the media type "application/alto- 1127 multicostmapfilter+json", which is a JSON Object of type 1128 ReqFilteredMultiCostMap, where: 1130 object { 1131 PIDName srcs<0..*>; 1132 PIDName dsts<0..*>; 1133 } PIDFilter; 1135 object { 1136 CostType cost-types<1..*>; 1137 JSONString constraints<0..*>; [OPTIONAL] 1138 JSONArray or-constraints<0..*>; [OPTIONAL] 1139 PIDFilter pids; [OPTIONAL] 1140 } ReqFilteredMultiCostMap; 1142 with members: 1144 cost-type The Cost Types for the returned costs. 1145 Each listed Cost Type MUST be one of the supported Cost Types 1146 indicated in this resource's capabilities. 1148 constraints 1149 Defines an array of additional constraints. The ALTO 1150 server MUST return the costs for all source/destination pair 1151 that satisfy all constraints in this list, and no other 1152 costs. This parameter MUST NOT be specified if this 1153 resource's capabilities indicate that 1154 constraint support is not available. Each string in the 1155 'constraint' array MUST contain three entities separated by 1156 whitespace, in the following format: 1157 [index] op value 1158 'Index' is a number between 0 and the number of Testable Cost 1159 Types minus 1, and indicates the Cost Type to which this 1160 constraint applies. (The square brackets ([]) surrounding 1161 'index' are required syntactic sugar. They serve as a 1162 reminder that 'index' is an array index, not a value to test, 1163 and they avoid unusual-looking constraints such as "1 ge 5".) 1164 'Op' is an operator: 'gt' for greater than, 'lt' for less 1165 than, 'ge' for greater than or equal to, 'le' for less than 1166 or equal to, 'eq' for equal to, or 'ne' for not equal to. 1167 'Value' is a target cost value to compare against the 1168 indicated Cost Type. For numeric Cost Types, 'value' MUST be 1169 a number defined in the same units as the Cost Type indicated 1170 by 'index'. ALTO servers SHOULD use at least IEEE 754 1171 doubleprecision floating point [IEEE.754.2008] to store the 1172 cost value, and SHOULD perform internal computations using 1173 double-precision floating-point arithmetic. For string Cost 1174 Types, 'value' MUST be a string enclosed in single quotes ('). 1175 For array-valued Cost Types, 'eq' is true iff one of the 1176 Cost Type values is equal to 'value', and 'ne' is true iff 1177 none of the Cost Type values are equal to 'value'. The other 1178 operators are not defined for array-valued Cost Types. 1180 or-constraints 1181 Defines an array of arrays of constraint strings. The 1182 individual constraint strings MUST be in the same format as 1183 strings in the 'constraints' parameter. The ALSO server MUST 1184 return costs that satisfy all constraints in one or more of 1185 the inner lists, and no other costs. That is, 1186 'or-constraints' is the logical OR of ANDs. The client MUST 1187 NOT specify this parameter if this resource's capabilities 1188 indicate that constraint support is not 1189 available. The client MUST NOT specify both a 1190 'or-constraints' and a 'constraints' parameter. 1192 pids A list of Source PIDs and a list of Destination PIDs for which 1193 Path Costs are to be returned. If a list is empty, the ALTO 1194 Server MUST interpret it as the full set of currently-defined 1195 PIDs. The ALTO Server MUST interpret entries appearing in a list 1196 multiple times as if they appeared only once. If the "pids" 1197 member is not present, both lists MUST be interpreted by the ALTO 1198 Server as containing the full set of currently-defined PIDs. 1200 6.3.4. Capabilities 1202 The URI providing this resource supports all capabilities documented 1203 in Section 6.2.4 (with identical semantics), plus additional 1204 capabilities. In particular, the capabilities are defined by a JSON 1205 object of type FilteredMultiCostMapCapability: 1207 object { 1208 CostType cost-types<1..*>; 1209 JSONBool cost-constraints; 1210 JSONNumber max-cost-types; [OPTIONAL] 1211 } FilteredMultiCostMapCapability; 1213 with members: 1215 cost-types The cost types available from this service. 1217 max-cost-types Indicates the maximum number of cost values 1218 the ALTO Server can provide in a multi-cost array of a 1219 Multi-Cost Map. 1221 cost-constraints If true, then the ALTO Server allows cost 1222 constraints to be included in requests to the corresponding URI. 1223 If not present, this member MUST be interpreted as if it specified 1224 false. 1226 6.3.5. Uses 1228 The Resource ID of the Network Map which defines the PIDs used in 1229 this Filtered Multi Cost Map. 1231 6.3.6. Response 1233 The response is the same format as for the Multi Cost Map Service 1234 (Section 6.2.6). The returned Cost Map MUST NOT contain any source/ 1235 destination pair that was not indicated (implicitly or explicitly) in 1236 the input parameters. If the input parameters contain a PID name 1237 that is not currently defined by the ALTO Server, the ALTO Server 1238 MUST behave as if the PID did not appear in the input parameters. If 1239 any constraints are specified, Source/Destination pairs for which the 1240 Path Costs do not meet the constraints MUST NOT be included in the 1241 returned Cost Map. If no constraints were specified, then all Path 1242 Costs are assumed to meet the constraints. 1244 6.3.7. Example 1 1245 POST multi/multicostmap/filtered HTTP/1.1 1246 Host: alto.example.com 1247 Content-Type: application/alto-multicostmapfilter+json 1248 Accept: application/alto-multicostmap+json,application/alto-error+json 1250 { 1251 "cost-types" : [ 1252 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1253 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1254 ], 1255 "pids" : { 1256 "srcs" : [ "PID1" ], 1257 "dsts" : [ "PID1", "PID2", "PID3" ] 1258 } 1259 } 1261 HTTP/1.1 200 OK 1262 Content-Length: [TODO] 1263 Content-Type: application/alto-multicostmap+json 1265 { 1266 "meta" : { 1267 "dependent-vtags" : [ 1268 {"resource-id": "my-default-network-map", 1269 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1270 } 1271 ], 1272 "cost-types" : [ 1273 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1274 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1275 ] 1276 } 1277 "multi-cost-map" : { 1278 "PID1": { "PID1": [1,6], "PID2": [5,23], "PID3": [10,5] } 1279 } 1280 } 1282 6.3.8. Example 2 1284 This is an example of using constraints to restrict returned source/ 1285 destination PID pairs to those with 'routingcost' between 5 and 10, 1286 or 'hopcount' equal to 0. 1288 POST multi/multicostmap/filtered HTTP/1.1 1289 Host: alto.example.com 1290 Content-Type: application/alto-multicostmapfilter+json 1291 Accept: application/alto-multicostmap+json,application/alto-error+json 1293 { 1294 "cost-types" : [ 1295 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1296 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1297 ], 1298 "or-constraints" : [ ["[0] ge 5", "[0] le 10"], 1299 ["[1] eq 0"] ] 1300 "pids" : { 1301 "srcs" : [ "PID1", "PID2" ], 1302 "dsts" : [ "PID1", "PID2", "PID3" ] 1303 } 1304 } 1306 HTTP/1.1 200 OK 1307 Content-Length: [TODO] 1308 Content-Type: application/alto-multicostmap+json 1310 { 1311 "meta" : { 1312 "dependent-vtags" : [ 1313 {"resource-id": "my-default-network-map", 1314 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1315 } 1316 ], 1317 "cost-types" : [ 1318 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1319 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1320 ] 1321 } 1322 "multi-cost-map" : { 1323 "PID1": { "PID2": [5,23], "PID3": [10,5] } 1324 "PID2": { "PID2": [1,0] }, 1325 } 1326 } 1328 6.4. Endpoint Multi-Cost Service 1330 The Endpoint Multi-Cost Service provides information on several Cost 1331 Types between individual Endpoints. 1333 This service MAY be provided by an ALTO Server. It is important to 1334 note that although this resource allows an ALTO Server to reveal 1335 costs between individual endpoints, an ALTO Server is not required to 1336 do so. A simple alternative would be to compute the cost between two 1337 endpoints as the costs between the PIDs corresponding to the 1338 endpoints if these values are available for the requested Cost Types. 1340 When the cost values are requested to perform multi-variate numerical 1341 optimization and are each available in the 'numerical' mode, then the 1342 ALTO Client SHOULD request the 'numerical' mode in order to get a 1343 reliable result. Note that this consideration is outside the scope 1344 of the ALTO protocol as it relates to the responsibility of the ALTO 1345 Client and related entries. However common sense lead to warn that a 1346 necessary condition for vector ranking method to be reliable is that 1347 the components of the processed vectors are numerical and not ordinal 1348 values. 1350 6.4.1. Media Type 1352 The media type is "application/alto-endpointmulticost+json". 1354 6.4.2. HTTP Method 1356 This resource is requested using the HTTP POST method 1358 6.4.3. Input Parameters 1360 Input parameters are supplied in the entity body of the POST request. 1361 This document specifies input parameters with a data format indicated 1362 by media type "application/alto-endpointmulticostparams+json", which 1363 is a JSON Object of type ReqEndpointMultiCostMap: 1365 object { 1366 TypedEndpointAddr srcs<0..*>; [OPTIONAL] 1367 TypedEndpointAddr dsts<1..*>; 1368 } EndpointFilter; 1370 object{ 1371 CostType cost-types<1..*>; 1372 JSONString constraints<0..*>; [OPTIONAL] 1373 JSONArray or-constraints<0..*>; [OPTIONAL] 1374 EndpointFilter endpoints; 1375 } ReqEndpointMultiCostMap; 1377 with members: 1379 cost-types Defined equivalently to the "cost-types" 1380 input parameter of a Filtered Multi Cost Map. 1382 constraints Defined equivalently to the "constraints" 1383 input parameter of a Filtered Multi Cost Map. 1385 or-constraints Defined equivalently to the "or-constraints" 1386 input parameter of a Filtered Multi Cost Map. 1388 endpoints A list of Source Endpoints and Destination Endpoints for 1389 which Path multiple Costs are to be returned. If the list 1390 of Source Endpoints is empty (or not included), the ALTO Server 1391 MUST interpret it as if it contained the Endpoint Address 1392 corresponding to the client IP address from the incoming 1393 connection (see Section 10.3 for discussion and considerations 1394 regarding this mode). The list of destination Endpoints 1395 MUST NOT be empty. The ALTO Server MUST interpret entries 1396 appearing multiple times in a list as if they appeared only once. 1398 6.4.4. Capabilities 1400 The capabiities are the same as described in Section 6.3.4. 1402 6.4.5. Uses 1404 As with the ALTO Endpoint Cost Service, the Endpoint Multi Cost 1405 Service MUST NOT use a Network Map. 1407 6.4.6. Response 1409 The "meta" field of an Endpoint Multi Cost response MUST include the 1410 "cost-types" key, to indicate the Cost Types used. 1412 The data component of an Endpoint Multi Cost response is named 1413 "endpoint-multi-cost-map", which is a JSON object of type 1414 EndpointCostMapData, as defined in Section 11.5.1.6 of the ALTO 1415 protocol. This is identical to the format of the ALTO Cost Map 1416 response, except that the JSONValues are arrays rather than numbers. 1417 The values in the arrays correspond to the Cost Type listed at the 1418 same place in the 'cost-types' array. This array MUST have the same 1419 size as the 'cost-types' array, and the values in the MUST be in the 1420 same order as in the 'cost-types' array. 1422 6.4.7. Example 1424 This is an example of requesting jointly cost values for 1425 "routingcost" and "hopcount" while using constraints to restrict the 1426 returned source/destination endpoints to those with 1427 'pathoccupationcost' between 5 and 10, or 'hopcount' equal to 0, 1428 where 'pathoccupationcost' and 'hopcount' respectively have index 2 1429 and 1 in the "testable-cost-types" member of the IRD capabilities of 1430 the "endpoint-multicost-map" resource. Only 2 of the 3 requested 1431 source/destination pairs meet the constraints. 1433 POST multi/endpointmulticost/lookup HTTP/1.1 1434 Host: alto.example.com 1435 Content-Length: [TODO] 1436 Content-Type: application/alto-endpointmulticostparams+json 1437 Accept: application/alto-endpointmulticost+json,application/alto-error+json 1439 { 1440 "cost-types" : [ 1441 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1442 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1443 ], 1444 "or-constraints" : [ ["[2] ge 5", "[2] le 10"], 1445 ["[1] eq 0"] ], 1446 "endpoints" : { 1447 "srcs": [ "ipv4:192.0.2.2" ], 1448 "dsts": [ 1449 "ipv4:192.0.2.89", 1450 "ipv4:198.51.100.34", 1451 "ipv4:203.0.113.45" 1452 ] 1453 } 1454 } 1456 HTTP/1.1 200 OK 1457 Content-Length: [TODO] 1458 Content-Type: application/alto-endpointmulticost+json 1460 { 1461 "meta" : { 1462 "dependent-vtags" : [ 1463 {"resource-id": "my-default-network-map", 1464 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1465 } 1466 ], 1467 "cost-types" : [ 1468 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1469 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1470 ] 1471 } 1472 "endpoint-multi-cost-map" : { 1473 "ipv4:192.0.2.2": { 1474 "ipv4:192.0.2.89" : [1, 7], 1475 "ipv4:203.0.113.45" : [3, 2] 1476 } 1477 } 1478 } 1480 7. IANA Considerations 1482 Information for the ALTO Endpoint property registry maintained by the 1483 IANA and related to the new Endpoints supported by the acting ALTO 1484 server. These definitions will be formulated according to the syntax 1485 defined in Section on "ALTO Endpoint Property Registry" of [RFC7285], 1487 Information for the ALTO Cost Type Registry maintained by the IANA 1488 and related to the new Cost Types supported by the acting ALTO 1489 server. These definitions will be formulated according to the syntax 1490 defined in Section on "ALTO Cost Type Registry" of [RFC7285], 1492 7.1. Information for IANA on proposed Cost Types 1494 When a new ALTO Cost Type is defined, accepted by the ALTO working 1495 group and requests for IANA registration MUST include the following 1496 information, detailed in Section 11.2: Identifier, Intended 1497 Semantics, Security Considerations. 1499 7.2. Information for IANA on proposed Endpoint Properties 1501 Likewise, an ALTO Endpoint Property Registry could serve the same 1502 purposes as the ALTO Cost Type registry. Application to IANA 1503 registration for Endpoint Properties would follow a similar process. 1505 8. Acknowledgements 1507 The authors would like to thank Vijay Gurbani, Dave Mac Dysan, Dhruv 1508 Dhodi and Young Lee for fruitful discussions and comments on this 1509 draft and previous versions. 1511 9. References 1513 9.1. Normative References 1515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1516 Requirement Levels", BCP 14, RFC 2119, March 1997. 1518 [RFC5693] "Application Layer Traffic Optimization (ALTO) Problem 1519 Statement", October 2009. 1521 9.2. Informative References 1523 [ID-alto-protocol] 1524 ""ALTO Protocol" RFC 7285", September 2014. 1526 [RFC6708] "Application-Layer Traffic Optimization (ALTO) 1527 Requirements", February 2012. 1529 [RFC7285] R. Alimi, R. Yang, R. Penno (Eds.), , "ALTO Protocol", 1530 September 2014. 1532 [draft-jenkins-alto-cdn-use-cases-01] 1533 ""Use Cases for ALTO within CDNs" draft-jenkins-alto-cdn- 1534 use-cases-01", June 2011. 1536 [draft-lee-alto-app-net-info-exchange] 1537 "Information Exchange for High Bandwidth Applications in 1538 TE networks", October 2013. 1540 [draft-randriamasy-alto-cost-schedule-01] 1541 "ALTO Cost Schedule", July 2012. 1543 [draft-randriamasy-alto-multi-cost-05] 1544 "Multi-Cost ALTO", October 2011. 1546 Authors' Addresses 1548 Sabine Randriamasy 1549 Alcatel-Lucent/Bell Labs 1550 Route de Villejust 1551 NOZAY 91460 1552 FRANCE 1554 Email: Sabine.Randriamasy@alcatel-lucent.com 1555 Wendy Roome 1556 Alcatel-Lucent/Bell Labs 1557 600 Mountain Ave, Rm 3B-324 1558 Murray Hill, NJ 07974 1559 USA 1561 Phone: +1-908-582-7974 1562 Email: w.roome@alcatel-lucent.com 1564 Nico Schwan 1565 Thales Deutschland 1566 Lorenzstrasse 10 1567 Stuttgart 70435 1568 Germany 1570 Email: nico.schwan@thalesgroup.com