idnits 2.17.1 draft-busibel-teas-yang-path-computation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 119 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 344 has weird spacing: '...ach may have ...' == Line 512 has weird spacing: '...ination is ve...' == Line 836 has weird spacing: '...ro name str...' == Line 847 has weird spacing: '...ro name str...' == Line 892 has weird spacing: '...clusive enu...' == (13 more instances...) -- The document date (November 15, 2016) is 2718 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7491' is mentioned on line 115, but not defined == Missing Reference: 'ACTN-frame' is mentioned on line 118, but not defined == Missing Reference: 'RFC 7926' is mentioned on line 437, but not defined == Unused Reference: 'ACTN-Frame' is defined on line 1699, but no explicit reference was found in the text == Unused Reference: 'ACTN-Info' is defined on line 1703, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Italo Busi 2 Internet Draft Huawei 3 Intended status: Informational Sergio Belotti 4 Expires: May 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 November 15, 2016 19 Yang model for requesting Path Computation 20 draft-busibel-teas-yang-path-computation-01.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 May 15, 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 protocols (e.g., 70 NETCONF or RESTCONF). 72 This document describes some use cases for a YANG model to request 73 path computation. 75 Table of Contents 77 1. Introduction...................................................3 78 2. Use Cases......................................................4 79 2.1. IP-Optical integration....................................4 80 2.1.1. Inter-layer path computation.........................6 81 2.1.2. Route Diverse IP Services............................8 82 2.2. Multi-domain TE Networks..................................8 83 2.3. Data center interconnections..............................9 84 3. Interactions with TE Topology.................................11 85 3.1. TE Topology Aggregation using the "virtual link model"...11 86 3.2. TE Topology Abstraction..................................14 87 3.3. Complementary use of TE topology and path computation....15 88 4. Motivation for a YANG Model...................................17 89 4.1. Benefits of common data models...........................17 90 4.2. Benefits of a single interface...........................18 91 4.3. Extensibility............................................19 92 5. Path Optimization Request.....................................19 93 6. YANG Model for requesting Path Computation....................19 94 6.1. YANG model for stateless TE path computation.............20 95 6.1.1. YANG Tree...........................................20 96 6.1.2. YANG Module.........................................33 97 7. Security Considerations.......................................42 98 8. IANA Considerations...........................................42 99 9. References....................................................42 100 9.1. Normative References.....................................42 101 9.2. Informative References...................................42 102 10. Acknowledgments..............................................43 104 1. Introduction 106 There are scenarios, typically in a hierarchical SDN context, in 107 which an orchestrator may not have detailed information to be able 108 to perform an end-to-end path computation and would need to request 109 lower layer/domain controllers to calculate some (partial) feasible 110 paths. 112 When we are thinking to this type of scenarios we have in mind 113 specific level of interfaces on which this request can be applied. 115 We can reference ABNO Control Interface [RFC7491] in which an 116 Application Service Coordinator can request ABNO controller to take 117 in charge path calculation (see Figure 1 in the RFC) and/or ACTN 118 [ACTN-frame],where controller hierarchy is defined, the need for 119 path computation arises on both interfaces CMI (interface between 120 Customer Network Controller(CNC) and Multi Domain Service 121 Coordinator (MDSC)) and/or MPI (interface between MSDC-PNC).[ACTN- 122 Info] describes an information model for the Path Computation 123 request. 125 Multiple protocol solutions can be used for communication between 126 different controller hierarchical levels. This document assumes that 127 the controllers are communicating using YANG-based protocols (e.g., 128 NETCONF or RESTCONF). 130 Path Computation Elements, Controllers and Orchestrators perform 131 their operations based on Traffic Engineering Databases (TED). Such 132 TEDs can be described, in a technology agnostic way, with the YANG 133 Data Model for TE Topologies [TE-TOPO]. Furthermore, the technology 134 specific details of the TED are modeled in the augmented TE topology 135 models (e.g. [L1-TOPO] for Layer-1 ODU technologies). 137 The availability of such topology models allows providing the TED 138 using YANG-based protocols (e.g., NETCONF or RESTCONF). Furthermore, 139 it enables a PCE/Controller performing the necessary abstractions or 140 modifications and offering this customized topology to another 141 PCE/Controller or high level orchestrator. 143 The tunnels that can be provided over the networks described with 144 the topology models can be also set-up, deleted and modified via 145 YANG-based protocols (e.g., NETCONF or RESTCONF)using the TE-Tunnel 146 Yang model [TE-TUNNEL]. 148 This document describes some use cases where a path computation 149 request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can 150 be needed. 152 2. Use Cases 154 This section presents different use cases, where an orchestrator 155 needs to request underlying SDN controllers for path computation. 157 The presented uses cases have been grouped, depending on the 158 different underlying topologies: a) IP-Optical integration; b) 159 Multi-domain Traffic Engineered (TE) Networks; and c) Data center 160 interconnections. 162 2.1. IP-Optical integration 164 In these use cases, an Optical domain is used to provide 165 connectivity between IP routers which are connected with the Optical 166 domains using access links (see Figure 1). 168 -------------------------------------------------------------------- 169 I I 170 I I 171 I I 172 I IP+Optical Use Cases I 173 I I 174 I I 175 I I 176 I I 177 I (only in PDF version) I 178 I I 179 I I 180 I I 181 I I 182 I I 183 I I 184 I I 185 -------------------------------------------------------------------- 187 Figure 1 - IP+Optical Use Cases 189 It is assumed that the Optical domain controller provides to the 190 orchestrator an abstracted view of the Optical network. A possible 191 abstraction shall be representing the optical domain as one "virtual 192 node" with "virtual ports" connected to the access links. 194 The path computation request helps the orchestrator to know which 195 are the real connections that can be provided at the optical domain. 197 -------------------------------------------------------------------- 198 I I 199 I I 200 I I 201 I I 202 I I 203 I IP+Optical Topology Abstraction I 204 I I 205 I I 206 I I 207 I I 208 I (only in PDF version) I 209 I I 210 I I 211 I I 212 I I 213 I I 214 I I 215 -------------------------------------------------------------------- 217 Figure 2 - IP+Optical Topology Abstraction 219 2.1.1. Inter-layer path computation 221 In this use case, the orchestrator needs to setup an optimal path 222 between two IP routers R1 and R2. 224 As depicted in Figure 2, the Orchestrator has only an "abstracted 225 view" of the physical network, and it does not know the feasibility 226 or the cost of the possible optical paths (e.g., VP1-VP4 and VP2- 227 VP5), which depend from the current status of the physical resources 228 within the optical network and on vendor-specific optical 229 attributes. 231 The orchestrator can request the underlying Optical domain 232 controller to compute a set of potential optimal paths, taking into 233 account optical constraints. Then, based on its own constraints, 234 policy and knowledge (e.g. cost of the access links), it can choose 235 which one of these potential paths to use to setup the optimal e2e 236 path crossing optical network. 238 -------------------------------------------------------------------- 239 I I 240 I IP+Optical Path Computation Example I 241 I I 242 I I 243 I (only in PDF version) I 244 I I 245 -------------------------------------------------------------------- 247 Figure 3 - IP+Optical Path Computation Example 249 For example, in Figure 3, the Orchestrator can request the Optical 250 domain controller to compute the paths between VP1-VP4 and VP2-VP5 251 and then decide to setup the optimal end-to-end path using the VP2- 252 VP5 Optical path even this is not the optimal path from the Optical 253 domain perspective. 255 Considering the dynamicity of the connectivity constraints of an 256 Optical domain, it is possible that a path computed by the Optical 257 domain controller when requested by the Orchestrator is no longer 258 valid when the Orchestrator requests it to be setup up. 260 It is worth noting that with the approach proposed in this document, 261 the likelihood for this issue to happen can be quite small since the 262 time window between the path computation request and the path setup 263 request should be quite short (especially if compared with the time 264 that would be needed to update the information of a very detailed 265 abstract connectivity matrix). 267 If this risk is still not acceptable, the Orchestrator may also 268 optionally request the Optical domain controller not only to compute 269 the path but also to keep track of its resources (e.g., these 270 resources can be reserved to avoid being used by any other 271 connection). In this case, some mechanism (e.g., a timeout) needs to 272 be defined to avoid having stranded resources within the Optical 273 domain. 275 These issues and solutions can be fine-tuned during the design of 276 the YANG model for requesting Path Computation. 278 2.1.2. Route Diverse IP Services 280 This is for further study. 282 2.2. Multi-domain TE Networks 284 In this use case there are two TE domains which are interconnected 285 together by multiple inter-domains links. 287 A possible example could be a multi-domain optical network. 289 -------------------------------------------------------------------- 290 I I 291 I I 292 I I 293 I I 294 I I 295 I I 296 I Multi-domain multi-link interconnection I 297 I I 298 I I 299 I I 300 I I 301 I (only in PDF version) I 302 I I 303 I I 304 I I 305 I I 306 I I 307 I I 308 -------------------------------------------------------------------- 310 Figure 4 - Multi-domain multi-link interconnection 312 In order to setup an end-to-end multi-domain TEpath (e.g., between 313 nodes A and H), the orchestrator needs to know the feasibility or 314 the cost of the possible TE paths within the two TE domains, which 315 depend from the current status of the physical resources within each 316 TE network. This is more challenging in case of optical networks 317 because the optimal paths depend also on vendor-specific optical 318 attributes (which may be different in the two domains if they are 319 provided by different vendors). 321 In order to setup a multi-domain TE path (e.g., between nodes A and 322 H), Orchestrator can request the TE domain controllers to compute a 323 set of intra-domain optimal paths and take decisions based on the 324 information received. For example: 326 o The Orchestrator asks TE domain controllers to provide set of 327 paths between A-C, A-D, E-H and F-H 329 o TE domain controllers return a set of feasible paths with the 330 associated costs: the path A-C is not part of this set(in optical 331 networks, it is typical to have some paths not being feasible due 332 to optical constraints that are known only by the optical domain 333 controller) 335 o The Orchestrator will select the path A- D-F- H since it is the 336 only feasible multi-domain path and then request the TE domain 337 controllers to setup the A-D and F-H intra-domain paths 339 o If there are multiple feasible paths, the Orchestrator can select 340 the optimal path knowing the cost of the intra-domain paths 341 (provided by the TE domain controllers) and the cost of the 342 inter-domain links (known by the Orchestrator) 344 This approach may have some scalability issues when the number of TE 345 domains is quite big (e.g. 20). 347 In this case, it would be worthwhile using the abstract TE topology 348 information provided by the domain controllers to limit the number of 349 potential optimal end-to-end paths and then request path computation 350 to fewer domain controllers in order to decide what the optimal path 351 within this limited set is. 353 For more details, see section 3.3. 355 2.3. Data center interconnections 357 In these use case, there is an TE domain which is used to provide 358 connectivity between data centers which are connected with the TE 359 domain using access links. 361 -------------------------------------------------------------------- 362 I I 363 I I 364 I I 365 I I 366 I I 367 I I 368 I Data Center Interconnection Use Case I 369 I I 370 I I 371 I I 372 I (only in PDF version) I 373 I I 374 I I 375 I I 376 I I 377 I I 378 I I 379 -------------------------------------------------------------------- 381 Figure 5 - Data Center Interconnection Use Case 383 In this use case, a virtual machine within Data Center 1 (DC1) needs 384 to transfer data to another virtual machine that can reside either 385 in DC2 or in DC3. 387 The optimal decision depends both on the cost of the TE path (DC1- 388 DC2 or DC1-DC3) and of the computing power (data center resources) 389 within DC2 or DC3. 391 The Cloud Orchestrator may not be able to make this decision because 392 it has only an abstract view of the TE network (as in use case in 393 2.1). 395 The cloud orchestrator can request to the TE domain controller to 396 compute the cost of the possible TE paths (e.g., DC1-DC2 and DC1- 397 DC3) and to the DC controller to compute the cost of the computing 398 power (DC resources) within DC2 and DC3 and then it can take the 399 decision about the optimal solution based on this information and 400 its policy. 402 3. Interactions with TE Topology 404 The use cases described in section 2 have been described assuming 405 that the topology view exported by each underlying SDN controller to 406 the orchestrator is aggregated using the "virtual node model", 407 defined in [RFC7926]. 409 TE Topology information, e.g., as provided by [TE-TOPO], could in 410 theory be used by an underlying SDN controllers to provide TE 411 information to the orchestrator thus allowing the Path Computation 412 Element (PCE) within the Orchestrator to perform multi-domain path 413 computation by its own, without requesting path computations to the 414 underlying SDN controllers. 416 This section analyzes the need for an orchestrator to request 417 underlying SDN controllers for path computation even in these 418 scenarios as well as how the TE Topology information and the path 419 computation can be complementary. 421 In nutshell, there is a scalability trade-off between providing all 422 the TE information needed by the Orchestrator's PCE to take optimal 423 path computation decisions by its own versus requesting the 424 Orchestrator to ask to too many underlying SDN Domain Controllers a 425 set of feasible optimal intra-domain TE paths. 427 3.1. TE Topology Aggregation using the "virtual link model" 429 Using the TE Topology model, as defined in [TE-TOPO], the underlying 430 SDN controller can export the whole TE domain as a single abstract 431 TE node with a "detailed connectivity matrix", which extends the 432 "connectivity matrix", defined in [RFC7446], with specific TE 433 attributes (e.g., delay, SRLGs and summary TE metrics). 435 The information provided by the "detailed abstract connectivity 436 matrix" would be equivalent to the information that should be 437 provided by "virtual link model" as defined in [RFC 7926]. 439 For example, in the IP-Optical integration use case, described in 440 section 2.1, the Optical domain controller can make the information 441 shown in Figure 3 available to the Orchestrator as part of the TE 442 Topology information and the Orchestrator could use this information 443 to calculate by its own the optimal path between routers R1 and R2, 444 without requesting any additional information to the Optical Domain 445 Controller. 447 However, there is a tradeoff between the accuracy (i.e., providing 448 "all" the information that might be needed by the Orchestrator's 449 PCE) and scalability to be considered when designing the amount of 450 information to provide within the "detailed abstract connectivity 451 matrix". 453 Figure 6 below shows another example, similar to Figure 3, where 454 there are two possible Optical paths between VP1 and VP4 with 455 different properties (e.g., available bandwidth and cost). 457 -------------------------------------------------------------------- 458 I I 459 I IP+Optical Path Computation Example I 460 I with multiple choices I 461 I I 462 I I 463 I (only in PDF version) I 464 I I 465 -------------------------------------------------------------------- 467 Figure 6 - IP+Optical Path Computation Example with multiple choices 469 Reporting all the information, as in Figure 6, using the "detailed 470 abstract connectivity matrix", is quite challenging from a 471 scalability perspective. The amount of this information is not just 472 based on number of end points (which would scale as N-square), but 473 also on many other parameters, including client rate, user 474 constraints / policies for the service, e.g. max latency < N ms, max 475 cost, etc., exclusion policies to route around busy links, min OSNR 476 margin, max preFEC BER etc. All these constraints could be different 477 based on connectivity requirements. 479 It is also worth noting that the "connectivity matrix" has been 480 originally defined in WSON, [RFC7446] to report the connectivity 481 constrains of a physical node within the WDM network: the 482 information it contains is pretty "static" and therefore, once taken 483 and stored in the TE data base, it can be always being considered 484 valid and up-to-date in path computation request. 486 Using the "connectivity matrix" with an abstract node to abstract 487 the information regarding the connectivity constraints of an Optical 488 domain, would make this information more "dynamic" since the 489 connectivity constraints of an Optical domain can change over time 490 because some optical paths that are feasible at a given time may 491 become unfeasible at a later time when e.g., another optical path is 492 established. The information in the "detailed abstract connectivity 493 matrix" is even more dynamic since the establishment of another 494 optical path may change some of the parameters (e.g., delay or 495 available bandwidth) in the "detailed abstract connectivity matrix" 496 while not changing the feasibility of the path. 498 "Connectivity matrix" is sometimes confused with optical reach table 499 that contain multiple (e.g. k-shortest) regen-free reachable paths 500 for every A-Z node combination in the network. Optical reach tables 501 can be calculated offline, utilizing vendor optical design and 502 planning tools,and periodically uploaded to the Controller: these 503 optical path reach tables are fairly static. However, to get the 504 connectivity matrix, between any two sites, either a regen free path 505 can be used, if one is available, or multiple regen free paths are 506 concatenated to get from src to dest, which can be a very large 507 combination. Additionally, when the optical path within optical 508 domain needs to be computed, it can result in different paths based 509 on input objective, constraints, and network conditions. In summary, 510 even though "optical reachability table" is fairly static, which 511 regen free paths to build the connectivity matrix between any source 512 and destination is very dynamic, and is done using very 513 sophisticated routing algorithms. 515 There is therefore the need to keep the information in the 516 "connectivity matrix" updated which means that there another 517 tradeoff between the accuracy (i.e., providing "all" the information 518 that might be needed by the Orchestrator's PCE) and having up-to- 519 date information. The more the information is provided and the 520 longer it takes to keep it up-to-date which increases the likelihood 521 that the Orchestrator's PCE computes paths using not updated 522 information. 524 It seems therefore quite challenging to have a "detailed abstract 525 connectivity matrix" that provides accurate, scalable and updated 526 information to allow the Orchestrator's PCE to take optimal 527 decisions by its own. 529 If the information in the "detailed abstract connectivity matrix" is 530 not complete/accurate, we can have the following drawbacks 531 considering for example the case in Figure 6: 533 o If only the VP1-VP4 path with available bandwidth of 2 Gb/s and 534 cost 50 is reported, the Orchestrator's PCE will fail to compute 535 a 5 Gb/s path between routers R1 and R2, although this would be 536 feasible; 538 o If only the VP1-VP4 path with available bandwidth of 10 Gb/s and 539 cost 60 is reported, the Orchestrator's PCE will compute, as 540 optimal, the 1 Gb/s path between R1 and R2 going through the VP2- 541 VP5 path within the Optical domain while the optimal path would 542 actually be the one going thought the VP1-VP4 sub-path (with cost 543 50) within the Optical domain. 545 Instead, using the approach proposed in this document, the 546 Orchestrator, when it needs to setup an end-to-end path, it can 547 request the Optical domain controller to compute a set of optimal 548 paths (e.g., for VP1-VP4 and VP2-VP5) and take decisions based on 549 the information received: 551 o When setting up a 5 Gb/s path between routers R1 and R2, the 552 Optical domain controller may report only the VP1-VP4 path as the 553 only feasible path: the Orchestrator can successfully setup the 554 end-to-end path passing though this Optical path; 556 o When setting up a 1 Gb/s path between routers R1 and R2, the 557 Optical domain controller (knowing that the path requires only 1 558 Gb/s) can report both the VP1-VP4 path, with cost 50, and the 559 VP2-VP5 path, with cost 65. The Orchestrator can then compute the 560 optimal path which is passing thought the VP1-VP4 sub-path (with 561 cost 50) within the Optical domain. 563 3.2. TE Topology Abstraction 565 Using the TE Topology model, as defined in [TE-TOPO], the underlying 566 SDN controller can export an abstract TE Topology, composed by a set 567 of TE nodes and TE links, which are abstracting the topology 568 controlled by each domain controller. 570 Considering the example in Figure 4, the TE domain controller 1 can 571 export a TE Topology encompassing the TE nodes A, B, C and D and the 572 TE Link interconnecting them. In a similar way, TE domain controller 573 2 can export a TE Topology encompassing the TE nodes E, F, G and H 574 and the TE Link interconnecting them. 576 In this example, for simplicity reasons, each abstract TE node maps 577 with each physical node, but this is not necessary. 579 In order to setup a multi-domain TE path (e.g., between nodes A and 580 H), the Orchestrator can compute by its own an optimal end-to-end 581 path based on the abstract TE topology information provided by the 582 domain controllers. For example: 584 o Orchestrator's PCE, based on its own information, can compute the 585 optimal multi-domain path being A-B-C-E-G-H, and then request the 586 TE domain controllers to setup the A-B-C and E-G-H intra-domain 587 paths 589 o But, during path setup, the domain controller may find out that 590 A-B-C intra-domain path is not feasible (as discussed in section 591 2.2, in optical networks it is typical to have some paths not 592 being feasible due to optical constraints that are known only by 593 the optical domain controller), while only the path A-B-D is 594 feasible 596 o So what the hierarchical controller computed is not good and need 597 to re-start the path computation from scratch 599 As discussed in section 3.1, providing more extensive abstract 600 information from the TE domain controllers to the multi-domain 601 Orchestator may lead to scalability problems. 603 In a sense this is similar to the problem of routing and wavelength 604 assignment within an Optical domain. It is possible to do first 605 routing (step 1) and then wavelength assignment (step 2), but the 606 chances of ending up with a good path is low. Alternatively, it is 607 possible to do combined routing and wavelength assignment, which is 608 known to be a more optimal and effective way for Optical path setup. 609 Similarly, it is possible to first compute an abstract end-to-end 610 path within the multi-domain Orchestrator (step 1) and then compute 611 an intra-domain path within each Optical domain (step 2), but there 612 are more chances not to find a path or to get a suboptimal path that 613 performing per-domain path computation and then stitch them. 615 3.3. Complementary use of TE topology and path computation 617 As discussed in section 2.2, there are some scalability issues with 618 path computation requests in a multi-domain TE network with many TE 619 domains, in terms of the number of requests to send to the TE domain 620 controllers. It would therefore be worthwhile using the TE topology 621 information provided by the domain controllers to limit the number 622 of requests. 624 An example can be described considering the multi-domain abstract 625 topology shown in Figure 7. In this example, an end-to-end TE path 626 between domains A and F needs to be setup. The transit domain should 627 be selected between domains B, C, D and E. 629 -------------------------------------------------------------------- 630 I I 631 I I 632 I I 633 I Multi-domain with many domains I 634 I (Topology information) I 635 I I 636 I I 637 I (only in PDF version) I 638 I I 639 I I 640 I I 641 -------------------------------------------------------------------- 643 Figure 7 - Multi-domain with many domains (Topology information) 645 The actual cost of each intra-domain path is not known a priori from 646 the abstract topology information. The Orchestrator only knows, from 647 the TE topology provided by the underlying domain controllers, the 648 feasibility of some intra-domain paths and some upper-bound and/or 649 lower-bound cost information. With this information, together with 650 the cost of inter-domain links, the Orchestrator can understand by 651 its own that: 653 o Domain B cannot be selected as the path connecting domains A and 654 E is not feasible; 656 o Domain E cannot be selected as a transit domain since it is know 657 from the abstract topology information provided by domain 658 controllers that the cost of the multi-domain path A-E-F (which 659 is 100, in the best case) will be always be higher than the cost 660 of the multi-domain paths A-D-F (which is 90, in the worst case) 661 and A-E-F (which is 80, in the worst case) 663 Therefore, the Orchestrator can understand by its own that the 664 optimal multi-domain path could be either A-D-F or A-E-F but it 665 cannot known which one of the two possible option actually provides 666 the optimal end-to-end path. 668 The Orchestrator can therefore request path computation only to the 669 TE domain controllers A, D, E and F (and not to all the possible TE 670 domain controllers). 672 -------------------------------------------------------------------- 673 I I 674 I I 675 I I 676 I Multi-domain with many domains I 677 I (Path Computation information) I 678 I I 679 I I 680 I (only in PDF version) I 681 I I 682 I I 683 I I 684 -------------------------------------------------------------------- 686 Figure 8 - Multi-domain with many domains (Path Computation 687 information) 689 Based on these requests, the Orchestrator can know the actual cost 690 of each intra-domain paths which belongs to potential optimal end- 691 to-end paths, as shown in Figure 8, and then compute the optimal 692 end-to-end path (e.g., A-D-F, having total cost of 50, instead of A- 693 C-F having a total cost of 70). 695 4. Motivation for a YANG Model 697 4.1. Benefits of common data models 699 Path computation requests should be closely aligned with the YANG 700 data models that provide (abstract) TE topology information, i.e., 701 [TE-TOPO] as well as that are used to configure and manage TE 702 Tunnels, i.e., [TE-TUNNEL]. Otherwise, an error-prone mapping or 703 correlation of information would be required. For instance, there is 704 benefit in using the same endpoint identifiers in path computation 705 requests and in the topology modeling. Also, the attributes used in 706 path computation constraints could use the same or similar data 707 models. As a result, there are many benefits in aligning path 708 computation requests with YANG models for TE topology information 709 and TE Tunnels configuration and management. 711 4.2. Benefits of a single interface 713 A typical use case for path computation requests is the interface 714 between an orchestrator and a domain controller. The system 715 integration effort is typically lower if a single, consistent 716 interface is used between such systems, i.e., one data modeling 717 language (i.e., YANG) and a common protocol (e.g., NETCONF or 718 RESTCONF). 720 Practical benefits of using a single, consistent interface include: 722 1. Simple authentication and authorization: The interface between 723 different components has to be secured. If different protocols 724 have different security mechanisms, ensuring a common access 725 control model may result in overhead. For instance, there may 726 be a need to deal with different security mechanisms, e.g., 727 different credentials or keys. This can result in increased 728 integration effort. 729 2. Consistency: Keeping data consistent over multiple different 730 interfaces or protocols is not trivial. For instance, the 731 sequence of actions can matter in certain use cases, or 732 transaction semantics could be desired. While ensuring 733 consistency within one protocol can already be challenging, it 734 is typically cumbersome to achieve that across different 735 protocols. 736 3. Testing: System integration requires comprehensive testing, 737 including corner cases. The more different technologies are 738 involved, the more difficult it is to run comprehensive test 739 cases and ensure proper integration. 740 4. Middle-box friendliness: Provider and consumer of path 741 computation requests may be located in different networks, and 742 middle-boxes such as firewalls, NATs, or load balancers may be 743 deployed. In such environments it is simpler to deploy a single 744 protocol. Also, it may be easier to debug connectivity 745 problems. 746 5. Tooling reuse: Implementers may want to implement path 747 computation requests with tools and libraries that already 748 exist in controllers and/or orchestrators, e.g., leveraging the 749 rapidly growing eco-system for YANG tooling. 751 4.3. Extensibility 753 Path computation is only a subset of the typical functionality of a 754 controller. In many use cases, issuing path computation requests 755 comes along with the need to access other functionality on the same 756 system. In addition to obtaining TE topology, for instance also 757 configuration of services (setup/modification/deletion) may be 758 required, as well as: 760 1. Receiving notifications for topology changes as well as 761 integration with fault management 762 2. Performance management such as retrieving monitoring and 763 telemetry data 764 3. Service assurance, e.g., by triggering OAM functionality 765 4. Other fulfilment and provisioning actions beyond tunnels and 766 services, such as changing QoS configurations 768 YANG is a very extensible and flexible data modeling language that 769 can be used for all these use cases. 771 Adding support for path computation requests to YANG models would 772 seamlessly complement with [TE-TOPO] and [TE-TUNNEL] in the use 773 cases where YANG-based protocols (e.g., NETCONF or RESTCONF) are 774 used. 776 5. Path Optimization Request 778 This is for further study 780 6. YANG Model for requesting Path Computation 782 Work on extending the TE Tunnel YANG model to support the need to 783 request path computation has recently started also in the context of 784 the [TE-TUNNEL] draft. 786 It is possible to request path computation by configuring a 787 "compute-only" TE tunnel and retrieving the computed path(s) in the 788 LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL]. 790 This is a stateful solution since the state of each created 791 "compute-only" TE tunnel needs to be maintained and updated, when 792 underlying network conditions change. 794 The need also for a stateless solution, based on an RPC, has been 795 recognized: section 6.1 describes an initial proposal for a 796 stateless RPC to request path computation. 798 This is intended as an input for further evaluation and discussion 799 with the authors of [TE-TUNNEL] Internet-Draft and TEAS WG 800 participants, about the technical solution as well as whether this 801 RPC should be merged with the YANG model defined in [TE-TUNNEL]. 803 6.1. YANG model for stateless TE path computation 805 6.1.1. YANG Tree 807 Figure 9 below shows the tree diagram of the YANG model defined in 808 module ietf-te-path-computation.yang. 810 module: ietf-te-path-computation 811 +--ro path* [path-id] 812 | +--ro _telink* [link-ref] 813 | | +--ro link-ref -> /nd:networks/network[nd:network- 814 id=current()/../network-ref]/lnk:link/link-id 815 | | +--ro network-ref? -> /nd:networks/network/network-id 816 | +--ro _routingConstraint 817 | | +--ro requestedCapacity? decimal64 818 | | +--ro pathConstraints 819 | | | +--ro path-constraints 820 | | | +--ro topology-id? te-types:te-topology-id 821 | | | +--ro cost-limit? uint32 822 | | | +--ro hop-limit? uint8 823 | | | +--ro metric-type? identityref 824 | | | +--ro tiebreaker-type? identityref 825 | | | +--ro ignore-overload? boolean 826 | | | +--ro path-affinities {named-path-affinities}? 827 | | | | +--ro (style)? 828 | | | | +--:(values) 829 | | | | | +--ro value? uint32 830 | | | | | +--ro mask? uint32 831 | | | | +--:(named) 832 | | | | +--ro constraints* [usage] 833 | | | | +--ro usage identityref 834 | | | | +--ro constraint 835 | | | | +--ro affinity-names* [name] 836 | | | | +--ro name string 837 | | | +--ro path-srlgs 838 | | | +--ro (style)? 839 | | | +--:(values) 840 | | | | +--ro usage? identityref 841 | | | | +--ro values* te-types:srlg 842 | | | +--:(named) 843 | | | +--ro constraints* [usage] 844 | | | +--ro usage identityref 845 | | | +--ro constraint 846 | | | +--ro srlg-names* [name] 847 | | | +--ro name string 848 | | +--ro _avoidTopology 849 | | +--ro provider-ref? -> 850 /nw:networks/network[nw:network-id = current()/../network- 851 ref]/tet:provider-id 852 | | +--ro client-ref? -> 853 /nw:networks/network[nw:network-id = current()/../network- 854 ref]/tet:client-id 855 | | +--ro te-topology-ref? -> 856 /nw:networks/network[nw:network-id = current()/../network- 857 ref]/tet:te-topology-id 858 | | +--ro network-ref? -> 859 /nw:networks/network/network-id 860 | +--ro path-id yang-types:uuid 861 +--rw pathComputationService 862 +--ro _path-ref* -> /path/path-id 863 +--rw _servicePort 864 | +--ro src-tp-ref 865 | | +--ro tp-ref? -> 866 /nd:networks/network[nd:network-id=current()/../network- 867 ref]/node[nd:node-id=current()/../node-ref]/lnk:termination- 868 point/tp-id 869 | | +--ro node-ref? -> 870 /nd:networks/network[nd:network-id=current()/../network- 871 ref]/node/node-id 872 | | +--ro network-ref? -> /nd:networks/network/network-id 873 | +--ro dst-tp-ref 874 | | +--ro tp-ref? -> 875 /nd:networks/network[nd:network-id=current()/../network- 876 ref]/node[nd:node-id=current()/../node-ref]/lnk:termination- 877 point/tp-id 878 | | +--ro node-ref? -> 879 /nd:networks/network[nd:network-id=current()/../network- 880 ref]/node/node-id 881 | | +--ro network-ref? -> /nd:networks/network/network-id 882 | +--ro serviceLayer 883 | +--ro switching-capability? identityref 884 | +--ro encoding? identityref 885 | +--ro inter-layer-lock-id? uint32 886 | +--ro protection-type? identityref 887 | +--ro local-link-connectivity* [link-tp-ref] 888 | +--ro link-tp-ref -> 889 ../../../../../nt:termination-point/tp-id 890 | +--ro label-restriction* [inclusive-exclusive label- 891 start] 892 | | +--ro inclusive-exclusive enumeration 893 | | +--ro label-start te- 894 types:generalized-label 895 | | +--ro label-end? te- 896 types:generalized-label 897 | | +--ro range-bitmap? binary 898 | +--ro max-lsp-bandwidth* [priority] 899 | | +--ro priority uint8 900 | | +--ro bandwidth? te-bandwidth 901 | +--ro max-link-bandwidth? te-bandwidth 902 | +--ro max-resv-link-bandwidth? te-bandwidth 903 | +--ro unreserved-bandwidth* [priority] 904 | | +--ro priority uint8 905 | | +--ro bandwidth? te-bandwidth 906 | +--ro te-default-metric? uint32 907 | +--ro te-delay-metric? uint32 908 | +--ro te-srlgs 909 | +--ro value* te-types:srlg 910 +--rw _routingConstraint 911 | +--ro requestedCapacity? decimal64 912 | +--ro pathConstraints 913 | | +--ro path-constraints 914 | | +--ro topology-id? te-types:te-topology-id 915 | | +--ro cost-limit? uint32 916 | | +--ro hop-limit? uint8 917 | | +--ro metric-type? identityref 918 | | +--ro tiebreaker-type? identityref 919 | | +--ro ignore-overload? boolean 920 | | +--ro path-affinities {named-path-affinities}? 921 | | | +--ro (style)? 922 | | | +--:(values) 923 | | | | +--ro value? uint32 924 | | | | +--ro mask? uint32 925 | | | +--:(named) 926 | | | +--ro constraints* [usage] 927 | | | +--ro usage identityref 928 | | | +--ro constraint 929 | | | +--ro affinity-names* [name] 930 | | | +--ro name string 931 | | +--ro path-srlgs 932 | | +--ro (style)? 933 | | +--:(values) 934 | | | +--ro usage? identityref 935 | | | +--ro values* te-types:srlg 936 | | +--:(named) 937 | | +--ro constraints* [usage] 938 | | +--ro usage identityref 939 | | +--ro constraint 940 | | +--ro srlg-names* [name] 941 | | +--ro name string 942 | +--ro _avoidTopology 943 | +--ro provider-ref? -> 944 /nw:networks/network[nw:network-id = current()/../network- 945 ref]/tet:provider-id 946 | +--ro client-ref? -> 947 /nw:networks/network[nw:network-id = current()/../network- 948 ref]/tet:client-id 949 | +--ro te-topology-ref? -> 950 /nw:networks/network[nw:network-id = current()/../network- 951 ref]/tet:te-topology-id 952 | +--ro network-ref? -> 953 /nw:networks/network/network-id 954 +--rw _objectiveFunction 955 | +--ro objectiveFunction? ObjectiveFunction 956 +--rw _optimizationConstraint 957 +--ro trafficInterruption? DirectiveValue 959 rpcs: 960 +---x statelessComputeP2PPath 961 | +---w input 962 | | +---w servicePort* 963 | | | +---w src-tp-ref 964 | | | | +---w tp-ref? -> 965 /nd:networks/network[nd:network-id=current()/../network- 966 ref]/node[nd:node-id=current()/../node-ref]/lnk:termination- 967 point/tp-id 968 | | | | +---w node-ref? -> 969 /nd:networks/network[nd:network-id=current()/../network- 970 ref]/node/node-id 971 | | | | +---w network-ref? -> 972 /nd:networks/network/network-id 973 | | | +---w dst-tp-ref 974 | | | | +---w tp-ref? -> 975 /nd:networks/network[nd:network-id=current()/../network- 976 ref]/node[nd:node-id=current()/../node-ref]/lnk:termination- 977 point/tp-id 978 | | | | +---w node-ref? -> 979 /nd:networks/network[nd:network-id=current()/../network- 980 ref]/node/node-id 981 | | | | +---w network-ref? -> 982 /nd:networks/network/network-id 983 | | | +---w serviceLayer 984 | | | +---w switching-capability? identityref 985 | | | +---w encoding? identityref 986 | | | +---w inter-layer-lock-id? uint32 987 | | | +---w protection-type? identityref 988 | | | +---w local-link-connectivity* [link-tp-ref] 989 | | | +---w link-tp-ref -> 990 ../../../../../nt:termination-point/tp-id 991 | | | +---w label-restriction* [inclusive-exclusive 992 label-start] 993 | | | | +---w inclusive-exclusive enumeration 994 | | | | +---w label-start te- 995 types:generalized-label 996 | | | | +---w label-end? te- 997 types:generalized-label 998 | | | | +---w range-bitmap? binary 999 | | | +---w max-lsp-bandwidth* [priority] 1000 | | | | +---w priority uint8 1001 | | | | +---w bandwidth? te-bandwidth 1002 | | | +---w max-link-bandwidth? te-bandwidth 1003 | | | +---w max-resv-link-bandwidth? te-bandwidth 1004 | | | +---w unreserved-bandwidth* [priority] 1005 | | | | +---w priority uint8 1006 | | | | +---w bandwidth? te-bandwidth 1007 | | | +---w te-default-metric? uint32 1008 | | | +---w te-delay-metric? uint32 1009 | | | +---w te-srlgs 1010 | | | +---w value* te-types:srlg 1011 | | +---w routingConstraint 1012 | | | +---w requestedCapacity? decimal64 1013 | | | +---w pathConstraints 1014 | | | | +---w path-constraints 1015 | | | | +---w topology-id? te-types:te-topology-id 1016 | | | | +---w cost-limit? uint32 1017 | | | | +---w hop-limit? uint8 1018 | | | | +---w metric-type? identityref 1019 | | | | +---w tiebreaker-type? identityref 1020 | | | | +---w ignore-overload? boolean 1021 | | | | +---w path-affinities {named-path-affinities}? 1022 | | | | | +---w (style)? 1023 | | | | | +--:(values) 1024 | | | | | | +---w value? uint32 1025 | | | | | | +---w mask? uint32 1026 | | | | | +--:(named) 1027 | | | | | +---w constraints* [usage] 1028 | | | | | +---w usage identityref 1029 | | | | | +---w constraint 1030 | | | | | +---w affinity-names* [name] 1031 | | | | | +---w name string 1032 | | | | +---w path-srlgs 1033 | | | | +---w (style)? 1034 | | | | +--:(values) 1035 | | | | | +---w usage? identityref 1036 | | | | | +---w values* te-types:srlg 1037 | | | | +--:(named) 1038 | | | | +---w constraints* [usage] 1039 | | | | +---w usage identityref 1040 | | | | +---w constraint 1041 | | | | +---w srlg-names* [name] 1042 | | | | +---w name string 1043 | | | +---w _avoidTopology 1044 | | | +---w provider-ref? -> 1045 /nw:networks/network[nw:network-id = current()/../network- 1046 ref]/tet:provider-id 1047 | | | +---w client-ref? -> 1048 /nw:networks/network[nw:network-id = current()/../network- 1049 ref]/tet:client-id 1050 | | | +---w te-topology-ref? -> 1051 /nw:networks/network[nw:network-id = current()/../network- 1052 ref]/tet:te-topology-id 1053 | | | +---w network-ref? -> 1054 /nw:networks/network/network-id 1055 | | +---w objectiveFunction 1056 | | +---w objectiveFunction? ObjectiveFunction 1057 | +--ro output 1058 | +--ro pathCompService 1059 | +--ro _path-ref* -> /path/path-id 1060 | +--ro _servicePort 1061 | | +--ro src-tp-ref 1062 | | | +--ro tp-ref? -> 1063 /nd:networks/network[nd:network-id=current()/../network- 1064 ref]/node[nd:node-id=current()/../node-ref]/lnk:termination- 1065 point/tp-id 1066 | | | +--ro node-ref? -> 1067 /nd:networks/network[nd:network-id=current()/../network- 1068 ref]/node/node-id 1069 | | | +--ro network-ref? -> 1070 /nd:networks/network/network-id 1071 | | +--ro dst-tp-ref 1072 | | | +--ro tp-ref? -> 1073 /nd:networks/network[nd:network-id=current()/../network- 1074 ref]/node[nd:node-id=current()/../node-ref]/lnk:termination- 1075 point/tp-id 1076 | | | +--ro node-ref? -> 1077 /nd:networks/network[nd:network-id=current()/../network- 1078 ref]/node/node-id 1079 | | | +--ro network-ref? -> 1080 /nd:networks/network/network-id 1081 | | +--ro serviceLayer 1082 | | +--ro switching-capability? identityref 1083 | | +--ro encoding? identityref 1084 | | +--ro inter-layer-lock-id? uint32 1085 | | +--ro protection-type? identityref 1086 | | +--ro local-link-connectivity* [link-tp-ref] 1087 | | +--ro link-tp-ref -> 1088 ../../../../../nt:termination-point/tp-id 1089 | | +--ro label-restriction* [inclusive-exclusive 1090 label-start] 1091 | | | +--ro inclusive-exclusive enumeration 1092 | | | +--ro label-start te- 1093 types:generalized-label 1094 | | | +--ro label-end? te- 1095 types:generalized-label 1096 | | | +--ro range-bitmap? binary 1097 | | +--ro max-lsp-bandwidth* [priority] 1098 | | | +--ro priority uint8 1099 | | | +--ro bandwidth? te-bandwidth 1100 | | +--ro max-link-bandwidth? te-bandwidth 1101 | | +--ro max-resv-link-bandwidth? te-bandwidth 1102 | | +--ro unreserved-bandwidth* [priority] 1103 | | | +--ro priority uint8 1104 | | | +--ro bandwidth? te-bandwidth 1105 | | +--ro te-default-metric? uint32 1106 | | +--ro te-delay-metric? uint32 1107 | | +--ro te-srlgs 1108 | | +--ro value* te-types:srlg 1109 | +--ro _routingConstraint 1110 | | +--ro requestedCapacity? decimal64 1111 | | +--ro pathConstraints 1112 | | | +--ro path-constraints 1113 | | | +--ro topology-id? te-types:te-topology- 1114 id 1115 | | | +--ro cost-limit? uint32 1116 | | | +--ro hop-limit? uint8 1117 | | | +--ro metric-type? identityref 1118 | | | +--ro tiebreaker-type? identityref 1119 | | | +--ro ignore-overload? boolean 1120 | | | +--ro path-affinities {named-path-affinities}? 1121 | | | | +--ro (style)? 1122 | | | | +--:(values) 1123 | | | | | +--ro value? uint32 1124 | | | | | +--ro mask? uint32 1125 | | | | +--:(named) 1126 | | | | +--ro constraints* [usage] 1127 | | | | +--ro usage identityref 1128 | | | | +--ro constraint 1129 | | | | +--ro affinity-names* [name] 1130 | | | | +--ro name string 1131 | | | +--ro path-srlgs 1132 | | | +--ro (style)? 1133 | | | +--:(values) 1134 | | | | +--ro usage? identityref 1135 | | | | +--ro values* te-types:srlg 1136 | | | +--:(named) 1137 | | | +--ro constraints* [usage] 1138 | | | +--ro usage identityref 1139 | | | +--ro constraint 1140 | | | +--ro srlg-names* [name] 1141 | | | +--ro name string 1142 | | +--ro _avoidTopology 1143 | | +--ro provider-ref? -> 1144 /nw:networks/network[nw:network-id = current()/../network- 1145 ref]/tet:provider-id 1146 | | +--ro client-ref? -> 1147 /nw:networks/network[nw:network-id = current()/../network- 1148 ref]/tet:client-id 1149 | | +--ro te-topology-ref? -> 1150 /nw:networks/network[nw:network-id = current()/../network- 1151 ref]/tet:te-topology-id 1152 | | +--ro network-ref? -> 1153 /nw:networks/network/network-id 1154 | +--ro _objectiveFunction 1155 | | +--ro objectiveFunction? ObjectiveFunction 1156 | +--ro _optimizationConstraint 1157 | +--ro trafficInterruption? DirectiveValue 1158 +---x optimizeP2PPath 1159 +---w input 1160 | +---w pathIdOrName? string 1161 | +---w routingConstraint 1162 | | +---w requestedCapacity? decimal64 1163 | | +---w pathConstraints 1164 | | | +---w path-constraints 1165 | | | +---w topology-id? te-types:te-topology-id 1166 | | | +---w cost-limit? uint32 1167 | | | +---w hop-limit? uint8 1168 | | | +---w metric-type? identityref 1169 | | | +---w tiebreaker-type? identityref 1170 | | | +---w ignore-overload? boolean 1171 | | | +---w path-affinities {named-path-affinities}? 1172 | | | | +---w (style)? 1173 | | | | +--:(values) 1174 | | | | | +---w value? uint32 1175 | | | | | +---w mask? uint32 1176 | | | | +--:(named) 1177 | | | | +---w constraints* [usage] 1178 | | | | +---w usage identityref 1179 | | | | +---w constraint 1180 | | | | +---w affinity-names* [name] 1181 | | | | +---w name string 1182 | | | +---w path-srlgs 1183 | | | +---w (style)? 1184 | | | +--:(values) 1185 | | | | +---w usage? identityref 1186 | | | | +---w values* te-types:srlg 1187 | | | +--:(named) 1188 | | | +---w constraints* [usage] 1189 | | | +---w usage identityref 1190 | | | +---w constraint 1191 | | | +---w srlg-names* [name] 1192 | | | +---w name string 1193 | | +---w _avoidTopology 1194 | | +---w provider-ref? -> 1195 /nw:networks/network[nw:network-id = current()/../network- 1196 ref]/tet:provider-id 1197 | | +---w client-ref? -> 1198 /nw:networks/network[nw:network-id = current()/../network- 1199 ref]/tet:client-id 1200 | | +---w te-topology-ref? -> 1201 /nw:networks/network[nw:network-id = current()/../network- 1202 ref]/tet:te-topology-id 1203 | | +---w network-ref? -> 1204 /nw:networks/network/network-id 1205 | +---w optimizationConstraint 1206 | | +---w trafficInterruption? DirectiveValue 1207 | +---w objectiveFunction 1208 | +---w objectiveFunction? ObjectiveFunction 1209 +--ro output 1210 +--ro pathCompService 1211 +--ro _path-ref* -> /path/path-id 1212 +--ro _servicePort 1213 | +--ro src-tp-ref 1214 | | +--ro tp-ref? -> 1215 /nd:networks/network[nd:network-id=current()/../network- 1216 ref]/node[nd:node-id=current()/../node-ref]/lnk:termination- 1217 point/tp-id 1218 | | +--ro node-ref? -> 1219 /nd:networks/network[nd:network-id=current()/../network- 1220 ref]/node/node-id 1221 | | +--ro network-ref? -> 1222 /nd:networks/network/network-id 1223 | +--ro dst-tp-ref 1224 | | +--ro tp-ref? -> 1225 /nd:networks/network[nd:network-id=current()/../network- 1226 ref]/node[nd:node-id=current()/../node-ref]/lnk:termination- 1227 point/tp-id 1228 | | +--ro node-ref? -> 1229 /nd:networks/network[nd:network-id=current()/../network- 1230 ref]/node/node-id 1231 | | +--ro network-ref? -> 1232 /nd:networks/network/network-id 1233 | +--ro serviceLayer 1234 | +--ro switching-capability? identityref 1235 | +--ro encoding? identityref 1236 | +--ro inter-layer-lock-id? uint32 1237 | +--ro protection-type? identityref 1238 | +--ro local-link-connectivity* [link-tp-ref] 1239 | +--ro link-tp-ref -> 1240 ../../../../../nt:termination-point/tp-id 1241 | +--ro label-restriction* [inclusive-exclusive 1242 label-start] 1243 | | +--ro inclusive-exclusive enumeration 1244 | | +--ro label-start te- 1245 types:generalized-label 1246 | | +--ro label-end? te- 1247 types:generalized-label 1248 | | +--ro range-bitmap? binary 1249 | +--ro max-lsp-bandwidth* [priority] 1250 | | +--ro priority uint8 1251 | | +--ro bandwidth? te-bandwidth 1252 | +--ro max-link-bandwidth? te-bandwidth 1253 | +--ro max-resv-link-bandwidth? te-bandwidth 1254 | +--ro unreserved-bandwidth* [priority] 1255 | | +--ro priority uint8 1256 | | +--ro bandwidth? te-bandwidth 1257 | +--ro te-default-metric? uint32 1258 | +--ro te-delay-metric? uint32 1259 | +--ro te-srlgs 1260 | +--ro value* te-types:srlg 1261 +--ro _routingConstraint 1262 | +--ro requestedCapacity? decimal64 1263 | +--ro pathConstraints 1264 | | +--ro path-constraints 1265 | | +--ro topology-id? te-types:te-topology- 1266 id 1267 | | +--ro cost-limit? uint32 1268 | | +--ro hop-limit? uint8 1269 | | +--ro metric-type? identityref 1270 | | +--ro tiebreaker-type? identityref 1271 | | +--ro ignore-overload? boolean 1272 | | +--ro path-affinities {named-path-affinities}? 1273 | | | +--ro (style)? 1274 | | | +--:(values) 1275 | | | | +--ro value? uint32 1276 | | | | +--ro mask? uint32 1277 | | | +--:(named) 1278 | | | +--ro constraints* [usage] 1279 | | | +--ro usage identityref 1280 | | | +--ro constraint 1281 | | | +--ro affinity-names* [name] 1282 | | | +--ro name string 1283 | | +--ro path-srlgs 1284 | | +--ro (style)? 1285 | | +--:(values) 1286 | | | +--ro usage? identityref 1287 | | | +--ro values* te-types:srlg 1288 | | +--:(named) 1289 | | +--ro constraints* [usage] 1290 | | +--ro usage identityref 1291 | | +--ro constraint 1292 | | +--ro srlg-names* [name] 1293 | | +--ro name string 1294 | +--ro _avoidTopology 1295 | +--ro provider-ref? -> 1296 /nw:networks/network[nw:network-id = current()/../network- 1297 ref]/tet:provider-id 1298 | +--ro client-ref? -> 1299 /nw:networks/network[nw:network-id = current()/../network- 1300 ref]/tet:client-id 1301 | +--ro te-topology-ref? -> 1302 /nw:networks/network[nw:network-id = current()/../network- 1303 ref]/tet:te-topology-id 1304 | +--ro network-ref? -> 1305 /nw:networks/network/network-id 1306 +--ro _objectiveFunction 1307 | +--ro objectiveFunction? ObjectiveFunction 1308 +--ro _optimizationConstraint 1309 +--ro trafficInterruption? DirectiveValue 1311 Figure 9 - TE path computation tree 1313 6.1.2. YANG Module 1315 file " ietf-te-path-computation.yang " 1316 module ietf-te-path-computation { 1317 yang-version 1.1; 1318 namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation"; 1319 // replace with IANA namespace when assigned 1321 prefix "tepc"; 1323 import ietf-yang-types { 1324 prefix "yang-types"; 1325 } 1327 import ietf-te-types { 1328 prefix "te-types"; 1329 } 1331 import ietf-te-topology { 1332 prefix "tet"; 1333 } 1335 import ietf-network-topology { 1336 prefix "nt"; 1337 } 1338 organization 1339 "Traffic Engineering Architecture and Signaling (TEAS) 1340 Working Group"; 1342 contact 1343 "WG Web: 1344 WG List: 1346 WG Chair: Lou Berger 1347 1349 WG Chair: Vishnu Pavan Beeram 1350 1352 "; 1354 description "YANG model for stateless TE path computation"; 1356 revision "2016-10-10" { 1357 description "Initial revision"; 1358 reference "YANG model for stateless TE path computation"; 1359 } 1361 /* 1362 * Features 1363 */ 1365 feature stateless-path-computation { 1366 description 1367 "This feature indicates that the system supports 1368 stateless path computation."; 1369 } 1371 /* 1372 * Typedefs 1373 */ 1375 typedef DirectiveValue { 1376 type enumeration { 1377 enum MINIMIZE { 1378 description "Minimize directive."; 1379 } 1380 enum MAXIMIZE { 1381 description "Maximize directive."; 1382 } 1383 enum ALLOW { 1384 description "Allow directive."; 1385 } 1386 enum DISALLOW { 1387 description "Disallow directive."; 1388 } 1389 enum DONT_CARE { 1390 description "Don't care directive."; 1391 } 1392 } 1393 description "Value to determine optimization type."; 1394 } 1396 typedef ObjectiveFunction { 1397 type enumeration { 1398 enum MCP { 1399 description "MCP."; 1400 } 1401 enum MLP { 1402 description "MLP."; 1403 } 1404 enum MBP { 1405 description "MBP."; 1406 } 1407 enum MBC { 1408 description "MBC."; 1409 } 1410 enum MLL { 1411 description "MLL."; 1412 } 1413 enum MCC { 1414 description "MCC."; 1415 } 1417 } 1418 description "RFC 5541 - Encoding of Objective Functions in the 1419 Path Computation Element Communication Protocol (PCEP)"; 1420 } 1422 /* 1423 * Groupings 1424 */ 1426 grouping Path { 1427 list _telink { 1428 key 'link-ref'; 1429 config false; 1430 uses nt:link-ref; 1431 description "List of telink refs."; 1432 } 1433 container _routingConstraint { 1434 config false; 1435 uses RoutingConstraint; 1436 description "Extended routing constraints."; 1437 } 1438 leaf path-id { 1439 type yang-types:uuid; 1440 config false; 1441 description "path-id ref."; 1442 } 1443 description "Path is described by an ordered list of TE Links."; 1444 } 1446 grouping PathCompServicePort { 1447 container src-tp-ref { 1448 uses nt:tp-ref; 1449 config false; 1450 description "Source termination point reference."; 1451 } 1452 container dst-tp-ref { 1453 uses nt:tp-ref; 1454 config false; 1455 description "Destination termination point reference."; 1457 } 1458 /**leaf direction { 1459 type PortDirection; 1460 config false; 1461 description "The orientation of defined flow."; 1462 }*/ 1463 container serviceLayer { 1464 uses tet:te-node-tunnel-termination-attributes; 1465 config false; 1466 description "Service Layer."; 1467 } 1468 description "Path Computation Service Port grouping."; 1469 } 1471 grouping PathComputationService { 1472 leaf-list _path-ref { 1473 type leafref { 1474 path '/path/path-id'; 1475 } 1476 config false; 1477 description "List of previously computed path references."; 1478 } 1479 container _servicePort { 1480 uses PathCompServicePort; 1481 description "Path Computation Service Port."; 1482 } 1483 container _routingConstraint { 1484 uses RoutingConstraint; 1485 description "Routing constraints."; 1486 } 1487 container _objectiveFunction { 1488 uses PathObjectiveFunction; 1489 description "Path Objective Function."; 1490 } 1491 container _optimizationConstraint { 1492 uses PathOptimizationConstraint; 1493 description "Path Optimization Constraint."; 1494 } 1495 description "Path computation service."; 1497 } 1499 grouping PathObjectiveFunction { 1500 leaf objectiveFunction { 1501 type ObjectiveFunction; 1502 config false; 1503 description "Objective Function."; 1504 } 1505 description "Path Objective Function."; 1506 } 1508 grouping PathOptimizationConstraint { 1509 leaf trafficInterruption { 1510 type DirectiveValue; 1511 config false; 1512 description "Traffic Interruption."; 1513 } 1514 description "Path Optimization Constraint."; 1515 } 1517 grouping RoutingConstraint { 1518 leaf requestedCapacity { 1519 type decimal64 { 1520 fraction-digits 2; 1521 } 1522 config false; 1523 description "Capacity required for connectivity service."; 1524 } 1525 container pathConstraints { 1526 config false; 1527 uses te-types:path-constraints; 1528 description "Service connectivity path selection properties"; 1529 } 1530 // path-constaints contains include topology 1531 /*leaf _includeTopology { 1532 uses te-types:te-topology-ref; 1533 config false; 1534 }*/ 1535 container _avoidTopology { 1536 uses tet:te-topology-ref; 1537 config false; 1538 description "Topology to be avoided."; 1539 } 1540 // path-constrains already include/exclude path 1541 /*list _includePath { 1542 key 'link-ref'; 1543 config false; 1544 uses nt:link-ref; 1545 }*/ 1546 /*list _excludePath { 1547 key 'link-ref'; 1548 config false; 1549 uses nt:link-ref; 1550 }*/ 1551 description "Extended routing constraints. Created to align with 1552 path-constaints."; 1553 } 1555 /* 1556 * Lists 1557 */ 1558 list path { 1559 key "path-id"; 1560 uses Path; 1561 config false; 1562 description "List of previous computed paths."; 1563 } 1565 container pathComputationService { 1566 uses PathComputationService; 1567 description "Service for computing paths."; 1568 } 1570 /*********************** 1571 * package Interfaces 1572 **********************/ 1573 rpc statelessComputeP2PPath { 1574 description "statelessComputeP2PPath"; 1575 input { 1576 list servicePort { 1577 min-elements 2; 1578 max-elements 2; 1579 uses PathCompServicePort; 1580 description "List of service ports."; 1581 } 1582 container routingConstraint { 1583 uses RoutingConstraint; 1584 description "routing constraint."; 1585 } 1586 container objectiveFunction { 1587 uses PathObjectiveFunction; 1588 description "objective function."; 1589 } 1590 } 1591 output { 1592 container pathCompService { 1593 uses PathComputationService; 1594 description "Path computation service."; 1595 } 1596 } 1597 } 1599 /**rpc computeP2PPath { 1600 input { 1601 list servicePort { 1602 min-elements 2; 1603 max-elements 2; 1604 uses PathCompServicePort; 1605 } 1606 container routingConstraint { 1607 uses RoutingConstraint; 1608 } 1609 container objectiveFunction { 1610 uses PathObjectiveFunction; 1611 } 1612 } 1613 output { 1614 container pathCompService { 1615 uses PathComputationService; 1616 } 1617 } 1618 }*/ 1620 rpc optimizeP2PPath { 1621 description "optimizeP2PPath."; 1622 input { 1623 leaf pathIdOrName { 1624 type string; 1625 description "path id or path name."; 1626 } 1627 container routingConstraint { 1628 uses RoutingConstraint; 1629 description "routing constraint."; 1630 } 1631 container optimizationConstraint { 1632 uses PathOptimizationConstraint; 1633 description "optimizationConstraint."; 1634 } 1635 container objectiveFunction { 1636 uses PathObjectiveFunction; 1637 description "objective function."; 1638 } 1639 } 1640 output { 1641 container pathCompService { 1642 uses PathComputationService; 1643 description "path computation service."; 1644 } 1645 } 1646 } 1648 /**rpc deleteP2PPath { 1649 input { 1650 leaf pathIdOrName { 1651 type string; 1652 } 1654 } 1655 output { 1656 container pathCompService { 1657 uses PathComputationService; 1658 } 1659 } 1660 }*/ 1661 } 1662 1664 Figure 10 - TE path computation YANG module 1666 7. Security Considerations 1668 This is for further study 1670 8. IANA Considerations 1672 This document requires no IANA actions. 1674 9. References 1676 9.1. Normative References 1678 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 1679 Information Exchange Between Interconnected Traffic 1680 Engineered Networks", RFC 7926, July 2016. 1682 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 1683 draft-ietf-teas-yang-te-topo, work in progress. 1685 [TE-TUNNEL] Xhang, X. et al., "A YANG Data Model for Traffic 1686 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1687 te, work in progress. 1689 9.2. Informative References 1691 [RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment 1692 Information Model for Wavelength Switched Optical 1693 Networks", RFC 7446, February 2015. 1695 [L1-TOPO] Zhang, X. et al., "A YANG Data Model for Layer 1 (ODU) 1696 Network Topology", draft-zhang-ccamp-l1-topo-yang, work in 1697 progress. 1699 [ACTN-Frame] D, Ceccarelli and Y. Lee (editors), "Framework for 1700 Abstraction and Control of Transport Networks," draft- 1701 ceccarelli-actn-framework, work in progress. 1703 [ACTN-Info] Y. Lee and S. Belotti, D. Dhody and D. Ceccarelli, 1704 "Information Model for Abstraction and Control of 1705 Transport Networks", draft-leebelotti-actn-info, work in 1706 progress. 1708 10. Acknowledgments 1710 The authors would like to thank Igor Bryskin and Xian Zhang for 1711 participating in discussions and providing valuable insights. 1713 This document was prepared using 2-Word-v2.0.template.dot. 1715 Contributors 1717 Dieter Beller 1718 Nokia 1719 Email: dieter.beller@nokia.com 1721 Authors' Addresses 1723 Italo Busi 1724 Huawei 1725 Email: italo.busi@huawei.com 1727 Sergio Belotti 1728 Nokia 1729 Email: sergio.belotti@nokia.com 1731 Victor Lopez 1732 Telefonica 1733 Email: victor.lopezalvarez@telefonica.com 1735 Oscar Gonzalez de Dios 1736 Telefonica 1737 Email: oscar.gonzalezdedios@telefonica.com 1739 Anurag Sharma 1740 Infinera 1741 Email: AnSharma@infinera.com 1743 Yan Shi 1744 China Unicom 1745 Email: shiyan49@chinaunicom.cn 1747 Ricard Vilalta 1748 CTTC 1749 Email: ricard.vilalta@cttc.es 1750 Karthik Sethuraman 1751 NEC 1752 Email: karthik.sethuraman@necam.com 1754 Michael Scharf 1755 Nokia 1756 Email: michael.scharf@nokia.com 1758 Daniele Ceccarelli 1759 Ericsson 1760 Email: daniele.ceccarelli@ericsson.com