idnits 2.17.1 draft-xiang-alto-unified-representation-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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([DRAFT-PV], [RFC7285]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2019) is 1866 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 460, but not defined -- Looks like a reference, but probably isn't: '0' on line 496 -- Looks like a reference, but probably isn't: '1' on line 496 -- Looks like a reference, but probably isn't: '2' on line 496 == Unused Reference: 'DRAFT-NFCHAIN' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'DRAFT-RSA' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'RFC8189' is defined on line 558, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG Q. Xiang 3 Internet-Draft Yale University 4 Intended status: Standards Track F. Le 5 Expires: September 12, 2019 IBM 6 Y. Yang 7 Yale University 8 March 11, 2019 10 ALTO Extension: Unified Resource Representation 11 draft-xiang-alto-unified-representation-01.txt 13 Abstract 15 The ALTO protocol [RFC7285] provides network information to 16 applications so that applications can make network informed decisions 17 to improve the performance. However, the base ALTO protocol only 18 provides coarse-grained end-to-end metrics, which are insufficient to 19 satisfy the demands of applications to solve more complex network 20 optimization problems. The ALTO Path Vector extension [DRAFT-PV] has 21 been introduced to allow ALTO clients to query information such as 22 capacity regions for a given set of flows. However, the current 23 design of this extension has a limited expressiveness. The goal of 24 this document is to introduce a unified resource representation 25 service as an extension of ALTO (ALTO-UR), which allows the ALTO 26 clients to query and get the capacity regions of more complex 27 resource information, such as Shared-Risk-Link-Group (SRLG), multi- 28 path routing, multicast and on-demand routing, for a given set of 29 flows. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 12, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 67 3. Changes Since Version -00 . . . . . . . . . . . . . . . . . . 3 68 4. Limitations of the ALTO Path Vector Extension . . . . . . . . 3 69 5. Overview of the Unified Representation Extension . . . . . . 5 70 5.1. Basic idea . . . . . . . . . . . . . . . . . . . . . . . 5 71 5.2. New Cost Type to Encode Mathematical Programming 72 Variables . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5.2.1. Cost Mode: array . . . . . . . . . . . . . . . . . . 6 74 5.2.2. Cost Metric: variable-list . . . . . . . . . . . . . 6 75 5.3. New Entity Domain to Provide Mathematical Programming 76 Constraints . . . . . . . . . . . . . . . . . . . . . . . 7 77 5.4. Multipart Response to Provide the Unified Representation 7 78 5.5. Designing New Interfaces for More Flexible Queries . . . 7 79 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 6.1. Protocol Extension . . . . . . . . . . . . . . . . . . . 8 81 6.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 9 82 6.3. Information Resource Directory Example . . . . . . . . . 9 83 6.4. Cost Map Service Example . . . . . . . . . . . . . . . . 10 84 7. Security and Privacy Considerations . . . . . . . . . . . . . 12 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 8.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 As discussed in [DRAFT-PV], the "one-big-switch" abstraction used in 93 the ALTO base protocol lacks the ability to support emerging use 94 cases, such as inter-datacenter data transfers, because this 95 abstraction cannot reveal the resource sharing, i.e., the capacity 96 region, for a set of flows. The ALTO Path Vector extension addresses 97 this insufficiency by using the path vector abstraction to express 98 the capacity region in a set of linear inequalities. However, in an 99 internal discussion with the leading persons of several important 100 ALTO use cases, it is revealed that the expressiveness of the ALTO 101 Path Vector extension is limited in three aspects: 103 o It cannot provide compact encoding of the SRLG for a set of flows; 105 o It assumes that each flow in the client's query will use a single- 106 path route, and hence cannot encode the resource sharing for flows 107 that are forwarded along multi-path routes or multicast flows; 109 o It assumes that the route of each flow in the client's query is 110 pre-computed, and hence cannot encode the resource sharing for 111 flows that use on-demand routing, e.g., the path computation 112 element (PCE) protocol. 114 To cope with these issues, this document introduces a new ALTO 115 extension, the unified representation (ALTO-UR). This extension 116 expands the linear inequality encoding of capacity regions used in 117 ALTO-PV, to a generic, complete encoding, which uses mathematical 118 programming constraints to represent the capacity regions for a set 119 of flows. 121 2. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Changes Since Version -00 129 o Add an initial proposal to design a more flexible resource 130 information query interface in Section 5.5. 132 4. Limitations of the ALTO Path Vector Extension 134 The limitations of the ALTO-PV extension are illustrated with the 135 same dumbbell topology used in [DRAFT-PV]. Assume that the bandwidth 136 of every link is 100 Mbps, and that the SRLG of each link is shown in 137 Figure 1. Consider an application overlay (e.g., a large data 138 analytics system) which wants to schedule the traffic among a set of 139 end host source-destination pairs, say eh1 -> eh2 and eh1 -> eh4. 141 +------+ 142 | | 143 {1, 3} --+ sw6 +-- {1, 2} 144 / | | \ 145 PID1 +-----+ / +------+ \ {1, 4} +-----+ PID2 146 eh1__| |_ {1} / \ ____| |__eh2 147 | sw1 | \ +--+---+ +---+--+ / | sw2 | 148 +-----+ \ | | {2, 4} | |/ +-----+ 149 \_| sw5 +---------+ sw7 | 150 PID3 +-----+ / | | | |\ +-----+ PID4 151 eh3__| |__/ +------+ +------+ \____| |__eh4 152 | sw3 | {2, 3} {2, 4} | sw4 | 153 +-----+ +-----+ 155 Figure 1: A Dumbbell Network Topology 157 o Assume the application is only interested in the SRLG of both 158 flows, not the bandwidth. The route of eh1 -> eh2 is eh1 -> sw1 159 -> sw5 -> sw6 -> sw7 -> sw2 -> eh2, and the route of eh3 -> eh4 is 160 eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4. The minimal yet accurate 161 information returned to the application should be {2, 3, 4}, the 162 SRLG of both flows, since flow 1 has a set of SRLG {1, 2, 3, 4} 163 and flow 2 has a set of SRLG {2, 3, 4}. In contrast, in the 164 current ALTO-PV service, the ALTO server needs to return the ane- 165 path of each flow and the SRLG of every ane, where ane and ane- 166 path are defined in [DRAFT-PV]. This response is redundant and 167 causes unnecessary information exposure to the application, e.g., 168 the information of flow has an SRLG 1 should not be returned to 169 the application. 171 o Assume the application is only interested in the bandwidth of both 172 flows. The route of eh1 -> eh2 is eh1 -> sw1 -> sw5 -> sw6 -> sw7 173 -> sw2 -> eh2, and the route of eh3 -> eh4 is a multi-path route, 174 i.e., {eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4, eh3 -> sw1 -> sw5 175 -> sw6 -> sw7 -> sw2 -> eh4}, where each path would forward 50 176 percent of the traffic for eh3 -> eh4. The ALTO-PV service cannot 177 reveal the traffic split of the multi-path route for eh3 -> eh4, 178 or the bandwidth sharing for both flows on link sw5 -> sw6. 180 o Assume the network has a PCE sever, through which the application 181 can reserve bandwidth for both flows. Before the application 182 makes the reservation request, the application queries the ALTO 183 server to get the bandwidth capacity region of both flows, which 184 it wants to use to decide how much bandwidth to reserve for each 185 flow. Suppose when the ALTO server receives a query, the network 186 only has two precomputed routes for both flows: eh1 -> sw1 -> sw5 187 -> sw6 -> sw7 -> sw2 -> eh2, and eh3 -> sw1 -> sw5 -> sw6 -> sw7 188 -> sw2 -> eh4. Through the ALTO-PV service, the application 189 receives the information that the total bandwidth it can reserve 190 for both flows cannot exceed 100 Mbps. However, one important 191 feature of the PCE server is that it can compute the route for 192 reservation request on-demand, and hence it can find routes with a 193 larger bandwidth. In this example, if the application submits a 194 request to reserve 100 Mbps bandwidth for each flow, the PCE 195 server can compute two on-demand routes, i.e., eh1 -> sw1 -> sw5 196 -> sw6 -> sw7 -> sw2 -> eh2 and eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> 197 eh4, and still return a success signal to the application. This 198 shows that the ALTO-PV service cannot encode the capacity region 199 for flows who use on-demand routing. 201 5. Overview of the Unified Representation Extension 203 Although different patches and extensions can be introduced to 204 address the aforementioned insufficiencies of the ALTO-PV service, it 205 is desirable to design a service that provides a generic solution 206 that can encode different types of resource sharing for a set of 207 flows. To this end, this document introduces the ALTO Unified 208 Representation (ALTO-UR) service. 210 5.1. Basic idea 212 The basic idea of the ALTO-UR service is to use mathematical 213 programming constraints to represent the capacity region for a set of 214 flows. Different from linear inequalities used in the ALTO-PV 215 service, mathematical programming constraints can represent a much 216 wider range of resource information. To illustrate the 217 expressiveness of mathematical programming constraints, we revisit 218 the examples in Figure 1. 220 Assume the route of eh1 -> eh2 is eh1 -> sw1 -> sw5 -> sw6 -> sw7 -> 221 sw2 -> eh2, and the route of eh3 -> eh4 is eh3 -> sw1 -> sw5 -> sw7 222 -> sw2 -> eh4. Denote the SRLG of flow eh1 -> eh2 as f1:SRLG, and 223 that of flow eh3->eh4 as f2:SRLG. Then the SRLG of both flows can be 224 represented as 226 f1:SRLG intersect f2:SRLG = {2, 3, 4} 228 Assume the route of eh1 -> eh2 is eh1 -> sw1 -> sw5 -> sw6 -> sw7 -> 229 sw2 -> eh2, and the route of eh3 -> eh4 is a multi-path route, i.e., 230 {eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4, eh3 -> sw1 -> sw5 -> sw6 -> 231 sw7 -> sw2 -> eh4}, where each path would forward 50 percent of the 232 traffic for eh3 -> eh4. Denote the available bandwidth of eh1 -> eh2 233 as f1-bw and those of eh3 -> eh4 along two paths as f2-bw-p1 and f2- 234 bw-p2. The bandwidth sharing of two flows can be represented as: 236 f1:bw <= 100 Mbps, for (sw1, sw5), (sw7, sw2) 237 f2:bw:p1 + f2:bw:p2 <= 100 Mbps, for (sw3, sw5), (sw7, sw4) 238 f1:bw + f2:bw:p1 <= 100 Mbps, for (sw5, sw6), (sw6, sw7) 239 f2:bw:p2 <= 100 Mbps, for (sw5, sw7) 240 f2:bw:p1 = f2:bw:p2 242 Assume the routes for both flows are computed on demand and each flow 243 can only use a single path. For eh1 -> eh2, use f1-bw-p1 and 244 f1-bw-p2 to represent the available bandwidth of routes eh1 -> sw1 -> 245 sw5 -> sw6 -> sw7 -> sw2 -> eh2 and eh1 -> sw1 -> sw5 -> sw7 -> sw2 246 -> eh2, respectively. For eh3 -> eh4, use f2-bw-p1 and f2-bw-p2 to 247 represent the available bandwidth of routes eh3 -> sw1 -> sw5 -> sw6 248 -> sw7 -> sw2 -> eh4 and eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4, 249 respectively. The bandwidth capacity region of both flows can be 250 represented as: 252 f1:bw:p1 + f1:bw:p2 <= 100 Mbps, for (sw1, sw5), (sw7, sw2) 253 f2:bw:p1 + f2:bw:p2 <= 100 Mbps, for (sw3, sw5), (sw7, sw4) 254 f1:bw:p1 + f2:bw:p1 <= 100 Mbps, for (sw5, sw6), (sw6, sw7) 255 f1:bw:p2 + f2:bw:p2 <= 100 Mbps, for (sw5, sw7) 256 f1:bw:p1 = 0 or f1:bw:p2 = 0 257 f2:bw:p1 = 0 or f2:bw:p2 = 0 259 The next few subsections present the approaches adopted by the ALTO 260 unified representation extension. 262 5.2. New Cost Type to Encode Mathematical Programming Variables 264 This document introduces the unified representation cost type, with 265 the following cost mode and cost metric. 267 5.2.1. Cost Mode: array 269 The cost mode of the notation cost type is "array", which is defined 270 in [DRAFT-PV]. The values are arrays of JSONValue. The specific 271 type of each element in the array depends on the cost metric. 273 5.2.2. Cost Metric: variable-list 275 This document specifies a new cost metric called "variable-list". 276 This cost metric indicates that the cost value is a list of variables 277 that will be used in mathematical programming constraints. 279 5.3. New Entity Domain to Provide Mathematical Programming Constraints 281 This document adopts the property map defined in [DRAFT-UP] to encode 282 the properties of abstract network elements. A new domain "cstr" 283 (short for constraint) is registered in the property map. Each 284 entity in the "cstr" domain has an identifier of an CSTR. Each CSTR 285 has one property, which represents the semantics of this constraint, 286 e.g., a "bw-cstr" property indicates that this constraint represents 287 the bandwidth sharing among flows. This property is provided in 288 information resources called "Property Map Resource" and "Filtered 289 Property Map Resource". The "Filtered Property Map" resource which 290 supports the "cstr" domain is used to encode the properties of cstr 291 entities, and it is called a cstr Property Map in this document. 293 5.4. Multipart Response to Provide the Unified Representation 295 To ensure the consistency between the unified representation cost map 296 and the corresponding CSTR property map, this document adopts the 297 design of [DRAFT-PV] to allow a response to contain both the unified 298 representation in a filtered cost map and the associated CSTR 299 property map. 301 5.5. Designing New Interfaces for More Flexible Queries 303 Current ALTO protocol and its extensions allow applications to query 304 resource information by specifying IP addresses of endpoints and 305 simple filters. However, with the emerging of new networking 306 architecture (e.g., software defined networking and network function 307 virtualization) and the fine-grained resource requirement of 308 applications (e.g., link-disjoint paths and endpoint precedence), 309 applications need a more flexible interface to specify queries of 310 resource information. 312 [DRAFT-FCS] proposes a flexible flow query extension service to allow 313 applications to specify query entities based on flexible matching 314 conditions (e.g., TCP/IP 5-tuple) instead of IP addresses only. 315 However, it still does not allow an application to specify more fine- 316 grained resource requirements. For example, a multi-domain service 317 function chaining application may want to get the endpoint cost 318 information of a chain of endpoints in the order of firewall, load 319 balancer and data analyzer. The endpoint cost information of a chain 320 of endpoints not in this order is of no interest to the application 321 and should not be returned to the application. 323 As such, this document makes an initial proposal to design new 324 interfaces for application to express fine-grained requirements of 325 resource in the query. In addition to allowing the ALTO client to 326 specify endpoints using flexible matching conditions (e.g., TCP/IP 5 327 tuple), one key idea in this proposal is to use a resource filter 328 design 330 Specifically, two types of resource properties are defined. The 331 first type is value property, which are typical quality of services 332 metrics for a given flow. Examples of the value property include the 333 bandwidth, delay, loss rate and so on. The second type is set 334 property. Examples of such a property include the forwarding and 335 processing devices used by a flow (denoted as nodes), the physical 336 links used by a flow (denoted as links) and the shared risk link 337 group (SRLG) of all the devices and links used by a flow. 339 With these two types of resource properties, the atomic resource 340 requirement predicates in resource filters are the comparison 341 expressions on value properties and set properties. Resource 342 requirement predicates can be composited using conjunction, 343 disjunction and negation. The ALTO client can send resource query 344 with composed resource requirement predicates to ALTO server, which 345 only returns the information of resources that satisfy such 346 predicates to ALTO client. 348 The details of this new interface will be fully specified in the next 349 version of this document. 351 6. Example 353 6.1. Protocol Extension 355 To allow the ALTO client to query and receive the mathematical 356 programming constraints for a set of flows, the Filtered Cost Map and 357 Endpoint Cost Service of the ALTO protocol need to be extended. The 358 current design adopted in this document uses a similar approach as 359 the ALTO-PV extension does in [DRAFT-PV]: (1) extending the 360 FilteredCostMapCapabilities object with a new member "property-map" 361 and (2) using a multipart service to send both the unified 362 representation cost map and the CSTR property map together. This 363 design is illustrated in the next few subsections. 365 However, for the ALTO-UR service, this is still an early stage 366 design. As a major next step for ALTO-UR service, other design 367 options are being investigated with the aim of enabling better 368 modularity and extensibility, and the protocol extension will be 369 updated in the next version accordingly. 371 6.2. Workflow 373 A typical workflow of an ALTO client using the unified representation 374 extension is as follows: 376 1. Send a GET request for the whole Information Resource Directory. 378 2. Look for the resource of the Cost Map Service which contains the 379 unified representation cost type and get the resource ID of the 380 dependent cstr property map. 382 3. Check whether the capabilities of the property map includes the 383 desired "prop-types". 385 4. Send a unified-representation request which accepts "multipart/ 386 related" media type following "application/alto-costmap+json" or 387 "application/endpointcost+json" 389 6.3. Information Resource Directory Example 391 An example of an Information Resource Directory is as follows. In 392 this example, filtered cost map "cost-map-ur" supports the unified- 393 representation extension. The property map "propmap-cstr" support 394 two properties, "bw-cstr" and "srlg-cstr", representing bandwidth 395 constraint and SRLG constraint, respectively. 397 { 398 "meta": { 399 "cost-types": { 400 "ur": { 401 "cost-mode": "array", 402 "cost-metric": "variable-list" 403 } 404 } 405 "resources": { 406 "my-default-networkmap": { 407 "uri" : "http://alto.example.com/networkmap", 408 "media-type" : "application/alto-networkmap+json" 409 } 410 "cost-map-ur" : { 411 "uri": "http://alto.example.com/costmap/ur", 412 "media-type": "application/alto-costmap+json", 413 "accepts": "application/alto-costmapfilter+json", 414 "capabilities": { 415 "cost-type-names": [ "ur"] 416 }, 417 "property-map": "propmap-cstr", 418 "uses": [ "my-default-networkmap" ] 419 }, 420 "propmap-cstr" : { 421 "uri": "http://alto.exmaple.com/propmap/cstr", 422 "media-type": "application/alto-propmap+json", 423 "accepts": "application/alto-propmapparams+json", 424 "capabilities": { 425 "domain-types": [ "cstr" ], 426 "prop-types": [ "bw-cstr", "srlg-cstr" ] 427 } 428 } 429 } 430 } 432 6.4. Cost Map Service Example 434 The following is an example of the cost map service in the ALTO-UR 435 extension. In the returned cost map, flow 1 has two bandwidth 436 variables, f1:bw:p1 and f2:bw:p2, and one SRLG variable, f1:srlg. 437 And flow 2 has one bandwidth variable, f2:bw, and one SRLG variable, 438 f2:srlg. Four mathematical programming constraints are returned in 439 the property map. The first three are bandwidth sharing constraints, 440 and the fourth is an SRLG constraint. 442 POST /costmap/pv HTTP/1.1 443 Host: alto.example.com 444 Accept: multipart/related, application/alto-costmap+json, 445 application/alto-propmap+json, application/alto-error+json 446 Content-Length: [TBD] 447 Content-Type: application/alto-costmapfilter+json 448 { 449 "cost-type": { 450 "cost-mode": "array", 451 "cost-metric": "variable-list" 452 }, 453 "pids": { 454 "srcs": [ "PID1" ], 455 "dsts": [ "PID2", "PID3" ] 456 } 457 } 459 HTTP/1.1 200 OK 460 Content-Length: [TBD] 461 Content-Type: multipart/related; boundary=42 463 --42 464 Content-Type: application/alto-costmap+json 466 { 467 "meta": { 468 "dependent-vtags": [ 469 { 470 "resource-id": "default-network-map", 471 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 472 } 473 ], 474 "cost-type": { 475 "cost-mode": "array", 476 "cost-metric": "variable-list" 477 }, 478 }, 480 "cost-map": { 481 "PID1": { 482 "PID2": [ "f1:bw:p1", "bw:p2", "f1:srlg"] 483 "PID3": [ "f2:bw:p1", "f2:srlg" ] 484 } 485 } 486 } 488 --42 489 Content-Type: application/alto-propmap+json 491 { 492 "property-map": { 493 "cstr:001": { "bw-cstr": "[0][0] add [0][1] leq 100"}, 494 "cstr:002": { "bw-cstr": "[0][0] eq [0][1]"}, 495 "cstr:003": { "bw-cstr": "[1][0] add [0][0] leq 100"}, 496 "cstr:004": { "srlg-cstr": "[0][2] intersect [1][1] eq {2, 3, 4}"}, 497 } 498 } 500 7. Security and Privacy Considerations 502 The unified representation extension may expose more private 503 information to applications than the ALTO base protocol does. 504 However, as shown in the motivating example of providing SRLG 505 information for a set of flows, this extension has the capability of 506 exposing less private information than the ALTO-PV extension does, 507 while having a better expressiveness on providing fine-grained 508 resource information to applications. A systematic study on the 509 security and privacy issues of the ALTO-UR extension is one of the 510 major next steps. 512 8. References 514 8.1. Normative References 516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", BCP 14, RFC 2119, 518 DOI 10.17487/RFC2119, March 1997, . 521 8.2. Informative References 523 [DRAFT-FCS] 524 Zhang, J., Gao, K., Wang, J., Xiang, Q., and Y. Yang, 525 "ALTO Extension: Flow-based Cost Query", 2017, 526 . 528 [DRAFT-NFCHAIN] 529 Perez, D. and C. Rothenberg, "ALTO-based Broker-assisted 530 Multi-domain Orchestration", 2018, 531 . 534 [DRAFT-PV] 535 Bernstein, G., Lee, Y., Roome, W., Scharf, M., and Y. 536 Yang, "ALTO Extension: Abstract Path Vector as a Cost 537 Mode", 2015, . 540 [DRAFT-RSA] 541 Gao, K., Wang, X., Xiang, Q., Gu, C., Yang, Y., and G. 542 Chen, "A Recommendation for Compressing ALTO Path 543 Vectors", 2017, . 546 [DRAFT-UP] 547 Roome, W., Chen, S., Randriamasy, S., Yang, Y., and J. 548 Zhang, "Unified Properties for the ALTO Protocol", 2015, 549 . 552 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 553 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 554 "Application-Layer Traffic Optimization (ALTO) Protocol", 555 RFC 7285, DOI 10.17487/RFC7285, September 2014, 556 . 558 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 559 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 560 DOI 10.17487/RFC8189, October 2017, . 563 Authors' Addresses 565 Qiao Xiang 566 Yale University 567 51 Prospect Street 568 New Haven, CT 569 USA 571 Email: qiao.xiang@cs.yale.edu 573 Franck Le 574 IBM 575 Thomas J. Watson Research Center 576 Yorktown Heights, NY 577 USA 579 Email: fle@us.ibm.com 580 Y. Richard Yang 581 Yale University 582 51 Prospect Street 583 New Haven, CT 584 USA 586 Email: yry@cs.yale.edu