idnits 2.17.1 draft-xiang-alto-unified-representation-00.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 (July 1, 2018) is 2098 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 403, but not defined -- Looks like a reference, but probably isn't: '0' on line 439 -- Looks like a reference, but probably isn't: '1' on line 439 -- Looks like a reference, but probably isn't: '2' on line 439 == Unused Reference: 'DRAFT-RSA' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'RFC8189' is defined on line 490, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 5 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 Tongji/Yale University 4 Intended status: Standards Track F. Le 5 Expires: January 2, 2019 IBM 6 Y. Yang 7 Tongji/Yale University 8 July 1, 2018 10 ALTO Extension: Unified Resource Representation 11 draft-xiang-alto-unified-representation-00.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 January 2, 2019. 48 Copyright Notice 50 Copyright (c) 2018 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. Limitations of the ALTO Path Vector Extension . . . . . . . . 3 68 4. Overview of the Unified Representation Extension . . . . . . 5 69 4.1. Basic idea . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.2. New Cost Type to Encode Mathematical Programming 71 Variables . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.2.1. Cost Mode: array . . . . . . . . . . . . . . . . . . 6 73 4.2.2. Cost Metric: variable-list . . . . . . . . . . . . . 6 74 4.3. New Entity Domain to Provide Mathematical Programming 75 Constraints . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.4. Multipart Response to Provide the Unified Representation 7 77 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 5.1. Protocol Extension . . . . . . . . . . . . . . . . . . . 7 79 5.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 7 80 5.3. Information Resource Directory Example . . . . . . . . . 8 81 5.4. Cost Map Service Example . . . . . . . . . . . . . . . . 9 82 6. Security and Privacy Considerations . . . . . . . . . . . . . 11 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 7.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 As discussed in [DRAFT-PV], the "one-big-switch" abstraction used in 91 the ALTO base protocol lacks the ability to support emerging use 92 cases, such as inter-datacenter data transfers, because this 93 abstraction cannot reveal the resource sharing, i.e., the capacity 94 region, for a set of flows. The ALTO Path Vector extension addresses 95 this insufficiency by using the path vector abstraction to express 96 the capacity region in a set of linear inequalities. However, in an 97 internal discussion with the leading persons of several important 98 ALTO use cases, it is revealed that the expressiveness of the ALTO 99 Path Vector extension is limited in three aspects: 101 o It cannot provide compact encoding of the SRLG for a set of flows; 103 o It assumes that each flow in the client's query will use a single- 104 path route, and hence cannot encode the resource sharing for flows 105 that are forwarded along multi-path routes or multicast flows; 107 o It assumes that the route of each flow in the client's query is 108 pre-computed, and hence cannot encode the resource sharing for 109 flows that use on-demand routing, e.g., the path computation 110 element (PCE) protocol. 112 To cope with these issues, this document introduces a new ALTO 113 extension, the unified representation (ALTO-UR). This extension 114 expands the linear inequality encoding of capacity regions used in 115 ALTO-PV, to a generic, complete encoding, which uses mathematical 116 programming constraints to represent the capacity regions for a set 117 of flows. 119 2. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Limitations of the ALTO Path Vector Extension 127 The limitations of the ALTO-PV extension are illustrated with the 128 same dumbbell topology used in [DRAFT-PV]. Assume that the bandwidth 129 of every link is 100 Mbps, and that the SRLG of each link is shown in 130 Figure 1. Consider an application overlay (e.g., a large data 131 analytics system) which wants to schedule the traffic among a set of 132 end host source-destination pairs, say eh1 -> eh2 and eh1 -> eh4. 134 +------+ 135 | | 136 {1, 3} --+ sw6 +-- {1, 2} 137 / | | \ 138 PID1 +-----+ / +------+ \ {1, 4} +-----+ PID2 139 eh1__| |_ {1} / \ ____| |__eh2 140 | sw1 | \ +--+---+ +---+--+ / | sw2 | 141 +-----+ \ | | {2, 4} | |/ +-----+ 142 \_| sw5 +---------+ sw7 | 143 PID3 +-----+ / | | | |\ +-----+ PID4 144 eh3__| |__/ +------+ +------+ \____| |__eh4 145 | sw3 | {2, 3} {2, 4} | sw4 | 146 +-----+ +-----+ 148 Figure 1: A Dumbbell Network Topology 150 o Assume the application is only interested in the SRLG of both 151 flows, not the bandwidth. The route of eh1 -> eh2 is eh1 -> sw1 152 -> sw5 -> sw6 -> sw7 -> sw2 -> eh2, and the route of eh3 -> eh4 is 153 eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4. The minimal yet accurate 154 information returned to the application should be {2, 3, 4}, the 155 SRLG of both flows, since flow 1 has a set of SRLG {1, 2, 3, 4} 156 and flow 2 has a set of SRLG {2, 3, 4}. In contrast, in the 157 current ALTO-PV service, the ALTO server needs to return the ane- 158 path of each flow and the SRLG of every ane, where ane and ane- 159 path are defined in [DRAFT-PV]. This response is redundant and 160 causes unnecessary information exposure to the application, e.g., 161 the information of flow has an SRLG 1 should not be returned to 162 the application. 164 o Assume the application is only interested in the bandwidth of both 165 flows. The route of eh1 -> eh2 is eh1 -> sw1 -> sw5 -> sw6 -> sw7 166 -> sw2 -> eh2, and the route of eh3 -> eh4 is a multi-path route, 167 i.e., {eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4, eh3 -> sw1 -> sw5 168 -> sw6 -> sw7 -> sw2 -> eh4}, where each path would forward 50 169 percent of the traffic for eh3 -> eh4. The ALTO-PV service cannot 170 reveal the traffic split of the multi-path route for eh3 -> eh4, 171 or the bandwidth sharing for both flows on link sw5 -> sw6. 173 o Assume the network has a PCE sever, through which the application 174 can reserve bandwidth for both flows. Before the application 175 makes the reservation request, the application queries the ALTO 176 server to get the bandwidth capacity region of both flows, which 177 it wants to use to decide how much bandwidth to reserve for each 178 flow. Suppose when the ALTO server receives a query, the network 179 only has two precomputed routes for both flows: eh1 -> sw1 -> sw5 180 -> sw6 -> sw7 -> sw2 -> eh2, and eh3 -> sw1 -> sw5 -> sw6 -> sw7 181 -> sw2 -> eh4. Through the ALTO-PV service, the application 182 receives the information that the total bandwidth it can reserve 183 for both flows cannot exceed 100 Mbps. However, one important 184 feature of the PCE server is that it can compute the route for 185 reservation request on-demand, and hence it can find routes with a 186 larger bandwidth. In this example, if the application submits a 187 request to reserve 100 Mbps bandwidth for each flow, the PCE 188 server can compute two on-demand routes, i.e., eh1 -> sw1 -> sw5 189 -> sw6 -> sw7 -> sw2 -> eh2 and eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> 190 eh4, and still return a success signal to the application. This 191 shows that the ALTO-PV service cannot encode the capacity region 192 for flows who use on-demand routing. 194 4. Overview of the Unified Representation Extension 196 Although different patches and extensions can be introduced to 197 address the aforementioned insufficiencies of the ALTO-PV service, it 198 is desirable to design a service that provides a generic solution 199 that can encode different types of resource sharing for a set of 200 flows. To this end, this document introduces the ALTO Unified 201 Representation (ALTO-UR) service. 203 4.1. Basic idea 205 The basic idea of the ALTO-UR service is to use mathematical 206 programming constraints to represent the capacity region for a set of 207 flows. Different from linear inequalities used in the ALTO-PV 208 service, mathematical programming constraints can represent a much 209 wider range of resource information. To illustrate the 210 expressiveness of mathematical programming constraints, we revisit 211 the examples in Figure 1. 213 Assume the route of eh1 -> eh2 is eh1 -> sw1 -> sw5 -> sw6 -> sw7 -> 214 sw2 -> eh2, and the route of eh3 -> eh4 is eh3 -> sw1 -> sw5 -> sw7 215 -> sw2 -> eh4. Denote the SRLG of flow eh1 -> eh2 as f1:SRLG, and 216 that of flow eh3->eh4 as f2:SRLG. Then the SRLG of both flows can be 217 represented as 219 f1:SRLG intersect f2:SRLG = {2, 3, 4} 221 Assume the route of eh1 -> eh2 is eh1 -> sw1 -> sw5 -> sw6 -> sw7 -> 222 sw2 -> eh2, and the route of eh3 -> eh4 is a multi-path route, i.e., 223 {eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4, eh3 -> sw1 -> sw5 -> sw6 -> 224 sw7 -> sw2 -> eh4}, where each path would forward 50 percent of the 225 traffic for eh3 -> eh4. Denote the available bandwidth of eh1 -> eh2 226 as f1-bw and those of eh3 -> eh4 along two paths as f2-bw-p1 and f2- 227 bw-p2. The bandwidth sharing of two flows can be represented as: 229 f1:bw <= 100 Mbps, for (sw1, sw5), (sw7, sw2) 230 f2:bw:p1 + f2:bw:p2 <= 100 Mbps, for (sw3, sw5), (sw7, sw4) 231 f1:bw + f2:bw:p1 <= 100 Mbps, for (sw5, sw6), (sw6, sw7) 232 f2:bw:p2 <= 100 Mbps, for (sw5, sw7) 233 f2:bw:p1 = f2:bw:p2 235 Assume the routes for both flows are computed on demand and each flow 236 can only use a single path. For eh1 -> eh2, use f1-bw-p1 and 237 f1-bw-p2 to represent the available bandwidth of routes eh1 -> sw1 -> 238 sw5 -> sw6 -> sw7 -> sw2 -> eh2 and eh1 -> sw1 -> sw5 -> sw7 -> sw2 239 -> eh2, respectively. For eh3 -> eh4, use f2-bw-p1 and f2-bw-p2 to 240 represent the available bandwidth of routes eh3 -> sw1 -> sw5 -> sw6 241 -> sw7 -> sw2 -> eh4 and eh3 -> sw1 -> sw5 -> sw7 -> sw2 -> eh4, 242 respectively. The bandwidth capacity region of both flows can be 243 represented as: 245 f1:bw:p1 + f1:bw:p2 <= 100 Mbps, for (sw1, sw5), (sw7, sw2) 246 f2:bw:p1 + f2:bw:p2 <= 100 Mbps, for (sw3, sw5), (sw7, sw4) 247 f1:bw:p1 + f2:bw:p1 <= 100 Mbps, for (sw5, sw6), (sw6, sw7) 248 f1:bw:p2 + f2:bw:p2 <= 100 Mbps, for (sw5, sw7) 249 f1:bw:p1 = 0 or f1:bw:p2 = 0 250 f2:bw:p1 = 0 or f2:bw:p2 = 0 252 The next few subsections present the approaches adopted by the ALTO 253 unified representation extension. 255 4.2. New Cost Type to Encode Mathematical Programming Variables 257 This document introduces the unified representation cost type, with 258 the following cost mode and cost metric. 260 4.2.1. Cost Mode: array 262 The cost mode of the notation cost type is "array", which is defined 263 in [DRAFT-PV]. The values are arrays of JSONValue. The specific 264 type of each element in the array depends on the cost metric. 266 4.2.2. Cost Metric: variable-list 268 This document specifies a new cost metric called "variable-list". 269 This cost metric indicates that the cost value is a list of variables 270 that will be used in mathematical programming constraints. 272 4.3. New Entity Domain to Provide Mathematical Programming Constraints 274 This document adopts the property map defined in [DRAFT-UP] to encode 275 the properties of abstract network elements. A new domain "cstr" 276 (short for constraint) is registered in the property map. Each 277 entity in the "cstr" domain has an identifier of an CSTR. Each CSTR 278 has one property, which represents the semantics of this constraint, 279 e.g., a "bw-cstr" property indicates that this constraint represents 280 the bandwidth sharing among flows. This property is provided in 281 information resources called "Property Map Resource" and "Filtered 282 Property Map Resource". The "Filtered Property Map" resource which 283 supports the "cstr" domain is used to encode the properties of cstr 284 entities, and it is called a cstr Property Map in this document. 286 4.4. Multipart Response to Provide the Unified Representation 288 To ensure the consistency between the unified representation cost map 289 and the corresponding CSTR property map, this document adopts the 290 design of [DRAFT-PV] to allow a response to contain both the unified 291 representation in a filtered cost map and the associated CSTR 292 property map. 294 5. Example 296 5.1. Protocol Extension 298 To allow the ALTO client to query and receive the mathematical 299 programming constraints for a set of flows, the Filtered Cost Map and 300 Endpoint Cost Service of the ALTO protocol need to be extended. The 301 current design adopted in this document uses a similar approach as 302 the ALTO-PV extension does in [DRAFT-PV]: (1) extending the 303 FilteredCostMapCapabilities object with a new member "property-map" 304 and (2) using a multipart service to send both the unified 305 representation cost map and the CSTR property map together. This 306 design is illustrated in the next few subsections. 308 However, for the ALTO-UR service, this is still an early stage 309 design. As a major next step for ALTO-UR service, other design 310 options are being investigated with the aim of enabling better 311 modularity and extensibility, and the protocol extension will be 312 updated in the next version accordingly. 314 5.2. Workflow 316 A typical workflow of an ALTO client using the unified representation 317 extension is as follows: 319 1. Send a GET request for the whole Information Resource Directory. 321 2. Look for the resource of the Cost Map Service which contains the 322 unified representation cost type and get the resource ID of the 323 dependent cstr property map. 325 3. Check whether the capabilities of the property map includes the 326 desired "prop-types". 328 4. Send a unified-representation request which accepts "multipart/ 329 related" media type following "application/alto-costmap+json" or 330 "application/endpointcost+json" 332 5.3. Information Resource Directory Example 334 An example of an Information Resource Directory is as follows. In 335 this example, filtered cost map "cost-map-ur" supports the unified- 336 representation extension. The property map "propmap-cstr" support 337 two properties, "bw-cstr" and "srlg-cstr", representing bandwidth 338 constraint and SRLG constraint, respectively. 340 { 341 "meta": { 342 "cost-types": { 343 "ur": { 344 "cost-mode": "array", 345 "cost-metric": "variable-list" 346 } 347 } 348 "resources": { 349 "my-default-networkmap": { 350 "uri" : "http://alto.example.com/networkmap", 351 "media-type" : "application/alto-networkmap+json" 352 } 353 "cost-map-ur" : { 354 "uri": "http://alto.example.com/costmap/ur", 355 "media-type": "application/alto-costmap+json", 356 "accepts": "application/alto-costmapfilter+json", 357 "capabilities": { 358 "cost-type-names": [ "ur"] 359 }, 360 "property-map": "propmap-cstr", 361 "uses": [ "my-default-networkmap" ] 362 }, 363 "propmap-cstr" : { 364 "uri": "http://alto.exmaple.com/propmap/cstr", 365 "media-type": "application/alto-propmap+json", 366 "accepts": "application/alto-propmapparams+json", 367 "capabilities": { 368 "domain-types": [ "cstr" ], 369 "prop-types": [ "bw-cstr", "srlg-cstr" ] 370 } 371 } 372 } 373 } 375 5.4. Cost Map Service Example 377 The following is an example of the cost map service in the ALTO-UR 378 extension. In the returned cost map, flow 1 has two bandwidth 379 variables, f1:bw:p1 and f2:bw:p2, and one SRLG variable, f1:srlg. 380 And flow 2 has one bandwidth variable, f2:bw, and one SRLG variable, 381 f2:srlg. Four mathematical programming constraints are returned in 382 the property map. The first three are bandwidth sharing constraints, 383 and the fourth is an SRLG constraint. 385 POST /costmap/pv HTTP/1.1 386 Host: alto.example.com 387 Accept: multipart/related, application/alto-costmap+json, 388 application/alto-propmap+json, application/alto-error+json 389 Content-Length: [TBD] 390 Content-Type: application/alto-costmapfilter+json 391 { 392 "cost-type": { 393 "cost-mode": "array", 394 "cost-metric": "variable-list" 395 }, 396 "pids": { 397 "srcs": [ "PID1" ], 398 "dsts": [ "PID2", "PID3" ] 399 } 400 } 402 HTTP/1.1 200 OK 403 Content-Length: [TBD] 404 Content-Type: multipart/related; boundary=42 406 --42 407 Content-Type: application/alto-costmap+json 409 { 410 "meta": { 411 "dependent-vtags": [ 412 { 413 "resource-id": "default-network-map", 414 "tag": "75ed013b3cb58f896e839582504f622838ce670f" 415 } 416 ], 417 "cost-type": { 418 "cost-mode": "array", 419 "cost-metric": "variable-list" 420 }, 421 }, 423 "cost-map": { 424 "PID1": { 425 "PID2": [ "f1:bw:p1", "bw:p2", "f1:srlg"] 426 "PID3": [ "f2:bw:p1", "f2:srlg" ] 427 } 428 } 429 } 431 --42 432 Content-Type: application/alto-propmap+json 434 { 435 "property-map": { 436 "cstr:001": { "bw-cstr": "[0][0] add [0][1] leq 100"}, 437 "cstr:002": { "bw-cstr": "[0][0] eq [0][1]"}, 438 "cstr:003": { "bw-cstr": "[1][0] add [0][0] leq 100"}, 439 "cstr:004": { "srlg-cstr": "[0][2] intersect [1][1] eq {2, 3, 4}"}, 440 } 441 } 443 6. Security and Privacy Considerations 445 The unified representation extension may expose more private 446 information to applications than the ALTO base protocol does. 447 However, as shown in the motivating example of providing SRLG 448 information for a set of flows, this extension has the capability of 449 exposing less private information than the ALTO-PV extension does, 450 while having a better expressiveness on providing fine-grained 451 resource information to applications. A systematic study on the 452 security and privacy issues of the ALTO-UR extension is one of the 453 major next steps. 455 7. References 457 7.1. Normative References 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, 461 DOI 10.17487/RFC2119, March 1997, . 464 7.2. Informative References 466 [DRAFT-PV] 467 Bernstein, G., Lee, Y., Roome, W., Scharf, M., and Y. 468 Yang, "ALTO Extension: Abstract Path Vector as a Cost 469 Mode", 2015, . 472 [DRAFT-RSA] 473 Gao, K., Wang, X., Xiang, Q., Gu, C., Yang, Y., and G. 474 Chen, "A Recommendation for Compressing ALTO Path 475 Vectors", 2017, . 478 [DRAFT-UP] 479 Roome, W., Chen, S., Randriamasy, S., Yang, Y., and J. 480 Zhang, "Unified Properties for the ALTO Protocol", 2015, 481 . 484 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 485 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 486 "Application-Layer Traffic Optimization (ALTO) Protocol", 487 RFC 7285, DOI 10.17487/RFC7285, September 2014, 488 . 490 [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost 491 Application-Layer Traffic Optimization (ALTO)", RFC 8189, 492 DOI 10.17487/RFC8189, October 2017, . 495 Authors' Addresses 497 Qiao Xiang 498 Tongji/Yale University 499 51 Prospect Street 500 New Haven, CT 501 USA 503 Email: qiao.xiang@cs.yale.edu 505 Franck Le 506 IBM 507 Thomas J. Watson Research Center 508 Yorktown Heights, NY 509 USA 511 Email: fle@us.ibm.com 513 Y. Richard Yang 514 Tongji/Yale University 515 51 Prospect Street 516 New Haven, CT 517 USA 519 Email: yry@cs.yale.edu