idnits 2.17.1 draft-ietf-alto-path-vector-11.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], [I-D.ietf-alto-unified-props-new]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'not RECOMMENDED' in this paragraph: This document does not specify how to integrate the Path Vector cost type with the multi-cost extension [RFC8189]. While it is not RECOMMENDED to put the Path Vector cost type with other cost types in a single query, there is no compatible issue. -- The document date (14 July 2020) is 1354 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: 'ANEName' is mentioned on line 554, but not defined == Missing Reference: 'TBD' is mentioned on line 1551, but not defined == Unused Reference: 'TON2019' is defined on line 1889, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-alto-performance-metrics-11 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-11 == Outdated reference: A later version (-10) exists of draft-contreras-alto-service-edge-00 == Outdated reference: A later version (-05) exists of draft-huang-alto-mowie-for-network-aware-app-00 == Outdated reference: A later version (-04) exists of draft-ietf-dmm-5g-uplane-analysis-03 == Outdated reference: A later version (-03) exists of draft-yang-alto-deliver-functions-over-networks-01 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO K. Gao 3 Internet-Draft Sichuan University 4 Intended status: Standards Track Y. Lee 5 Expires: 15 January 2021 6 S. Randriamasy 7 Nokia Bell Labs 8 Y.R. Yang 9 Yale University 10 J. Zhang 11 Tongji University 12 14 July 2020 14 ALTO Extension: Path Vector 15 draft-ietf-alto-path-vector-11 17 Abstract 19 This document is an extension to the base Application-Layer Traffic 20 Optimization protocol [RFC7285]. The current ALTO Cost Services only 21 allow applications to obtain cost values on an end-to-end path 22 defined by its source and destination. The present extension 23 provides abstracted information on particular network components or 24 elements traversed by a path between its source and destination. 25 Examples of such abstracted components are networks, data centers or 26 links. This is useful for applications whose performance is impacted 27 by particular network components they traverse or by their 28 properties. Applications having the choice among several connection 29 paths may use this information to select paths accordingly and 30 improve their performance. In particular, they may infer that 31 several paths share common links and prevent traffic bottlenecks by 32 avoiding such paths. This document introduces a new cost type called 33 Path Vector. A Path Vector is an array of entities that each 34 identifies an abstracted representation of a network part and that 35 are called Abstract Network Element (ANE). Each ANE is defined by a 36 set of properties. ANE properties are conveyed by an ALTO 37 information resource called "Property Map", that can be packed 38 together with the Path Vectors in a multipart response. They can 39 also be obtained via a separate ALTO request to a Property Map. An 40 ALTO Property Map is an extension to the ALTO protocol, that is 41 specified in another document entitled "Unified Properties for the 42 ALTO Protocol" [I-D.ietf-alto-unified-props-new]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on 15 January 2021. 61 Copyright Notice 63 Copyright (c) 2020 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Simplified BSD License text 72 as described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Requirements Languages . . . . . . . . . . . . . . . . . . . 6 79 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 81 4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 7 82 4.2. Recent Use Cases . . . . . . . . . . . . . . . . . . . . 9 83 4.2.1. Large-scale Data Analytics . . . . . . . . . . . . . 9 84 4.2.2. Context-aware Data Transfer . . . . . . . . . . . . . 10 85 4.2.3. CDN and Service Edge . . . . . . . . . . . . . . . . 10 86 5. Path Vector Extension: Overview . . . . . . . . . . . . . . . 10 87 5.1. Abstract Network Element . . . . . . . . . . . . . . . . 11 88 5.1.1. ANE Domain . . . . . . . . . . . . . . . . . . . . . 11 89 5.1.2. Ephemeral ANE and Persistent ANE . . . . . . . . . . 11 90 5.1.3. Property Filtering . . . . . . . . . . . . . . . . . 12 91 5.2. Path Vector Cost Type . . . . . . . . . . . . . . . . . . 12 92 5.3. Multipart Path Vector Response . . . . . . . . . . . . . 13 93 5.3.1. Identifying the Media Type of the Root Object . . . . 14 94 5.3.2. References to Part Messages . . . . . . . . . . . . . 14 95 5.3.3. Order of Part Messages . . . . . . . . . . . . . . . 15 96 6. Specification: Basic Data Types . . . . . . . . . . . . . . . 15 97 6.1. ANE Name . . . . . . . . . . . . . . . . . . . . . . . . 15 98 6.2. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 15 99 6.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 16 100 6.2.2. Entity Identifier Encoding . . . . . . . . . . . . . 16 101 6.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 16 102 6.2.4. Media Type of Defining Resource . . . . . . . . . . . 16 103 6.3. ANE Property Name . . . . . . . . . . . . . . . . . . . . 16 104 6.4. Initial ANE Property Types . . . . . . . . . . . . . . . 16 105 6.4.1. New ANE Property Type: Maximum Reservable 106 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 17 107 6.4.2. New ANE Property Type: Persistent Entity ID . . . . . 18 108 6.5. Path Vector Cost Type . . . . . . . . . . . . . . . . . . 18 109 6.5.1. Cost Metric: ane-path . . . . . . . . . . . . . . . . 18 110 6.5.2. Cost Mode: array . . . . . . . . . . . . . . . . . . 19 111 6.6. Part Resource ID . . . . . . . . . . . . . . . . . . . . 19 112 7. Specification: Service Extensions . . . . . . . . . . . . . . 19 113 7.1. Multipart Filtered Cost Map for Path Vector . . . . . . . 19 114 7.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 19 115 7.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 19 116 7.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 20 117 7.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . 21 118 7.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 21 119 7.1.6. Response . . . . . . . . . . . . . . . . . . . . . . 21 120 7.2. Multipart Endpoint Cost Service for Path Vector . . . . . 25 121 7.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 25 122 7.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 25 123 7.2.3. Accept Input Parameters . . . . . . . . . . . . . . . 25 124 7.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 26 125 7.2.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 26 126 7.2.6. Response . . . . . . . . . . . . . . . . . . . . . . 26 127 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29 128 8.1. Example: Information Resource Directory . . . . . . . . . 29 129 8.2. Example: Multipart Filtered Cost Map . . . . . . . . . . 31 130 8.3. Example: Multipart Endpoint Cost Resource . . . . . . . . 32 131 8.4. Example: Incremental Updates . . . . . . . . . . . . . . 35 132 9. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 36 133 9.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 36 134 9.2. Compatibility with Multi-Cost Extension . . . . . . . . . 36 135 9.3. Compatibility with Incremental Update . . . . . . . . . . 36 136 9.4. Compatibility with Cost Calendar . . . . . . . . . . . . 36 137 10. General Discussions . . . . . . . . . . . . . . . . . . . . . 37 138 10.1. Constraint Tests for General Cost Types . . . . . . . . 37 139 10.2. General Multipart Resources Query . . . . . . . . . . . 37 140 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 141 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 142 12.1. ALTO Entity Domain Registry . . . . . . . . . . . . . . 38 143 12.2. ALTO Entity Property Type Registry . . . . . . . . . . . 39 144 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 145 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 146 14.1. Normative References . . . . . . . . . . . . . . . . . . 40 147 14.2. Informative References . . . . . . . . . . . . . . . . . 41 148 Appendix A. Changes since -10 . . . . . . . . . . . . . . . . . 42 149 Appendix B. Changes since -09 . . . . . . . . . . . . . . . . . 43 150 Appendix C. Changes since -08 . . . . . . . . . . . . . . . . . 43 151 Appendix D. Changes Since Version -06 . . . . . . . . . . . . . 43 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 154 1. Introduction 156 Network performance metrics are crucial to the Quality of Experience 157 (QoE) of today's applications. The ALTO protocol allows Internet 158 Service Providers (ISPs) to provide guidance, such as topological 159 distance between different end hosts, to overlay applications. Thus, 160 the overlay applications can potentially improve the QoE by better 161 orchestrating their traffic to utilize the resources in the 162 underlying network infrastructure. 164 Existing ALTO Cost Map and Endpoint Cost Service provide only cost 165 information on an end-to-end path defined by its endpoints: The base protocol [RFC7285] allows the 167 services to expose the topological distances of end-to-end paths, 168 while various extensions have been proposed to extend the capability 169 of these services, e.g., to express other performance metrics 170 [I-D.ietf-alto-performance-metrics], to query multiple costs 171 simultaneously [RFC8189], and to obtain the time-varying values 172 [I-D.ietf-alto-cost-calendar]. 174 While the existing extensions are sufficient for many overlay 175 applications, however, the QoE of some overlay applications depends 176 not only on the cost information of end-to-end paths, but also on 177 some intermediate network components and their properties. For 178 example, job completion time, which is an important QoE metric for a 179 large-scale data analytics application, is impacted by shared 180 bottlenecks inside the carrier network. 182 Predicting such information can be very complex without the help of 183 the ISP [AAAI2019]. With proper guidance from the ISP, an overlay 184 application may be able to schedule its traffic for better QoE. In 185 the meantime, it may be helpful as well for ISPs if applications 186 could avoid using bottlenecks or challenging the network with poorly 187 scheduled traffic. 189 Despite the benefits, ISPs are not likely to expose details on their 190 network paths: first for the sake of confidentiality, second because 191 it may result in a huge volume and overhead, and last because it is 192 difficult for ISPs to figure out what information and what details an 193 application needs. Likewise, applications do not necessarily need 194 all the network path details and are likely not able to understand 195 them. 197 Therefore, it is beneficial for both parties if an ALTO server 198 provides ALTO clients with an "abstract network state" that provides 199 the necessary details to applications, while hiding the network 200 complexity and confidential information. An "abstract network state" 201 is a selected set of abstract representations of intermediate network 202 components traversed by the paths between pairs 203 combined with properties of these components that are relevant to the 204 overlay applications' QoE. Both an application via its ALTO client 205 and the ISP via the ALTO server can achieve better confidentiality 206 and resource utilization by appropriately abstracting relevant path 207 components. The pressure on the server scalability can also be 208 reduced by abstracting components and their properties and combining 209 them in a single response. 211 This document extends [RFC7285] to allow an ALTO server convey 212 "abstract network state", for paths defined by their pairs. To this end, it introduces a new cost type 214 called "Path Vector". A Path Vector is an array of identifiers of 215 so-called Abstract Network Element (ANE). An ANE represents an 216 abstract intermediate component traversed by a path. It can be 217 associated with various properties. The associations between ANEs 218 and their properties are encoded in an ALTO information resource 219 called Unified Property Map, which is specified in 220 [I-D.ietf-alto-unified-props-new]. 222 For better confidentiality, this document aims to minimize 223 information exposure. In particular, this document enables and 224 recommends that first ANEs are constructed on demand, and second an 225 ANE is only associated with properties that are requested by an ALTO 226 client. A Path Vector response involved two ALTO Maps: the Cost Map 227 that contains the Path Vector results and the up-to-date Unified 228 Property Map that contains the properties requested for these ANEs. 229 To enforce consistency and improve server scalability, this document 230 uses the "multipart/related" message defined in [RFC2387] to return 231 the two maps in a single response. 233 The rest of the document are organized as follows. Section 3 234 introduces the extra terminologies that are used in this document. 235 Section 4 uses an illustrative example to introduce the additional 236 requirements of the ALTO framework, and discusses potential use 237 cases. Section 5 gives an overview of the protocol design. 238 Section 6 and Section 7 specify the Path Vector extension to the ALTO 239 IRD and the information resources, with some concrete examples 240 presented in Section 8. Section 9 discusses the backward 241 compatibility with the base protocol and existing extensions. 242 Security and IANA considerations are discussed in Section 11 and 243 Section 12 respectively. 245 2. Requirements Languages 247 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 248 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 249 "OPTIONAL" in this document are to be interpreted as described in BCP 250 14 [RFC2119] [RFC8174] when, and only when, they appear in all 251 capitals, as shown here. 253 When the words appear in lower case, they are to be interpreted with 254 their natural language meanings. 256 3. Terminology 258 This document extends the ALTO base protocol [RFC7285] and the 259 Unified Property Map extension [I-D.ietf-alto-unified-props-new]. In 260 addition to the terms defined in these documents, this document also 261 uses the following additional terms: 263 * Abstract Network Element (ANE): An Abstract Network Element is a 264 representation of network components. It can be a link, a 265 middlebox, a virtualized network function (VNF), etc., or their 266 aggregations. An ANE can be constructed either statically in 267 advance or on demand based on the requested information. In a 268 response, each ANE is represented by a unique ANE Name. Note that 269 an ALTO client must not assume ANEs in different responses but 270 with the same ANE Name refer to the same network component(s). 272 * Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array 273 of ANE Names. It conveys the information that the path between a 274 source and a destination traverses the ANEs in the same order as 275 they appear in the Path Vector. 277 * Path Vector resource: A Path Vector resource refers to an ALTO 278 resource which supports the extension defined in this document. 280 * Path Vector cost type: The Path Vector cost type is a special cost 281 type, which is specified in Section 6.5. When this cost type is 282 present in an IRD entry, it indicates that the information 283 resource is a Path Vector resource. When this cost type is 284 present in a Cost Map or an Endpoint Cost Map, it indicates each 285 cost value must be interpreted as a Path Vector. 287 * Path Vector request: A Path Vector request refers to the POST 288 message sent to an ALTO Path Vector resource. 290 * Path Vector response: A Path Vector response refers to the 291 multipart/related message returned by a Path Vector resource. 293 4. Problem Statement 295 4.1. Design Requirements 297 This section gives an illustrative example of how an overlay 298 application can benefit from the Path Vector extension. 300 Assume that an application has control over a set of flows, which may 301 go through shared links or switches and share a bottleneck. The 302 application hopes to schedule the traffic among multiple flows to get 303 better performance. The capacity region information for those flows 304 will benefit the scheduling. However, existing cost maps can not 305 reveal such information. 307 Specifically, consider a network as shown in Figure 1. The network 308 has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches 309 sw1/sw3 provide access on one side, sw2/sw4 provide access on the 310 other side, and sw5-sw7 form the backbone. Endhosts eh1 to eh4 are 311 connected to access switches sw1 to sw4 respectively. Assume that 312 the bandwidth of link eh1 -> sw1 and link sw1 -> sw5 are 150 Mbps, 313 and the bandwidth of the rest links are 100 Mbps. 315 +------+ 316 | | 317 --+ sw6 +-- 318 / | | \ 319 PID1 +-----+ / +------+ \ +-----+ PID2 320 eh1__| |_ / \ ____| |__eh2 321 1.2.3.4 | sw1 | \ +--|---+ +---|--+ / | sw2 | 2.3.4.5 322 +-----+ \ | | | |/ +-----+ 323 \_| sw5 +---------+ sw7 | 324 PID3 +-----+ / | | | |\ +-----+ PID4 325 eh3__| |__/ +------+ +------+ \____| |__eh4 326 3.4.5.6 | sw3 | | sw4 | 4.5.6.7 327 +-----+ +-----+ 329 Figure 1: Raw Network Topology 331 The single-node ALTO topology abstraction of the network is shown in 332 Figure 2. 334 +----------------------+ 335 {eh1} | | {eh2} 336 PID1 | | PID2 337 +------+ +------+ 338 | | 339 | | 340 {eh3} | | {eh4} 341 PID3 | | PID4 342 +------+ +------+ 343 | | 344 +----------------------+ 346 Figure 2: Base Single-Node Topology Abstraction 348 Consider an application overlay (e.g., a large-scale data analytics 349 system) which wants to optimize the total throughput of the traffic 350 among a set of end host pairs, say eh1 -> eh2 351 and eh1 -> eh4. The application can request a cost map providing 352 end-to-end available bandwidth, using "availbw" as cost-metric and 353 "numerical" as cost-mode. 355 The application will receive from the ALTO server that the bandwidth 356 of eh1 -> eh2 and eh1 -> eh4 are both 100 Mbps. But this information 357 is not enough to determine the optimal total throughput. Consider 358 the following two cases: 360 * Case 1: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw6 -> 361 sw7 -> sw2 -> eh2 and eh1 -> eh4 uses path eh1 -> sw1 -> sw5 -> 362 sw7 -> sw4 -> eh4, then the application will obtain 150 Mbps at 363 most. 365 * Case 2: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw7 -> 366 sw2 -> eh2 and eh1 -> eh4 uses the path eh1 -> sw1 -> sw5 -> sw7 367 -> sw4 -> eh4, then the application will obtain only 100 Mbps at 368 most. 370 To allow applications to distinguish the two aforementioned cases, 371 the network needs to provide more details. In particular: 373 * For eh1 -> eh2, the ALTO server must give more details which is 374 critical for the overlay application to distinguish between Case 1 375 and Case 2 and to compute the optimal total throughput 376 accordingly. 378 * The ALTO server must allow the client to distinguish the common 379 network components shared by eh1 -> eh2 and eh1 -> eh4, e.g., eh1 380 - sw1 and sw1 - sw5 in Case 1. 382 * The ALTO server must give details on the properties of the network 383 components used by eh1 -> eh2 and eh1 -> eh4, e.g., the available 384 bandwidth between eh1 - sw1, sw1 - sw5, sw5 - sw7, sw5 - sw6, sw6 385 - sw7, sw7 - sw2, sw7 - sw4, sw2 - eh2, sw4 - eh4 in Case 1. 387 In general, we can conclude that to support the multiple flow 388 scheduling use case, the ALTO framework must be extended to satisfy 389 the following additional requirements: 391 AR1: An ALTO server must provide essential information on 392 intermediate network components on the path of a pair that are critical to the QoE of the overlay 394 application. 396 AR2: An ALTO server must provide essential information on how the 397 paths of different pairs share a common 398 network component. 400 AR3: An ALTO server must provide essential information on the 401 properties associated to the network components. 403 The Path Vector extension defined in this document propose a solution 404 to provide these details. 406 4.2. Recent Use Cases 408 While the multiple flow scheduling problem is used to help identify 409 the additional requirements, the Path Vector extension can be applied 410 to a wide range of applications. This section highlights some real 411 use cases that are recently reported. See [I-D.bernstein-alto-topo] 412 for a more comprehensive survey of use cases where extended network 413 topology information is needed. 415 4.2.1. Large-scale Data Analytics 417 One potential use case of the Path Vector extension is for large- 418 scale data analytics such as [SENSE] and [LHC], where data of 419 Gigabytes, Terabytes and even Petabytes are transferred. For these 420 applications, the QoE is usually measured as the job completion time, 421 which is related to the completion time of the slowest data transfer. 422 With the Path Vector extension, an ALTO client can identify 423 bottlenecks inside the network. Therefore, the overlay application 424 can make optimal traffic distribution or resource reservation (i.e., 425 proportional to the size of the transferred data), leading to optimal 426 job completion time and network resource utilization. 428 4.2.2. Context-aware Data Transfer 430 It is sometimes important to know how the capabilities of various 431 network components between two end hosts, especially in the mobile 432 environment. With the Path Vector extension, an ALTO client may 433 query the "network context" information, i.e., whether the two hosts 434 are connected to the access network through a wireless link or a 435 wire, and the capabilities of the access network. Thus, the client 436 may use different data transfer mechanisms, or even deploy different 437 5G User Plane Functions (UPF) [I-D.ietf-dmm-5g-uplane-analysis] to 438 optimize the data transfer. 440 4.2.3. CDN and Service Edge 442 A growing trend in today's applications is to bring storage and 443 computation closer to the end user for better QoE, such as Content 444 Delivery Network (CDN), AR/VR, and cloud gaming, as reported in 445 various recent documents ([I-D.contreras-alto-service-edge], 446 [I-D.huang-alto-mowie-for-network-aware-app], and 447 [I-D.yang-alto-deliver-functions-over-networks]). 449 With the Path Vector extension, an ALTO server can selectively reveal 450 the CDNs and service edges that reside along the paths between 451 different end hosts, together with their properties such as available 452 Service Level Agreement (SLA) plans. Otherwise, the ALTO client may 453 have to make multiple queries and potentially with the complete list 454 of CDNs and/or service edges. While both approaches offer the same 455 information, making multiple queries introduces larger delay and more 456 overhead on both the ALTO server and the ALTO client. 458 5. Path Vector Extension: Overview 460 This section gives a non-normative overview of the Path Vector 461 extension. It is assumed that readers are familiar with both the 462 base protocol [RFC7285] and the Unified Property Map extension 463 [I-D.ietf-alto-unified-props-new]. 465 To satisfies the additional requirements, this extension: 467 1. introduces Abstract Network Element (ANE) as the abstraction of 468 intermediate network components, 470 2. extends the Cost Map and Endpoint Cost Service to convey the 471 intermediate network components traversed by the path of a 472 pair as Path Vectors, 474 3. uses the Unified Property Map to convey the association between 475 the intermediate network components and their properties. 477 Thus, an ALTO client can learn about the intermediate network 478 components that are critical to the QoE of a 479 pair by investigating the corresponding Path Vector value (AR1), 480 identify common network components if an ANE appears in the Path 481 Vectors of multiple pairs (AR2), and retrieve 482 the properties of the network components by searching the Unified 483 Property Map (AR3). 485 5.1. Abstract Network Element 487 This extension introduces Abstract Network Element (ANE) as an 488 indirect and network-agnostic way to specify an aggregation of 489 intermediate network components between a source and a destination. 490 Specifically, an ANE is a string of type ANEName as specified in 491 Section 6.1 and its associated set of properties. 493 5.1.1. ANE Domain 495 In this extension, the associations between ANE and the properties 496 are conveyed in a Unified Property Map. Thus, they must follow the 497 mechanisms specified in the [I-D.ietf-alto-unified-props-new]. 499 Specifically, this document defines a new entity domain called "ane" 500 as specified in Section 5.1.1 and defines two initial properties for 501 the "ane" domain. 503 5.1.2. Ephemeral ANE and Persistent ANE 505 For different requests, there can be different ways of grouping 506 network components and assigning ANEs. For example, an ALTO server 507 may define an ANE for each aggregated bottleneck link between the 508 sources and destinations specified in the request. As the aggregated 509 bottleneck links vary for different combinations of sources and 510 destinations, the ANEs are ephemeral and are no longer valid after 511 the request completes. Thus, the scope of ephemeral ANEs are limited 512 to the corresponding Path Vector response. 514 While ephemeral ANEs returned by a Path Vector response do not exist 515 beyond that response, some of them may represent entities that are 516 persistent and defined in a standalone Property Map. Indeed, it may 517 be useful for clients to occasionally query properties on persistent 518 entities, without caring about the path that traverses them. 519 Persistent entities have a persistent ID that is registered in a 520 Property Map, together with their properties. 522 5.1.3. Property Filtering 524 Resource-constrained ALTO clients may benefit from the filtering of 525 Path Vector query results at the ALTO server, as an ALTO client may 526 only require a subset of the available properties. 528 Specifically, the available properties for a given resource are 529 announced in the Information Resource Directory as a new capability 530 called "ane-property-names". The selected properties are specified 531 in a filter called "ane-property-names" in the request body, and the 532 response must return and only return the selected properties for the 533 ANEs in the response. 535 The "ane-property-names" capability for Cost Map and for Endpoint 536 Cost Service are specified in Section 7.1.4 and Section 7.2.4 537 respectively. The "ane-property-names" filter for Cost Map and 538 Endpoint Cost Service are specified in Section 7.1.3 and 539 Section 7.2.3 accordingly. 541 5.2. Path Vector Cost Type 543 For an ALTO client to correctly interpret the Path Vector, this 544 extension specifies a new cost type called the Path Vector cost type, 545 which must be included both in the Information Resource Directory and 546 the ALTO Cost Map or Endpoint Cost Map so that an ALTO client can 547 correct interpret the cost values. 549 The Path Vector cost type must convey both the interpretation and 550 semantics in the "cost-mode" and "cost-metric" respectively. 551 Unfortunately, a single "cost-mode" value cannot fully specify the 552 interpretation of a Path Vector, which is a compound data type. For 553 example, in programming languages such as Java, a Path Vector will 554 have the type of JSONArray[ANEName]. 556 Instead of extending the "type system" of ALTO, this document takes a 557 simple and backward compatible approach. Specifically, the "cost- 558 mode" of the Path Vector cost type is "array", which indicates the 559 value is a JSON array. Then, an ALTO client must check the value of 560 the "cost-metric". If the value is "ane-path", meaning the JSON 561 array should be further interpreted as a path of ANENames. 563 The Path Vector cost type is specified in Section 6.5. 565 5.3. Multipart Path Vector Response 567 For a basic ALTO information resource, a response contains only one 568 type of ALTO resources, e.g., Network Map, Cost Map, or Property Map. 569 Thus, only one round of communication is required: An ALTO client 570 sends a request to an ALTO server, and the ALTO server returns a 571 response, as shown in Figure 3. 573 ALTO client ALTO server 574 |-------------- Request ---------------->| 575 |<------------- Response ----------------| 577 Figure 3: A Typical ALTO Request and Response 579 The Path Vector extension, on the other hand, involves two types of 580 information resources: Path Vectors conveyed in a Cost Map or an 581 Endpoint Cost Map, and ANE properties conveyed in a Unified Property 582 Map. Instead of two consecutive message exchanges, the Path Vector 583 extension enforces one round of communication. Specifically, the 584 Path Vector extension requires the ALTO client to include the source 585 and destination pairs and the requested ANE properties in a single 586 request, and encapsulates both Path Vectors and properties associated 587 with the ANEs in a single response, as shown in Figure 4. 589 ALTO client ALTO server 590 |------------- PV Request -------------->| 591 |<----- PV Response (Cost Map Part) -----| 592 |<--- PV Response (Property Map Part) ---| 594 Figure 4: The Path Vector Extension Request and Response 596 This design is based on the following considerations: 598 1. Since ANEs may be constructed on demand, and potentially based on 599 the requested properties (See Section 5.1 for more details). If 600 sources and destinations are not in the same request as the 601 properties, an ALTO server either cannot construct ANEs on- 602 demand, or must wait until both requests are received. 604 2. As ANEs may be constructed on demand, mappings of each ANE to its 605 underlying network devices and resources can be specific to the 606 request. In order to respond to the Property Map request 607 correctly, an ALTO server must store the mapping of each Path 608 Vector request until the client fully retrieves the property 609 information. The "stateful" behavior may substantially harm the 610 server scalability and potentially lead to Denial-of-Service 611 attacks. 613 One approach to realize the one-round communication is to define a 614 new media type to contain both objects, but this violates modular 615 design. This document follows the standard-conforming usage of 616 "multipart/related" media type defined in [RFC2387] to elegantly 617 combine the objects. Path Vectors are encoded as a Cost Map or an 618 Endpoint Cost Map, and the Property Map is encoded as a Unified 619 Propert Map. They are encapsulated as parts of a multipart message. 620 The modular composition allows ALTO servers and clients to reuse the 621 data models of the existing information resources. Specifically, 622 this document addresses the following practical issues using 623 "multipart/related". 625 5.3.1. Identifying the Media Type of the Root Object 627 ALTO uses media type to indicate the type of an entry in the 628 Information Resource Directory (IRD) (e.g., "application/alto- 629 costmap+json" for Cost Map and "application/alto-endpointcost+json" 630 for Endpoint Cost Map). Simply putting "multipart/related" as the 631 media type, however, makes it impossible for an ALTO client to 632 identify the type of service provided by related entries. 634 To address this issue, this document uses the "type" parameter to 635 indicate the root object of a multipart/related message. For a Cost 636 Map resource, the "media-type" in the IRD entry must be "multipart/ 637 related" with the parameter "type=application/alto-costmap+json"; for 638 an Endpoint Cost Service, the parameter must be "type=application/ 639 alto-endpointcost+json". 641 5.3.2. References to Part Messages 643 The ALTO SSE extension (see [I-D.ietf-alto-incr-update-sse]) uses 644 "client-id" to demultiplex push updates. However, "client-id" is 645 provided for each request, which introduces ambiguity when applying 646 SSE to a Path Vector resource. 648 To address this issue, an ALTO server must assign a unique identifier 649 to each part of the "multipart/related" response message. This 650 identifier, referred to as a Part Resource ID (See Section 6.6 for 651 details), must be present in the part message's "Resource-Id" header. 652 The MIME part header must also contain the "Content-Type" header, 653 whose value is the media type of the part (e.g., "application/alto- 654 costmap+json", "application/alto-endpointcost+json", or "application/ 655 alto-propmap+json"). 657 If an ALTO server provides incremental updates for this Path Vector 658 resource, it must generate incremental updates for each part 659 separately. The client-id must have the following format: 661 pv-client-id '.' part-resource-id 663 where pv-client-id is the client-id assigned to the Path Vector 664 request, and part-resource-id is the "Resource-Id" header value of 665 the part. The media-type must match the "Content-Type" of the part. 667 The same problem applies to the part messages as well. The two parts 668 must contain a version tag, which SHOULD contain a unique Resource 669 ID. This document requires the resource-id in a Version Tag to have 670 the following format: 672 pv-resource-id '.' part-resource-id 674 where pv-resource-id is the resource ID of the Path Vector resource 675 in the IRD entry, and the part-resource-id has the same value as the 676 "Resource-Id" header of the part. 678 5.3.3. Order of Part Messages 680 According to [RFC2387], the Path Vector part, whose media type is the 681 same as the "type" parameter of the multipart response message, is 682 the root object. Thus, it is the element the application processes 683 first. Even though the "start" parameter allows it to be placed 684 anywhere in the part sequence, it is RECOMMENDED that the parts 685 arrive in the same order as they are processed, i.e., the Path Vector 686 part is always put as the first part, followed by the property map 687 part. It is also RECOMMENDED that when doing so, an ALTO server 688 SHOULD NOT set the "start" parameter, which implies the first part is 689 the root object. 691 6. Specification: Basic Data Types 693 6.1. ANE Name 695 An ANE Name is encoded as a JSON string with the same format as that 696 of the type PIDName (Section 10.1 of [RFC7285]). 698 The type ANEName is used in this document to indicate a string of 699 this format. 701 6.2. ANE Domain 703 The ANE domain associates property values with the Abstract Network 704 Elements in a Property Map. Accordingly, the ANE domain always 705 depends on a Property Map. 707 6.2.1. Entity Domain Type 709 ane 711 6.2.2. Entity Identifier Encoding 713 The entity identifier of the "ane" domain has the same format as 714 defined in Section 5.1.3 in [I-D.ietf-alto-unified-props-new], and 715 the DomainTypeSpecificEntityID part has the same format as the 716 ANEName type. 718 6.2.3. Hierarchy and Inheritance 720 There is no hierarchy or inheritance for properties associated with 721 ANEs. 723 6.2.4. Media Type of Defining Resource 725 When resource specific domains are defined with entities of domain 726 type "ane", the defining resource for entity domain type "ane" MUST 727 be a Property Map. The media type of defining resources for the "ane" 728 domain is: 730 application/alto-propmap+json 732 Specifically, the defining resource of ephemeral ANEs is the Property 733 Map part of the multipart response. The defining resource of 734 persistent ANEs is the Property Map on which standalone queries for 735 properties of persistent ANEs are made. 737 6.3. ANE Property Name 739 An ANE Property Name is encoded as a JSON string with the same format 740 as that of Entity Property Name (Section 5.2.2 of 741 [I-D.ietf-alto-unified-props-new]). 743 6.4. Initial ANE Property Types 745 In this document, two initial ANE property types are specified, "max- 746 reservable-bandwidth" and "persistent-entity-id". 748 Note that the two property types defined in this document do not 749 depend on any information resource, so their ResourceID part must be 750 empty. 752 ----- L1 753 / 754 PID1 +---------------+ 10 Gbps +----------+ PID3 755 1.2.3.0/24+---+ +-----------+ +---------+ +---+3.4.5.0/24 756 | | MEC1 | | | | 757 | +-----------+ | +-----+ | 758 PID2 | | | +----------+ 759 2.3.4.0/24+---+ | | NET3 760 | | | 15 Gbps 761 | | | \ 762 +---------------+ | -------- L2 763 NET1 | 764 +---------------+ 765 | +-----------+ | PID4 766 | | MEC2 | +---+4.5.6.0/24 767 | +-----------+ | 768 +---------------+ 769 NET2 771 Figure 5: Examples of ANE Properties 773 In this document, Figure 5 is used to illustrate the use of the two 774 initial ANE property types. There are 3 sub-networks (NET1, NET2 and 775 NET3) and two interconnection links (L1 and L2). It is assumed that 776 each sub-network has sufficiently large bandwidth to be reserved. 778 6.4.1. New ANE Property Type: Maximum Reservable Bandwidth 780 Identifier: "max-reservable-bandwidth" 782 Intended Semantics: The maximum reservable bandwidth property stands 783 for the maximum bandwidth that can be reserved for all the traffic 784 that traverses an ANE. The value MUST be encoded as a non- 785 negative numerical cost value as defined in Section 6.1.2.1 of 786 [RFC7285] and the unit is bit per second. If this property is 787 requested but not present in an ANE, it MUST be interpreted as 788 that the ANE does not support bandwidth reservation. 790 Security Considerations: ALTO entity properties expose information 791 to ALTO clients. ALTO service providers should be made aware of 792 the security ramifications related to the exposure of an entity 793 property. 795 To illustrate the use of "max-reservable-bandwidth", consider the 796 network in Figure 5. An ALTO server can create an ANE for each 797 interconnection link, where the initial value for "max-reservable- 798 bandwidth" is the link capacity. 800 6.4.2. New ANE Property Type: Persistent Entity ID 802 Identifier: "persistent-entity-id" 804 Intended Semantics: The persistent entity ID property is the entity 805 identifier of the persistent ANE associated with an ephemeral ANE. 806 The value of this property is encoded with the format defined in 807 Section 5.1.3 of [I-D.ietf-alto-unified-props-new]. In this 808 format, the entity ID combines: 810 * a defining information resource for the ANE on which a 811 "persistent-entity-id" is queried, which is the property map 812 defining the ANE as a persistent entity, together with the 813 properties 815 * the persistent name of the ANE in this property map 817 With this format, the client has all the needed information for 818 further standalone query properties on the persistent ANE. 820 Security Considerations: ALTO entity properties expose information 821 to ALTO clients. ALTO service providers should be made aware of 822 the security ramifications related to the exposure of an entity 823 property. 825 To illustrate the use of "persistent-entity-id", consider the network 826 in Figure 5. Assume the ALTO server has a Property Map resource 827 called "mec-props" that defines persistent ANEs "MEC1" and "MEC2" 828 that represent the corresponding mobile edge computing (MEC) 829 clusters. The "persistent-entity-id" of the ephemeral ANE that is 830 associated with MEC1 has the value "mec-props.ane:MEC1". 832 6.5. Path Vector Cost Type 834 This document defines a new cost type, which is referred to as the 835 "Path Vector" cost type. An ALTO server MUST offer this cost type if 836 it supports the Path Vector extension. 838 6.5.1. Cost Metric: ane-path 840 The cost metric "ane-path" indicates the value of such a cost type 841 conveys an array of ANE names, where each ANE name uniquely 842 represents an ANE traversed by traffic from a source to a 843 destination. 845 6.5.2. Cost Mode: array 847 The cost mode "array" indicates that every cost value in a Cost Map 848 or an Endpoint Cost Map MUST be interpreted as a JSON array object. 850 Note that this cost mode only requires the cost value to be a JSON 851 array of JSONValue. However, an ALTO server that enables this 852 extension MUST return a JSON array of ANEName (Section 6.1) when the 853 cost metric is "ane-path". 855 6.6. Part Resource ID 857 A Part Resource ID is encoded as a JSON string with the same format 858 as that of the type ResourceID (Section 10.2 of [RFC7285]). 860 NOTE: Even though the client-id assigned to a Path Vector request and 861 the Part Resource ID may contain up to 64 characters by their own 862 definition, their concatenation (see Section 5.3.2) MUST also conform 863 to the same length constraint. The same requirement applies to the 864 resource ID of the Path Vector resource, too. Thus, it is 865 RECOMMENDED to limit the length of resource ID and client ID related 866 to a Path Vector resource to 31 characters. 868 7. Specification: Service Extensions 870 7.1. Multipart Filtered Cost Map for Path Vector 872 This document introduces a new ALTO resource called multipart 873 filtered cost map resource, which allows an ALTO server to provide 874 other ALTO resources associated to the cost map resource in the same 875 response. 877 7.1.1. Media Type 879 The media type of the multipart filtered cost map resource is 880 "multipart/related;type=application/alto-costmap+json". 882 7.1.2. HTTP Method 884 The multipart filtered cost map is requested using the HTTP POST 885 method. 887 7.1.3. Accept Input Parameters 889 The input parameters of the multipart filtered cost map are supplied 890 in the body of an HTTP POST request. This document extends the input 891 parameters to a filtered cost map with a data format indicated by the 892 media type "application/alto-costmapfilter+json", which is a JSON 893 object of type PVReqFilteredCostMap, where: 895 object { 896 [EntityPropertyName ane-property-names<0..*>;] 897 } PVReqFilteredCostMap : ReqFilteredCostMap; 899 with fields: 901 ane-property-names: A list of properties that are associated with 902 the ANEs. Each property in this list MUST match one of the 903 supported ANE properties indicated in the resource's "ane- 904 property-names" capability. If the field is NOT present, it MUST 905 be interpreted as an empty list, indicating that the ALTO server 906 MUST NOT return any property in the Unified Property part. 908 Example: Consider the network in Figure 1. If an ALTO client wants 909 to query the "max-reservable-bandwidth" between PID1 and PID2, it can 910 submit the following request. 912 POST /costmap/pv HTTP/1.1 913 Host: alto.example.com 914 Accept: multipart/related;type=application/alto-costmap+json, 915 application/alto-error+json 916 Content-Length: [TBD] 917 Content-Type: application/alto-costmapfilter+json 919 { 920 "cost-type": { 921 "cost-mode": "array", 922 "cost-metric": "ane-path" 923 }, 924 "pids": { 925 "srcs": [ "PID1" ], 926 "dsts": [ "PID2" ] 927 }, 928 "ane-property-names": [ "max-reservable-bandwidth" ] 929 } 931 7.1.4. Capabilities 933 The multipart filtered cost map resource extends the capabilities 934 defined in Section 11.3.2.4 of [RFC7285]. The capabilities are 935 defined by a JSON object of type PVFilteredCostMapCapabilities: 937 object { 938 [EntityPropertyName ane-property-names<0..*>;] 939 } PVFilteredCostMapCapabilities : FilteredCostMapCapabilities; 941 with fields: 943 cost-type-names: The "cost-type-names" field MUST only include the 944 Path Vector cost type, unless explicitly documented by a future 945 extension. This also implies that the Path Vector cost type MUST 946 be defined in the "cost-types" of the Information Resource 947 Directory's "meta" field. 949 cost-constraints: If the "cost-type-names" field includes the Path 950 Vector cost type, "cost-constraints" field MUST be "false" or not 951 present unless specifically instructed by a future document. 953 testable-cost-type-names: If the "cost-type-names" field includes 954 the Path Vector cost type, the Path Vector cost type MUST NOT be 955 included in the "testable-cost-type-names" field unless 956 specifically instructed by a future document. 958 ane-property-names: Defines a list of ANE properties that can be 959 returned. If the field is NOT present, it MUST be interpreted as 960 an empty list, indicating the ALTO server cannot provide any ANE 961 property. 963 7.1.5. Uses 965 This member MUST include the resource ID of the network map based on 966 which the PIDs are defined. If this resource supports "persistent- 967 entity-id", it MUST also include the defining resources of persistent 968 ANEs that may appear in the response. 970 7.1.6. Response 972 The response MUST indicate an error, using ALTO protocol error 973 handling, as defined in Section 8.5 of [RFC7285], if the request does 974 no. 976 The "Content-Type" header of the response MUST be "multipart/related" 977 as defined by [RFC2387] with the following parameters: 979 type: The type parameter MUST be "application/alto-costmap+json". 980 Note that [RFC2387] permits both parameters with and without the 981 double quotes. 983 start: The start parameter is as defined in [RFC2387]. If present, 984 it MUST have the same value as the "Resource-Id" header of the 985 Path Vector part. 987 boundary: The boundary parameter is as defined in [RFC2387]. 989 The body of the response consists of two parts: 991 * The Path Vector part MUST include "Resource-Id" and "Content-Type" 992 in its header. The value of "Resource-Id" MUST has the format of 993 a Part Resource ID. The "Content-Type" MUST be "application/alto- 994 costmap+json". 996 The body of the Path Vector part MUST be a JSON object with the 997 same format as defined in Section 11.2.3.6 of [RFC7285]. The JSON 998 object MUST include the "vtag" field in the "meta" field, which 999 provides the version tag of the returned cost map. The resource 1000 ID of the version tag MUST follow the format in Section 5.3.2. 1001 The "meta" field MUST also include the "dependent-vtags" field, 1002 whose value is a single-element array to indicate the version tag 1003 of the network map used, where the network map is specified in the 1004 "uses" attribute of the multipart filtered cost map resource in 1005 IRD. 1007 * The Unified Property Map part MUST also include "Resource-Id" and 1008 "Content-Type" in its header. The value of "Resource-Id" has the 1009 format of a Part Resource ID. The "Content-Type" MUST be 1010 "application/alto-propmap+json". 1012 The body of the Unified Property Map part MUST be a JSON object 1013 with the same format as defined in Section 4.6 of 1014 [I-D.ietf-alto-unified-props-new]. The JSON object MUST include 1015 the "dependent-vtags" field in the "meta" field. The value of the 1016 "dependent-vtags" field MUST be an array of VersionTag objects as 1017 defined by Section 10.3 of [RFC7285]. The "vtag" of the Path 1018 Vector part MUST be included in the "dependent-vtags". If 1019 "persistent-entity-id" is requested, the version tags of the 1020 dependent resources that may expose the entities in the response 1021 MUST also be included. The PropertyMapData has one member for 1022 each ANEName that appears in the Path Vector part, which is an 1023 entity identifier belonging to the self-defined entity domain as 1024 defined in Section 5.1.2.3 of [I-D.ietf-alto-unified-props-new]. 1025 The EntityProps has one member for each property requested by an 1026 ALTO client if applicable. 1028 If the "start" parameter is not present, the Path Vector part MUST be 1029 the first part in the multipart response. 1031 Example: Consider the network in Figure 1. The response of the 1032 example request in Section 7.1.3 is as follows, where "ANE1" 1033 represents the aggregation of all the switches in the network. 1035 HTTP/1.1 200 OK 1036 Content-Length: [TBD] 1037 Content-Type: multipart/related; boundary=example-1; 1038 type=application/alto-costmap+json 1040 --example-1 1041 Resource-Id: costmap 1042 Content-Type: application/alto-costmap+json 1044 { 1045 "meta": { 1046 "vtag": { 1047 "resource-id": "filtered-cost-map-pv.costmap", 1048 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1049 }, 1050 "dependent-vtags": [ 1051 { 1052 "resource-id": "my-default-networkmap", 1053 "tag": "75ed013b3cb58f896e839582504f6228" 1054 } 1055 ], 1056 "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" } 1057 }, 1058 "cost-map": { 1059 "PID1": { "PID2": ["ANE1"] } 1060 } 1061 } 1062 --example-1 1063 Resource-Id: propmap 1064 Content-Type: application/alto-propmap+json 1066 { 1067 "meta": { 1068 "dependent-vtags": [ 1069 { 1070 "resource-id": "filtered-cost-map-pv.costmap", 1071 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1072 } 1073 ] 1074 }, 1075 "property-map": { 1076 ".ane:ANE1": { "max-reservable-bandwidth": 100000000 } 1077 } 1078 } 1080 7.2. Multipart Endpoint Cost Service for Path Vector 1082 This document introduces a new ALTO resource called multipart 1083 endpoint cost resource, which allows an ALTO server to provide other 1084 ALTO resources associated to the endpoint cost resource in the same 1085 response. 1087 7.2.1. Media Type 1089 The media type of the multipart endpoint cost resource is 1090 "multipart/related;type=application/alto-endpointcost+json". 1092 7.2.2. HTTP Method 1094 The multipart endpoint cost resource is requested using the HTTP POST 1095 method. 1097 7.2.3. Accept Input Parameters 1099 The input parameters of the multipart endpoint cost resource are 1100 supplied in the body of an HTTP POST request. This document extends 1101 the input parameters to an endpoint cost map with a data format 1102 indicated by the media type "application/alto- 1103 endpointcostparams+json", which is a JSON object of type 1104 PVEndpointCostParams, where 1106 object { 1107 [EntityPropertyName ane-property-names<0..*>;] 1108 } PVReqEndpointcost : ReqEndpointcost; 1110 with fields: 1112 ane-property-names: This document defines the "ane-property-names" 1113 in PVReqEndpointcost as the same as in PVReqFilteredCostMap. See 1114 Section 7.1.3. 1116 Example: Consider the network in Figure 1. If an ALTO client wants 1117 to query the "max-reservable-bandwidth" between eh1 and eh2, it can 1118 submit the following request. 1120 POST /ecs/pv HTTP/1.1 1121 Host: alto.example.com 1122 Accept: multipart/related;type=application/alto-endpointcost+json, 1123 application/alto-error+json 1124 Content-Length: [TBD] 1125 Content-Type: application/alto-endpointcostparams+json 1127 { 1128 "cost-type": { 1129 "cost-mode": "array", 1130 "cost-metric": "ane-path" 1131 }, 1132 "endpoints": { 1133 "srcs": [ "ipv4:1.2.3.4" ], 1134 "dsts": [ "ipv4:2.3.4.5" ] 1135 }, 1136 "ane-property-names": [ "max-reservable-bandwidth" ] 1137 } 1139 7.2.4. Capabilities 1141 The capabilities of the multipart endpoint cost resource are defined 1142 by a JSON object of type PVEndpointcostCapabilities, which is defined 1143 as the same as PVFilteredCostMapCapabilities. See Section 7.1.4. 1145 7.2.5. Uses 1147 If this resource supports "persistent-entity-id", it MUST also 1148 include the defining resources of persistent ANEs that may appear in 1149 the response. 1151 7.2.6. Response 1153 The response MUST indicate an error, using ALTO protocol error 1154 handling, as defined in Section 8.5 of [RFC7285], if the request is 1155 invalid. 1157 The "Content-Type" header of the response MUST be "multipart/related" 1158 as defined by [RFC7285] with the following parameters: 1160 type: The type parameter MUST be "application/alto- 1161 endpointcost+json". 1163 start: The start parameter is as defined in Section 7.1.6. 1165 boundary: The boundary parameter is as defined in [RFC2387]. 1167 The body consists of two parts: 1169 * The Path Vector part MUST include "Resource-Id" and "Content-Type" 1170 in its header. The value of "Resource-Id" MUST has the format of 1171 a Part Resource ID. The "Content-Type" MUST be "application/alto- 1172 endpointcost+json". 1174 The body of the Path Vector part MUST be a JSON object with the 1175 same format as defined in Section 11.5.1.6 of [RFC7285]. The JSON 1176 object MUST include the "vtag" field in the "meta" field, which 1177 provides the version tag of the returned endpoint cost map. The 1178 resource ID of the version tag MUST follow the format in 1179 Section 5.3.2. 1181 * The Unified Property Map part MUST also include "Resource-Id" and 1182 "Content-Type" in its header. The value of "Resource-Id" MUST has 1183 the format of a Part Resource ID. The "Content-Type" MUST be 1184 "application/alto-propmap+json". 1186 The body of the Unified Property Map part MUST be a JSON object 1187 with the same format as defined in Section 4.6 of 1188 [I-D.ietf-alto-unified-props-new]. The JSON object MUST include 1189 the "dependent-vtags" field in the "meta" field. The value of the 1190 "dependent-vtags" field MUST be an array of VersionTag objects as 1191 defined by Section 10.3 of [RFC7285]. The "vtag" of the Path 1192 Vector part MUST be included in the "dependent-vtags". If 1193 "persistent-entity-id" is requested, the version tags of the 1194 dependent resources that may expose the entities in the response 1195 MUST also be included. The PropertyMapData has one member for 1196 each ANEName that appears in the Path Vector part, which is an 1197 entity identifier belonging to the self-defined entity domain as 1198 defined in Section 5.1.2.3 of [I-D.ietf-alto-unified-props-new]. 1199 The EntityProps has one member for each property requested by the 1200 ALTO client if applicable. 1202 If the "start" parameter is not present, the Path Vector part MUST be 1203 the first part in the multipart response. 1205 Example: Consider the network in Figure 1. The response of the 1206 example request in Section 7.2.3 is as follows. 1208 HTTP/1.1 200 OK 1209 Content-Length: [TBD] 1210 Content-Type: multipart/related; boundary=example-1; 1211 type=application/alto-endpointcost+json 1213 --example-1 1214 Resource-Id: ecs 1215 Content-Type: application/alto-endpointcost+json 1217 { 1218 "meta": { 1219 "vtag": { 1220 "resource-id": "ecs-pv.costmap", 1221 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1222 }, 1223 "dependent-vtags": [ 1224 { 1225 "resource-id": "my-default-networkmap", 1226 "tag": "75ed013b3cb58f896e839582504f6228" 1227 } 1228 ], 1229 "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" } 1230 }, 1231 "cost-map": { 1232 "ipv4:1.2.3.4": { "ipv4:2.3.4.5": ["ANE1"] } 1233 } 1234 } 1235 --example-1 1236 Resource-Id: propmap 1237 Content-Type: application/alto-propmap+json 1239 { 1240 "meta": { 1241 "dependent-vtags": [ 1242 { 1243 "resource-id": "ecs-pv.costmap", 1244 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1245 } 1246 ] 1247 }, 1248 "property-map": { 1249 ".ane:ANE1": { "max-reservable-bandwidth": 100000000 } 1250 } 1251 } 1253 8. Examples 1255 This section lists some examples of Path Vector queries and the 1256 corresponding responses. Some long lines are truncated for better 1257 readability. 1259 8.1. Example: Information Resource Directory 1261 To give a comprehensive example of the Path Vector extension, we 1262 consider the network in Figure 5. The example ALTO server provides 1263 the following information resources: 1265 * "my-default-networkmap": A Network Map resource which contains the 1266 PIDs in the network. 1268 * "filtered-cost-map-pv": A Multipart Filtered Cost Map resource for 1269 Path Vector, which exposes the "max-reservable-bandwidth" property 1270 for the PIDs in "my-default-networkmap". 1272 * "ane-props": A filtered Unified Property resource that exposes the 1273 information for persistent ANEs in the network. 1275 * "endpoint-cost-pv": A Multipart Endpoint Cost Service for Path 1276 Vector, which exposes the "max-reservable-bandwidth" and the 1277 "persistent-entity-id" properties. 1279 * "update-pv": An Update Stream service, which provides the 1280 incremental update service for the "endpoint-cost-pv" service. 1282 Below is the Information Resource Directory of the example ALTO 1283 server. To enable the Path Vector extension, the "path-vector" cost 1284 type (Section 6.5) is defined in the "cost-types" of the "meta" 1285 field, and is included in the "cost-type-names" of resources 1286 "filetered-cost-map-pv" and "endpoint-cost-pv". 1288 { 1289 "meta": { 1290 "cost-types": { 1291 "path-vector": { 1292 "cost-mode": "array", 1293 "cost-metric": "ane-path" 1294 } 1295 } 1296 }, 1297 "resources": { 1298 "my-default-networkmap": { 1299 "uri" : "https://alto.example.com/networkmap", 1300 "media-type" : "application/alto-networkmap+json" 1302 }, 1303 "filtered-cost-map-pv": { 1304 "uri": "https://alto.example.com/costmap/pv", 1305 "media-type": "multipart/related; 1306 type=application/alto-costmap+json", 1307 "accepts": "application/alto-costmapfilter+json", 1308 "capabilities": { 1309 "cost-type-names": [ "path-vector" ], 1310 "ane-property-names": [ "max-reservable-bandwidth" ] 1311 }, 1312 "uses": [ "my-default-networkmap" ] 1313 }, 1314 "ane-props": { 1315 "uri": "https://alto.example.com/ane-props", 1316 "media-type": "application/alto-propmap+json", 1317 "accepts": "application/alto-propmapparams+json", 1318 "capabilities": { 1319 "mappings": { 1320 ".ane": [ "cpu" ] 1321 } 1322 } 1323 }, 1324 "endpoint-cost-pv": { 1325 "uri": "https://alto.exmaple.com/endpointcost/pv", 1326 "media-type": "multipart/related; 1327 type=application/alto-endpointcost+json", 1328 "accepts": "application/alto-endpointcostparams+json", 1329 "capabilities": { 1330 "cost-type-names": [ "path-vector" ], 1331 "ane-property-names": [ 1332 "max-reservable-bandwidth", "persistent-entity-id" 1333 ] 1334 }, 1335 "uses": [ "ane-props" ] 1336 }, 1337 "update-pv": { 1338 "uri": "https://alto.example.com/updates/pv", 1339 "media-type": "text/event-stream", 1340 "uses": [ "endpoint-cost-pv" ], 1341 "accepts": "application/alto-updatestreamparams+json", 1342 "capabilities": { 1343 "support-stream-control": true 1344 } 1345 } 1346 } 1347 } 1349 8.2. Example: Multipart Filtered Cost Map 1351 The following examples demonstrate the request to the "filtered-cost- 1352 map-pv" resource and the corresponding response. 1354 The request uses the "path-vector" cost type in the "cost-type" 1355 field. The "ane-property-names" field is missing, indicating that 1356 the client only requests for the Path Vector but not the ANE 1357 properties. 1359 The response consists of two parts. The first part returns the array 1360 of ANEName for each source and destination pair. There are two ANEs, 1361 where "L1" represents the interconnection link L1, and "L2" 1362 represents the interconnection link L2. 1364 The second part returns an empty Property Map. Note that the ANE 1365 entries are omitted since they have no properties (See Section 3.1 of 1366 [I-D.ietf-alto-unified-props-new]). 1368 POST /costmap/pv HTTP/1.1 1369 Host: alto.example.com 1370 Accept: multipart/related;type=application/alto-costmap+json, 1371 application/alto-error+json 1372 Content-Length: [TBD] 1373 Content-Type: application/alto-costmapfilter+json 1375 { 1376 "cost-type": { 1377 "cost-mode": "array", 1378 "cost-metric": "ane-path" 1379 }, 1380 "pids": { 1381 "srcs": [ "PID1" ], 1382 "dsts": [ "PID3", "PID4" ] 1383 } 1384 } 1386 HTTP/1.1 200 OK 1387 Content-Length: [TBD] 1388 Content-Type: multipart/related; boundary=boundary; 1389 type=application/alto-costmap+json 1391 --boundary 1392 Resource-Id: costmap 1393 Content-Type: application/alto-costmap+json 1395 { 1396 "meta": { 1397 "vtag": { 1398 "resource-id": "filtered-cost-map-pv.costmap", 1399 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1400 }, 1401 "dependent-vtags": [ 1402 { 1403 "resource-id": "my-default-networkmap", 1404 "tag": "75ed013b3cb58f896e839582504f6228" 1405 } 1406 ], 1407 "cost-type": { 1408 "cost-mode": "array", 1409 "cost-metric": "ane-path" 1410 } 1411 }, 1412 "cost-map": { 1413 "PID1": { 1414 "PID3": [ "L1" ], 1415 "PID4": [ "L1", "L2" ] 1416 } 1417 } 1418 } 1419 --boundary 1420 Resource-Id: propmap 1421 Content-Type: application/alto-propmap+json 1423 { 1424 "meta": { 1425 "dependent-vtags": [ 1426 { 1427 "resource-id": "filtered-cost-map-pv.costmap", 1428 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1429 } 1430 ] 1431 }, 1432 "property-map": { 1433 } 1434 } 1436 8.3. Example: Multipart Endpoint Cost Resource 1438 The following examples demonstrate the request to the "endpoint-cost- 1439 pv" resource and the corresponding response. 1441 The request uses the path vector cost type in the "cost-type" field, 1442 and queries the Maximum Reservable Bandwidth ANE property and the 1443 Persistent Entity property. 1445 The response consists of two parts. The first part returns the array 1446 of ANEName for each valid source and destination pair, where "NET1" 1447 represent sub-network NET1, and "AGGR" is the aggregation of L1 and 1448 NET3. 1450 The second part returns the requested properties of ANEs. Since NET1 1451 has sufficient bandwidth, it sets the "max-reservable-bandwidth" to a 1452 sufficiently large number. It also represents a persistent ANE 1453 defined in the "ane-props" resource, identified by "ane- 1454 props.ane:datacenter1". The aggregated "max-reservable-bandwidth" of 1455 ane:AGGR is constrained by the link capacity of L1. The "persistent- 1456 entity-id" property is omitted as both L1 and NET3 do not represent 1457 any persistent entity. 1459 POST /endpointcost/pv HTTP/1.1 1460 Host: alto.example.com 1461 Accept: multipart/related; 1462 type=application/alto-endpointcost+json, 1463 application/alto-error+json 1464 Content-Length: [TBD] 1465 Content-Type: application/alto-endpointcostparams+json 1467 { 1468 "cost-type": { 1469 "cost-mode": "array", 1470 "cost-metric": "ane-path" 1471 }, 1472 "endpoints": { 1473 "srcs": [ "ipv4:1.2.3.4", "ipv4:2.3.4.5" ], 1474 "dsts": [ "ipv4:3.4.5.6" ] 1475 }, 1476 "ane-property-names": [ 1477 "max-reservable-bandwidth", 1478 "persistent-entity-id" 1479 ] 1480 } 1482 HTTP/1.1 200 OK 1483 Content-Length: [TBD] 1484 Content-Type: multipart/related; boundary=boundary; 1485 type=application/alto-endpointcost+json 1487 --boundary 1488 Resource-Id: ecs 1489 Content-Type: application/alto-endpointcost+json 1491 { 1492 "meta": { 1493 "vtags": { 1494 "resource-id": "endpoint-cost-pv.ecs", 1495 "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef" 1496 }, 1497 "cost-type": { 1498 "cost-mode": "array", 1499 "cost-metric": "ane-path" 1500 } 1501 }, 1502 "endpoint-cost-map": { 1503 "ipv4:1.2.3.4": { 1504 "ipv4:3.4.5.6": [ "NET1", "AGGR" ] 1505 }, 1506 "ipv4:2.3.4.5": { 1507 "ipv4:3.4.5.6": [ "NET1", "AGGR" ] 1508 } 1509 } 1510 } 1511 --boundary 1512 Resource-Id: propmap 1513 Content-Type: application/alto-propmap+json 1515 { 1516 "meta": { 1517 "dependent-vtags": [ 1518 { 1519 "resource-id": "endpoint-cost-pv.ecs", 1520 "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef" 1521 }, 1522 { 1523 "resource-id": "ane-props", 1524 "tag": "bf3c8c1819d2421c9a95a9d02af557a3" 1525 } 1526 ] 1527 }, 1528 "property-map": { 1529 ".ane:NET1": { 1530 "max-reservable-bandwidth": 50000000000, 1531 "persistent-entity-id": "ane-props.ane:datacenter1", 1532 }, 1533 ".ane:AGGR": { 1534 "max-reservable-bandwidth": 10000000000 1535 } 1536 } 1537 } 1539 After the client obtains "ane-props.ane:datacenter1", it can query 1540 the "ane-props" resource to get the properties of the persistent ANE. 1542 8.4. Example: Incremental Updates 1544 In this example, an ALTO client subscribes to the incremental update 1545 for the multipart endpoint cost resource "endpoint-cost-pv". 1547 POST /updates/pv HTTP/1.1 1548 Host: alto.example.com 1549 Accept: text/event-stream 1550 Content-Type: application/alto-updatestreamparams+json 1551 Content-Length: [TBD] 1553 { 1554 "add": { 1555 "ecspvsub1": { 1556 "resource-id": "endpoint-cost-pv", 1557 "input": 1558 } 1559 } 1560 } 1562 Based on the server-side process defined in 1563 [I-D.ietf-alto-incr-update-sse], the ALTO server will send the 1564 "control-uri" first using Server-Sent Event (SSE), followed by the 1565 full response of the multipart message. 1567 HTTP/1.1 200 OK 1568 Connection: keep-alive 1569 Content-Type: text/event-stream 1571 event: application/alto-updatestreamcontrol+json 1572 data: {"control-uri": "https://alto.example.com/updates/streams/123"} 1574 event: multipart/related;boundary=boundary; 1575 type=application/alto-endpointcost+json,ecspvsub1 1576 data: --boundary 1577 data: Resource-ID: ecsmap 1578 data: Content-Type: application/alto-endpointcost+json 1579 data: 1580 data: 1581 data: --boundary 1582 data: Resource-ID: propmap 1583 data: Content-Type: application/alto-propmap+json 1584 data: 1585 data: 1586 data: --boundary-- 1588 When the contents change, the ALTO server will publish the updates 1589 for each node in this tree separately. 1591 event: application/merge-patch+json, ecspvsub1.ecsmap 1592 data: 1594 event: application/merge-patch+json, ecspvsub1.propmap 1595 data: 1597 9. Compatibility 1599 9.1. Compatibility with Legacy ALTO Clients/Servers 1601 The multipart filtered cost map resource and the multipart endpoint 1602 cost resource has no backward compatibility issue with legacy ALTO 1603 clients and servers. Although these two types of resources reuse the 1604 media types defined in the base ALTO protocol for the accept input 1605 parameters, they have different media types for responses. If the 1606 ALTO server provides these two types of resources, but the ALTO 1607 client does not support them, the ALTO client will ignore the 1608 resources without conducting any incompatibility. 1610 9.2. Compatibility with Multi-Cost Extension 1612 This document does not specify how to integrate the Path Vector cost 1613 type with the multi-cost extension [RFC8189]. While it is not 1614 RECOMMENDED to put the Path Vector cost type with other cost types in 1615 a single query, there is no compatible issue. 1617 9.3. Compatibility with Incremental Update 1619 The extension specified in this document is not compatible with the 1620 original incremental update extension 1621 [I-D.ietf-alto-incr-update-sse]. A legacy ALTO client cannot 1622 recognize the compound client-id, and a legacy ALTO server may use 1623 the same client-id for updates of both parts. 1625 ALTO clients and servers must follow the specifications given in this 1626 document to ensure compatibility with the incremental update 1627 extension. 1629 9.4. Compatibility with Cost Calendar 1631 The extension specified in this document is compatible with the Cost 1632 Calendar extension [I-D.ietf-alto-cost-calendar]. When used together 1633 with the Cost Calendar extension, the cost value between a source and 1634 a destination is an array of path vectors, where the k-th path vector 1635 refers to the abstract network paths traversed in the k-th time 1636 interval by traffic from the source to the destination. 1638 When used with time-varying properties, e.g., maximum reservable 1639 bandwidth (maxresbw), a property of a single entity may also have 1640 different values in different time intervals. In this case, an ANE 1641 with different property values must be considered as different ANEs. 1643 The two extensions combined together can provide the historical 1644 network correlation information for a set of source and destination 1645 pairs. A network broker or client may use this information to derive 1646 other resource requirements such as Time-Block-Maximum Bandwidth, 1647 Bandwidth-Sliding-Window, and Time-Bandwidth-Product (TBP) (See 1648 [SENSE] for details). 1650 10. General Discussions 1652 10.1. Constraint Tests for General Cost Types 1654 The constraint test is a simple approach to query the data. It 1655 allows users to filter the query result by specifying some boolean 1656 tests. This approach is already used in the ALTO protocol. 1657 [RFC7285] and [RFC8189] allow ALTO clients to specify the 1658 "constraints" and "or-constraints" tests to better filter the result. 1660 However, the current syntax can only be used to test scalar cost 1661 types, and cannot easily express constraints on complex cost types, 1662 e.g., the Path Vector cost type defined in this document. 1664 In practice, developing a language for general-purpose boolean tests 1665 can be complex and is likely to be a duplicated work. Thus, it is 1666 worth looking into the direction of integrating existing well- 1667 developed query languages, e.g., XQuery and JSONiq, or their subset 1668 with ALTO. 1670 Filtering the Path Vector results or developing a more sophisticated 1671 filtering mechanism is beyond the scope of this document. 1673 10.2. General Multipart Resources Query 1675 Querying multiple ALTO information resources continuously may be a 1676 general requirement. And the coming issues like inefficiency and 1677 inconsistency are also general. There is no standard solving these 1678 issues yet. So we need some approach to make the ALTO client request 1679 the compound ALTO information resources in a single query. 1681 11. Security Considerations 1683 This document is an extension of the base ALTO protocol, so the 1684 Security Considerations [RFC7285] of the base ALTO protocol fully 1685 apply when this extension is provided by an ALTO server. 1687 The Path Vector extension requires additional considerations on two 1688 security considerations discussed in the base protocol: 1689 confidentiality of ALTO information (Section 15.3 of [RFC7285]) and 1690 availability of ALTO service (Section 15.5 of [RFC7285]). 1692 For confidentiality of ALTO information, a network operator should be 1693 aware of that this extension may introduce a new risk: the Path 1694 Vector information may make network attacks easier. For example, as 1695 the Path Vector information may reveal more fine-grained internal 1696 network structures than the base protocol, an ALTO client may detect 1697 the bottleneck link and start a distributed denial-of-service (DDoS) 1698 attack involving minimal flows to conduct the in-network congestion. 1700 To mitigate this risk, the ALTO server should consider protection 1701 mechanisms to reduce information exposure or obfuscate the real 1702 information, in particular, in settings where the network and the 1703 application do not belong to the same trust domain. But the 1704 implementation of Path Vector extension involving reduction or 1705 obfuscation should guarantee the requested properties are still 1706 accurate. 1708 For availability of ALTO service, an ALTO server should be cognizant 1709 that using Path Vector extension might have a new risk: frequent 1710 requesting for path vectors might conduct intolerable increment of 1711 the server-side storage and break the ALTO server. It is known that 1712 the computation of Path Vectors is unlikely to be cacheable, in that 1713 the results will depend on the particular requests (e.g., where the 1714 flows are distributed). Hence, the service providing Path Vectors 1715 may become an entry point for denial-of-service attacks on the 1716 availability of an ALTO server. To avoid this risk, authenticity and 1717 authorization of this ALTO service may need to be better protected. 1719 12. IANA Considerations 1721 12.1. ALTO Entity Domain Registry 1723 This document registers a new entry to the ALTO Domain Entity 1724 Registry, as instructed by Section 12.2 of 1725 [I-D.ietf-alto-unified-props-new]. The new entry is as shown below 1726 in Table 1. 1728 +------------+----------------+-------------+-------------------+ 1729 | Identifier | Entity Address | Hierarchy & | Media Type of | 1730 | | Encoding | Inheritance | Defining Resource | 1731 +============+================+=============+===================+ 1732 | ane | See | None | application/alto- | 1733 | | Section 6.2.2 | | propmap+json | 1734 +------------+----------------+-------------+-------------------+ 1736 Table 1: ALTO Entity Domain 1738 Identifier: See Section 6.2.1. 1740 Entity Identifier Encoding: See Section 6.2.2. 1742 Hierarchy: None 1744 Inheritance: None 1746 Media Type of Defining Resource: See Section 6.2.4. 1748 Security Considerations: In some usage scenarios, ANE addresses 1749 carried in ALTO Protocol messages may reveal information about an 1750 ALTO client or an ALTO service provider. Applications and ALTO 1751 service providers using addresses of ANEs will be made aware of 1752 how (or if) the addressing scheme relates to private information 1753 and network proximity, in further iterations of this document. 1755 12.2. ALTO Entity Property Type Registry 1757 Two initial entries are registered to the ALTO Domain "ane" in the 1758 "ALTO Entity Property Type Registry", as instructed by Section 12.3 1759 of [I-D.ietf-alto-unified-props-new]. The two new entries are shown 1760 below in Table 2. 1762 +--------------------------+--------------------+ 1763 | Identifier | Intended Semantics | 1764 +==========================+====================+ 1765 | max-reservable-bandwidth | See Section 6.4.1 | 1766 +--------------------------+--------------------+ 1767 | persistent-entity-id | See Section 6.4.2 | 1768 +--------------------------+--------------------+ 1770 Table 2: Initial Entries for ane Domain in 1771 the ALTO Entity Property Types Registry 1773 13. Acknowledgments 1775 The authors would like to thank discussions with Andreas Voellmy, 1776 Erran Li, Haibin Song, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan 1777 Liu, Xiao Shi, Xin Wang, and Yan Luo. The authors thank Greg 1778 Bernstein (Grotto Networks), Dawn Chen (Tongji University), Wendy 1779 Roome, and Michael Scharf for their contributions to earlier drafts. 1781 14. References 1783 14.1. Normative References 1785 [I-D.ietf-alto-cost-calendar] 1786 Randriamasy, S., Yang, Y., WU, Q., Lingli, D., and N. 1787 Schwan, "Application-Layer Traffic Optimization (ALTO) 1788 Cost Calendar", Work in Progress, Internet-Draft, draft- 1789 ietf-alto-cost-calendar-21, 17 March 2020, 1790 . 1793 [I-D.ietf-alto-incr-update-sse] 1794 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1795 Server-Sent Events (SSE)", Work in Progress, Internet- 1796 Draft, draft-ietf-alto-incr-update-sse-22, 20 March 2020, 1797 . 1800 [I-D.ietf-alto-performance-metrics] 1801 WU, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and 1802 L. Contreras, "ALTO Performance Cost Metrics", Work in 1803 Progress, Internet-Draft, draft-ietf-alto-performance- 1804 metrics-11, 12 June 2020, . 1807 [I-D.ietf-alto-unified-props-new] 1808 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 1809 Gao, "Unified Properties for the ALTO Protocol", Work in 1810 Progress, Internet-Draft, draft-ietf-alto-unified-props- 1811 new-11, 9 March 2020, . 1814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1815 Requirement Levels", BCP 14, RFC 2119, 1816 DOI 10.17487/RFC2119, March 1997, 1817 . 1819 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 1820 RFC 2387, DOI 10.17487/RFC2387, August 1998, 1821 . 1823 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1824 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1825 "Application-Layer Traffic Optimization (ALTO) Protocol", 1826 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1827 . 1829 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1830 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1831 May 2017, . 1833 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1834 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1835 DOI 10.17487/RFC8189, October 2017, 1836 . 1838 14.2. Informative References 1840 [AAAI2019] Xiang, Q., Yu, H., Aspnes, J., Le, F., Kong, L., and Y.R. 1841 Yang, "Optimizing in the dark: Learning an optimal 1842 solution through a simple request interface", Proceedings 1843 of the AAAI Conference on Artificial Intelligence 33, 1844 1674-1681 , 2019. 1846 [I-D.bernstein-alto-topo] 1847 Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology 1848 Service: Uses Cases, Requirements, and Framework", Work in 1849 Progress, Internet-Draft, draft-bernstein-alto-topo-00, 21 1850 October 2013, . 1853 [I-D.contreras-alto-service-edge] 1854 Contreras, L., Perez, D., and C. Rothenberg, "Use of ALTO 1855 for Determining Service Edge", Work in Progress, Internet- 1856 Draft, draft-contreras-alto-service-edge-00, 4 November 1857 2019, . 1860 [I-D.huang-alto-mowie-for-network-aware-app] 1861 Huang, W., Zhang, Y., Yang, R., Xiong, C., Lei, Y., Han, 1862 Y., and G. Li, "MoWIE for Network Aware Application", Work 1863 in Progress, Internet-Draft, draft-huang-alto-mowie-for- 1864 network-aware-app-00, 9 March 2020, . 1868 [I-D.ietf-dmm-5g-uplane-analysis] 1869 Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, 1870 "User Plane Protocol and Architectural Analysis on 3GPP 5G 1871 System", Work in Progress, Internet-Draft, draft-ietf-dmm- 1872 5g-uplane-analysis-03, 3 November 2019, 1873 . 1876 [I-D.yang-alto-deliver-functions-over-networks] 1877 Yang, S., Cui, L., Xu, M., Yang, Y., and R. Huang, 1878 "Delivering Functions over Networks: Traffic and 1879 Performance Optimization for Edge Computing using ALTO", 1880 Work in Progress, Internet-Draft, draft-yang-alto-deliver- 1881 functions-over-networks-01, 13 July 2020, 1882 . 1885 [LHC] "CERN - LHC", 2019, . 1887 [SENSE] "Services - SENSE", 2019, . 1889 [TON2019] Gao, K., Xiang, Q., Wang, X., Yang, Y.R., and J. Bi, "An 1890 objective-driven on-demand network abstraction for 1891 adaptive applications", IEEE/ACM Transactions on 1892 Networking (TON) Vol 27, no. 2 (2019): 805-818., 2019. 1894 Appendix A. Changes since -10 1896 Revision -11 1898 * replaces "part" with "components" in the abstract; 1900 * identifies additional requirements (AR) derived from the flow 1901 scheduling example, and introduces how the extension addresses the 1902 additional requirements 1904 * fixes the inconsistent use of "start" parameter in multipart 1905 responses; 1907 * specifies explicitly how to handle "cost-constraints"; 1909 * uses the latest IANA registration mechanism defined in 1910 [I-D.ietf-alto-unified-props-new]; 1912 * renames "persistent-entities" to "persistent-entity-id"; 1914 * makes "application/alto-propmap+json" as the media type of 1915 defining resources for the "ane" domain; 1917 * updates the examples; 1919 * adds the discussion on ephemeral and persistent ANEs. 1921 Appendix B. Changes since -09 1923 Revision -10 1925 * revises the introduction which 1927 - extends the scope where the PV extension can be applied beyond 1928 the "path correlation" information 1930 * brings back the capacity region use case to better illustrate the 1931 problem 1933 * revises the overview to explain and defend the concepts and 1934 decision choices 1936 * fixes inconsistent terms, typos 1938 Appendix C. Changes since -08 1940 This revision 1942 * fixes a few spelling errors 1944 * emphasizes that abstract network elements can be generated on 1945 demand in both introduction and motivating use cases 1947 Appendix D. Changes Since Version -06 1949 * We emphasize the importance of the path vector extension in two 1950 aspects: 1952 1. It expands the problem space that can be solved by ALTO, from 1953 preferences of network paths to correlations of network paths. 1955 2. It is motivated by new usage scenarios from both application's 1956 and network's perspectives. 1958 * More use cases are included, in addition to the original capacity 1959 region use case. 1961 * We add more discussions to fully explore the design space of the 1962 path vector extension and justify our design decisions, including 1963 the concept of abstract network element, cost type (reverted to 1964 -05), newer capabilities and the multipart message. 1966 * Fix the incremental update process to be compatible with SSE -16 1967 draft, which uses client-id instead of resource-id to demultiplex 1968 updates. 1970 * Register an additional ANE property (i.e., persistent-entities) to 1971 cover all use cases mentioned in the draft. 1973 Authors' Addresses 1975 Kai Gao 1976 China 1977 610000 1978 Chengdu 1979 No.24 South Section 1, Yihuan Road 1980 Sichuan University 1982 Email: kaigao@scu.edu.cn 1984 Young Lee 1986 Sabine Randriamasy 1987 Nokia Bell Labs 1988 Route de Villejust 1989 91460 Nozay 1990 France 1992 Email: sabine.randriamasy@nokia-bell-labs.com 1994 Yang Richard Yang 1995 Yale University 1996 51 Prospect Street 1997 New Haven, CT 1998 United States of America 2000 Email: yry@cs.yale.edu 2002 Jingxuan Jensen Zhang 2003 China 2004 201804 2005 Shanghai 2006 4800 Caoan Road 2007 Tongji University 2009 Email: jingxuan.n.zhang@gmail.com