idnits 2.17.1 draft-ietf-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. ** The abstract seems to contain references ([RFC7285]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 25, 2017) is 2557 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) -- Looks like a reference, but probably isn't: '10' on line 1145 -- Looks like a reference, but probably isn't: '20' on line 312 -- Looks like a reference, but probably isn't: '1' on line 1089 -- Looks like a reference, but probably isn't: '0' on line 967 -- Looks like a reference, but probably isn't: '5' on line 1144 -- Looks like a reference, but probably isn't: '16' on line 1144 -- Looks like a reference, but probably isn't: '19' on line 1089 -- Looks like a reference, but probably isn't: '8' on line 1088 -- Looks like a reference, but probably isn't: '15' on line 1140 -- Looks like a reference, but probably isn't: '4' on line 1141 -- Looks like a reference, but probably isn't: '23' on line 1141 -- Looks like a reference, but probably isn't: '2' on line 1145 == Unused Reference: 'RFC5693' is defined on line 1198, but no explicit reference was found in the text == Unused Reference: 'RFC6708' is defined on line 1201, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 13 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 Nokia Bell Labs 5 Expires: October 27, 2017 N. Schwan 6 Thales Deutschland 7 April 25, 2017 9 Multi-Cost ALTO 10 draft-ietf-alto-multi-cost-09 12 Abstract 14 The ALTO (Application Layer-Traffic Optimization) Protocol 15 ([RFC7285]) defines several services that return various metrics 16 describing the costs between network endpoints. 18 This document defines a new service that allows an ALTO Client to 19 retrieve several cost metrics in a single request for an ALTO 20 Filtered Cost Map and Endpoint Cost Map. In addition, it extends the 21 constraints to further filter those maps by allowing a client to 22 specify a logical combination of tests on several cost metrics. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 27, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Multi-Cost Data Format . . . . . . . . . . . . . . . . . 5 68 3.2. Compatibility With Legacy ALTO Clients . . . . . . . . . 5 69 3.3. Filtered Multi Cost Map Resources . . . . . . . . . . . . 6 70 3.4. Endpoint Cost Service Resources . . . . . . . . . . . . . 6 71 3.5. Full Cost Map Resources . . . . . . . . . . . . . . . . . 7 72 3.6. Extended Constraint Tests . . . . . . . . . . . . . . . . 7 73 3.6.1. Extended constraint predicates . . . . . . . . . . . 7 74 3.6.2. Extended logical combination of predicates . . . . . 7 75 3.6.3. Testable Cost Types in constraints . . . . . . . . . 8 76 3.6.4. Testable Cost Type Names in IRD capabilities . . . . 9 77 3.6.5. Legacy ALTO Client issues . . . . . . . . . . . . . . 9 78 4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 11 79 4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11 80 4.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 11 81 4.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 12 82 4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 15 83 4.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 15 84 4.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 16 85 4.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 16 86 4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 17 87 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 5.1. Information Resource Directory . . . . . . . . . . . . . 17 89 5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . 19 90 5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . 20 91 5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . 22 92 5.5. Multi-Cost Filtered Cost Map: Example #4 . . . . . . . . 23 93 5.6. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 24 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 7. Privacy And Security Considerations . . . . . . . . . . . . . 26 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 99 9.2. Informative References . . . . . . . . . . . . . . . . . 26 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 102 1. Introduction 104 IETF has defined ALTO services in [RFC7285] to provide guidance to 105 overlay applications, which have to select one or several hosts from 106 a set of candidates that are able to provide a desired resource. 107 This guidance is based on parameters such as the topological 108 distance, that affect performance of the data transmission between 109 the hosts. The purpose of ALTO is to improve Quality of Experience 110 (QoE) in the application while reducing resource consumption in the 111 underlying network infrastructure. The ALTO protocol conveys a view 112 of the Internet called a Network Map and composed of Provider defined 113 locations spanning from subnets to several Autonomous Systems (AS). 114 ALTO may also convey the Provider determined Costs between Network 115 Map locations or between groups of individual endpoints. 117 Current ALTO Cost Types provide values such as hopcount and 118 administrative routing cost to reflect ISP routing preferences. 119 Recently, new use cases have extended the usage scope of ALTO to 120 Content Delivery Networks (CDN), Data Centers and applications that 121 need additional information to select their endpoints or network 122 locations. Thus a multitude of new Cost Types that better reflect 123 the requirements of these applications are expected to be specified. 125 The ALTO protocol [RFC7285], which this document refers to as the 126 base protocol, restricts ALTO Cost Maps and Endpoint Cost Services to 127 only one Cost Type per ALTO request. To retrieve information for 128 several Cost Types, an ALTO Client must send several separate 129 requests to the Server. 131 It is far more efficient, in terms of Round Trip Time (RTT), traffic, 132 and processing load on the ALTO Client and Server, to get all costs 133 with a single query/response transaction. One Cost Map reporting on 134 N Cost Types is less bulky than N Cost Maps containing one Cost Type 135 each. This is valuable for both the storage of these maps and their 136 transmission. Additionally, for many emerging applications that need 137 information on several Cost Types, having them gathered in one map 138 will save time. Another advantage is consistency: providing values 139 for several Cost Types in one single batch is useful for ALTO Clients 140 needing synchronized ALTO information updates. This document defines 141 how to retrieve multiple cost metrics in a single request for ALTO 142 Filtered Cost Maps and Endpoint Cost Maps. To ensure compatibility 143 with legacy ALTO Clients, only the Filtered Cost Map and Endpoint 144 Cost Map services are extended to return Multi-Cost values. 146 Along with multi-cost values queries, the filtering capabilities need 147 to be extended to allow constraints on multiple metrics. The base 148 protocol allows an ALTO Client to provide optional constraint tests 149 for a Filtered Cost Map or the Endpoint Cost Service, where the 150 constraint tests are limited to the AND-combination of comparison 151 tests on the value of the (single) requested Cost Type. However, 152 applications that are sensitive to several metrics and struggle with 153 complicated network conditions may need to arbitrate between 154 conflicting objectives such as routing cost and network performance. 155 To this end, this document extends the base protocol with constraints 156 that may test multiple metrics and may be combined with logical 'ORs' 157 as well as logical 'ANDs'. This allows an application to make 158 requests such as: "select solutions with either (moderate "hopcount" 159 AND high "routingcost") OR (higher "hopcount" AND moderate 160 "routingcost")". 162 This document is organized as follows: Section 2 defines terminology 163 used in this document. Section 3 gives a non-normative overview of 164 the multi-cost extensions, and Section 4 gives their formal 165 definitions. Section 5 gives several complete examples. The 166 remaining sections describe the IANA and privacy considerations. 168 2. Terminology 170 o ALTO transaction: A request/response exchange between an ALTO 171 Client and an ALTO Server. 173 o Client: This term refers to an ALTO client, when used with a 174 capital "C". 176 o Endpoint (EP): An endpoint is defined as in {2.1} of [RFC7285]. 177 It can be for example a peer, a CDN storage location, a physical 178 server involved in a virtual server-supported application, a party 179 in a resource sharing swarm such as a computation grid or an 180 online multi-party game. 182 o Server: This term refers to an ALTO server, when used with a 183 capital "S". 185 References with curly brackets such as '{1.2.3}' are to sections in 186 the ALTO protocol specification [RFC7285], to avoid overloading the 187 document with citations of [RFC7285]. 189 3. Overview Of Approach 191 The following is a non-normative overview of the multi-cost 192 extensions defined in this document. It assumes the reader is 193 familiar with Cost Map resources in the ALTO Protocol ([RFC7285]). 195 3.1. Multi-Cost Data Format 197 Formally, the cost entries in an ALTO Cost Map can be any type of 198 JSON value (see the DstCosts object in {11.2.3.6}). However, that 199 section also says that an implementation may assume costs are JSON 200 numbers, unless the implementation is using an extension which 201 signals a different data type. 203 Therefore this document extends the definition of a Cost Map to allow 204 a cost to be an array of costs, one per metric, instead of just one 205 number. For example, here is a Cost Map with the "routingcost" and 206 "hopcount" metrics. Note that this is identical to a regular ALTO 207 Cost Map, except that the values are arrays instead of numbers. The 208 multiple metrics are listed in member "multi-cost-types", indicating 209 to the Client how to map values in the array to cost metrics. 211 { 212 "meta" : { 213 "dependent-vtags" : [ ... ], 214 "cost-type" : {}, 215 "multi-cost-types" : [ 216 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 217 {"cost-mode": "numerical", "cost-metric": "hopcount"} 218 ] 219 } 220 "cost-map" : { 221 "PID1": { "PID1":[1,0], "PID2":[5,23], "PID3":[10,5] }, 222 ... 223 } 224 } 226 Note also the presence of member '"cost-type" : {}' to maintain 227 backwards compatibility with [RFC7285]. 229 3.2. Compatibility With Legacy ALTO Clients 231 This document does not define any new media types. Instead, as 232 described below, it extends the specifications in the ALTO Server's 233 Information Resource Directory (IRD) so that legacy Clients will not 234 request array-valued Multi Cost Map resources. This relies on the 235 requirement that ALTO Clients MUST ignore unknown fields ({8.3.7}). 237 3.3. Filtered Multi Cost Map Resources 239 This document extends the Filtered Cost Map service to allow the same 240 resource to return either a single-valued Cost Map, as defined in 241 [RFC7285], or an array-valued Multi Cost Map, as defined in this 242 document. An extended Filtered Cost Map resource has a new 243 capability, "max-cost-types". The value is the maximum number of 244 cost types this resource can return for one request. The existence 245 of this capability means the resource understands the extensions in 246 this document. 248 For example, the following fragment from an IRD defines an extended 249 Filtered Cost Map resource: 251 "filtered-multicost-map" : { 252 "uri" : "http://alto.example.com/multi/costmap/filtered", 253 "media-types" : [ "application/alto-costmap+json" ], 254 "accepts" : [ "application/alto-costmapfilter+json" ], 255 "uses" : [ "my-default-network-map" ], 256 "capabilities" : { 257 "max-cost-types" : 2, 258 "cost-type-names" : [ "num-routingcost", 259 "num-hopcount" ], 260 ... 261 } 263 A legacy ALTO Client will ignore the "max-cost-types" capability, and 264 will send a request with the input parameter "cost-type" describing 265 the desired cost metric, as defined in [RFC7285]. The ALTO Server 266 will return a single-valued legacy Cost Map. 268 However, a multi-cost-aware ALTO Client will realize that this 269 resource supports the multi-cost extensions, and can send a POST 270 request with the new input parameter "multi-cost-types", whose value 271 is an array of cost types. Because the request has the "multi-cost- 272 types" parameter (rather than the "cost-type" parameter defined in 273 the base protocol), the Server realizes that the ALTO Client also 274 supports the extensions in this document, and hence responds with a 275 Multi Cost Map, with the costs in the order listed in "multi-cost- 276 types". 278 3.4. Endpoint Cost Service Resources 280 Section {4.1.4} of [RFC7285] specifies that "The Endpoint Cost 281 Service allows an ALTO Server to return costs directly amongst 282 endpoints.", whereas the Filtered Cost Map Service returns costs 283 amongst PIDs. This document uses the technique described in 284 Section 3.3 to extend the Endpoint Cost Service to return array- 285 valued costs to ALTO Clients who also are aware of these extensions. 287 3.5. Full Cost Map Resources 289 Section {11.3.2.3} of [RFC7285] requires a Filtered Cost Map to 290 return the entire Cost Map if the ALTO Client omits the source and 291 destination PIDs. Hence a Multi-Cost aware ALTO Client can use an 292 extended Filtered Cost Map resource to get a full Multi Cost Map. 294 Full Cost Map resources are GET-mode requests. The response for a 295 Full Cost Map conveying multiple cost types would include a "meta" 296 field that would itself include a "cost-type" field, that would list 297 several values corresponding to the cost types of the cost map. A 298 legacy ALTO Client would not be able to understand this list. 299 Neither would it be able to interpret the cost values array provided 300 by a Multi-Cost full maps. 302 3.6. Extended Constraint Tests 304 [RFC7285] defines a simple constraint test capability for Filtered 305 Cost Maps and Endpoint Cost Services. If a resource supports 306 constraints, the Server restricts the response to costs that satisfy 307 a list of simple predicates provided by the ALTO Client. For 308 example, if the ALTO Client gives the constraints 310 "constraints": ["ge 10", "le 20"] 312 Then the Server only returns costs in the range [10,20]. 314 To be useful with multi-cost requests, the constraint tests require 315 several extensions. 317 3.6.1. Extended constraint predicates 319 First, because a multi-cost request involves more than one cost 320 metric, the simple predicates must be extended to specify the metric 321 to test. Therefore we extend the predicate syntax to "[##] op 322 value", where "##" is the index of a cost metric in this multi-cost 323 request. 325 3.6.2. Extended logical combination of predicates 327 Second, once multiple cost metrics are involved, the "AND" of simple 328 predicates is no longer sufficient. To be useful, Clients must be 329 able to express "OR" tests. Hence we add a new field, "or- 330 constraints", to the Client request. The value is an array of arrays 331 of simple predicates, and represents the OR of ANDs of those 332 predicates. 334 Thus, the following request tells the Server to limit its response to 335 cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else 336 "routingcost" <= 10 AND "hopcount" <= 6: 338 { 339 "multi-cost-types": [ 340 {"cost-metric": "routingcost", "cost-mode": "numerical"}, 341 {"cost-metric": "hopcount", "cost-mode": "numerical"} 342 ], 343 "or-constraints": [ 344 ["[0] le 100", "[1] le 2"], 345 ["[0] le 10", "[1] le 6"] 346 ], 347 "pids": {...} 348 } 350 Note that a "constraints" parameter with the array of predicates [P1, 351 P2, ...] is equivalent to an "or-constraints" parameter with one 352 array of value [[P1, P2, ...]]. A Client is therefore allowed to 353 express either "constraints" or "or-constraints" but not both. 355 3.6.3. Testable Cost Types in constraints 357 Finally, a Client may want to test a cost type whose actual value is 358 irrelevant, as long as it satisfies the tests. For example, a Client 359 may want the value of the cost metric "routingcost" for all PID pairs 360 that satisfy constraints on the metric "hopcount", without needing 361 the actual value of "hopcount". 363 To this end, we add a specific parameter named "testable-cost-types", 364 that does not contain the same cost types as parameter "multi-cost- 365 types". The Client can express constraints only on cost types listed 366 in "testable-cost-types". 368 For example, the following request tells the Server to return just 369 "routingcost" for those source and destination pairs for which 370 "hopcount" is <= 6: 372 { 373 "multi-cost-types": [ 374 {"cost-metric": "routingcost", "cost-mode": "numerical"}, 375 ], 376 "testable-cost-types": [ 377 {"cost-metric": "hopcount", "cost-mode": "numerical"}, 378 ], 379 "constraints": ["[0] le 6"], 380 "pids": {...} 381 } 383 3.6.4. Testable Cost Type Names in IRD capabilities 385 In [RFC7285], when a resource's capability "constraints" is true, the 386 Server accepts constraints on all the cost types listed in the "cost- 387 type-names" capability. However, some ALTO Servers may not be 388 willing to allow constraint tests on all available cost metrics. 389 Therefore the Multi-Cost ALTO protocol extension defines the 390 capability field "testable-cost-type-names". Like "cost-type-names", 391 it is an array of cost type names. If present, that resource only 392 allows constraint tests on the cost types in that list. "testable- 393 cost-type-names" must be a subset of "cost-type-names". 395 3.6.5. Legacy ALTO Client issues 397 While a multi-cost-aware Client will recognize the "testable-cost- 398 type-names" field, and will honor those restrictions, a legacy Client 399 will not. Hence, when "constraints" has the value 'true', a legacy 400 client may send a request with a constraint test on any of the cost 401 types listed in "cost-type-names". 403 To avoid that problem, the "testable-cost-type-names" and "cost- 404 constraints" fields are mutually exclusive: a resource may define one 405 or the other capability, but MUST NOT define both. Thus a resource 406 that does not allow constraint tests on all cost metrics will set 407 "testable-cost-type-names" to the testable metrics, and will set 408 "cost-constraints" to "false". A multi-cost-aware Client will 409 recognize the "testable-cost-type-names" field, and will realize that 410 its existence means the resource does allow (limited) constraint 411 tests, while a legacy Client will think that resource does not allow 412 constraint tests at all. To allow legacy Clients to use constraint 413 tests, the ALTO Server can define an additional resource with "cost- 414 constraints" set to "true" and "cost-type-names" set to the metrics 415 which can be tested. 417 In the IRD example below, the resource "filtered-cost-map-extended" 418 provides values for three metrics: "num-routingcost", "num-hopcount" 419 and "num-bwscore". The capability "testable-cost-type-names" 420 indicates that the Server only allows constraints on "routingcost" 421 and "hopcount". A multi-cost capable Client will see this 422 capability, and will limit its constraint tests to those metrics. 423 Because capability "cost-constraints" is false (by default), a legacy 424 Client will not use constraint tests on this resource at all. 426 The second resource, "filtered-multicost-map", is similar to the 427 first, except that all the metrics it returns are testable. 428 Therefore it sets "cost-constraints" to "true", and does not set the 429 "testable-cost-type-names" field. A legacy Client that needs a 430 constraint test will use this resource rather than the first. A 431 multi-cost-aware Client that does not need to retrieve the "num- 432 bwscore" metric may use either resource. 434 Note that if a multi-cost Server specifies a "filtered-cost-map- 435 extended", it will most likely not specify an "filtered-multicost- 436 map" if the capabilities of the latter are covered by the 437 capabilities of the former or unless the "filtered-multicost-map" 438 ressource is also intended for legacy Clients. 440 "filtered-cost-map-extended" : { 441 "uri" : "http://alto.example.com/multi/extn/costmap/filtered", 442 "media-types" : [ "application/alto-costmap+json" ], 443 "accepts" : [ "application/alto-costmapfilter+json" ], 444 "uses" : [ "my-default-network-map" ], 445 "capabilities" : { 446 "max-cost-types" : 3, 447 "cost-type-names" : [ "num-routingcost", 448 "num-hopcount", 449 "num-bwscore"], 450 "testable-cost-type-names" : [ "num-routingcost", 451 "num-hopcount" ] 452 } 453 }, 455 "filtered-multicost-map" : { 456 "uri" : "http://alto.example.com/multi/costmap/filtered", 457 "media-types" : [ "application/alto-costmap+json" ], 458 "accepts" : [ "application/alto-costmapfilter+json" ], 459 "uses" : [ "my-default-network-map" ], 460 "capabilities" : { 461 "cost-constraints" : true, 462 "max-cost-types" : 2, 463 "cost-type-names" : [ "num-routingcost", 464 "num-hopcount"], 465 } 466 } 468 4. Protocol Extensions for Multi-Cost ALTO Transactions 470 This section formally specifies the extensions to [RFC7285] to 471 support Multi-Cost ALTO transactions. 473 This document uses the notation rules specified in {8.2}. In 474 particular, an optional field is enclosed by [ ]. In the 475 definitions, the JSON names of the fields are case sensitive. An 476 array is indicated by two numbers in angle brackets, , where m 477 indicates the minimal number of values and n is the maximum. When 478 this document uses * for n, it means no upper bound. 480 4.1. Filtered Cost Map Extensions 482 This document extends Filtered Cost Maps, as defined in {11.3.2} of 483 [RFC7285], by adding new input parameters and capabilities, and by 484 returning JSONArrays instead of JSONNumbers as the cost values. 486 The media type (11.3.2.1}, HTTP method (11.3.2.2} and "uses" 487 specifications (11.3.2.5} are unchanged. 489 4.1.1. Capabilities 491 The filtered cost map capabilities are extended with two new members: 493 o max-cost-types, 495 o testable-cost-type-names 497 The capability "max-cost-types" indicates whether this resource 498 supports the Multi-Cost ALTO extensions, and the capability 499 "testable-cost-type-names" allows the resource to restrict constraint 500 tests to a subset of the available cost types. With these two 501 additional members, the FilteredCostMapCapabilities object in 502 {11.3.2.4} is structured as follows: 504 object { 505 JSONString cost-type-names<1..*>; 506 [JSONBool cost-constraints;] 507 [JSONNumber max-cost-types;] 508 [JSONString testable-cost-type-names<1..*>;] 509 } FilteredCostMapCapabilities; 511 cost-type-names: As defined in {11.3.2.4} of [RFC7285]. 513 cost-constraints: As defined in {11.3.2.4} of [RFC7285]. Thus if 514 "cost-constraints" is true, the resource MUST accept constraint 515 tests on any cost type in "cost-type-names". Note in addition 516 that if "cost-constraints" is "true", the "testable-cost-type- 517 names" capability MUST NOT be present 519 max-cost-types: If present with value N greater than 0, this 520 resource understands the multi-cost extensions in this document, 521 and can return a Multi Cost Map with any combination of N or fewer 522 cost types in the "cost-type-names" list. If omitted, the default 523 value is 0. 525 testable-cost-type-names: If present, the resource allows constraint 526 tests, but only on the cost type names in this array. Each name 527 in "testable-cost-type-names" MUST also be in "cost-type-names". 528 If "testable-cost-type-names" is present, the "cost-constraints" 529 capability MUST NOT be true. 531 As discussed in Section 3.6.4, this capability is useful when a 532 Server is unable or unwilling to implement constraint tests on all 533 cost types. As discussed in Section 3.6.5, "testable-cost-type- 534 names" and "cost-constraints" are mutually exclusive to prevent 535 legacy Clients from issuing constraint tests on untestable cost 536 types. 538 4.1.2. Accept Input Parameters 540 The ReqFilteredCostMap object in {11.3.2.3} of [RFC7285] is extended 541 as follows: 543 object { 544 [CostType cost-type;] 545 [CostType multi-cost-types<1..*>;] 546 [CostType testable-cost-types<1..*>;] 547 [JSONString constraints<0..*>;] 548 [JSONString or-constraints<1..*><1..*>;] 549 [PIDFilter pids]; 550 } ReqFilteredCostMap; 552 cost-type: As defined in {11.3.2.3} of [RFC7285], with the 553 additional requirement that the Client MUST specify either "cost- 554 type" or "multi-cost-types", but MUST NOT specify both. Therefore 555 this field is made optional. When placing a single cost request 556 as specified in [RFC7285], a Client MUST use "cost-type". 558 multi-cost-types: If present, the ALTO Server MUST return array- 559 valued costs for the cost types in this list. For each entry, the 560 "cost-metric" and "cost-mode" fields MUST match one of the 561 supported cost types indicated in member "cost-type-names" of this 562 resource's "capabilities" field (Section 4.1.1). The Client MUST 563 NOT use this field unless this resource's "max-cost-types" 564 capability exists and has a value greater than 0. This field MUST 565 NOT have more than "max-cost-types" cost types. The Client MUST 566 specify either "cost-type" or "multi-cost-types", but MUST NOT 567 specify both. 569 Note that if "multi-cost-types" has one cost type, the values in 570 the cost map will be arrays with one value. 572 testable-cost-types: A list of cost types used for extended 573 constraint tests, as described for the "constraints" and "or- 574 constraints" parameters. These cost types must either be a subset 575 of the cost types in the resource's "testable-cost-type-names" 576 capability (Section 4.1.1), or else, if the resource's capability 577 "cost-constraints" is true, a subset of the cost types in the 578 resource's "cost-type-names" capability. 580 If "testable-cost-types" is omitted, it is assumed to have the 581 cost types in "multi-cost-types" or "cost-type". 583 This feature is useful when a Client wants to test a cost type 584 whose actual value is irrelevant, as long as it satisfies the 585 tests. For example, a Client may want the cost metric 586 "routingcost" for those PID pairs whose "hopcount" is less than 587 10. The exact hopcount does not matter. 589 constraints: If this resource's "max-cost-types" capability 590 (Section 4.1.1) has the value 0 (or is not defined), this 591 parameter is as defined in {11.3.2.3} of [RFC7285]: an array of 592 constraint tests related to each other by a logical AND. In this 593 case it MUST NOT be specified unless the resource's "cost- 594 constraints" capability is "true". 596 If this resource's "max-cost-types" capability has a value greater 597 than 0, then this parameter is an array of extended constraint 598 predicates as defined below and related to each other by a logical 599 AND. In this case, it MAY be specified if the resource allows 600 constraint tests (the resource's "cost-constraints" capability is 601 "true" or its "testable-cost-type-names" capability is not empty). 603 This parameter MUST NOT be specified if the "or-constraints" 604 parameter is specified. 606 An extended constraint predicate consists of two or three entities 607 separated by white space: (1) an optional cost type index, of the 608 form "[#]", with default value "[0]", (2) a required operator, and 609 (3) a required target value. The operator and target value are as 610 defined in {11.3.2.3} of [RFC7285]. The cost type index, i, 611 specifies the cost type to test. If the "testable-cost-type" 612 parameter is present, the test applies to the i'th cost type in 613 "testable-cost-types", starting with index 0. Otherwise if the 614 "multi-cost-types" parameter is present, the test applies to the 615 i'th cost type in that array. If neither parameters are present, 616 the test applies to the cost type in the "cost-type" parameter, in 617 which case the index MUST be 0. Regardless of how the tested cost 618 type is selected, it MUST be in the resource's "testable-cost- 619 type-names" capability, or, if not present, in the "cost-type- 620 names" capability. 622 As an example, suppose "multi-cost-types" has the single element 623 "routingcost", "testable-cost-types" has the single element 624 "hopcount", and "constraints" has the single element "[0] le 5". 625 This is equivalent to the database query "SELECT and provide 626 routingcost WHERE hopcount <= 5". 628 Note that the index is optional, so a constraint test as defined 629 in {11.3.2.3}, such as "le 10", is equivalent to "[0] le 10". 630 Thus legacy constraint tests are also legal extended constraint 631 tests. 633 Note that a "constraints" parameter with the array of extended 634 predicates [P1, P2, ...] is equivalent to an "or-constraints" 635 parameter as defined below, with the value [[P1, P2, ...]]. 637 or-constraints: A JSONArray of JSONArrays of JSONStrings, where each 638 string is an extended constraint predicate as defined above. The 639 "or-constraint" tests are interpreted as the logical OR of ANDs of 640 predicates. That is, the ALTO Server should return a cost point 641 only if it satisfies all constraints in any one of the sub-arrays. 643 This parameter MAY be specified if this resource's "max-cost- 644 types" capability is defined with a value greater than 0 645 (Section 4.1.1), and if the resource allows constraint tests (the 646 resource's "cost-constraints" capability is "true" or its 647 "testable-cost-type-names" capability is not empty). Otherwise 648 this parameter MUST NOT be specified. 650 This parameter MUST NOT be specified if the "constraints" 651 parameter is specified. 653 This parameter MUST NOT contain any empty array of AND predicates. 654 An empty array would be equivalent to a constraint that is always 655 "true". An OR combination including such a constraint would be 656 always "true" and thus useless. 658 As an example, suppose "multi-cost-types" has the two elements 659 "routingcost" and "bandwidthscore", and "testable-cost-types" has 660 the two elements "routingcost" and "hopcount", and "or- 661 constraints" has the two elements ["[0] le 100", "[1] le 2"] and 662 ["[0] le 10", "[1] le 6"]. This is equivalent to the words: 663 "SELECT and provide routingcost and bandwidthscore WHERE 664 ("routingcost" <= 100 AND "hopcount" <= 2) OR ("routingcost" <= 10 665 AND "hopcount" <= 6)". 667 Note that if the "max-cost-types" capability has a value greater 668 than 0, a Client MAY use the "or-constraints" parameter together 669 with the "cost-type" parameter. That is, if the Client and Server 670 are both aware of the extensions in this document, a Client MAY 671 use an "OR" test for a single-valued cost request. 673 pids: As defined in {11.3.2.3} of [RFC7285]. 675 4.1.3. Response 677 If the Client specifies the "cost-type" input parameter, the response 678 is exactly as defined in {11.2.3.6} of [RFC7285]. If the Client 679 provides the "multi-cost-types" instead, then the response is changed 680 as follows: 682 o In "meta", the value of field "cost-type" will be ignored by the 683 receiver and set to {}. Instead, the field "multi-cost-types" is 684 added with the same value as the "multi-cost-types" input 685 parameter. 687 o The costs are JSONArrays, instead of JSONNumbers. All arrays have 688 the same cardinality as the "multi-cost-types" input parameter, 689 and contain the cost type values in that order. If a cost type is 690 not available for a particular source and destination, the ALTO 691 Server MUST use the JSON "null" value for that array element. If 692 none of the cost types are available for a particular source and 693 destination, the ALTO Server MAY omit the entry for that source 694 and destination. 696 4.2. Endpoint Cost Service Extensions 698 This document extends the Endpoint Cost Service, as defined in 699 {11.5.1} of [RFC7285], by adding new input parameters and 700 capabilities, and by returning JSONArrays instead of JSONNumbers as 701 the cost values. 703 The media type {11.5.1.1}, HTTP method {11.5.1.2} and "uses" 704 specifications {11.5.1.5} are unchanged. 706 4.2.1. Capabilities 708 The extensions to the Endpoint Cost Service capabilities are 709 identical to the extensions to the Filtered Cost Map (see 710 Section 4.1.1). 712 4.2.2. Accept Input Parameters 714 The ReqEndpointCostMap object in {11.5.1.3} of [RFC7285] is extended 715 as follows: 717 object { 718 [CostType cost-type;] 719 [CostType multi-cost-types<1..*>;] 720 [CostType testable-cost-types<1..*>;] 721 [JSONString constraints<0..*>;] 722 [JSONString or-constraints<1..*><1..*>;] 723 EndpointFilter endpoints; 724 } ReqEndpointCostMap; 726 cost-type: As defined in {11.5.1.3} of [RFC7285], with the 727 additional requirement that the Client MUST specify either "cost- 728 type" or "multi-cost-types", but MUST NOT specify both. 730 multi-cost-types: If present, the ALTO Server MUST return array- 731 valued costs for the cost types in this list. For each entry, the 732 "cost-metric" and "cost-mode" fields MUST match one of the 733 supported cost types indicated in this resource's "capabilities" 734 field (Section 4.2.1). The Client MUST NOT use this field unless 735 this resource's "max-cost-types" capability exists and has a value 736 greater than 0. This field MUST NOT have more than "max-cost- 737 types" cost types. The Client MUST specify either "cost-type" or 738 "multi-cost-types", but MUST NOT specify both. 740 Note that if "multi-cost-types" has one cost type, the values in 741 the cost map will be arrays with one value. 743 testable-cost-types, constraints, or-constraints: Defined 744 equivalently to the corresponding input parameters for an extended 745 Filtered Cost Map (Section 4.1.2). 747 endpoints: As defined in {11.5.1.3} of [RFC7285]. 749 4.2.3. Response 751 The extensions to the Endpoint Cost Service response are similar to 752 the extensions to the Filtered Cost Map response (Section 4.1.3). 753 Specifically, if the Client specifies the "cost-type" input 754 parameter, the response is exactly as defined in {11.5.1.6} of 755 [RFC7285]. If the Client provides the "multi-cost-types" instead, 756 then the response is changed as follows: 758 o In "meta", the value of field "cost-type" will be ignored by the 759 receiver and set to {}. Instead, the field "multi-cost-types" is 760 added with the same value as the "multi-cost-types" input 761 parameter. 763 o The costs are JSONArrays, instead of JSONNumbers. All arrays have 764 the same cardinality as the "multi-cost-types" input parameter, 765 and contain the cost type values in that order. If a cost type is 766 not available for a particular source and destination, the ALTO 767 Server MUST use the JSON "null" value for that array element. If 768 none of the cost types are available for a particular source and 769 destination, the ALTO Server MAY omit the entry for that source 770 and destination. 772 5. Examples 774 This section provides examples of Multi-Cost ALTO transactions. It 775 uses cost metrics, in addition to the mandatory legacy 'routingcost', 776 that are deliberately irrelevant and not registered at the IANA. 778 5.1. Information Resource Directory 780 The following is an example of an ALTO Server's Information Resource 781 Directory. In addition to Network and Cost Map resources, it defines 782 two Filtered Cost Map and an Endpoint Cost Service, which all 783 understand the multi-cost extensions. 785 GET /directory HTTP/1.1 786 Host: alto.example.com 787 Accept: application/alto-directory+json,application/alto-error+json 789 HTTP/1.1 200 OK 790 Content-Length: 2704 791 Content-Type: application/alto-directory+json 793 { 794 "meta" : { 795 "default-alto-network-map" : "my-default-network-map", 796 "cost-types" : { 797 "num-routing" : { 798 "cost-mode" : "numerical", 799 "cost-metric" : "routingcost" 800 }, 801 "num-shoesize" : { 802 "cost-mode" : "numerical", 803 "cost-metric" : "shoesize" 804 }, 805 "num-scenery" : { 806 "cost-mode" : "numerical", 807 "cost-metric" : "sceneryrate" 808 } 809 } 810 }, 811 "resources" : { 812 "my-default-network-map" : { 813 "uri" : "http://alto.example.com/networkmap", 814 "media-type" : "application/alto-networkmap+json" 815 }, 816 "numerical-routing-cost-map" : { 817 "uri" : "http://alto.example.com/costmap/num-routing", 818 "media-types" : [ "application/alto-costmap+json" ], 819 "uses" : [ "my-default-network-map" ], 820 "capabilities" : { 821 "cost-type-names" : [ "num-routing" ] 822 } 823 }, 824 "numerical-shoesize-cost-map" : { 825 "uri" : "http://alto.example.com/costmap/num-shoesize", 826 "media-types" : [ "application/alto-costmap+json" ], 827 "uses" : [ "my-default-network-map" ], 828 "capabilities" : { 829 "cost-type-names" : [ "num-shoesize" ] 830 } 831 }, 832 "filtered-multicost-map" : { 833 "uri" : "http://alto.example.com/multi/costmap/filtered", 834 "media-types" : [ "application/alto-costmap+json" ], 835 "accepts" : [ "application/alto-costmapfilter+json" ], 836 "uses" : [ "my-default-network-map" ], 837 "capabilities" : { 838 "cost-constraints" : true, 839 "max-cost-types" : 2, 840 "cost-type-names" : [ "num-routingcost", 841 "num-shoesize" ] 842 } 843 }, 844 "filtered-cost-map-extended" : { 845 "uri" : "http://alto.example.com/multi/extn/costmap/filtered", 846 "media-types" : [ "application/alto-costmap+json" ], 847 "accepts" : [ "application/alto-costmapfilter+json" ], 848 "uses" : [ "my-default-network-map" ], 849 "capabilities" : { 850 "max-cost-types" : 3, 851 "cost-type-names" : [ "num-routingcost", 852 "num-shoesize", 853 "num-scenery"], 854 "testable-cost-type-names" : [ "num-routingcost", 855 "num-shoesize" ] 856 } 857 }, 858 "endpoint-multicost-map" : { 859 "uri" : "http://alto.example.com/multi/endpointcost/lookup", 860 "media-types" : [ "application/alto-endpointcost+json" ], 861 "accepts" : [ "application/alto-endpointcostparams+json" ], 862 "uses" : [ "my-default-network-map" ], 863 "capabilities" : { 864 "cost-constraints" : true, 865 "max-cost-types" : 2, 866 "cost-type-names" : [ "num-routingcost", 867 "num-shoesize" ] 868 } 869 } 870 } 871 } 873 5.2. Multi-Cost Filtered Cost Map: Example #1 875 This example illustrates a simple multi-cost ALTO transaction. The 876 ALTO Server provides two Cost Types, "routingcost" and "shoesize", 877 both in "numerical" mode. The Client wants the entire Multi-Cost 878 Map. The Server does not know the value of "routingcost" between 879 PID2 and PID3, and hence returns the value 'null' for "routingcost" 880 between PID2 and PID3. 882 POST /multi/costmap/filtered" HTTP/1.1 883 Host: alto.example.com 884 Accept: application/alto-costmap+json,application/alto-error+json 885 Content-Type: application/alto-costmapfilter+json 886 Content-Length: 206 888 { 889 "multi-cost-types": [ 890 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 891 {"cost-mode": "numerical", "cost-metric": "shoesize"} 892 ], 893 "pids" : { 894 "srcs" : [ ], 895 "dsts" : [ ] 896 } 897 } 899 HTTP/1.1 200 OK 900 Content-Type: application/alto-costmap+json 901 Content-Length: 549 903 { 904 "meta" : { 905 "dependent-vtags" : [ 906 {"resource-id": "my-default-network-map", 907 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 908 } 909 ], 910 "cost-type" : {}, 911 "multi-cost-types" : [ 912 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 913 {"cost-mode": "numerical", "cost-metric": "shoesize"} 914 ] 915 } 916 "cost-map" : { 917 "PID1": { "PID1":[1,0], "PID2":[4,3], "PID3":[10,2] }, 918 "PID2": { "PID1":[15,5], "PID2":[1,0], "PID3":[null,9] }, 919 "PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0] } 920 } 921 } 923 5.3. Multi-Cost Filtered Cost Map: Example #2 925 This example uses constraints to restrict the returned source/ 926 destination PID pairs to those with "routingcost" between 5 and 10, 927 or "shoesize" equal to 0. 929 POST /multi/costmap/filtered HTTP/1.1 930 Host: alto.example.com 931 Accept: application/alto-costmap+json,application/alto-error+json 932 Content-Type: application/alto-costmapfilter+json 933 Content-Length: 333 935 { 936 "multi-cost-types" : [ 937 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 938 {"cost-mode": "numerical", "cost-metric": "shoesize"} 939 ], 940 "or-constraints" : [ ["[0] ge 5", "[0] le 10"], 941 ["[1] eq 0"] ] 942 "pids" : { 943 "srcs" : [ "PID1", "PID2" ], 944 "dsts" : [ "PID1", "PID2", "PID3" ] 945 } 946 } 948 HTTP/1.1 200 OK 949 Content-Type: application/alto-costmap+json 950 Content-Length: 461 952 { 953 "meta" : { 954 "dependent-vtags" : [ 955 {"resource-id": "my-default-network-map", 956 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 957 } 958 ], 959 "cost-type" : {}, 960 "multi-cost-types" : [ 961 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 962 {"cost-mode": "numerical", "cost-metric": "shoesize"} 963 ] 964 } 965 "cost-map" : { 966 "PID1": { "PID1": [1,0], "PID3": [10,5] }, 967 "PID2": { "PID2": [1,0] } 968 } 969 } 971 5.4. Multi-Cost Filtered Cost Map: Example #3 973 This example uses extended constraints to limit the response to cost 974 points with ("routingcost" <= 10 and "shoesize" <= 2), or else 975 ("routingcost" <= 3 and "shoesize" <= 6). Unlike the previous 976 example, the Client is only interested in the "routingcost" cost 977 type, and uses the "cost-type" parameter instead of "multi-cost- 978 types" to tell the Server to return scalar costs instead of array 979 costs. 981 In this example, "[0]" means the constraint applies to "routingcost" 982 because that is the first cost type in the "testable-cost-types" 983 parameter. (If "testable-cost-types" is omitted, it is assumed to be 984 the same as "multi-cost-types".) The choice of using an index to 985 refer to cost types aims at minimizing the length of the expression 986 of constraints, especially for those combining several OR and AND 987 expressions. It was also the shortest path from the constraints 988 design in [RFC7285]. 990 POST /multi/multicostmap/filtered HTTP/1.1 991 Host: alto.example.com 992 Accept: application/alto-costmap+json,application/alto-error+json 993 Content-Type: application/alto-costmapfilter+json 994 Content-Length: 390 996 { 997 "cost-type" : { 998 "cost-mode": "numerical", "cost-metric": "routingcost" 999 }, 1000 "testable-cost-types" : [ 1001 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1002 {"cost-mode": "numerical", "cost-metric": "shoesize"} 1003 ], 1004 "or-constraints": [ 1005 ["[0] le 10", "[1] le 2"], 1006 ["[0] le 3", "[1] le 6"] 1007 ], 1008 "pids" : { 1009 "srcs" : [ ], 1010 "dsts" : [ ] 1011 } 1012 } 1013 HTTP/1.1 200 OK 1014 Content-Type: application/alto-costmap+json 1015 Content-Length: 368 1017 { 1018 "meta" : { 1019 "dependent-vtags" : [ 1020 {"resource-id": "my-default-network-map", 1021 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1022 } 1023 ], 1024 "cost-type" : { 1025 "cost-mode": "numerical", "cost-metric": "routingcost" 1026 } 1027 } 1028 "cost-map" : { 1029 "PID1": { "PID1": 1, "PID3": 10 }, 1030 "PID2": { "PID2": 1 }, 1031 "PID3": { "PID3": 1 } 1032 } 1033 } 1035 5.5. Multi-Cost Filtered Cost Map: Example #4 1037 This example uses extended constraints to limit the response to cost 1038 points with ("routingcost" <= 10 and "shoesize" <= 2), or else 1039 ("routingcost" <= 3 and "shoesize" <= 6). In this example, the 1040 Client is interested in the "routingcost" and "sceneryrate" cost 1041 metrics, but not in the "shoesize" metric: 1043 POST /multi/extn/costmap/filtered HTTP/1.1 1044 Host: alto.example.com 1045 Accept: application/alto-costmap+json,application/alto-error+json 1046 Content-Type: application/alto-costmapfilter+json 1047 Content-Length: 461 1049 { 1050 "multi-cost-types" : [ 1051 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1052 {"cost-mode": "numerical", "cost-metric": "sceneryrate"} 1053 ], 1054 "testable-cost-types" : [ 1055 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1056 {"cost-mode": "numerical", "cost-metric": "shoesize"} 1057 ], 1058 "or-constraints": [ 1059 ["[0] le 10", "[1] le 2"], 1061 ["[0] le 3", "[1] le 6"] 1062 ], 1063 "pids" : { 1064 "srcs" : [ ], 1065 "dsts" : [ ] 1066 } 1067 } 1069 HTTP/1.1 200 OK 1070 Content-Type: application/alto-costmap+json 1071 Content-Length: 481 1073 { 1074 "meta" : { 1075 "dependent-vtags" : [ 1076 {"resource-id": "my-default-network-map", 1077 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1078 } 1079 ], 1080 "cost-type" : {}, 1081 "multi-cost-types" : [ 1082 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1083 {"cost-mode": "numerical", "cost-metric": "sceneryrate"} 1084 ] 1085 } 1086 "cost-map" : { 1087 "PID1": { "PID1": [1,16] "PID3": [10,19] }, 1088 "PID2": { "PID2": [1,8] }, 1089 "PID3": { "PID3": [1,19] } 1090 } 1091 } 1093 5.6. Endpoint Cost Service 1095 This example uses the Endpoint Cost Service to retrieve the 1096 "routingcost" and "shoesize" for selected endpoints, limiting the 1097 response to costs with either low shoesize and reasonable routingcost 1098 (shoesize <= 2 and routingcost <= 10), or else low routingcost and 1099 reasonable shoesize (routingcost <= 3 and shoesize <= 6). 1101 POST /multi/endpointcost/lookup HTTP/1.1 1102 Host: alto.example.com 1103 Accept: application/alto-endpointcost+json, 1104 application/alto-error+json 1105 Content-Type: application/alto-endpoincostparams+json 1106 Content-Length: 455 1107 { 1108 "multi-cost-types" : [ 1109 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1110 {"cost-mode": "numerical", "cost-metric": "shoesize"} 1111 ], 1112 "or-constraints": [ 1113 ["[0] le 10", "[1] le 2"], 1114 ["[0] le 3", "[1] le 6"] 1115 ], 1116 "endpoints" : { 1117 "srcs": [ "ipv4:192.0.2.2", "ipv6:2001:db8::1:0 ], 1118 "dsts": [ 1119 "ipv4:192.0.2.89", 1120 "ipv4:198.51.100.34", 1121 "ipv4:203.0.113.45", 1122 "ipv6:2001:db8::10" 1123 ] 1124 } 1125 } 1127 HTTP/1.1 200 OK 1128 Content-Length: 419 1129 Content-Type: application/alto-endpointcost+json 1131 { 1132 "meta" : { 1133 "multi-cost-types" : [ 1134 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1135 {"cost-mode": "numerical", "cost-metric": "shoesize"} 1136 ] 1137 } 1138 "endpoint-cost-map" : { 1139 "ipv4:192.0.2.2": { 1140 "ipv4:192.0.2.89": [15, 5], 1141 "ipv4:203.0.113.45": [4, 23] 1142 } 1143 "ipv6:2001:db8::1:0": { 1144 "ipv4:198.51.100.34": [16, 5], 1145 "ipv6:2001:db8::10": [10, 2] 1146 } 1147 } 1148 } 1150 6. IANA Considerations 1152 This document does not define any new media types or introduce any 1153 new IANA considerations. 1155 7. Privacy And Security Considerations 1157 This document does not introduce any privacy or security issues not 1158 already present in the ALTO protocol. 1160 The Multi-Cost optimization even tends to reduce the on the wire data 1161 exchange volume, compared to multiple single cost ALTO transactions. 1162 Likewise, the risk related to massive Multi-Cost requests is 1163 moderated by the fact that Multi-Cost constraints additionally filter 1164 ALTO Server responses and thus reduce their volume. 1166 Note that, because queries for multiple metrics represent a stronger 1167 fingerprinting signal than queries for a single metric, 1168 implementations of this protocol may leak more information about the 1169 ALTO client than would occur with a succession of individual queries. 1170 Though, in many cases it would already be possible to link those 1171 queries by using the source IP address or other existing information. 1173 8. Acknowledgements 1175 The authors would like to thank Richard Alimi, Fred Baker, Dhruv 1176 Dhodi, Vijay Gurbani, Dave Mac Dysan, Young Lee, Richard Yang, for 1177 fruitful discussions and feedback on this document and previous 1178 versions. Gao Kai, Hans Seidel, Richard Yang, Qiao Xiang and Wang 1179 Xin provided substantial review feedback and suggestions to the 1180 protocol design. 1182 9. References 1184 9.1. Normative References 1186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1187 Requirement Levels", BCP 14, RFC 2119, 1188 DOI 10.17487/RFC2119, March 1997, 1189 . 1191 [RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 1192 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 1193 Traffic Optimization (ALTO) Protocol", RFC 7285, September 1194 2014. 1196 9.2. Informative References 1198 [RFC5693] "Application Layer Traffic Optimization (ALTO) Problem 1199 Statement", October 2009. 1201 [RFC6708] "Application-Layer Traffic Optimization (ALTO) 1202 Requirements", February 2012. 1204 Authors' Addresses 1206 Sabine Randriamasy 1207 Nokia Bell Labs 1208 Route de Villejust 1209 NOZAY 91460 1210 FRANCE 1212 Email: Sabine.Randriamasy@nokia-bell-labs.com 1214 Wendy Roome 1215 Nokia Bell Labs 1216 124 Burlington Rd 1217 Murray Hill, NJ 07974 1218 USA 1220 Email: ietf@wdroome.com 1222 Nico Schwan 1223 Thales Deutschland 1224 Lorenzstrasse 10 1225 Stuttgart 70435 1226 Germany 1228 Email: nico.schwan@thalesgroup.com