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