idnits 2.17.1 draft-busibel-ccamp-path-computation-api-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 : ---------------------------------------------------------------------------- ** There are 116 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 312 has weird spacing: '...ination is ve...' -- The document date (July 7, 2016) is 2851 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Italo Busi 2 Internet Draft Huawei 3 Intended status: Informational Sergio Belotti 4 Expires: January 2017 Nokia 5 Victor Lopez 6 Oscar Gonzalez de Dios 7 Telefonica 8 Anurag Sharma 9 Infinera 10 Yan Shi 11 China Unicom 12 Ricard Vilalta 13 CTTC 14 Karthik Sethuraman 15 NEC 17 July 7, 2016 19 Path Computation API 20 draft-busibel-ccamp-path-computation-api-00.txt 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on January 7, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Abstract 61 There are scenarios, typically in a hierarchical SDN context, in 62 which an orchestrator may not have detailed information to be able 63 to perform an end-to-end path computation and would need to request 64 lower layer/domain controllers to calculate some (partial) feasible 65 paths. 67 Multiple protocol solutions can be used for communication between 68 different controller hierarchical levels. This document assumes that 69 the controllers are communicating using YANG-based Application 70 Programming Interface (APIs). 72 This document describes some use cases for an Application 73 Programming Interface for path computation. A related yang model 74 will be proposed in a next version or in another document. 76 Table of Contents 78 1. Introduction...................................................3 79 2. Use Cases......................................................4 80 2.1. IP-Optical integration....................................4 81 2.1.1. Inter-layer path computation.........................5 82 2.1.2. Route Diverse IP Services...........................10 84 2.2. Multi-domain Optical Networks............................10 85 2.3. Data center interconnections.............................14 86 3. Security Considerations.......................................16 87 4. IANA Considerations...........................................16 88 5. References....................................................16 89 5.1. Normative References.....................................16 90 5.2. Informative References...................................16 91 6. Acknowledgments...............................................16 93 1. Introduction 95 There are scenarios, typically in a hierarchical SDN context, in 96 which an orchestrator may not have detailed information to be able 97 to perform an end-to-end path computation and would need to request 98 lower layer/domain controllers to calculate some (partial) feasible 99 paths. 101 Multiple protocol solutions can be used for communication between 102 different controller hierarchical levels. This document assumes that 103 the controllers are communicating using YANG-based Application 104 Programming Interface (APIs). 106 Path Computation Elements, Controllers and Orchestrators perform 107 their operations based on Traffic Engineering Databases (TED). Such 108 TEDs can be described, in a technology agnostic way, with the YANG 109 Data Model for TE Topologies [TE-TOPO]. Furthermore, the technology 110 specific details of the TED are modeled in the augmented TE topology 111 models (e.g. [L1-TOPO] for Layer-1 ODU technologies). 113 The availability of such topology models allows providing the TED 114 via Netconf or Restconf API. Furthermore, it enables that a 115 PCE/Controller performs the necessary abstractions or modifications 116 and offer this customized topology to another PCE/Controller or high 117 level orchestrator. 119 The tunnels that can be provided over the networks described with 120 the topology models can be also set-up, deleted and modified via 121 Netconf or Restconf API using the TE-Tunnel Yang model [TE-TUNNEL]. 123 This document describes some use cases where a path computation 124 function, also using Netconf or Restconf API, can be needed. A 125 related yang model will be proposed in a next version or in another 126 document. 128 2. Use Cases 130 This document presents different use cases, where an API for path 131 computation is required. The presented uses cases have been grouped, 132 depending on the different underlying topologies: a) IP-Optical 133 integration; b) Multi-domain Optical Networks; and c) Data center 134 interconnections. 136 2.1. IP-Optical integration 138 In these use cases, there is an Optical domain which is used to 139 provide connectivity between IP routers which are connected with the 140 Optical domains using access links (see Figure 1). 142 -------------------------------------------------------------------- 143 I I 144 I I 145 I I 146 I IP+Optical Use Cases I 147 I I 148 I I 149 I I 150 I I 151 I (only in PDF version) I 152 I I 153 I I 154 I I 155 I I 156 I I 157 -------------------------------------------------------------------- 159 Figure 1 - IP+Optical Use Cases 161 It is assumed that the Optical domain controller provides to the 162 orchestrator an abstracted view of the Optical network. A possible 163 abstraction shall be representing the optical domain as one "virtual 164 node" with "virtual ports" connected to the access links. 166 The path computation request helps the orchestrator to know which 167 are the real connections that can be provided at the optical domain. 169 -------------------------------------------------------------------- 170 I I 171 I I 172 I I 173 I I 174 I IP+Optical Topology Abstraction I 175 I I 176 I I 177 I I 178 I I 179 I (only in PDF version) I 180 I I 181 I I 182 I I 183 I I 184 I I 185 I I 186 -------------------------------------------------------------------- 188 Figure 2 - IP+Optical Topology Abstraction 190 2.1.1. Inter-layer path computation 192 In this use case the orchestrator needs to setup an optimal path 193 between two IP routers R1 and R2. 195 As depicted in Figure 2, the Orchestrator has only an "abstracted 196 view" of the physical network, and it does not know the feasibility 197 or the cost of the possible optical paths (e.g., VP1-VP4 and VP2- 198 VP5), which depend from the current status of the physical resources 199 within the optical network and on vendor-specific optical 200 attributes. 202 However, the orchestrator can ask the underlying Optical domain 203 controller to compute a set of potential optimal paths, taking into 204 account optical constraints Then, based on its own constraints, 205 policy and knowledge (e.g. cost of the access links), it can choose 206 which one of these potential paths to use to setup the optimal e2e 207 path crossing optical network. 209 -------------------------------------------------------------------- 210 I I 211 I IP+Optical Path Computation Example I 212 I I 213 I I 214 I (only in PDF version) I 215 I I 216 -------------------------------------------------------------------- 218 Figure 3 - IP+Optical Path Computation Example 220 For example, in Figure 3, the Orchestrator can request the Optical 221 domain controller to compute the paths between VP1-VP4 and VP2-VP5 222 and then decide to setup the optimal end-to-end path which passes 223 through the VP2-VP5 Optical path even this is not the optimal path 224 from the Optical domain perspective. 226 An alternative approach could be to have the Optical domain 227 controller making the information shown in Figure 3 available to the 228 Orchestrator. 230 One possibility, under discussion within the TEAS WG, is to provide 231 a "detailed connectivity matrix" which extends the "connectivity 232 matrix" defined in [RFC7446] and describes not only the valid 233 inbound-outbound TE link switching combinations, but also specifies 234 a vector of various costs (in terms of delay, OSNR, intra-node SRLGs 235 and summary TE metrics) a potential TE path associated with the 236 connectivity matrix entry. 238 The information provided by the "detailed abstract connectivity 239 matrix" would be equivalent to the information that should be 240 provided by "virtual link model" as defined in [TE-INTERCONNECT]. 242 In this case, the Path Computation Element (PCE) within the 243 Orchestrator could use this information to calculate by its own the 244 optimal path between routers R1 and R2, without requesting any 245 additional information to the Optical Domain Controller. 247 However, there is a tradeoff between the accuracy (i.e., providing 248 "all" the information that might be needed by the Orchestrator's 249 PCE) and scalability to be considered when designing the amount of 250 information to provide within the "detailed abstract connectivity 251 matrix". 253 Figure 4 below shows another example, similar to the one in Figure 254 3, but where there are two possible Optical paths between VP1 and 255 VP4 with different properties (e.g., available bandwidth and cost). 257 -------------------------------------------------------------------- 258 I I 259 I IP+Optical Path Computation Example I 260 I with multiple choices I 261 I I 262 I I 263 I (only in PDF version) I 264 I I 265 -------------------------------------------------------------------- 267 Figure 4 - IP+Optical Path Computation Example with multiple choices 269 Reporting all the information, as in Figure 4, using the "detailed 270 abstract connectivity matrix" is quite challenging from a 271 scalability perspective since the amount of this information is not 272 just based on number of end points (which would scale as N-square), 273 but also on many other parameters, including client rate, user 274 constraints / policies for the service, e.g. max latency < N ms, max 275 cost, etc., exclusion policies to route around busy links, min OSNR 276 margin, max preFEC BER etc. All these constraints could be different 277 based on connectivity requirements. 279 It is also worth noting that the "connectivity matrix" has been 280 originally defined in WSON, [RFC7446] to report the connectivity 281 constrains of a physical node within the WDM network: the 282 information it contains is pretty "static" and therefore, once taken 283 and stored in the TE data base, it can be always being considered 284 valid and up-to-date in path computation request. 286 Using the "connectivity matrix" with an abstract node to abstract 287 the information regarding the connectivity constraints of an Optical 288 domain, would make this information more "dynamic" since the 289 connectivity constraints of an Optical domain can change over time 290 because some optical paths that are feasible at a given time may 291 become unfeasible at a later time when e.g., another optical path is 292 established. The information in the "detailed abstract connectivity 293 matrix" is even more dynamic since the establishment of another 294 optical path may change some of the parameters (e.g., delay or 295 available bandwidth) in the "detailed abstract connectivity matrix" 296 while not changing the feasibility of the path. 298 "Connectivity matrix" is sometimes confused with optical reach table 299 that contain multiple (e.g. k-shortest) regen-free reachable paths 300 for every A-Z node combination in the network. Optical reach tables 301 can be calculated offline, utilizing vendor optical design and 302 planning tools,and periodically uploaded to the Controller: these 303 optical path reach tables are fairly static. However, to get the 304 connectivity matrix, between any two sites, either a regen free path 305 can be used, if one is available, or multiple regen free paths are 306 concatenated to get from src to dest, which can be a very large 307 combination. Additionally, when the optical path within optical 308 domain needs to be computed, it can result in different paths based 309 on input objective, constraints, and network conditions. In summary, 310 even though "optical reachability table" is fairly static, which 311 regen free paths to build the connectivity matrix between any source 312 and destination is very dynamic, and is done using very 313 sophisticated routing algorithms. 315 There is therefore the need to keep the information in the 316 "connectivity matrix" updated which means that there another 317 tradeoff between the accuracy (i.e., providing "all" the information 318 that might be needed by the Orchestrator's PCE) and having up-to- 319 date information. The more the information is provided and the 320 longer it takes to keep it up-to-date which increases the likelihood 321 that the Orchestrator's PCE computes paths using not updated 322 information. 324 It seems therefore quite challenging to have a "detailed abstract 325 connectivity matrix" that provides accurate, scalable and updated 326 information to allow the Orchestrator's PCE to take optimal 327 decisions by its own. 329 If the information in the "detailed abstract connectivity matrix" is 330 not complete/accurate, we can have the following drawbacks 331 considering for example the case in Figure 4: 333 o If only the VP1-VP4 path with available bandwidth of 2 Gb/s and 334 cost 50 is reported, the Orchestrator's PCE will fail to compute 335 a 5 Gb/s path between routers R1 and R2, although this would be 336 feasible; 338 o If only the VP1-VP4 path with available bandwidth of 10 Gb/s and 339 cost 60 is reported, the Orchestrator's PCE will compute, as 340 optimal, the 1 Gb/s path between R1 and R2 going through the VP2- 341 VP5 path within the Optical domain while the optimal path would 342 actually be the one going thought the VP1-VP4 sub-path (with cost 343 50) within the Optical domain. 345 Instead, using the approach proposed in this document, the 346 Orchestrator, when it needs to setup an end-to-end path, it can 347 request the Optical domain controller to compute a set of optimal 348 paths (e.g., for VP1-VP4 and VP2-VP5) and take decisions based on 349 the information received: 351 o When setting up a 5 Gb/s path between routers R1 and R2, the 352 Optical domain controller may report only the VP1-VP4 path as the 353 only feasible path: the Orchestrator can successfully setup the 354 end-to-end path passing though this Optical path; 356 o When setting up a 1 Gb/s path between routers R1 and R2, the 357 Optical domain controller (knowing that the path requires only 1 358 Gb/s) can report both the VP1-VP4 path, with cost 50, and the 359 VP2-VP5 path, with cost 65. The Orchestrator can then compute the 360 optimal path which is passing thought the VP1-VP4 sub-path (with 361 cost 50) within the Optical domain. 363 Considering the dynamicity of the connectivity constraints of an 364 Optical domain, it is possible that a path computed by the Optical 365 domain controller when requested by the Orchestrator is no longer 366 valid when the Orchestrator requests it to be setup up. 368 It is worth noting that with the approach proposed in this document, 369 the likelihood for this issue to happen can be quite small since the 370 time window between the path computation request and the path setup 371 request should be quite short (especially if compared with the time 372 that would be needed to update the information of a very detailed 373 abstract connectivity matrix). 375 If this risk is still not acceptable, the Orchestrator may also 376 optionally request the Optical domain controller not only to compute 377 the path but also to keep track of its resources (e.g., these 378 resources can be reserved to avoid being used by any other 379 connection). In this case, some mechanism (e.g., a timeout) needs to 380 be defined to avoid having stranded resources within the Optical 381 domain. 383 These issues and solutions can be fine-tuned during the design of 384 the Path Computation API. 386 2.1.2. Route Diverse IP Services 388 This is for further study. 390 2.2. Multi-domain Optical Networks 392 In this use case there are two optical domains which are 393 interconnected together by multiple inter-domains links. 395 -------------------------------------------------------------------- 396 I I 397 I I 398 I I 399 I I 400 I I 401 I I 402 I Multi-domain multi-link interconnection I 403 I I 404 I I 405 I I 406 I I 407 I (only in PDF version) I 408 I I 409 I I 410 I I 411 I I 412 I I 413 I I 414 -------------------------------------------------------------------- 416 Figure 5 - Multi-domain multi-link interconnection 418 In order to setup an end-to-end multi-domain Optical path (e.g., 419 between nodes A and H), the orchestrator needs to know the 420 feasibility or the cost of the possible optical paths within the two 421 optical domains, which depend from the current status of the 422 physical resources within each optical network and on vendor- 423 specific optical attributes (which may be different in the two 424 domains if they are provided by different vendors). 426 There is a trade-off between having the Orchestrator's PCE being 427 able to take path computation decisions by its own versus having the 428 Orchestrator being able to ask the Domain Controllers to provide a 429 set of feasible optimal optical paths. 431 Orchestrator could want to select/optimize end-to-end path based on 432 abstract topology information provided by the domain controllers. 433 For example: 435 o Need to compute a path between A and H 437 o That path can go through inter-domain link C-E or through inter- 438 domain link D-F 440 o Orchestrator's PCE, based on its own information, can compute the 441 optimal multi-domain path being A-B-C-E-G-H 443 o But, during path setup, the domain controller may find out that 444 A-B-C is not optically feasible, while only the path A-B-D is 445 feasible 447 o So what the hierarchical controller computed is not good and need 448 to re-start the path computation from scratch 450 As discussed in section 3.1, providing more extensive abstract 451 information from the Optical domain controllers to the multi-domain 452 Orchestator may lead to scalability problems. 454 Alternatively the Orchestrator can request the Optical domain 455 controllers to compute a set of optimal paths and take decisions 456 based on the information received. For example: 458 o Need to compute a path between A and H 460 o The Orchestrator asks Optical domain controllers to provide set 461 of paths between A-C, A-D, E-H and F-H 463 o Optical domain controllers return a set of feasible paths with 464 the associated costs: the path A-C would not be part of this set 466 o The Orchestrator will select the path A-B-D-F-G-H since it is the 467 only feasible path and then request the Optical domain 468 controllers to setup the A-B-D and F-G-H paths 470 o If there are multiple feasible paths, the Orchestrator can select 471 the optimal path knowing the cost of the intra-domain paths 472 (provided by the Optical domain controllers) and the cost of the 473 inter-domain links (known by the Orchestrator) 475 In a sense this is similar to the problem of routing and wavelength 476 assignment within an Optical domain. It is possible to do first 477 routing (step 1) and then wavelength assignment (step 2), but the 478 chances of ending up with a good path is low. Alternatively, it is 479 possible to do combined routing and wavelength assignment, which is 480 known to be a more optimal and effective way for Optical path setup. 481 Similarly, it is possible to first compute an abstract end-to-end 482 path within the multi-domain Orchestrator (step 1) and then compute 483 an intra-domain path within each Optical domain (step 2), but there 484 are more chances not to find a path or to get a suboptimal path that 485 performing per-domain path computation and then stitch them. 487 The approach to request each Optical domain controllers to compute a 488 set of optimal paths and take decisions based on the information 489 received may still have some scalability issues when the number of 490 Optical domains is quite big (e.g. 20). 492 In this case, it would be worthwhile combining the two approaches and 493 use the abstract topology information provided by the domain 494 controllers to limit the number of potential optimal end-to-end paths 495 and then the Path Computation to decide what is the optimal path 496 within this limited set. 498 -------------------------------------------------------------------- 499 I I 500 I I 501 I I 502 I Multi-domain with many domains I 503 I (Topology information) I 504 I I 505 I I 506 I (only in PDF version) I 507 I I 508 I I 509 I I 510 -------------------------------------------------------------------- 512 Figure 6 - Multi-domain with many domains (Topology information) 514 An example can be described considering multi-domain abstract 515 topology shown in Figure 6. In this example an end-to-end Optical 516 path between domains A and F needs to be setup. The transit domain 517 should be selected between domains B, C, D and E. 519 The actual cost of each intra-domain path is not known a priori from 520 the abstract topology information. The Orchestrator only knows the 521 feasibility of some intra-domain paths and some upper-bound and/or 522 lower-bound cost information. With this information, together with 523 the cost of inter-domain links, the Orchestrator can decide that: 525 o Domain B cannot be selected as the path connecting domains A and 526 E is not feasible; 528 o Domain E cannot be selected as a transit domain since it is know 529 from the abstract topology information provided by domain 530 controllers that the cost of the multi-domain path A-E-F (which 531 is 100, in the best case) will be always be higher than the cost 532 of the multi-domain paths A-D-F (which is 90, in the worst case) 533 and A-E-F (which is 80, in the worst case) 535 Therefore, the Orchestrator can decide by its own that the optimal 536 multi-domain path could be either A-D-F or A-E-F. 538 The Orchestrator can therefore request only the Optical domain 539 controllers A, D, E and F to provide a set of optimal paths. 541 -------------------------------------------------------------------- 542 I I 543 I I 544 I I 545 I Multi-domain with many domains I 546 I (Path Computation information) I 547 I I 548 I I 549 I (only in PDF version) I 550 I I 551 I I 552 I I 553 -------------------------------------------------------------------- 555 Figure 7 - Multi-domain with many domains (Path Computation 556 information) 558 Based on these requests, the Orchestrator can know the actual cost 559 of each intra-domain paths which belongs to potential optimal end- 560 to-end paths, as shown in Figure 7, and then compute the optimal 561 end-to-end path (e.g., A-D-F, having total cost of 50, instead of A- 562 C-F having a total cost of 70). 564 2.3. Data center interconnections 566 In these use case, there is an Optical domain which is used to 567 provide connectivity between data centers which are connected with 568 the Optical domains using access links. 570 -------------------------------------------------------------------- 571 I I 572 I I 573 I I 574 I I 575 I I 576 I I 577 I Data Center Interconnection Use Case I 578 I I 579 I I 580 I I 581 I (only in PDF version) I 582 I I 583 I I 584 I I 585 I I 586 I I 587 I I 588 -------------------------------------------------------------------- 590 Figure 8 - Data Center Interconnection Use Case 592 In this use case, a virtual machine within Data Center 1 (DC1) needs 593 to transfer data to another virtual machine that can reside either 594 in DC2 or in DC3. 596 The optimal decision depends both on the cost of the optical path 597 (DC1-DC2 or DC1-DC3) and of the computing power (data center 598 resources) within DC2 or DC3. 600 The Cloud Orchestrator may not be able to make this decision because 601 it has only an abstract view of the optical network (as in use case 602 in 3.1). 604 The cloud orchestrator can request to the Optical domain controller 605 to compute the cost of the possible optical paths (e.g., DC1-DC2 and 606 DC1-DC3) and to the DC controller to compute the cost of the 607 computing power (DC resources) within DC2 and DC3 and then it can 608 take the decision about the optimal solution based on this 609 information and its policy. 611 3. Security Considerations 613 This is for further study 615 4. IANA Considerations 617 This document requires no IANA actions. 619 5. References 621 5.1. Normative References 623 [RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment 624 Information Model for Wavelength Switched Optical 625 Networks", RFC 7446, February 2015. 627 5.2. Informative References 629 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 630 draft-ietf-teas-yang-te-topo, work in progress. 632 [L1-TOPO] Zhang, X. et al., "A YANG Data Model for Layer 1 (ODU) 633 Network Topology", draft-zhang-ccamp-l1-topo-yang, work in 634 progress. 636 [TE-TUNNEL] Xhang, X. et al., "A YANG Data Model for Traffic 637 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 638 te, work in progress. 640 [TE-INTERCONNECT] Farrel, A. et al., "Problem Statement and 641 Architecture for Information Exchange Between 642 Interconnected Traffic Engineered Networks", draft-ietf- 643 teas-interconnected-te-info-exchange, work in progress. 645 6. Acknowledgments 647 The authors would like to thank Igor Bryskin and Xian Zhang for 648 participating in discussions and providing valuable insights. 650 This document was prepared using 2-Word-v2.0.template.dot. 652 Contributors 654 Dieter Beller 655 Nokia 656 Email: dieter.beller@nokia.com 658 Authors' Addresses 660 Italo Busi 661 Huawei 662 Email: italo.busi@huawei.com 664 Sergio Belotti 665 Nokia 666 Email: sergio.belotti@nokia.com 668 Victor Lopez 669 Telefonica 670 Email: victor.lopezalvarez@telefonica.com 672 Oscar Gonzalez de Dios 673 Telefonica 674 Email: oscar.gonzalezdedios@telefonica.com 676 Anurag Sharma 677 Infinera 678 Email: AnSharma@infinera.com 680 Yan Shi 681 China Unicom 682 Email: shiyan49@chinaunicom.cn 684 Ricard Vilalta 685 CTTC 686 Email: ricard.vilalta@cttc.es 687 Karthik Sethuraman 688 NEC 689 Email: karthik.sethuraman@necam.com