idnits 2.17.1 draft-ietf-alto-path-vector-01.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 == Line 486 has weird spacing: '...NString tag;...' == Line 487 has weird spacing: '...NString query...' -- The document date (July 3, 2017) is 2489 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 1025, but not defined == Unused Reference: 'I-D.amante-i2rs-topology-use-cases' is defined on line 1200, but no explicit reference was found in the text == Unused Reference: 'I-D.clemm-i2rs-yang-network-topo' is defined on line 1210, but no explicit reference was found in the text == Unused Reference: 'I-D.gao-alto-fcs' is defined on line 1216, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-cost-calendar' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-incr-update-sse' is defined on line 1226, but no explicit reference was found in the text == Unused Reference: 'I-D.lee-alto-app-net-info-exchange' is defined on line 1236, 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 (-07) exists of draft-gao-alto-fcs-01 == Outdated reference: A later version (-21) exists of draft-ietf-alto-cost-calendar-01 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-03 == Outdated reference: A later version (-10) exists of draft-ietf-alto-multi-cost-07 == Outdated reference: A later version (-04) exists of draft-lee-alto-app-net-info-exchange-02 Summary: 1 error (**), 0 flaws (~~), 16 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: January 4, 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 July 3, 2017 19 ALTO Extension: Path Vector Cost Mode 20 draft-ietf-alto-path-vector-01.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 January 4, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. Use Case: Capacity Region for Multi-Flow Scheduling . . . . . 5 80 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 4.1. Path Vector . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.2. Cost Type Extension . . . . . . . . . . . . . . . . . . . 8 83 4.3. Abstract Network Element Property Map . . . . . . . . . . 8 84 4.4. New Media Type: multipart/related . . . . . . . . . . . . 8 85 5. Path-Vector Extension: Basic Data Types . . . . . . . . . . . 9 86 5.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 9 87 5.1.1. Cost Metric . . . . . . . . . . . . . . . . . . . . . 9 88 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 10 89 5.2. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 10 90 5.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 10 91 5.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 10 92 5.3. Abstract Network Element Name . . . . . . . . . . . . . . 11 93 5.4. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 11 94 6. Path-Vector Extension: Services . . . . . . . . . . . . . . . 11 95 6.1. IRD Extensions . . . . . . . . . . . . . . . . . . . . . 11 96 6.2. Cost Map Extensions . . . . . . . . . . . . . . . . . . . 12 97 6.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . 12 98 6.2.2. Capabilities . . . . . . . . . . . . . . . . . . . . 12 99 6.2.3. Property-map . . . . . . . . . . . . . . . . . . . . 12 100 6.2.4. Response . . . . . . . . . . . . . . . . . . . . . . 13 101 6.3. Filtered Cost Map Extensions . . . . . . . . . . . . . . 13 102 6.3.1. Media Type . . . . . . . . . . . . . . . . . . . . . 13 103 6.3.2. Capabilities . . . . . . . . . . . . . . . . . . . . 13 104 6.3.3. Property-map . . . . . . . . . . . . . . . . . . . . 14 105 6.3.4. Accept Input Parameters . . . . . . . . . . . . . . . 14 106 6.3.5. Response . . . . . . . . . . . . . . . . . . . . . . 14 107 6.4. Endpoint Cost Service Extensions . . . . . . . . . . . . 14 108 6.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . 15 109 6.4.2. Capabilities . . . . . . . . . . . . . . . . . . . . 15 110 6.4.3. Property-map . . . . . . . . . . . . . . . . . . . . 15 111 6.4.4. Accept Input Parameters . . . . . . . . . . . . . . . 15 112 6.4.5. Response . . . . . . . . . . . . . . . . . . . . . . 15 113 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 114 7.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 16 115 7.2. Information Resource Directory Example . . . . . . . . . 17 116 7.3. Single Query Example # 1 . . . . . . . . . . . . . . . . 18 117 7.4. Single Query Example # 2 . . . . . . . . . . . . . . . . 20 118 7.5. Multiple Queries Example . . . . . . . . . . . . . . . . 21 119 7.5.1. Endpoint Cost Service Example . . . . . . . . . . . . 21 120 7.5.2. Abstract Network Element Property Map Example . . . . 23 121 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 23 122 8.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 23 123 8.2. Compatibility with Multi-Cost Extensions . . . . . . . . 23 124 8.3. Compatibility with Incremental Update . . . . . . . . . . 24 125 9. Design Decisions and Discussions . . . . . . . . . . . . . . 24 126 9.1. Provide More General Calendar Extension . . . . . . . . . 24 127 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 128 10.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 24 129 10.2. Resource Consumption on ALTO Servers . . . . . . . . . . 25 130 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 131 11.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 25 132 11.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . 25 133 11.3. ALTO Entity Domain Registry . . . . . . . . . . . . . . 26 134 11.4. ALTO Network Element Property Type Registry . . . . . . 26 135 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 136 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 137 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 138 13.2. Informative References . . . . . . . . . . . . . . . . . 27 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 141 1. Introduction 143 The ALTO base protocol [RFC7285] is designed for exposing network 144 information through services such as the Network Map service and the 145 Cost Map service. These services use an extreme "single-node" 146 abstraction, which represents the whole network with a single node 147 and hosts with "endpoint groups" directly connected to the node. 149 Although the "single-node" abstraction works well in many settings, 150 it lacks the ability to support new emerging use cases, such as 151 inter-datacenter flow scheduling and scientific high-performance 152 computing data transfers. Specifically, the base ALTO protocol MUST 153 provide the following two functionalities: 155 o Providing information on shared bottlenecks: In the aforementioned 156 use cases, the volume of a single flow can reach 10s - 100s Gbps, 157 so that the network cannot treat the flows as independent like in 158 the base ALTO protocol. In this case, ALTO servers MUST be able 159 to provide information on shared bottlenecks to help applications 160 avoid congestion. 162 o Encapsulating multiple cost values in a single session: Some flow 163 scheduling problems take multiple metrics into consideration. 164 Making multiple queries introduces larger communication overhead, 165 and more importantly, out-of-sync data for different cost types. 166 Encapsulating multiple cost values in a single query and response 167 session reduces communication overhead and simplifies the 168 synchronization in use cases involving multiple cost types. 170 This draft aims to extend the base ALTO protocol to support these new 171 functionalities, with the path-vector extension. The path-vector 172 extension specifies how to encode the shared bottlenecks in a network 173 for a given set of flows with many design details driven by 174 effectiveness, performance and backward compatibility considerations. 176 The second functionality for simple cost types, such as those 177 introduced in the base protocol, is already addressed in a recent 178 extension, e.g. [I-D.ietf-alto-multi-cost]. However, the path- 179 vector extension in this document has introduced a new cost type 180 which complicates the situation. Thus, the multiple cost 181 encapsulation must still be taken into consideration. 183 The document is organized as follows. Section 3 gives an example of 184 flow scheduling and illustrates the limitations of the base ALTO 185 protocol in such a use case. Section 4 gives an overview of the 186 path-vector extension, before specifying the details of the extension 187 in Section 5 and Section 6. Section 7 presents several examples, and 188 Section 9 explains some design decisions. Section 8 discusses 189 compatibility issues with some other ALTO extensions. Section 10 and 190 Section 11 discusses about security and IANA considerations. 192 2. Terminology 194 This document uses the same terms as defined in [RFC7285], 195 [I-D.ietf-alto-multi-cost] and [I-D.roome-alto-unified-props] with 196 the following additional terms: Abstract Network Element, Abstract 197 Network Element Name, Abstract Network Element Property, Abstract 198 Network Element Property Map and Path Vector. 200 o Abstract Network Element (ANE): An abstract network element is an 201 abstraction of network components, it can be an aggregation of 202 links, middle boxes, Virtualized Network Function (VNF), or even a 203 sub-network. An abstract network element has two attributes: 204 abstract network element name and abstract network element 205 property, which are defined below. 207 o Abstract Network Element Name (ANEN): An abstract network element 208 name is an identifier which uniquely identifies an abstract 209 network element, as defined in Section 5.3. 211 o Abstract Network Element Property (ANEP): An abstract network 212 element property is a specific metric associated with a given 213 abstract network element, as introduced in Section 4.3. An 214 abstract network element CAN have several network element 215 properties. 217 o Abstract Network Element Property Map (ANEP Map): An abstract 218 network element property map is a Filtered Property Map defined in 219 [I-D.roome-alto-unified-props] which supports the "ane" domain in 220 its "domain-types" capability. 222 o Path Vector (PV): A path vector is an array of abstract network 223 elements, representing an abstract path between entities (PIDs or 224 endpoints). 226 3. Use Case: Capacity Region for Multi-Flow Scheduling 228 Consider the case that routing is given. Then what application-layer 229 traffic optimization will focus on is traffic scheduling among 230 application-layer paths. Specifically, assume that an application 231 has control over a set of flows F = {f_1, f_2, ..., f_|F|}. If 232 routing is given, what the application can control is x_1, x_2, ..., 233 x_|F|, where x_i is the amount of traffic for flow i. Let x = [x_1, 234 ..., x_|F|] be the vector of the flow traffic amounts. Due to shared 235 links, feasible values of x where link capacities are not exceeded 236 can be a complex polytype. 238 Specifically, consider a network as shown in Figure 1. The network 239 has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches 240 sw1/sw3 provide access on one side, sw2/sw4 provide access on the 241 other side, and sw5-sw7 form the backbone. End hosts eh1 to eh4 are 242 connected to access switches sw1 to sw4 respectively. Assume that 243 the bandwidth of link eh1 -> sw1 and link sw1 -> sw5 are 150 Mbps, 244 and the bandwidth of the rest links are 100 Mbps. 246 +------+ 247 | | 248 --+ sw6 +-- 249 / | | \ 250 PID1 +-----+ / +------+ \ +-----+ PID2 251 eh1__| |_ / \ ____| |__eh2 252 | sw1 | \ +--|---+ +---|--+ / | sw2 | 253 +-----+ \ | | | |/ +-----+ 254 \_| sw5 +---------+ sw7 | 255 PID3 +-----+ / | | | |\ +-----+ PID4 256 eh3__| |__/ +------+ +------+ \____| |__eh4 257 | sw3 | | sw4 | 258 +-----+ +-----+ 260 Figure 1: Raw Network Topology. 262 The single-node ALTO topology abstraction of the network is shown in 263 Figure 2. 265 +----------------------+ 266 {eh1} | | {eh2} 267 PID1 | | PID2 268 +------+ +------+ 269 | | 270 | | 271 {eh3} | | {eh4} 272 PID3 | | PID4 273 +------+ +------+ 274 | | 275 +----------------------+ 277 Figure 2: Base Single-Node Topology Abstraction. 279 Consider an application overlay (e.g., a large data analysis system) 280 which needs to schedule the traffic among a set of end host source- 281 destination pairs, say eh1 -> eh2 and eh1 -> eh4. The application 282 can request a cost map providing end-to-end available bandwidth, 283 using 'availbw' as cost-metric and 'numerical' as cost-mode. 285 The application will receive from ALTO server that the bandwidth of 286 eh1 -> eh2 and eh1 -> eh4 are both 100 Mbps. But this information is 287 not enough. Consider the following two cases: 289 o Case 1: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw6 -> 290 sw7 -> sw2 -> eh2 and eh1 -> eh4 uses path eh1 -> sw1 -> sw5 -> 291 sw7 -> sw4 -> eh4, then the application will obtain 150 Mbps. 293 o Case 2: If eh1 -> eh2 uses the path eh1 -> sw1 -> sw5 -> sw7 -> 294 sw2 -> eh2 and eh1 -> eh4 uses the path eh1 -> sw1 -> sw5 -> sw7 295 -> sw4 -> eh4, then the application will obtain only 100 Mbps. 297 To allow applications to distinguish the two aforementioned cases, 298 the network needs to provide more details. In particular, it needs 299 to provide the following new capabilities: 301 o The network needs to expose more detailed routing information to 302 show the shared bottlenecks. 304 o The network needs to provide the necessary abstraction to hide the 305 real topology information as possible. 307 The path-vector extension defined in this document will satisfy all 308 the requirements. 310 See [I-D.bernstein-alto-topo] for a survey of use-cases where 311 extended network topology information is needed. 313 4. Overview 315 This section presents a non-normative overview of the path-vector 316 extension. It assumes the readers are familiar with (Filtered) Cost 317 Map and Endpoint Cost Service defined in [RFC7285], their extensions 318 defined in [I-D.ietf-alto-multi-cost] and Filtered Property Map 319 defined in [I-D.roome-alto-unified-props]. 321 4.1. Path Vector 323 A path vector is an array of abstract network elements, representing 324 an abstract path between entities (PIDs or endpoints). Each abstract 325 network element has two attributes: name and property. The abstract 326 network element names are encoded in cost maps and the abstract 327 network element properties are encoded in abstract network element 328 property maps. 330 4.2. Cost Type Extension 332 To provide abstract network element names of a path in cost maps, 333 each cost value is a list of abstract network element names. 334 However, as defined in Section 6.1.2 of [RFC7285], a cost mode is 335 either "numerical" or "ordinal", none of which can be used to present 336 a list. 338 This document specifies a new cost mode "array" and a new cost metric 339 "ane-path". The new cost mode "array" means each cost value in the 340 cost maps is a list. The new cost metric "ane-path" means each cost 341 value represents an abstract path consisting of abstract network 342 element names between two entities (PIDs or endpoints). 344 The new cost type follows the convention of the cost types in the 345 base protocol. For example: 347 +------------+--------------+---------------------------------------+ 348 | cost mode | cost metric | meaning | 349 +------------+--------------+---------------------------------------+ 350 | numerical | routingcost | a number representing the routing | 351 | | | cost | 352 | ordinal | hopcount | a ranking representing the hop count | 353 | array | ane-path | a list representing the ane path | 354 +------------+--------------+---------------------------------------+ 356 Table 1: Cost Types and Their Meanings 358 4.3. Abstract Network Element Property Map 360 Given that Cost Map and Endpoint Cost service now provide the 361 abstract network element names along a flow path, ALTO clients can 362 learn that there exist bottlenecks between different flows. However, 363 only providing the abstract network element names without abstract 364 network element properties is not enough, because ALTO clients often 365 require the information on specific metric values like the link 366 capacity. This document adopts the property map defined in a recent 367 draft [I-D.roome-alto-unified-props] to encode the properties of 368 abstract network elements. A new domain "ane" is registered in the 369 property map. Each entity in the "ane" domain is an abstract network 370 element. The property map which supports "ane" domain is an Abstract 371 Network Element Property Map. 373 4.4. New Media Type: multipart/related 375 In the base ALTO protocol, ALTO servers use media types in the HTTP 376 header to indicate the type of the response. Typically one response 377 only contains a single media type, such as "application/alto- 378 costmap+json" or "application/alto-propmap+json". This has limited 379 the capability of ALTO servers to return multiple services in a 380 single response. 382 Thus, an ALTO client MUST make multiple queries to get the 383 information from services of different types. This has led to the 384 data synchronization problem between dependent ALTO services because 385 when making the second query, the result for the first query may have 386 already changed. The very same problem can happen to Network Map and 387 Cost Map resources. However, unlike Network Map and Cost Map which 388 are considered more stable, path vectors and the dependent abstract 389 network element property maps might change more frequently. 391 Instead of introducing a new media type to encapsulate multiple types 392 in a single response, this documents adopts the "multipart" media 393 type defined in [RFC2387]. Thus, a response can contain both the 394 path vector as a Cost Map (or Endpoint Cost Map) and the 395 corresponding abstract network element property map as a Property 396 Map. The media types of the path vector and the abstract network 397 element property map can still be retrieved from the response, 398 achieving consistency with the base ALTO protocol. 400 For backward compatibility, this extension also allows ALTO clients 401 to make multiple queries instead of encapsulating abstract network 402 element property map along with the path vector. Thus, each Cost Map 403 or Endpoint Cost Service with this extension MUST include a "prop- 404 map" in their capabilities to indicate where to retrieve the network 405 element properties. An additional field "query-id" MUST also be 406 added to the "vtag" field to uniquely identify a path vector query 407 session. 409 5. Path-Vector Extension: Basic Data Types 411 This section formally specifies the path-vector extension of some 412 basic data types. 414 5.1. Cost Type 416 This document extends the cost types defined in Section 6.1 of 417 [RFC7285] by introducing a new cost mode "array" and a new cost 418 metric "ane-path". 420 5.1.1. Cost Metric 422 This document specifies a new cost metric: "ane-path". It is of type 423 CostMetric as defined in Section 10.6 of [RFC7285]. The cost metric 424 "ane-path" MUST NOT be used when the cost mode is not "array" unless 425 it is explicitly specified by a future extension. Meanwhile, an ALTO 426 server with path-vector extension MUST support the cost metric "ane- 427 path". 429 Cost metric "ane-path": This cost metric MUST be encoded as the 430 JSONString "ane-path". 432 5.1.2. Cost Mode 434 This document extends the CostMode defined in Section 10.5 of 435 [RFC7285] with a new cost mode: "array". The extended CostMode is 436 encoded as a string and MUST have a value of either "numerical", 437 "ordinal" or "array" unless it is explicitly specified by a future 438 extension. In particular, this extension has specified that when the 439 cost metric is "ane-path", the cost value MUST be interpreted as a 440 JSONArray of Abstract Network Element Names (defined in Section 5.3). 442 An ALTO cost service MUST return a JSONArray of JSONValue when the 443 cost mode is "array" unless the interpretation is explicitly 444 specified by an ALTO extension. 446 Cost mode "array": This cost mode MUST be encoded as the JSONString 447 "array". 449 5.2. ANE Domain 451 This document specifies a new domain in addition to the ones in [I- 452 D.roome-alto-unified-props]. 454 5.2.1. Domain Name 456 ane 458 5.2.2. Domain-Specific Entity Addresses 460 The entity address of ane domain is encoded as a JSON string. The 461 string MUST be no more than 64 characters, and it MUST NOT contain 462 characters other than US-ASCII alphanumeric characters 463 (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', 464 U+002D), the colon (':', U+003A), the at sign ('@', code point 465 U+0040), the low line ('_', U+005F), or the '.' separator (U+002E). 466 The '.' separator is reserved for future use and MUST NOT be used 467 unless specifically indicated in this document, or an extension 468 document. 470 5.3. Abstract Network Element Name 472 An Abstract Network Element Name MUST be encoded as an EntityAddr as 473 defined in Section 5.2.2. It MUST belong to the "ane" domain. 475 5.4. Version Tag 477 This document extends the VersionTag, previously defined in 478 Section 10.3 of [RFC7285] with an optional field "query-id". If an 479 ALTO cost service supports the path-vector extension, this field MUST 480 be included in the "vtag" field, and the "vtag" field MUST be 481 included in the "meta" field in the response in order to provide the 482 "query-id" information. 484 object { 485 ResourceID resource-id; 486 JSONString tag; 487 [JSONString query-id;] 488 } VersionTag; 490 resource-id, tag: As defined in Section 10.3 of [RFC7285]. 492 query-id: A string used to uniquely identify the abstract network 493 element names in the response and correlate abstract network 494 element names with abstract network element properties. A "query- 495 id" MUST be encoded in the same format as defined in Section 10.1 496 of [RFC7285]. 498 6. Path-Vector Extension: Services 500 This section extends IRDResourceEntry, Cost Map Service and Endpoint 501 Cost Service. 503 6.1. IRD Extensions 505 This document extends IRDResourceEntry defined in Section 9.2.2 of 506 [RFC7285] by introducing a new entry named "property-map", which 507 indicates where the specific properties of the abstract network 508 elements can be retrieved. The IRDResourceEntry object is extended 509 as follows: 511 object { 512 JSONString uri; 513 JSONString media-type; 514 [JSONString accepts;] 515 [Capabilities capabilities;] 516 [ResourceID uses<0..*>;] 517 [ResourceID property-map;] 518 } IRDResourceEntry; 520 uri, media-type, accepts, capabilities, uses: The same as defined in 521 Section 9.2.2 of [RFC7285]. 523 property-map: A resource ID defined in the same IRD pointing to an 524 abstract network element property map as defined in Section 2. 526 6.2. Cost Map Extensions 528 This document extends the Cost Map defined in Section 11.2.3 of 529 [RFC7285]. 531 The specifications for "HTTP method", "accept input parameters" and 532 "uses" are the same as defined in Section 11.2.3 of [RFC7285]. 534 6.2.1. Media Type 536 The path vector extension now enables ALTO clients to receive 537 multiple services in a cost map response. 539 Specifically, if an ALTO client accepts "multipart/related", 540 "application/alto-costmap+json" and "application/alto-propmap+json" 541 at the same time, the ALTO server MUST use "multipart/related" as the 542 media type in the HTTP header. 544 6.2.2. Capabilities 546 If a service supports the path-vector extension, the "cost-type- 547 names" field MUST include a single cost type with "ane-path" as cost 548 metric and "array" as cost mode. 550 6.2.3. Property-map 552 If a service supports the path-vector extension, the "property-map" 553 field MUST be specified. This field is a resource ID of an abstract 554 network element property map where the abstract network element 555 properties are provided. 557 6.2.4. Response 559 If an ALTO client accepts "multipart/related" as defined in 560 Section 6.3.1, HTTP body of the response MUST consists of two parts 561 with the media types "application/alto-costmap+json" and 562 "application/alto-propmap+json" accordingly. Specifically, the part 563 with media type "application/alto-costmap+json" MUST be the first 564 part. 566 The content of the "application/alto-costmap+json" part uses the 567 format in Section 11.2.3.6 of [RFC7285] with the following 568 constraints: 570 o The cost value for a path vector query, e.g. the cost mode is 571 "array" and the cost metric is "ane-path", MUST be encoded as a 572 JSONArray of AbstractNetworkElementName. 574 o If the query sent by the client includes cost type path vector, 575 the "vtag" field defined in Section 5.4 has to be included in the 576 response. And the "query-id" information in "vtag" MUST be 577 provided to ALTO clients. 579 6.3. Filtered Cost Map Extensions 581 This document extends the Filtered Cost Map defined in Section 4.1 of 582 [I-D.ietf-alto-multi-cost]. 584 The specifications for "HTTP method" and "uses" are the same as 585 defined in Section 4.1 of [I-D.ietf-alto-multi-cost]. 587 6.3.1. Media Type 589 The same as Section 6.2.1. 591 6.3.2. Capabilities 593 The FilteredCostMapCapabilities object has the same format as defined 594 in Section 4.1.1 of [I-D.ietf-alto-multi-cost] with the following 595 constraint: 597 testable-cost-type-names: The path vector cost type with "ane-path" 598 as the cost metric and "array" as the cost mode MUST NOT be 599 included in "testable-cost-type-names". 601 6.3.3. Property-map 603 The same as Section 6.2.3. 605 6.3.4. Accept Input Parameters 607 The ReqFilteredCostMap uses the same format as defined in 608 Section 4.1.2 of [I-D.ietf-alto-multi-cost], with the following 609 constraints: 611 constraints, or-constraints: If the path vector cost type is 612 included in either "cost-type" or "multi-cost-types", ALTO clients 613 MUST NOT use it in "constraints" or "or-constraints". Otherwise, 614 the ALTO server MUST return an error with error code 615 "E_INVALID_FIELD_VALUE". 617 testable-cost-types: The path vector cost type MUST NOT be included 618 in the "testable-cost-types" field. Otherwise, the ALTO server 619 MUST return an error with error code "E_INVALID_FIELD_VALUE". 621 6.3.5. Response 623 If an ALTO client accepts "multipart/related" as defined in 624 Section 6.3.1, HTTP body of the response MUST consist of two parts 625 with the media types "application/alto-costmap+json" and 626 "application/alto-propmap+json" accordingly. Specifically, the part 627 with media type "application/alto-costmap+json" MUST be the first 628 part. 630 The content of the "application/alto-costmap+json" part has the same 631 format as defined in Section 4.1.3 of [I-D.ietf-alto-multi-cost] with 632 the following constraints: 634 o When the path vector cost type is included in "cost type" or 635 "multi-cost-type", the corresponding cost value MUST be encoded as 636 a JSONArray of AbstractNetworkElementName. 638 o If the query sent by the client includes cost type path vector, 639 the "vtag" field defined in Section 5.4 has to be included in the 640 response. And the "query-id" information in "vtag" MUST be 641 provided to ALTO clients. 643 6.4. Endpoint Cost Service Extensions 645 This document extends the Endpoint Cost Service defined in 646 Section 4.2 in [I-D.ietf-alto-multi-cost]. 648 The specifications for "HTTP method" and "uses" are the same as 649 defined in Section 4.2 in [I-D.ietf-alto-multi-cost]. 651 6.4.1. Media Type 653 The path vector extension now enables ALTO clients to receive 654 multiple objects from the endpoint cost service response. 656 Specifically, if an ALTO client accepts "multipart/related", 657 "application/alto-endpointcost+json" and "application/alto- 658 propmap+json" at the same time, the ALTO server MUST use "multipart/ 659 related" as the media type in the HTTP header. 661 6.4.2. Capabilities 663 The same as defined in Section 6.3.2. 665 6.4.3. Property-map 667 The same as Section 6.2.3. 669 6.4.4. Accept Input Parameters 671 The ReqEndpointCostMap uses the same format as defined in 672 Section 4.2.2 of [I-D.ietf-alto-multi-cost], with the following 673 constraints: 675 cost-type, multi-cost-types: ALTO clients MUST include the path 676 vector cost type, e.g. the one with "ane-path" as cost metric and 677 "array" as cost mode, in either "cost-type" or "multi-cost-types" 678 to activate the path vector extension. 680 constraints, or-constraints: If the path vector cost type is 681 included in either "cost-type" or "multi-cost-types", ALTO clients 682 MUST NOT use it in "constraints" or "or-constraints". Otherwise, 683 the ALTO server MUST return an error with error code 684 "E_INVALID_FIELD_VALUE". 686 testable-cost-types: The path vector cost type MUST NOT be included 687 in the "testable-cost-types" field. Otherwise, the ALTO server 688 MUST return an error with error code "E_INVALID_FIELD_VALUE". 690 6.4.5. Response 692 If an ALTO client accepts "multipart/related" as defined in 693 Section 6.4.1, HTTP body of the response MUST consist of two parts 694 with the media types "application/alto-endpointcost+json" and 695 "application/alto-propmap+json" accordingly. Specifically, the part 696 with media type "application/alto-endpointcost+json" MUST be the 697 first part. 699 The content of the "application/alto-endpointcost+json" part has the 700 same format as defined in Section 4.2.3 of [I-D.ietf-alto-multi-cost] 701 with the following constraints: 703 o When the path vector cost type is included in "cost type" or 704 "multi-cost-type", the corresponding cost value MUST be encoded as 705 a JSONArray of AbstractNetworkElementName. 707 o If the query sent by the client includes cost type path vector, 708 the "vtag" field defined in Section 5.4 has to be included in the 709 response. And the "query-id" information in "vtag" MUST be 710 provided to ALTO clients. 712 7. Examples 714 This section lists a series of examples to proceed the flow 715 scheduling use case in Section 3. 717 7.1. Workflow 719 This section gives a typical workflow of an ALTO client using the 720 path-vector extension. 722 1. Send a GET request for the whole Information Resource Directory. 724 2. Look for the resource of the (Filtered) Cost Map/Endpoint Cost 725 Service which contains the path vector cost type and get the 726 resource ID of the dependent abstract network element property 727 map. 729 3. Check whether the capabilities of the property map includes the 730 desired "prop-types". 732 4. Send a path-vector request which accepts "multipart/related" 733 media type following Section 6.2.1, Section 6.3.1 or 734 Section 6.4.1. 736 Alternatively, one can replace step 4 with the following: 738 1. Send a path-vector request which accepts "application/alto- 739 costmap+json" or "application/alto-endpointcost+json". 741 2. Find the "query-id" in "vtag" in the response. 743 3. Query the dependent abstract network element property map with 744 the query ID and abstract network element names to retrieve the 745 associated properties. 747 7.2. Information Resource Directory Example 749 Here is an example of an Information Resource Directory. In this 750 example, filtered cost map "cost-map-pv" doesn't support the multi- 751 cost extension but support the path-vector extension, "endpoint- 752 multicost-map" supports both multi-cost extension and path-vector 753 extension. Filtered Property Map "propmap-delay-availbw" supports 754 properties "availbw" and "delay", and "propmap-location" supports 755 property "location". 757 { 758 "meta": { 759 "cost-types": { 760 "pv": { 761 "cost-mode": "array", 762 "cost-metric": "ane-path" 763 }, 764 "num-routingcost": { 765 "cost-mode": "numerical", 766 "cost-metric": "routingcost" 767 }, 768 "num-hopcount": { 769 "cost-mode": "numerical", 770 "cost-metric": "hopcount" 771 } 772 } 773 }, 774 "resources": { 775 "my-default-networkmap": { 776 "uri" : "http://alto.example.com/networkmap", 777 "media-type" : "application/alto-networkmap+json" 778 } 779 "cost-map-pv" : { 780 "uri": "http://alto.example.com/costmap/pv", 781 "media-type": "application/alto-costmap+json", 782 "accepts": "application/alto-costmapfilter+json", 783 "capabilities": { 784 "cost-type-names": [ "pv", "num-hopcount" ] 785 }, 786 "property-map": "propmap-delay", 787 "uses": [ "my-default-networkmap" ] 788 }, 789 "endpoint-multicost-map" : { 790 "uri": "http://alto.exmaple.com/endpointcostmap/multicost", 791 "media-type": "application/alto-endpointcost+json", 792 "accepts": "application/alto-endpointcostparams+json", 793 "capabilities": { 794 "cost-constraints": true, 795 "cost-type-names": [ "pv", "num-routingcost" ], 796 "max-cost-types": 2 797 }, 798 "property-map": "propmap-availbw" 799 }, 800 "propmap-availbw" : { 801 "uri": "http://alto.exmaple.com/propmap/availbw", 802 "media-type": "application/alto-propmap+json", 803 "accepts": "application/alto-propmapparams+json", 804 "capabilities": { 805 "domain-types": [ "ane" ], 806 "prop-types": [ "delay", "availbw" ] 807 } 808 }, 809 "propmap-delay" : { 810 "uri": "http://alto.exmaple.com/propmap/delay", 811 "media-type": "application/alto-propmap+json", 812 "accepts": "application/alto-propmapparams+json", 813 "capabilities": { 814 "domain-types": [ "ane" ], 815 "prop-types": [ "delay" ] 816 } 817 } 818 } 819 } 821 7.3. Single Query Example # 1 823 POST /costmap/pv HTTP/1.1 824 Host: alto.example.com 825 Accept: multipart/related, application/alto-costmap+json, 826 application/alto-propmap+json, application/alto-error+json 827 Content-Length: [TBD] 828 Content-Type: application/alto-costmapfilter+json 830 { 831 "cost-type": { 832 "cost-mode": "array", 833 "cost-metric": "ane-path" 834 }, 835 "pids": { 836 "srcs": [ "PID1" ], 837 "dsts": [ "PID2", "PID3" ] 838 } 840 } 842 HTTP/1.1 200 OK 843 Content-Length: [TBD] 844 Content-Type: multipart/related; boundary=42 846 --42 847 Content-Type: application/alto-costmap+json 849 { 850 "meta": { 851 "dependent-vtags": [ 852 { 853 "resource-id": "default-network-map", 854 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 855 } 856 ], 857 "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" }, 859 "vtag": { 860 "resource-id": "cost-map-pv", 861 "tag": "27612897acf278ffu3287c284dd28841da78213", 862 "query-id": "query1" 863 } 864 }, 866 "cost-map": { 867 "PID1": { 868 "PID2": [ "ane:L001", "ane:L003" ], 869 "PID3": [ "ane:L001", "ane:L004" ] 870 } 871 } 872 } 874 --42 875 Content-Type: application/alto-propmap+json 877 { 878 "property-map": { 879 "ane:L001": { "delay": 46}, 880 "ane:L003": { "delay": 50}, 881 "ane:L004": { "delay": 70} 882 } 883 } 885 --42-- 887 7.4. Single Query Example # 2 889 POST /endpointcostmap/multicost HTTP/1.1 890 Host: alto.example.com 891 Accept: multipart/related, application/alto-costmap+json, 892 application/alto-propmap+json, application/alto-error+json 893 Content-Length: [TBD] 894 Content-Type: application/alto-costmapfilter+json 896 { 897 "multi-cost-types": [ 898 { 899 "cost-mode": "array", 900 "cost-metric": "ane-path" 901 }, 902 { 903 "cost-mode": "numerical", 904 "cost-metric": "routingcost" 905 } 906 ], 907 "endpoints": { 908 "srcs": [ "ipv4:192.0.2.2" ], 909 "dsts": [ "ipv4:192.0.2.89", 910 "ipv4:203.0.113.45", 911 "ipv6:2001:db8::10" ] 912 } 913 } 915 HTTP/1.1 200 OK 916 Content-Length: [TBD] 917 Content-Type: multipart/related; boundary=example-2 919 --example-2 920 Content-Type: application/alto-endpointcost+json 922 { 923 "meta": { 924 "multi-cost-types": [ 925 {"cost-mode": "array", "cost-metric": "ane-path"}, 926 {"cost-mode": "numerical", "cost-metric": "routingcost"} 927 ] 928 "vtag": { 929 "resource-id": "endpoint-multicost-map", 930 "tag": "47612897acf278ffa3287cb84dd28841da78213", 931 "query-id": "query2" 932 } 933 }, 934 "endpoint-cost-map": { 935 "ipv4:192.0.2.2": { 936 "ipv4:192.0.2.89": [[ "ane:L001", "ane:L003", "ane:L004" ], 77], 937 "ipv4:203.0.113.45": [[ "ane:L001", "ane:L004", "ane:L005" ], 68], 938 "ipv6:2001:db8::10": [[ "ane:L001", "ane:L005", "ane:L007" ], 98] 939 } 940 } 941 } 943 --example-2 944 Content-Type: application/alto-propmap+json 946 { 947 "property-map": { 948 "ane:L001": { "availbw": 50 }, 949 "ane:L003": { "availbw": 48 }, 950 "ane:L004": { "availbw": 55 }, 951 "ane:L005": { "availbw": 60 }, 952 "ane:L007": { "availbw": 35 } 953 } 954 } 956 --example-2-- 958 7.5. Multiple Queries Example 960 7.5.1. Endpoint Cost Service Example 961 POST /endpointcostmap/multicost HTTP/1.1 962 Host: alto.example.com 963 Accept: application/alto-costmap+json, application/alto-error+json 964 Content-Length: [TBD] 965 Content-Type: application/alto-costmapfilter+json 967 { 968 "multi-cost-types": [ 969 { 970 "cost-mode": "array", 971 "cost-metric": "ane-path" 972 }, 973 { 974 "cost-mode": "numerical", 975 "cost-metric": "routingcost" 976 } 977 ], 978 "endpoints": { 979 "srcs": [ "ipv6:2001:db8::10" ], 980 "dsts": [ "ipv4:192.0.2.3", 981 "ipv4:203.0.113.56" ] 982 } 983 } 985 HTTP/1.1 200 OK 986 Content-Length: [TBD] 987 Content-Type: application/alto-endpointcost+json 989 { 990 "meta": { 991 "vtag": { 992 "resource-id": "endpoint-multicost-map", 993 "tag": "f7622897bcf278ffu3287c284dd23841da78213", 994 "query-id": "query3" 995 }, 996 "multi-cost-types": [ 997 { "cost-mode": "array", "cost-metric": "ane-path" }, 998 { "cost-mode": "numerical", "cost-metric": "routingcost"} 999 ] 1000 }, 1001 "endpoint-cost-map": { 1002 "ipv6:2001:db8::10": { 1003 "ipv4:192.0.2.3": [ "ane:L001", "ane:L006" ], 1004 "ipv4:203.0.113.56": [ "ane:L001", "ane:L007" ] 1005 } 1006 } 1007 } 1009 7.5.2. Abstract Network Element Property Map Example 1011 POST /propmap/availbw HTTP/1.1 1012 Host: alto.example.com 1013 Accept: application/alto-propmap+json,application/alto-error+json 1014 Content-Length: [TBD] 1015 Content-Type: application/alto-propmapparams+json 1017 { 1018 "query-id": "query3", 1019 "entities" : [ "ane:L001", 1020 "ane:L006" ], 1021 "properties" : [ "availbw" ] 1022 } 1024 HTTP/1.1 200 OK 1025 Content-Length: [TBD] 1026 Content-Type: application/alto-propmap+json 1028 { 1029 "property-map": { 1030 "ane:L001": { "availbw": 25 }, 1031 "ane:L006": { "availbw": 40 } 1032 } 1033 } 1035 8. Compatibility 1037 8.1. Compatibility with Legacy ALTO Clients/Servers 1039 Legacy ALTO clients SHOULD NOT send queries with the path-vector 1040 extension and ALTO servers with this extension SHOULD NOT have any 1041 compatibility issue. Legacy ALTO servers do not support cost types 1042 with cost mode being "array" and cost metric being "ane-path", so 1043 they MUST NOT announce the extended cost types in IRD. Thus, ALTO 1044 clients MUST NOT send queries specified in this extension to legacy 1045 ALTO servers according to Section 11.3.2.3 [RFC7285]. 1047 8.2. Compatibility with Multi-Cost Extensions 1049 Path Vector is not a testable cost type. Any format of constraints 1050 SHOULD NOT be applied to cost type path-vector in order for multi- 1051 cost to support the path-vector extension. Specifically, 1053 o Cost type path-vector MUST NOT be included in "testable-cost- 1054 types-names" or "testable-cost-types". 1056 o When "testable-cost-types-names" is omitted in the "capabilities" 1057 and "testable-cost-types" is omitted in the input parameters, 1058 "constraints" or "or-constraints" SHOULD NOT add any format of 1059 constraints on cost type path-vector. 1061 8.3. Compatibility with Incremental Update 1063 Without considering the incremental update of multipart/related 1064 information, there is no compatibility issue with incremental update 1065 extension. Compatibility issue with the incremental update of 1066 multipart/related information will be discussed and addressed in the 1067 next version. 1069 9. Design Decisions and Discussions 1071 9.1. Provide More General Calendar Extension 1073 Cost Calendar is proposed as a useful ALTO extension to provide the 1074 historical cost values for Filtered Cost Map Service and Endpoint 1075 Cost Service. Since path vector is an extension to these services, 1076 it SHOULD be compatible with Cost Calendar extension. 1078 However, the calendar of a path-vector (Endpoint) Cost Map is 1079 insufficient for the application which requires the historical data 1080 of routing state information. The (Endpoint) Cost Map can only 1081 provide the changes of the paths. But more useful information is the 1082 history of network element properties which are recorded in the 1083 dependent Network Element Property Map. 1085 Before the Unified Property Map is introduced as an ALTO extension, 1086 Filtered Cost Map Service and Endpoint Cost Service are the only 1087 resources which require the calendar supported. Because other 1088 resources don't have to be updated frequently. But Network Element 1089 Property Map as a use case of Unified Property Map will collect the 1090 real-time information of the network. It SHOULD be updated as soon 1091 as possible once the metrics of network elements change. 1093 So the requirement is to provide a general calendar extension which 1094 not only meets the Filtered Cost Map and Endpoint Cost Service but 1095 also applies to the Property Map Service. 1097 10. Security Considerations 1099 10.1. Privacy Concerns 1101 We can identify multiple potential security issues. A main security 1102 issue is network privacy, as the path-vector information may reveal 1103 more network internal structures than the more abstract single-node 1104 abstraction. The network should consider protection mechanisms to 1105 reduce information exposure, in particular, in settings where the 1106 network and the application do not belong to the same trust domain. 1107 On the other hand, in a setting of the same trust domain, a key 1108 benefit of the path-vector abstraction is reduced information 1109 transfer from the network to the application. 1111 The path-vector query may also reveal more information about the 1112 application. In particular, the application may reveal all potential 1113 transfers sites (e.g., where the data source is replicated, and where 1114 the potential replication sites are). The application should 1115 evaluate the potential privacy concerns. 1117 Beyond the privacy issues, the computation of the path-vector is 1118 unlikely to be cachable, in that the results will depend on the 1119 particular requests (e.g., where the flows are distributed). Hence, 1120 this service may become an entry point for denial of service attacks 1121 on the availability of an ALTO server. Hence, authenticity and 1122 authorization of this ALTO service may need to be better protected. 1124 10.2. Resource Consumption on ALTO Servers 1126 The Abstract Network Element Property Map is dynamically enriched 1127 when the (Filtered) Cost Map/Endpoint Cost Service is queried of the 1128 path-vector information. The properties of the abstract network 1129 elements can consume a large amount of resources when cached. So, a 1130 time-to-live is needed to remove outdated entries in the Network 1131 Element Property Map. 1133 11. IANA Considerations 1135 11.1. ALTO Cost Mode Registry 1137 This document specifies a new cost mode "array". However, the base 1138 ALTO protocol does not have a Cost Mode Registry where new cost mode 1139 can be registered. This new cost mode will be registered once the 1140 registry is defined either in a revised version of [RFC7285] or in 1141 another future extension. 1143 11.2. ALTO Cost Metric Registry 1145 A new cost metric needs to be registered in the "ALTO Cost Metric 1146 Registry", listed in Table 2. 1148 +-------------+---------------------+ 1149 | Identifier | Intended Semantics | 1150 +-------------+---------------------+ 1151 | ane-path | See Section 5.1.1 | 1152 +-------------+---------------------+ 1154 Table 2: ALTO Cost Metrics 1156 11.3. ALTO Entity Domain Registry 1158 As proposed in Section 9.2 of [I-D.roome-alto-unified-props], "ALTO 1159 Entity Domain Registry" is requested. Besides, a new domain is to be 1160 registered, listed in Table 3. 1162 +-------------+--------------------------+--------------------------+ 1163 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1164 +-------------+--------------------------+--------------------------+ 1165 | ane | See Section 5.2.2 | None | 1166 +-------------+--------------------------+--------------------------+ 1168 Table 3: ALTO Entity Domain 1170 11.4. ALTO Network Element Property Type Registry 1172 The "ALTO Abstract Network Element Property Type Registry" is 1173 required by the ALTO Entity Domain "ane", listed in Table 4. 1175 +-------------+--------------------------+ 1176 | Identifier | Intended Semantics | 1177 +-------------+--------------------------+ 1178 | availbw | The available bandwidth | 1179 | delay | The transmission delay | 1180 +-------------+--------------------------+ 1182 Table 4: ALTO Abstract Network Element Property Types 1184 12. Acknowledgments 1186 The authors would like to thank discussions with Andreas Voellmy, 1187 Erran Li, Haibin Son, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan 1188 Liu, Xiao Shi, Xin Wang, and Yan Luo. 1190 13. References 1191 13.1. Normative References 1193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1194 Requirement Levels", BCP 14, RFC 2119, 1195 DOI 10.17487/RFC2119, March 1997, 1196 . 1198 13.2. Informative References 1200 [I-D.amante-i2rs-topology-use-cases] 1201 Medved, J., Previdi, S., Lopez, V., and S. Amante, 1202 "Topology API Use Cases", draft-amante-i2rs-topology-use- 1203 cases-01 (work in progress), October 2013. 1205 [I-D.bernstein-alto-topo] 1206 Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology 1207 Service: Uses Cases, Requirements, and Framework", draft- 1208 bernstein-alto-topo-00 (work in progress), October 2013. 1210 [I-D.clemm-i2rs-yang-network-topo] 1211 Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N., 1212 and H. Ananthakrishnan, "A YANG Data Model for Network 1213 Topologies", draft-clemm-i2rs-yang-network-topo-01 (work 1214 in progress), October 2014. 1216 [I-D.gao-alto-fcs] 1217 Gao, K., Zhang, J., Wang, J., Xiang, Q., and Y. Yang, 1218 "ALTO Extension: Flow-based Cost Query", draft-gao-alto- 1219 fcs-01 (work in progress), March 2017. 1221 [I-D.ietf-alto-cost-calendar] 1222 Randriamasy, S., Yang, Y., Wu, Q., Lingli, D., and N. 1223 Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- 1224 calendar-01 (work in progress), February 2017. 1226 [I-D.ietf-alto-incr-update-sse] 1227 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1228 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 1229 sse-03 (work in progress), September 2016. 1231 [I-D.ietf-alto-multi-cost] 1232 Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1233 ALTO", draft-ietf-alto-multi-cost-07 (work in progress), 1234 March 2017. 1236 [I-D.lee-alto-app-net-info-exchange] 1237 Lee, Y., Bernstein, G., Choi, T., and D. Dhody, "ALTO 1238 Extensions to Support Application and Network Resource 1239 Information Exchange for High Bandwidth Applications", 1240 draft-lee-alto-app-net-info-exchange-02 (work in 1241 progress), July 2013. 1243 [I-D.roome-alto-unified-props] 1244 Roome, W., "Extensible Property Maps for the ALTO 1245 Protocol", draft-roome-alto-unified-props-01 (work in 1246 progress), July 2016. 1248 [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", 1249 RFC 2387, DOI 10.17487/RFC2387, August 1998, 1250 . 1252 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1253 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1254 "Application-Layer Traffic Optimization (ALTO) Protocol", 1255 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1256 . 1258 Authors' Addresses 1260 Greg Bernstein 1261 Grotto Networking 1262 Fremont, CA 1263 USA 1265 Email: gregb@grotto-networking.com 1267 Shiwei Dawn Chen 1268 Tongji University 1269 4800 Caoan Road 1270 Shanghai 201804 1271 China 1273 Email: dawn_chen_f@hotmail.com 1275 Kai Gao 1276 Tsinghua University 1277 Beijing Beijing 1278 China 1280 Email: gaok12@mails.tsinghua.edu.cn 1281 Young Lee 1282 Huawei 1283 TX 1284 USA 1286 Email: leeyoung@huawei.com 1288 Wendy Roome 1289 Nokia/Bell Labs 1290 600 Mountain Ave, Rm 3B-324 1291 Murray Hill, NJ 07974 1292 USA 1294 Phone: +1-908-582-7974 1295 Email: wendy.roome@nokia.com 1297 Michael Scharf 1298 Nokia 1299 Germany 1301 Email: michael.scharf@nokia.com 1303 Y. Richard Yang 1304 Yale University 1305 51 Prospect St 1306 New Haven CT 1307 USA 1309 Email: yry@cs.yale.edu 1311 Jingxuan Jensen Zhang 1312 Tongji University 1313 4800 Caoan Road 1314 Shanghai 201804 1315 China 1317 Email: jingxuan.n.zhang@gmail.com