idnits 2.17.1 draft-ietf-alto-path-vector-03.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 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 5, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 845, but not defined == Unused Reference: 'I-D.amante-i2rs-topology-use-cases' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-cost-calendar' is defined on line 1057, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-alto-cost-calendar-01 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-08 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG G. Bernstein 3 Internet-Draft Grotto Networking 4 Intended status: Standards Track S. Chen 5 Expires: September 6, 2018 Tongji University 6 K. Gao 7 Tsinghua University 8 Y. Lee 9 Huawei 10 W. Roome 11 M. Scharf 12 Nokia 13 Y. Yang 14 Yale University 15 J. Zhang 16 Tongji University 17 March 5, 2018 19 ALTO Extension: Path Vector Cost Type 20 draft-ietf-alto-path-vector-03.txt 22 Abstract 24 The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] 25 has defined several resources and services to provide clients with 26 basic network information. However, the base ALTO protocol and 27 latest extensions only provide end-to-end metrics, which are 28 insufficient to satisfy the demands of solving more complex network 29 optimization problems. This document introduces an extension to the 30 base ALTO protocol, namely the path-vector extension, which allows 31 ALTO clients to query information such as capacity regions for a 32 given set of flows. A non-normative example called multi-flow 33 scheduling is presented to illustrate the limitations of existing 34 ALTO (endpoint) cost maps. After that, details of the extension are 35 defined. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on September 6, 2018. 60 Copyright Notice 62 Copyright (c) 2018 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. Use Case: Capacity Region for Multi-Flow Scheduling . . . . . 5 80 4. Overview of Path Vector Extensions . . . . . . . . . . . . . 7 81 4.1. New Cost Type to Encode Path Vectors . . . . . . . . . . 7 82 4.2. New Entity Domain to Provide ANE Properties . . . . . . . 8 83 4.3. New Service to Enable Multipart Resources . . . . . . . . 8 84 5. Path Vector Extension: Basic Data Types . . . . . . . . . . . 9 85 5.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 9 86 5.1.1. Cost Mode: array . . . . . . . . . . . . . . . . . . 9 87 5.1.2. Cost Metric: ane-path . . . . . . . . . . . . . . . . 9 88 5.1.3. Path Vector Cost Type Semantics . . . . . . . . . . . 9 89 5.2. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 10 90 5.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 10 91 5.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 10 92 5.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 11 93 5.3. Abstract Network Element Name . . . . . . . . . . . . . . 11 94 6. Path Vector Extension: Services . . . . . . . . . . . . . . . 11 95 6.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11 96 6.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 11 97 6.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 12 98 6.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 12 99 6.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 12 100 6.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 12 101 6.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 12 102 6.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 13 103 6.3. Multipart Cost Property Service . . . . . . . . . . . . . 13 104 6.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 13 105 6.3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 13 106 6.3.3. Accept Input Parameters . . . . . . . . . . . . . . . 13 107 6.3.4. Capabilities . . . . . . . . . . . . . . . . . . . . 14 108 6.3.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 14 109 6.3.6. Response . . . . . . . . . . . . . . . . . . . . . . 14 110 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 111 7.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 15 112 7.2. Information Resource Directory Example . . . . . . . . . 15 113 7.3. Example # 1 . . . . . . . . . . . . . . . . . . . . . . . 17 114 7.4. Example # 2 . . . . . . . . . . . . . . . . . . . . . . . 18 115 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19 116 8.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 19 117 8.2. Compatibility with Multi-Cost Extensions . . . . . . . . 20 118 8.3. Compatibility with Incremental Update . . . . . . . . . . 20 119 9. Design Decisions and Discussions . . . . . . . . . . . . . . 20 120 9.1. Provide More General Calendar Extension . . . . . . . . . 20 121 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 122 10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 21 123 10.2. Resource Consumption on ALTO Servers . . . . . . . . . . 21 124 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 125 11.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 21 126 11.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . 22 127 11.3. ALTO Entity Domain Registry . . . . . . . . . . . . . . 22 128 11.4. ALTO Network Element Property Type Registry . . . . . . 22 129 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 131 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 132 13.2. Informative References . . . . . . . . . . . . . . . . . 23 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 135 1. Introduction 137 The base ALTO protocol [RFC7285] is designed to expose network 138 information through services such as Cost Map and Endpoint Cost 139 service. These services use an extreme "single-node" network view 140 abstraction, which represents the whole network with a single node 141 and hosts with "endpoint groups" directly connected to the node. 143 Although the "single-node" network view abstraction works well in 144 many settings, it lacks the ability to support emerging use cases, 145 such as inter-datacenter data transfers 146 [I-D.lee-alto-app-net-info-exchange]. For these use cases, 147 applications require a more powerful network view abstraction beyond 148 the "single-node" abstraction to support application capabilities, in 149 particular, the ability of multi-flow scheduling. 151 To support capabilities like multi-flow scheduling, 152 [I-D.yang-alto-topology] provides many candidate network view 153 abstractions. This document uses one of those abstractions called 154 "path vector" abstraction. The path vector abstraction use path 155 vectors with abstract network elements to provide network graph view 156 for applications. Here, abstract network elements can be links, 157 switches, middleboxes and their aggregations. And a path vector 158 presents a sequence of abstract network elements that end-to-end 159 traffic goes through. Each abstract network element can own several 160 properties like "bandwidth" and "delay". These information may help 161 the application avoid network congestion, achieving better 162 application performance. 164 Providing path vector abstraction using ALTO introduces the following 165 requirements: 167 o Encoding path vectors rather than scalar cost values in cost maps: 168 Cost maps allow only scalar (numerical or ordinal) cost values, 169 they cannot carry an array of abstract network elements as a cost. 170 A new cost type is required to encode path vectors as costs in 171 cost maps. 173 o Encoding the properties of abstract network elements: Unified 174 property map can provide properties of endpoints and pids, but it 175 cannot convey the properties of abstract network elements. A new 176 entity domain needs to be registered so that unified property map 177 can encode the properties of abstract network elements. 179 o Encapsulating multiple map messages in a single session: Making 180 multiple queries to get path vectors and the properties of 181 abstract network elements introduce additional communication 182 overhead. A mechanism to provide multiple map messages in a 183 single session is necessary. 185 This document proposes the path vector extension which satisfies 186 these additional requirements to the ALTO protocol. Specifically, it 187 encodes selected abstract network elements in an end-to-end path with 188 a new cost type called "path-vector", and conveys the properties of 189 abstract network elements using unified property map. 191 The rest of this document is organized as follows. Section 3 gives 192 an example of multi-flow scheduling and illustrates the limitations 193 of the base ALTO protocol in such a use case. Section 4 gives an 194 overview of the path vector extension. Section 5 and Section 6 195 define the formal extension. Section 7 presents several examples. 196 Section 8 and Section 9 discusses compatibility issues with other 197 existing ALTO extensions and design decisions. Section 10 and 198 Section 11 review the security and IANA considerations. 200 2. Terminology 202 Besides the terms defined in [RFC7285], [RFC8189] and 203 [I-D.ietf-alto-unified-props-new], this document also uses the 204 following additional terms: Abstract Network Element, Abstract 205 Network Element Name, Abstract Network Element Property, Abstract 206 Network Element Property Map, Path Vector and Path-Vector. 208 o Abstract Network Element (ANE): An abstract network element is an 209 abstraction of network components, it can be an aggregation of 210 links, middle boxes, virtualized network function (VNF), or even a 211 sub-network. An abstract network element has two attributes: a 212 name and a set of properties. 214 o Abstract Network Element Name (ANE Name): An abstract network 215 element name is an identifier that uniquely identifies an abstract 216 network element, as defined in Section 5.3. 218 o Abstract Network Element Property (ANE Property): An abstract 219 network element property is a network-related property of an 220 abstract network element. It can be "bandwidth" for links and 221 "delay" between two switches. 223 o Abstract Network Element Property Map (ANE Property Map): An 224 abstract network element property map is a Filtered Property Map 225 defined in [I-D.ietf-alto-unified-props-new] which supports the 226 "ane" domain in its "domain-types" capability. 228 o Path Vector: A path vector is an array of ALTO Abstract Network 229 Elements (ANEs). It presents an abstract network path between 230 entities such as PIDs or endpoints. An ANE represents a selected 231 part of an end-to-end path that the ALTO Server considers worth 232 exposing. 234 3. Use Case: Capacity Region for Multi-Flow Scheduling 236 Assume that an application has control over a set of flows, some 237 flows may go through shared links or switches and share a bottleneck. 238 Existing cost maps can not reveal such information. 240 Specifically, consider a network as shown in Figure 1. The network 241 has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches 242 sw1/sw3 provide access on one side, sw2/sw4 provide access on the 243 other side, and sw5-sw7 form the backbone. Endhosts eh1 to eh4 are 244 connected to access switches sw1 to sw4 respectively. Assume that 245 the bandwidth of link eh1 -> sw1 and link sw1 -> sw5 are 150 Mbps, 246 and the bandwidth of the rest links are 100 Mbps. 248 +------+ 249 | | 250 --+ sw6 +-- 251 / | | \ 252 PID1 +-----+ / +------+ \ +-----+ PID2 253 eh1__| |_ / \ ____| |__eh2 254 | sw1 | \ +--|---+ +---|--+ / | sw2 | 255 +-----+ \ | | | |/ +-----+ 256 \_| sw5 +---------+ sw7 | 257 PID3 +-----+ / | | | |\ +-----+ PID4 258 eh3__| |__/ +------+ +------+ \____| |__eh4 259 | sw3 | | sw4 | 260 +-----+ +-----+ 262 Figure 1: Raw Network Topology. 264 The single-node ALTO topology abstraction of the network is shown in 265 Figure 2. 267 +----------------------+ 268 {eh1} | | {eh2} 269 PID1 | | PID2 270 +------+ +------+ 271 | | 272 | | 273 {eh3} | | {eh4} 274 PID3 | | PID4 275 +------+ +------+ 276 | | 277 +----------------------+ 279 Figure 2: Base Single-Node Topology Abstraction. 281 Consider an application overlay (e.g., a large data analysis system) 282 which wants to schedule the traffic among a set of end host source- 283 destination pairs, say eh1 -> eh2 and eh1 -> eh4. The application 284 can request a cost map providing end-to-end available bandwidth, 285 using 'availbw' as cost-metric and 'numerical' as cost-mode. 287 The application will receive from ALTO server that the bandwidth of 288 eh1 -> eh2 and eh1 -> eh4 are both 100 Mbps. But this information is 289 not enough. Consider the following two cases: 291 o Case 1: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw6 -> 292 sw7 -> sw2 -> eh2 and eh1 -> eh4 uses path eh1 -> sw1 -> sw5 -> 293 sw7 -> sw4 -> eh4, then the application will obtain 150 Mbps. 295 o Case 2: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw7 -> 296 sw2 -> eh2 and eh1 -> eh4 uses the path eh1 -> sw1 -> sw5 -> sw7 297 -> sw4 -> eh4, then the application will obtain only 100 Mbps. 299 To allow applications to distinguish the two aforementioned cases, 300 the network needs to provide more details. In particular: 302 o The network needs to expose more detailed routing information to 303 show the shared bottlenecks. 305 o The network needs to provide the necessary abstraction to hide the 306 real topology information while providing enough information to 307 applications. 309 The path-vector extension defined in this document meets all the 310 requirements. 312 See [I-D.bernstein-alto-topo] for a survey of use-cases where 313 extended network topology information is needed. 315 4. Overview of Path Vector Extensions 317 This section presents an overview of approaches adopted by the path 318 vector extension. It assumes the readers are familiar with 319 (Filtered) Cost Map and Endpoint Cost Service defined in [RFC7285] 320 and their extensions defined in [RFC8189]. The path vector extension 321 also requires the support of Filtered Property Map defined in 322 [I-D.ietf-alto-unified-props-new]. 324 The path vector extension is composed of three building blocks: (1) a 325 new cost type to encode path vectors; (2) a new entity domain for 326 unified property extension [I-D.ietf-alto-unified-props-new] to 327 encode properties of abstract network elements; and (3) a new service 328 to provide path vector messages in a single session; 330 4.1. New Cost Type to Encode Path Vectors 332 Existing cost types defined in [RFC7285] only allow scalar cost 333 values, they cannot be used to convey vector format information. 334 This document defines a new cost mode to enable the cost value to 335 carry an array of elements, and a new cost metric to pass ANE names 336 as elements in the array. Detailed information and specifications 337 are given in Section 5.1.1 and Section 5.1.2. 339 4.2. New Entity Domain to Provide ANE Properties 341 Given the new cost type introduced by Section 4.1, Cost Map and 342 Endpoint Cost Service can provide the ANE names along a flow path. 343 However, only providing the ANE names without properties is not 344 enough. To detect shared bottlenecks, ALTO clients may expect 345 information on specific ANE properties such as link capacity or 346 delay. 348 This document adopts the property map defined in 349 [I-D.ietf-alto-unified-props-new] to encode the properties of 350 abstract network elements. A new domain "ane" is registered in the 351 property map. Each entity in the "ane" domain has an identifier of 352 an ANE. An ANE identifier is the ANE name used in the values of the 353 "ane-path" metric defined in the present draft. ANE properties are 354 provided in information resources called "Property Map Resource" and 355 "Filtered Property Map Resource". The "Filtered Property Map" 356 resource which supports the "ane" domain is used to encode the 357 properties of ane entities, and it is called an ANE Property Map in 358 this document. 360 4.3. New Service to Enable Multipart Resources 362 In the base ALTO protocol, ALTO servers use media types in the HTTP 363 header to indicate the type of the response. Typically one response 364 only contains a single media type, such as "application/alto- 365 costmap+json" or "application/alto-propmap+json". This has limited 366 the capability of ALTO servers to return multiple map messages in a 367 single response. 369 Thus, an ALTO client needs to make separate queries to get the 370 information of related services. This may cause a data 371 synchronization problem between dependent ALTO services because when 372 making the second query, the result for the first query may have 373 already changed. The same problem can happen to Network Map and Cost 374 Map resources. However, unlike Network Map and Cost Map which are 375 considered more stable, Path Vectors and the dependent ANE Property 376 Maps might change more frequently. 378 Instead of introducing a new media type to encapsulate multiple types 379 in a single response, this document adopts the "multipart/related" 380 media type defined in [RFC2387]. In this way, a response can contain 381 both the path vectors in a filtered cost map (or endpoint cost map) 382 and the associated ANE Property Map. The media types of the cost map 383 and the property map can still be retrieved from the response. The 384 interpretation of each media type in the "multipart/related" response 385 is consistent with the base ALTO protocol. 387 5. Path Vector Extension: Basic Data Types 389 This section formally specifies a new cost type and a new entity 390 domain. 392 5.1. Cost Type 394 This document extends the cost types defined in Section 6.1 of 395 [RFC7285] by introducing a new cost mode "array" and a new cost 396 metric "ane-path". In the rest content, this document use "path- 397 vector" to indicate the combination cost type of the cost mode 398 "array" and the cost metric "ane-path". 400 5.1.1. Cost Mode: array 402 This document extends the CostMode defined in Section 10.5 of 403 [RFC7285] with a new cost mode: "array". This cost mode indicates 404 that every cost value in a cost map represents an array rather than a 405 simple value. The values are arrays of JSONValue. The specific type 406 of each element in the array depends on the cost metric. 408 5.1.2. Cost Metric: ane-path 410 This document specifies a new cost metric: "ane-path". This cost 411 metric indicates that the cost value is a list of abstract network 412 elements which the path from a source to a destination goes across. 413 The values are arrays of ANE names which are defined in Section 5.3. 415 The cost metric "ane-path" SHOULD NOT be used when the cost mode is 416 not "array" unless it is explicitly specified by a future extension. 417 If an ALTO client send queries with the cost metric "ane-path" and a 418 non "array" cost mode, the ALTO server SHOULD return an error with 419 the error code "E_INVALID_FIELD_VALUE"; If an ALTO server declares 420 the support of a cost type with the cost metric "ane-path" and a non 421 "array" cost mode, the ALTO client SHOULD assume such a cost type is 422 invalid and ignore it. 424 5.1.3. Path Vector Cost Type Semantics 426 The new cost type follows the convention of the cost types in the 427 base ALTO protocol. Table 1 lists some of the current defined cost 428 types and their semantics. 430 +------------+--------------+---------------------------------------+ 431 | Cost Mode | Cost Metric | Semantics | 432 +------------+--------------+---------------------------------------+ 433 | numerical | routingcost | a number representing the routing | 434 | | | cost | 435 | numerical | hopcount | a number representing the hop count | 436 | ordinal | routingcost | a ranking representing the routing | 437 | | | cost | 438 | ordinal | hopcount | a ranking representing the hop count | 439 | array | ane-path | a list representing the ane path | 440 +------------+--------------+---------------------------------------+ 442 Table 1: Cost Types and Their Semantics 444 The "routingcost" and "hopcount" can encoded in "numerical" or 445 "ordinal", however, the cost metric "ane-path" can only be applied to 446 the cost mode "array" defined in this document to convey path vector 447 information. The cost metric "ane-path" can not be used in 448 "numerical" or "ordinal" unless it is defined in future extensions. 449 If the ALTO server declares that it support cost type with cost 450 metric being "ane-path" and cost mode not being "array", the ALTO 451 client SHOULD ignore them. 453 5.2. ANE Domain 455 This document specifies a new entity domain in addition to the ones 456 in [I-D.ietf-alto-unified-props-new]. 458 5.2.1. Domain Name 460 ane 462 5.2.2. Domain-Specific Entity Addresses 464 The entity address of ane domain is encoded as a JSON string. The 465 string MUST be no more than 64 characters, and it MUST NOT contain 466 characters other than US-ASCII alphanumeric characters 467 (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ("-", 468 U+002D), the colon (":", U+003A), the at sign ("@", code point 469 U+0040), the low line ("_", U+005F), or the "." separator (U+002E). 470 The "." separator is reserved for future use and MUST NOT be used 471 unless specifically indicated in this document, or an extension 472 document. 474 5.2.3. Hierarchy and Inheritance 476 There is no hierarchy or inheritance for properties associated with 477 ANEs. 479 5.3. Abstract Network Element Name 481 An Abstract Network Element Name is encoded as an EntityAddr of the 482 "ane" domain as defined in Section 3.4.2 of 483 [I-D.ietf-alto-unified-props-new]. 485 6. Path Vector Extension: Services 487 This section extends Filtered Cost Map Service and Endpoint Cost 488 Service. It also introduce a new service called "Multipart Cost 489 Property Service". 491 6.1. Filtered Cost Map Extensions 493 This document extends the Filtered Cost Map defined in Section 4.1 of 494 [RFC8189]. 496 The specifications for the "media type", "HTTP method" and "uses" are 497 the same as defined in Section 4.1 of [RFC8189]. 499 6.1.1. Capabilities 501 The FilteredCostMapCapabilities object is extended with a new member 502 "property-map": 504 object { 505 [ResourceID property-map;] 506 } PathVectorFilteredCostMapCapabilities : FilteredCostMapCapabilities 508 property-map: A resource ID defined in the same IRD pointing to an 509 ANE Property Map as defined in Section 2. This field MUST be 510 present if the path vector cost type is present in the "cost-type- 511 names" field. 513 Other fields of the FilteredCostMapCapabilities object has the same 514 format as defined in Section 4.1.1 of [RFC8189] with the following 515 restriction: 517 testable-cost-type-names: The path vector cost type with "ane-path" 518 as the cost metric and "array" as the cost mode MUST NOT be 519 included in "testable-cost-type-names". 521 6.1.2. Accept Input Parameters 523 The ReqFilteredCostMap uses the same format as defined in 524 Section 4.1.2 of [RFC8189], with the following restrictions: 526 constraints, or-constraints: If the path vector cost type is 527 included in either "cost-type" or "multi-cost-types", ALTO clients 528 MUST NOT use it in "constraints" or "or-constraints". Otherwise, 529 the ALTO server MUST return an error with error code 530 "E_INVALID_FIELD_VALUE". 532 testable-cost-types: The path vector cost type MUST NOT be included 533 in the "testable-cost-types" field. Otherwise, the ALTO server 534 MUST return an error with error code "E_INVALID_FIELD_VALUE". 536 6.1.3. Response 538 If the ALTO client includes the cost type "path-vector" in the "cost- 539 type" or "multi-cost-types" field of the input parameter, the 540 response use the same format as defined in Section 4.1.3 of 541 [RFC8189], but the corresponding cost value MUST be encoded as a 542 JSONArray of AbstractNetworkElementName. 544 6.2. Endpoint Cost Service Extensions 546 This document extends the Endpoint Cost Service defined in 547 Section 4.2 in [RFC8189]. 549 The specifications for "HTTP method", "media-type" and "uses" are the 550 same as defined in Section 4.2 in [RFC8189]. 552 6.2.1. Capabilities 554 The same as defined in Section 6.1.1. 556 6.2.2. Accept Input Parameters 558 The ReqEndpointCostMap uses the same format as defined in 559 Section 4.2.2 of [RFC8189], with the following restrictions: 561 cost-type, multi-cost-types: ALTO clients MUST include the path 562 vector cost type, e.g. the one with "ane-path" as cost metric and 563 "array" as cost mode, in either "cost-type" or "multi-cost-types" 564 to activate the path vector extension. 566 constraints, or-constraints: If the path vector cost type is 567 included in either "cost-type" or "multi-cost-types", ALTO clients 568 MUST NOT use it in "constraints" or "or-constraints". Otherwise, 569 the ALTO server MUST return an error with error code 570 "E_INVALID_FIELD_VALUE". 572 testable-cost-types: The path vector cost type MUST NOT be included 573 in the "testable-cost-types" field. Otherwise, the ALTO server 574 MUST return an error with error code "E_INVALID_FIELD_VALUE". 576 6.2.3. Response 578 If the ALTO client specifies the path vector cost type in the "cost- 579 type" or "multi-cost-types" field of the input parameter, the 580 response use the same format as defined in Section 4.2.3 of 581 [RFC8189], but the corresponding cost value MUST be encoded as a 582 JSONArray of AbstractNetworkElementName. 584 6.3. Multipart Cost Property Service 586 This document introduces a new ALTO service called "Multipart Cost 587 Property Service", which provides the path vector information and the 588 associated ANE property information in the same response. 590 6.3.1. Media Type 592 The media type of the Multipart Cost Property service is "multipart/ 593 related". 595 6.3.2. HTTP Method 597 The Multipart Cost Property service is requested using the HTTP POST 598 method. 600 6.3.3. Accept Input Parameters 602 The input parameters of the Multipart Cost Property service MUST be 603 encoded as a JSON object in the body of an HTTP POST request. The 604 media type of the request SHOULD be one of "application/alto- 605 costmapfilter+json" and "application/alto-endpointcostparams+json". 606 The format of the request body depends on the media type: 608 o If the media type of the request is "application/alto- 609 costmapfilter+json", the request body MUST be the same type as 610 defined by Section 6.1.2. 612 o If the media type of the request is "application/alto- 613 endpointcostparams+json", the request body MUST be the same type 614 as defined by Section 6.2.2. 616 The path vector cost type MUST be the only cost type in the input 617 parameter. 619 6.3.4. Capabilities 621 TBD 623 6.3.5. Uses 625 The "uses" attribute MUST be an array with at least one resource id. 626 The first resource id MUST point to a Filtered Cost Map or an 627 Endpoint Cost Service resource. And the path vector cost type MUST 628 be in its "cost-type" capability. If there are more than one 629 resource id in the "uses" attribute, the ALTO client SHOULD ignore 630 any additional resource ids. 632 According to Section 6.1.1, the "property-map" field MUST be present 633 in the first resource. So the ALTO client MUST infer that the 634 Property Map pointed by the "property-map" field of the first 635 resource is also a dependent resource. 637 6.3.6. Response 639 If an ALTO client sends a request of the media type "application/ 640 alto-costmapfilter+json" and accepts "multipart/related", the HTTP 641 body of the response MUST consist of two parts with the media types 642 "application/alto-costmap+json" and "application/alto-propmap+json" 643 accordingly. The part with media type "application/alto- 644 costmap+json" MUST be the first part. The content of the 645 "application/alto-endpointcost+json" part has the same format as 646 defined in Section 6.1.3. 648 If an ALTO client sends a request of the media type "application/ 649 alto-endpointcostparams+json" and accepts "multipart/related", the 650 HTTP body of the response MUST consist of two parts with the media 651 types "application/alto-endpointcost+json" and "application/alto- 652 propmap+json" accordingly. The part with media type "application/ 653 alto-endpointcost+json" MUST be the first part. The content of the 654 "application/alto-endpointcost+json" part has the same format as 655 defined in Section 6.2.3. 657 7. Examples 659 This section lists some examples of path vector queries and the 660 corresponding responses. 662 7.1. Workflow 664 This section gives a typical workflow of an ALTO client using the 665 path-vector extension. 667 1. Send a GET request for the whole Information Resource Directory. 669 2. Look for the resource of the (Filtered) Cost Map/Endpoint Cost 670 Service which contains the path vector cost type and get the 671 resource ID of the dependent abstract network element property 672 map. 674 3. Check whether the capabilities of the property map includes the 675 desired "prop-types". 677 4. Send a path-vector request which accepts "multipart/related" 678 media type following "application/alto-costmap+json" or 679 "application/endpointcost+json". 681 7.2. Information Resource Directory Example 683 Here is an example of an Information Resource Directory. In this 684 example, filtered cost map "cost-map-pv" doesn't support the multi- 685 cost extension but support the path-vector extension, "endpoint- 686 multicost-map" supports both multi-cost extension and path-vector 687 extension. Filtered Property Map "propmap-delay-availbw" supports 688 properties "availbw" and "delay", and "propmap-location" supports 689 property "location". 691 { 692 "meta": { 693 "cost-types": { 694 "pv": { 695 "cost-mode": "array", 696 "cost-metric": "ane-path" 697 }, 698 "num-routingcost": { 699 "cost-mode": "numerical", 700 "cost-metric": "routingcost" 701 }, 702 "num-hopcount": { 703 "cost-mode": "numerical", 704 "cost-metric": "hopcount" 705 } 706 } 707 }, 708 "resources": { 709 "my-default-networkmap": { 710 "uri" : "http://alto.example.com/networkmap", 711 "media-type" : "application/alto-networkmap+json" 712 } 713 "cost-map-pv" : { 714 "uri": "http://alto.example.com/costmap/pv", 715 "media-type": "application/alto-costmap+json", 716 "accepts": "application/alto-costmapfilter+json", 717 "capabilities": { 718 "cost-type-names": [ "pv", "num-hopcount" ] 719 }, 720 "property-map": "propmap-delay", 721 "uses": [ "my-default-networkmap" ] 722 }, 723 "endpoint-multicost-map" : { 724 "uri": "http://alto.exmaple.com/endpointcostmap/multicost", 725 "media-type": "application/alto-endpointcost+json", 726 "accepts": "application/alto-endpointcostparams+json", 727 "capabilities": { 728 "cost-constraints": true, 729 "cost-type-names": [ "pv", "num-routingcost" ], 730 "max-cost-types": 2 731 }, 732 "property-map": "propmap-availbw" 733 }, 734 "propmap-availbw-delay" : { 735 "uri": "http://alto.exmaple.com/propmap/availbw", 736 "media-type": "application/alto-propmap+json", 737 "accepts": "application/alto-propmapparams+json", 738 "capabilities": { 739 "domain-types": [ "ane" ], 740 "prop-types": [ "availbw" ] 741 } 742 }, 743 "propmap-location" : { 744 "uri": "http://alto.exmaple.com/propmap/delay", 745 "media-type": "application/alto-propmap+json", 746 "accepts": "application/alto-propmapparams+json", 747 "capabilities": { 748 "domain-types": [ "pid" ], 749 "prop-types": [ "location" ] 750 } 751 } 752 } 753 } 755 7.3. Example # 1 757 POST /costmap/pv HTTP/1.1 758 Host: alto.example.com 759 Accept: multipart/related, application/alto-costmap+json, 760 application/alto-propmap+json, application/alto-error+json 761 Content-Length: [TBD] 762 Content-Type: application/alto-costmapfilter+json 764 { 765 "cost-type": { 766 "cost-mode": "array", 767 "cost-metric": "ane-path" 768 }, 769 "pids": { 770 "srcs": [ "PID1" ], 771 "dsts": [ "PID2", "PID3" ] 772 } 773 } 775 HTTP/1.1 200 OK 776 Content-Length: [TBD] 777 Content-Type: multipart/related; boundary=42 779 --42 780 Content-Type: application/alto-costmap+json 782 { 783 "meta": { 784 "dependent-vtags": [ 785 { 786 "resource-id": "default-network-map", 787 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 788 } 789 ], 790 "cost-type": { 791 "cost-mode": "array", 792 "cost-metric": "ane-path" 793 }, 794 }, 796 "cost-map": { 797 "PID1": { 798 "PID2": [ "ane:L001", "ane:L003" ], 799 "PID3": [ "ane:L001", "ane:L004" ] 800 } 801 } 802 } 803 --42 804 Content-Type: application/alto-propmap+json 806 { 807 "property-map": { 808 "ane:L001": { "delay": 46}, 809 "ane:L003": { "delay": 50}, 810 "ane:L004": { "delay": 70} 811 } 812 } 814 --42-- 816 7.4. Example # 2 818 POST /endpointcostmap/multicost HTTP/1.1 819 Host: alto.example.com 820 Accept: multipart/related, application/alto-endpointcost+json, 821 application/alto-propmap+json, application/alto-error+json 822 Content-Length: [TBD] 823 Content-Type: application/alto-endpointcostparams+json 825 { 826 "multi-cost-types": [ 827 { 828 "cost-mode": "array", 829 "cost-metric": "ane-path" 830 }, 831 { 832 "cost-mode": "numerical", 833 "cost-metric": "routingcost" 834 } 835 ], 836 "endpoints": { 837 "srcs": [ "ipv4:192.0.2.2" ], 838 "dsts": [ "ipv4:192.0.2.89", 839 "ipv4:203.0.113.45", 840 "ipv6:2001:db8::10" ] 841 } 842 } 844 HTTP/1.1 200 OK 845 Content-Length: [TBD] 846 Content-Type: multipart/related; boundary=example-2 848 --example-2 849 Content-Type: application/alto-endpointcost+json 850 { 851 "meta": { 852 "multi-cost-types": [ 853 {"cost-mode": "array", "cost-metric": "ane-path"}, 854 {"cost-mode": "numerical", "cost-metric": "routingcost"} 855 ] 856 }, 858 "endpoint-cost-map": { 859 "ipv4:192.0.2.2": { 860 "ipv4:192.0.2.89": [[ "ane:L001", "ane:L003", "ane:L004" ], 77], 861 "ipv4:203.0.113.45": [[ "ane:L001", "ane:L004", "ane:L005" ], 68], 862 "ipv6:2001:db8::10": [[ "ane:L001", "ane:L005", "ane:L007" ], 98] 863 } 864 } 865 } 867 --example-2 868 Content-Type: application/alto-propmap+json 870 { 871 "property-map": { 872 "ane:L001": { "availbw": 50 }, 873 "ane:L003": { "availbw": 48 }, 874 "ane:L004": { "availbw": 55 }, 875 "ane:L005": { "availbw": 60 }, 876 "ane:L007": { "availbw": 35 } 877 } 878 } 880 --example-2-- 882 8. Compatibility 884 8.1. Compatibility with Legacy ALTO Clients/Servers 886 The path vector extension on Filtered Cost Map and Endpoint Cost 887 Service is backward compatible with the base ALTO protocol. If the 888 ALTO server provides path vector extended Filtered Cost Map or 889 Endpoint Cost Service, but the client is a base ALTO client, then the 890 client will ignore the path vector cost type without conducting any 891 incompatibility. If the client sents a request with path vector cost 892 type, but the server is a base ALTO server, the server will return an 893 "E_INVALID_FIELD_VALUE" error. 895 8.2. Compatibility with Multi-Cost Extensions 897 Cost type path-vector is not a testable cost type. Any format of 898 constraints SHOULD NOT be applied to cost type path-vector in order 899 for multi-cost to support the path-vector extension. Specifically, 901 o Cost type path-vector MUST NOT be included in "testable-cost- 902 types-names" or "testable-cost-types". 904 o When "testable-cost-types-names" is omitted in the "capabilities" 905 and "testable-cost-types" is omitted in the input parameters, 906 "constraints" or "or-constraints" SHOULD NOT add any format of 907 constraints on cost type path-vector. 909 8.3. Compatibility with Incremental Update 911 [I-D.ietf-alto-incr-update-sse] defines incremental updates to ALTO 912 resources and hence it can be applied to the path-vector resource 913 defined in this document. 915 9. Design Decisions and Discussions 917 9.1. Provide More General Calendar Extension 919 Cost Calendar is proposed as a useful ALTO extension to provide the 920 historical cost values for Filtered Cost Map Service and Endpoint 921 Cost Service. Since path vector is an extension to these services, 922 it SHOULD be compatible with Cost Calendar extension. 924 However, the calendar of a path-vector (Endpoint) Cost Map is 925 insufficient for the application which requires the historical data 926 of routing state information. The (Endpoint) Cost Map can only 927 provide the changes of the paths. But more useful information is the 928 history of network element properties which are recorded in the 929 dependent Network Element Property Map. 931 Before the Unified Property Map is introduced as an ALTO extension, 932 Filtered Cost Map Service and Endpoint Cost Service are the only 933 resources which require the calendar supported. Because other 934 resources don't have to be updated frequently. But Network Element 935 Property Map as a use case of Unified Property Map will collect the 936 real-time information of the network. It SHOULD be updated as soon 937 as possible once the metrics of network elements change. 939 So the requirement is to provide a general calendar extension which 940 not only meets the Filtered Cost Map and Endpoint Cost Service but 941 also applies to the Property Map Service. 943 10. Security Considerations 945 10.1. Privacy Concerns 947 We can identify multiple potential security issues. A main security 948 issue is network privacy, as the path-vector information may reveal 949 more network internal structures than the more abstract single-node 950 abstraction. The network should consider protection mechanisms to 951 reduce information exposure, in particular, in settings where the 952 network and the application do not belong to the same trust domain. 953 On the other hand, in a setting of the same trust domain, a key 954 benefit of the path-vector abstraction is reduced information 955 transfer from the network to the application. 957 The path-vector query may also reveal more information about the 958 application. In particular, the application may reveal all potential 959 transfers sites (e.g., where the data source is replicated, and where 960 the potential replication sites are). The application should 961 evaluate the potential privacy concerns. 963 Beyond the privacy issues, the computation of the path-vector is 964 unlikely to be cachable, in that the results will depend on the 965 particular requests (e.g., where the flows are distributed). Hence, 966 this service may become an entry point for denial of service attacks 967 on the availability of an ALTO server. Hence, authenticity and 968 authorization of this ALTO service may need to be better protected. 970 10.2. Resource Consumption on ALTO Servers 972 TODO: The Abstract Network Element Property Map is dynamically 973 enriched when the (Filtered) Cost Map/Endpoint Cost Service is 974 queried of the path-vector information. The properties of the 975 abstract network elements can consume a large amount of resources 976 when cached. So, a time-to-live is needed to remove outdated entries 977 in the Abstract Network Element Property Map. 979 11. IANA Considerations 981 11.1. ALTO Cost Mode Registry 983 This document specifies a new cost mode "array". However, the base 984 ALTO protocol does not have a Cost Mode Registry where new cost mode 985 can be registered. This new cost mode will be registered once the 986 registry is defined either in a revised version of [RFC7285] or in 987 another future extension. 989 11.2. ALTO Cost Metric Registry 991 A new cost metric needs to be registered in the "ALTO Cost Metric 992 Registry", listed in Table 2. 994 +-------------+---------------------+ 995 | Identifier | Intended Semantics | 996 +-------------+---------------------+ 997 | ane-path | See Section 5.1.2 | 998 +-------------+---------------------+ 1000 Table 2: ALTO Cost Metrics 1002 11.3. ALTO Entity Domain Registry 1004 As proposed in Section 9.2 of [I-D.ietf-alto-unified-props-new], 1005 "ALTO Entity Domain Registry" is requested. Besides, a new domain is 1006 to be registered, listed in Table 3. 1008 +-------------+--------------------------+--------------------------+ 1009 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1010 +-------------+--------------------------+--------------------------+ 1011 | ane | See Section 5.2.2 | None | 1012 +-------------+--------------------------+--------------------------+ 1014 Table 3: ALTO Entity Domain 1016 11.4. ALTO Network Element Property Type Registry 1018 The "ALTO Abstract Network Element Property Type Registry" is 1019 required by the ALTO Entity Domain "ane", listed in Table 4. 1021 +-------------+--------------------------+ 1022 | Identifier | Intended Semantics | 1023 +-------------+--------------------------+ 1024 | availbw | The available bandwidth | 1025 | delay | The transmission delay | 1026 +-------------+--------------------------+ 1028 Table 4: ALTO Abstract Network Element Property Types 1030 12. Acknowledgments 1032 The authors would like to thank discussions with Randriamasy Sabine, 1033 Andreas Voellmy, Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao 1034 Xiang, Tianyuan Liu, Xiao Shi, Xin Wang, and Yan Luo. 1036 13. References 1038 13.1. Normative References 1040 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1041 Requirement Levels", BCP 14, RFC 2119, 1042 DOI 10.17487/RFC2119, March 1997, . 1045 13.2. Informative References 1047 [I-D.amante-i2rs-topology-use-cases] 1048 Medved, J., Previdi, S., Lopez, V., and S. Amante, 1049 "Topology API Use Cases", draft-amante-i2rs-topology-use- 1050 cases-01 (work in progress), October 2013. 1052 [I-D.bernstein-alto-topo] 1053 Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology 1054 Service: Uses Cases, Requirements, and Framework", draft- 1055 bernstein-alto-topo-00 (work in progress), October 2013. 1057 [I-D.ietf-alto-cost-calendar] 1058 Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. 1059 Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- 1060 calendar-01 (work in progress), February 2017. 1062 [I-D.ietf-alto-incr-update-sse] 1063 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1064 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 1065 sse-08 (work in progress), January 2018. 1067 [I-D.ietf-alto-unified-props-new] 1068 Roome, W., Chen, S., xinwang2014@hotmail.com, x., Yang, 1069 Y., and J. Zhang, "Extensible Property Maps for the ALTO 1070 Protocol", draft-ietf-alto-unified-props-new-01 (work in 1071 progress), December 2017. 1073 [I-D.lee-alto-app-net-info-exchange] 1074 Lee, Y., Dhody, D., Wu, Q., Bernstein, G., and T. Choi, 1075 "ALTO Extensions to Support Application and Network 1076 Resource Information Exchange for High Bandwidth 1077 Applications in TE networks", draft-lee-alto-app-net-info- 1078 exchange-04 (work in progress), October 2013. 1080 [I-D.yang-alto-topology] 1081 Bernstein, G., Lee, Y., Roome, W., Scharf, M., and Y. 1082 Yang, "ALTO Topology Extensions: Node-Link Graphs", draft- 1083 yang-alto-topology-06 (work in progress), March 2015. 1085 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 1086 RFC 2387, DOI 10.17487/RFC2387, August 1998, 1087 . 1089 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1090 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1091 "Application-Layer Traffic Optimization (ALTO) Protocol", 1092 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1093 . 1095 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1096 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1097 DOI 10.17487/RFC8189, October 2017, . 1100 Authors' Addresses 1102 Greg Bernstein 1103 Grotto Networking 1104 Fremont, CA 1105 USA 1107 Email: gregb@grotto-networking.com 1109 Shiwei Dawn Chen 1110 Tongji University 1111 4800 Caoan Road 1112 Shanghai 201804 1113 China 1115 Email: dawn_chen_f@hotmail.com 1117 Kai Gao 1118 Tsinghua University 1119 Beijing Beijing 1120 China 1122 Email: gaok12@mails.tsinghua.edu.cn 1124 Young Lee 1125 Huawei 1126 TX 1127 USA 1129 Email: leeyoung@huawei.com 1130 Wendy Roome 1131 Nokia/Bell Labs (Retired) 1132 124 Burlington Rd 1133 Murray Hill, NJ 07974 1134 USA 1136 Phone: +1-908-464-6975 1137 Email: wendy@wdroome.com 1139 Michael Scharf 1140 Nokia 1141 Germany 1143 Email: michael.scharf@nokia.com 1145 Y. Richard Yang 1146 Yale University 1147 51 Prospect St 1148 New Haven CT 1149 USA 1151 Email: yry@cs.yale.edu 1153 Jingxuan Jensen Zhang 1154 Tongji University 1155 4800 Caoan Road 1156 Shanghai 201804 1157 China 1159 Email: jingxuan.n.zhang@gmail.com