idnits 2.17.1 draft-ietf-alto-multi-cost-07.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 (March 10, 2017) is 2575 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 1179 -- Looks like a reference, but probably isn't: '20' on line 357 == Missing Reference: 'TODO' is mentioned on line 828, but not defined -- Looks like a reference, but probably isn't: '1' on line 1122 -- Looks like a reference, but probably isn't: '0' on line 1010 -- Looks like a reference, but probably isn't: '5' on line 1178 -- Looks like a reference, but probably isn't: '16' on line 1178 -- Looks like a reference, but probably isn't: '19' on line 1122 -- Looks like a reference, but probably isn't: '8' on line 1121 -- Looks like a reference, but probably isn't: '15' on line 1174 -- Looks like a reference, but probably isn't: '4' on line 1175 -- Looks like a reference, but probably isn't: '23' on line 1175 -- Looks like a reference, but probably isn't: '2' on line 1179 == Unused Reference: 'RFC5693' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: 'RFC6708' is defined on line 1222, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 4 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: September 11, 2017 N. Schwan 6 Thales Deutschland 7 March 10, 2017 9 Multi-Cost ALTO 10 draft-ietf-alto-multi-cost-07 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. An ALTO Server may 17 offer a variety of cost metrics, based on latency,bandwidth, hop 18 count, jitter, or whatever else the ALTO Server deems useful. For 19 example, when downloading a file that is mirrored on several sites, a 20 user application may consider more than one metric, perhaps trading 21 bandwidth for latency to determine the most efficient mirror site. 23 While the base ALTO Protocol allows an ALTO Client to use more than 24 one cost metric, to do so, the Client must request each metric 25 separately. This document defines a new service that allows a Client 26 to retrieve several cost metrics with one request, which is 27 considerably more efficient. In addition, this document extends the 28 ALTO constraint tests to allow a user to specify an arbitrary logical 29 combination of tests on several cost metrics. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 11, 2017. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Overview Of Approach . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Multi-Cost Data Format . . . . . . . . . . . . . . . . . 5 75 3.2. Compatibility With Legacy ALTO Clients . . . . . . . . . 6 76 3.3. Filtered Multi Cost Map Resources . . . . . . . . . . . . 6 77 3.4. Endpoint Cost Service Resources . . . . . . . . . . . . . 7 78 3.5. Full Cost Map Resources . . . . . . . . . . . . . . . . . 7 79 3.6. Extended Constraint Tests . . . . . . . . . . . . . . . . 8 80 3.6.1. Extended constraint predicates . . . . . . . . . . . 8 81 3.6.2. Extended logical combination of predicates . . . . . 8 82 3.6.3. Testable Cost Types in constraints . . . . . . . . . 9 83 3.6.4. Testable Cost Type Names in IRD capabilities . . . . 10 84 3.6.5. Legacy ALTO Client issues . . . . . . . . . . . . . . 10 85 4. Protocol Extensions for Multi-Cost ALTO Transactions . . . . 11 86 4.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11 87 4.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 12 88 4.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 13 89 4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 16 90 4.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 16 91 4.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 16 92 4.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 16 93 4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 17 94 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 5.1. Information Resource Directory . . . . . . . . . . . . . 18 96 5.2. Multi-Cost Filtered Cost Map: Example #1 . . . . . . . . 20 97 5.3. Multi-Cost Filtered Cost Map: Example #2 . . . . . . . . 22 98 5.4. Multi-Cost Filtered Cost Map: Example #3 . . . . . . . . 23 99 5.5. Multi-Cost Filtered Cost Map: Example #4 . . . . . . . . 25 100 5.6. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 26 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 102 7. Privacy And Security Considerations . . . . . . . . . . . . . 27 103 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 106 9.2. Informative References . . . . . . . . . . . . . . . . . 28 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 109 1. Introduction 111 IETF has defined ALTO services in [RFC7285] to provide guidance to 112 overlay applications, which have to select one or several hosts from 113 a set of candidates that are able to provide a desired resource. 114 This guidance is based on parameters such as the topological 115 distance, that affect performance and efficiency of the data 116 transmission between the hosts. The purpose of ALTO is to improve 117 Quality of Experience (QoE) in the application while reducing 118 resource consumption in the underlying network infrastructure. The 119 ALTO protocol conveys the Internet View from the perspective of a 120 Provider Network region that spans from a region to one or more 121 Autonomous System (AS) and is called a Network Map. ALTO may also 122 provide the Provider determined Cost Map between locations of the 123 Network Map or Endpoint Cost Map between groups of individual 124 endpoints. Last, these costs are provided as numerical or ordinal 125 values. 127 Current ALTO Cost Maps and their modes provide values such as 128 hopcount and administrative routing cost to reflect ISP routing 129 preferences. Recently, new use cases have extended the usage scope 130 of ALTO to Content Delivery Networks (CDN), Data Centers and 131 applications that need additional information to select their 132 endpoints or handle their Provider-defined IDentifiers (PID)s. 134 Thus a multitude of new Cost Types that better reflect the 135 requirements of these applications are expected to be specified. 136 Handling multiple costs, however, can add more complexities, such as 137 overheads and consistency. In particular, cost values that change 138 more frequently than previously assumed may require more frequent 139 ALTO requests. Moreover, to make sure to have up to date values, 140 applications using several frequently changing metrics will tend to 141 refresh their values simultaneously. 143 The ALTO protocol [RFC7285], which this document refers to as the 144 base protocol, restricts ALTO Cost Maps and Endpoint Cost Services to 145 only one Cost Type and Cost Mode per ALTO request. To retrieve 146 information for several Cost Types, an ALTO Client must send several 147 separate requests to the Server. 149 It would be far more efficient, in terms of Round Trip Time (RTT), 150 traffic, and processing load on the ALTO Client and Server, to get 151 all costs with a single query/response transaction. Vector costs 152 provide a robust and natural input to multi-variate path computation 153 as well as robust multi-variate selection of multiple endpoints. In 154 particular, one Cost Map reporting on N Cost Types is less bulky than 155 N Cost Maps containing one Cost Type each. This is valuable for both 156 the storage of these maps and for their transmission. Additionally, 157 for many emerging applications that need information on several Cost 158 Types, having them gathered in one map will save time. Another 159 potential advantage is consistency: providing values for several Cost 160 Types in one single batch is useful for ALTO Clients needing 161 synchronized ALTO information updates. 163 Along with multi-cost values queries, the filtering capabilities need 164 to be extended to allow constraints on multiple metrics. The base 165 protocol allows an ALTO Client to provide optional constraint tests 166 for a Filtered Cost Map or the Endpoint Cost Service. In the base 167 protocol, the constraint tests are limited to the AND-combination of 168 simple comparison tests on the value of the (single) requested Cost 169 Type. It is therefore necessary to allow constraints on multiple 170 metrics. Beyond that, applications that are sensitive to several 171 metrics and struggle with complicated network conditions may need to 172 arbitrate between conflicting objectives such as routing cost and 173 network performance. To address this issue, this document extends 174 the base protocol by extending constraints to test multiple metrics, 175 and by allowing these constraints to be combined with logical 'ORs' 176 as well as logical 'ANDs'. This allows an application to make 177 requests such as: "select solutions with either (moderate "hopcount" 178 AND high "routingcost") OR (higher "hopcount" AND moderate 179 "routingcost")". To ensure compatibility with legacy ALTO Clients, 180 only the Filtered Cost Map and Endpoint Cost Map services are 181 extended to return Multi-Cost values. Full Cost Map services remain 182 unchanged, and are restricted to returning single cost values. 184 This document is organized as follows: Section 2 defines terminology 185 used in this document. Section 3 gives a non-normative overview of 186 the multi-cost extensions, and Section 4 gives their formal 187 definitions. Section 5 gives several complete examples. The 188 remaining sections describe the IANA and privacy considerations. 190 2. Terminology 192 o {1.2.3}: References with curly brackets are to sections in the 193 ALTO protocol specification [RFC7285]. 195 o ALTO transaction: A request/response exchange between an ALTO 196 Client and an ALTO Server. 198 o Application client (AC): This term generalizes the case of a P2P 199 client to include the case of a CDN client, a client of an 200 application running on a virtual server, a Grid application 201 client, or any application client that can choose between several 202 connection points for data or resource exchange. 204 o Client: This term refers to an ALTO client, when used with a 205 capital "C". 207 o Endpoint (EP): An endpoint is defined as in {2.1} of [RFC7285]. 208 It can be for example a peer, a CDN storage location, a physical 209 server involved in a virtual server-supported application, a party 210 in a resource sharing swarm such as a computation grid or an 211 online multi-party game. 213 o Endpoint Discovery (EP Discovery): This term covers the different 214 types of processes used to discover the eligible endpoints. 216 o Network Service Provider (NSP): Includes both ISPs, who provide 217 means to transport the data, and CDNs who care for the 218 dissemination, persistent storage and possibly identification of 219 the best/closest content copy. 221 o Server: This term refers to an ALTO server, when used with a 222 capital "S". 224 3. Overview Of Approach 226 The following is a non-normative overview of the multi-cost 227 extensions defined in this document. It assumes the reader is 228 familiar with Cost Map resources in the ALTO Protocol ([RFC7285]). 230 3.1. Multi-Cost Data Format 232 Formally, the cost entries in an ALTO Cost Map can be any type of 233 JSON value (see the DstCosts object in {11.2.3.6}). However, that 234 section also says that an implementation may assume costs are JSON 235 numbers, unless the implementation is using an extension which 236 signals a different data type. 238 Therefore this document extends the definition of a Cost Map to allow 239 a cost to be an array of costs, one per metric, instead of just one 240 number. For example, here is a Cost Map with the "routingcost" and 241 "hopcount" metrics. Note that this is identical to a regular ALTO 242 Cost Map, except that the values are arrays instead of numbers. 244 { 245 "meta" : { 246 "dependent-vtags" : [ ... ], 247 "cost-type" : {}, 248 "multi-cost-types" : [ 249 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 250 {"cost-mode": "numerical", "cost-metric": "hopcount"} 251 ] 252 } 253 "cost-map" : { 254 "PID1": { "PID1":[1,0], "PID2":[5,23], "PID3":[10,5] }, 255 ... 256 } 257 } 259 3.2. Compatibility With Legacy ALTO Clients 261 The multi-cost extensions defined in this document must not break 262 legacy implementations (that is, ALTO Clients and servers which are 263 not aware of these extensions). One way to achieve that would be to 264 define a new media type for an array-valued Multi Cost Map. However, 265 as indicated above, an array-valued Multi Cost Map is almost 266 identical to a single-valued Cost Map, so it should be simple to 267 write a parser which handles either type of cost map. Hence defining 268 a new media type could result in a lot of wasteful duplication. 270 Therefore this document does not define any new media types. 271 Instead, as described below, it extends the specifications in the 272 ALTO Server's Information Resource Directory (IRD) so that legacy 273 Clients will not request array-valued Multi Cost Map resources. This 274 relies on the requirement that ALTO Clients MUST ignore unknown 275 fields ({8.3.7}). 277 3.3. Filtered Multi Cost Map Resources 279 This document extends the Filtered Cost Map service to allow the same 280 resource to return either a single-valued Cost Map, as defined in 281 [RFC7285], or an array-valued Multi Cost Map, as defined in this 282 document. An extended Filtered Cost Map resource has a new 283 capability, "max-cost-types". The value is the maximum number of 284 cost types this resource can return for one request. The existence 285 of this capability means the resource understands the extensions in 286 this document. 288 For example, the following fragment from an IRD defines an extended 289 Filtered Cost Map resource: 291 "filtered-multicost-map" : { 292 "uri" : "http://alto.example.com/multi/costmap/filtered", 293 "media-types" : [ "application/alto-costmap+json" ], 294 "accepts" : [ "application/alto-costmapfilter+json" ], 295 "uses" : [ "my-default-network-map" ], 296 "capabilities" : { 297 "max-cost-types" : 2, 298 "cost-type-names" : [ "num-routingcost", 299 "num-hopcount" ], 300 ... 301 } 303 A legacy ALTO Client will ignore the "max-cost-types" capability, and 304 will send a request with the input parameter "cost-type" describing 305 the desired cost metric, as defined in [RFC7285]. The ALTO Server 306 will return a single-valued legacy Cost Map. 308 However, a multi-cost-aware ALTO Client will realize that this 309 resource supports the multi-cost extensions, and can send a POST 310 request with the new input parameter "multi-cost-types", whose value 311 is an array of cost types. Because the request has the "multi-cost- 312 types" parameter (rather than the "cost-type" parameter defined in 313 the base protocol), the Server realizes that the ALTO Client also 314 supports the extensions in this document, and hence responds with a 315 Multi Cost Map, with the costs in the order listed in "multi-cost- 316 types". 318 3.4. Endpoint Cost Service Resources 320 Section {4.1.4} of [RFC7285] specifies that "The Endpoint Cost 321 Service allows an ALTO Server to return costs directly amongst 322 endpoints.", whereas the Filtered Cost Map Service returns costs 323 amongst PIDs. This document uses the technique described in 324 Section 3.3 to extend the Endpoint Cost Service to return array- 325 valued costs to ALTO Clients who also are aware of these extensions. 327 3.5. Full Cost Map Resources 329 Section {11.3.2.3} of [RFC7285] requires a Filtered Cost Map to 330 return the entire Cost Map if the ALTO Client omits the source and 331 destination PIDs. Hence a Multi-Cost aware ALTO Client can use an 332 extended Filtered Cost Map resource to get a full Multi Cost Map. 334 Full Cost Map resources are GET-mode requests, with no capabilities 335 other than the name of the cost type they return. Therefore unless 336 we create a new media type for array-valued Cost Maps, it is not 337 possible to define a Multi-Cost Full Cost Map resource so that multi- 338 cost-aware ALTO Clients can recognize it and legacy ALTO Clients will 339 ignore it. Indeed, the response for a Full Cost Map conveying 340 multiple cost types would include a "meta" field that would itself 341 include a "cost-type" field, that would list several values 342 corresponding to the cost types of the cost map. A legacy ALTO 343 Client would not be able to understand this list. It would not know 344 what the cost type of the map is and neither would it be able to 345 interpret the cost values array provided by a Multi-Cost full maps. 347 3.6. Extended Constraint Tests 349 [RFC7285] defines a simple constraint test capability for Filtered 350 Cost Maps and Endpoint Cost Services. If a resource supports 351 constraints, the Server restricts the response to costs that satisfy 352 a list of simple predicates provided by the ALTO Client. For 353 example, if the ALTO Client gives the constraints 355 "constraints": ["ge 10", "le 20"] 357 Then the Server only returns costs in the range [10,20]. 359 To be useful with multi-cost requests, the constraint tests require 360 several extensions. 362 3.6.1. Extended constraint predicates 364 First, because a multi-cost request involves more than one cost 365 metric, the simple predicates must be extended to specify the metric 366 to test. Therefore we extend the predicate syntax to "[##] op 367 value", where "##" is the index of a cost metric in this multi-cost 368 request. 370 3.6.2. Extended logical combination of predicates 372 Second, once multiple cost metrics are involved, the "AND" of simple 373 predicates is no longer sufficient. To be useful, Clients must be 374 able to express "OR" tests. Hence we add a new field, "or- 375 constraints", to the Client request. The value is an array of arrays 376 of simple predicates, and represents the OR of ANDs of those 377 predicates. 379 Thus, the following request tells the Server to limit its response to 380 cost points with "routingcost" <= 100 AND "hopcount" <= 2, OR else 381 "routingcost" <= 10 AND "hopcount" <= 6: 383 { 384 "multi-cost-types": [ 385 {"cost-metric": "routingcost", "cost-mode": "numerical"}, 386 {"cost-metric": "hopcount", "cost-mode": "numerical"} 387 ], 388 "or-constraints": [ 389 ["[0] le 100", "[1] le 2"], 390 ["[0] le 10", "[1] le 6"] 391 ], 392 "pids": {...} 393 } 395 3.6.3. Testable Cost Types in constraints 397 Finally, a Client may want to test a cost type whose actual value is 398 irrelevant, as long as it satisfies the tests. For example, a Client 399 may want the value of the cost metric "routingcost" for all PID pairs 400 that satisfy constraints on the metric "hopcount", without needing 401 the actual value of "hopcount". 403 For example, the following request tells the Server to return just 404 "routingcost" for those source and destination pairs for which 405 "hopcount" is <= 6: 407 { 408 "multi-cost-types": [ 409 {"cost-metric": "routingcost", "cost-mode": "numerical"}, 410 ], 411 "testable-cost-types": [ 412 {"cost-metric": "hopcount", "cost-mode": "numerical"}, 413 ], 414 "constraints": ["[0] le 6"], 415 "pids": {...} 416 } 418 In this example, "[0]" means the constraint applies to "hopcount" 419 because that is the first cost type in the "testable-cost-types" 420 parameter. (If "testable-cost-types" is omitted, it is assumed to be 421 the same as "multi-cost-types".) 423 The choice of using an index to refer to cost-types aims at 424 minimizing the length of the expression of constraints, especially 425 for those combining several OR and AND expressions. It was also the 426 shortest path from the constraints design in RFC 7285. 428 3.6.4. Testable Cost Type Names in IRD capabilities 430 In [RFC7285], when a resource's capability "constraints" is true, the 431 Server accepts constraints on all the cost types listed in the "cost- 432 type-names" capability. However, some ALTO Servers may not be 433 willing to allow constraint tests on all available cost metrics. 434 Therefore the Multi-Cost ALTO protocol extension defines the 435 capability field "testable-cost-type-names". Like "cost-type-names", 436 it is an array of cost type names. If present, that resource only 437 allows constraint tests on the cost types in that list. "testable- 438 cost-type-names" must be a subset of "cost-type-names". 440 3.6.5. Legacy ALTO Client issues 442 While a multi-cost-aware Client will recognize the "testable-cost- 443 type-names" field, and will honor those restrictions, a legacy Client 444 will not. Hence a legacy may send a request with a constraint test 445 on any of the cost types listed in "cost-type-names". 447 To avoid that problem, the "testable-cost-type-names" and "cost- 448 constraints" fields are mutually exclusive: a resource may define one 449 or the other capability, but must not define both. Thus a resource 450 that does not allow constraint tests on all cost metrics will set 451 "testable-cost-type-names" to the testable metrics, and will set 452 "cost-constraints" to "false". A multi-cost-aware Client will 453 recognize the "testable-cost-type-names" field, and will realize that 454 its existence means the resource does allow (limited) constraint 455 tests, while a legacy Client will think that resource does not allow 456 constraint tests at all. To allow legacy Clients to use constraint 457 tests, the ALTO Server may define an additional resource with "cost- 458 constraints" set to "true" and "cost-type-names" set to the metrics 459 which can be tested. 461 In the IRD example below, the resource "filtered-cost-map-extended" 462 provides values for three metrics: "num-routingcost", "num-hopcount" 463 and "num-bwscore". The capability "testable-cost-type-names" 464 indicates that the Server only allows constraints on "routingcost" 465 and "hopcount". A multi-cost capable Client will see this 466 capability, and will limit its constraint tests to those metrics. 467 Because capability "cost-constraints" is false (by default), a legacy 468 Client will not use constraint tests on this resource at all. 470 The second resource, "filtered-multicost-map", is similar to the 471 first, except that all the metrics it returns are testable. 472 Therefore it sets "cost-constraints" to "true", and does not set the 473 "testable-cost-type-names" field. A legacy Client that needs a 474 constraint test will use this resource rather than the first. A 475 multi-cost-aware Client that does not need to retrieve the "num- 476 bwscore" metric may use either resource. 478 "filtered-cost-map-extended" : { 479 "uri" : "http://alto.example.com/multi/extn/costmap/filtered", 480 "media-types" : [ "application/alto-costmap+json" ], 481 "accepts" : [ "application/alto-costmapfilter+json" ], 482 "uses" : [ "my-default-network-map" ], 483 "capabilities" : { 484 "max-cost-types" : 3, 485 "cost-type-names" : [ "num-routingcost", 486 "num-hopcount", 487 "num-bwscore"], 488 "testable-cost-type-names" : [ "num-routingcost", 489 "num-hopcount" ] 490 } 491 }, 493 "filtered-multicost-map" : { 494 "uri" : "http://alto.example.com/multi/costmap/filtered", 495 "media-types" : [ "application/alto-costmap+json" ], 496 "accepts" : [ "application/alto-costmapfilter+json" ], 497 "uses" : [ "my-default-network-map" ], 498 "capabilities" : { 499 "cost-constraints" : true, 500 "max-cost-types" : 2, 501 "cost-type-names" : [ "num-routingcost", 502 "num-hopcount"], 503 } 504 } 506 4. Protocol Extensions for Multi-Cost ALTO Transactions 508 This section formally specifies the extensions to [RFC7285] to 509 support Multi-Cost ALTO transactions. 511 4.1. Filtered Cost Map Extensions 513 This document extends Filtered Cost Maps, as defined in {11.3.2} of 514 [RFC7285], by adding new input parameters and capabilities, and by 515 returning JSONArrays instead of JSONNumbers as the cost values. 517 The media type (11.3.2.1}, HTTP method (11.3.2.2} and "uses" 518 specifications (11.3.2.5} are unchanged. 520 4.1.1. Capabilities 522 The filtered cost map capabilities are extended with two new members: 524 o max-cost-types, 526 o testable-cost-type-names 528 The capability "max-cost-types" indicates whether this resource 529 supports the Multi-Cost ALTO extensions, and the capability 530 "testable-cost-type-names" allows the resource to restrict constraint 531 tests to a subset of the available cost types. The 532 FilteredCostMapCapabilities object in {11.3.2.4} is extended as 533 follows: 535 object { 536 JSONString cost-type-names<1..*>; 537 [JSONBool cost-constraints;] 538 [JSONNumber max-cost-types;] 539 [JSONString testable-cost-type-names<1..*>;] 540 } FilteredCostMapCapabilities; 542 cost-type-names and cost-constraints: As defined in {11.3.2.4} of 543 [RFC7285]. 545 max-cost-types: If present with value N greater than 0, this 546 resource understands the multi-cost extensions in this document, 547 and can return a Multi Cost Map with any combination of N or fewer 548 cost types in the "cost-type-names" list. If omitted, the default 549 value is 0. 551 testable-cost-type-names: If present, the resource allows constraint 552 tests, but only on the cost type names in this array. Each name 553 in "testable-cost-type-names" MUST also be in "cost-type-names". 554 If "testable-cost-type-names" is present, the "cost-constraints" 555 capability MUST NOT be "true", and if "cost-constraints" is 556 "true", "testable-cost-type-names" MUST NOT be present. Thus if 557 "cost-constraints" is "true", the resource MUST accept constraint 558 tests on any cost type in "cost-type-names". 560 As discussed in Section 3.6.4, this capability is useful when a 561 Server is unable or unwilling to implement constraint tests on all 562 cost types. As discussed in Section 3.6.5, "testable-cost-type- 563 names" and "cost-constraints" are mutually exclusive to prevent 564 legacy Clients from issuing constraint tests on untestable cost 565 types. 567 4.1.2. Accept Input Parameters 569 The ReqFilteredCostMap object in {11.3.2.3} of [RFC7285] is extended 570 as follows: 572 object { 573 [CostType cost-type;] 574 [CostType multi-cost-types<1..*>;] 575 [CostType testable-cost-types<1..*>;] 576 [JSONString constraints<0..*>;] 577 [JSONString or-constraints<1..*><1..*>;] 578 PIDFilter pids; 579 } ReqFilteredCostMap; 581 object { 582 PIDName srcs<0..*>; 583 PIDName dsts<0..*>; 584 } PIDFilter; 586 cost-type: As defined in {11.3.2.3} of [RFC7285], with the 587 additional requirement that the Client MUST specify either "cost- 588 type" or "multi-cost-types", but MUST NOT specify both. 590 multi-cost-types: If present, the ALTO Server MUST return array- 591 valued costs for the cost types in this list. For each entry, the 592 "cost-metric" and "cost-mode" fields MUST match one of the 593 supported cost types indicated in member "cost-type-names" of this 594 resource's "capabilities" field (Section 4.1.1). The Client MUST 595 NOT use this field unless this resource's "max-cost-types" 596 capability exists and has a value greater than 0. This field MUST 597 NOT have more than "max-cost-types" cost types. The Client MUST 598 specify either "cost-type" or "multi-cost-types", but MUST NOT 599 specify both. 601 Note that if "multi-cost-types" has one cost type, the values in 602 the cost map will be arrays with one value. 604 testable-cost-types: A list of cost types used for extended 605 constraint tests, as described for the "constraints" and "or- 606 constraints" parameters. These cost types must either be a subset 607 of the cost types in the resource's "testable-cost-type-names" 608 capability (Section 4.1.1), or else, if the resource's capability 609 "cost-constraints" is true, a subset of the cost types in the 610 resource's "cost-type-names" capability. 612 If "testable-cost-types" is omitted, it is assumed to have the 613 cost types in "multi-cost-types" or "cost-type". 615 This feature is useful when a Client wants to test a cost type 616 whose actual value is irrelevant, as long as it satisfies the 617 tests. For example, a Client may want the cost metric 618 "routingcost" for those PID pairs whose "hopcount" is less than 619 10. The exact hopcount does not matter. 621 constraints: If this resource's "max-cost-types" capability 622 (Section 4.1.1) has the value 0 (or is not defined), this 623 parameter is as defined in {11.3.2.3} of [RFC7285]: an array of 624 constraint tests related to each other by a logical AND. In this 625 case it MUST NOT be specified unless the resource's "cost- 626 constraints" capability is "true". 628 If this resource's "max-cost-types" capability has a value greater 629 than 0, then this parameter is an array of extended constraint 630 predicates as defined below and related to each other by a logical 631 AND. In this case, it MAY be specified if the resource allows 632 constraint tests (the resource's "cost-constraints" capability is 633 "true" or its "testable-cost-type-names" capability is not empty). 635 This parameter MUST NOT be specified if the "or-constraints" 636 parameter is specified. 638 An extended constraint predicate consists of two or three entities 639 separated by white space: (1) an optional cost type index, of the 640 form "[#]", with default value "[0]", (2) a required operator, and 641 (3) a required target value. The operator and target value are as 642 defined in {11.3.2.3} of [RFC7285]. The cost type index, i, 643 specifies the cost type to test. If the "testable-cost-type" 644 parameter is present, the test applies to the i'th cost type in 645 "testable-cost-types", starting with index 0. Otherwise if the 646 "multi-cost-types" parameter is present, the test applies to the 647 i'th cost type in that array. If neither parameters are present, 648 the test applies to the cost type in the "cost-type" parameter, in 649 which case the index MUST be 0. Regardless of how the tested cost 650 type is selected, it MUST be in the resource's "testable-cost- 651 type-names" capability, or, if not present, in the "cost-type- 652 names" capability. 654 As an example, suppose "multi-cost-types" has the single element 655 "routingcost", "testable-cost-types" has the single element 656 "hopcount", and "constraints" has the single element "[0] le 5". 657 This is equivalent to the database query "SELECT and provide 658 routingcost WHERE hopcount <= 5". 660 Note that the index is optional, so a constraint test as defined 661 in {11.3.2.3}, such as "le 10", is equivalent to "[0] le 10". 663 Thus legacy constraint tests are also legal extended constraint 664 tests. 666 Note that a "constraints" parameter with the array of extended 667 predicates [P1, P2, ...] is equivalent to an "or-constraints" 668 parameter as defined below, with the value [[P1, P2, ...]]. 670 or-constraints: A JSONArray of JSONArrays of JSONStrings, where each 671 string is an extended constraint predicate as defined above. The 672 "or-constraint" tests are interpreted as the logical OR of ANDs of 673 predicates. That is, the ALTO Server should return a cost point 674 only if it satisfies all constraints in any one of the sub-arrays. 676 This parameter MAY be specified if this resource's "max-cost- 677 types" capability is defined with a value greater than 0 678 (Section 4.1.1), and if the resource allows constraint tests (the 679 resource's "cost-constraints" capability is "true" or its 680 "testable-cost-type-names" capability is not empty). Otherwise 681 this parameter MUST NOT be specified. 683 This parameter MUST NOT be specified if the "constraints" 684 parameter is specified. 686 This parameter MUST NOT contain any empty array of AND predicates. 687 An empty array would be equivalent to a constraint that is always 688 "true". An OR combination including such a constraint would be 689 always "true" and thus useless. 691 As an example, suppose "multi-cost-types" has the two elements 692 "routingcost" and "bandwidthscore", and "testable-cost-types" has 693 the two elements "routingcost" and "hopcount", and "or- 694 constraints" has the two elements ["[0] le 100", "[1] le 2"] and 695 ["[0] le 10", "[1] le 6"]. This is equivalent to the database 696 query: "SELECT and provide routingcost and bandwidthscore WHERE 697 ("routingcost" <= 100 AND "hopcount" <= 2) OR ("routingcost" <= 10 698 AND "hopcount" <= 6)". 700 Note that if the "max-cost-types" capability has a value greater 701 than 0, a Client MAY use the "or-constraints" parameter together 702 with the "cost-type" parameter. That is, if the Client and Server 703 are both aware of the extensions in this document, a Client MAY 704 use an "OR" test for a single-valued cost request. 706 pids, srcs, dsts: As defined in {11.3.2.3} of [RFC7285]. 708 4.1.3. Response 710 If the Client specifies the "cost-type" input parameter, the response 711 is exactly as defined in {11.2.3.6} of [RFC7285]. If the Client 712 provides the "multi-cost-types" instead, then the response is changed 713 as follows: 715 o In "meta", the value of field "cost-type" will be ignored by the 716 receiver and set to {}. Instead, the field "multi-cost-types" is 717 added with the same value as the "multi-cost-types" input 718 parameter. 720 o The costs are JSONArrays, instead of JSONNumbers. All arrays have 721 the same cardinality as the "multi-cost-types" input parameter, 722 and contain the cost type values in that order. If a cost type is 723 not available for a particular source and destination, the ALTO 724 Server MUST use the JSON "null" value for that array element. If 725 none of the cost types are available for a particular source and 726 destination, the ALTO Server MAY omit the entry for that source 727 and destination. 729 4.2. Endpoint Cost Service Extensions 731 This document extends the Endpoint Cost Service, as defined in 732 {11.5.1} of [RFC7285], by adding new input parameters and 733 capabilities, and by returning JSONArrays instead of JSONNumbers as 734 the cost values. 736 The media type (11.5.1.1}, HTTP method (11.5.1.2} and "uses" 737 specifications (11.5.1.5} are unchanged. 739 4.2.1. Capabilities 741 The extensions to the Endpoint Cost Service capabilities are 742 identical to the extensions to the Filtered Cost Map (see 743 Section 4.1.1). 745 4.2.2. Accept Input Parameters 747 The ReqEndpointCostMap object in {11.5.1.3} of [RFC7285] is extended 748 as follows: 750 object { 751 [CostType cost-type;] 752 [CostType multi-cost-types<1..*>;] 753 [CostType testable-cost-types<1..*>;] 754 [JSONString constraints<0..*>;] 755 [JSONString or-constraints<1..*><1..*>;] 756 EndpointFilter endpoints; 757 } ReqFilteredCostMap; 759 object { 760 [TypedEndpointAddr srcs<0..*>;] 761 [TypedEndpointAddr dsts<0..*>;] 762 } EndpointFilter; 764 cost-type: As defined in {11.5.1.3} of [RFC7285], with the 765 additional requirement that the Client MUST specify either "cost- 766 type" or "multi-cost-types", but MUST NOT specify both. 768 multi-cost-types: If present, the ALTO Server MUST return array- 769 valued costs for the cost types in this list. For each entry, the 770 "cost-metric" and "cost-mode" fields MUST match one of the 771 supported cost types indicated in this resource's "capabilities" 772 field (Section 4.2.1). The Client MUST NOT use this field unless 773 this resource's "max-cost-types" capability exists and has a value 774 greater than 0. This field MUST NOT have more than "max-cost- 775 types" cost types. The Client MUST specify either "cost-type" or 776 "multi-cost-types", but MUST NOT specify both. 778 Note that if "multi-cost-types" has one cost type, the values in 779 the cost map will be arrays with one value. 781 testable-cost-types, constraints, or-constraints: Defined 782 equivalently to the corresponding input parameters for an extended 783 Filtered Cost Map (Section 4.1.2). 785 endpoints, srcs, dsts: As defined in {11.5.1.3} of [RFC7285]. 787 4.2.3. Response 789 The extensions to the Endpoint Cost Service response are similar to 790 the extensions to the Filtered Cost Map response (Section 4.1.3). 791 Specifically, if the Client specifies the "cost-type" input 792 parameter, the response is exactly as defined in {11.5.1.6} of 793 [RFC7285]. If the Client provides the "multi-cost-types" instead, 794 then the response is changed as follows: 796 o In "meta", the field "cost-type" is provided with a dummy value. 797 Instead, the field "multi-cost-types" is added with the same value 798 as the "multi-cost-types" input parameter. 800 o The costs are JSONArrays, instead of JSONNumbers. All arrays have 801 the same cardinality as the "multi-cost-types" input parameter, 802 and contain the cost type values in that order. If a cost type is 803 not available for a particular source and destination, the ALTO 804 Server MUST use the JSON "null" value for that array element. If 805 none of the cost types are available for a particular source and 806 destination, the ALTO Server MAY omit the entry for that source 807 and destination. 809 5. Examples 811 The examples exposed in this section use cost metrics such as 812 'hopcount', and 'bandwidthscore' that are not registered at the IANA. 813 These metrics are only here for illustrative purposes and reflect 814 widely valued information by applications. 816 5.1. Information Resource Directory 818 The following is an example of an ALTO Server's Information Resource 819 Directory. In addition to Network and Cost Map resources, it defines 820 two Filtered Cost Map and an Endpoint Cost Service, which all 821 understand the multi-cost extensions. 823 GET /directory HTTP/1.1 824 Host: alto.example.com 825 Accept: application/alto-directory+json,application/alto-error+json 827 HTTP/1.1 200 OK 828 Content-Length: [TODO] 829 Content-Type: application/alto-directory+json 831 { 832 "meta" : { 833 "default-alto-network-map" : "my-default-network-map", 834 "cost-types" : { 835 "num-routing" : { 836 "cost-mode" : "numerical", 837 "cost-metric" : "routingcost" 838 }, 839 "num-hopcount" : { 840 "cost-mode" : "numerical", 841 "cost-metric" : "hopcount" 842 }, 843 "num-bwscore" : { 844 "cost-mode" : "numerical", 845 "cost-metric" : "bandwidthscore" 846 }, 847 ..... 848 Other ALTO cost types as described in RFC7285 849 ..... 850 } 851 }, 852 "resources" : { 853 "my-default-network-map" : { 854 "uri" : "http://alto.example.com/networkmap", 855 "media-type" : "application/alto-networkmap+json" 856 }, 857 "numerical-routing-cost-map" : { 858 "uri" : "http://alto.example.com/costmap/num-routing", 859 "media-types" : [ "application/alto-costmap+json" ], 860 "uses" : [ "my-default-network-map" ], 861 "capabilities" : { 862 "cost-type-names" : [ "num-routing" ] 863 } 864 }, 865 "numerical-hopcount-cost-map" : { 866 "uri" : "http://alto.example.com/costmap/num-hopcount", 867 "media-types" : [ "application/alto-costmap+json" ], 868 "uses" : [ "my-default-network-map" ], 869 "capabilities" : { 870 "cost-type-names" : [ "num-hopcount" ] 871 } 872 }, 873 ......... 874 Other resources as described in RFC7285 875 ......... 876 "filtered-multicost-map" : { 877 "uri" : "http://alto.example.com/multi/costmap/filtered", 878 "media-types" : [ "application/alto-costmap+json" ], 879 "accepts" : [ "application/alto-costmapfilter+json" ], 880 "uses" : [ "my-default-network-map" ], 881 "capabilities" : { 882 "cost-constraints" : true, 883 "max-cost-types" : 2, 884 "cost-type-names" : [ "num-routingcost", 885 "num-hopcount" ] 886 } 887 }, 888 "filtered-cost-map-extended" : { 889 "uri" : "http://alto.example.com/multi/extn/costmap/filtered", 890 "media-types" : [ "application/alto-costmap+json" ], 891 "accepts" : [ "application/alto-costmapfilter+json" ], 892 "uses" : [ "my-default-network-map" ], 893 "capabilities" : { 894 "max-cost-types" : 3, 895 "cost-type-names" : [ "num-routingcost", 896 "num-hopcount", 897 "num-bwscore"], 898 "testable-cost-type-names" : [ "num-routingcost", 899 "num-hopcount" ] 900 } 901 }, 902 "endpoint-multicost-map" : { 903 "uri" : "http://alto.example.com/multi/endpointcost/lookup", 904 "media-types" : [ "application/alto-endpointcost+json" ], 905 "accepts" : [ "application/alto-endpointcostparams+json" ], 906 "uses" : [ "my-default-network-map" ], 907 "capabilities" : { 908 "cost-constraints" : true, 909 "max-cost-types" : 2, 910 "cost-type-names" : [ "num-routingcost", 911 "num-hopcount" ] 912 } 913 } 914 } 915 } 917 5.2. Multi-Cost Filtered Cost Map: Example #1 919 This example illustrates a simple multi-cost ALTO transaction. The 920 ALTO Server provides two Cost Types, "routingcost" and "hopcount", 921 both in "numerical" mode. The ALTO Server does not know the value of 922 the "routingcost" between PID2 and PID3, and hence uses "null" for 923 those costs. 925 POST /multi/costmap/filtered" HTTP/1.1 926 Host: alto.example.com 927 Accept: application/alto-costmap+json,application/alto-error+json 928 Content-Type: application/alto-costmapfilter+json 929 Content-Length: ### 931 { 932 "multi-cost-types": [ 933 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 934 {"cost-mode": "numerical", "cost-metric": "hopcount"} 935 ], 936 "pids" : { 937 "srcs" : [ ], 938 "dsts" : [ ] 939 } 940 } 942 HTTP/1.1 200 OK 943 Content-Type: application/alto-costmap+json 944 Content-Length: ### 946 { 947 "meta" : { 948 "dependent-vtags" : [ 949 {"resource-id": "my-default-network-map", 950 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 951 } 952 ], 953 "cost-type" : {}, 954 "multi-cost-types" : [ 955 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 956 {"cost-mode": "numerical", "cost-metric": "hopcount"} 957 ] 958 } 959 } 960 "cost-map" : { 961 "PID1": { "PID1":[1,0], "PID2":[4,3], "PID3":[10,2] }, 962 "PID2": { "PID1":[15,5], "PID2":[1,0], "PID3":[null,9] }, 963 "PID3": { "PID1":[20,12], "PID2":[null,1], "PID3":[1,0] } 964 } 965 } 967 5.3. Multi-Cost Filtered Cost Map: Example #2 969 This example uses constraints to restrict the returned source/ 970 destination PID pairs to those with "routingcost" between 5 and 10, 971 or "hopcount" equal to 0. 973 POST /multi/costmap/filtered HTTP/1.1 974 Host: alto.example.com 975 Accept: application/alto-costmap+json,application/alto-error+json 976 Content-Type: application/alto-costmapfilter+json 977 Content-Length: ### 979 { 980 "multi-cost-types" : [ 981 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 982 {"cost-mode": "numerical", "cost-metric": "hopcount"} 983 ], 984 "or-constraints" : [ ["[0] ge 5", "[0] le 10"], 985 ["[1] eq 0"] ] 986 "pids" : { 987 "srcs" : [ "PID1", "PID2" ], 988 "dsts" : [ "PID1", "PID2", "PID3" ] 989 } 990 } 991 HTTP/1.1 200 OK 992 Content-Type: application/alto-costmap+json 993 Content-Length: ### 995 { 996 "meta" : { 997 "dependent-vtags" : [ 998 {"resource-id": "my-default-network-map", 999 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1000 } 1001 ], 1002 "cost-type" : {}, 1003 "multi-cost-types" : [ 1004 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1005 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1006 ] 1007 } 1008 "cost-map" : { 1009 "PID1": { "PID1": [1,0], "PID3": [10,5] }, 1010 "PID2": { "PID2": [1,0] } 1011 } 1012 } 1014 5.4. Multi-Cost Filtered Cost Map: Example #3 1016 This example uses extended constraints to limit the response to cost 1017 points with ("routingcost" <= 10 and "hopcount" <= 2), or else 1018 ("routingcost" <= 3 and "hopcount" <= 6). Unlike the previous 1019 example, the Client is only interested in the "routingcost" cost 1020 type, and uses the "cost-type" parameter instead of "multi-cost- 1021 types" to tell the Server to return scalar costs instead of array 1022 costs: 1024 POST /multi/multicostmap/filtered HTTP/1.1 1025 Host: alto.example.com 1026 Accept: application/alto-costmap+json,application/alto-error+json 1027 Content-Type: application/alto-costmapfilter+json 1028 Content-Length: ### 1030 { 1031 "cost-type" : { 1032 "cost-mode": "numerical", "cost-metric": "routingcost" 1033 }, 1034 "testable-cost-types" : [ 1035 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1036 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1037 ], 1038 "or-constraints": [ 1039 ["[0] le 10", "[1] le 2"], 1040 ["[0] le 3", "[1] le 6"] 1041 ], 1042 "pids" : { 1043 "srcs" : [ ], 1044 "dsts" : [ ] 1045 } 1046 } 1048 HTTP/1.1 200 OK 1049 Content-Type: application/alto-costmap+json 1050 Content-Length: ### 1052 { 1053 "meta" : { 1054 "dependent-vtags" : [ 1055 {"resource-id": "my-default-network-map", 1056 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1057 } 1058 ], 1059 "cost-type" : { 1060 "cost-mode": "numerical", "cost-metric": "routingcost" 1061 } 1062 } 1063 "cost-map" : { 1064 "PID1": { "PID1": 1, "PID3": 10 }, 1065 "PID2": { "PID2": 1 }, 1066 "PID3": { "PID3": 1 } 1067 } 1068 } 1070 5.5. Multi-Cost Filtered Cost Map: Example #4 1072 This example uses extended constraints to limit the response to cost 1073 points with ("routingcost" <= 10 and "hopcount" <= 2), or else 1074 ("routingcost" <= 3 and "hopcount" <= 6). In this example, the 1075 Client is interested in the "routingcost" and "bandwidthscore" cost 1076 metrics, but not in the "hopcount" metric: 1078 POST /multi/extn/costmap/filtered HTTP/1.1 1079 Host: alto.example.com 1080 Accept: application/alto-costmap+json,application/alto-error+json 1081 Content-Type: application/alto-costmapfilter+json 1082 Content-Length: ### 1084 { 1085 "multi-cost-types" : [ 1086 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1087 {"cost-mode": "numerical", "cost-metric": "bandwidthscore"} 1088 ], 1089 "testable-cost-types" : [ 1090 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1091 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1092 ], 1093 "or-constraints": [ 1094 ["[0] le 10", "[1] le 2"], 1095 ["[0] le 3", "[1] le 6"] 1096 ], 1097 "pids" : { 1098 "srcs" : [ ], 1099 "dsts" : [ ] 1100 } 1101 } 1102 HTTP/1.1 200 OK 1103 Content-Type: application/alto-costmap+json 1104 Content-Length: ### 1106 { 1107 "meta" : { 1108 "dependent-vtags" : [ 1109 {"resource-id": "my-default-network-map", 1110 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e" 1111 } 1112 ], 1113 "cost-type" : {}, 1114 "multi-cost-types" : [ 1115 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1116 {"cost-mode": "numerical", "cost-metric": "bandwidthscore"} 1117 ] 1118 } 1119 "cost-map" : { 1120 "PID1": { "PID1": [1,16] "PID3": [10,19] }, 1121 "PID2": { "PID2": [1,8] }, 1122 "PID3": { "PID3": [1,19] } 1123 } 1124 } 1126 5.6. Endpoint Cost Service 1128 This example uses the Endpoint Cost Service to retrieve the 1129 "routingcost" and "hopcount" for selected endpoints, limiting the 1130 response to costs with either low hopcount and reasonable routingcost 1131 (hopcount <= 2 and routingcost <= 10), or else low routingcost and 1132 reasonable hopcount (routingcost <= 3 and hopcount <= 6). 1134 POST /multi/endpointcost/lookup HTTP/1.1 1135 Host: alto.example.com 1136 Accept: application/alto-endpointcost+json, 1137 application/alto-error+json 1138 Content-Type: application/alto-endpoincostparams+json 1139 Content-Length: ### 1141 { 1142 "multi-cost-types" : [ 1143 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1144 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1145 ], 1146 "or-constraints": [ 1147 ["[0] le 10", "[1] le 2"], 1148 ["[0] le 3", "[1] le 6"] 1149 ], 1150 "endpoints" : { 1151 "srcs": [ "ipv4:192.0.2.2", "ipv6:2001:db8::1:0 ], 1152 "dsts": [ 1153 "ipv4:192.0.2.89", 1154 "ipv4:198.51.100.34", 1155 "ipv4:203.0.113.45", 1156 "ipv6:2001:db8::10" 1157 ] 1158 } 1159 } 1161 HTTP/1.1 200 OK 1162 Content-Length: ### 1163 Content-Type: application/alto-endpointcost+json 1165 { 1166 "meta" : { 1167 "multi-cost-types" : [ 1168 {"cost-mode": "numerical", "cost-metric": "routingcost"}, 1169 {"cost-mode": "numerical", "cost-metric": "hopcount"} 1170 ] 1171 } 1172 "endpoint-cost-map" : { 1173 "ipv4:192.0.2.2": { 1174 "ipv4:192.0.2.89": [15, 5], 1175 "ipv4:203.0.113.45": [4, 23] 1176 } 1177 "ipv6:2001:db8::1:0": { 1178 "ipv4:198.51.100.34": [16, 5], 1179 "ipv6:2001:db8::10": [10, 2] 1180 } 1181 } 1182 } 1184 6. IANA Considerations 1186 This document does not define any new media types or introduce any 1187 new IANA considerations. 1189 7. Privacy And Security Considerations 1191 This document does not introduce any privacy or security issues not 1192 already present in the ALTO protocol. 1194 8. Acknowledgements 1196 The authors would like to thank Richard Alimi, Fred Baker, Dhruv 1197 Dhodi, Vijay Gurbani, Dave Mac Dysan, Young Lee, Richard Yang, for 1198 fruitful discussions and feedback on this document and previous 1199 versions. Gao Kai, Hans Seidel, Richard Yang, Qiao Xiang and Wang 1200 Xin provided substantial review feedback and suggestions to the 1201 protocol design. 1203 9. References 1205 9.1. Normative References 1207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1208 Requirement Levels", BCP 14, RFC 2119, 1209 DOI 10.17487/RFC2119, March 1997, 1210 . 1212 [RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 1213 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 1214 Traffic Optimization (ALTO) Protocol", RFC 7285, September 1215 2014. 1217 9.2. Informative References 1219 [RFC5693] "Application Layer Traffic Optimization (ALTO) Problem 1220 Statement", October 2009. 1222 [RFC6708] "Application-Layer Traffic Optimization (ALTO) 1223 Requirements", February 2012. 1225 Authors' Addresses 1227 Sabine Randriamasy 1228 Nokia Bell Labs 1229 Route de Villejust 1230 NOZAY 91460 1231 FRANCE 1233 Email: Sabine.Randriamasy@nokia-bell-labs.com 1234 Wendy Roome 1235 Nokia Bell Labs 1236 124 Burlington Rd 1237 Murray Hill, NJ 07974 1238 USA 1240 Email: ietf@wdroome.com 1242 Nico Schwan 1243 Thales Deutschland 1244 Lorenzstrasse 10 1245 Stuttgart 70435 1246 Germany 1248 Email: nico.schwan@thalesgroup.com