idnits 2.17.1 draft-lee-alto-app-net-info-exchange-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 248: '... MAY be supported by the ALTO server...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3838 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ER1' is mentioned on line 301, but not defined == Missing Reference: 'ER2' is mentioned on line 301, but not defined == Missing Reference: 'DC1' is mentioned on line 301, but not defined == Missing Reference: 'DC2' is mentioned on line 301, but not defined == Missing Reference: 'DC3' is mentioned on line 301, but not defined == Missing Reference: 'TODO' is mentioned on line 741, but not defined Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ALTO Working Group Young Lee 2 Dhruv Dhody 3 Qin Wu 4 Internet Draft Huawei 5 Intended status: standard Greg Bernstein 6 Grotto Networking 7 Tae Sang Choi 8 ETRI 10 October 21, 2013 12 ALTO Extensions to Support Application and Network Resource 13 Information Exchange for High Bandwidth Applications in TE networks 15 draft-lee-alto-app-net-info-exchange-04.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with 20 the provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 21, 2014. 40 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. 51 Abstract 53 This draft proposes ALTO information model and protocol extensions to 54 support application and network resource information exchange for high 55 bandwidth applications in partially controlled and controlled 56 environments as part of the infrastructure to application information 57 exposure (i2aex) initiative. 59 Table of Contents 61 1. Introduction..................................................3 62 2. Problem Statement..............................................5 63 3. ALTO Constraints Filtering Extension Model.....................8 64 3.1. ALTO Query from Application Stratum to Network Stratum....8 65 3.2. ALTO Response from Network Stratum to Application Stratum10 66 3.3. Information Model of ALTO Query from Application Stratum to 67 Network Stratum...............................................10 68 3.4. Information Model of ALTO Response from Network Stratum to 69 Application Stratum...........................................11 70 3.5. ALTO Protocol Extension for Constraints Filtering Mechanism 71 ..............................................................11 72 3.6. Multiple Service Class...................................13 73 3.6.1. Gold Service........................................13 74 3.6.2. Silver Service......................................15 75 3.6.3. Bronze Service......................................17 76 4. ALTO Protocol Extension for Graph Representation Mechanism....19 77 5. Summary and Conclusion........................................19 78 6. Security Considerations.......................................19 79 7. IANA Considerations...........................................19 80 8. References....................................................19 81 8.1. Informative References...................................19 82 Author's Addresses...............................................21 83 Intellectual Property Statement..................................21 84 Disclaimer of Validity...........................................22 86 1. Introduction 88 This draft proposes ALTO information model and protocol extensions 89 to support application and network resource information exchange for 90 high bandwidth applications in partially controlled and controlled 91 environments as part of the infrastructure to application 92 information exposure (i2aex) initiative. The Controlled and 93 partially controlled ALTO environments referred to here are those 94 where general access to a specific ALTO server may be restricted to 95 a qualified list of clients. 97 This draft is build upon the previously introduced High Bandwidth 98 Use Cases [HighBW] and assumes that the network type carrying high 99 bandwidth is a Traffic-Engineered (TE) network. In [HighBW], we have 100 discussed two generic use cases that motivate the usefulness of 101 general interfaces for cross stratum optimization in the network 102 core. In our first use case, network resource usage became 103 significant due to the aggregation of many individually unique 104 client demands. In the second use case where data centers are 105 sending large amount of data with each other, bandwidth usage was 106 already significant enough to warrant the use of traffic engineered 107 "express lanes" (e.g., private line service). We introduce third use 108 case where inter-CDN providers may want to expose controlled network 109 resource usage information so that CDN applications (e.g., request 110 routing server) can utilize such information when appropriate 111 decisions (e.g., request routing redirection) are needed. 113 These use cases result in optimization problems that trade off 114 computational versus network costs and constraints. Both featured 115 use cases show the usefulness of an ALTO interface between the 116 application and network strata in optimizing the networked 117 applications. 119 In particular, this draft introduces: (i) enhanced constraints 120 filtering extensions to the ALTO protocol to reduce extraneous 121 information transfer and enhance information hiding from the 122 network's perspective; (ii) constrained cost graph mechanism 123 encoding that enables enhanced application traffic optimization that 124 was introduced by [HighBW]. 126 In controlled and partially controlled environments in which 127 operators are willing to share additional network stratum resource 128 information such as bandwidth constraints or additional cost types 129 of topology (e.g., graph or summary), it can be useful to reduce the 130 amount of information transferred from the ALTO server to the ALTO 131 client. 133 In considering information exchange between the application stratum 134 and the network stratum, especially from the network stratum to the 135 application stratum, the degree of information details is one of the 136 key concerns from the network providers' standpoint. On the one 137 hand, the network information has to be useful to the application; 138 on the other hand, the provided network information should hide 139 details about the network. In order to achieve these desired goals, 140 a simple enhancement to ALTO protocol would help significantly both 141 in reducing/filtering the amount of information and in increasing 142 the usefulness of the information from network to application. 144 Figure 1 shows ALTO Client-Server Architecture for Application- 145 Network information Exchange. Figure 1 shows that ALTO Client in the 146 application stratum can interface with ALTO Server in the network 147 stratum. With this architecture, a simple ALTO query mechanism from 148 application (via ALTO client) to network (via ALTO server) can be 149 implemented. According to this architecture, ALTO Client is assumed 150 to interact with the Application Orchestrator that has the knowledge 151 of the end-user (i.e., source) application requirement, Data Center 152 locations (i.e., destinations) and their resource information. 154 +--------------+ 155 Resource Request | Application | 156 -----------> | Orchestrator | 157 +--------------+ 158 | ALTO Client | 159 +--------------+ 160 | /|\ 161 ALTO Query | | ALTO Response 162 | | 163 | | 164 | | 165 \|/ | 166 +--------------+ 167 | ALTO Server | 168 +--------------+ 169 | Network | 170 | Orchestrator | 171 +--------------+ 173 Figure 1 ALTO Client-Server Architecture for Application-Network 174 information Exchange 176 The Application Orchestration functions depicted in Figure 1 177 interfacing data centers and end-users are out of the scope of this 178 document. For simplicity purpose, Figure 1 doesn't depict the 179 detailed relationship between ALTO client and server. In fact, both 180 client and server don't need to be in the same administration 181 boundary. It can be inter-operator and one to many relationships. 182 For example, in the cases of inter-CDN environment or generic multi- 183 domain environment, ALTO client represents a request routing server 184 of upstream CDN operator and it interacts with multiple downstream 185 CDN operators for their network resource information to make 186 efficient decisions for desired quality CDN services. Interaction 187 methods can either iterative or recursive. That is, ALTO client can 188 interact with multiple ALTO servers directly or ALTO client can 189 interact with one representative ALTO server and subsequent 190 interaction is done by the representative one to rest of ALTO 191 servers. 193 The organization of this document is as follows. Section 2 discusses 194 the ALTO architecture in the context of the application and network 195 strata interaction. Section 3 provides ALTO Information model and 196 protocol extension to support ALTO Constraints Filtering Mechanism. 197 Section 4 provides ALTO information model and the protocol extension 198 to support ALTO Constrained Cost Graph Mechanism. 200 2. Problem Statement 202 One critical issue in Application-Network information exchange in 203 ALTO is the amount of information exchanged between the application 204 and network strata. The information provided by network providers 205 can be not so useful to the application stratum unless such 206 information is abstracted into an appropriate level the that 207 application stratum can understand. 209 In partially controlled and controlled environments, network 210 providers can furnish appropriately abstracted and pruned 211 information to the application stratum with the cooperation of the 212 application stratum that can indicate some level of filtering and 213 pruning in its query. 215 To reduce extraneous information this draft allows for "filtering" 216 (or "pruning") of the following information in query/response of the 217 ALTO pull model: 219 . Topology Filtering - reduction of the results to only those 220 specified set of source(s) and destination(s) instead of the 221 entire network cost map. Note that this mechanism is not new 222 in the current ALTO protocol. In the context of application- 223 network information exchange, this topology filtering can be 224 of a tremendous help in reducing the amount of data exchanged 225 between application and network. 226 . Multiple Service Class: ALTO server may provide multiple class 227 of service (Gold, Silver, or Bronze) and allow application to 228 request them accordingly. 229 . Multiple Cost: Alto server should be able to provide multiple 230 cost for a end to end path or abstract links in the graph. 231 . Optimization Criteria: The optimization criteria that the ALTO 232 server may use. For example, the criteria can be least number 233 of hops, least amount of delay (latency), etc. 234 . Constraint Filtering on paths or graphs (e.g., bandwidth, 235 latency, hop count, packet loss, etc.) - reduction of results 236 to only those that meet ALTO client specified cost bounds. 238 As discussed in [HighBW], in a controlled environment optimization 239 is significantly enhanced by sharing data related to bandwidth 240 constraints and additional cost measures [MultiCost], [TE-cost]. 241 Such information may be considered sensitive to the network provider 242 just as application data, e.g., usage, demand, etc., may be 243 considered sensitive to an application provider. Section 3 provides 244 ALTO information model and protocol extensions to support topology, 245 multiple service class, constraints filtering mechanism. 247 Multiple Service Class (such as gold, silver and bronze services) 248 MAY be supported by the ALTO server. These service classes could 249 specify how the network is used (for ex exclusively reserved for the 250 application, protection provided etc). The Application should 251 further provision/reserve the network using some mechanisms which 252 are out of scope of this document. Some example of services: _ 254 . Gold Service 256 This service could be used to specify that an exact path meeting the 257 application needs should be found. This path would be provisioned 258 and resources reserved exclusively for its use. An example could be 259 a private enterprise DC, which wish to offload to a public DC during 260 peak load. 262 . Silver Service 264 This service could be used to get the path properties between User 265 regions and DC. It could also specify some basic constraints that 266 all of them should satisfy. These paths would be provisioned and 267 resources maybe reserved. The Application may further assign end 268 user request to a particular DC by using the network information of 269 these paths. An example could be a gaming server geographically 270 dispersed at multiple DC. The end-user (gamer) could be dynamically 271 assigned to the DC by looking at the past assignment, DC load and 272 network properties. 274 . Bronze Service 276 This service could be used to specify that a simple best effort path 277 should be found. This path would not be provisioned and resources 278 will not be reserved. The service could still return the network 279 information to the application which can use this information for DC 280 selection by taking network information into consideration. An 281 example could be a HD video service, which may use the network info 282 to select video source for the end user. 284 While it is important to reduce and filter the information amount 285 from network to application, for some applications that require 286 stringent QoS objectives (e.g., bandwidth and latency), simple 287 summary source-destination network resource information (i.e., 288 summary form of topology) may not provide sufficient details to the 289 application stratum. For example, suppose that a multiple number of 290 large concurrent flows need to be scheduled from application to 291 network. In such a case, a summary form of network topology that 292 only shows source-destination bandwidth availability may not show 293 the bottleneck links over which more than one flow may compete for 294 the link bandwidth resource. This problem was indicated by [HighBW]. 295 The following are the excerpts from [HighBW]. 297 Consider the network shown in Figure 2, where DC indicates a 298 datacenter, ER an end user region (as in the end user aggregation 299 use case), N a switching node of some sort, and L a link. The link 300 capacities and costs are also shown on the figure as well as a cost 301 map between [ER1, ER2] and [DC1, DC2, DC3]. Since the network has a 302 tree structure (very unusual but easier to draw in ASCII art), the 303 cost map is unique. 305 As an illustration, assume that the maximum available capacity 306 between any individual end region and a data center is 5 units(i.e., 307 L1=L2=L5=L6=5). However, link L3 (capacity 8 units) represents a 308 bottle neck to all the data centers (L3 is on all the paths to DC1, 309 DC2, or DC3 from all end regions, ER1 and ER2). 311 ALTO Cost Map is shown in the lower right corner of Figure 2. This 312 summary cost map does not provide enough details on the bottle 313 necks. The lower left corner shows Link Capacity Cost, from which 314 the bottle necks can be shown such that multi-flow commodity 315 scheduling can be made possible to avoid such bottle necks. 317 ,---. L1 +----+ 318 ( ER1 )`-. L5 .'|DC1 | 319 `---' `-._ ,-. / +----+ 320 ( N1) L3 ,-..' 321 .-'`-' `-.__ L4--(N3 ) 322 ,---. .' `-. ,-..--'' `-'`. +----+ 323 ( ER2 ).-'L2 (N2 ) L6 `-.|DC2 | 324 `---' `-'`-._ +----+ 325 `-. 326 Link Capacity Cost `-._L7 327 L1 5 `-. 328 L2 5 `-._ 329 L3 8 `-. 330 L4 6 ALTO Cost Map `-.+----+ 331 L5 5 DC1 DC2 DC3 _ |DC3 | 332 L6 5 ER1 5 5 8 +----+ 333 L7 10 ER2 6 6 9 335 Figure 2. Example network illustrating bottlenecks 337 With the current ALTO cost map structure, the least cost path from 338 ER1 would be either to DC1 or DC2. However, with the proposed 339 capacitated cost map, the connection from ER1 to DC3 could be a 340 better choice than the rest depending on the relative cost of 341 network resources to data center resources. 343 A more general and relatively efficient alternative is to provide 344 the requestor with a capacitated and multiply weighted graph that 345 approximates and abstracts the capabilities of the network as seen 346 by the source and destination location sets. This document provides 347 ALTO information model and protocol extensions to support the graph 348 model in Section 4. 350 3. ALTO Constraints Filtering Extension Model 352 3.1. ALTO Query from Application Stratum to Network Stratum 354 In order for the network stratum to provide its resource 355 information, the application stratum needs to provide the End Point 356 Cost Map to the network stratum. The End Point Cost Map should 357 include the following information at a minimum: 359 . End Point Source Address(es) /* these are the respective 360 addresses of the nearest PE's to the user/client location */ 362 . End Point Destination Address(es) /* these are the respective 363 addresses of the nearest PE's to a set of the candidate Data 364 Center locations that can provide service to the user request. 365 */ 367 Note that how ALTO client derives the End Point Source/Destination 368 addresses in terms of the nearest PE's is beyond the scope of this 369 document. 371 . Service-Class:= {gold, silver, bronze} /*the service class as 372 described in this document*/ 374 . Cost Type:= 'routingcost' as defined by base specification. 375 Additional cost (ex. latency, hopcount) are defined in 376 [MultiCost] and [TE-cost]. 378 . Cost Mode :={summary, graph} /* the cost map can be either a 379 summary form or a graph form */ 381 o Cost Mode: summary 383 This cost mode is indicated by string 'summary'. This mode 384 indicates that the returned costs contain end-to-end 385 values which can be used by application stratum for better 386 selection of resources. 388 o Cost Mode: gragh 390 This cost mode is indicated by string 'gragh' in which 391 case an abstract topology is returned to the application. 393 . Constraints /* a set of constraints that apply to the requested 394 path summary or graph for filtering. For instance, constraints 395 can be like bandwidth greater than 'x', latency less than 'y', 396 hopcount less than 'z', packetloss less than 'a' etc. */ 398 . Objective-function (or Optimization Criteria): The summary or 399 the graph should be computed based on optimizing which 400 parameter - IGP cost, latency, residual bandwidth, etc. This is 401 for future use. 403 3.2. ALTO Response from Network Stratum to Application Stratum 405 In response to the ALTO Query from the Application Stratum, the 406 Network Stratum needs to provide the filtered Cost Map Data of the 407 feasible path found. The Filtered End Cost Map Data should include 408 the following information at a minimum: 410 . The list of feasible Source-Destination pair and its Cost Type 412 . For each feasible S-D pair, indicate the following as specified 413 in Section 3.4: 415 o Service Class; 417 o Cost Mode; 419 o Cost Type; 421 o Endpoint Cost Map Data 423 . Parameter Values /* indicate the actual values of each 424 constraint requested */ 426 Note that in case of Graph, each S-D pair is the source of the 427 abstract link and the destination of the abstract link. 429 3.3. Information Model of ALTO Query from Application Stratum to 430 Network Stratum 432 Alto query: 434 Object{ 435 TypedEndpointAddr Src<1...*>; /*atleast one source*/ 436 TypedEndpointAddr Dsts<2...*>; /*atleast two destinations*/ 437 }EndpointList; 439 Object{ 440 ServiceClass service-class; 441 CostMode cost-mode; 442 CostType cost-type; 443 [JSONString constraints<0...*>; ] 444 [JSONString ObjectiveFunction] 445 EndpointList endpoints; 446 }EndpointCostMapReq; 448 3.4. Information Model of ALTO Response from Network Stratum to 449 Application Stratum 451 Alto response: 453 Object-map{ 454 JSONString costparam; 455 } EndpointCostParam ; 457 Object-map{ 458 TypedEndpointAddr -> EndpointCostParam<1...*>; 459 } EndpointCosts ; 461 Object-map{ 462 TypedEndpointAddr -> EndpointCosts; 463 } EndpointCostMapData ; 465 Object{ 466 ServiceClass service-class; 467 CostMode cost-mode; 468 CostType cost-type; 469 [EndpointCostMapData map;] 470 }EndpointCostMapRsp; 472 The Alto response consist of map (EndpointCostMapData) which is map 473 containing the S-D pairs information. For each destination, its 474 parameters (rank, cost etc) is included using EndpointCostParam. 476 3.5. ALTO Protocol Extension for Constraints Filtering Mechanism 478 This section provides the ALTO protocol extensions based on the 479 information model discussed in Sections 3.3. and 3.4. The scenario 480 provided in this section is that the ALTO client in the Application 481 Stratum requests the summary cost map from the network with one 482 source and three destinations. 484 In this particular example, the ALTO client requests the filtered 485 summary of the network path subject to: bandwidth >= 20, latency < 486 10, hop count < 5 and packet loss < 0.03. 488 The ALTO server provides the resulted network paths in summary. 490 POST /endpointcost/lookup HTTP/1.1 491 Host: alto.example.com 492 Content-Length: [TODO] 493 Content-Type: application/alto-csoendpointcostparams+json 494 Accept: application/alto-csoendpointsummary+json,application/alto- 495 error+json 496 { 497 "service-class" : "silver", 498 "cost-mode" : "summary", 499 "cost-type" : "routingcost", 500 "constraints": ["availbw gt 20", "delay lt 10", "hopcount lt 5", 501 "pktloss lt 0.03"], 502 "endpoints" : { 503 "srcs": [ "ipv4:192.0.2.2" ], 504 "dsts": [ 505 "ipv4:192.0.2.89", 506 "ipv4:198.51.100.34", 507 "ipv4:203.0.113.45" 508 ] 509 } 510 } 512 HTTP/1.1 200 OK 513 Content-Length: [TODO] 514 Content-Type: application/alto-csoendpointsummary+json 515 { 516 "meta" : {}, 517 "data" : { 518 "service-class" : "silver", 519 "cost-mode" : "summary", 520 "cost-type" : "routingcost", 521 "map" : { 522 "ipv4:192.0.2.2": { 523 "ipv4:192.0.2.89" : [ "delay eq 5", 524 "hopcount eq 8", "pktloss eq 0.01", cost eq 525 100" ], 526 "ipv4:18.51.100.34" : [ "delay eq 9", 527 "hopcount eq 10", "pktloss eq 0.02", cost 528 eq 120" ], 529 "ipv4:203.0.113.45" : [ "delay eq 40", 530 "hopcount eq 12", "pktloss eq 0.02", cost 531 eq 50" ] 532 } 533 } 534 } 535 } 536 3.6. Multiple Service Class 538 The examples of various class of service is as follows, note that 539 these examples are for illustrative purpose only. 541 3.6.1. Gold Service 543 As an example of a Gold service, consider a customer (say an 544 Enterprise Private DC) who pays Top-Dollor to setup network based on 545 the actual demand. The Path (maybe a TE LSP) would not be used by 546 any other customer / application giving guarantee of service and 547 best QoE to the application. The ALTO request/response may be used 548 first to get the network states and later the path may also be 549 provisioned by some mechanism which is out of scope of this 550 document. 552 In this example, the application may like to find out the ranking of 553 the destinations (DC) from the network point of view. It may further 554 set the filtering constraints for bandwidth (bw), delay etc. The 555 ALTO server first filter the destination that do not meet the 556 constraints, further it provides ranking information based on the 557 requested costtype. 559 Alto Request: 560 POST /endpointcost/lookup HTTP/1.1 561 Host: alto.example.com 562 Content-Length: [TODO] 563 Content-Type: application/alto-csoendpointcostparams+json 564 Accept: application/alto- 565 csoendpointsummary+json,application/alto- 566 error+json 567 { 568 "service-class" : "gold", 569 "cost-mode" : "summary", 570 "cost-type" : "routingcost", 571 "constraints": ["availbwgt 20", "delay lt 10", 572 "pktloss lt 0.03", "jitter lt 10", "hopcount 573 lt 5" ], 574 "endpoints" : { 575 "srcs": [ "ipv4:192.0.2.2" ], 576 "dsts": [ 577 "ipv4:192.0.2.89", 578 "ipv4:198.51.100.34", 579 "ipv4:203.0.113.45" 580 ] 581 } 582 } 583 ALTO server would factor in the filtering constraints and provide 584 only the ranking information to the application. 586 Alto Response: 588 HTTP/1.1 200 OK 589 Content-Length: [TODO] 590 Content-Type: application/alto-csoendpointsummary+json 591 { 592 "meta" : {}, 593 "data" : { 594 "service-class" : "gold", 595 "cost-mode" : "summary", 596 "cost-type" : "routingcost", 597 "map" : { 598 "ipv4:192.0.2.2": { 599 "ipv4:192.0.2.89" : [ "rank eq 3" ], 600 "ipv4:198.51.100.34" : [ "rank eq 1" ], 601 "ipv4:203.0.113.45" : [ "rank eq 2" ] 602 } 603 } 604 } 605 } 606 Note that above is just an example, a gold service may also choose to 607 get detailed end to end information or an abstract graph. 609 3.6.2. Silver Service 611 As an example of a Silver service, consider a customer (say a Online 612 Gaming Company) which will pay flat subscription fees to connect end 613 user-regions to the DC hosting the online gaming servers.. In this 614 case during the setup phase a flat full mesh of paths are 615 established between the User regions and the Data Centers. 617 The Application gaming load balancer would handle the gaming end 618 user by allocating him to a particular DC (gaming server). The 619 reserved resources during admin setup are allocated to multiple end 620 user requests. 622 In this example, application may want to know the end to end 623 properties of the path between the user-regions and the DC. It may 624 further set the filtering constraints for bandwidth (bw), delay etc. 626 Alto Request: 628 POST /endpointcost/lookup HTTP/1.1 630 Host: alto.example.com 631 Content-Length: [TODO] 632 Content-Type: application/alto-csoendpointcostparams+json 633 Accept: application/alto-csoendpointsummary+json,application/alto- 634 error+json 635 { 636 "service-class" : "silver", 637 "cost-mode" : "summary", 638 "cost-type" : "routingcost", 639 "constraints": ["availbwgt 20", "delay lt 10", 640 "pktloss lt 0.03", "jitter lt 10", "hopcount 641 lt 5" ], 643 "endpoints" : { 644 "srcs": [ 645 "ipv4:192.0.2.2", 646 "ipv4:192.0.2.10" 647 ], 648 "dsts": [ 649 "ipv4:192.0.2.89", 650 "ipv4:198.51.100.34", 651 "ipv4:203.0.113.45" 653 ] 654 } 655 } 656 ALTO server would factor in the filtering constraints and provide 657 the end to end cost parameters to the application. 659 Alto Response: 660 HTTP/1.1 200 OK 661 Content-Length: [TODO] 662 Content-Type: application/alto-csoendpointsummary+json 663 { 664 "meta" : {}, 665 "data" : { 666 "service-class" : "silver", 667 "cost-mode" : "summary", 668 "cost-type" : "routingcost", 669 "map" : { 670 "ipv4:192.0.2.2": { 671 "ipv4:192.0.2.89" : [ "delay eq 5", "jitter eq 5", 672 "pktloss eq 0.01", "hopcount eq 8", 673 "cost eq 100" ], 674 "ipv4:198.51.100.34" : [ "delay eq 9", "jitter eq 3", 675 "pktloss eq 0.02", "hopcount eq 10", 676 "cost eq 500" ], 677 "ipv4:203.0.113.45" : [ "delay eq 4", "jitter eq 4", 678 "pktloss eq 0.02", "hopcount eq 12", 679 "cost eq 200" ] 680 } 682 "ipv4:192.0.2.10": { 683 "ipv4:192.0.2.89" : [ "delay eq 4", "jitter eq 4", 684 "pktloss eq 0.03", "hopcount eq 6", 685 "cost eq 300" ], 686 "ipv4:203.0.113.45" : [ "delay eq 6", "jitter eq 6", 687 "pktloss eq 0.04", "hopcount eq 8", 688 "cost eq 400"] 689 } 690 } 691 } 692 } 694 Note that above is just an example, a silver service may also choose to 695 get an abstract graph in response. 697 3.6.3. Bronze Service 699 As an example of a Bronze service, consider a customer (say a Video 700 service) doesnt reserve resources but pays a small fees to get an 701 abstract view of the network. Best effort service, use IP best 702 effort path(instead of reserved paths used by gold, silver). The 703 application (global load balancer) could get the network abstract 704 topology and would further handle the end user request by allocating 705 them to a particular DC or CDN. 707 In this example, application may rely on the basic IP best effort 708 but would like to know the abstract topology that could be used by 709 the application to find out bottleneck etc. Note that no constraints 710 are passed in this example and graph is requested. 712 Alto Request: 713 POST /endpointcost/lookup HTTP/1.1 714 Host: alto.example.com 715 Content-Length: [TODO] 716 Content-Type: application/alto-csoendpointcostparams+json 717 Accept: application/alto- 718 csoendpointsummary+json,application/alto- 719 error+json 720 { 721 "service-class" : "bronze", 722 "cost-mode" : "graph", 723 "cost-type" : "routingcost", 724 "endpoints" : { 725 "srcs": [ 726 "ipv4:192.0.2.2", 727 "ipv4:192.0.2.10" ], 728 "dsts": [ 729 "ipv4:192.0.2.89", 730 "ipv4:198.51.100.34", 731 "ipv4:203.0.113.45" 732 ] 733 } 734 } 736 ALTO server would prepare an abstract network graph based on the 737 source(s) and destination(s). The graph may also include some 738 internal (maybe abstract) nodes (ex 192.0.2.20 and 192.0.2.30). 739 Alto Response: 740 HTTP/1.1 200 OK 741 Content-Length: [TODO] 742 Content-Type: application/alto-csoendpointsummary+json 743 { 744 "meta" : {}, 745 "data" : { 746 "service-class" : "bronze", 747 "cost-mode" : "graph", 748 "cost-type" : "routingcost", 749 "map": { 750 "ipv4:192.0.2.2": { 751 "ipv4:192.0.2.20" : [ "delay eq 9", "jitter eq 2", 752 "pktloss eq 0.04", "availbw eq 20", 753 "cost eq 100" ] 754 } 756 "ipv4:192.0.2.20": { 757 "ipv4:192.0.2.89" : [ "delay eq 5", "jitter eq 2", 758 "pktloss eq 0.02", "availbw eq 30", 759 "cost eq 100" ], 760 "ipv4:198.51.100.34" : [ "delay eq 3", "jitter eq 2", 761 "pktloss eq 0.01", "availbw eq 50", 762 "cost eq 400" ] 763 } 765 "ipv4:192.0.2.10": { 766 "ipv4:192.0.2.30" : [ "delay eq 4", "jitter eq 2", 767 "pktloss eq 0.01", "availbw eq 60", 768 "cost eq 300" ] 769 } 771 "ipv4:192.0.2.30": { 772 "ipv4:203.0.113.45" : [ "delay eq 2", "jitter eq 2", 773 "pktloss eq 0.03", "availbw eq 10", 774 "cost eq 200" ] 775 } 776 } 777 } 779 } 780 Note that above is just an example, a bronze service may also choose to 781 get end to end information instead of an abstract graph in response. 783 Note that the EndpointCostMapData can be used for both the Graph 784 representation as well as the end to end path. 786 4. ALTO Protocol Extension for Graph Representation Mechanism 788 The encoding details for graph representation mechanism are shown in 789 Section 3.6.3 where the use of graph in a Bronze service is 790 described. 792 5. Summary and Conclusion 794 TBD 796 6. Security Considerations 798 TBD 800 7. IANA Considerations 802 TBD 804 8. Acknowledgements 806 The authors would like to thank Richard Yang and Sabine Randriamasy 807 for many helpful comments that greatly improved the contents of this 808 draft. 810 9. References 812 9.1. Informative References 814 [HighBW] G. Bernstein and Y. Lee, "Use Cases for High Bandwidth 815 Query and Control of Core Networks," draft-bernstein-alto- 816 large-bandwidth-cases, work in progress. 818 [MultiCost] S. Randriamasy, Ed., "Multi-Cost ALTO," draft- 819 randriamasy-alto-multi-cost, work in progress. 821 [TE-cost] Q. Wu, et. al. "JSON Format Extensions for Traffic 822 Engineering (TE) performance metrics in the ALTO 823 Information Resource Directory, draft-wu-alto-json-te, 824 work in progress. 826 Author's Addresses 828 Young Lee 829 Huawei Technologies 830 1700 Alma Drive, Suite 500 831 Plano, TX 75075 832 USA 833 Phone: (972) 509-5599 834 Email: leeyoung@huawei.com 836 Dhruv Dhody 837 Huawei Technologies, India 838 Email: dhruv.dhody@huawei.com 840 Qin Wu 841 Huawei Technologies, China 842 Email: bill.wu@huawei.com 844 Greg M. Bernstein 845 Grotto Networking 846 Fremont California, USA 847 Phone: (510) 573-2237 848 Email: gregb@grotto-networking.com 850 Tae-Sang Choi 851 ETRI 852 161 Gajong-Dong, Yusong-Gu 853 Daejon, Republic of Korea 854 Phone: (8242) 860-5628 855 Email: choits@etri.re.kr 857 Intellectual Property Statement 859 The IETF Trust takes no position regarding the validity or scope of 860 any Intellectual Property Rights or other rights that might be 861 claimed to pertain to the implementation or use of the technology 862 described in any IETF Document or the extent to which any license 863 under such rights might or might not be available; nor does it 864 represent that it has made any independent effort to identify any 865 such rights. 867 Copies of Intellectual Property disclosures made to the IETF 868 Secretariat and any assurances of licenses to be made available, or 869 the result of an attempt made to obtain a general license or 870 permission for the use of such proprietary rights by implementers or 871 users of this specification can be obtained from the IETF on-line 872 IPR repository at http://www.ietf.org/ipr 874 The IETF invites any interested party to bring to its attention any 875 copyrights, patents or patent applications, or other proprietary 876 rights that may cover technology that may be required to implement 877 any standard or specification contained in an IETF Document. Please 878 address the information to the IETF at ietf-ipr@ietf.org. 880 Disclaimer of Validity 882 All IETF Documents and the information contained therein are 883 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 884 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 885 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 886 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 887 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 888 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 889 FOR A PARTICULAR PURPOSE. 891 Acknowledgment 893 Funding for the RFC Editor function is currently provided by the 894 Internet Society.