idnits 2.17.1 draft-ietf-alto-path-vector-06.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 (June 18, 2019) is 1773 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 868, but not defined == 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-16 == Outdated reference: A later version (-28) exists of draft-ietf-alto-performance-metrics-06 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-07 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG K. Gao 3 Internet-Draft Tsinghua University 4 Intended status: Standards Track Y. Lee 5 Expires: December 20, 2019 Huawei 6 S. Randriamasy 7 Nokia Bell Labs 8 Y. Yang 9 Yale University 10 J. Zhang 11 Tongji University 12 June 18, 2019 14 ALTO Extension: Path Vector Cost Type 15 draft-ietf-alto-path-vector-06 17 Abstract 19 The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] 20 has defined cost maps and endpoint cost maps to provide basic network 21 information. However, they provide only scalar (numerical or 22 ordinal) cost mode values, which are insufficient to satisfy the 23 demands of solving more complex network optimization problems. This 24 document introduces an extension to the base ALTO protocol, namely 25 the path-vector extension, which allows ALTO clients to query 26 information such as the capacity region for a given set of flows 27 (called co-flows). A non-normative example called co-flow scheduling 28 is presented to illustrate the limitations of existing ALTO endpoint 29 cost maps. After that, details of the extension are defined. 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 https://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 December 20, 2019. 54 Copyright Notice 56 Copyright (c) 2019 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 (https://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. Use Case: Capacity Region for Co-Flow Scheduling . . . . . . 5 74 4. Overview of Path Vector Extensions . . . . . . . . . . . . . 7 75 4.1. New Cost Mode to Encode Path Vectors . . . . . . . . . . 7 76 4.2. New ALTO Entity Domain for ANE Properties . . . . . . . . 8 77 4.3. Multipart/Related Resource for Consistency . . . . . . . 8 78 5. Path-Vector Cost Type . . . . . . . . . . . . . . . . . . . . 9 79 5.1. Cost Mode: path-vector . . . . . . . . . . . . . . . . . 10 80 5.2. Cost Metric: Link Maximum Reservable Bandwidth . . . . . 10 81 6. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 6.1. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 11 83 6.2. Domain-Specific Entity Identifier . . . . . . . . . . . . 11 84 6.3. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 11 85 7. Multipart Filtered Cost Map for Path Vector . . . . . . . . . 11 86 7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 11 87 7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 11 88 7.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 12 89 7.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 12 90 7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 12 92 8. Multipart Endpoint Cost Service for Path Vector . . . . . . . 13 93 8.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 13 94 8.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 13 95 8.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 13 96 8.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 13 97 8.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 8.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 14 99 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 100 9.1. Information Resource Directory Example . . . . . . . . . 14 101 9.2. Example #1 . . . . . . . . . . . . . . . . . . . . . . . 16 102 9.3. Example #2 . . . . . . . . . . . . . . . . . . . . . . . 17 103 9.4. Example for Incremental Update . . . . . . . . . . . . . 19 104 10. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 20 105 10.1. Compatibility with Base ALTO Clients/Servers . . . . . . 20 106 10.2. Compatibility with Multi-Cost Extension . . . . . . . . 21 107 10.3. Compatibility with Incremental Update . . . . . . . . . 21 108 11. General Discussions . . . . . . . . . . . . . . . . . . . . . 21 109 11.1. Provide Calendar for Property Map . . . . . . . . . . . 21 110 11.2. Constraint Tests for General Cost Types . . . . . . . . 22 111 11.3. General Multipart Resources Query . . . . . . . . . . . 22 112 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 113 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 114 13.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 23 115 13.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . 23 116 13.3. ALTO Property Type Registry . . . . . . . . . . . . . . 24 117 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 118 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 119 15.1. Normative References . . . . . . . . . . . . . . . . . . 24 120 15.2. Informative References . . . . . . . . . . . . . . . . . 25 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 123 1. Introduction 125 The base ALTO protocol [RFC7285] is designed to expose network 126 information through services such as cost maps and endpoint cost 127 service. These services use an extreme "single-node" network 128 abstraction, which represents a whole network as a single node, and 129 hosts as "endpoint groups" directly connected to the node. 131 Although the "single-node" abstraction works well in many settings, 132 it lacks the ability to support emerging use cases, such as co-flow 133 scheduling for large-scale data analytics. For such a use case, 134 applications require a more powerful network view abstraction beyond 135 the "single-node" abstraction. 137 To support capabilities like co-flow scheduling, this document uses a 138 "path vector" abstraction to represent more detailed network graph 139 information like capacity regions. A path vector is a sequence of 140 abstract network elements (ANEs), and each ANE represents a network 141 device that end-to-end traffic goes through, such as links, switches, 142 middleboxes, and their aggregations. An ANE can have properties such 143 as "bandwidth", and "delay". Providing such information can help 144 both applications to achieve better application performance and 145 networks to avoid network congestion. 147 Providing path vector abstraction using ALTO introduces the following 148 additional requirements (ARs): 150 AR-1: The path vector abstraction requires the encoding of array- 151 like cost values rather than scalar cost values in cost maps or 152 endpoint cost maps. 154 Specifically, the path vector abstraction requires the 155 specification of the sequence of ANEs between sources and 156 destinations. Such a sequence, however, cannot be encoded by the 157 scalar types (numerical or ordinal) which the base ALTO protocol 158 supports. 160 AR-2: The path vector abstraction requires the encoding of the 161 properties of aforementioned ANEs. 163 Specifically, only the sequences of ANEs are not enough for 164 existing use cases. Properties of ANEs such as "bandwidth" and 165 "delay" are needed by applications to properly construct network 166 constraints or states. 168 AR-3: The path vector abstraction requires consistent encoding of 169 path vectors (AR-1) and the properties of the ANEs in a path 170 vector (AR-2). 172 Specifically, path vectors and the properties of ANEs in the 173 vectors are dependent. A mechanism to query both of them 174 consistently is necessary. 176 This document proposes the path vector extension to the ALTO protocol 177 to satisfy these additional requirements . 179 Specifically, the extension encodes the array (AR-1) of ANEs over an 180 end-to-end path using a new cost type, and conveys the properties of 181 ANEs (AR-2) using unified property map 182 [I-D.ietf-alto-unified-props-new]. The path vector and ANE 183 properties are conveyed in a single message encoded as a multipart/ 184 related message to satisfy AR-3. 186 The rest of this document is organized as follows. Section 3 gives 187 an example of co-flow scheduling and illustrates the limitations of 188 the base ALTO protocol in such a use case. Section 4 gives an 189 overview of the path vector extension. Section 5 introduces a new 190 cost type. Section 6 registers a new domain in Domain Registry. 191 Section 7 and Section 8 define new ALTO resources to support Path 192 Vector query by using the request format of Filtered Cost Map and 193 Endpoint Cost Service. Section 9 presents several examples. 194 Section 10 and Section 11 discusses compatibility issues with other 195 existing ALTO extensions and design decisions. Section 12 and 196 Section 13 review the security and IANA considerations. 198 2. Terminology 200 Besides the terms defined in [RFC7285] and 201 [I-D.ietf-alto-unified-props-new], this document also uses the 202 following additional terms: Abstract Network Element and Path Vector. 204 o Abstract Network Element (ANE): An abstract network element is an 205 abstraction of network components. It can be an aggregation of 206 links, middleboxes, virtualized network function (VNF), etc. An 207 abstract network element has two types of attributes: a name and a 208 set of properties. 210 o Path Vector: A path vector is an array of ANEs. It presents an 211 abstract network path between source/destination points such as 212 PIDs or endpoints. 214 3. Use Case: Capacity Region for Co-Flow Scheduling 216 Assume that an application has control over a set of flows, which may 217 go through shared links or switches and share a bottleneck. The 218 application hopes to schedule the traffic among multiple flows to get 219 better performance. The capacity region information for those flows 220 will benefit the scheduling. However, existing cost maps cannot 221 reveal such information. 223 Specifically, consider a network as shown in Figure 1. The network 224 has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches 225 sw1/sw3 provide access on one side, sw2/sw4 provide access on the 226 other side, and sw5-sw7 form the backbone. Endhosts eh1 to eh4 are 227 connected to access switches sw1 to sw4 respectively. Assume that 228 the bandwidth all links are 100 Mbps. 230 +------+ 231 | | 232 --+ sw6 +-- 233 / | | \ 234 PID1 +-----+ / +------+ \ +-----+ PID2 235 eh1__| |_ / \ ____| |__eh2 236 | sw1 | \ +--|---+ +---|--+ / | sw2 | 237 +-----+ \ | | | |/ +-----+ 238 \_| sw5 +---------+ sw7 | 239 PID3 +-----+ / | | | |\ +-----+ PID4 240 eh3__| |__/ +------+ +------+ \____| |__eh4 241 | sw3 | | sw4 | 242 +-----+ +-----+ 244 Figure 1: Raw Network Topology. 246 The single-node ALTO topology abstraction of the network is shown in 247 Figure 2. 249 +----------------------+ 250 {eh1} | | {eh2} 251 PID1 | | PID2 252 +------+ +------+ 253 | | 254 | | 255 {eh3} | | {eh4} 256 PID3 | | PID4 257 +------+ +------+ 258 | | 259 +----------------------+ 261 Figure 2: Base Single-Node Topology Abstraction. 263 Consider an application overlay (e.g., a large data analysis system) 264 which wants to schedule the traffic among a set of end host source- 265 destination pairs, say eh1 -> eh2 and eh3 -> eh4. The application 266 can request a cost map providing end-to-end available bandwidth, 267 using "availbw" as cost-metric and "numerical" as cost-mode. 269 The application will receive from ALTO server that the bandwidth of 270 eh1 -> eh2 and eh3 -> eh4 are both 100 Mbps. But this information is 271 not enough. Consider the following two cases: 273 o Case 1: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw6 -> 274 sw7 -> sw2 -> eh2 and eh3 -> eh4 uses path eh3 -> sw3 -> sw5 -> 275 sw7 -> sw4 -> eh4, then the application will obtain 200 Mbps. 277 o Case 2: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw7 -> 278 sw2 -> eh2 and eh3 -> eh4 uses the path eh3 -> sw3 -> sw5 -> sw7 279 -> sw4 -> eh4, then the application will obtain only 100 Mbps due 280 to the shared link from sw5 to sw7. 282 To allow applications to distinguish the two aforementioned cases, 283 the network needs to provide more details. In particular: 285 o The network needs to expose more detailed routing information to 286 show the shared bottlenecks; 288 o The network needs to provide the necessary abstraction to hide the 289 real topology information while providing enough information to 290 applications. 292 The path vector extension defined in this document provides a 293 solution to address the preceding issue. 295 See [I-D.bernstein-alto-topo] for a more comprehensive survey of use 296 cases where extended network topology information is needed. 298 4. Overview of Path Vector Extensions 300 This section presents an overview of approaches adopted by the path 301 vector extension. It assumes that the readers are familiar with cost 302 map and endpoint cost service defined in [RFC7285]. The path vector 303 extension also requires the support of Filtered Property Map defined 304 in [I-D.ietf-alto-unified-props-new]. 306 The path vector extension is composed of three building blocks: (1) a 307 new cost mode to encode path vectors in a cost map or an endpoint 308 cost map; (2) a new ALTO entity domain to enable ANE property 309 encoding using the unified property extension 310 [I-D.ietf-alto-unified-props-new]; and (3) a generic mechanism to put 311 multiple ALTO information objects in a single response to enforce 312 consistency, to preserve modularity and to avoid complex linking of 313 multiple responses. 315 4.1. New Cost Mode to Encode Path Vectors 317 Existing cost modes defined in [RFC7285] allow only scalar cost 318 values. However, the "path vector" abstraction requires to convey 319 vector format information (AR-1). To fulfill this requirement, this 320 document defines a new "cost-mode" named path vector to indicate that 321 the cost value is an array of ANEs. A path vector abstraction should 322 be computed for a specific performance metric, and this is achieved 323 using the existing "cost-metric" component of cost type. The details 324 of the new "cost-mode" is given in Section 5. 326 4.2. New ALTO Entity Domain for ANE Properties 328 A path vector of ANEs contains only the abstracted routing elements 329 between a source and a destination. Hence, an application can find 330 shared ANEs of different source-destination pairs but cannot know the 331 shared ANEs' properties. For the capacity region use case in 332 Section 3, knowing that eh1->eh2 and eh3->eh4 share ANEs but not the 333 available bandwidth of the shared ANEs, is not enough. 335 To encode ANE properties like the available bandwidth in a path 336 vector query response, this document uses the unified property 337 extension defined in [I-D.ietf-alto-unified-props-new]. 338 Specifically, for each path vector query, the ALTO server generates a 339 property map associated to the (endpoint) cost map as follows: 341 o a dynamic entity domain of an entity domain type "ane" is 342 generated to contain the generated ANEs. Each ANE has the same 343 unique identifier in the path vectors and in the dynamic entity 344 domain; 346 o each entity in this dynamic entity domain has the property defined 347 by the "cost-metric" that generated the ANEs in the query. 349 Detailed information and specifications are given in Section 6. 351 4.3. Multipart/Related Resource for Consistency 353 Path vectors and the property map containing the ANEs are two 354 different types of objects, but they require strong consistency. One 355 approach to achieving strong consistency is to define a new media 356 type to contain both objects, but this violates modular design. 358 Another approach is to provide the objects in two different 359 information resources. Thus, an ALTO client needs to make separate 360 queries to get the information of related services. This may cause a 361 data synchronization problem between two queries. Also, as the 362 generation of ANE is dynamic, an ALTO server must cache the results 363 of a query before a client fully retrieves all related resources, 364 which hurts the scalability and security of an ALTO server. 366 This document uses standard-conforming usage of "multipart/related" 367 media type defined in [RFC2387] to elegantly solve the problem. 369 Specifically, using "multipart/related" needs to address two issues: 371 o ALTO uses media type to indicate the type of an entry in the 372 information resource directory (IRD) (e.g., "application/alto- 373 costmap+json" for cost map and "application/alto- 374 endpointcostmap+json" for endpoint cost map). Simply putting 375 "multipart/related" as the media type, however, makes it 376 impossible for an ALTO client to identify the type of service 377 provided by related entries. 379 o The ALTO SSE extension (see [I-D.ietf-alto-incr-update-sse]) 380 depends on resource-id to identify push updates, but resource-id 381 is provided only in IRD and hence each entry in the IRD has only 382 one resource-id. 384 This design addresses the two issues as follows: 386 o To address the first issue, the multipart/related media type 387 includes the type parameter to allow type indication of the root 388 object. For a cost map service, the "media-type" will be 389 "multipart/related" with the parameter "type=application/alto- 390 costmap+json"; for an endpoint cost map service, the parameter 391 will be "type=application/alto-endpointcostmap+json". This design 392 is highly extensible. The entries can still use "application/ 393 alto-costmapfilter+json" or "application/alto- 394 endpointcostparams+json" as the accept input parameters, and hence 395 an ALTO client still sends the filtered cost map request or 396 endpoint cost service request. The ALTO server sends the response 397 as a "multipart/related" message. The body of the response 398 includes two parts: the first one is of the media type specified 399 by the "type" parameter; the second one is a property map 400 associated to the first map. 402 o To address the second issue, each part of the "multipart/related" 403 response message has the MIME part header information including 404 "Content-Type" and "Resource-Id". An ALTO server MAY generate 405 incremental updates (see [I-D.ietf-alto-incr-update-sse]) for each 406 part separately using the "Resource-Id" header. 408 By applying the design above, for each path vector query, an ALTO 409 server returns the path vectors and the associated property map 410 modularly and consistently. An ALTO server can reuse the data models 411 of the existing information resources. And an ALTO client can 412 subscribe to the incremental updates for the dynamic generated 413 information resources without any changes, if th ALTO server provides 414 incremental updates for them. 416 5. Path-Vector Cost Type 418 This document extends the cost types defined in Section 6.1 of 419 [RFC7285] by introducing a new cost mode "path-vector". In the rest 420 of the document, we use "path-vector" to indicate the cost type with 421 the cost-mode "path-vector" for short. 423 5.1. Cost Mode: path-vector 425 This document extends the CostMode defined in Section 10.5 of 426 [RFC7285] with a new cost mode: "path-vector". This cost mode 427 indicates that every cost value in a cost map represents an array of 428 ANEs which are defined in Section 6.2, rather than a JSON number or a 429 ranking order. 431 The ANEs computed by the ALTO server associate to the cost metric for 432 the "path-vector" cost mode. This document re-defines some cost 433 metrics for "path-vector", which are motivated by the co-flow 434 scheduling use case. The ALTO client SHOULD ignore the "path-vector" 435 cost mode with any other cost metrics, unless the future documents 436 define other cost metrics or specify the semantics of existing cost 437 metrics for "path-vector" cost mode for some additional requirements. 439 5.2. Cost Metric: Link Maximum Reservable Bandwidth 441 This document uses the same metric name, units of measurement and 442 measurement point(s) with potential measurement domain defined by 443 section 4.1 of [I-D.ietf-alto-performance-metrics], but specifies 444 different metric description and method of measurement or calculation 445 for "path-vector" cost mode only. 447 Metric Description: When used with "path-vector" cost mode, it is to 448 specify the path vector computed by using the spatial and temporal 449 maximum reservable bandwidth over each network link. The value of 450 the maximum reservable bandwidth of each ANE in the path vector is 451 specified in the associated property map. 453 Method of Measurement or Calculation: The value of Maximum 454 Reservable Bandwidth is the bandwidth measured between two 455 directly connected IS-IS neighbors, OSPF neighbors or BGP 456 neighbors. The associated ANEs are computed by some algorithm 457 which can guarantee the equivalent Maximum Reservable Bandwidth 458 constraints. 460 6. ANE Domain 462 This document specifies a new ALTO entity domain called "ane" in 463 addition to the ones in [I-D.ietf-alto-unified-props-new]. The ANE 464 domain associates property values with the ANEs in a network. The 465 entity in ANE domain is often used in the path vector by cost maps or 466 endpoint cost resources. Accordingly, the ANE domain always depends 467 on a cost map or an endpoint cost map. 469 6.1. Domain Name 471 ane 473 6.2. Domain-Specific Entity Identifier 475 The entity identifier of ane domain is encoded as a JSON string. The 476 string MUST be no more than 64 characters, and it MUST NOT contain 477 characters other than US-ASCII alphanumeric characters 478 (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ("-", 479 U+002D), the colon (":", U+003A), the at sign ("@", code point 480 U+0040), the low line ("_", U+005F), or the "." separator (U+002E). 481 The "." separator is reserved for future use and MUST NOT be used 482 unless specifically indicated in this document, or an extension 483 document. 485 To simplify the description, we use "ANE name" to indicate the 486 identifier of an entity in ANE domain in this document. 488 The ANE name is usually unrelated to the physical device information. 489 It is usually generated by the ALTO server on demand and used to 490 distinguish from other ANEs in its dependent cost map or endpoint 491 cost map. 493 6.3. Hierarchy and Inheritance 495 There is no hierarchy or inheritance for properties associated with 496 ANEs. 498 7. Multipart Filtered Cost Map for Path Vector 500 This document introduces a new ALTO resource called Multipart 501 Filtered Cost Map resource, which allows an ALTO server to provide 502 other ALTO resources associated to the Cost Map resource in the same 503 response. 505 7.1. Media Type 507 The media type of the Multipart Filtered Cost Map Resource is 508 "multipart/related;type=application/alto-costmap+json". 510 7.2. HTTP Method 512 The Multipart Filtered Cost Map is requested using the HTTP POST 513 method. 515 7.3. Accept Input Parameters 517 The input parameters of the Multipart Filtered Cost Map MUST be 518 encoded as a JSON object in the body of an HTTP POST request. The 519 media type of the request MUST be one of "application/alto- 520 costmapfilter+json". The format of the request body MUST be the same 521 type as defined by section 11.3.2.3 of [RFC7285]. 523 7.4. Capabilities 525 The Multipart Filtered Cost Map resource uses the same capabilities 526 as defined by section 11.3.2.4 of [RFC7285]. But the "cost-type- 527 names" field SHOULD only includes cost types in "path-vector" cost 528 mode. Otherwise, the ALTO client SHOULD ignore a cost type in other 529 cost mode, unless additional documents define the specification of it 530 for the Multipart Filtered Cost Map resource. 532 7.5. Uses 534 The resource ID of the network map based on which the PIDs in the 535 returned cost map will be defined. 537 7.6. Response 539 The response MUST indicate an error, using ALTO protocol error 540 handling, as defined in Section 8.5 of [RFC7285], if the request is 541 invalid. 543 The response to a valid request MUST be a "multipart/related" message 544 as defined by [RFC2387]. The body consists of two parts: 546 o the first part MUST include "Resource-Id" and "Content-Type" in 547 its header. The value of "Resource-Id" MUST be prefixed by the 548 resource id of the Multipart Filtered Cost Map appended by a "." 549 character. The body of this part MUST be a JSON object with the 550 same format as defined in Section 11.2.3.6 of [RFC7285]; The JSON 551 object MUST include the "vtag" field in the "meta" field, which 552 provides the version tag of the returned cost map. The resource 553 id of the version tag MUST be as same as the value of the 554 "Resource-Id" header. The "meta" field MUST also include the 555 "dependent-vtags" field, whose value is a single-element array to 556 indicate the version tag of the network map used, where the 557 network map is specified in the "uses" attribute of the Multipart 558 Cost Map resource in IRD. 560 o the second part MUST also include "Resource-Id" and "Content-Type" 561 in its header. The value of "Resource-Id" MUST be prefixed by the 562 resource id of the Multipart Filtered Cost Map appended by a "." 563 character. The body of this part MUST be a JSON object with the 564 same format as defined in Section 4.6 of 565 [I-D.ietf-alto-unified-props-new]. The JSON object MUST include 566 the "dependent-vtags" field in the "meta" field. The value of the 567 "dependent-vtags" field MUST be an array with a single VersionTag 568 object as defined by section 10.3 of [RFC7285]. The "resource-id" 569 of this VersionTag MUST be the value of "Resource-Id" header of 570 the first part. The "tag" of this VersionTag MUST be the "tag" of 571 "vtag" of the first part body. 573 8. Multipart Endpoint Cost Service for Path Vector 575 This document introduces a new ALTO resource called Multipart 576 Endpoint Cost resource, which allows an ALTO server to provide other 577 ALTO resources associated to the Endpoint Cost resource in the same 578 response. 580 8.1. Media Type 582 The media type of the Multipart Endpoint Cost Resource is 583 "multipart/related;type=application/alto-endpointcostmap+json". 585 8.2. HTTP Method 587 The Multipart Endpoint Cost resource is requested using the HTTP POST 588 method. 590 8.3. Accept Input Parameters 592 The input parameters of the Multipart Endpoint Cost resource MUST be 593 encoded as a JSON object in the body of an HTTP POST request. The 594 media type of the request MUST be one of "application/alto- 595 endpointcostparams+json". The format of the request body MUST be the 596 same type as defined by section 11.5.1.3 of [RFC7285]. 598 8.4. Capabilities 600 The Multipart Endpoint Cost resource uses the same capabilities as 601 defined by section 11.3.2.4 of [RFC7285]. But the "cost-type-names" 602 field SHOULD only includes cost types in "path-vector" cost mode. 603 Otherwise, the ALTO client SHOULD ignore a cost type in other cost 604 mode, unless additional documents define the specification of it for 605 the Multipart Endpoint Cost resource. 607 8.5. Uses 609 The Multipart Endpoint Cost resource MUST NOT specify the "uses" 610 attribute. 612 8.6. Response 614 The response MUST indicate an error, using ALTO protocol error 615 handling, as defined in Section 8.5 of [RFC7285], if the request is 616 invalid. 618 The response to a valid request MUST be a "multipart/related" message 619 as defined by [RFC2387]. The body consists of two parts: 621 o the first part MUST include "Resource-Id" and "Content-Type" in 622 its header. The value of "Resource-Id" MUST be prefixed by the 623 resource id of the Multipart Filtered Cost Map appended by a "." 624 character (U+002E). The body of this part MUST be a JSON object 625 with the same format as defined in Section 11.5.1.6 of [RFC7285]; 626 The JSON object MUST include the "vtag" field in the "meta" field, 627 which provides the version tag of the returned endpoint cost map. 628 The resource id of the version tag MUST be as same as the value of 629 the "Resource-Id" header. 631 o the second part MUST also include "Resource-Id" and "Content-Type" 632 in its header. The value of "Resource-Id" MUST be prefixed by the 633 resource id of the Multipart Filtered Cost Map appended by a "." 634 character (U+002E). The body of this part MUST be a JSON object 635 with the same format as defined in Section 4.6 of 636 [I-D.ietf-alto-unified-props-new]. The JSON object MUST include 637 the "dependent-vtags" field in the "meta" field. The value of the 638 "dependent-vtags" field MUST be an array with a single VersionTag 639 object as defined by section 10.3 of [RFC7285]. The "resource-id" 640 of this VersionTag MUST be the value of "Resource-Id" header of 641 the first part. The "tag" of this VersionTag MUST be the "tag" of 642 "vtag" of the first part body. 644 9. Examples 646 This section lists some examples of path vector queries and the 647 corresponding responses. 649 9.1. Information Resource Directory Example 651 Here is an example of an Information Resource Directory. In this 652 example, the "cost-map-pv" information resource provides a Multipart 653 Cost Map resource for path-vector; the "endpoint-cost-pv" information 654 resource provides a MultipartEndpoint Cost resource for path-vector. 656 Both of them support the Maximum Reservable Bandwidth ("maxresbw") 657 cost metric in "path-vector" cost mode. 659 { 660 "meta": { 661 "cost-types": { 662 "pv-maxresbw": { 663 "cost-mode": "path-vector", 664 "cost-metric": "maxresbw" 665 } 666 } 667 }, 668 "resources": { 669 "my-default-networkmap": { 670 "uri" : "http://alto.example.com/networkmap", 671 "media-type" : "application/alto-networkmap+json" 672 }, 673 "cost-map-pv": { 674 "uri": "http://alto.example.com/costmap/pv", 675 "media-type": `multipart/related; 676 type=application/alto-costmap+json`, 677 "accepts": "application/alto-costmapfilter+json", 678 "capabilities": { 679 "cost-type-names": [ "pv-maxresbw" ] 680 }, 681 "uses": [ "my-default-networkmap" ] 682 }, 683 "endpoint-cost-pv": { 684 "uri": "http://alto.exmaple.com/endpointcost/pv", 685 "media-type": `multipart/related; 686 type=application/alto-endpointcost+json`, 687 "accepts": "application/alto-endpointcostparams+json", 688 "capabilities": { 689 "cost-type-names": [ "pv-maxresbw" ] 690 } 691 }, 692 "update-pv": { 693 "uri": "http://alto.example.com/updates/pv", 694 "media-type": "text/event-stream", 695 "uses": [ "endpoint-cost-pv" ], 696 "accepts": "application/alto-updatestreamparams+json", 697 "capabilities": { 698 "support-stream-control": true 699 } 700 } 701 } 702 } 704 9.2. Example #1 706 Query filtered cost map to get the path vectors. 708 POST /costmap/pv HTTP/1.1 709 Host: alto.example.com 710 Accept: multipart/related; 711 type=application/alto-costmap+json, 712 application/alto-error+json 713 Content-Length: [TBD] 714 Content-Type: application/alto-costmapfilter+json 716 { 717 "cost-type": { 718 "cost-mode": "path-vector", 719 "cost-metric": "maxresbw" 720 }, 721 "pids": { 722 "srcs": [ "PID1" ], 723 "dsts": [ "PID2", "PID3" ] 724 } 725 } 727 HTTP/1.1 200 OK 728 Content-Length: [TBD] 729 Content-Type: multipart/related; boundary=example-1; 730 start=cost-map-pv.costmap 731 type=application/alto-costmap+json 733 --example-1 734 Resource-Id: cost-map-pv.costmap 735 Content-Type: application/alto-costmap+json 737 { 738 "meta": { 739 "vtag": { 740 "resource-id": "cost-map-pv.costmap", 741 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 742 }, 743 "dependent-vtags": [ 744 { 745 "resource-id": "my-default-networkmap", 746 "tag": "75ed013b3cb58f896e839582504f6228" 747 } 748 ], 749 "cost-type": { 750 "cost-mode": "path-vector", 751 "cost-metric": "maxresbw" 753 } 754 }, 755 "cost-map": { 756 "PID1": { 757 "PID2": [ "ane:L001", "ane:L003" ], 758 "PID3": [ "ane:L001", "ane:L004" ] 759 } 760 } 761 } 762 --example-1 763 Resource-Id: cost-map-pv.propmap 764 Content-Type: application/alto-propmap+json 766 { 767 "meta": { 768 "dependent-vtags": [ 769 { 770 "resource-id": "cost-map-pv.costmap", 771 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 772 } 773 ] 774 }, 775 "property-map": { 776 "ane:L001": { "maxresbw": 100000000}, 777 "ane:L003": { "maxresbw": 150000000}, 778 "ane:L004": { "maxresbw": 50000000} 779 } 780 } 782 9.3. Example #2 783 POST /endpointcost/pv HTTP/1.1 784 Host: alto.example.com 785 Accept: multipart/related; 786 type=application/alto-endpointcost+json, 787 application/alto-error+json 788 Content-Length: [TBD] 789 Content-Type: application/alto-endpointcostparams+json 791 { 792 "cost-type": { 793 "cost-mode": "path-vector", 794 "cost-metric": "maxresbw" 795 }, 796 "endpoints": { 797 "srcs": [ "ipv4:192.0.2.2" ], 798 "dsts": [ "ipv4:192.0.2.89", 799 "ipv4:203.0.113.45", 800 "ipv6:2001:db8::10" ] 801 } 802 } 804 HTTP/1.1 200 OK 805 Content-Length: [TBD] 806 Content-Type: multipart/related; boundary=example-2; 807 start=endpoint-cost-pv.ecs 808 type=application/alto-endpointcost+json 810 --example-2 811 Resource-Id: endpoint-cost-pv.ecs 812 Content-Type: application/alto-endpointcost+json 814 { 815 "meta": { 816 "vtags": { 817 "resource-id": "endpoint-cost-pv.ecs", 818 "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef" 819 }, 820 "cost-type": { 821 "cost-mode": "path-vector", 822 "cost-metric": "maxresbw" 823 } 824 }, 825 "endpoint-cost-map": { 826 "ipv4:192.0.2.2": { 827 "ipv4:192.0.2.89": [ "ane:L001", "ane:L003", 828 "ane:L004" ], 829 "ipv4:203.0.113.45": [ "ane:L001", "ane:L004", 830 "ane:L005" ], 832 "ipv6:2001:db8::10": [ "ane:L001", "ane:L005", 833 "ane:L007" ] 834 } 835 } 836 } 837 --example-2 838 Resource-Id: endpoint-cost-pv.propmap 839 Content-Type: application/alto-propmap+json 841 { 842 "meta": { 843 "dependent-vtags": [ 844 { 845 "resource-id": "endpoint-cost-pv.ecs", 846 "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef" 847 } 848 ] 849 }, 850 "property-map": { 851 "ane:L001": { "maxresbw": 50000000 }, 852 "ane:L003": { "maxresbw": 48000000 }, 853 "ane:L004": { "maxresbw": 55000000 }, 854 "ane:L005": { "maxresbw": 60000000 }, 855 "ane:L007": { "maxresbw": 35000000 } 856 } 857 } 859 9.4. Example for Incremental Update 861 In this example, an ALTO client subscribe the incremental update for 862 the Multipart Endpoint Cost resource "endpoint-cost-pv". 864 POST /updates/pv HTTP/1.1 865 Host: alto.example.com 866 Accept: text/event-stream 867 Content-Type: application/alto-updatestreamparams+json 868 Content-Length: [TBD] 870 { 871 "add": { 872 "ecspvsub1": { 873 "resource-id": "endpoint-cost-pv", 874 "input": 875 } 876 } 877 } 878 Based on the server process defined in 879 [I-D.ietf-alto-incr-update-sse], the ALTO server will send the 880 control-uri first using Server-Sent Event (SSE), and follow the full 881 response of the multipart message. 883 HTTP/1.1 200 OK 884 Connection: keep-alive 885 Content-Type: text/event-stream 887 event: application/alto-updatestreamcontrol+json 888 data: {"control-uri": "http://alto.example.com/updates/streams/1414"} 890 event: multipart/related;boundary=example-3;start=pvmap; 891 type=application/alto-endpointcost+json,ecspvsub1 892 data: --example-3 893 data: Content-ID: pvmap 894 data: Content-Type: application/alto-endpointcost+json 895 data: 896 data: 897 data: --example-3 898 data: Content-ID: nepmap 899 data: Content-Type: application/alto-propmap+json 900 data: 901 data: 902 data: --example-3-- 904 Then, the ALTO server will subscribe the whole tree of the multipart 905 message automatically. 907 When the data updated, the ALTO server will publish the data updates 908 for each node in this tree separately. 910 event: application/merge-patch+json,ecspvsub1.pvmap 911 data: 913 event: application/merge-patch+json,ecspvsub2.nepmap 914 data: 916 10. Compatibility 918 10.1. Compatibility with Base ALTO Clients/Servers 920 The Multipart Filtered Cost Map resource and the Multipart Endpoint 921 Cost resource has no backward compatibility issue with the base ALTO 922 clients and servers. Although these two types of resources reuse the 923 media types defined in the base ALTO protocol for the accept input 924 parameters, they have different media types for responses. If the 925 ALTO server provides these two types of resources, but the ALTO 926 client does not support them, the ALTO client will ignore the 927 resources without conducting any incompatibility. 929 10.2. Compatibility with Multi-Cost Extension 931 This document does not specify how to integrate the "path-vector" 932 cost mode with the multi-cost extension [RFC8189]. Although there is 933 no reason why somebody has to compound the path vectors with other 934 cost types in a single query, there is no compatible issue doing it 935 without constraint tests. 937 10.3. Compatibility with Incremental Update 939 As this document still follows the basic request/response protocol 940 with JSON encoding, it is surely compatible with the incremental 941 update service as defined by [I-D.ietf-alto-incr-update-sse]. But 942 the following details are to be noticed: 944 o When using the compound response, updates on both cost map and 945 property map SHOULD be notified. 947 o When not using the compound response, because the cost map is in 948 the "uses" attribute of the property map, once the path vectors in 949 the cost map change, the ALTO server MUST send the updates of the 950 cost map before the updates of the property map. 952 11. General Discussions 954 11.1. Provide Calendar for Property Map 956 Fetching the historical network information is useful for many 957 traffic optimization problem. [I-D.ietf-alto-cost-calendar] already 958 proposes an ALTO extension called Cost Calendar which provides the 959 historical cost values using Filtered Cost Map and Endpoint Cost 960 Service. However, the calendar for only path costs is not enough. 962 For example, as the properties of ANEs (e.g., available bandwidth and 963 link delay) are usually the real-time network states, they change 964 frequently in the real network. It is very helpful to get the 965 historical value of these properties. Applications may predicate the 966 network status using these information to better optimize their 967 performance. 969 So the coming requirement may be a general calendar service for the 970 ALTO information resources. 972 11.2. Constraint Tests for General Cost Types 974 The constraint test is a simple approach to query the data. It 975 allows users to filter the query result by specifying some boolean 976 tests. This approach is already used in the ALTO protocol. 977 [RFC7285] and [RFC8189] allow ALTO clients to specify the 978 "constraints" and "or-constraints" tests to better filter the result. 980 However, the current defined syntax is too simple and can only be 981 used to test the scalar cost value. For more complex cost types, 982 like the "array" mode defined in this document, it does not work 983 well. It will be helpful to propose more general constraint tests to 984 better perform the query. 986 In practice, it is too complex to customize a language for the 987 general-purpose boolean tests, and can be a duplicated work. So it 988 may be a good idea to integrate some already defined and widely used 989 query languages (or their subset) to solve this problem. The 990 candidates can be XQuery and JSONiq. 992 11.3. General Multipart Resources Query 994 Querying multiple ALTO information resources continuously MAY be a 995 general requirement. And the coming issues like inefficiency and 996 inconsistency are also general. There is no standard solving these 997 issues yet. So we need some approach to make the ALTO client request 998 the compound ALTO information resources in a single query. 1000 12. Security Considerations 1002 This document is an extension of the base ALTO protocol, so the 1003 Security Considerations [RFC7285] of the base ALTO protocol fully 1004 apply when this extension is provided by an ALTO server. 1006 The path vector extension requires additional considerations on two 1007 security considerations discussed in the base protocol: 1008 confidentiality of ALTO information (Section 15.3 of [RFC7285]) and 1009 availability of ALTO service (Section 15.5 of [RFC7285]). 1011 For confidentiality of ALTO information, a network operator should be 1012 aware of that this extension may introduce a new risk: the path 1013 vector information may make network attacks easier. For example, as 1014 the path vector information may reveal more network internal 1015 structures than the more abstract single-node abstraction, an ALTO 1016 client may detect the bottleneck link and start a distributed denial- 1017 of-service (DDoS) attack involving minimal flows to conduct the in- 1018 network congestion. 1020 To mitigate this risk, the ALTO server should consider protection 1021 mechanisms to reduce information exposure or obfuscate the real 1022 information, in particular, in settings where the network and the 1023 application do not belong to the same trust domain. But the 1024 implementation of path vector extension involving reduction or 1025 obfuscation should guarantees the constraints on the requested 1026 properties are still accurate. 1028 For availability of ALTO service, an ALTO server should be cognizant 1029 that using path vector extension might have a new risk: frequent 1030 requesting for path vectors might conduct intolerable increment of 1031 the server-side storage and break the ALTO server. It is known that 1032 the computation of path vectors is unlikely to be cacheable, in that 1033 the results will depend on the particular requests (e.g., where the 1034 flows are distributed). Hence, the service providing path vectors 1035 may become an entry point for denial-of-service attacks on the 1036 availability of an ALTO server. To avoid this risk, authenticity and 1037 authorization of this ALTO service may need to be better protected. 1039 Even if there is no intentional attack, the dependent property map of 1040 path vector might be still dynamically enriched, in that every new 1041 request for path vectors will make the ALTO server generate a new 1042 property map. So the properties of the abstract network elements can 1043 consume a large amount of resources when cached. To avoid this, the 1044 ALTO server providing the path vector extension should support a 1045 time-to-live configuration for the property map, so that the outdated 1046 entries can be removed from the property map resource. 1048 13. IANA Considerations 1050 13.1. ALTO Cost Mode Registry 1052 This document specifies a new cost mode "path-vector". However, the 1053 base ALTO protocol does not have a Cost Mode Registry where new cost 1054 mode can be registered. This new cost mode will be registered once 1055 the registry is defined either in a revised version of [RFC7285] or 1056 in another future extension. 1058 13.2. ALTO Entity Domain Registry 1060 As proposed in Section 9.2 of [I-D.ietf-alto-unified-props-new], 1061 "ALTO Domain Entity Registry" is requested. Besides, a new domain is 1062 to be registered, listed in Table 1. 1064 +-------------+--------------------------+--------------------------+ 1065 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1066 +-------------+--------------------------+--------------------------+ 1067 | ane | See Section 6.2 | None | 1068 +-------------+--------------------------+--------------------------+ 1070 Table 1: ALTO Entity Domain 1072 13.3. ALTO Property Type Registry 1074 The "ALTO Property Type Registry" is required by the ALTO Domain 1075 "ane", listed in Table 2. 1077 +-------------+------------+----------------------------------------+ 1078 | Identifier | Intended | Dependencies and Interpretation | 1079 | | Semantics | | 1080 +-------------+------------+----------------------------------------+ 1081 | ane:maxresb | The | application/alto-costmap+json, or | 1082 | w | maximum | application/alto-endpointcostmap+json, | 1083 | | reservable | where the ANE names are used. | 1084 | | bandwidth | | 1085 | | for the | | 1086 | | ANE | | 1087 +-------------+------------+----------------------------------------+ 1089 Table 2: ALTO Abstract Network Element Property Types 1091 14. Acknowledgments 1093 The authors would like to thank discussions with Andreas Voellmy, 1094 Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan 1095 Liu, Xiao Shi, Xin Wang, and Yan Luo. The authors thank Greg 1096 Bernstein (Grotto Networks), Dawn Chen (Tongji University), Wendy 1097 Roome, and Michael Scharf for their contributions to earlier drafts. 1099 15. References 1101 15.1. Normative References 1103 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1104 Requirement Levels", BCP 14, RFC 2119, 1105 DOI 10.17487/RFC2119, March 1997, 1106 . 1108 15.2. Informative References 1110 [I-D.bernstein-alto-topo] 1111 Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology 1112 Service: Uses Cases, Requirements, and Framework", draft- 1113 bernstein-alto-topo-00 (work in progress), October 2013. 1115 [I-D.ietf-alto-cost-calendar] 1116 Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. 1117 Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- 1118 calendar-01 (work in progress), February 2017. 1120 [I-D.ietf-alto-incr-update-sse] 1121 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1122 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 1123 sse-16 (work in progress), March 2019. 1125 [I-D.ietf-alto-performance-metrics] 1126 Wu, Q., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, 1127 "ALTO Performance Cost Metrics", draft-ietf-alto- 1128 performance-metrics-06 (work in progress), November 2018. 1130 [I-D.ietf-alto-unified-props-new] 1131 Roome, W., Randriamasy, S., Yang, Y., and J. Zhang, 1132 "Unified Properties for the ALTO Protocol", draft-ietf- 1133 alto-unified-props-new-07 (work in progress), March 2019. 1135 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 1136 RFC 2387, DOI 10.17487/RFC2387, August 1998, 1137 . 1139 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1140 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1141 "Application-Layer Traffic Optimization (ALTO) Protocol", 1142 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1143 . 1145 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1146 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1147 DOI 10.17487/RFC8189, October 2017, 1148 . 1150 Authors' Addresses 1151 Kai Gao 1152 Tsinghua University 1153 Beijing Beijing 1154 China 1156 Email: gaok12@mails.tsinghua.edu.cn 1158 Young Lee 1159 Huawei 1160 TX 1161 USA 1163 Email: leeyoung@huawei.com 1165 Sabine Randriamasy 1166 Nokia Bell Labs 1167 Route de Villejust 1168 NOZAY 91460 1169 FRANCE 1171 Email: Sabine.Randriamasy@nokia-bell-labs.com 1173 Y. Richard Yang 1174 Yale University 1175 51 Prospect St 1176 New Haven CT 1177 USA 1179 Email: yry@cs.yale.edu 1181 Jingxuan Jensen Zhang 1182 Tongji University 1183 4800 Caoan Road 1184 Shanghai 201804 1185 China 1187 Email: jingxuan.n.zhang@gmail.com