idnits 2.17.1 draft-xiang-alto-unified-representation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The 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 09, 2020) is 1481 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 463, but not defined -- Looks like a reference, but probably isn't: '0' on line 499 -- Looks like a reference, but probably isn't: '1' on line 499 -- Looks like a reference, but probably isn't: '2' on line 499 == Unused Reference: 'DRAFT-NFCHAIN' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'DRAFT-RSA' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC8189' is defined on line 593, 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 J. Zhang 5 Expires: September 10, 2020 Tongji/Yale University 6 F. Le 7 IBM 8 Y. Yang 9 Yale University 10 March 09, 2020 12 ALTO Extension: Unified Resource Representation 13 draft-xiang-alto-unified-representation-02.txt 15 Abstract 17 The ALTO protocol [RFC7285] provides network information to 18 applications so that applications can make network informed decisions 19 to improve the performance. However, the base ALTO protocol only 20 provides coarse-grained end-to-end metrics, which are insufficient to 21 satisfy the demands of applications to solve more complex network 22 optimization problems. The ALTO Path Vector extension [DRAFT-PV] has 23 been introduced to allow ALTO clients to query information such as 24 capacity regions for a given set of flows. However, the current 25 design of this extension has a limited expressiveness. The goal of 26 this document is to introduce a unified resource representation 27 service as an extension of ALTO (ALTO-UR), which allows the ALTO 28 clients to query and get the capacity regions of more complex 29 resource information, such as Shared-Risk-Link-Group (SRLG), multi- 30 path routing, multicast and on-demand routing, for a given set of 31 flows. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 10, 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 69 3. Changes Since Version -01 . . . . . . . . . . . . . . . . . . 3 70 4. Limitations of the ALTO Path Vector Extension . . . . . . . . 3 71 5. Overview of the Unified Representation Extension . . . . . . 5 72 5.1. Basic idea . . . . . . . . . . . . . . . . . . . . . . . 5 73 5.2. New Cost Type to Encode Mathematical Programming 74 Variables . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5.2.1. Cost Mode: array . . . . . . . . . . . . . . . . . . 6 76 5.2.2. Cost Metric: variable-list . . . . . . . . . . . . . 6 77 5.3. New Entity Domain to Provide Mathematical Programming 78 Constraints . . . . . . . . . . . . . . . . . . . . . . . 7 79 5.4. Multipart Response to Provide the Unified Representation 7 80 5.5. Designing New Interfaces for More Flexible Queries . . . 7 81 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 6.1. Protocol Extension . . . . . . . . . . . . . . . . . . . 8 83 6.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 9 84 6.3. Information Resource Directory Example . . . . . . . . . 9 85 6.4. Cost Map Service Example . . . . . . . . . . . . . . . . 10 86 7. Use Case: Programmable End-to-End Multi-Domain Route Control 12 87 8. Security and Privacy Considerations . . . . . . . . . . . . . 12 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 9.2. Informative References . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 As discussed in [DRAFT-PV], the "one-big-switch" abstraction used in 96 the ALTO base protocol lacks the ability to support emerging use 97 cases, such as inter-datacenter data transfers, because this 98 abstraction cannot reveal the resource sharing, i.e., the capacity 99 region, for a set of flows. The ALTO Path Vector extension addresses 100 this insufficiency by using the path vector abstraction to express 101 the capacity region in a set of linear inequalities. However, in an 102 internal discussion with the leading persons of several important 103 ALTO use cases, it is revealed that the expressiveness of the ALTO 104 Path Vector extension is limited in three aspects: 106 o It cannot provide compact encoding of the SRLG for a set of flows; 108 o It assumes that each flow in the client's query will use a single- 109 path route, and hence cannot encode the resource sharing for flows 110 that are forwarded along multi-path routes or multicast flows; 112 o It assumes that the route of each flow in the client's query is 113 pre-computed, and hence cannot encode the resource sharing for 114 flows that use on-demand routing, e.g., the path computation 115 element (PCE) protocol. 117 To cope with these issues, this document introduces a new ALTO 118 extension, the unified representation (ALTO-UR). This extension 119 expands the linear inequality encoding of capacity regions used in 120 ALTO-PV, to a generic, complete encoding, which uses mathematical 121 programming constraints to represent the capacity regions for a set 122 of flows. 124 2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. Changes Since Version -01 132 o Add an important multi-domain use case that can benefit from the 133 unified resource representation in Section 6. 135 4. Limitations of the ALTO Path Vector Extension 137 The limitations of the ALTO-PV extension are illustrated with the 138 same dumbbell topology used in [DRAFT-PV]. Assume that the bandwidth 139 of every link is 100 Mbps, and that the SRLG of each link is shown in 140 Figure 1. Consider an application overlay (e.g., a large data 141 analytics system) which wants to schedule the traffic among a set of 142 end host source-destination pairs, say eh1 -> eh2 and eh1 -> eh4. 144 +------+ 145 | | 146 {1, 3} --+ sw6 +-- {1, 2} 147 / | | \ 148 PID1 +-----+ / +------+ \ {1, 4} +-----+ PID2 149 eh1__| |_ {1} / \ ____| |__eh2 150 | sw1 | \ +--+---+ +---+--+ / | sw2 | 151 +-----+ \ | | {2, 4} | |/ +-----+ 152 \_| sw5 +---------+ sw7 | 153 PID3 +-----+ / | | | |\ +-----+ PID4 154 eh3__| |__/ +------+ +------+ \____| |__eh4 155 | sw3 | {2, 3} {2, 4} | sw4 | 156 +-----+ +-----+ 158 Figure 1: A Dumbbell Network Topology 160 o Assume the application is only interested in the SRLG of both 161 flows, not the bandwidth. The route of eh1 -> eh2 is eh1 -> sw1 162 -> sw5 -> sw6 -> sw7 -> sw2 -> eh2, and the route of eh3 -> eh4 is 163 eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4. The minimal yet accurate 164 information returned to the application should be {2, 3, 4}, the 165 SRLG of both flows, since flow 1 has a set of SRLG {1, 2, 3, 4} 166 and flow 2 has a set of SRLG {2, 3, 4}. In contrast, in the 167 current ALTO-PV service, the ALTO server needs to return the ane- 168 path of each flow and the SRLG of every ane, where ane and ane- 169 path are defined in [DRAFT-PV]. This response is redundant and 170 causes unnecessary information exposure to the application, e.g., 171 the information of flow has an SRLG 1 should not be returned to 172 the application. 174 o Assume the application is only interested in the bandwidth of both 175 flows. The route of eh1 -> eh2 is eh1 -> sw1 -> sw5 -> sw6 -> sw7 176 -> sw2 -> eh2, and the route of eh3 -> eh4 is a multi-path route, 177 i.e., {eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4, eh3 -> sw1 -> sw5 178 -> sw6 -> sw7 -> sw2 -> eh4}, where each path would forward 50 179 percent of the traffic for eh3 -> eh4. The ALTO-PV service cannot 180 reveal the traffic split of the multi-path route for eh3 -> eh4, 181 or the bandwidth sharing for both flows on link sw5 -> sw6. 183 o Assume the network has a PCE sever, through which the application 184 can reserve bandwidth for both flows. Before the application 185 makes the reservation request, the application queries the ALTO 186 server to get the bandwidth capacity region of both flows, which 187 it wants to use to decide how much bandwidth to reserve for each 188 flow. Suppose when the ALTO server receives a query, the network 189 only has two precomputed routes for both flows: eh1 -> sw1 -> sw5 190 -> sw6 -> sw7 -> sw2 -> eh2, and eh3 -> sw1 -> sw5 -> sw6 -> sw7 191 -> sw2 -> eh4. Through the ALTO-PV service, the application 192 receives the information that the total bandwidth it can reserve 193 for both flows cannot exceed 100 Mbps. However, one important 194 feature of the PCE server is that it can compute the route for 195 reservation request on-demand, and hence it can find routes with a 196 larger bandwidth. In this example, if the application submits a 197 request to reserve 100 Mbps bandwidth for each flow, the PCE 198 server can compute two on-demand routes, i.e., eh1 -> sw1 -> sw5 199 -> sw6 -> sw7 -> sw2 -> eh2 and eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> 200 eh4, and still return a success signal to the application. This 201 shows that the ALTO-PV service cannot encode the capacity region 202 for flows who use on-demand routing. 204 5. Overview of the Unified Representation Extension 206 Although different patches and extensions can be introduced to 207 address the aforementioned insufficiencies of the ALTO-PV service, it 208 is desirable to design a service that provides a generic solution 209 that can encode different types of resource sharing for a set of 210 flows. To this end, this document introduces the ALTO Unified 211 Representation (ALTO-UR) service. 213 5.1. Basic idea 215 The basic idea of the ALTO-UR service is to use mathematical 216 programming constraints to represent the capacity region for a set of 217 flows. Different from linear inequalities used in the ALTO-PV 218 service, mathematical programming constraints can represent a much 219 wider range of resource information. To illustrate the 220 expressiveness of mathematical programming constraints, we revisit 221 the examples in Figure 1. 223 Assume the route of eh1 -> eh2 is eh1 -> sw1 -> sw5 -> sw6 -> sw7 -> 224 sw2 -> eh2, and the route of eh3 -> eh4 is eh3 -> sw1 -> sw5 -> sw7 225 -> sw2 -> eh4. Denote the SRLG of flow eh1 -> eh2 as f1:SRLG, and 226 that of flow eh3->eh4 as f2:SRLG. Then the SRLG of both flows can be 227 represented as 229 f1:SRLG intersect f2:SRLG = {2, 3, 4} 231 Assume the route of eh1 -> eh2 is eh1 -> sw1 -> sw5 -> sw6 -> sw7 -> 232 sw2 -> eh2, and the route of eh3 -> eh4 is a multi-path route, i.e., 233 {eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4, eh3 -> sw1 -> sw5 -> sw6 -> 234 sw7 -> sw2 -> eh4}, where each path would forward 50 percent of the 235 traffic for eh3 -> eh4. Denote the available bandwidth of eh1 -> eh2 236 as f1-bw and those of eh3 -> eh4 along two paths as f2-bw-p1 and f2- 237 bw-p2. The bandwidth sharing of two flows can be represented as: 239 f1:bw <= 100 Mbps, for (sw1, sw5), (sw7, sw2) 240 f2:bw:p1 + f2:bw:p2 <= 100 Mbps, for (sw3, sw5), (sw7, sw4) 241 f1:bw + f2:bw:p1 <= 100 Mbps, for (sw5, sw6), (sw6, sw7) 242 f2:bw:p2 <= 100 Mbps, for (sw5, sw7) 243 f2:bw:p1 = f2:bw:p2 245 Assume the routes for both flows are computed on demand and each flow 246 can only use a single path. For eh1 -> eh2, use f1-bw-p1 and 247 f1-bw-p2 to represent the available bandwidth of routes eh1 -> sw1 -> 248 sw5 -> sw6 -> sw7 -> sw2 -> eh2 and eh1 -> sw1 -> sw5 -> sw7 -> sw2 249 -> eh2, respectively. For eh3 -> eh4, use f2-bw-p1 and f2-bw-p2 to 250 represent the available bandwidth of routes eh3 -> sw1 -> sw5 -> sw6 251 -> sw7 -> sw2 -> eh4 and eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4, 252 respectively. The bandwidth capacity region of both flows can be 253 represented as: 255 f1:bw:p1 + f1:bw:p2 <= 100 Mbps, for (sw1, sw5), (sw7, sw2) 256 f2:bw:p1 + f2:bw:p2 <= 100 Mbps, for (sw3, sw5), (sw7, sw4) 257 f1:bw:p1 + f2:bw:p1 <= 100 Mbps, for (sw5, sw6), (sw6, sw7) 258 f1:bw:p2 + f2:bw:p2 <= 100 Mbps, for (sw5, sw7) 259 f1:bw:p1 = 0 or f1:bw:p2 = 0 260 f2:bw:p1 = 0 or f2:bw:p2 = 0 262 The next few subsections present the approaches adopted by the ALTO 263 unified representation extension. 265 5.2. New Cost Type to Encode Mathematical Programming Variables 267 This document introduces the unified representation cost type, with 268 the following cost mode and cost metric. 270 5.2.1. Cost Mode: array 272 The cost mode of the notation cost type is "array", which is defined 273 in [DRAFT-PV]. The values are arrays of JSONValue. The specific 274 type of each element in the array depends on the cost metric. 276 5.2.2. Cost Metric: variable-list 278 This document specifies a new cost metric called "variable-list". 279 This cost metric indicates that the cost value is a list of variables 280 that will be used in mathematical programming constraints. 282 5.3. New Entity Domain to Provide Mathematical Programming Constraints 284 This document adopts the property map defined in [DRAFT-UP] to encode 285 the properties of abstract network elements. A new domain "cstr" 286 (short for constraint) is registered in the property map. Each 287 entity in the "cstr" domain has an identifier of an CSTR. Each CSTR 288 has one property, which represents the semantics of this constraint, 289 e.g., a "bw-cstr" property indicates that this constraint represents 290 the bandwidth sharing among flows. This property is provided in 291 information resources called "Property Map Resource" and "Filtered 292 Property Map Resource". The "Filtered Property Map" resource which 293 supports the "cstr" domain is used to encode the properties of cstr 294 entities, and it is called a cstr Property Map in this document. 296 5.4. Multipart Response to Provide the Unified Representation 298 To ensure the consistency between the unified representation cost map 299 and the corresponding CSTR property map, this document adopts the 300 design of [DRAFT-PV] to allow a response to contain both the unified 301 representation in a filtered cost map and the associated CSTR 302 property map. 304 5.5. Designing New Interfaces for More Flexible Queries 306 Current ALTO protocol and its extensions allow applications to query 307 resource information by specifying IP addresses of endpoints and 308 simple filters. However, with the emerging of new networking 309 architecture (e.g., software defined networking and network function 310 virtualization) and the fine-grained resource requirement of 311 applications (e.g., link-disjoint paths and endpoint precedence), 312 applications need a more flexible interface to specify queries of 313 resource information. 315 [DRAFT-FCS] proposes a flexible flow query extension service to allow 316 applications to specify query entities based on flexible matching 317 conditions (e.g., TCP/IP 5-tuple) instead of IP addresses only. 318 However, it still does not allow an application to specify more fine- 319 grained resource requirements. For example, a multi-domain service 320 function chaining application may want to get the endpoint cost 321 information of a chain of endpoints in the order of firewall, load 322 balancer and data analyzer. The endpoint cost information of a chain 323 of endpoints not in this order is of no interest to the application 324 and should not be returned to the application. 326 As such, this document makes an initial proposal to design new 327 interfaces for application to express fine-grained requirements of 328 resource in the query. In addition to allowing the ALTO client to 329 specify endpoints using flexible matching conditions (e.g., TCP/IP 5 330 tuple), one key idea in this proposal is to use a resource filter 331 design 333 Specifically, two types of resource properties are defined. The 334 first type is value property, which are typical quality of services 335 metrics for a given flow. Examples of the value property include the 336 bandwidth, delay, loss rate and so on. The second type is set 337 property. Examples of such a property include the forwarding and 338 processing devices used by a flow (denoted as nodes), the physical 339 links used by a flow (denoted as links) and the shared risk link 340 group (SRLG) of all the devices and links used by a flow. 342 With these two types of resource properties, the atomic resource 343 requirement predicates in resource filters are the comparison 344 expressions on value properties and set properties. Resource 345 requirement predicates can be composited using conjunction, 346 disjunction and negation. The ALTO client can send resource query 347 with composed resource requirement predicates to ALTO server, which 348 only returns the information of resources that satisfy such 349 predicates to ALTO client. 351 The details of this new interface will be fully specified in the next 352 version of this document. 354 6. Example 356 6.1. Protocol Extension 358 To allow the ALTO client to query and receive the mathematical 359 programming constraints for a set of flows, the Filtered Cost Map and 360 Endpoint Cost Service of the ALTO protocol need to be extended. The 361 current design adopted in this document uses a similar approach as 362 the ALTO-PV extension does in [DRAFT-PV]: (1) extending the 363 FilteredCostMapCapabilities object with a new member "property-map" 364 and (2) using a multipart service to send both the unified 365 representation cost map and the CSTR property map together. This 366 design is illustrated in the next few subsections. 368 However, for the ALTO-UR service, this is still an early stage 369 design. As a major next step for ALTO-UR service, other design 370 options are being investigated with the aim of enabling better 371 modularity and extensibility, and the protocol extension will be 372 updated in the next version accordingly. 374 6.2. Workflow 376 A typical workflow of an ALTO client using the unified representation 377 extension is as follows: 379 1. Send a GET request for the whole Information Resource Directory. 381 2. Look for the resource of the Cost Map Service which contains the 382 unified representation cost type and get the resource ID of the 383 dependent cstr property map. 385 3. Check whether the capabilities of the property map includes the 386 desired "prop-types". 388 4. Send a unified-representation request which accepts "multipart/ 389 related" media type following "application/alto-costmap+json" or 390 "application/endpointcost+json" 392 6.3. Information Resource Directory Example 394 An example of an Information Resource Directory is as follows. In 395 this example, filtered cost map "cost-map-ur" supports the unified- 396 representation extension. The property map "propmap-cstr" support 397 two properties, "bw-cstr" and "srlg-cstr", representing bandwidth 398 constraint and SRLG constraint, respectively. 400 { 401 "meta": { 402 "cost-types": { 403 "ur": { 404 "cost-mode": "array", 405 "cost-metric": "variable-list" 406 } 407 } 408 "resources": { 409 "my-default-networkmap": { 410 "uri" : "http://alto.example.com/networkmap", 411 "media-type" : "application/alto-networkmap+json" 412 } 413 "cost-map-ur" : { 414 "uri": "http://alto.example.com/costmap/ur", 415 "media-type": "application/alto-costmap+json", 416 "accepts": "application/alto-costmapfilter+json", 417 "capabilities": { 418 "cost-type-names": [ "ur"] 419 }, 420 "property-map": "propmap-cstr", 421 "uses": [ "my-default-networkmap" ] 422 }, 423 "propmap-cstr" : { 424 "uri": "http://alto.exmaple.com/propmap/cstr", 425 "media-type": "application/alto-propmap+json", 426 "accepts": "application/alto-propmapparams+json", 427 "capabilities": { 428 "domain-types": [ "cstr" ], 429 "prop-types": [ "bw-cstr", "srlg-cstr" ] 430 } 431 } 432 } 433 } 435 6.4. Cost Map Service Example 437 The following is an example of the cost map service in the ALTO-UR 438 extension. In the returned cost map, flow 1 has two bandwidth 439 variables, f1:bw:p1 and f2:bw:p2, and one SRLG variable, f1:srlg. 440 And flow 2 has one bandwidth variable, f2:bw, and one SRLG variable, 441 f2:srlg. Four mathematical programming constraints are returned in 442 the property map. The first three are bandwidth sharing constraints, 443 and the fourth is an SRLG constraint. 445 POST /costmap/pv HTTP/1.1 446 Host: alto.example.com 447 Accept: multipart/related, application/alto-costmap+json, 448 application/alto-propmap+json, application/alto-error+json 449 Content-Length: [TBD] 450 Content-Type: application/alto-costmapfilter+json 451 { 452 "cost-type": { 453 "cost-mode": "array", 454 "cost-metric": "variable-list" 455 }, 456 "pids": { 457 "srcs": [ "PID1" ], 458 "dsts": [ "PID2", "PID3" ] 459 } 460 } 462 HTTP/1.1 200 OK 463 Content-Length: [TBD] 464 Content-Type: multipart/related; boundary=42 466 --42 467 Content-Type: application/alto-costmap+json 469 { 470 "meta": { 471 "dependent-vtags": [ 472 { 473 "resource-id": "default-network-map", 474 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 475 } 476 ], 477 "cost-type": { 478 "cost-mode": "array", 479 "cost-metric": "variable-list" 480 }, 481 }, 483 "cost-map": { 484 "PID1": { 485 "PID2": [ "f1:bw:p1", "bw:p2", "f1:srlg"] 486 "PID3": [ "f2:bw:p1", "f2:srlg" ] 487 } 488 } 489 } 491 --42 492 Content-Type: application/alto-propmap+json 494 { 495 "property-map": { 496 "cstr:001": { "bw-cstr": "[0][0] add [0][1] leq 100"}, 497 "cstr:002": { "bw-cstr": "[0][0] eq [0][1]"}, 498 "cstr:003": { "bw-cstr": "[1][0] add [0][0] leq 100"}, 499 "cstr:004": { "srlg-cstr": "[0][2] intersect [1][1] eq {2, 3, 4}"}, 500 } 501 } 503 7. Use Case: Programmable End-to-End Multi-Domain Route Control 505 This section describes a multi-domian use case that can benefit from 506 a unified resource presentation extension of ALTO. Specifically, a 507 novel multi-domain network programming framework is recently proposed 508 to achieve programmable, end-to-end interdomain route control. 509 Specifically, in this framework, each autonomus system (AS) deploys 510 an ALTO server to provide a programming abstraction. Collectively, 511 these ALTO servers provide the client a single, abstract, 512 programmable network spanning multiple individual networks. Unlike 513 existing SDN abstractions (e.g., OpenFlow and P4), it includes a 514 built-in layer to extract and learn the interactions of interdomain 515 policies of individual networks (e.g., route selection preference), 516 providing a unified abstraction. 518 In particular, given a destination IP prefix p specified by a client, 519 each autonomous system (AS) exposes its routing information base 520 (RIB), i.e., all available routes it has to reach p, and the 521 corresponding price for the client to use each route, by deploying an 522 ALTO server. A client queries the available routes and the 523 corresponding prices at different ASes. With the retrieved 524 information, it then itereatively selects the best route based on its 525 internal objective function and budget, and interacts with different 526 ASes to check if the selected route is policy compliant, i.e., 527 whether all ASes along this route will export the preceding segment 528 to its upstream neighbor. After finding the best policy compliant 529 route, the client then interacts with ASes of the route in a backward 530 order along the route to setup the AS path. A blackbox based 531 optimization algorithm has been developed to allow the client to 532 swiftly find the best policy compliant route. A paper describing 533 this framework has been accepted by IEEE INFOCOM 2020. 535 8. Security and Privacy Considerations 537 The unified representation extension may expose more private 538 information to applications than the ALTO base protocol does. 539 However, as shown in the motivating example of providing SRLG 540 information for a set of flows, this extension has the capability of 541 exposing less private information than the ALTO-PV extension does, 542 while having a better expressiveness on providing fine-grained 543 resource information to applications. A systematic study on the 544 security and privacy issues of the ALTO-UR extension is one of the 545 major next steps. 547 9. References 549 9.1. Normative References 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, 553 DOI 10.17487/RFC2119, March 1997, 554 . 556 9.2. Informative References 558 [DRAFT-FCS] 559 Zhang, J., Gao, K., Wang, J., Xiang, Q., and Y. Yang, 560 "ALTO Extension: Flow-based Cost Query", 2017, 561 . 563 [DRAFT-NFCHAIN] 564 Perez, D. and C. Rothenberg, "ALTO-based Broker-assisted 565 Multi-domain Orchestration", 2018, 566 . 569 [DRAFT-PV] 570 Bernstein, G., Lee, Y., Roome, W., Scharf, M., and Y. 571 Yang, "ALTO Extension: Abstract Path Vector as a Cost 572 Mode", 2015, . 575 [DRAFT-RSA] 576 Gao, K., Wang, X., Xiang, Q., Gu, C., Yang, Y., and G. 577 Chen, "A Recommendation for Compressing ALTO Path 578 Vectors", 2017, . 581 [DRAFT-UP] 582 Roome, W., Chen, S., Randriamasy, S., Yang, Y., and J. 583 Zhang, "Unified Properties for the ALTO Protocol", 2015, 584 . 587 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 588 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 589 "Application-Layer Traffic Optimization (ALTO) Protocol", 590 RFC 7285, DOI 10.17487/RFC7285, September 2014, 591 . 593 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 594 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 595 DOI 10.17487/RFC8189, October 2017, 596 . 598 Authors' Addresses 600 Qiao Xiang 601 Yale University 602 51 Prospect Street 603 New Haven, CT 604 USA 606 Email: qiao.xiang@cs.yale.edu 608 J. Jensen Zhang 609 Tongji/Yale University 610 51 Prospect Street 611 New Haven, CT 612 USA 614 Email: jingxuan.zhang@yale.edu 616 Franck Le 617 IBM 618 Thomas J. Watson Research Center 619 Yorktown Heights, NY 620 USA 622 Email: fle@us.ibm.com 624 Y. Richard Yang 625 Yale University 626 51 Prospect Street 627 New Haven, CT 628 USA 630 Email: yry@cs.yale.edu