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