idnits 2.17.1 draft-yang-alto-path-vector-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2595 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 1098, but not defined == Unused Reference: 'I-D.amante-i2rs-topology-use-cases' is defined on line 1292, but no explicit reference was found in the text == Unused Reference: 'I-D.clemm-i2rs-yang-network-topo' is defined on line 1302, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-cost-calendar' is defined on line 1308, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-incr-update-sse' is defined on line 1313, but no explicit reference was found in the text == Unused Reference: 'I-D.lee-alto-app-net-info-exchange' is defined on line 1323, 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 (-22) exists of draft-ietf-alto-incr-update-sse-03 == Outdated reference: A later version (-10) exists of draft-ietf-alto-multi-cost-05 == Outdated reference: A later version (-04) exists of draft-lee-alto-app-net-info-exchange-02 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG G. Bernstein 3 Internet-Draft Grotto Networking 4 Intended status: Standards Track S. Chen 5 Expires: September 14, 2017 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 March 13, 2017 19 ALTO Extension: Path Vector Cost Mode 20 draft-yang-alto-path-vector-04.txt 22 Abstract 24 The Application-Layer Traffic Optimization (ALTO) Service has defined 25 network and cost maps to provide basic network information, where the 26 cost maps allow only scalar (numerical or ordinal) cost mode values. 27 This document introduces a new cost mode called path-vector to allow 28 ALTO clients to support use cases such as capacity regions for 29 applications. This document starts with a non-normative example 30 called multi-flow scheduling (or capacity region) to illustrate that 31 ALTO cost maps without path vectors cannot provide sufficient 32 information. This document then defines path-vector as a new cost 33 mode. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 14, 2017. 58 Copyright Notice 60 Copyright (c) 2017 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Overview of Approach . . . . . . . . . . . . . . . . . . . . 5 77 2.1. Graph Model and Path Vector Data Format . . . . . . . . . 5 78 2.2. Network Element Property Map Data Format . . . . . . . . 6 79 2.3. Flow-based Query Data Format . . . . . . . . . . . . . . 6 80 2.4. Routing State Abstraction Service . . . . . . . . . . . . 6 81 3. Changes Since Version -03 . . . . . . . . . . . . . . . . . . 6 82 4. Use Case: Capacity Region for Multi-Flow Scheduling . . . . . 6 83 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 84 5.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . . . 8 85 5.1.1. Cost Metric . . . . . . . . . . . . . . . . . . . . . 8 86 5.1.2. Cost Mode: Path Vector . . . . . . . . . . . . . . . 9 87 5.2. Network Element Name . . . . . . . . . . . . . . . . . . 9 88 5.3. Entity Domains . . . . . . . . . . . . . . . . . . . . . 9 89 5.3.1. NE Domain . . . . . . . . . . . . . . . . . . . . . . 9 90 5.3.2. ANE Domain . . . . . . . . . . . . . . . . . . . . . 10 91 5.4. (Filtered) Network Element Property Map Resource . . . . 10 92 5.4.1. Media Type . . . . . . . . . . . . . . . . . . . . . 10 93 5.4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 10 94 5.4.3. Accept Input Parameters . . . . . . . . . . . . . . . 10 95 5.4.4. Capabilities . . . . . . . . . . . . . . . . . . . . 11 96 5.4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 11 97 5.4.6. Response . . . . . . . . . . . . . . . . . . . . . . 11 98 5.5. Cost Map Extensions . . . . . . . . . . . . . . . . . . . 11 99 5.5.1. Media Types . . . . . . . . . . . . . . . . . . . . . 11 100 5.5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 11 101 5.5.3. Accept Input Parameters . . . . . . . . . . . . . . . 11 102 5.5.4. Capabilities . . . . . . . . . . . . . . . . . . . . 11 103 5.5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 12 104 5.5.6. Response . . . . . . . . . . . . . . . . . . . . . . 12 105 5.6. Filtered Cost Map Extensions . . . . . . . . . . . . . . 12 106 5.6.1. Media Type . . . . . . . . . . . . . . . . . . . . . 12 107 5.6.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 12 108 5.6.3. Accept Input Parameters . . . . . . . . . . . . . . . 12 109 5.6.4. Capabilities . . . . . . . . . . . . . . . . . . . . 13 110 5.6.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 14 111 5.6.6. Response . . . . . . . . . . . . . . . . . . . . . . 14 112 5.7. Endpoint Cost Service Extensions . . . . . . . . . . . . 14 113 5.7.1. Media Type . . . . . . . . . . . . . . . . . . . . . 14 114 5.7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 15 115 5.7.3. Accept Input Parameters . . . . . . . . . . . . . . . 15 116 5.7.4. Capabilities . . . . . . . . . . . . . . . . . . . . 15 117 5.7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . 16 118 5.7.6. Response . . . . . . . . . . . . . . . . . . . . . . 16 119 5.8. Optional: RSA Extension . . . . . . . . . . . . . . . . . 16 120 5.8.1. Media Type . . . . . . . . . . . . . . . . . . . . . 16 121 5.8.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 16 122 5.8.3. Accept Input Parameters . . . . . . . . . . . . . . . 17 123 5.8.4. Capabilities . . . . . . . . . . . . . . . . . . . . 17 124 5.8.5. Response . . . . . . . . . . . . . . . . . . . . . . 17 125 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 126 6.1. Information Resource Directory Example . . . . . . . . . 17 127 6.2. Network Element Property Map Example . . . . . . . . . . 19 128 6.3. Filtered Cost Map Example #1 . . . . . . . . . . . . . . 19 129 6.4. Filtered Cost Map Example #2 . . . . . . . . . . . . . . 21 130 6.5. Endpoint Cost Map Example #1 . . . . . . . . . . . . . . 22 131 6.6. Endpoint Cost Map Example #2 . . . . . . . . . . . . . . 23 132 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 24 133 7.1. Compatibility with Legacy ALTO Clients/Servers . . . . . 24 134 7.2. Compatibility with Multi-Cost Extensions . . . . . . . . 25 135 7.3. Compatibility with Incremental Update . . . . . . . . . . 25 136 8. Design Decisions and Discussions . . . . . . . . . . . . . . 25 137 8.1. Path Vector or Path Graph? . . . . . . . . . . . . . . . 25 138 8.2. Provide More General Calendar Extension? . . . . . . . . 26 139 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 140 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 141 10.1. ALTO Cost Mode Registry . . . . . . . . . . . . . . . . 27 142 10.2. ALTO Cost Metric Registry . . . . . . . . . . . . . . . 27 143 10.3. ALTO Entity Domain Registry . . . . . . . . . . . . . . 27 145 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 146 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 147 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 148 12.2. Informative References . . . . . . . . . . . . . . . . . 28 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 151 1. Introduction 153 The ALTO base protocol [RFC7285] is designed for exposing network 154 information through services such as the Network Map service and the 155 Cost Map service. These services use the extreme "single-node" 156 abstraction, which represents a whole network with a single node and 157 hosts are connected to the node's access ports. 159 Although the "single-node" abstraction works well for many settings, 160 new use cases, such as inter-datacenter data transfers and scientific 161 high-performance computing data transfers, require additional network 162 information beyond the single-node abstraction, to support 163 application capabilities, in particular, the ability of application 164 flow scheduling. 166 Specifically, providing network information to support application 167 flow scheduling introduces multiple complexities. First, the 168 underlying assumption of existing ALTO services is single-commodity 169 flows. Hence, given the flow from a source to a destination, ALTO 170 computes the network metrics of the flow and returns them to the 171 application. The metrics for different flows are independent. 172 Application flow scheduling, however, requires network information to 173 compute application-desirable multi-commodity flows, where multiple 174 flows under the control of the same application may share common 175 network bottlenecks. This requirement is beyond the capability of 176 the single-node abstraction adopted by the base ALTO protocol. 177 Second, some flow scheduling problems may consider end-to-end metrics 178 at the same time and thus require multiple costs to be updated 179 simultaneously. Such a requirement, even though already addressed by 180 [I-D.ietf-alto-multi-cost], still needs to be handled very carefully. 181 Third, flow scheduling can be conducted with several independent sets 182 of flows. Using the cross product of "src" and "dst" lists will 183 introduce a lot of redundancies. 185 To address these complexities in supporting the new flow scheduling 186 use case, this document specifies a path vector extension to the base 187 ALTO protocol. This extension introduces a new family of cost types, 188 which uses "path-vector" as cost mode and "ne" (network element) or 189 "ane" (abstract network element) as cost metric. It also extends 190 "Unified Property Map" defined in [I-D.roome-alto-unified-props] to 191 address the issue of scalability and consistency in providing path 192 vectors with fine-grained information, and declares "pid-flows" and 193 "endpoint-flows" to support queries for multiple independent flow 194 sets. This document also registers new domains, entity specification 195 and properties in the ALTO Entity Domain Registry. 197 The document is organized as follows. Section 2 gives an overview of 198 the path vector extension. Section 4 gives an example of flow 199 scheduling to illustrate the need to introduce cost mode "path- 200 vector" and new cost metrics. Section 5 specifies the new cost mode 201 and cost metrics, new domain types and entity properties, new 202 resource Network Element Property Map, and protocol extensions for 203 (Filtered) Cost Maps and Endpoint Cost Services. Section 6 presents 204 examples of Information Resources, requests and responses. Section 7 205 discusses the compatibility issues with some other proposed ALTO 206 extensions. Section 8 lists several to-be-determined design 207 decisions. Section 9 discusses about security and Section 10 208 discusses about IANA Considerations. 210 2. Overview of Approach 212 This section presents a non-normative overview of the path vector 213 extension defined in this document. It assumes the readers are 214 familiar with Cost Map and Endpoint Cost Service defined in 215 [RFC7285], and Unified Property Map defined in 216 [I-D.roome-alto-unified-props]. 218 2.1. Graph Model and Path Vector Data Format 220 In this document, the graph model presented to ALTO clients is 221 represented by path vectors. A path vector between two entities 222 (either PIDs or endpoints) is an array of Network Element Names, 223 where each Network Element Name represents a network element (usually 224 a link) in the path between the two entities. 226 A specific Network Element Name MUST represent the same network 227 element in the same ALTO Network Element Property Map resource. 228 Thus, ALTO clients can find the flows that share this specific 229 network element by finding the source-destination pairs whose 230 corresponding path vectors contain the Network Element Name. 232 The cost entries contained in an ALTO Cost Map or Endpoint Cost Map 233 are formally defined in Section 11.2.3.6 [RFC7285] to be any type of 234 JSON value. But the section also suggests that implementations may 235 assume the cost values are numbers unless specifically defined by an 236 extension. This document extends the definition of Cost Map and 237 Endpoint Cost Map to allow the returned cost to be a path vector, 238 which is a JSONArray of Network Element Names. 240 An example can be found in Section 6.3. 242 2.2. Network Element Property Map Data Format 244 An ALTO client may need not know all attributes associated with all 245 network elements. Thus, Network Element Property Map is provided so 246 after an ALTO client obtains the path vectors, it can use Network 247 Element Names to selectively query the associated attributes in the 248 corresponding Network Element Property Map. 250 2.3. Flow-based Query Data Format 252 Flow scheduling may involve multiple sets of flows which have 253 different source-destination combinations. Using source and 254 destination lists can lead to a lot of redundancies. To allow more 255 flexible specification of path vector requests, two new filter types 256 for ReqFilteredCostMap and ReqEndpointCostMap are specified in this 257 document. 259 2.4. Routing State Abstraction Service 261 For security and scalability considerations, this document specifies 262 an optional feature called Routing State Abstraction (RSA). Routing 263 State Abstraction feature compresses the original path vector 264 information without loss of equivalence. A Routing State Abstraction 265 compression feature MUST be applied only when a (Filtered) Cost Map 266 or Endpoint Cost Service provides the path vector cost type with cost 267 metric being "ane". 269 3. Changes Since Version -03 271 o Define "ne" and "ane" as the only cost metrics of the cost mode 272 "path-vector". 274 o Define new entity domains for network property map and add the 275 "availbw", "delay" property to these domains. 277 o Use Unified Property service to query properties of network 278 elements. 280 o Augment the request schema of the (Filtered) Cost Map and Endpoint 281 Cost Service. 283 4. Use Case: Capacity Region for Multi-Flow Scheduling 285 Consider the case that routing is given. Then what application-layer 286 traffic optimization will focus on is traffic scheduling among 287 application-layer paths. Specifically, assume that an application 288 has control over a set of flows F = {f_1, f_2, ..., f_|F|}. If 289 routing is given, what the application can control is x_1, x_2, ..., 290 x_|F|, where x_i is the amount of traffic for flow i. Let x = [x_1, 291 ..., x_|F|] be the vector of the flow traffic amounts. Due to shared 292 links, feasible values of x where link capacities are not exceeded 293 can be a complex polytype. 295 Specifically, consider a network as shown in Figure 1. The network 296 has 7 switches (sw1 to sw7) forming a dumb-bell topology. Switches 297 sw1/sw3 provide access on one side, sw2/sw4 provide access on the 298 other side, and sw5-sw7 form the backbone. End hosts eh1 to eh4 are 299 connected to access switches sw1 to sw4 respectively. Assume that 300 the bandwidth of each link is 100 Mbps. 302 +------+ 303 | | 304 --+ sw6 +-- 305 / | | \ 306 PID1 +-----+ / +------+ \ +-----+ PID2 307 eh1__| |_ / \ ____| |__eh2 308 | sw1 | \ +--|---+ +---|--+ / | sw2 | 309 +-----+ \ | | | |/ +-----+ 310 \_| sw5 +---------+ sw7 | 311 PID3 +-----+ / | | | |\ +-----+ PID4 312 eh3__| |__/ +------+ +------+ \____| |__eh4 313 | sw3 | | sw4 | 314 +-----+ +-----+ 316 Figure 1: Raw Network Topology. 318 The single-node ALTO topology abstraction of the network is shown in 319 Figure 2. 321 +----------------------+ 322 {eh1} | | {eh2} 323 PID1 | | PID2 324 +------+ +------+ 325 | | 326 | | 327 {eh3} | | {eh4} 328 PID3 | | PID4 329 +------+ +------+ 330 | | 331 +----------------------+ 333 Figure 2: Base Single-Node Topology Abstraction. 335 Consider an application overlay (e.g., a large data analysis system) 336 which needs to schedule the traffic among a set of end host source- 337 destination pairs, say eh1 -> eh2, and eh3 -> eh4. The application 338 can request a cost map providing end-to-end available bandwidth, 339 using 'availbw' as cost-metric and 'numerical' as cost-mode. 341 Assume that the application receives from the ALTO server that the 342 bandwidth of eh1 -> eh2 and eh3 ->eh4 are both 100 Mbps. It cannot 343 determine that if it schedules the two flows together, whether it 344 will obtain a total of 100 Mbps or 200 Mbps. This depends on whether 345 the routing paths of the two flows share a bottleneck in the 346 underlying topology: 348 o Case 1: If eh1 -> eh2 and eh3 -> eh4 use different paths, for 349 example, when the first uses sw1 -> sw5 -> sw7 -> sw2, and the 350 second uses sw3 -> sw5 -> sw6 -> sw7 -> sw4. Then the application 351 will obtain 200 Mbps. 353 o Case 2: If eh1 -> eh2 and eh3 -> eh4 share a bottleneck, for 354 example, when both use the direct link sw5 -> sw7, then the 355 application will obtain only 100 Mbps. 357 To allow applications to distinguish the two aforementioned cases, 358 the network needs to provide more details. The path vector extension 359 defined in this document resolves this issue. 361 See [I-D.bernstein-alto-topo] for a survey of use-cases where 362 extended network topology information is needed. 364 5. Protocol Extensions 366 This section formally specifies the path vector extension. 368 5.1. Cost Type 370 The path vector extension defined in this document extends the Cost 371 Types as specified in Section 6.1 of [RFC7285] . 373 5.1.1. Cost Metric 375 This document specifies two new cost metrics: "ne" and "ane". Both 376 cost metrics are of type CostMetric as defined in Section 10.6 of 377 [RFC7285]. These cost metrics MUST NOT be used when the cost mode is 378 not "path-vector" unless it is explicitly specified in a future 379 extension. An ALTO server with path vector extension MUST support at 380 least one of these two cost metrics. 382 Cost metric "ne": This cost metric MUST be encoded as the JSONString 383 "ne". When cost metric is "ne", Network Element Names contained 384 in the path vectors MUST be resource-specific. In this case, 385 different path vector queries to the same (Filtered) Cost Map or 386 Endpoint Cost Service MUST have the same Network Element Property 387 Map in the responses. 389 Cost metric "ane": This cost metric MUST be encoded as the 390 JSONString "ane". When cost metric is "ane", Network Element 391 Names contained in the path vector MUST be query-specific. In 392 this case, different path vector queries to the same (Filtered) 393 Cost Map or Endpoint Cost Service MAY have different Network 394 Element Property Maps. 396 5.1.2. Cost Mode: Path Vector 398 This document extends the cost mode as defined in Section 10.5 of 399 [RFC7285] by allowing an ALTO server to provide a new cost mode other 400 than "numerical" and "ordinal". The path vector cost mode is of type 401 CostMode and is encoded as the JSONString "path-vector". 403 A (Filtered) Cost Map resource or Endpoint Cost Service, when queried 404 with this cost mode, MUST return a CostMapData or EndpointCostMapData 405 whose costs are JSONArrays of type NetworkElementName as specified in 406 Section 5.2. 408 This cost mode MUST be used with either cost metric "ne" or "ane" 409 unless it is explicitly specified by a future extension. 411 5.2. Network Element Name 413 This document also extends [RFC7285] with a new basic data type: 414 Network Element Name. A Network Element Name is of type EntityAddr 415 as defined in Section 2.3 of [I-D.roome-alto-unified-props] and is 416 encoded as a JSONString. A Network Element Name MUST be an 417 EntityAddr either of the NE domain (Section 5.3.1) or of the ANE 418 domain (Section 5.3.2). 420 5.3. Entity Domains 422 This document specifies two new domains in addition to the ones in 423 [I-D.roome-alto-unified-props]. 425 5.3.1. NE Domain 427 5.3.1.1. Domain Name 429 ne 431 5.3.1.2. Domain-Specific Entity Addresses 433 Entity address of NE domain MUST be encoded as a JSONString with the 434 same format as PID name defined in Section 10.1 of [RFC7285]. 436 5.3.2. ANE Domain 438 5.3.2.1. Domain Name 440 ane 442 5.3.2.2. Domain-Specific Entity Addresses 444 The same as Section 5.3.1.2. 446 5.4. (Filtered) Network Element Property Map Resource 448 This document extends the base ALTO protocol with a new (filtered) 449 resource: (Filtered) Network Element Property Map. 451 A Network Element Property Map MUST be a Property Map as defined in 452 Section 4 of [I-D.roome-alto-unified-props] and a Filtered Network 453 Element Property Map MUST be a Filtered Property Map as defined in 454 Section 5 of [I-D.roome-alto-unified-props]. 456 5.4.1. Media Type 458 The media type of a (Filtered) Network Element Property Map resource 459 is "application/alto-propmap+json". 461 5.4.2. HTTP Method 463 An ALTO Network Element Property Map is requested using the HTTP GET 464 method. 466 An ALTO Filtered Network Element Property Map is requested using the 467 HTTP POST method. 469 5.4.3. Accept Input Parameters 471 Network Element Property Map does not accept any input parameters. 473 The input parameters of a Filtered Network Element Property Map MUST 474 conform to the format in Section 5.3 of 475 [I-D.roome-alto-unified-props]. The EntityAddr in the request MUST 476 have the same format as Network Element Name specified in 477 Section 5.2. 479 5.4.4. Capabilities 481 A (Filtered) Network Element Property Map MUST have capabilities 482 "domain-types" and "prop-types" as defined in Section 4.4 of 483 [I-D.roome-alto-unified-props]. The "domain-types" capability MUST 484 contain either "ne" or "ane" but not both at the same time and the 485 "prop-types" capability MUST contain property type "availbw". 487 5.4.5. Uses 489 None. 491 5.4.6. Response 493 The "vtag" field MUST be included in the "meta" field of a response 494 to a (Filtered) Network Element Map, with the same format as defined 495 in Section 11.2.1.6 of [RFC7285]. 497 The response is the same as for the Property Map, as defined in 498 Section 4.6 of [I-D.roome-alto-unified-props], except that only the 499 requested entities and properties are returned for Filtered Network 500 Element Map. Examples can be found in Section 6.2. 502 5.5. Cost Map Extensions 504 5.5.1. Media Types 506 The same as Section 11.2.3.1 of [RFC7285]. 508 5.5.2. HTTP Method 510 The same as Section 11.2.3.2 of [RFC7285]. 512 5.5.3. Accept Input Parameters 514 The same as Section 11.2.3.3 of [RFC7285]. 516 5.5.4. Capabilities 518 If a Cost Map resource supports the path vector extension defined in 519 this document, its "cost-type-names" capability MUST have exactly one 520 single cost type with the cost mode being "path-vector" and the cost 521 metric being either "ne" or "ane", unless it is explicitly specified 522 by a future extension. 524 5.5.5. Uses 526 The same as Section 11.2.3.5 of [RFC7285]. 528 5.5.6. Response 530 The response has the same format as in Section 4.1.3 of 531 [I-D.ietf-alto-multi-cost], except the follows. 533 o If cost mode is "path-vector", the costs MUST be JSONArrays of 534 Network Element Names. 536 o If cost mode is "path-vector", the "meta" field MUST include the 537 "nep-map" field, whose value is of type IRDResourceEntry as 538 defined in Section 9.2.2 of [RFC7285] and represents the Filtered 539 Network Element Property Map associated with this Cost Map as 540 defined in Section 5.4. An ALTO server providing this resource 541 MUST verify the following conditions are met: 543 o If cost metric of this Cost Map resource is "ne", the "nep-map" 544 entry MUST have "domain-types" capability which includes domain 545 name "ne". 547 o If cost metric of this Cost Map resource is "ane", the "nep-map" 548 entry MUST have "domain-types" capability which includes domain 549 name "ane". 551 ALTO servers MUST also verity the conditions in Section 5.1.1 are 552 also met. 554 5.6. Filtered Cost Map Extensions 556 5.6.1. Media Type 558 The same as Section 11.3.2.1 of [RFC7285]. 560 5.6.2. HTTP Method 562 The same as Section 11.3.2.2 of [RFC7285]. 564 5.6.3. Accept Input Parameters 566 This document extends the ReqFilteredCostMap as follows: 568 object { 569 [CostType cost-type;] 570 [CostType multi-cost-types<1..*>;] 571 [CostType testable-cost-types<1..*>;] 572 [JSONString constraints<0..*>;] 573 [JSONString or-constraints<1..*><1..*>;] 574 [PIDFilter pids;] 575 [PIDFlow pid-flows<1..*>;] 576 } ReqFilteredCostMap; 578 object { 579 PIDName src; 580 PIDName dst; 581 } PIDFlow; 583 pid-flows: A list of PID src to PID dst for which path costs are to 584 be returned. 586 pids: As defined in Section 11.3.2.3 of [RFC7285]. 588 cost-type, multi-cost-types, testable-cost-types, constraints, or- 589 constraints: 590 As defined in Section 4.1.2 of [I-D.ietf-alto-multi-cost]. A 591 valid query MUST be considered a path vector query, either when 592 "cost-type" of this query exists with "path-vector" cost mode, or 593 when "multi-cost-types" exists and exact one cost type uses "path- 594 vector" cost mode. For a path vector query, the path vector cost 595 type MUST follow the definition in Section 5.1, otherwise the ALTO 596 server SHOULD return an error with error code 597 "E_INVALID_FIELD_VALUE". If "multi-cost-types" contains multiple 598 path vector cost types, ALTO servers SHOULD return an error with 599 the error code "E_INVALID_FIELD_VALUE". If a query is a path 600 vector query and its "constraints" or "or-constraints" field is 601 present, the "testable-cost-types" field MUST be explicitly 602 specified and MUST NOT include any path vector cost type. If a 603 path vector cost type is included, an ALTO server SHOULD return an 604 error with the error code "E_INVALID_FIELD_VALUE". 606 An ALTO client MUST specify either "pids" or "pid-flows", but MUST 607 NOT specify both in a single query. 609 5.6.4. Capabilities 611 A Filtered Cost Map with the path vector extension MAY have the 612 "flow-based-filter" in its IRD capabilities. 614 object { 615 JSONString cost-type-names<1..*>; 616 [JSONBool cost-constraints;] 617 [JSONNumber max-cost-types;] 618 [JSONString testable-cost-type-names<1..*>;] 619 [JSONBool flow-based-filter;] 620 } FilteredCostMapCapabilities; 622 flow-based-filter: If the value is true, the ALTO server allows ALTO 623 clients to use "pid-flows" to query the Filtered Cost Map. If 624 false or not present, ALTO clients MUST NOT include this field in 625 the queries and the ALTO server SHOULD return an error with the 626 error code "E_INVALID_FIELD_TYPE" for the queries including this 627 field. 629 cost-type-names and cost-constraints: As defined in Section 11.3.2.4 630 of [RFC7285]. 632 max-cost-types and testable-cost-type-names: As defined in 633 Section 4.1.1 of [I-D.ietf-alto-multi-cost]. If a cost type with 634 "path-vector" mode is included in "cost-type-names", either the 635 "testable-cost-type-names" field is explicitly specified which 636 MUST NOT include any path vector cost type, or the "testable-cost- 637 type-names" field is empty where ALTO clients MUST interpret this 638 as specified in Section 4.1.1 of [I-D.ietf-alto-multi-cost] except 639 that the resource MUST NOT accept tests on any path vector cost 640 type. 642 5.6.5. Uses 644 The same as Section 5.5.5. 646 5.6.6. Response 648 The response MUST have the same format as defined in Section 5.5.6 649 with the supplement that if a query uses the field "pid-flows", the 650 response MUST still conform to the CostMapData format defined in 651 Section 11.2.3.6 of [RFC7285]. Examples can be found in Section 6.3. 653 5.7. Endpoint Cost Service Extensions 655 5.7.1. Media Type 657 The same as Section 11.5.1.1 of [RFC7285]. 659 5.7.2. HTTP Method 661 The same as Section 11.5.1.2 of [RFC7285]. 663 5.7.3. Accept Input Parameters 665 This document extends the input parameters of Endpoint Cost Service 666 as follows: 668 object { 669 [CostType cost-type;] 670 [CostType multi-cost-types<1..*>;] 671 [CostType testable-cost-types<1..*>;] 672 [JSONString constraints<0..*>;] 673 [JSONString or-constraints<1..*><1..*>;] 674 [EndpointFilter endpoints;] 675 [EndpointFlow endpoint-flows<1..*>;] 676 } ReqEndpointCostMap; 678 object { 679 TypedEndpointAddr src; 680 TypedEndpointAddr dst; 681 } EndpointFlow; 683 endpoint-flows: A list of source-destination endpoint pairs for 684 which path costs are to be returned. 686 endpoints: As defined in Section 11.5.1.3 of [RFC7285]. 688 cost-type, multi-cost-types, testable-cost-types, constraints, or- 689 constraints: 690 As defined in Section 5.6.3. 692 ALTO clients MUST specify either "endpoints" or "endpoint-flows", but 693 MUST NOT specify both in the same query. 695 5.7.4. Capabilities 697 This document defines EndpointCostMapCpabilities the same as 698 FilteredCostMapCapabilities in Section 5.6.4. 700 If the value of capability flow-based-filter is true, the ALTO server 701 MUST be able to process "endpoint-flows" in a query. If the value is 702 false or not present, ALTO clients MUST assume the "endpoint-flows" 703 is not supported and ALTO servers SHOULD return an error with the 704 error code "E_INVALID_FIELD_TYPE" if "endpoint-flows" is included in 705 the query. 707 5.7.5. Uses 709 The same as Section 11.5.1.5 of [RFC7285]. 711 5.7.6. Response 713 The response has the same format as in Section 4.2.3 of 714 [I-D.ietf-alto-multi-cost] for compatibility, except the follows. 716 o If cost mode is "path-vector", the costs MUST be JSONArrays of 717 Network Element Names. 719 o If cost mode is "path-vector", the "meta" field MUST include the 720 "nep-map" field, whose value is of type IRDResourceEntry as 721 defined in Section 9.2.2 of [RFC7285] and represents the Filtered 722 Network Element Property Map associated with this Endpoint Cost 723 Service as defined in Section 5.4. An ALTO server providing this 724 resource MUST verify the following conditions are met: 726 o If cost metric of this Endpoint Cost Service is "ne", the "nep- 727 map" entry MUST have "domain-types" capability which includes 728 domain name "ne". 730 o If cost metric of this Endpoint Cost Service is "ane", the "nep- 731 map" entry MUST have "domain-types" capability which includes 732 domain name "ane". 734 ALTO servers MUST also verity the conditions in Section 5.1.1 are 735 also met. 737 Examples can be found in Section 6.5. 739 5.8. Optional: RSA Extension 741 5.8.1. Media Type 743 RSA extension MUST NOT change media types of (Filtered) Cost Map 744 resource or Endpoint Cost Service. 746 5.8.2. HTTP Method 748 RSA extension MUST NOT change HTTP method for (Filtered) Cost Map or 749 Endpoint Cost Service. 751 5.8.3. Accept Input Parameters 753 RSA extension SHOULD NOT change the input parameters of a Filtered 754 Cost Map or an Endpoint Cost Service unless it is explicitly 755 specified by a future extension. 757 5.8.4. Capabilities 759 If a (Filtered) Cost Map or an Endpoint Cost Service supports RSA 760 extension, the "cost-type-names" MUST have one cost type with "path- 761 vector" cost mode and "ane" cost metric, and ALTO clients MUST ignore 762 this field when no such path vector cost type exists. The resource/ 763 service MUST also have the field "rsa" explicitly specified to "true" 764 in the "capabilities" field. If the "rsa" field has a value of 765 "false" or is not present, ALTO clients MUST assume this resource/ 766 service does not provide RSA compression. 768 An example can be found in Section 6.1. 770 5.8.5. Response 772 RSA extension SHOULD NOT change the output of a (Filtered) Cost Map 773 or an Endpoint Cost Service unless it is explicitly specified in a 774 future extension. 776 6. Examples 778 6.1. Information Resource Directory Example 780 Here is an example of an ALTO server's Information Resource 781 Directory. 783 "meta" { 784 "cost-types": { 785 "pv-ne": { 786 "cost-mode": "pv", 787 "cost-metric": "ne" 788 }, 789 "pv-ane": { 790 "cost-mode": "pv", 791 "cost-metric": "ane" 792 }, 793 "num-hopcount": { 794 "cost-mode": "numerical", 795 "cost-metric": "hopcount" 796 }, 797 "num-routingcost": { 798 "cost-mode": "numerical", 799 "cost-metric": "routingcost" 800 }, 801 "num-delay": { 802 "cost-mode": "numerial", 803 "cost-metric": "delay" 804 }, 805 "num-availbw": { 806 "cost-mode": "numerical", 807 "cost-metric": "availbw" 808 } 809 } 810 }, 811 "resource": { 812 "default-network-map": { 813 "uri": "http://alto.example.com/networkmap", 814 "media-type": "application/alto-networkmap+json" 815 }, 817 ... Filtered Cost Map Resource ... 819 "filtered-multi-cost-map1": { 820 "uri": "http://alto.example.com/costmap/multi/filtered1", 821 "media-type": "application/alto-costmap+json", 822 "accepts": "application/alto-costmapfilter+json", 823 "uses": ["default-network-map"], 824 "capabilities": { 825 "max-cost-types": 3, 826 "cost-type-names": ["pv-ne", "num-availbw", "num-hopcount"], 827 "testable-cost-types-names": ["num-availbw", "num-hopcount"] 828 } 829 }, 831 "filtered-multi-cost-map2": { 832 "uri": "http://alto.example.com/costmap/multi/filtered2", 833 "media-type": "application/alto-costmap", 834 "accepts": "application/alto-costmapfilter+json", 835 "uses": ["default-network-map"], 836 "capabilities": { 837 "max-cost-types":2, 838 "cost-type-names": ["pv-ne", "num-routingcost", "num-delay"], 839 "cost-constraints": true 840 } 841 } 842 ... Endpoint Cost Map Resource ... 844 "default-endpoint-cost-map": { 845 "uri": "http://alto.example.com//endpointcost/lookup/ne-ane", 846 "media-type": "application/alto-endpointcostmap+json", 847 "accepts": "application/alto-endpointcostparams+json", 848 "capabilities": { 849 "rsa": true, 850 "max-cost-types": 4, 851 "cost-type-names": ["pv-ne", "pv-ane", "num-routingcost", "num-hopcount"], 852 "testable-cost-types-names": ["num-hopcount", "num-routingcost"] 853 } 854 } 855 } 857 6.2. Network Element Property Map Example 859 POST /propmap/lookup/nep-map HTTP/1.1 860 Host: alto.example.com 861 Accept: application/alto-propmap+json,application/alto-error+json 862 Content-Length: [TBD] 863 Content-Type: application/alto-propmapparams+json 865 { 866 "entities" : [ "ne:ne12", 867 "ne:ne23", 868 "ne:ne34" ], 869 "properties" : [ "availbw", "delay" ] 870 } 872 HTTP/1.1 200 OK 873 Content-Length: [TBD] 874 Content-Type: application/alto-propmap+json 876 { 877 "meta": { 878 "vtag": { 879 "resource-id": "default-network-element-prop-map", 880 "tag": "babbc14521772381472bffefff627813909875dd" 881 } 882 } 883 "property-map": { 884 "ne:ne12": { "availbw": "90", "delay": "30" }, 885 "ne:ne23": { "availbw": "80", "delay": "15" }, 886 "ne:ne34": { "availbw": "70", "delay": "25" } 887 } 888 } 890 6.3. Filtered Cost Map Example #1 892 Assume that the available bandwidth between PID1 and PID3 is less 893 than 50. 895 POST /costmap/multi/filtered1 HTTP/1.1 896 Host: alto.example.com 897 Accept: application/alto-costmap+json,application/alto-error+json 898 Content-Length: [TBD] 899 Content-Type: application/alto-costmapfilter+json 901 { 902 "cost-type": { 903 "cost-mode": "path-vector", 904 "cost-metric": "ne" 905 }, 906 "testable-cost-types": [ 907 { "cost-mode": "numerical", "cost-metric": "availbw" }, 908 { "cost-mode": "numerical", "cost-metric": "hopcount" } 909 ], 910 "or-constraints": [ 911 ["[0] ge 50", "[1] le 100"] 912 ], 913 "pid-flows": [ 914 { "src": "PID1", "dst": "PID2" } 915 { "src": "PID1", "dst": "PID3" } 916 { "src": "PID3", "dst": "PID4" } 917 ] 918 } 920 HTTP/1.1 200 OK 921 Content-Length: [TBD] 922 Content-Type: application/alto-costmap+json 924 { 925 "meta": { 926 "dependent-vtags": [ 927 { 928 "resource-id": "my-default-network-map", 929 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 930 } 931 ], 932 "cost-type": { 933 "cost-mode": "path-vector", 934 "cost-metric": "ne" 935 }, 936 "nep-map": { 937 "uri": "http://alto.example.com/propmap/lookup/nep-map", 938 "media-type": "application/alto-prompmap+json", 939 "accepts": "application/alto-propmapparams+json", 940 "capabilities": { 941 "domain-types": ["ne"], 942 "prop-types": ["availbw", "delay"] 944 } 945 } 946 }, 947 "cost-map": { 948 "PID1": { "PID2": [ "ne:ne12", "ne:ne23" ] }, 949 "PID3": { "PID4": [ "ne:ne23", "ne:ne34" ] } 950 } 951 } 953 6.4. Filtered Cost Map Example #2 955 Assume that the delay between PID1 and PID2 is greater than 80. 957 POST /costmap/multi/filtered2 HTTP/1.1 958 Host: alto.example.com 959 Accept: application/alto-costmap+json,application/alto-error+json 960 Content-Length: [TBD] 961 Content-Type: application/alto-costmapfilter+json 963 { 964 "multi-cost-types": [ 965 { "cost-mode": "path-vector", "cost-metric": "ne" }, 966 { "cost-mode": "numerical", "cost-metric": "delay" } 967 ], 968 "testable-cost-types": [ 969 { "cost-mode": "numerical", "cost-metric": "delay" } 970 ], 971 "constraints": [ "[0] le 80" ], 972 "pid-flows": [ 973 { "src": "PID1", "dst": "PID2" }, 974 { "src": "PID1", "dst": "PID3" }, 975 { "src": "PID3", "dst": "PID4" } 976 ] 977 } 979 HTTP/1.1 200 OK 980 Content-Length: [TBD] 981 Content-Type: application/alto-costmap+json 983 { 984 "meta": { 985 "dependent-vtags": [ 986 { 987 "resource-id": "my-default-network-map", 988 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 989 } 990 ], 991 "cost-type": {}, 992 "multi-cost-types": [ 993 { "cost-mode": "path-vector", "cost-metric": "ne"}, 994 { "cost-mode": "numerical", "cost-metric": "delay"} 995 ], 996 "nep-map": { 997 "uri": "http://alto.example.com/propmap/lookup/nep-map", 998 "media-type": "application/alto-prompmap+json", 999 "accepts": "application/alto-propmapparams+json", 1000 "capabilities": { 1001 "domain-types": ["ne"], 1002 "prop-types": ["availbw", "delay"] 1003 } 1004 } 1005 }, 1006 "cost-map": { 1007 "PID1": { "PID3": [ [ "ne:ne23", "ne:ne45" ], 60 ] }, 1008 "PID3": { "PID4": [ [ "ne:ne23", "ne:ne34" ], 40 ] } 1009 } 1010 } 1012 6.5. Endpoint Cost Map Example #1 1014 Assume that the delay between ipv4:203.0.113.45 and 1015 ipv4:198.51.100.34 is greater than 100. 1017 POST /endpointcost/lookup HTTP/1.1 1018 Host: alto.example.com 1019 Accept: application/alto-endpointcost+json,application/alto-error+json 1020 Content-Length: [TBD] 1021 Content-Type: application/alto-endpointcostparams+json 1023 { 1024 "cost-type": { 1025 "cost-mode": "path-vector", 1026 "cost-metric": "ne" 1027 }, 1028 "testable-cost-types": [ 1029 { 1030 "cost-mode": "numerical", 1031 "cost-metric": "delay" 1032 } 1033 ], 1034 "constraints": [ 1035 "[0] le 100" 1036 ], 1037 "endpoint-flows": [ 1038 { "src": "ipv4:192.0.2.2", "dst": "ipv4:192.0.2.89" }, 1039 { "src": "ipv4:192.0.2.2", "dst": "ipv4:198.51.100.34" }, 1040 { "src": "ipv4:203.0.113.45", "dst": "ipv4:198.51.100.34" } 1041 ] 1042 } 1044 HTTP/1.1 200 OK 1045 Content-Length: [TBD] 1046 Content-Type: application/alto-endpointcost+json 1048 { 1049 "meta": { 1050 "cost-type": { 1051 "cost-mode": "path-vector", 1052 "cost-metric": "ne" 1053 }, 1054 "nep-map": { 1055 "uri": "http://alto.example.com/propmap/lookup/nep-map", 1056 "media-type": "application/alto-prompmap+json", 1057 "accepts": "application/alto-propmapparams+json", 1058 "capabilities": { 1059 "domain-types": ["ne"], 1060 "prop-types": ["availbw", "delay"] 1061 } 1062 } 1063 }, 1064 "endpoint-cost-map": { 1065 "ipv4:192.0.2.2": { 1066 "ipv4:192.0.2.89": [ "ne:ne12", "ne:ne23" ], 1067 "ipv4:198.51.100.34": [ "ne:ne12", "ne:ne24", "ne:ne45" ] 1068 } 1069 } 1070 } 1072 6.6. Endpoint Cost Map Example #2 1074 POST /endpointcost/lookup/ne-ane HTTP/1.1 1075 Host: alto.example.com 1076 Accept: application/alto-endpointcost+json,application/alto-error+json 1077 Content-Length: [TBD] 1078 Content-Type: application/alto-endpointcostparams+json 1080 { 1081 "multi-cost-types": [ 1082 { 1083 "cost-mode": "path-vector", 1084 "cost-metric": "ane" 1085 }, 1086 { 1087 "cost-mode": "numerical", 1088 "cost-metric": "delay" 1089 }], 1090 "endpoint-flows": [ 1091 { "src": "ipv4:192.0.2.2", "dst": "ipv4:192.0.2.89" }, 1092 { "src": "ipv4:192.0.2.2", "dst": "ipv4:198.51.100.34" }, 1093 { "src": "ipv4:203.0.113.45", "dst": "ipv4:198.51.100.34" } 1094 ] 1095 } 1097 HTTP/1.1 200 OK 1098 Content-Length: [TBD] 1099 Content-Type: application/alto-endpointcost+json 1100 { 1101 "meta": { 1102 "cost-type": {}, 1103 "multi-cost-types": [ 1104 { "cost-mode": "path-vector", "cost-metric": "ane"}, 1105 { "cost-mode": "numerical", "cost-metric": "delay"} 1106 ], 1107 "nep-map": { 1108 "uri": "http://alto.example.com/propmap/lookup/nep-map/31415926", 1109 "media-type": "application/alto-prompmap+json", 1110 "accepts": "application/alto-propmapparams+json", 1111 "capabilities": { 1112 "domain-types": ["ane"], 1113 "prop-types": ["availbw", "delay"] 1114 } 1115 } 1116 }, 1117 "endpoint-cost-map": { 1118 "ipv4:192.0.2.2": { 1119 "ipv4:192.0.2.89": [ ["ane:ane12", "ane:ane23"], 45 ], 1120 "ipv4:198.51.100.34": [ ["ane:ane12", "ane:ane24"], 90 ] 1121 }, 1122 "ipv4:203.0.113.45": { 1123 "ipv4:198.51.100.34": [ ["ane:ane34"], 120 ] 1124 } 1125 } 1126 } 1128 7. Compatibility 1130 7.1. Compatibility with Legacy ALTO Clients/Servers 1132 Legacy ALTO clients SHOULD NOT send queries with path vector 1133 extension and ALTO servers with this extension SHOULD NOT have any 1134 compatibility issue. Legacy ALTO servers do not support cost types 1135 with the "path-vector" cost mode and MUST NOT announce the extended 1136 cost types in IRD. Thus, ALTO clients MUST NOT send queries 1137 specified in this extension to legacy ALTO servers according to 1138 Section 11.3.2.3 [RFC7285]. 1140 7.2. Compatibility with Multi-Cost Extensions 1142 Path Vector extension SHOULD be fully compatible with Multi-Cost 1143 extensions. 1145 7.3. Compatibility with Incremental Update 1147 There is no compatibility issue with incremental update extension. 1149 8. Design Decisions and Discussions 1151 8.1. Path Vector or Path Graph? 1153 When we introduce the "path-vector" as a cost mode in the Cost Map, 1154 an unavoidable problem is how to handle multipath. Because a PID is 1155 a group of endpoints, it is common that there are multiple paths 1156 between two PIDs. The valid routing state information is all of the 1157 accessible paths. So in this scenario, the Cost Map Resource SHOULD 1158 provide the cost values including of the multiple paths. 1160 A natural solution is to provide an array of path vectors as the cost 1161 value. Every path vector in this array means an accessible path 1162 between the source PID and the destination PID. It is different from 1163 the solution of the path vector extension which provides an array of 1164 network elements. So it requires to introduce a different cost mode. 1165 This document proposes this new cost mode named "path-graph". 1167 However, the "path-graph" will increase the complexity of the Cost 1168 Map Response. Since the applications select ALTO as the protocol to 1169 get the network information rather than other topology-based solution 1170 such as I2RS, the major reason should be the simplicity. If we 1171 provide "path-graph" for each PID pairs, the ALTO client has to 1172 handle the complex data structure. 1174 What's more, the "path-vector" is powerful enough to express multiple 1175 paths. The simple solution is to list the network elements of all 1176 accessible paths in a single path vector. This solution will lose 1177 the information about paths. Another solution is to define the path 1178 as a new type of network elements. In this way, the path vector can 1179 provide an array of paths. Each element of this array contains a 1180 path vector of network elements in the Network Element Property Map. 1182 So in this document, we just introduce "path-vector" as the only 1183 required cost mode for routing state information. 1185 8.2. Provide More General Calendar Extension? 1187 Cost Calendar is proposed as a useful ALTO extension to provide the 1188 historical cost values for Filtered Cost Map Service and Endpoint 1189 Cost Service. Since path vector is an extension to these services, 1190 it SHOULD be compatible with Cost Calendar extension. 1192 However, the calendar of a path-vector (Endpoint) Cost Map is 1193 insufficient for the application which requires the historical data 1194 of routing state information. The (Endpoint) Cost Map can only 1195 provide the changes of the paths. But more useful information is the 1196 history of network element properties which are recorded in the 1197 dependent Network Element Property Map. 1199 Before the Unified Property Map is introduced as a new ALTO service, 1200 Filtered Cost Map Service and Endpoint Cost Service are the only 1201 resources which require the calendar supported. Because other 1202 resources don't have to be updated frequently. But Network Element 1203 Property Map as a use case of Unified Property Map will collect the 1204 real-time information of the network. It SHOULD be updated as soon 1205 as possible once the metrics of network elements change. 1207 So the requirement is to provide a general calendar extension which 1208 not only meets the Filtered Cost Map and Endpoint Cost Service but 1209 also applies to the Property Map Service. 1211 9. Security Considerations 1213 We can identify multiple potential security issues. A main security 1214 issue is network privacy, as the path-vector information may reveal 1215 more network internal structures than the more abstract single-node 1216 abstraction. The network should consider protection mechanisms to 1217 reduce information exposure, in particular, in settings where the 1218 network and the application do not belong to the same trust domain. 1219 On the other hand, in a setting of the same trust domain, a key 1220 benefit of the path-vector abstraction is reduced information 1221 transfer from the network to the application. 1223 The path-vector query may also reveal more information about the 1224 application. In particular, the application may reveal all potential 1225 transfers sites (e.g., where the data source is replicated, and where 1226 the potential replication sites are). The application should 1227 evaluate the potential privacy concerns. 1229 Beyond the privacy issues, the computation of the path-vector is 1230 unlikely to be cachable, in that the results will depend on the 1231 particular requests (e.g., where the flows are distributed). Hence, 1232 this service may become an entry point for denial of service attacks 1233 on the availability of an ALTO server. Hence, authenticity and 1234 authorization of this ALTO service may need to be better protected. 1236 10. IANA Considerations 1238 10.1. ALTO Cost Mode Registry 1240 This document specifies a new cost mode "path-vector". However, the 1241 base ALTO protocol does not have a Cost Mode Registry where new cost 1242 mode can be registered. This new cost mode will be registered once 1243 the registry is defined either in a revised version of [RFC7285] or 1244 in another future extension. 1246 10.2. ALTO Cost Metric Registry 1248 Two new cost metrics need to be registered in the "ALTO Cost Metric 1249 Registry", listed in Table 1. 1251 +-------------+---------------------+ 1252 | Identifier | Intended Semantics | 1253 +-------------+---------------------+ 1254 | ne | See Section 5.1.1 | 1255 | ane | See Section 5.1.1 | 1256 +-------------+---------------------+ 1258 Table 1: ALTO Cost Metrics 1260 10.3. ALTO Entity Domain Registry 1262 As proposed in Section 9.2 of [I-D.roome-alto-unified-props], "ALTO 1263 Entity Domain Registry" is requested. Besides, two new domains are 1264 to be registered, listed in Table 2. 1266 +-------------+--------------------------+--------------------------+ 1267 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1268 +-------------+--------------------------+--------------------------+ 1269 | ne | See Section 5.3.1.2 | None | 1270 | ane | See Section 5.3.2.2 | None | 1271 +-------------+--------------------------+--------------------------+ 1273 Table 2: ALTO Entity Domain 1275 11. Acknowledgments 1277 The authors would like to thank discussions with Andreas Voellmy, 1278 Erran Li, Haibin Son, Haizhou Du, Qiao Xiang, Tianyuan Liu, Xiao Shi, 1279 Xin Wang, and Yan Luo. 1281 12. References 1283 12.1. Normative References 1285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1286 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1287 RFC2119, March 1997, 1288 . 1290 12.2. Informative References 1292 [I-D.amante-i2rs-topology-use-cases] 1293 Medved, J., Previdi, S., Lopez, V., and S. Amante, 1294 "Topology API Use Cases", draft-amante-i2rs-topology-use- 1295 cases-01 (work in progress), October 2013. 1297 [I-D.bernstein-alto-topo] 1298 Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology 1299 Service: Uses Cases, Requirements, and Framework", draft- 1300 bernstein-alto-topo-00 (work in progress), October 2013. 1302 [I-D.clemm-i2rs-yang-network-topo] 1303 Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N., 1304 and H. Ananthakrishnan, "A YANG Data Model for Network 1305 Topologies", draft-clemm-i2rs-yang-network-topo-01 (work 1306 in progress), October 2014. 1308 [I-D.ietf-alto-cost-calendar] 1309 Randriamasy, S., Yang, Y., Wu, W., Lingli, D., and N. 1310 Schwan, "ALTO Cost Calendar", draft-ietf-alto-cost- 1311 calendar-01 (work in progress), February 2017. 1313 [I-D.ietf-alto-incr-update-sse] 1314 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 1315 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 1316 sse-03 (work in progress), September 2016. 1318 [I-D.ietf-alto-multi-cost] 1319 Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 1320 ALTO", draft-ietf-alto-multi-cost-05 (work in progress), 1321 February 2017. 1323 [I-D.lee-alto-app-net-info-exchange] 1324 Lee, Y., Bernstein, G., Choi, T., and D. Dhody, "ALTO 1325 Extensions to Support Application and Network Resource 1326 Information Exchange for High Bandwidth Applications", 1327 draft-lee-alto-app-net-info-exchange-02 (work in 1328 progress), July 2013. 1330 [I-D.roome-alto-unified-props] 1331 Roome, W., "Extensible Property Maps for the ALTO 1332 Protocol", draft-roome-alto-unified-props-01 (work in 1333 progress), July 2016. 1335 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1336 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1337 "Application-Layer Traffic Optimization (ALTO) Protocol", 1338 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1339 . 1341 Authors' Addresses 1343 Greg Bernstein 1344 Grotto Networking 1345 Fremont, CA 1346 USA 1348 Email: gregb@grotto-networking.com 1350 Shiwei Dawn Chen 1351 Tongji University 1352 4800 Caoan Road 1353 Shanghai 201804 1354 China 1356 Email: dawn_chen_f@hotmail.com 1358 Kai Gao 1359 Tsinghua University 1360 Beijing Beijing 1361 China 1363 Email: gaok12@mails.tsinghua.edu.cn 1364 Young Lee 1365 Huawei 1366 TX 1367 USA 1369 Email: leeyoung@huawei.com 1371 Wendy Roome 1372 Nokia/Bell Labs 1373 600 Mountain Ave, Rm 3B-324 1374 Murray Hill, NJ 07974 1375 USA 1377 Phone: +1-908-582-7974 1378 Email: wendy.roome@nokia.com 1380 Michael Scharf 1381 Nokia 1382 Germany 1384 Email: michael.scharf@nokia.com 1386 Y. Richard Yang 1387 Yale University 1388 51 Prospect St 1389 New Haven CT 1390 USA 1392 Email: yry@cs.yale.edu 1394 Jingxuan Jensen Zhang 1395 Tongji University 1396 4800 Caoan Road 1397 Shanghai 201804 1398 China 1400 Email: jingxuan.n.zhang@gmail.com