idnits 2.17.1 draft-ietf-alto-path-vector-12.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 compatibility issue. -- The document date (2 November 2020) is 1270 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 580, but not defined == Missing Reference: 'TBD' is mentioned on line 1602, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-12 ** Downref: Normative reference to an Informational RFC: RFC 2216 == Outdated reference: A later version (-10) exists of draft-contreras-alto-service-edge-01 == Outdated reference: A later version (-05) exists of draft-huang-alto-mowie-for-network-aware-app-01 == Outdated reference: A later version (-28) exists of draft-ietf-alto-performance-metrics-12 == 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: 2 errors (**), 0 flaws (~~), 11 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: 6 May 2021 Samsung 6 S. Randriamasy 7 Nokia Bell Labs 8 Y.R. Yang 9 Yale University 10 J. Zhang 11 Tongji University 12 2 November 2020 14 ALTO Extension: Path Vector 15 draft-ietf-alto-path-vector-12 17 Abstract 19 This document is an extension to the base Application-Layer Traffic 20 Optimization protocol [RFC7285]. While the current ALTO Cost 21 Services only allow applications to obtain numerical/ordinal cost 22 values on an end-to-end path defined by its source and destination, 23 the present extension enables the provision of abstracted information 24 on particular Abstract Network Elements on the path. These Abstract 25 Network Elements, or simply Elements, are components of the network 26 which handle data packets, and their properties may have an impact on 27 the end-to-end performance of the applications' traffic. Examples of 28 such Elements include physical devices such as routers, cables and 29 interfaces, and aggregations of devices such as subnetworks and data 30 centers. Such information is useful for applications whose 31 performance is impacted by particular Abstract Network Elements they 32 traverse or by their properties. Applications having the choice 33 among several connection paths may use this information to select 34 paths accordingly and improve their performance. In particular, they 35 may infer that several paths share common links and prevent traffic 36 bottlenecks by avoiding such paths. This document introduces a new 37 cost type called Path Vector. A Path Vector is an array of entities 38 that each identifies an Abstract Network Element (ANE). Each ANE is 39 associated with a set of properties. ANE properties are conveyed by 40 an ALTO information resource called "Property Map", that can be 41 packed together with the Path Vectors in a multipart response. They 42 can also be obtained via a separate ALTO request to a Property Map. 43 An ALTO Property Map is an extension to the ALTO protocol, that is 44 specified in another document entitled "Unified Properties for the 45 ALTO Protocol" [I-D.ietf-alto-unified-props-new]. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on 6 May 2021. 64 Copyright Notice 66 Copyright (c) 2020 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 71 license-info) in effect on the date of publication of this document. 72 Please review these documents carefully, as they describe your rights 73 and restrictions with respect to this document. Code Components 74 extracted from this document must include Simplified BSD License text 75 as described in Section 4.e of the Trust Legal Provisions and are 76 provided without warranty as described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Requirements Languages . . . . . . . . . . . . . . . . . . . 6 82 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 84 4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 8 85 4.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 10 86 4.2.1. Large-scale Data Analytics . . . . . . . . . . . . . 10 87 4.2.2. Context-aware Data Transfer . . . . . . . . . . . . . 11 88 4.2.3. CDN and Service Edge . . . . . . . . . . . . . . . . 11 89 5. Path Vector Extension: Overview . . . . . . . . . . . . . . . 11 90 5.1. Abstract Network Element . . . . . . . . . . . . . . . . 12 91 5.1.1. ANE Domain . . . . . . . . . . . . . . . . . . . . . 12 92 5.1.2. Ephemeral ANE and Persistent ANE . . . . . . . . . . 12 93 5.1.3. Property Filtering . . . . . . . . . . . . . . . . . 13 94 5.2. Path Vector Cost Type . . . . . . . . . . . . . . . . . . 13 95 5.3. Multipart Path Vector Response . . . . . . . . . . . . . 14 96 5.3.1. Identifying the Media Type of the Root Object . . . . 15 97 5.3.2. References to Part Messages . . . . . . . . . . . . . 15 98 5.3.3. Order of Part Messages . . . . . . . . . . . . . . . 16 99 6. Specification: Basic Data Types . . . . . . . . . . . . . . . 16 100 6.1. ANE Name . . . . . . . . . . . . . . . . . . . . . . . . 16 101 6.2. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 17 102 6.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 17 103 6.2.2. Domain-Specific Entity Identifier . . . . . . . . . . 17 104 6.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 17 105 6.2.4. Media Type of Defining Resource . . . . . . . . . . . 17 106 6.3. ANE Property Name . . . . . . . . . . . . . . . . . . . . 17 107 6.4. Initial ANE Property Types . . . . . . . . . . . . . . . 18 108 6.4.1. New ANE Property Type: Maximum Reservable 109 Bandwidth . . . . . . . . . . . . . . . . . . . . . . 18 110 6.4.2. New ANE Property Type: Persistent Entity ID . . . . . 19 111 6.5. Path Vector Cost Type . . . . . . . . . . . . . . . . . . 19 112 6.5.1. Cost Metric: ane-path . . . . . . . . . . . . . . . . 20 113 6.5.2. Cost Mode: array . . . . . . . . . . . . . . . . . . 20 114 6.6. Part Resource ID . . . . . . . . . . . . . . . . . . . . 20 115 7. Specification: Service Extensions . . . . . . . . . . . . . . 20 116 7.1. Multipart Filtered Cost Map for Path Vector . . . . . . . 21 117 7.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 21 118 7.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 21 119 7.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 21 120 7.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . 22 121 7.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 23 122 7.1.6. Response . . . . . . . . . . . . . . . . . . . . . . 23 123 7.2. Multipart Endpoint Cost Service for Path Vector . . . . . 26 124 7.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 26 125 7.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 26 126 7.2.3. Accept Input Parameters . . . . . . . . . . . . . . . 26 127 7.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . 27 128 7.2.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 27 129 7.2.6. Response . . . . . . . . . . . . . . . . . . . . . . 27 130 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 30 131 8.1. Example: Information Resource Directory . . . . . . . . . 30 132 8.2. Example: Multipart Filtered Cost Map . . . . . . . . . . 32 133 8.3. Example: Multipart Endpoint Cost Resource . . . . . . . . 33 134 8.4. Example: Incremental Updates . . . . . . . . . . . . . . 36 135 9. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 37 136 9.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 37 137 9.2. Compatibility with Multi-Cost Extension . . . . . . . . . 37 138 9.3. Compatibility with Incremental Update . . . . . . . . . . 37 139 9.4. Compatibility with Cost Calendar . . . . . . . . . . . . 37 140 10. General Discussions . . . . . . . . . . . . . . . . . . . . . 38 141 10.1. Constraint Tests for General Cost Types . . . . . . . . 38 142 10.2. General Multipart Resources Query . . . . . . . . . . . 39 144 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 145 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 146 12.1. ALTO Entity Domain Type Registry . . . . . . . . . . . . 40 147 12.2. ALTO Entity Property Type Registry . . . . . . . . . . . 40 148 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 149 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 150 14.1. Normative References . . . . . . . . . . . . . . . . . . 41 151 14.2. Informative References . . . . . . . . . . . . . . . . . 42 152 Appendix A. Changes since -11 . . . . . . . . . . . . . . . . . 44 153 Appendix B. Changes since -10 . . . . . . . . . . . . . . . . . 44 154 Appendix C. Changes since -09 . . . . . . . . . . . . . . . . . 44 155 Appendix D. Changes since -08 . . . . . . . . . . . . . . . . . 45 156 Appendix E. Changes Since Version -06 . . . . . . . . . . . . . 45 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 159 1. Introduction 161 Network performance metrics are crucial to the Quality of Experience 162 (QoE) of today's applications. The ALTO protocol allows Internet 163 Service Providers (ISPs) to provide guidance, such as topological 164 distance between different end hosts, to overlay applications. Thus, 165 the overlay applications can potentially improve the QoE by better 166 orchestrating their traffic to utilize the resources in the 167 underlying network infrastructure. 169 Existing ALTO Cost Map and Endpoint Cost Service provide only cost 170 information on an end-to-end path defined by its endpoints: The base protocol [RFC7285] allows the 172 services to expose the topological distances of end-to-end paths, 173 while various extensions have been proposed to extend the capability 174 of these services, e.g., to express other performance metrics 175 [I-D.ietf-alto-performance-metrics], to query multiple costs 176 simultaneously [RFC8189], and to obtain the time-varying values 177 [I-D.ietf-alto-cost-calendar]. 179 While the existing extensions are sufficient for many overlay 180 applications, however, the QoE of some overlay applications depends 181 not only on the cost information of end-to-end paths, but also on 182 particular components of a network on the paths and their properties. 183 For example, job completion time, which is an important QoE metric 184 for a large-scale data analytics application, is impacted by shared 185 bottleneck links inside the carrier network. We refer to such 186 components of a network as Abstract Network Elements (ANE). 188 Predicting such information can be very complex without the help of 189 the ISP [AAAI2019]. With proper guidance from the ISP, an overlay 190 application may be able to schedule its traffic for better QoE. In 191 the meantime, it may be helpful as well for ISPs if applications 192 could avoid using bottlenecks or challenging the network with poorly 193 scheduled traffic. 195 Despite the benefits, ISPs are not likely to expose details on their 196 network paths: first for the sake of confidentiality, second because 197 it may result in a huge volume and overhead, and last because it is 198 difficult for ISPs to figure out what information and what details an 199 application needs. Likewise, applications do not necessarily need 200 all the network path details and are likely not able to understand 201 them. 203 Therefore, it is beneficial for both parties if an ALTO server 204 provides ALTO clients with an "abstract network state" that provides 205 the necessary details to applications, while hiding the network 206 complexity and confidential information. An "abstract network state" 207 is a selected set of abstract representations of Abstract Network 208 Elements traversed by the paths between pairs 209 combined with properties of these Abstract Network Elements that are 210 relevant to the overlay applications' QoE. Both an application via 211 its ALTO client and the ISP via the ALTO server can achieve better 212 confidentiality and resource utilization by appropriately abstracting 213 relevant Abstract Network Elements. The pressure on the server 214 scalability can also be reduced by combining Abstract Network 215 Elements and their properties in a single response. 217 This document extends [RFC7285] to allow an ALTO server convey 218 "abstract network state", for paths defined by their pairs. To this end, it introduces a new cost type 220 called "Path Vector". A Path Vector is an array of identifiers that 221 each identifies an Abstract Network Element, which can be associated 222 with various properties. The associations between ANEs and their 223 properties are encoded in an ALTO information resource called Unified 224 Property Map, which is specified in 225 [I-D.ietf-alto-unified-props-new]. 227 For better confidentiality, this document aims to minimize 228 information exposure. In particular, this document enables and 229 recommends that first ANEs are constructed on demand, and second an 230 ANE is only associated with properties that are requested by an ALTO 231 client. A Path Vector response involves two ALTO Maps: the Cost Map 232 that contains the Path Vector results and the up-to-date Unified 233 Property Map that contains the properties requested for these ANEs. 234 To enforce consistency and improve server scalability, this document 235 uses the "multipart/related" message defined in [RFC2387] to return 236 the two maps in a single response. 238 The rest of the document is organized as follows. Section 3 239 introduces the extra terminologies that are used in this document. 240 Section 4 uses an illustrative example to introduce the additional 241 requirements of the ALTO framework, and discusses potential use 242 cases. Section 5 gives an overview of the protocol design. 243 Section 6 and Section 7 specify the Path Vector extension to the ALTO 244 IRD and the information resources, with some concrete examples 245 presented in Section 8. Section 9 discusses the backward 246 compatibility with the base protocol and existing extensions. 247 Security and IANA considerations are discussed in Section 11 and 248 Section 12 respectively. 250 2. Requirements Languages 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 254 "OPTIONAL" in this document are to be interpreted as described in BCP 255 14 [RFC2119] [RFC8174] when, and only when, they appear in all 256 capitals, as shown here. 258 When the words appear in lower case, they are to be interpreted with 259 their natural language meanings. 261 3. Terminology 263 NOTE: This document depends on the Unified Property Map extension 264 [I-D.ietf-alto-unified-props-new] and should be processed after the 265 Unified Property Map document. 267 This document extends the ALTO base protocol [RFC7285] and the 268 Unified Property Map extension [I-D.ietf-alto-unified-props-new]. In 269 addition to the terms defined in these documents, this document also 270 uses the following additional terms: 272 * Abstract Network Element (ANE): An Abstract Network Element is an 273 abstract representation for a component in a network that handle 274 data packets and whose properties can potentially have an impact 275 on the end-to-end performance of traffic. An ANE can be a 276 physical device such as a router, a link or an interface, or an 277 aggregation of devices such as a subnetwork, or a data center. 279 The definition of Abstract Network Element is similar to Network 280 Element defined in [RFC2216] in the sense that they both provide 281 an abstract representation of particular components of a network. 282 However, they have different criteria on how these particular 283 components are selected. Specifically, Network Element requires 284 the components to be potentially capable of exercising QoS 285 control, while Abstract Network Element only requires the 286 components to have an impact on the end-to-end performance. 288 * ANE Name: An ANE can be constructed either statically in advance 289 or on demand based on the requested information. Thus, different 290 ANEs may only be valid within a particular scope, either ephemeral 291 or persistent. Within each scope, an ANE is uniquely identified 292 by an ANE Name, as defined in Section 6.1. Note that an ALTO 293 client must not assume ANEs in different scopes but with the same 294 ANE Name refer to the same component(s) of the network. 296 * Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array 297 of ANE Names. It is defined either for a source PID and a 298 destination PID as in a cost map or for a source endpoint and a 299 destination endpoint as in an endpoint cost map. Specifically, 300 each ANE Name in a Path Vector indicates that the ANE is on the 301 path between the source and the destination. 303 * Path Vector resource: A Path Vector resource refers to an ALTO 304 resource which supports the extension defined in this document. 306 * Path Vector cost type: The Path Vector cost type is a special cost 307 type, which is specified in Section 6.5. When this cost type is 308 present in an IRD entry, it indicates that the information 309 resource is a Path Vector resource. When this cost type is 310 present in a Cost Map or an Endpoint Cost Map, it indicates each 311 cost value must be interpreted as a Path Vector. 313 * Path Vector request: A Path Vector request refers to the POST 314 message sent to an ALTO Path Vector resource. 316 * Path Vector response: A Path Vector response refers to the 317 multipart/related message returned by a Path Vector resource. 319 4. Problem Statement 320 4.1. Design Requirements 322 This section gives an illustrative example of how an overlay 323 application can benefit from the Path Vector extension. 325 Assume that an application has control over a set of flows, which may 326 go through shared links or switches and share a bottleneck. The 327 application hopes to schedule the traffic among multiple flows to get 328 better performance. The capacity region information for those flows 329 will benefit the scheduling. However, existing cost maps can not 330 reveal such information. 332 Specifically, consider a network as shown in Figure 1. The network 333 has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches 334 sw1/sw3 provide access on one side, sw2/sw4 provide access on the 335 other side, and sw5-sw7 form the backbone. Endhosts eh1 to eh4 are 336 connected to access switches sw1 to sw4 respectively. Assume that 337 the bandwidth of link eh1 -> sw1 and link sw1 -> sw5 are 150 Mbps, 338 and the bandwidth of the rest links are 100 Mbps. 340 +------+ 341 | | 342 --+ sw6 +-- 343 / | | \ 344 PID1 +-----+ / +------+ \ +-----+ PID2 345 eh1__| |_ / \ ____| |__eh2 346 1.2.3.4 | sw1 | \ +--|---+ +---|--+ / | sw2 | 2.3.4.5 347 +-----+ \ | | | |/ +-----+ 348 \_| sw5 +---------+ sw7 | 349 PID3 +-----+ / | | | |\ +-----+ PID4 350 eh3__| |__/ +------+ +------+ \____| |__eh4 351 3.4.5.6 | sw3 | | sw4 | 4.5.6.7 352 +-----+ +-----+ 354 Figure 1: Raw Network Topology 356 The single-node ALTO topology abstraction of the network is shown in 357 Figure 2. 359 +----------------------+ 360 {eh1} | | {eh2} 361 PID1 | | PID2 362 +------+ +------+ 363 | | 364 | | 365 {eh3} | | {eh4} 366 PID3 | | PID4 367 +------+ +------+ 368 | | 369 +----------------------+ 371 Figure 2: Base Single-Node Topology Abstraction 373 Consider an application overlay (e.g., a large-scale data analytics 374 system) which wants to optimize the total throughput of the traffic 375 among a set of end host pairs, say eh1 -> eh2 376 and eh1 -> eh4. The application can request a cost map providing 377 end-to-end available bandwidth, using "availbw" as cost-metric and 378 "numerical" as cost-mode. 380 The application will receive from the ALTO server that the bandwidth 381 of eh1 -> eh2 and eh1 -> eh4 are both 100 Mbps. But this information 382 is not enough to determine the optimal total throughput. Consider 383 the following two cases: 385 * Case 1: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw6 -> 386 sw7 -> sw2 -> eh2 and eh1 -> eh4 uses path eh1 -> sw1 -> sw5 -> 387 sw7 -> sw4 -> eh4, then the application will obtain 150 Mbps at 388 most. 390 * Case 2: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw7 -> 391 sw2 -> eh2 and eh1 -> eh4 uses the path eh1 -> sw1 -> sw5 -> sw7 392 -> sw4 -> eh4, then the application will obtain only 100 Mbps at 393 most. 395 To allow applications to distinguish the two aforementioned cases, 396 the network needs to provide more details. In particular: 398 * For eh1 -> eh2, the ALTO server must give more details which is 399 critical for the overlay application to distinguish between Case 1 400 and Case 2 and to compute the optimal total throughput 401 accordingly. 403 * The ALTO server must allow the client to distinguish the common 404 ANE shared by eh1 -> eh2 and eh1 -> eh4, e.g., eh1 - sw1 and sw1 - 405 sw5 in Case 1. 407 * The ALTO server must give details on the properties of the ANEs 408 used by eh1 -> eh2 and eh1 -> eh4, e.g., the available bandwidth 409 between eh1 - sw1, sw1 - sw5, sw5 - sw7, sw5 - sw6, sw6 - sw7, sw7 410 - sw2, sw7 - sw4, sw2 - eh2, sw4 - eh4 in Case 1. 412 In general, we can conclude that to support the multiple flow 413 scheduling use case, the ALTO framework must be extended to satisfy 414 the following additional requirements: 416 AR1: An ALTO server must provide essential information on ANEs on 417 the path of a pair that are critical to the 418 QoE of the overlay application. 420 AR2: An ALTO server must provide essential information on how the 421 paths of different pairs share a common ANE. 423 AR3: An ALTO server must provide essential information on the 424 properties associated to the ANEs. 426 The Path Vector extension defined in this document propose a solution 427 to provide these details. 429 4.2. Use Cases 431 While the multiple flow scheduling problem is used to help identify 432 the additional requirements, the Path Vector extension can be applied 433 to a wide range of applications. This section highlights some real 434 use cases that are reported. 436 4.2.1. Large-scale Data Analytics 438 One potential use case of the Path Vector extension is for large- 439 scale data analytics such as [SENSE] and [LHC], where data of 440 Gigabytes, Terabytes and even Petabytes are transferred. For these 441 applications, the QoE is usually measured as the job completion time, 442 which is related to the completion time of the slowest data transfer. 443 With the Path Vector extension, an ALTO client can identify 444 bottlenecks inside the network. Therefore, the overlay application 445 can make optimal traffic distribution or resource reservation (i.e., 446 proportional to the size of the transferred data), leading to optimal 447 job completion time and network resource utilization. 449 4.2.2. Context-aware Data Transfer 451 It is getting important to know the capabilities of various ANEs 452 between two end hosts, especially in the mobile environment. With 453 the Path Vector extension, an ALTO client may query the "network 454 context" information, i.e., whether the two hosts are connected to 455 the access network through a wireless link or a wire, and the 456 capabilities of the access network. Thus, the client may use 457 different data transfer mechanisms, or even deploy different 5G User 458 Plane Functions (UPF) [I-D.ietf-dmm-5g-uplane-analysis] to optimize 459 the data transfer. 461 4.2.3. CDN and Service Edge 463 A growing trend in today's applications is to bring storage and 464 computation closer to the end user for better QoE, such as Content 465 Delivery Network (CDN), AR/VR, and cloud gaming, as reported in 466 various documents ([I-D.contreras-alto-service-edge], 467 [I-D.huang-alto-mowie-for-network-aware-app], and 468 [I-D.yang-alto-deliver-functions-over-networks]). 470 With the Path Vector extension, an ALTO server can selectively reveal 471 the CDNs and service edges that reside along the paths between 472 different end hosts, together with their properties such as available 473 Service Level Agreement (SLA) plans. Otherwise, the ALTO client may 474 have to make multiple queries and potentially with the complete list 475 of CDNs and/or service edges. While both approaches offer the same 476 information, making multiple queries introduces larger delay and more 477 overhead on both the ALTO server and the ALTO client. 479 5. Path Vector Extension: Overview 481 This section gives a non-normative overview of the Path Vector 482 extension. It is assumed that readers are familiar with both the 483 base protocol [RFC7285] and the Unified Property Map extension 484 [I-D.ietf-alto-unified-props-new]. 486 To satisfies the additional requirements, this extension: 488 1. introduces Abstract Network Element (ANE) as the abstraction of 489 components in a network whose properties may have an impact on 490 the end-to-end performance of the traffic handled by those 491 component, 493 2. extends the Cost Map and Endpoint Cost Service to convey the ANEs 494 traversed by the path of a pair as Path 495 Vectors, 497 3. uses the Unified Property Map to convey the association between 498 the ANEs and their properties. 500 Thus, an ALTO client can learn about the ANEs that are critical to 501 the QoE of a pair by investigating the 502 corresponding Path Vector value (AR1), identify common ANEs if an ANE 503 appears in the Path Vectors of multiple pairs 504 (AR2), and retrieve the properties of the ANEs by searching the 505 Unified Property Map (AR3). 507 5.1. Abstract Network Element 509 This extension introduces Abstract Network Element (ANE) as an 510 indirect and network-agnostic way to specify a component or an 511 aggregation of components of a network whose properties have an 512 impact on the end-to-end performance for traffic between a source and 513 a destination. 515 When an ANE is defined by the ALTO server, it MUST be assigned an 516 identifier, i.e., string of type ANEName as specified in Section 6.1, 517 and a set of associated properties. 519 5.1.1. ANE Domain 521 In this extension, the associations between ANE and the properties 522 are conveyed in a Unified Property Map. Thus, they must follow the 523 mechanisms specified in the [I-D.ietf-alto-unified-props-new]. 525 Specifically, this document defines a new entity domain called "ane" 526 as specified in Section 6.2 and defines two initial properties for 527 the "ane" domain. 529 5.1.2. Ephemeral ANE and Persistent ANE 531 For different requests, there can be different ways of grouping 532 components of a network and assigning ANEs. For example, an ALTO 533 server may define an ANE for each aggregated bottleneck link between 534 the sources and destinations specified in the request. As the 535 aggregated bottleneck links vary for different combinations of 536 sources and destinations, the ANEs are ephemeral and are no longer 537 valid after the request completes. Thus, the scope of ephemeral ANEs 538 are limited to the corresponding Path Vector response. 540 While ephemeral ANEs returned by a Path Vector response do not exist 541 beyond that response, some of them may represent entities that are 542 persistent and defined in a standalone Property Map. Indeed, it may 543 be useful for clients to occasionally query properties on persistent 544 entities, without caring about the path that traverses them. 545 Persistent entities have a persistent ID that is registered in a 546 Property Map, together with their properties. 548 5.1.3. Property Filtering 550 Resource-constrained ALTO clients may benefit from the filtering of 551 Path Vector query results at the ALTO server, as an ALTO client may 552 only require a subset of the available properties. 554 Specifically, the available properties for a given resource are 555 announced in the Information Resource Directory as a new capability 556 called "ane-property-names". The selected properties are specified 557 in a filter called "ane-property-names" in the request body, and the 558 response MUST only return the selected properties for the ANEs in the 559 response. 561 The "ane-property-names" capability for Cost Map and for Endpoint 562 Cost Service are specified in Section 7.1.4 and Section 7.2.4 563 respectively. The "ane-property-names" filter for Cost Map and 564 Endpoint Cost Service are specified in Section 7.1.3 and 565 Section 7.2.3 accordingly. 567 5.2. Path Vector Cost Type 569 For an ALTO client to correctly interpret the Path Vector, this 570 extension specifies a new cost type called the Path Vector cost type, 571 which must be included both in the Information Resource Directory and 572 the ALTO Cost Map or Endpoint Cost Map so that an ALTO client can 573 correctly interpret the cost values. 575 The Path Vector cost type must convey both the interpretation and 576 semantics in the "cost-mode" and "cost-metric" respectively. 577 Unfortunately, a single "cost-mode" value cannot fully specify the 578 interpretation of a Path Vector, which is a compound data type. For 579 example, in programming languages such as Java, a Path Vector will 580 have the type of JSONArray[ANEName]. 582 Instead of extending the "type system" of ALTO, this document takes a 583 simple and backward compatible approach. Specifically, the "cost- 584 mode" of the Path Vector cost type is "array", which indicates the 585 value is a JSON array. Then, an ALTO client must check the value of 586 the "cost-metric". If the value is "ane-path", meaning the JSON 587 array should be further interpreted as a path of ANENames. 589 The Path Vector cost type is specified in Section 6.5. 591 5.3. Multipart Path Vector Response 593 For a basic ALTO information resource, a response contains only one 594 type of ALTO resources, e.g., Network Map, Cost Map, or Property Map. 595 Thus, only one round of communication is required: An ALTO client 596 sends a request to an ALTO server, and the ALTO server returns a 597 response, as shown in Figure 3. 599 ALTO client ALTO server 600 |-------------- Request ---------------->| 601 |<------------- Response ----------------| 603 Figure 3: A Typical ALTO Request and Response 605 The Path Vector extension, on the other hand, involves two types of 606 information resources: Path Vectors conveyed in a Cost Map or an 607 Endpoint Cost Map, and ANE properties conveyed in a Unified Property 608 Map. Instead of two consecutive message exchanges, the Path Vector 609 extension enforces one round of communication. Specifically, the 610 ALTO client must include the source and destination pairs and the 611 requested ANE properties in a single request, and the ALTO server 612 must encapsulate both Path Vectors and properties associated with the 613 ANEs in a single response, as shown in Figure 4. Since the two parts 614 are bundled together in one response message, their orders are 615 interchangeable. See Section 7.1.6 and Section 7.2.6 for details. 617 ALTO client ALTO server 618 |------------- PV Request -------------->| 619 |<----- PV Response (Cost Map Part) -----| 620 |<--- PV Response (Property Map Part) ---| 622 Figure 4: The Path Vector Extension Request and Response 624 This design is based on the following considerations: 626 1. Since ANEs may be constructed on demand, and potentially based on 627 the requested properties (See Section 5.1 for more details). If 628 sources and destinations are not in the same request as the 629 properties, an ALTO server either cannot construct ANEs on- 630 demand, or must wait until both requests are received. 632 2. As ANEs may be constructed on demand, mappings of each ANE to its 633 underlying network devices and resources can be specific to the 634 request. In order to respond to the Property Map request 635 correctly, an ALTO server must store the mapping of each Path 636 Vector request until the client fully retrieves the property 637 information. The "stateful" behavior may substantially harm the 638 server scalability and potentially lead to Denial-of-Service 639 attacks. 641 One approach to realize the one-round communication is to define a 642 new media type to contain both objects, but this violates modular 643 design. This document follows the standard-conforming usage of 644 "multipart/related" media type defined in [RFC2387] to elegantly 645 combine the objects. Path Vectors are encoded as a Cost Map or an 646 Endpoint Cost Map, and the Property Map is encoded as a Unified 647 Propert Map. They are encapsulated as parts of a multipart message. 648 The modular composition allows ALTO servers and clients to reuse the 649 data models of the existing information resources. Specifically, 650 this document addresses the following practical issues using 651 "multipart/related". 653 5.3.1. Identifying the Media Type of the Root Object 655 ALTO uses media type to indicate the type of an entry in the 656 Information Resource Directory (IRD) (e.g., "application/alto- 657 costmap+json" for Cost Map and "application/alto-endpointcost+json" 658 for Endpoint Cost Map). Simply putting "multipart/related" as the 659 media type, however, makes it impossible for an ALTO client to 660 identify the type of service provided by related entries. 662 To address this issue, this document uses the "type" parameter to 663 indicate the root object of a multipart/related message. For a Cost 664 Map resource, the "media-type" in the IRD entry must be "multipart/ 665 related" with the parameter "type=application/alto-costmap+json"; for 666 an Endpoint Cost Service, the parameter must be "type=application/ 667 alto-endpointcost+json". 669 5.3.2. References to Part Messages 671 The ALTO SSE extension (see [I-D.ietf-alto-incr-update-sse]) uses 672 "client-id" to demultiplex push updates. However, "client-id" is 673 provided for each request, which introduces ambiguity when applying 674 SSE to a Path Vector resource. 676 To address this issue, an ALTO server must assign a unique identifier 677 to each part of the "multipart/related" response message. This 678 identifier, referred to as a Part Resource ID (See Section 6.6 for 679 details), must be present in the part message's "Resource-Id" header. 680 The MIME part header must also contain the "Content-Type" header, 681 whose value is the media type of the part (e.g., "application/alto- 682 costmap+json", "application/alto-endpointcost+json", or "application/ 683 alto-propmap+json"). 685 If an ALTO server provides incremental updates for this Path Vector 686 resource, it must generate incremental updates for each part 687 separately. The client-id must have the following format: 689 pv-client-id '.' part-resource-id 691 where pv-client-id is the client-id assigned to the Path Vector 692 request, and part-resource-id is the "Resource-Id" header value of 693 the part. The media-type must match the "Content-Type" of the part. 695 The same problem applies to the part messages as well. The two parts 696 must contain a version tag, which SHOULD contain a unique Resource 697 ID. This document requires the resource-id in a Version Tag to have 698 the following format: 700 pv-resource-id '.' part-resource-id 702 where pv-resource-id is the resource ID of the Path Vector resource 703 in the IRD entry, and the part-resource-id has the same value as the 704 "Resource-Id" header of the part. 706 5.3.3. Order of Part Messages 708 According to [RFC2387], the Path Vector part, whose media type is the 709 same as the "type" parameter of the multipart response message, is 710 the root object. Thus, it is the element the application processes 711 first. Even though the "start" parameter allows it to be placed 712 anywhere in the part sequence, it is RECOMMENDED that the parts 713 arrive in the same order as they are processed, i.e., the Path Vector 714 part is always put as the first part, followed by the property map 715 part. It is also RECOMMENDED that when doing so, an ALTO server 716 SHOULD NOT set the "start" parameter, which implies the first part is 717 the root object. 719 6. Specification: Basic Data Types 721 6.1. ANE Name 723 An ANE Name is encoded as a JSON string with the same format as that 724 of the type PIDName (Section 10.1 of [RFC7285]). 726 The type ANEName is used in this document to indicate a string of 727 this format. 729 6.2. ANE Domain 731 The ANE domain associates property values with the Abstract Network 732 Elements in a Property Map. Accordingly, the ANE domain always 733 depends on a Property Map. 735 6.2.1. Entity Domain Type 737 ane 739 6.2.2. Domain-Specific Entity Identifier 741 The entity identifiers are the ANE Names in the associated Property 742 Map. 744 6.2.3. Hierarchy and Inheritance 746 There is no hierarchy or inheritance for properties associated with 747 ANEs. 749 6.2.4. Media Type of Defining Resource 751 When resource specific domains are defined with entities of domain 752 type "ane", the defining resource for entity domain type "pid" MUST 753 be a Property Map. The media type of defining resources for the "ane" 754 domain is: 756 application/alto-propmap+json 758 Specifically, for ephemeral ANEs that appear in a Path Vector 759 response, their entity domain names MUST be ".ane" and the defining 760 resource of these ANEs is the Property Map part of the multipart 761 response. Meanwhile, for persistent ANEs whose entity domain name 762 has the format of "PROPMAP.ane" where PROPMAP is the name of a 763 Property Map resource, PROPMAP is the defining resource of these 764 ANEs. 766 For example, the defining resource of ".ane:NET1" is the Property Map 767 part that contains this identifier, i.e., the ANE entity ".ane:NET1" 768 is self-defined. The defining resource of "dc-props.ane:DC1" is the 769 Property Map with the resource ID "dc-props". 771 6.3. ANE Property Name 773 An ANE Property Name is encoded as a JSON string with the same format 774 as that of Entity Property Name (Section 5.2.2 of 775 [I-D.ietf-alto-unified-props-new]). 777 6.4. Initial ANE Property Types 779 In this document, two initial ANE property types are specified, "max- 780 reservable-bandwidth" and "persistent-entity-id". 782 Note that the two property types defined in this document do not 783 depend on any information resource, so their ResourceID part must be 784 empty. 786 ----- L1 787 / 788 PID1 +---------------+ 10 Gbps +----------+ PID3 789 1.2.3.0/24+---+ +-----------+ +---------+ +---+3.4.5.0/24 790 | | MEC1 | | | | 791 | +-----------+ | +-----+ | 792 PID2 | | | +----------+ 793 2.3.4.0/24+---+ | | NET3 794 | | | 15 Gbps 795 | | | \ 796 +---------------+ | -------- L2 797 NET1 | 798 +---------------+ 799 | +-----------+ | PID4 800 | | MEC2 | +---+4.5.6.0/24 801 | +-----------+ | 802 +---------------+ 803 NET2 805 Figure 5: Examples of ANE Properties 807 In this document, Figure 5 is used to illustrate the use of the two 808 initial ANE property types. There are 3 sub-networks (NET1, NET2 and 809 NET3) and two interconnection links (L1 and L2). It is assumed that 810 each sub-network has sufficiently large bandwidth to be reserved. 812 6.4.1. New ANE Property Type: Maximum Reservable Bandwidth 814 Identifier: "max-reservable-bandwidth" 816 Intended Semantics: The maximum reservable bandwidth property stands 817 for the maximum bandwidth that can be reserved for all the traffic 818 that traverses an ANE. The value MUST be encoded as a non- 819 negative numerical cost value as defined in Section 6.1.2.1 of 820 [RFC7285] and the unit is bit per second. If this property is 821 requested but not present in an ANE, it MUST be interpreted as 822 that the ANE does not support bandwidth reservation. 824 Security Considerations: ALTO entity properties expose information 825 to ALTO clients. ALTO service providers should be made aware of 826 the security ramifications related to the exposure of an entity 827 property. 829 To illustrate the use of "max-reservable-bandwidth", consider the 830 network in Figure 5. An ALTO server can create an ANE for each 831 interconnection link, where the initial value for "max-reservable- 832 bandwidth" is the link capacity. 834 6.4.2. New ANE Property Type: Persistent Entity ID 836 Identifier: "persistent-entity-id" 838 Intended Semantics: The persistent entity ID property is the entity 839 identifier of the persistent ANE which an ephemeral ANE presents 840 (See Section 5.1.2 for details). The value of this property is 841 encoded with the format defined in Section 5.1.3 of 842 [I-D.ietf-alto-unified-props-new]. In this format, the entity ID 843 combines: 845 * a defining information resource for the ANE on which a 846 "persistent-entity-id" is queried, which is the property map 847 defining the ANE as a persistent entity, together with the 848 properties 850 * the persistent name of the ANE in this property map 852 With this format, the client has all the needed information for 853 further standalone query properties on the persistent ANE. 855 Security Considerations: ALTO entity properties expose information 856 to ALTO clients. ALTO service providers should be made aware of 857 the security ramifications related to the exposure of an entity 858 property. 860 To illustrate the use of "persistent-entity-id", consider the network 861 in Figure 5. Assume the ALTO server has a Property Map resource 862 called "mec-props" that defines persistent ANEs "MEC1" and "MEC2" 863 that represent the corresponding mobile edge computing (MEC) 864 clusters. Since MEC1 is associated with NET1, the "persistent- 865 entity-id" of the ephemeral ANE ".ane:NET1" is the persistent entity 866 id "mec-props.ane:MEC1". 868 6.5. Path Vector Cost Type 870 This document defines a new cost type, which is referred to as the 871 "Path Vector" cost type. An ALTO server MUST offer this cost type if 872 it supports the Path Vector extension. 874 6.5.1. Cost Metric: ane-path 876 The cost metric "ane-path" indicates the value of such a cost type 877 conveys an array of ANE names, where each ANE name uniquely 878 represents an ANE traversed by traffic from a source to a 879 destination. 881 An ALTO client MUST interpret the Path Vector as if the traffic 882 between a source and a destination logically traverses the ANEs in 883 the same order as they appear in the Path Vector. However, under 884 certain scenarios where the traversal order is not crucial, an ALTO 885 server implementation may choose to not follow strictly the physical 886 traversal order and may even obfuscate the order intentionally, for 887 security and performance considerations. For example, in the multi- 888 flow bandwidth reservation use case as introduced in Section 4, only 889 the available bandwidth of the shared bottleneck link is crucial, and 890 the ALTO server may change the order of links appearing in the Path 891 Vector response. 893 6.5.2. Cost Mode: array 895 The cost mode "array" indicates that every cost value in a Cost Map 896 or an Endpoint Cost Map MUST be interpreted as a JSON array object. 898 Note that this cost mode only requires the cost value to be a JSON 899 array of JSONValue. However, an ALTO server that enables this 900 extension MUST return a JSON array of ANEName (Section 6.1) when the 901 cost metric is "ane-path". 903 6.6. Part Resource ID 905 A Part Resource ID is encoded as a JSON string with the same format 906 as that of the type ResourceID (Section 10.2 of [RFC7285]). 908 Even though the client-id assigned to a Path Vector request and the 909 Part Resource ID MAY contain up to 64 characters by their own 910 definition, their concatenation (see Section 5.3.2) MUST also conform 911 to the same length constraint. The same requirement applies to the 912 resource ID of the Path Vector resource, too. Thus, it is 913 RECOMMENDED to limit the length of resource ID and client ID related 914 to a Path Vector resource to 31 characters. 916 7. Specification: Service Extensions 917 7.1. Multipart Filtered Cost Map for Path Vector 919 This document introduces a new ALTO resource called multipart 920 filtered cost map resource, which allows an ALTO server to provide 921 other ALTO resources associated to the cost map resource in the same 922 response. 924 7.1.1. Media Type 926 The media type of the multipart filtered cost map resource is 927 "multipart/related;type=application/alto-costmap+json". 929 7.1.2. HTTP Method 931 The multipart filtered cost map is requested using the HTTP POST 932 method. 934 7.1.3. Accept Input Parameters 936 The input parameters of the multipart filtered cost map are supplied 937 in the body of an HTTP POST request. This document extends the input 938 parameters to a filtered cost map with a data format indicated by the 939 media type "application/alto-costmapfilter+json", which is a JSON 940 object of type PVReqFilteredCostMap, where: 942 object { 943 [EntityPropertyName ane-property-names<0..*>;] 944 } PVReqFilteredCostMap : ReqFilteredCostMap; 946 with fields: 948 ane-property-names: A list of properties that are associated with 949 the ANEs. Each property in this list MUST match one of the 950 supported ANE properties indicated in the resource's "ane- 951 property-names" capability. If the field is NOT present, it MUST 952 be interpreted as an empty list, indicating that the ALTO server 953 MUST NOT return any property in the Unified Property part. 955 Example: Consider the network in Figure 1. If an ALTO client wants 956 to query the "max-reservable-bandwidth" between PID1 and PID2, it can 957 submit the following request. 959 POST /costmap/pv HTTP/1.1 960 Host: alto.example.com 961 Accept: multipart/related;type=application/alto-costmap+json, 962 application/alto-error+json 963 Content-Length: [TBD] 964 Content-Type: application/alto-costmapfilter+json 966 { 967 "cost-type": { 968 "cost-mode": "array", 969 "cost-metric": "ane-path" 970 }, 971 "pids": { 972 "srcs": [ "PID1" ], 973 "dsts": [ "PID2" ] 974 }, 975 "ane-property-names": [ "max-reservable-bandwidth" ] 976 } 978 7.1.4. Capabilities 980 The multipart filtered cost map resource extends the capabilities 981 defined in Section 11.3.2.4 of [RFC7285]. The capabilities are 982 defined by a JSON object of type PVFilteredCostMapCapabilities: 984 object { 985 [EntityPropertyName ane-property-names<0..*>;] 986 } PVFilteredCostMapCapabilities : FilteredCostMapCapabilities; 988 with fields: 990 cost-type-names: The "cost-type-names" field MUST only include the 991 Path Vector cost type, unless explicitly documented by a future 992 extension. This also implies that the Path Vector cost type MUST 993 be defined in the "cost-types" of the Information Resource 994 Directory's "meta" field. 996 cost-constraints: If the "cost-type-names" field includes the Path 997 Vector cost type, "cost-constraints" field MUST be "false" or not 998 present unless specifically instructed by a future document. 1000 testable-cost-type-names: If the "cost-type-names" field includes 1001 the Path Vector cost type, the Path Vector cost type MUST NOT be 1002 included in the "testable-cost-type-names" field unless 1003 specifically instructed by a future document. 1005 ane-property-names: Defines a list of ANE properties that can be 1006 returned. If the field is NOT present, it MUST be interpreted as 1007 an empty list, indicating the ALTO server cannot provide any ANE 1008 property. 1010 7.1.5. Uses 1012 This member MUST include the resource ID of the network map based on 1013 which the PIDs are defined. If this resource supports "persistent- 1014 entity-id", it MUST also include the defining resources of persistent 1015 ANEs that may appear in the response. 1017 7.1.6. Response 1019 The response MUST indicate an error, using ALTO protocol error 1020 handling, as defined in Section 8.5 of [RFC7285], if the request is 1021 invalid. 1023 The "Content-Type" header of the response MUST be "multipart/related" 1024 as defined by [RFC2387] with the following parameters: 1026 type: The type parameter MUST be "application/alto-costmap+json". 1027 Note that [RFC2387] permits both parameters with and without the 1028 double quotes. 1030 start: The start parameter is as defined in [RFC2387]. If present, 1031 it MUST have the same value as the "Resource-Id" header of the 1032 Path Vector part. 1034 boundary: The boundary parameter is as defined in [RFC2387]. 1036 The body of the response MUST consist of two parts: 1038 * The Path Vector part MUST include "Resource-Id" and "Content-Type" 1039 in its header. The value of "Resource-Id" MUST has the format of 1040 a Part Resource ID. The "Content-Type" MUST be "application/alto- 1041 costmap+json". 1043 The body of the Path Vector part MUST be a JSON object with the 1044 same format as defined in Section 11.2.3.6 of [RFC7285]. The JSON 1045 object MUST include the "vtag" field in the "meta" field, which 1046 provides the version tag of the returned cost map. The resource 1047 ID of the version tag MUST follow the format in Section 5.3.2. 1048 The "meta" field MUST also include the "dependent-vtags" field, 1049 whose value is a single-element array to indicate the version tag 1050 of the network map used, where the network map is specified in the 1051 "uses" attribute of the multipart filtered cost map resource in 1052 IRD. 1054 * The Unified Property Map part MUST also include "Resource-Id" and 1055 "Content-Type" in its header. The value of "Resource-Id" has the 1056 format of a Part Resource ID. The "Content-Type" MUST be 1057 "application/alto-propmap+json". 1059 The body of the Unified Property Map part MUST be a JSON object 1060 with the same format as defined in Section 4.6 of 1061 [I-D.ietf-alto-unified-props-new]. The JSON object MUST include 1062 the "dependent-vtags" field in the "meta" field. The value of the 1063 "dependent-vtags" field MUST be an array of VersionTag objects as 1064 defined by Section 10.3 of [RFC7285]. The "vtag" of the Path 1065 Vector part MUST be included in the "dependent-vtags". If 1066 "persistent-entity-id" is requested, the version tags of the 1067 dependent resources that MAY expose the entities in the response 1068 MUST also be included. The PropertyMapData has one member for 1069 each ANEName that appears in the Path Vector part, which is an 1070 entity identifier belonging to the self-defined entity domain as 1071 defined in Section 5.1.2.3 of [I-D.ietf-alto-unified-props-new]. 1072 The EntityProps has one member for each property requested by an 1073 ALTO client if applicable. 1075 If the "start" parameter is not present, the Path Vector part MUST be 1076 the first part in the multipart response. If any part is NOT 1077 present, the client MUST discard the received information and send 1078 another request if necessary. 1080 Example: Consider the network in Figure 1. The response of the 1081 example request in Section 7.1.3 is as follows, where "ANE1" 1082 represents the aggregation of all the switches in the network. 1084 HTTP/1.1 200 OK 1085 Content-Length: [TBD] 1086 Content-Type: multipart/related; boundary=example-1; 1087 type=application/alto-costmap+json 1089 --example-1 1090 Resource-Id: costmap 1091 Content-Type: application/alto-costmap+json 1093 { 1094 "meta": { 1095 "vtag": { 1096 "resource-id": "filtered-cost-map-pv.costmap", 1097 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1098 }, 1099 "dependent-vtags": [ 1100 { 1101 "resource-id": "my-default-networkmap", 1102 "tag": "75ed013b3cb58f896e839582504f6228" 1103 } 1104 ], 1105 "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" } 1106 }, 1107 "cost-map": { 1108 "PID1": { "PID2": ["ANE1"] } 1109 } 1110 } 1111 --example-1 1112 Resource-Id: propmap 1113 Content-Type: application/alto-propmap+json 1115 { 1116 "meta": { 1117 "dependent-vtags": [ 1118 { 1119 "resource-id": "filtered-cost-map-pv.costmap", 1120 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1121 } 1122 ] 1123 }, 1124 "property-map": { 1125 ".ane:ANE1": { "max-reservable-bandwidth": 100000000 } 1126 } 1127 } 1129 7.2. Multipart Endpoint Cost Service for Path Vector 1131 This document introduces a new ALTO resource called multipart 1132 endpoint cost resource, which allows an ALTO server to provide other 1133 ALTO resources associated to the endpoint cost resource in the same 1134 response. 1136 7.2.1. Media Type 1138 The media type of the multipart endpoint cost resource is 1139 "multipart/related;type=application/alto-endpointcost+json". 1141 7.2.2. HTTP Method 1143 The multipart endpoint cost resource is requested using the HTTP POST 1144 method. 1146 7.2.3. Accept Input Parameters 1148 The input parameters of the multipart endpoint cost resource are 1149 supplied in the body of an HTTP POST request. This document extends 1150 the input parameters to an endpoint cost map with a data format 1151 indicated by the media type "application/alto- 1152 endpointcostparams+json", which is a JSON object of type 1153 PVEndpointCostParams, where 1155 object { 1156 [EntityPropertyName ane-property-names<0..*>;] 1157 } PVReqEndpointcost : ReqEndpointcost; 1159 with fields: 1161 ane-property-names: This document defines the "ane-property-names" 1162 in PVReqEndpointcost as the same as in PVReqFilteredCostMap. See 1163 Section 7.1.3. 1165 Example: Consider the network in Figure 1. If an ALTO client wants 1166 to query the "max-reservable-bandwidth" between eh1 and eh2, it can 1167 submit the following request. 1169 POST /ecs/pv HTTP/1.1 1170 Host: alto.example.com 1171 Accept: multipart/related;type=application/alto-endpointcost+json, 1172 application/alto-error+json 1173 Content-Length: [TBD] 1174 Content-Type: application/alto-endpointcostparams+json 1176 { 1177 "cost-type": { 1178 "cost-mode": "array", 1179 "cost-metric": "ane-path" 1180 }, 1181 "endpoints": { 1182 "srcs": [ "ipv4:1.2.3.4" ], 1183 "dsts": [ "ipv4:2.3.4.5" ] 1184 }, 1185 "ane-property-names": [ "max-reservable-bandwidth" ] 1186 } 1188 7.2.4. Capabilities 1190 The capabilities of the multipart endpoint cost resource are defined 1191 by a JSON object of type PVEndpointcostCapabilities, which is defined 1192 as the same as PVFilteredCostMapCapabilities. See Section 7.1.4. 1194 7.2.5. Uses 1196 If this resource supports "persistent-entity-id", it MUST also 1197 include the defining resources of persistent ANEs that may appear in 1198 the response. 1200 7.2.6. Response 1202 The response MUST indicate an error, using ALTO protocol error 1203 handling, as defined in Section 8.5 of [RFC7285], if the request is 1204 invalid. 1206 The "Content-Type" header of the response MUST be "multipart/related" 1207 as defined by [RFC7285] with the following parameters: 1209 type: The type parameter MUST be "application/alto- 1210 endpointcost+json". 1212 start: The start parameter is as defined in Section 7.1.6. 1214 boundary: The boundary parameter is as defined in [RFC2387]. 1216 The body MUST consist of two parts: 1218 * The Path Vector part MUST include "Resource-Id" and "Content-Type" 1219 in its header. The value of "Resource-Id" MUST has the format of 1220 a Part Resource ID. The "Content-Type" MUST be "application/alto- 1221 endpointcost+json". 1223 The body of the Path Vector part MUST be a JSON object with the 1224 same format as defined in Section 11.5.1.6 of [RFC7285]. The JSON 1225 object MUST include the "vtag" field in the "meta" field, which 1226 provides the version tag of the returned endpoint cost map. The 1227 resource ID of the version tag MUST follow the format in 1228 Section 5.3.2. 1230 * The Unified Property Map part MUST also include "Resource-Id" and 1231 "Content-Type" in its header. The value of "Resource-Id" MUST has 1232 the format of a Part Resource ID. The "Content-Type" MUST be 1233 "application/alto-propmap+json". 1235 The body of the Unified Property Map part MUST be a JSON object 1236 with the same format as defined in Section 4.6 of 1237 [I-D.ietf-alto-unified-props-new]. The JSON object MUST include 1238 the "dependent-vtags" field in the "meta" field. The value of the 1239 "dependent-vtags" field MUST be an array of VersionTag objects as 1240 defined by Section 10.3 of [RFC7285]. The "vtag" of the Path 1241 Vector part MUST be included in the "dependent-vtags". If 1242 "persistent-entity-id" is requested, the version tags of the 1243 dependent resources that MAY expose the entities in the response 1244 MUST also be included. The PropertyMapData has one member for 1245 each ANEName that appears in the Path Vector part, which is an 1246 entity identifier belonging to the self-defined entity domain as 1247 defined in Section 5.1.2.3 of [I-D.ietf-alto-unified-props-new]. 1248 The EntityProps has one member for each property requested by the 1249 ALTO client if applicable. 1251 If the "start" parameter is not present, the Path Vector part MUST be 1252 the first part in the multipart response. If any part is NOT 1253 present, the client MUST discard the received information and send 1254 another request if necessary. 1256 Example: Consider the network in Figure 1. The response of the 1257 example request in Section 7.2.3 is as follows. 1259 HTTP/1.1 200 OK 1260 Content-Length: [TBD] 1261 Content-Type: multipart/related; boundary=example-1; 1262 type=application/alto-endpointcost+json 1264 --example-1 1265 Resource-Id: ecs 1266 Content-Type: application/alto-endpointcost+json 1268 { 1269 "meta": { 1270 "vtag": { 1271 "resource-id": "ecs-pv.costmap", 1272 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1273 }, 1274 "dependent-vtags": [ 1275 { 1276 "resource-id": "my-default-networkmap", 1277 "tag": "75ed013b3cb58f896e839582504f6228" 1278 } 1279 ], 1280 "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" } 1281 }, 1282 "cost-map": { 1283 "ipv4:1.2.3.4": { "ipv4:2.3.4.5": ["ANE1"] } 1284 } 1285 } 1286 --example-1 1287 Resource-Id: propmap 1288 Content-Type: application/alto-propmap+json 1290 { 1291 "meta": { 1292 "dependent-vtags": [ 1293 { 1294 "resource-id": "ecs-pv.costmap", 1295 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1296 } 1297 ] 1298 }, 1299 "property-map": { 1300 ".ane:ANE1": { "max-reservable-bandwidth": 100000000 } 1301 } 1302 } 1304 8. Examples 1306 This section lists some examples of Path Vector queries and the 1307 corresponding responses. Some long lines are truncated for better 1308 readability. 1310 8.1. Example: Information Resource Directory 1312 To give a comprehensive example of the Path Vector extension, we 1313 consider the network in Figure 5. The example ALTO server provides 1314 the following information resources: 1316 * "my-default-networkmap": A Network Map resource which contains the 1317 PIDs in the network. 1319 * "filtered-cost-map-pv": A Multipart Filtered Cost Map resource for 1320 Path Vector, which exposes the "max-reservable-bandwidth" property 1321 for the PIDs in "my-default-networkmap". 1323 * "ane-props": A filtered Unified Property resource that exposes the 1324 information for persistent ANEs in the network. 1326 * "endpoint-cost-pv": A Multipart Endpoint Cost Service for Path 1327 Vector, which exposes the "max-reservable-bandwidth" and the 1328 "persistent-entity-id" properties. 1330 * "update-pv": An Update Stream service, which provides the 1331 incremental update service for the "endpoint-cost-pv" service. 1333 Below is the Information Resource Directory of the example ALTO 1334 server. To enable the Path Vector extension, the "path-vector" cost 1335 type (Section 6.5) is defined in the "cost-types" of the "meta" 1336 field, and is included in the "cost-type-names" of resources 1337 "filetered-cost-map-pv" and "endpoint-cost-pv". 1339 { 1340 "meta": { 1341 "cost-types": { 1342 "path-vector": { 1343 "cost-mode": "array", 1344 "cost-metric": "ane-path" 1345 } 1346 } 1347 }, 1348 "resources": { 1349 "my-default-networkmap": { 1350 "uri" : "https://alto.example.com/networkmap", 1351 "media-type" : "application/alto-networkmap+json" 1353 }, 1354 "filtered-cost-map-pv": { 1355 "uri": "https://alto.example.com/costmap/pv", 1356 "media-type": "multipart/related; 1357 type=application/alto-costmap+json", 1358 "accepts": "application/alto-costmapfilter+json", 1359 "capabilities": { 1360 "cost-type-names": [ "path-vector" ], 1361 "ane-property-names": [ "max-reservable-bandwidth" ] 1362 }, 1363 "uses": [ "my-default-networkmap" ] 1364 }, 1365 "ane-props": { 1366 "uri": "https://alto.example.com/ane-props", 1367 "media-type": "application/alto-propmap+json", 1368 "accepts": "application/alto-propmapparams+json", 1369 "capabilities": { 1370 "mappings": { 1371 ".ane": [ "cpu" ] 1372 } 1373 } 1374 }, 1375 "endpoint-cost-pv": { 1376 "uri": "https://alto.exmaple.com/endpointcost/pv", 1377 "media-type": "multipart/related; 1378 type=application/alto-endpointcost+json", 1379 "accepts": "application/alto-endpointcostparams+json", 1380 "capabilities": { 1381 "cost-type-names": [ "path-vector" ], 1382 "ane-property-names": [ 1383 "max-reservable-bandwidth", "persistent-entity-id" 1384 ] 1385 }, 1386 "uses": [ "ane-props" ] 1387 }, 1388 "update-pv": { 1389 "uri": "https://alto.example.com/updates/pv", 1390 "media-type": "text/event-stream", 1391 "uses": [ "endpoint-cost-pv" ], 1392 "accepts": "application/alto-updatestreamparams+json", 1393 "capabilities": { 1394 "support-stream-control": true 1395 } 1396 } 1397 } 1398 } 1400 8.2. Example: Multipart Filtered Cost Map 1402 The following examples demonstrate the request to the "filtered-cost- 1403 map-pv" resource and the corresponding response. 1405 The request uses the "path-vector" cost type in the "cost-type" 1406 field. The "ane-property-names" field is missing, indicating that 1407 the client only requests for the Path Vector but not the ANE 1408 properties. 1410 The response consists of two parts. The first part returns the array 1411 of ANEName for each source and destination pair. There are two ANEs, 1412 where "L1" represents the interconnection link L1, and "L2" 1413 represents the interconnection link L2. 1415 The second part returns an empty Property Map. Note that the ANE 1416 entries are omitted since they have no properties (See Section 3.1 of 1417 [I-D.ietf-alto-unified-props-new]). 1419 POST /costmap/pv HTTP/1.1 1420 Host: alto.example.com 1421 Accept: multipart/related;type=application/alto-costmap+json, 1422 application/alto-error+json 1423 Content-Length: [TBD] 1424 Content-Type: application/alto-costmapfilter+json 1426 { 1427 "cost-type": { 1428 "cost-mode": "array", 1429 "cost-metric": "ane-path" 1430 }, 1431 "pids": { 1432 "srcs": [ "PID1" ], 1433 "dsts": [ "PID3", "PID4" ] 1434 } 1435 } 1437 HTTP/1.1 200 OK 1438 Content-Length: [TBD] 1439 Content-Type: multipart/related; boundary=example-1; 1440 type=application/alto-costmap+json 1442 --example-1 1443 Resource-Id: costmap 1444 Content-Type: application/alto-costmap+json 1446 { 1447 "meta": { 1448 "vtag": { 1449 "resource-id": "filtered-cost-map-pv.costmap", 1450 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1451 }, 1452 "dependent-vtags": [ 1453 { 1454 "resource-id": "my-default-networkmap", 1455 "tag": "75ed013b3cb58f896e839582504f6228" 1456 } 1457 ], 1458 "cost-type": { 1459 "cost-mode": "array", 1460 "cost-metric": "ane-path" 1461 } 1462 }, 1463 "cost-map": { 1464 "PID1": { 1465 "PID3": [ "L1" ], 1466 "PID4": [ "L1", "L2" ] 1467 } 1468 } 1469 } 1470 --example-1 1471 Resource-Id: propmap 1472 Content-Type: application/alto-propmap+json 1474 { 1475 "meta": { 1476 "dependent-vtags": [ 1477 { 1478 "resource-id": "filtered-cost-map-pv.costmap", 1479 "tag": "d827f484cb66ce6df6b5077cb8562b0a" 1480 } 1481 ] 1482 }, 1483 "property-map": { 1484 } 1485 } 1487 8.3. Example: Multipart Endpoint Cost Resource 1489 The following examples demonstrate the request to the "endpoint-cost- 1490 pv" resource and the corresponding response. 1492 The request uses the path vector cost type in the "cost-type" field, 1493 and queries the Maximum Reservable Bandwidth ANE property and the 1494 Persistent Entity property. 1496 The response consists of two parts. The first part returns the array 1497 of ANEName for each valid source and destination pair, where "NET1" 1498 represent sub-network NET1, and "AGGR" is the aggregation of L1 and 1499 NET3. 1501 The second part returns the requested properties of ANEs. Since NET1 1502 has sufficient bandwidth, it sets the "max-reservable-bandwidth" to a 1503 sufficiently large number. It also represents a persistent ANE 1504 defined in the "ane-props" resource, identified by "ane- 1505 props.ane:datacenter1". The aggregated "max-reservable-bandwidth" of 1506 ane:AGGR is constrained by the link capacity of L1. The "persistent- 1507 entity-id" property is omitted as both L1 and NET3 do not represent 1508 any persistent entity. 1510 POST /endpointcost/pv HTTP/1.1 1511 Host: alto.example.com 1512 Accept: multipart/related; 1513 type=application/alto-endpointcost+json, 1514 application/alto-error+json 1515 Content-Length: [TBD] 1516 Content-Type: application/alto-endpointcostparams+json 1518 { 1519 "cost-type": { 1520 "cost-mode": "array", 1521 "cost-metric": "ane-path" 1522 }, 1523 "endpoints": { 1524 "srcs": [ "ipv4:1.2.3.4", "ipv4:2.3.4.5" ], 1525 "dsts": [ "ipv4:3.4.5.6" ] 1526 }, 1527 "ane-property-names": [ 1528 "max-reservable-bandwidth", 1529 "persistent-entity-id" 1530 ] 1531 } 1533 HTTP/1.1 200 OK 1534 Content-Length: [TBD] 1535 Content-Type: multipart/related; boundary=example-2; 1536 type=application/alto-endpointcost+json 1538 --example-2 1539 Resource-Id: ecs 1540 Content-Type: application/alto-endpointcost+json 1542 { 1543 "meta": { 1544 "vtags": { 1545 "resource-id": "endpoint-cost-pv.ecs", 1546 "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef" 1547 }, 1548 "cost-type": { 1549 "cost-mode": "array", 1550 "cost-metric": "ane-path" 1551 } 1552 }, 1553 "endpoint-cost-map": { 1554 "ipv4:1.2.3.4": { 1555 "ipv4:3.4.5.6": [ "NET1", "AGGR" ] 1556 }, 1557 "ipv4:2.3.4.5": { 1558 "ipv4:3.4.5.6": [ "NET1", "AGGR" ] 1559 } 1560 } 1561 } 1562 --example-2 1563 Resource-Id: propmap 1564 Content-Type: application/alto-propmap+json 1566 { 1567 "meta": { 1568 "dependent-vtags": [ 1569 { 1570 "resource-id": "endpoint-cost-pv.ecs", 1571 "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef" 1572 }, 1573 { 1574 "resource-id": "ane-props", 1575 "tag": "bf3c8c1819d2421c9a95a9d02af557a3" 1576 } 1577 ] 1578 }, 1579 "property-map": { 1580 ".ane:NET1": { 1581 "max-reservable-bandwidth": 50000000000, 1582 "persistent-entity-id": "ane-props.ane:datacenter1", 1583 }, 1584 ".ane:AGGR": { 1585 "max-reservable-bandwidth": 10000000000 1586 } 1587 } 1588 } 1590 After the client obtains "ane-props.ane:datacenter1", it can query 1591 the "ane-props" resource to get the properties of the persistent ANE. 1593 8.4. Example: Incremental Updates 1595 In this example, an ALTO client subscribes to the incremental update 1596 for the multipart endpoint cost resource "endpoint-cost-pv". 1598 POST /updates/pv HTTP/1.1 1599 Host: alto.example.com 1600 Accept: text/event-stream 1601 Content-Type: application/alto-updatestreamparams+json 1602 Content-Length: [TBD] 1604 { 1605 "add": { 1606 "ecspvsub1": { 1607 "resource-id": "endpoint-cost-pv", 1608 "input": 1609 } 1610 } 1611 } 1613 Based on the server-side process defined in 1614 [I-D.ietf-alto-incr-update-sse], the ALTO server will send the 1615 "control-uri" first using Server-Sent Event (SSE), followed by the 1616 full response of the multipart message. 1618 HTTP/1.1 200 OK 1619 Connection: keep-alive 1620 Content-Type: text/event-stream 1622 event: application/alto-updatestreamcontrol+json 1623 data: {"control-uri": "https://alto.example.com/updates/streams/123"} 1625 event: multipart/related;boundary=example-3; 1626 type=application/alto-endpointcost+json,ecspvsub1 1627 data: --example-3 1628 data: Resource-ID: ecsmap 1629 data: Content-Type: application/alto-endpointcost+json 1630 data: 1631 data: 1632 data: --example-3 1633 data: Resource-ID: propmap 1634 data: Content-Type: application/alto-propmap+json 1635 data: 1636 data: 1637 data: --example-3-- 1639 When the contents change, the ALTO server will publish the updates 1640 for each node in this tree separately. 1642 event: application/merge-patch+json, ecspvsub1.ecsmap 1643 data: 1645 event: application/merge-patch+json, ecspvsub1.propmap 1646 data: 1648 9. Compatibility 1650 9.1. Compatibility with Legacy ALTO Clients/Servers 1652 The multipart filtered cost map resource and the multipart endpoint 1653 cost resource has no backward compatibility issue with legacy ALTO 1654 clients and servers. Although these two types of resources reuse the 1655 media types defined in the base ALTO protocol for the accept input 1656 parameters, they have different media types for responses. If the 1657 ALTO server provides these two types of resources, but the ALTO 1658 client does not support them, the ALTO client will ignore the 1659 resources without conducting any incompatibility. 1661 9.2. Compatibility with Multi-Cost Extension 1663 This document does not specify how to integrate the Path Vector cost 1664 type with the multi-cost extension [RFC8189]. While it is not 1665 RECOMMENDED to put the Path Vector cost type with other cost types in 1666 a single query, there is no compatibility issue. 1668 9.3. Compatibility with Incremental Update 1670 The extension specified in this document is NOT compatible with the 1671 original incremental update extension 1672 [I-D.ietf-alto-incr-update-sse]. A legacy ALTO client CANNOT 1673 recognize the compound client-id, and a legacy ALTO server MAY use 1674 the same client-id for updates of both parts. 1676 ALTO clients and servers MUST follow the specifications given in this 1677 document to support incremental updates for a Path Vector resource. 1679 9.4. Compatibility with Cost Calendar 1681 The extension specified in this document is compatible with the Cost 1682 Calendar extension [I-D.ietf-alto-cost-calendar]. When used together 1683 with the Cost Calendar extension, the cost value between a source and 1684 a destination is an array of path vectors, where the k-th path vector 1685 refers to the abstract network paths traversed in the k-th time 1686 interval by traffic from the source to the destination. 1688 When used with time-varying properties, e.g., maximum reservable 1689 bandwidth (maxresbw), a property of a single ANE may also have 1690 different values in different time intervals. In this case, if such 1691 an ANE has different property values in two time intervals, it MUST 1692 be treated as two different ANEs, i.e., with different entity 1693 identifiers. However, if it has the same property values in two time 1694 intervals, it MAY use the same identifier. 1696 This rule allows the Path Vector extension to represent both changes 1697 of ANEs and changes of the ANEs' properties in a uniform way. The 1698 Path Vector part is calendared in a compatible way, and the Property 1699 Map part is not affected by the calendar extension. 1701 The two extensions combined together can provide the historical 1702 network correlation information for a set of source and destination 1703 pairs. A network broker or client may use this information to derive 1704 other resource requirements such as Time-Block-Maximum Bandwidth, 1705 Bandwidth-Sliding-Window, and Time-Bandwidth-Product (TBP) (See 1706 [SENSE] for details). 1708 10. General Discussions 1710 10.1. Constraint Tests for General Cost Types 1712 The constraint test is a simple approach to query the data. It 1713 allows users to filter the query result by specifying some boolean 1714 tests. This approach is already used in the ALTO protocol. 1715 [RFC7285] and [RFC8189] allow ALTO clients to specify the 1716 "constraints" and "or-constraints" tests to better filter the result. 1718 However, the current syntax can only be used to test scalar cost 1719 types, and cannot easily express constraints on complex cost types, 1720 e.g., the Path Vector cost type defined in this document. 1722 In practice, developing a language for general-purpose boolean tests 1723 can be complex and is likely to be a duplicated work. Thus, it is 1724 worth looking into the direction of integrating existing well- 1725 developed query languages, e.g., XQuery and JSONiq, or their subset 1726 with ALTO. 1728 Filtering the Path Vector results or developing a more sophisticated 1729 filtering mechanism is beyond the scope of this document. 1731 10.2. General Multipart Resources Query 1733 Querying multiple ALTO information resources continuously MAY be a 1734 general requirement. And the coming issues like inefficiency and 1735 inconsistency are also general. There is no standard solving these 1736 issues yet. So we need some approach to make the ALTO client request 1737 the compound ALTO information resources in a single query. 1739 11. Security Considerations 1741 This document is an extension of the base ALTO protocol, so the 1742 Security Considerations [RFC7285] of the base ALTO protocol fully 1743 apply when this extension is provided by an ALTO server. 1745 The Path Vector extension requires additional considerations on two 1746 security considerations discussed in the base protocol: 1747 confidentiality of ALTO information (Section 15.3 of [RFC7285]) and 1748 availability of ALTO service (Section 15.5 of [RFC7285]). 1750 For confidentiality of ALTO information, a network operator should be 1751 aware of that this extension may introduce a new risk: the Path 1752 Vector information may make network attacks easier. For example, as 1753 the Path Vector information may reveal more fine-grained internal 1754 network structures than the base protocol, an ALTO client may detect 1755 the bottleneck link and start a distributed denial-of-service (DDoS) 1756 attack involving minimal flows to conduct the in-network congestion. 1758 To mitigate this risk, the ALTO server should consider protection 1759 mechanisms to reduce information exposure or obfuscate the real 1760 information, in particular, in settings where the network and the 1761 application do not belong to the same trust domain. But the 1762 implementation of Path Vector extension involving reduction or 1763 obfuscation should guarantee the requested properties are still 1764 accurate, for example, by using minimal feasible region compression 1765 algorithms [TON2019] or obfuscation protocols [SC2018][JSAC2019]. 1767 For availability of ALTO service, an ALTO server should be cognizant 1768 that using Path Vector extension might have a new risk: frequent 1769 requesting for Path Vectors might conduct intolerable increment of 1770 the server-side storage and break the ALTO server, for example, if an 1771 ALTO server implementation dynamically computes the Path Vectors for 1772 each requests. Hence, the service providing Path Vectors may become 1773 an entry point for denial-of-service attacks on the availability of 1774 an ALTO server. To avoid this risk, authenticity and authorization 1775 of this ALTO service may need to be better protected. Also, an ALTO 1776 server may consider using optimizations such as precomputation-and- 1777 projection mechanisms [JSAC2019]. 1779 12. IANA Considerations 1781 12.1. ALTO Entity Domain Type Registry 1783 This document registers a new entry to the ALTO Domain Entity Type 1784 Registry, as instructed by Section 12.2 of 1785 [I-D.ietf-alto-unified-props-new]. The new entry is as shown below 1786 in Table 1. 1788 +============+=========================+=========================+ 1789 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1790 +============+=========================+=========================+ 1791 | ane | See Section 6.2.2 | None | 1792 +------------+-------------------------+-------------------------+ 1794 Table 1: ALTO Entity Domain Type Registry 1796 Identifier: See Section 6.2.1. 1798 Entity Identifier Encoding: See Section 6.2.2. 1800 Hierarchy: None 1802 Inheritance: None 1804 Media Type of Defining Resource: See Section 6.2.4. 1806 Security Considerations: In some usage scenarios, ANE addresses 1807 carried in ALTO Protocol messages may reveal information about an 1808 ALTO client or an ALTO service provider. Applications and ALTO 1809 service providers using addresses of ANEs will be made aware of 1810 how (or if) the addressing scheme relates to private information 1811 and network proximity, in further iterations of this document. 1813 12.2. ALTO Entity Property Type Registry 1815 Two initial entries are registered to the ALTO Domain "ane" in the 1816 "ALTO Entity Property Type Registry", as instructed by Section 12.3 1817 of [I-D.ietf-alto-unified-props-new]. The two new entries are shown 1818 below in Table 2. 1820 +==========================+====================+ 1821 | Identifier | Intended Semantics | 1822 +==========================+====================+ 1823 | max-reservable-bandwidth | See Section 6.4.1 | 1824 +--------------------------+--------------------+ 1825 | persistent-entity-id | See Section 6.4.2 | 1826 +--------------------------+--------------------+ 1828 Table 2: Initial Entries for ane Domain in 1829 the ALTO Entity Property Types Registry 1831 13. Acknowledgments 1833 The authors would like to thank discussions with Andreas Voellmy, 1834 Erran Li, Haibin Song, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan 1835 Liu, Xiao Shi, Xin Wang, and Yan Luo. The authors thank Greg 1836 Bernstein (Grotto Networks), Dawn Chen (Tongji University), Wendy 1837 Roome, and Michael Scharf for their contributions to earlier drafts. 1839 14. References 1841 14.1. Normative References 1843 [I-D.ietf-alto-cost-calendar] 1844 Randriamasy, S., Yang, Y., WU, Q., Lingli, D., and N. 1845 Schwan, "Application-Layer Traffic Optimization (ALTO) 1846 Cost Calendar", Work in Progress, Internet-Draft, draft- 1847 ietf-alto-cost-calendar-21, 17 March 2020, 1848 . 1851 [I-D.ietf-alto-incr-update-sse] 1852 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1853 Server-Sent Events (SSE)", Work in Progress, Internet- 1854 Draft, draft-ietf-alto-incr-update-sse-22, 20 March 2020, 1855 . 1858 [I-D.ietf-alto-unified-props-new] 1859 Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. 1860 Gao, "Unified properties for the ALTO protocol", Work in 1861 Progress, Internet-Draft, draft-ietf-alto-unified-props- 1862 new-12, 13 July 2020, . 1865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1866 Requirement Levels", BCP 14, RFC 2119, 1867 DOI 10.17487/RFC2119, March 1997, 1868 . 1870 [RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service 1871 Specification Template", RFC 2216, DOI 10.17487/RFC2216, 1872 September 1997, . 1874 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 1875 RFC 2387, DOI 10.17487/RFC2387, August 1998, 1876 . 1878 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1879 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1880 "Application-Layer Traffic Optimization (ALTO) Protocol", 1881 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1882 . 1884 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1885 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1886 May 2017, . 1888 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1889 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1890 DOI 10.17487/RFC8189, October 2017, 1891 . 1893 14.2. Informative References 1895 [AAAI2019] Xiang, Q., Yu, H., Aspnes, J., Le, F., Kong, L., and Y.R. 1896 Yang, "Optimizing in the dark: Learning an optimal 1897 solution through a simple request interface", Proceedings 1898 of the AAAI Conference on Artificial Intelligence 33, 1899 1674-1681 , 2019. 1901 [I-D.contreras-alto-service-edge] 1902 Contreras, L., Perez, D., and C. Rothenberg, "Use of ALTO 1903 for Determining Service Edge", Work in Progress, Internet- 1904 Draft, draft-contreras-alto-service-edge-01, 13 July 2020, 1905 . 1908 [I-D.huang-alto-mowie-for-network-aware-app] 1909 Huang, W., Zhang, Y., Yang, R., Xiong, C., Lei, Y., Han, 1910 Y., and G. Li, "MoWIE for Network Aware Application", Work 1911 in Progress, Internet-Draft, draft-huang-alto-mowie-for- 1912 network-aware-app-01, 13 July 2020, . 1916 [I-D.ietf-alto-performance-metrics] 1917 WU, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and 1918 L. Contreras, "ALTO Performance Cost Metrics", Work in 1919 Progress, Internet-Draft, draft-ietf-alto-performance- 1920 metrics-12, 13 July 2020, . 1923 [I-D.ietf-dmm-5g-uplane-analysis] 1924 Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, 1925 "User Plane Protocol and Architectural Analysis on 3GPP 5G 1926 System", Work in Progress, Internet-Draft, draft-ietf-dmm- 1927 5g-uplane-analysis-03, 3 November 2019, 1928 . 1931 [I-D.yang-alto-deliver-functions-over-networks] 1932 Yang, S., Cui, L., Xu, M., Yang, Y., and R. Huang, 1933 "Delivering Functions over Networks: Traffic and 1934 Performance Optimization for Edge Computing using ALTO", 1935 Work in Progress, Internet-Draft, draft-yang-alto-deliver- 1936 functions-over-networks-01, 13 July 2020, 1937 . 1940 [JSAC2019] Xiang, Q., Zhang, J., Wang, X., Liu, Y., Guok, C., Le, F., 1941 MacAuley, J., Newman, H., and Y.R. Yang, "Toward Fine- 1942 Grained, Privacy-Preserving, Efficient Multi-Domain 1943 Network Resource Discovery", IEEE/ACM IEEE Journal on 1944 Selected Areas of Communication 37(8): 1924-1940, 2019. 1946 [LHC] "CERN - LHC", 2019, . 1948 [SC2018] Xiang, Q., Zhang, J., Wang, X., Liu, Y., Guok, C., Le, F., 1949 MacAuley, J., Newman, H., and Y.R. Yang, "Fine-grained, 1950 multi-domain network resource abstraction as a fundamental 1951 primitive to enable high-performance, collaborative data 1952 sciences", Proceedings of the Super Computing 2018, 1953 5:1-5:13 , 2019. 1955 [SENSE] "Services - SENSE", 2019, . 1957 [TON2019] Gao, K., Xiang, Q., Wang, X., Yang, Y.R., and J. Bi, "An 1958 objective-driven on-demand network abstraction for 1959 adaptive applications", IEEE/ACM Transactions on 1960 Networking (TON) Vol 27, no. 2 (2019): 805-818., 2019. 1962 Appendix A. Changes since -11 1964 Revision -12 1966 * clarifies the definition of ANEs in a similar way as how Network 1967 Elements is defined in [RFC2216] 1969 * restructures several paragraphs that are not clear (Sec 3, Path 1970 Vector bullet, Sec 4.2, Sec 5.1.3, Sec 6.2.4, Sec 6.4.2, Sec 9.3) 1972 * uses "ALTO Entity Domain Type Registry" 1974 Appendix B. Changes since -10 1976 Revision -11 1978 * replaces "part" with "components" in the abstract; 1980 * identifies additional requirements (AR) derived from the flow 1981 scheduling example, and introduces how the extension addresses the 1982 additional requirements 1984 * fixes the inconsistent use of "start" parameter in multipart 1985 responses; 1987 * specifies explicitly how to handle "cost-constraints"; 1989 * uses the latest IANA registration mechanism defined in 1990 [I-D.ietf-alto-unified-props-new]; 1992 * renames "persistent-entities" to "persistent-entity-id"; 1994 * makes "application/alto-propmap+json" as the media type of 1995 defining resources for the "ane" domain; 1997 * updates the examples; 1999 * adds the discussion on ephemeral and persistent ANEs. 2001 Appendix C. Changes since -09 2003 Revision -10 2004 * revises the introduction which 2006 - extends the scope where the PV extension can be applied beyond 2007 the "path correlation" information 2009 * brings back the capacity region use case to better illustrate the 2010 problem 2012 * revises the overview to explain and defend the concepts and 2013 decision choices 2015 * fixes inconsistent terms, typos 2017 Appendix D. Changes since -08 2019 This revision 2021 * fixes a few spelling errors 2023 * emphasizes that abstract network elements can be generated on 2024 demand in both introduction and motivating use cases 2026 Appendix E. Changes Since Version -06 2028 * We emphasize the importance of the path vector extension in two 2029 aspects: 2031 1. It expands the problem space that can be solved by ALTO, from 2032 preferences of network paths to correlations of network paths. 2034 2. It is motivated by new usage scenarios from both application's 2035 and network's perspectives. 2037 * More use cases are included, in addition to the original capacity 2038 region use case. 2040 * We add more discussions to fully explore the design space of the 2041 path vector extension and justify our design decisions, including 2042 the concept of abstract network element, cost type (reverted to 2043 -05), newer capabilities and the multipart message. 2045 * Fix the incremental update process to be compatible with SSE -16 2046 draft, which uses client-id instead of resource-id to demultiplex 2047 updates. 2049 * Register an additional ANE property (i.e., persistent-entities) to 2050 cover all use cases mentioned in the draft. 2052 Authors' Addresses 2054 Kai Gao 2055 Sichuan University 2056 No.24 South Section 1, Yihuan Road 2057 Chengdu 2058 610000 2059 China 2061 Email: kaigao@scu.edu.cn 2063 Young Lee 2064 Samsung 2065 South Korea 2067 Email: younglee.tx@gmail.com 2069 Sabine Randriamasy 2070 Nokia Bell Labs 2071 Route de Villejust 2072 91460 Nozay 2073 France 2075 Email: sabine.randriamasy@nokia-bell-labs.com 2077 Yang Richard Yang 2078 Yale University 2079 51 Prospect Street 2080 New Haven, CT 2081 United States of America 2083 Email: yry@cs.yale.edu 2085 Jingxuan Jensen Zhang 2086 Tongji University 2087 4800 Caoan Road 2088 Shanghai 2089 201804 2090 China 2092 Email: jingxuan.n.zhang@gmail.com