idnits 2.17.1 draft-ietf-alto-path-vector-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7285]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 18, 2017) is 2320 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 866, but not defined == Unused Reference: 'I-D.amante-i2rs-topology-use-cases' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'I-D.clemm-i2rs-yang-network-topo' is defined on line 1066, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-cost-calendar' is defined on line 1072, but no explicit reference was found in the text == Unused Reference: 'I-D.lee-alto-app-net-info-exchange' is defined on line 1082, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-clemm-i2rs-yang-network-topo-01 == Outdated reference: A later version (-21) exists of draft-ietf-alto-cost-calendar-01 == Outdated reference: A later version (-24) exists of draft-ietf-alto-unified-props-new-00 == Outdated reference: A later version (-04) exists of draft-lee-alto-app-net-info-exchange-02 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 WG G. Bernstein 3 Internet-Draft Grotto Networking 4 Intended status: Standards Track S. Chen 5 Expires: June 21, 2018 Tongji University 6 K. Gao 7 Tsinghua University 8 Y. Lee 9 Huawei 10 W. Roome 11 M. Scharf 12 Nokia 13 Y. Yang 14 Yale University 15 J. Zhang 16 Tongji University 17 December 18, 2017 19 ALTO Extension: Path Vector Cost Type 20 draft-ietf-alto-path-vector-02.txt 22 Abstract 24 The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] 25 has defined several resources and services to provide clients with 26 basic network information. However, the base ALTO protocol and 27 latest extensions only provide end-to-end metrics, which are 28 insufficient to satisfy the demands of solving more complex network 29 optimization problems. This document introduces an extension to the 30 base ALTO protocol, namely the path-vector extension, which allows 31 ALTO clients to query information such as capacity regions for a 32 given set of flows. A non-normative example called multi-flow 33 scheduling is presented to illustrate the limitations of existing 34 ALTO (endpoint) cost maps. After that, details of the extension are 35 defined. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on June 21, 2018. 60 Copyright Notice 62 Copyright (c) 2017 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. Use Case: Capacity Region for Multi-Flow Scheduling . . . . . 5 80 4. Overview of Path Vector Extensions . . . . . . . . . . . . . 7 81 4.1. Path Vector Cost Type Extensions . . . . . . . . . . . . 7 82 4.1.1. New Cost Metric for Path Vector . . . . . . . . . . . 7 83 4.1.2. New Cost Mode for Path Vector . . . . . . . . . . . . 8 84 4.1.3. Path Vector Cost Type Semantics . . . . . . . . . . . 8 85 4.2. ANE Property Map . . . . . . . . . . . . . . . . . . . . 8 86 4.3. media type for path vector: multipart/related . . . . . . 9 87 4.4. Applicable ALTO services for Path Vector costs . . . . . 9 88 4.5. Impact of backwards compatibility on the PV design . . . 10 89 4.6. Requirements for PV on Clients and Servers . . . . . . . 10 90 5. Path-Vector Extension: Basic Data Types . . . . . . . . . . . 10 91 5.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 10 92 5.1.1. Cost Mode: array . . . . . . . . . . . . . . . . . . 11 93 5.1.2. Cost Metric: ane-path . . . . . . . . . . . . . . . . 11 94 5.2. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 11 95 5.3. Abstract Network Element Name . . . . . . . . . . . . . . 11 97 6. Path-Vector Extension: Services . . . . . . . . . . . . . . . 11 98 6.1. Filtered Cost Map Extensions . . . . . . . . . . . . . . 11 99 6.1.1. Capabilities . . . . . . . . . . . . . . . . . . . . 12 100 6.1.2. Accept Input Parameters . . . . . . . . . . . . . . . 12 101 6.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 12 102 6.2. Endpoint Cost Service Extensions . . . . . . . . . . . . 13 103 6.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . 13 104 6.2.2. Accept Input Parameters . . . . . . . . . . . . . . . 13 105 6.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 13 106 6.3. Multipart Cost Property Service . . . . . . . . . . . . . 13 107 6.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 14 108 6.3.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 14 109 6.3.3. Accept Input Parameters . . . . . . . . . . . . . . . 14 110 6.3.4. Capabilities . . . . . . . . . . . . . . . . . . . . 14 111 6.3.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 14 112 6.3.6. Response . . . . . . . . . . . . . . . . . . . . . . 15 113 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 114 7.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 15 115 7.2. Information Resource Directory Example . . . . . . . . . 16 116 7.3. Example # 1 . . . . . . . . . . . . . . . . . . . . . . . 17 117 7.4. Example # 2 . . . . . . . . . . . . . . . . . . . . . . . 18 118 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 20 119 8.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 20 120 8.2. Compatibility with Multi-Cost Extensions . . . . . . . . 20 121 8.3. Compatibility with Incremental Update . . . . . . . . . . 20 122 9. Design Decisions and Discussions . . . . . . . . . . . . . . 21 123 9.1. Provide More General Calendar Extension . . . . . . . . . 21 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 125 10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 21 126 10.2. Resource Consumption on ALTO Servers . . . . . . . . . . 22 127 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 128 11.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 22 129 11.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . 22 130 11.3. ALTO Network Element Property Type Registry . . . . . . 22 131 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 132 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 133 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 134 13.2. Informative References . . . . . . . . . . . . . . . . . 23 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 137 1. Introduction 139 The base ALTO protocol [RFC7285] is designed for exposing network 140 information through services such as the Network Map service and the 141 Cost Map service. These services use an extreme "single-node" 142 network view abstraction, which represents the whole network with a 143 single node and hosts with "endpoint groups" directly connected to 144 the node. 146 Although the "single-node" network view abstraction works well in 147 many settings, it lacks the ability to support new emerging use 148 cases, such as inter-datacenter flow scheduling, scientific high- 149 performance computing data transfers and end-to-end paths crossing 150 heterogeneous technologies. For these use cases, more powerful 151 network view abstraction is required. To provide a better network 152 view abstraction, ALTO services need to support the following 153 additional functionalities: 155 o Providing path vector rather than a simple path cost of endpoint 156 to endpoint. The path vector exposes the network elements (e.g., 157 links, switches, middle boxes and their aggregations) that 158 endpoint to endpoint traffic goes through. 160 o Providing information of the network elements in the path vector. 161 The information can be "bandwidth" for links, "delay" between 162 neighboring switches and other properties of network elements. 163 These information may help the application avoid network 164 congestion, achieving better application performance. 166 To support these new functionalities, this document proposes the 167 path-vector extension, which introduces a qualitative cost type 168 listing selected groups of one or more abstracted network elements in 169 an e2e path and optionally conveys some of their properties. 171 The rest of this document is organized as follows. Section 3 gives 172 an example of flow scheduling and illustrates the limitations of the 173 base ALTO protocol in such a use case. Section 4 gives an overview 174 of the path-vector extension, before specifying the details of the 175 extension in Section 5 and Section 6. Section 7 presents several 176 examples, and Section 9 explains some design decisions. Section 8 177 discusses compatibility issues with some other ALTO extensions. 178 Section 10 and Section 11 discusses about security and IANA 179 considerations. 181 2. Terminology 183 This document uses the same terms as defined in [RFC7285], [RFC8189] 184 and [I-D.ietf-alto-unified-props-new] with the following additional 185 terms: Abstract Network Element, Abstract Network Element Name, 186 Abstract Network Element Property, Abstract Network Element Property 187 Map and Path Vector. 189 o Abstract Network Element (ANE): An abstract network element is an 190 abstraction of network components, it can be an aggregation of 191 links, middle boxes, Virtualized Network Function (VNF), or even a 192 sub-network. An abstract network element has two attributes: 194 abstract network element name and abstract network element 195 property, which are defined below. 197 o Abstract Network Element Name (ANEN): An abstract network element 198 name is an identifier which uniquely identifies an abstract 199 network element, as defined in Section 5.3. 201 o Abstract Network Element Property (ANEP): An abstract network 202 element property is a specific metric associated with a given 203 abstract network element, as introduced in Section 4.2. An 204 abstract network element can have several network element 205 properties. 207 o Abstract Network Element Property Map (ANE Property Map): An 208 abstract network element property map is a Filtered Property Map 209 defined in [I-D.ietf-alto-unified-props-new] which supports the 210 "ane" domain in its "domain-types" capability. 212 o Path Vector (PV): A path vector is an array of ALTO Abstract 213 Network Elements (ANEs), which presents an abstract network path 214 between entities such as PIDs or endpoints. An ANE represents a 215 selected part of an end-to-end path that the ALTO Server considers 216 worth exposing. An ANE is a set of one or more network elements 217 such as links, switches, middle boxes and their aggregations, it 218 is expected to have properties that may influence the applications 219 e.g. when they select an endpoint or want to estimate their 220 performance. 222 3. Use Case: Capacity Region for Multi-Flow Scheduling 224 Once routing has been configured in the network, application-layer 225 traffic optimization may want to schedule traffic among application- 226 layer paths. Specifically, assume that an application has control 227 over a set of flows F = {f_1, f_2, ..., f_|F|}. If routing is given, 228 what the application can control is x_1, x_2, ..., x_|F|, where x_i 229 is the amount of traffic for flow i. Let x = [x_1, ..., x_|F|] be 230 the vector of the flow traffic amounts. Due to shared links, 231 feasible values of x where link capacities are not exceeded can be a 232 complex polytype. 234 Specifically, consider a network as shown in Figure 1. The network 235 has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches 236 sw1/sw3 provide access on one side, sw2/sw4 provide access on the 237 other side, and sw5-sw7 form the backbone. End hosts eh1 to eh4 are 238 connected to access switches sw1 to sw4 respectively. Assume that 239 the bandwidth of link eh1 -> sw1 and link sw1 -> sw5 are 150 Mbps, 240 and the bandwidth of the rest links are 100 Mbps. 242 +------+ 243 | | 244 --+ sw6 +-- 245 / | | \ 246 PID1 +-----+ / +------+ \ +-----+ PID2 247 eh1__| |_ / \ ____| |__eh2 248 | sw1 | \ +--|---+ +---|--+ / | sw2 | 249 +-----+ \ | | | |/ +-----+ 250 \_| sw5 +---------+ sw7 | 251 PID3 +-----+ / | | | |\ +-----+ PID4 252 eh3__| |__/ +------+ +------+ \____| |__eh4 253 | sw3 | | sw4 | 254 +-----+ +-----+ 256 Figure 1: Raw Network Topology. 258 The single-node ALTO topology abstraction of the network is shown in 259 Figure 2. 261 +----------------------+ 262 {eh1} | | {eh2} 263 PID1 | | PID2 264 +------+ +------+ 265 | | 266 | | 267 {eh3} | | {eh4} 268 PID3 | | PID4 269 +------+ +------+ 270 | | 271 +----------------------+ 273 Figure 2: Base Single-Node Topology Abstraction. 275 Consider an application overlay (e.g., a large data analysis system) 276 which wants to schedule the traffic among a set of end host source- 277 destination pairs, say eh1 -> eh2 and eh1 -> eh4. The application 278 can request a cost map providing end-to-end available bandwidth, 279 using 'availbw' as cost-metric and 'numerical' as cost-mode. 281 The application will receive from ALTO server that the bandwidth of 282 eh1 -> eh2 and eh1 -> eh4 are both 100 Mbps. But this information is 283 not enough. Consider the following two cases: 285 o Case 1: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw6 -> 286 sw7 -> sw2 -> eh2 and eh1 -> eh4 uses path eh1 -> sw1 -> sw5 -> 287 sw7 -> sw4 -> eh4, then the application will obtain 150 Mbps. 289 o Case 2: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw7 -> 290 sw2 -> eh2 and eh1 -> eh4 uses the path eh1 -> sw1 -> sw5 -> sw7 291 -> sw4 -> eh4, then the application will obtain only 100 Mbps. 293 To allow applications to distinguish the two aforementioned cases, 294 the network needs to provide more details. In particular: 296 o The network needs to expose more detailed routing information to 297 show the shared bottlenecks. 299 o The network needs to provide the necessary abstraction to hide the 300 real topology information while providing enough information to 301 applications. 303 The path-vector extension defined in this document meets all the 304 requirements. 306 See [I-D.bernstein-alto-topo] for a survey of use-cases where 307 extended network topology information is needed. 309 4. Overview of Path Vector Extensions 311 This section presents the approaches taken to support the path-vector 312 extension. It assumes the readers are familiar with (Filtered) Cost 313 Map and Endpoint Cost Service defined in [RFC7285] and their 314 extensions defined in [RFC8189]. It also uses features such as 315 Filtered Property Map defined in [I-D.ietf-alto-unified-props-new]. 317 4.1. Path Vector Cost Type Extensions 319 None of current cost types defined in [RFC7285] can be used to convey 320 path vector information. So, a new cost type with a new cost metric 321 "ane-path" and a new cost mode "array" is defined in this document. 322 Below are brief descriptions. Detailed information and 323 specifications are given in Section 5.1.1 and Section 5.1.2. 325 4.1.1. New Cost Metric for Path Vector 327 To represent an abstract network path, this document introduces a new 328 cost metric named "ane-path". A cost value in this metric is a list 329 containing the names of the ALTO ANEs that the ALTO Server has 330 specified as describing the network path elements. The ANE names 331 array is organized as a sequence beginning at the source of the path 332 and ending at its destination. 334 4.1.2. New Cost Mode for Path Vector 336 A cost mode as defined in Section 6.1.2 of [RFC7285], a cost mode is 337 either "numerical" or "ordinal" and none of these can be used to 338 present a list of ANE names. Therefore, this document specifies a 339 new cost mode named "array" for the cost metric "ane-path". The new 340 cost mode "array" means each cost value in the cost maps is a list. 342 4.1.3. Path Vector Cost Type Semantics 344 The new cost type follows the convention of the cost types in the 345 legacy ALTO protocol. Table 1 lists some of the current defined cost 346 types and their semantics. 348 +------------+--------------+---------------------------------------+ 349 | Cost Mode | Cost Metric | Semantics | 350 +------------+--------------+---------------------------------------+ 351 | numerical | routingcost | a number representing the routing | 352 | | | cost | 353 | numerical | hopcount | a number representing the hop count | 354 | ordinal | routingcost | a ranking representing the routing | 355 | | | cost | 356 | ordinal | hopcount | a ranking representing the hop count | 357 | array | ane-path | a list representing the ane path | 358 +------------+--------------+---------------------------------------+ 360 Table 1: Cost Types and Their Semantics 362 The "routingcost" and "hopcount" can encoded in "numerical" or 363 "ordinal", however, the cost metric "ane-path" can only be applied to 364 the cost mode "array" defined in this document to convey path vector 365 information. The cost metric "ane-path" can not be used in 366 "numerical" or "ordinal" unless it is defined in future extensions. 367 If the ALTO server declares that it support cost type with cost 368 metric being "ane-path" and cost mode not being "array", the ALTO 369 client SHOULD ignore them. 371 4.2. ANE Property Map 373 Given that Cost Map and Endpoint Cost service now provide the 374 abstract network element names along a flow path, ALTO clients can 375 learn that there exist bottlenecks shared by different flows. 376 However, only providing the abstract network element names without 377 abstract network element properties is not enough, some ALTO clients 378 may want to have information on specific ANE properties such as link 379 capacity or delay. This document adopts the property map resources 380 defined in [I-D.ietf-alto-unified-props-new] to encode the properties 381 of ANEs. Draft [I-D.ietf-alto-unified-props-new] defines a new 382 entity domain called "ane" and each entity in the "ane" domain has an 383 identifier of an ANE. An ANE identifier is the ANE name used in the 384 values of the "ane-path" metric defined in the present draft. ANE 385 properties are provided in information resources called "Property Map 386 Resource" and "Filtered Property Map Resource". The "Filtered 387 Property Map" resource which support the "ane" domain is used to 388 encode the properties of ane entities, and it is called an ANE 389 Property Map in this document. 391 4.3. media type for path vector: multipart/related 393 In the legacy ALTO protocol, ALTO servers use media types in the HTTP 394 header to indicate the type of the response. Typically one response 395 only contains a single media type, such as "application/alto- 396 costmap+json" or "application/alto-propmap+json". This has limited 397 the capability of ALTO servers to return multiple services in a 398 single response. 400 Thus, an ALTO client needs to make separate queries to get the 401 information of related services. This may cause a data 402 synchronization problem between dependent ALTO services because when 403 making the second query, the result for the first query may have 404 already changed. The very same problem can happen to Network Map and 405 Cost Map resources. However, unlike Network Map and Cost Map which 406 are considered more stable, Path Vectors and the dependent ANE 407 Property Maps might change more frequently. 409 Instead of introducing a new media type to encapsulate multiple types 410 in a single response, this document adopts the "multipart/related" 411 media type defined in [RFC2387]. In this way, a response can contain 412 both the Path Vectors in a Filtered Cost Map (or Endpoint Cost Map) 413 and the associated ANE Property Map. The media types of the cost map 414 and the property map can still be retrieved from the response. The 415 interpretation of each media type in the "multipart/related" response 416 is consistent with the base ALTO protocol. 418 4.4. Applicable ALTO services for Path Vector costs 420 This document defines Filtered Cost Map and Endpoint Cost Map are 421 applicable for path vector costs. Although the new cost type for 422 path vector can also be used in the GET-mode Cost Map service from 423 [RFC7285], the behaviours of the ALTO server and client for such a 424 GET-mode service is not defined. So it is not recommended to apply 425 path vector costs to the GET-mode Cost Map service. 427 4.5. Impact of backwards compatibility on the PV design 429 The path vector extension on Filtered Cost Map and Endpoint Cost 430 Service is backward compatible with the base ALTO protocol. If the 431 ALTO server provides path vector extended Filtered Cost Map or 432 Endpoint Cost Service, but the client is a base ALTO client, then the 433 client will ignore the path vector cost type without conducting any 434 incompatibility. If the client sents a request with path vector cost 435 type, but the server is a base ALTO server, the server will return an 436 "E_INVALID_FIELD_VALUE" error. 438 4.6. Requirements for PV on Clients and Servers 440 A path vector extended ALTO server MUST implement the legacy ALTO 441 protocol specified in [RFC7285] with the following additional 442 requirements: 444 o If an ALTO server supports path vector extension, it MUST support 445 the Unified Property Map defined in 446 [I-D.ietf-alto-unified-props-new]. 448 o If an ALTO server supports path vector extended Filtered Cost Map 449 or Endpoint Cost Service, the server MUST provide the associated 450 Property Map simultaneously. 452 o If an ALTO server provides "multipart/related" media type for path 453 vector, the server MUST provide the associated Filtered Cost Map 454 or Endpoint Cost Service and the Property Map simultaneously. 456 An ALTO client supported path vector extension MUST be able to 457 interpret Unified Property Map correctly. If the ALTO client wants 458 to interpret "multipart/related" path vector response, the client 459 MUST implement the path vector extension on Filtered Cost Map or 460 Endpoint Cost Service at first. 462 5. Path-Vector Extension: Basic Data Types 464 This section formally specifies a new cost type. 466 5.1. Cost Type 468 This document extends the cost types defined in Section 6.1 of 469 [RFC7285] by introducing a new cost mode "array" and a new cost 470 metric "ane-path". 472 5.1.1. Cost Mode: array 474 This document extends the CostMode defined in Section 10.5 of 475 [RFC7285] with a new cost mode: "array". This cost mode indicates 476 that every cost value in a cost map represents an array rather than a 477 simple value. The values are arrays of JSONValue. The specific type 478 of each element in the array depends on the cost metric. 480 5.1.2. Cost Metric: ane-path 482 This document specifies a new cost metric: "ane-path". This cost 483 metric indicates that the cost value is a list of abstract network 484 elements which the path from a source to a destination goes across. 485 The values are arrays of ANE Names which are defined in Section 5.3. 487 The cost metric "ane-path" SHOULD NOT be used when the cost mode is 488 not "array" unless it is explicitly specified by a future extension. 489 If an ALTO client send queries with the cost metric "ane-path" and a 490 non "array" cost mode, the ALTO server SHOULD return an error with 491 the error code "E_INVALID_FIELD_VALUE"; If an ALTO server declares 492 the support of a cost type with the cost metric "ane-path" and a non 493 "array" cost mode, the ALTO client SHOULD assume such a cost type is 494 invalid and ignore it. 496 5.2. ANE Domain 498 This document uses the same definition of entity domain name 'ane' as 499 defined in Section 3.4 of [I-D.ietf-alto-unified-props-new]. 501 5.3. Abstract Network Element Name 503 An Abstract Network Element Name is encoded as an EntityAddr of the 504 "ane" domain as defined in Section 3.4.2 of 505 [I-D.ietf-alto-unified-props-new]. 507 6. Path-Vector Extension: Services 509 This section extends Filtered Cost Map Service and Endpoint Cost 510 Service. 512 6.1. Filtered Cost Map Extensions 514 This document extends the Filtered Cost Map defined in Section 4.1 of 515 [RFC8189]. 517 The specifications for the "media type", "HTTP method" and "uses" are 518 the same as defined in Section 4.1 of [RFC8189]. 520 6.1.1. Capabilities 522 The FilteredCostMapCapabilities object is extended with a new member 523 "property-map": 525 object { 526 [ResourceID property-map;] 527 } PathVectorFilteredCostMapCapabilities : FilteredCostMapCapabilities 529 property-map: A resource ID defined in the same IRD pointing to an 530 ANE Property Map as defined in Section 2. This field MUST be 531 present if the path vector cost type is present in the "cost-type- 532 names" field. 534 Other fields of the FilteredCostMapCapabilities object has the same 535 format as defined in Section 4.1.1 of [RFC8189] with the following 536 constraint: 538 testable-cost-type-names: The path vector cost type with "ane-path" 539 as the cost metric and "array" as the cost mode MUST NOT be 540 included in "testable-cost-type-names". 542 6.1.2. Accept Input Parameters 544 The ReqFilteredCostMap uses the same format as defined in 545 Section 4.1.2 of [RFC8189], with the following constraints: 547 constraints, or-constraints: If the path vector cost type is 548 included in either "cost-type" or "multi-cost-types", ALTO clients 549 MUST NOT use it in "constraints" or "or-constraints". Otherwise, 550 the ALTO server MUST return an error with error code 551 "E_INVALID_FIELD_VALUE". 553 testable-cost-types: The path vector cost type MUST NOT be included 554 in the "testable-cost-types" field. Otherwise, the ALTO server 555 MUST return an error with error code "E_INVALID_FIELD_VALUE". 557 6.1.3. Response 559 If the ALTO client includes the path vector cost type in the "cost- 560 type" or "multi-cost-types" field of the input parameter, the 561 response use the same format as defined in Section 4.1.3 of 562 [RFC8189], but the corresponding cost value MUST be encoded as a 563 JSONArray of AbstractNetworkElementName. 565 6.2. Endpoint Cost Service Extensions 567 This document extends the Endpoint Cost Service defined in 568 Section 4.2 in [RFC8189]. 570 The specifications for "HTTP method" and "uses" are the same as 571 defined in Section 4.2 in [RFC8189]. 573 6.2.1. Capabilities 575 The same as defined in Section 6.1.1. 577 6.2.2. Accept Input Parameters 579 The ReqEndpointCostMap uses the same format as defined in 580 Section 4.2.2 of [RFC8189], with the following constraints: 582 cost-type, multi-cost-types: ALTO clients MUST include the path 583 vector cost type, e.g. the one with "ane-path" as cost metric and 584 "array" as cost mode, in either "cost-type" or "multi-cost-types" 585 to activate the path vector extension. 587 constraints, or-constraints: If the path vector cost type is 588 included in either "cost-type" or "multi-cost-types", ALTO clients 589 MUST NOT use it in "constraints" or "or-constraints". Otherwise, 590 the ALTO server MUST return an error with error code 591 "E_INVALID_FIELD_VALUE". 593 testable-cost-types: The path vector cost type MUST NOT be included 594 in the "testable-cost-types" field. Otherwise, the ALTO server 595 MUST return an error with error code "E_INVALID_FIELD_VALUE". 597 6.2.3. Response 599 If the ALTO client specifies the path vector cost type in the "cost- 600 type" or "multi-cost-types" field of the input parameter, the 601 response use the same format as defined in Section 4.2.3 of 602 [RFC8189], but the corresponding cost value MUST be encoded as a 603 JSONArray of AbstractNetworkElementName. 605 6.3. Multipart Cost Property Service 607 This document introduces a new ALTO service called "Multipart Cost 608 Property Service", which provides the path vector information and the 609 associated ANE property information in the same response. 611 6.3.1. Media Type 613 The media type of the Multipart Cost Property service is "multipart/ 614 related". 616 6.3.2. HTTP Method 618 The Multipart Cost Property service is requested using the HTTP POST 619 method. 621 6.3.3. Accept Input Parameters 623 The input parameters of the Multipart Cost Property service MUST be 624 encoded as a JSON object in the body of an HTTP POST request. The 625 media type of the request SHOULD be one of "application/alto- 626 costmapfilter+json" and "application/alto-endpointcostparams+json". 627 The format of the request body depends on the media type: 629 o If the media type of the request is "application/alto- 630 costmapfilter+json", the request body MUST be the same type as 631 defined by Section 6.1.2. 633 o If the media type of the request is "application/alto- 634 endpointcostparams+json", the request body MUST be the same type 635 as defined by Section 6.2.2. 637 The path vector cost type MUST be the only cost type in the input 638 parameter. 640 6.3.4. Capabilities 642 TBD 644 6.3.5. Uses 646 The "uses" attribute MUST be an array with at least one resource id. 647 The first resource id MUST point to a Filtered Cost Map or an 648 Endpoint Cost Service resource. And the path vector cost type MUST 649 be in its "cost-type" capability. If there are more than one 650 resource id in the "uses" attribute, the ALTO client SHOULD ignore 651 any additional resource ids. 653 According to Section 6.1.1, the "property-map" field MUST be present 654 in the first resource. So the ALTO client MUST infer that the 655 Property Map pointed by the "property-map" field of the first 656 resource is also a dependent resource. 658 6.3.6. Response 660 If an ALTO client sends a request of the media type "application/ 661 alto-costmapfilter+json" and accepts "multipart/related", the HTTP 662 body of the response MUST consist of two parts with the media types 663 "application/alto-costmap+json" and "application/alto-propmap+json" 664 accordingly. The part with media type "application/alto- 665 costmap+json" MUST be the first part. The content of the 666 "application/alto-endpointcost+json" part has the same format as 667 defined in Section 6.1.3. 669 If an ALTO client sends a request of the media type "application/ 670 alto-endpointcostparams+json" and accepts "multipart/related", the 671 HTTP body of the response MUST consist of two parts with the media 672 types "application/alto-endpointcost+json" and "application/alto- 673 propmap+json" accordingly. The part with media type "application/ 674 alto-endpointcost+json" MUST be the first part. The content of the 675 "application/alto-endpointcost+json" part has the same format as 676 defined in Section 6.2.3. 678 7. Examples 680 This section lists some examples of path vector queries and the 681 corresponding responses. 683 7.1. Workflow 685 This section gives a typical workflow of an ALTO client using the 686 path-vector extension. 688 1. Send a GET request for the whole Information Resource Directory. 690 2. Look for the resource of the (Filtered) Cost Map/Endpoint Cost 691 Service which contains the path vector cost type and get the 692 resource ID of the dependent abstract network element property 693 map. 695 3. Check whether the capabilities of the property map includes the 696 desired "prop-types". 698 4. Send a path-vector request which accepts "multipart/related" 699 media type following "application/alto-costmap+json" or 700 "application/endpointcost+json". 702 7.2. Information Resource Directory Example 704 Here is an example of an Information Resource Directory. In this 705 example, filtered cost map "cost-map-pv" doesn't support the multi- 706 cost extension but support the path-vector extension, "endpoint- 707 multicost-map" supports both multi-cost extension and path-vector 708 extension. Filtered Property Map "propmap-delay-availbw" supports 709 properties "availbw" and "delay", and "propmap-location" supports 710 property "location". 712 { 713 "meta": { 714 "cost-types": { 715 "pv": { 716 "cost-mode": "array", 717 "cost-metric": "ane-path" 718 }, 719 "num-routingcost": { 720 "cost-mode": "numerical", 721 "cost-metric": "routingcost" 722 }, 723 "num-hopcount": { 724 "cost-mode": "numerical", 725 "cost-metric": "hopcount" 726 } 727 } 728 }, 729 "resources": { 730 "my-default-networkmap": { 731 "uri" : "http://alto.example.com/networkmap", 732 "media-type" : "application/alto-networkmap+json" 733 } 734 "cost-map-pv" : { 735 "uri": "http://alto.example.com/costmap/pv", 736 "media-type": "application/alto-costmap+json", 737 "accepts": "application/alto-costmapfilter+json", 738 "capabilities": { 739 "cost-type-names": [ "pv", "num-hopcount" ] 740 }, 741 "property-map": "propmap-delay", 742 "uses": [ "my-default-networkmap" ] 743 }, 744 "endpoint-multicost-map" : { 745 "uri": "http://alto.exmaple.com/endpointcostmap/multicost", 746 "media-type": "application/alto-endpointcost+json", 747 "accepts": "application/alto-endpointcostparams+json", 748 "capabilities": { 749 "cost-constraints": true, 750 "cost-type-names": [ "pv", "num-routingcost" ], 751 "max-cost-types": 2 752 }, 753 "property-map": "propmap-availbw" 754 }, 755 "propmap-availbw-delay" : { 756 "uri": "http://alto.exmaple.com/propmap/availbw", 757 "media-type": "application/alto-propmap+json", 758 "accepts": "application/alto-propmapparams+json", 759 "capabilities": { 760 "domain-types": [ "ane" ], 761 "prop-types": [ "availbw" ] 762 } 763 }, 764 "propmap-location" : { 765 "uri": "http://alto.exmaple.com/propmap/delay", 766 "media-type": "application/alto-propmap+json", 767 "accepts": "application/alto-propmapparams+json", 768 "capabilities": { 769 "domain-types": [ "pid" ], 770 "prop-types": [ "location" ] 771 } 772 } 773 } 774 } 776 7.3. Example # 1 778 POST /costmap/pv HTTP/1.1 779 Host: alto.example.com 780 Accept: multipart/related, application/alto-costmap+json, 781 application/alto-propmap+json, application/alto-error+json 782 Content-Length: [TBD] 783 Content-Type: application/alto-costmapfilter+json 785 { 786 "cost-type": { 787 "cost-mode": "array", 788 "cost-metric": "ane-path" 789 }, 790 "pids": { 791 "srcs": [ "PID1" ], 792 "dsts": [ "PID2", "PID3" ] 793 } 794 } 796 HTTP/1.1 200 OK 797 Content-Length: [TBD] 798 Content-Type: multipart/related; boundary=42 800 --42 801 Content-Type: application/alto-costmap+json 803 { 804 "meta": { 805 "dependent-vtags": [ 806 { 807 "resource-id": "default-network-map", 808 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 809 } 810 ], 811 "cost-type": { 812 "cost-mode": "array", 813 "cost-metric": "ane-path" 814 }, 815 }, 817 "cost-map": { 818 "PID1": { 819 "PID2": [ "ane:L001", "ane:L003" ], 820 "PID3": [ "ane:L001", "ane:L004" ] 821 } 822 } 823 } 825 --42 826 Content-Type: application/alto-propmap+json 828 { 829 "property-map": { 830 "ane:L001": { "delay": 46}, 831 "ane:L003": { "delay": 50}, 832 "ane:L004": { "delay": 70} 833 } 834 } 836 --42-- 838 7.4. Example # 2 840 POST /endpointcostmap/multicost HTTP/1.1 841 Host: alto.example.com 842 Accept: multipart/related, application/alto-endpointcost+json, 843 application/alto-propmap+json, application/alto-error+json 844 Content-Length: [TBD] 845 Content-Type: application/alto-endpointcostparams+json 846 { 847 "multi-cost-types": [ 848 { 849 "cost-mode": "array", 850 "cost-metric": "ane-path" 851 }, 852 { 853 "cost-mode": "numerical", 854 "cost-metric": "routingcost" 855 } 856 ], 857 "endpoints": { 858 "srcs": [ "ipv4:192.0.2.2" ], 859 "dsts": [ "ipv4:192.0.2.89", 860 "ipv4:203.0.113.45", 861 "ipv6:2001:db8::10" ] 862 } 863 } 865 HTTP/1.1 200 OK 866 Content-Length: [TBD] 867 Content-Type: multipart/related; boundary=example-2 869 --example-2 870 Content-Type: application/alto-endpointcost+json 872 { 873 "meta": { 874 "multi-cost-types": [ 875 {"cost-mode": "array", "cost-metric": "ane-path"}, 876 {"cost-mode": "numerical", "cost-metric": "routingcost"} 877 ] 878 }, 880 "endpoint-cost-map": { 881 "ipv4:192.0.2.2": { 882 "ipv4:192.0.2.89": [[ "ane:L001", "ane:L003", "ane:L004" ], 77], 883 "ipv4:203.0.113.45": [[ "ane:L001", "ane:L004", "ane:L005" ], 68], 884 "ipv6:2001:db8::10": [[ "ane:L001", "ane:L005", "ane:L007" ], 98] 885 } 886 } 887 } 889 --example-2 890 Content-Type: application/alto-propmap+json 892 { 893 "property-map": { 894 "ane:L001": { "availbw": 50 }, 895 "ane:L003": { "availbw": 48 }, 896 "ane:L004": { "availbw": 55 }, 897 "ane:L005": { "availbw": 60 }, 898 "ane:L007": { "availbw": 35 } 899 } 900 } 902 --example-2-- 904 8. Compatibility 906 8.1. Compatibility with Legacy ALTO Clients/Servers 908 Legacy ALTO clients SHOULD NOT send queries with the path-vector 909 extension and ALTO servers with this extension SHOULD NOT have any 910 compatibility issue. Legacy ALTO servers do not support cost types 911 with cost mode being "array" and cost metric being "ane-path", so 912 they MUST NOT announce the extended cost types in IRD. Thus, ALTO 913 clients MUST NOT send queries specified in this extension to base 914 ALTO servers according to Section 11.3.2.3 [RFC7285]. 916 8.2. Compatibility with Multi-Cost Extensions 918 Path Vector is not a testable cost type. Any format of constraints 919 SHOULD NOT be applied to cost type path-vector in order for multi- 920 cost to support the path-vector extension. Specifically, 922 o Cost type path-vector MUST NOT be included in "testable-cost- 923 types-names" or "testable-cost-types". 925 o When "testable-cost-types-names" is omitted in the "capabilities" 926 and "testable-cost-types" is omitted in the input parameters, 927 "constraints" or "or-constraints" SHOULD NOT add any format of 928 constraints on cost type path-vector. 930 8.3. Compatibility with Incremental Update 932 Without considering the incremental update of multipart/related 933 information, there is no compatibility issue with incremental update 934 extension. Compatibility issue with the incremental update of 935 multipart/related information will be discussed and addressed in the 936 next version. 938 9. Design Decisions and Discussions 940 9.1. Provide More General Calendar Extension 942 Cost Calendar is proposed as a useful ALTO extension to provide the 943 historical cost values for Filtered Cost Map Service and Endpoint 944 Cost Service. Since path vector is an extension to these services, 945 it SHOULD be compatible with Cost Calendar extension. 947 However, the calendar of a path-vector (Endpoint) Cost Map is 948 insufficient for the application which requires the historical data 949 of routing state information. The (Endpoint) Cost Map can only 950 provide the changes of the paths. But more useful information is the 951 history of network element properties which are recorded in the 952 dependent Network Element Property Map. 954 Before the Unified Property Map is introduced as an ALTO extension, 955 Filtered Cost Map Service and Endpoint Cost Service are the only 956 resources which require the calendar supported. Because other 957 resources don't have to be updated frequently. But Network Element 958 Property Map as a use case of Unified Property Map will collect the 959 real-time information of the network. It SHOULD be updated as soon 960 as possible once the metrics of network elements change. 962 So the requirement is to provide a general calendar extension which 963 not only meets the Filtered Cost Map and Endpoint Cost Service but 964 also applies to the Property Map Service. 966 10. Security Considerations 968 10.1. Privacy Concerns 970 We can identify multiple potential security issues. A main security 971 issue is network privacy, as the path-vector information may reveal 972 more network internal structures than the more abstract single-node 973 abstraction. The network should consider protection mechanisms to 974 reduce information exposure, in particular, in settings where the 975 network and the application do not belong to the same trust domain. 976 On the other hand, in a setting of the same trust domain, a key 977 benefit of the path-vector abstraction is reduced information 978 transfer from the network to the application. 980 The path-vector query may also reveal more information about the 981 application. In particular, the application may reveal all potential 982 transfers sites (e.g., where the data source is replicated, and where 983 the potential replication sites are). The application should 984 evaluate the potential privacy concerns. 986 Beyond the privacy issues, the computation of the path-vector is 987 unlikely to be cachable, in that the results will depend on the 988 particular requests (e.g., where the flows are distributed). Hence, 989 this service may become an entry point for denial of service attacks 990 on the availability of an ALTO server. Hence, authenticity and 991 authorization of this ALTO service may need to be better protected. 993 10.2. Resource Consumption on ALTO Servers 995 The Abstract Network Element Property Map is dynamically enriched 996 when the (Filtered) Cost Map/Endpoint Cost Service is queried of the 997 path-vector information. The properties of the abstract network 998 elements can consume a large amount of resources when cached. So, a 999 time-to-live is needed to remove outdated entries in the Network 1000 Element Property Map. 1002 11. IANA Considerations 1004 11.1. ALTO Cost Mode Registry 1006 This document specifies a new cost mode "array". However, the base 1007 ALTO protocol does not have a Cost Mode Registry where new cost mode 1008 can be registered. This new cost mode will be registered once the 1009 registry is defined either in a revised version of [RFC7285] or in 1010 another future extension. 1012 11.2. ALTO Cost Metric Registry 1014 A new cost metric needs to be registered in the "ALTO Cost Metric 1015 Registry", listed in Table 2. 1017 +-------------+---------------------+ 1018 | Identifier | Intended Semantics | 1019 +-------------+---------------------+ 1020 | ane-path | See Section 5.1.2 | 1021 +-------------+---------------------+ 1023 Table 2: ALTO Cost Metrics 1025 11.3. ALTO Network Element Property Type Registry 1027 The "ALTO Abstract Network Element Property Type Registry" is 1028 required by the ALTO Entity Domain "ane", listed in Table 3. 1030 +-------------+--------------------------+ 1031 | Identifier | Intended Semantics | 1032 +-------------+--------------------------+ 1033 | availbw | The available bandwidth | 1034 | delay | The transmission delay | 1035 +-------------+--------------------------+ 1037 Table 3: ALTO Abstract Network Element Property Types 1039 12. Acknowledgments 1041 The authors would like to thank discussions with Randriamasy Sabine, 1042 Andreas Voellmy, Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao 1043 Xiang, Tianyuan Liu, Xiao Shi, Xin Wang, and Yan Luo. 1045 13. References 1047 13.1. Normative References 1049 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1050 Requirement Levels", BCP 14, RFC 2119, 1051 DOI 10.17487/RFC2119, March 1997, . 1054 13.2. Informative References 1056 [I-D.amante-i2rs-topology-use-cases] 1057 Medved, J., Previdi, S., Lopez, V., and S. Amante, 1058 "Topology API Use Cases", draft-amante-i2rs-topology-use- 1059 cases-01 (work in progress), October 2013. 1061 [I-D.bernstein-alto-topo] 1062 Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology 1063 Service: Uses Cases, Requirements, and Framework", draft- 1064 bernstein-alto-topo-00 (work in progress), October 2013. 1066 [I-D.clemm-i2rs-yang-network-topo] 1067 Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N., 1068 and H. Ananthakrishnan, "A YANG Data Model for Network 1069 Topologies", draft-clemm-i2rs-yang-network-topo-01 (work 1070 in progress), October 2014. 1072 [I-D.ietf-alto-cost-calendar] 1073 Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. 1074 Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- 1075 calendar-01 (work in progress), February 2017. 1077 [I-D.ietf-alto-unified-props-new] 1078 Roome, W. and Y. Yang, "Extensible Property Maps for the 1079 ALTO Protocol", draft-ietf-alto-unified-props-new-00 (work 1080 in progress), July 2017. 1082 [I-D.lee-alto-app-net-info-exchange] 1083 Lee, Y., Bernstein, G., Choi, T., and D. Dhody, "ALTO 1084 Extensions to Support Application and Network Resource 1085 Information Exchange for High Bandwidth Applications", 1086 draft-lee-alto-app-net-info-exchange-02 (work in 1087 progress), July 2013. 1089 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 1090 RFC 2387, DOI 10.17487/RFC2387, August 1998, 1091 . 1093 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1094 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1095 "Application-Layer Traffic Optimization (ALTO) Protocol", 1096 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1097 . 1099 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1100 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 1101 DOI 10.17487/RFC8189, October 2017, . 1104 Authors' Addresses 1106 Greg Bernstein 1107 Grotto Networking 1108 Fremont, CA 1109 USA 1111 Email: gregb@grotto-networking.com 1113 Shiwei Dawn Chen 1114 Tongji University 1115 4800 Caoan Road 1116 Shanghai 201804 1117 China 1119 Email: dawn_chen_f@hotmail.com 1120 Kai Gao 1121 Tsinghua University 1122 Beijing Beijing 1123 China 1125 Email: gaok12@mails.tsinghua.edu.cn 1127 Young Lee 1128 Huawei 1129 TX 1130 USA 1132 Email: leeyoung@huawei.com 1134 Wendy Roome 1135 Nokia/Bell Labs 1136 600 Mountain Ave, Rm 3B-324 1137 Murray Hill, NJ 07974 1138 USA 1140 Phone: +1-908-582-7974 1141 Email: wendy.roome@nokia.com 1143 Michael Scharf 1144 Nokia 1145 Germany 1147 Email: michael.scharf@nokia.com 1149 Y. Richard Yang 1150 Yale University 1151 51 Prospect St 1152 New Haven CT 1153 USA 1155 Email: yry@cs.yale.edu 1156 Jingxuan Jensen Zhang 1157 Tongji University 1158 4800 Caoan Road 1159 Shanghai 201804 1160 China 1162 Email: jingxuan.n.zhang@gmail.com