idnits 2.17.1 draft-ietf-teas-yang-path-computation-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([TE-TUNNEL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1343 has weird spacing: '...tion-id uin...' == Line 1350 has weird spacing: '...ic-type ide...' == Line 1359 has weird spacing: '...-- name str...' == Line 1366 has weird spacing: '...ic-type ide...' == Line 1435 has weird spacing: '...o usage ide...' == (36 more instances...) -- The document date (December 10, 2019) is 1598 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7491 ** Downref: Normative reference to an Informational RFC: RFC 8453 ** Downref: Normative reference to an Informational RFC: RFC 8454 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Italo Busi (Ed.) 2 Internet Draft Huawei 3 Intended status: Standard Track Sergio Belotti (Ed.) 4 Expires: June 2020 Nokia 5 Victor Lopez 6 Telefonica 7 Anurag Sharma 8 Google 9 Yan Shi 10 China Unicom 12 December 10, 2019 14 Yang model for requesting Path Computation 15 draft-ietf-teas-yang-path-computation-08.txt 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on June 10, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Abstract 57 There are scenarios, typically in a hierarchical SDN context, where 58 the topology information provided by a TE network provider may not 59 be sufficient for its client to perform end-to-end path computation. 60 In these cases the client would need to request the provider to 61 calculate some (partial) feasible paths. 63 This document defines a YANG data model for a stateless RPC to 64 request path computation. This model complements the stateful 65 solution defined in [TE-TUNNEL]. 67 Moreover this document describes some use cases where a path 68 computation request, via YANG-based protocols (e.g., NETCONF or 69 RESTCONF), can be needed. 71 Table of Contents 73 1. Introduction...................................................3 74 1.1. Terminology...............................................5 75 2. Use Cases......................................................5 76 2.1. Packet/Optical Integration................................5 77 2.2. Multi-domain TE Networks.................................10 78 2.3. Data center interconnections.............................12 79 2.4. Backward Recursive Path Computation scenario.............14 80 2.5. Hierarchical PCE scenario................................15 81 3. Motivations...................................................17 82 3.1. Motivation for a YANG Model..............................17 83 3.1.1. Benefits of common data models......................17 84 3.1.2. Benefits of a single interface......................18 85 3.1.3. Extensibility.......................................19 86 3.2. Interactions with TE Topology............................19 87 3.2.1. TE Topology Aggregation.............................20 88 3.2.2. TE Topology Abstraction.............................23 89 3.2.3. Complementary use of TE topology and path computation24 90 3.3. Stateless and Stateful Path Computation..................27 91 3.3.1. Temporary reporting of the computed path state......29 92 4. Path Computation and Optimization for multiple paths..........31 93 5. YANG Model for requesting Path Computation....................32 94 5.1. Synchronization of multiple path computation requests....32 95 5.2. Returned metric values...................................34 96 5.3. Multiple Paths Requests for the same TE Tunnel...........36 97 6. YANG model for stateless TE path computation..................38 98 6.1. YANG Tree................................................38 99 6.2. YANG Module..............................................49 100 7. Security Considerations.......................................64 101 8. IANA Considerations...........................................64 102 9. References....................................................65 103 9.1. Normative References.....................................65 104 9.1. Informative References...................................66 105 10. Acknowledgments..............................................67 106 Appendix A. Examples of dimensioning the "detailed connectivity 107 matrix"...........................................68 108 Appendix B. New proposed YANG Tree overview...................74 110 1. Introduction 112 There are scenarios, typically in a hierarchical SDN context, where 113 the topology information provided by a TE network provider may not 114 be sufficient for its client to perform end-to-end path computation. 115 In these cases the client would need to request the provider to 116 calculate some (partial) feasible paths, complementing his topology 117 knowledge, to make his end-to-end path computation feasible. 119 This type of scenarios can be applied to different interfaces in 120 different reference architectures: 122 o ABNO control interface [RFC7491], in which an Application Service 123 Coordinator can request ABNO controller to take in charge path 124 calculation (see Figure 1 in [RFC7491]). 126 o ACTN [RFC8453], where a controller hierarchy is defined, the need 127 for path computation arises on both interfaces CMI (interface 128 between Customer Network Controller (CNC) and Multi Domain 129 Service Coordinator (MDSC)) and/or MPI (interface between MSDC- 130 PNC). [RFC8454] describes an information model for the Path 131 Computation request. 133 Multiple protocol solutions can be used for communication between 134 different controller hierarchical levels. This document assumes that 135 the controllers are communicating using YANG-based protocols (e.g., 136 NETCONF or RESTCONF). 138 Path Computation Elements, Controllers and Orchestrators perform 139 their operations based on Traffic Engineering Databases (TED). Such 140 TEDs can be described, in a technology agnostic way, with the YANG 141 Data Model for TE Topologies [TE-TOPO]. Furthermore, the technology 142 specific details of the TED are modeled in the augmented TE topology 143 models (e.g. [OTN-TOPO] for OTN ODU technologies). 145 The availability of such topology models allows providing the TED 146 using YANG-based protocols (e.g., NETCONF or RESTCONF). Furthermore, 147 it enables a PCE/Controller performing the necessary abstractions or 148 modifications and offering this customized topology to another 149 PCE/Controller or high level orchestrator. 151 Note: This document assumes that the client of the YANG data model 152 defined in this document may not implement a "PCE" functionality, as 153 defined in [RFC4655]. 155 The tunnels that can be provided over the networks described with 156 the topology models can be also set-up, deleted and modified via 157 YANG-based protocols (e.g., NETCONF or RESTCONF) using the TE-Tunnel 158 Yang model [TE-TUNNEL]. 160 This document proposes a YANG model for a path computation request 161 defined as a stateless RPC, which complements the stateful solution 162 defined in [TE-TUNNEL]. 164 Moreover, this document describes some use cases where a path 165 computation request, via YANG-based protocols (e.g., NETCONF or 166 RESTCONF), can be needed. 168 1.1. Terminology 170 TED: The traffic engineering database is a collection of all TE 171 information about all TE nodes and TE links in a given network. 173 PCE: A Path Computation Element (PCE) is an entity that is capable 174 of computing a network path or route based on a network graph, and 175 of applying computational constraints during the computation. The 176 PCE entity is an application that can be located within a network 177 node or component, on an out-of-network server, etc. For example, a 178 PCE would be able to compute the path of a TE LSP by operating on 179 the TED and considering bandwidth and other constraints applicable 180 to the TE LSP service request. [RFC4655] 182 2. Use Cases 184 This section presents some use cases, where a client needs to 185 request underlying SDN controllers for path computation. 187 The use of the YANG model defined in this document is not restricted 188 to these use cases but can be used in any other use case when deemed 189 useful. 191 The presented uses cases have been grouped, depending on the 192 different underlying topologies: a) Packet-Optical integration; b) 193 Multi-domain Traffic Engineered (TE) Networks; and c) Data center 194 interconnections. Use cases d) and e) respectively present how to 195 apply this Yang model for standard multi-domain PCE i.e. Backward 196 Recursive Path Computation [RFC5441] and Hierarchical PCE [RFC6805]. 198 2.1. Packet/Optical Integration 200 In this use case, an Optical network is used to provide connectivity 201 to some nodes of a Packet network (see Figure 1). 203 +----------------+ 204 | | 205 | Packet/Optical | 206 | Coordinator | 207 | | 208 +---+------+-----+ 209 | | 210 +------------+ | 211 | +-----------+ 212 +------V-----+ | 213 | | +------V-----+ 214 | Packet | | | 215 | Network | | Optical | 216 | Controller | | Network | 217 | | | Controller | 218 +------+-----+ +-------+----+ 219 | | 220 .........V......................... | 221 : Packet Network : | 222 +----+ +----+ | 223 | R1 |= = = = = = = = = = = = = = = =| R2 | | 224 +-+--+ +--+-+ | 225 | : : | | 226 | :................................ : | | 227 | | | 228 | +-----+ | | 229 | ...........| Opt |........... | | 230 | : | C | : | | 231 | : /+--+--+\ : | | 232 | : / | \ : | | 233 | : / | \ : | | 234 | +-----+ / +--+--+ \ +-----+ | | 235 | | Opt |/ | Opt | \| Opt | | | 236 +---| A | | D | | B |---+ | 237 +-----+\ +--+--+ /+-----+ | 238 : \ | / : | 239 : \ | / : | 240 : \ +--+--+ / Optical<---------+ 241 : \| Opt |/ Network: 242 :..........| E |..........: 243 +-----+ 245 Figure 1 - Packet/Optical Integration Use Case 247 Figure 1 as well as Figure 2 below only show a partial view of the 248 packet network connectivity, before additional packet connectivity 249 is provided by the Optical network. 251 It is assumed that the Optical network controller provides to the 252 packet/optical coordinator an abstracted view of the Optical 253 network. A possible abstraction could be to represent the whole 254 optical network as one "virtual node" with "virtual ports" connected 255 to the access links, as shown in Figure 2. 257 It is also assumed that Packet network controller can provide the 258 packet/optical coordinator the information it needs to setup 259 connectivity between packet nodes through the Optical network (e.g., 260 the access links). 262 The path computation request helps the coordinator to know the real 263 connections that can be provided by the optical network. 265 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,. 266 , Packet/Optical Coordinator view , 267 , +----+ , . 268 , | | , 269 , | R2 | , . 270 , +----+ +------------ + /+----+ , 271 , | | | |/-----/ / / , . 272 , | R1 |--O VP1 VP4 O / / , 273 , | |\ | | /----/ / , . 274 , +----+ \| |/ / , 275 , / O VP2 VP5 O / , . 276 , / | | +----+ , 277 , / | | | | , . 278 , / O VP3 VP6 O--| R4 | , 279 , +----+ /-----/|_____________| +----+ , . 280 , | |/ +------------ + , 281 , | R3 | , . 282 , +----+ ,,,,,,,,,,,,,,,,, 283 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,. 284 . Packet Network Controller view +----+ , 285 only packet nodes and packet links | | , . 286 . with access links to the optical network | R2 | , 287 , +----+ /+----+ , . 288 . , | | /-----/ / / , 289 , | R1 |--- / / , . 290 . , +----+\ /----/ / , 291 , / \ / / , . 292 . , / / , 293 , / +----+ , . 294 . , / | | , 295 , / ---| R4 | , . 296 . , +----+ /-----/ +----+ , 297 , | |/ , . 298 . , | R3 | , 299 , +----+ ,,,,,,,,,,,,,,,,,. 300 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 301 Optical Network Controller view , . 302 . only optical nodes, +--+ , 303 optical links and /|OF| , . 304 . access links from the +--++--+ / , 305 packet network |OA| \ /-----/ / , . 306 . , ---+--+--\ +--+/ / , 307 , \ | \ \-|OE|-------/ , . 308 . , \ | \ /-+--+ , 309 , \+--+ X | , . 311 . , |OB|-/ \ | , 312 , +--+-\ \+--+ , . 313 . , / \ \--|OD|--- , 314 , /-----/ +--+ +--+ , . 315 . , / |OC|/ , 316 , +--+ , . 317 ., ,,,,,,,,,,,,,,,,,, 318 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 319 . Actual Physical View +----+ , 320 , +--+ | | , 321 . , /|OF| | R2 | , 322 , +----+ +--++--+ /+----+ , 323 . , | | |OA| \ /-----/ / / , 324 , | R1 |---+--+--\ +--+/ / / , 325 . , +----+\ | \ \-|OE|-------/ / , 326 , / \ | \ /-+--+ / , 327 . , / \+--+ X | / , 328 , / |OB|-/ \ | +----+ , 329 . , / +--+-\ \+--+ | | , 330 , / / \ \--|OD|---| R4 | , 331 . , +----+ /-----/ +--+ +--+ +----+ , 332 , | |/ |OC|/ , 333 . , | R3 | +--+ , 334 , +----+ , 335 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 337 Figure 2 - Packet and Optical Topology Abstractions 339 In this use case, the coordinator needs to setup an optimal 340 underlying path for an IP link between R1 and R2. 342 As depicted in Figure 2, the coordinator has only an "abstracted 343 view" of the physical network, and it does not know the feasibility 344 or the cost of the possible optical paths (e.g., VP1-VP4 and VP2- 345 VP5), which depend from the current status of the physical resources 346 within the optical network and on vendor-specific optical 347 attributes. 349 The coordinator can request the underlying Optical domain controller 350 to compute a set of potential optimal paths, taking into account 351 optical constraints. Then, based on its own constraints, policy and 352 knowledge (e.g. cost of the access links), it can choose which one 353 of these potential paths to use to setup the optimal end-to-end path 354 crossing optical network. 356 ............................ 357 : : 358 O VP1 VP4 O 359 cost=10 /:\ /:\ cost=10 360 / : \----------------------/ : \ 361 +----+ / : cost=50 : \ +----+ 362 | |/ : : \| | 363 | R1 | : : | R2 | 364 | |\ : : /| | 365 +----+ \ : /--------------------\ : / +----+ 366 \ : / cost=55 \ : / 367 cost=5 \:/ \:/ cost=5 368 O VP2 VP5 O 369 : : 370 :..........................: 372 Figure 3 - Packet/Optical Path Computation Example 374 For example, in Figure 3, the Coordinator can request the Optical 375 network controller to compute the paths between VP1-VP4 and VP2-VP5 376 and then decide to setup the optimal end-to-end path using the VP2- 377 VP5 Optical path even this is not the optimal path from the Optical 378 domain perspective. 380 Considering the dynamicity of the connectivity constraints of an 381 Optical domain, it is possible that a path computed by the Optical 382 network controller when requested by the Coordinator is no longer 383 valid/available when the Coordinator requests it to be setup up. 384 This is further discussed in section 3.3. 386 2.2. Multi-domain TE Networks 388 In this use case there are two TE domains which are interconnected 389 together by multiple inter-domains links. 391 A possible example could be a multi-domain optical network. 393 +--------------+ 394 | Multi-domain | 395 | Controller | 396 +---+------+---+ 397 | | 398 +------------+ | 399 | +-----------+ 400 +------V-----+ | 401 | | | 402 | TE Domain | +------V-----+ 403 | Controller | | | 404 | 1 | | TE Domain | 405 +------+-----+ | Controller | 406 | | 2 | 407 | +------+-----+ 408 .........V.......... | 409 : : | 410 +-----+ : | 411 | | : .........V.......... 412 | X | : : : 413 | | +-----+ +-----+ : 414 +-----+ | | | | : 415 : | C |------| E | : 416 +-----+ +-----+ /| | | |\ +-----+ +-----+ 417 | | | |/ +-----+ +-----+ \| | | | 418 | A |----| B | : : | G |----| H | 419 | | | |\ : : /| | | | 420 +-----+ +-----+ \+-----+ +-----+/ +-----+ +-----+ 421 : | | | | : 422 : | D |------| F | : 423 : | | | | +-----+ 424 : +-----+ +-----+ | | 425 : : : | Y | 426 : : : | | 427 : Domain 1 : : Domain 2 +-----+ 428 :..................: :.................: 430 Figure 4 - Multi-domain multi-link interconnection 432 In order to setup an end-to-end multi-domain TE path (e.g., between 433 nodes A and H), the multi-domain controller needs to know the 434 feasibility or the cost of the possible TE paths within the two TE 435 domains, which depend from the current status of the physical 436 resources within each TE network. This is more challenging in case 437 of optical networks because the optimal paths depend also on vendor- 438 specific optical attributes (which may be different in the two 439 domains if they are provided by different vendors). 441 In order to setup a multi-domain TE path (e.g., between nodes A and 442 H), the multi-domain controller can request the TE domain 443 controllers to compute a set of intra-domain optimal paths and take 444 decisions based on the information received. For example: 446 o The multi-domain controller asks TE domain controllers to provide 447 set of paths between A-C, A-D, E-H and F-H 449 o TE domain controllers return a set of feasible paths with the 450 associated costs: the path A-C is not part of this set(in optical 451 networks, it is typical to have some paths not being feasible due 452 to optical constraints that are known only by the optical domain 453 controller) 455 o The multi-domain controller will select the path A-D-F-H since it 456 is the only feasible multi-domain path and then request the TE 457 domain controllers to setup the A-D and F-H intra-domain paths 459 o If there are multiple feasible paths, the multi-domain controller 460 can select the optimal path knowing the cost of the intra-domain 461 paths (provided by the TE domain controllers) and the cost of the 462 inter-domain links (known by the multi-domain controller) 464 This approach may have some scalability issues when the number of TE 465 domains is quite big (e.g. 20). 467 In this case, it would be worthwhile using the abstract TE topology 468 information provided by the TE domain controllers to limit the 469 number of potential optimal end-to-end paths and then request path 470 computation to fewer TE domain controllers in order to decide what 471 the optimal path within this limited set is. 473 For more details, see section 3.2.3. 475 2.3. Data center interconnections 477 In these use case, there is a TE domain which is used to provide 478 connectivity between data centers which are connected with the TE 479 domain using access links. 481 +--------------+ 482 | Cloud Network| 483 | Orchestrator | 484 +--------------+ 485 | | | | 486 +-------------+ | | +------------------------+ 487 | | +------------------+ | 488 | +--------V---+ | | 489 | | | | | 490 | | TE Network | | | 491 +------V-----+ | Controller | +------V-----+ | 492 | DC | +------------+ | DC | | 493 | Controller | | | Controller | | 494 +------------+ | +-----+ +------------+ | 495 | ....V...| |........ | | 496 | : | P | : | | 497 .....V..... : /+-----+\ : .....V..... | 498 : : +-----+ / | \ +-----+ : : | 499 : DC1 || : | |/ | \| | : DC2 || : | 500 : ||||----| PE1 | | | PE2 |---- |||| : | 501 : _|||||| : | |\ | /| | : _|||||| : | 502 : : +-----+ \ +-----+ / +-----+ : : | 503 :.........: : \| |/ : :.........: | 504 :.......| PE3 |.......: | 505 | | | 506 +-----+ +---------V--+ 507 .....|..... | DC | 508 : : | Controller | 509 : DC3 || : +------------+ 510 : |||| : | 511 : _|||||| <------------------+ 512 : : 513 :.........: 515 Figure 5 - Data Center Interconnection Use Case 517 In this use case, there is need to transfer data from Data Center 1 518 (DC1) to either DC2 or DC3 (e.g. workload migration). 520 The optimal decision depends both on the cost of the TE path (DC1- 521 DC2 or DC1-DC3) and of the data center resources within DC2 or DC3. 523 The cloud network orchestrator needs to make a decision for optimal 524 connection based on TE Network constraints and data centers 525 resources. It may not be able to make this decision because it has 526 only an abstract view of the TE network (as in use case in 2.1). 528 The cloud network orchestrator can request to the TE network 529 controller to compute the cost of the possible TE paths (e.g., DC1- 530 DC2 and DC1-DC3) and to the DC controller to provide the information 531 it needs about the required data center resources within DC2 and DC3 532 and then it can take the decision about the optimal solution based 533 on this information and its policy. 535 2.4. Backward Recursive Path Computation scenario 537 [RFC5441] has defined the Virtual Source Path Tree (VSPT) TLV within 538 PCE Reply Object in order to compute inter-domain paths following a 539 "Backward Recursive Path Computation" (BRPC) method. The main 540 principle is to forward the PCE request message up to the 541 destination domain. Then, each PCE involved in the computation will 542 compute its part of the path and send it back to the requester 543 through PCE Response message. The resulting computation is spread 544 from destination PCE to source PCE. Each PCE is in charge of merging 545 the path it received with the one it calculated. At the end, the 546 source PCE merges its local part of the path with the received one 547 to achieve the end-to-end path. 549 Figure 6 below show a typical BRPC scenario where 3 PCEs cooperate 550 to compute inter-domain paths. 552 +----------------+ +----------------+ 553 | Domain (B) | | Domain (C) | 554 | | | | 555 | /-------|---PCEP---|--------\ | 556 | / | | \ | 557 | (PCE) | | (PCE) | 558 | / <----------> | 559 | / | Inter | | 560 +---|----^-------+ Domain +----------------+ 561 | | Link 562 PCEP | 563 | | Inter-domain Link 564 | | 565 +---|----v-------+ 566 | | | 567 | | Domain (A) | 568 | \ | 569 | (PCE) | 570 | | 571 | | 572 +----------------+ 573 Figure 6 - BRPC Scenario 575 In this use case, a client can use the YANG model defined in this 576 document to request path computation to the PCE that controls the 577 source of the tunnel. For example, a client can request to the PCE 578 of domain A to compute a path from a source S, within domain A, to a 579 destination D, within domain C. Then PCE of domain A will use PCEP 580 protocol, as per [RFC5441], to compute the path from S to D and in 581 turn gives the final answer to the requester. 583 2.5. Hierarchical PCE scenario 585 [RFC6805] has defined an architecture and extensions to the PCE 586 standard to compute inter-domain path following a hierarchical 587 method. Two new roles have been defined: Parent PCE and child PCE. 588 The parent PCE is in charge to coordinate the end-to-end path 589 computation. For that purpose it sends to each child PCE involve in 590 the multi-domain path computation a PCE Request message to obtain 591 the local part of the path. Once received all answer through PCE 592 Response message, the Parent PCE will merge the different local 593 parts of the path to achieve the end-to-end path. 595 Figure 7 below shows a typical hierarchical scenario where a Parent 596 PCE request end-to-end path to the different child PCE. Note that a 597 PCE could take independently the role of Child or Parent PCE 598 depending of which PCE will request the path. 600 ----------------------------------------------------------------- 601 | Domain 5 | 602 | ----- | 603 | |PCE 5| | 604 | ----- | 605 | | 606 | ---------------- ---------------- ---------------- | 607 | | Domain 1 | | Domain 2 | | Domain 3 | | 608 | | | | | | | | 609 | | ----- | | ----- | | ----- | | 610 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 611 | | ----- | | ----- | | ----- | | 612 | | | | | | | | 613 | | ----| |---- ----| |---- | | 614 | | |BN11+---+BN21| |BN23+---+BN31| | | 615 | | - ----| |---- ----| |---- - | | 616 | | |S| | | | | |D| | | 617 | | - ----| |---- ----| |---- - | | 618 | | |BN12+---+BN22| |BN24+---+BN32| | | 619 | | ----| |---- ----| |---- | | 620 | | | | | | | | 621 | | ---- | | | | ---- | | 622 | | |BN13| | | | | |BN33| | | 623 | -----------+---- ---------------- ----+----------- | 624 | \ / | 625 | \ ---------------- / | 626 | \ | | / | 627 | \ |---- ----| / | 628 | ----+BN41| |BN42+---- | 629 | |---- ----| | 630 | | | | 631 | | ----- | | 632 | | |PCE 4| | | 633 | | ----- | | 634 | | | | 635 | | Domain 4 | | 636 | ---------------- | 637 | | 638 ----------------------------------------------------------------- 639 Figure 7 - Hierarchical domain topology from [RFC6805] 641 In this use case, a client can use the YANG model defined in this 642 document to request to the Parent PCE a path from a source S to a 643 destination D. The Parent PCE will in turn contact the child PCEs 644 through PCEP protocol to compute the end-to-end path and then return 645 the computed path to the client, using the YANG model defined in 646 this document. For example the YANG model can be used to request to 647 PCE5 acting as Parent PCE to compute a path from source S, within 648 domain 1, to destination D, within domain 3. PCE5 will contact child 649 PCEs of domain 1, 2 and 3 to obtain local part of the end-to-end 650 path through the PCEP protocol. Once received the PCE Response 651 message, it merges the answers to compute the end-to-end path and 652 send it back to the client. 654 3. Motivations 656 This section provides the motivation for the YANG model defined in 657 this document. 659 Section 3.1 describes the motivation for a YANG model to request 660 path computation. 662 Section 3.2 describes the motivation for a YANG model which 663 complements the TE Topology YANG model defined in [TE-TOPO]. 665 Section 3.3 describes the motivation for a stateless YANG RPC which 666 complements the TE Tunnel YANG model defined in [TE-TUNNEL]. 668 3.1. Motivation for a YANG Model 670 3.1.1. Benefits of common data models 672 The YANG data model for requesting path computation is closely 673 aligned with the YANG data models that provide (abstract) TE 674 topology information, i.e., [TE-TOPO] as well as that are used to 675 configure and manage TE Tunnels, i.e., [TE-TUNNEL]. 677 There are many benefits in aligning the data model used for path 678 computation requests with the YANG data models used for TE topology 679 information and for TE Tunnels configuration and management: 681 o There is no need for an error-prone mapping or correlation of 682 information. 684 o It is possible to use the same endpoint identifiers in path 685 computation requests and in the topology modeling. 687 o The attributes used for path computation constraints are the same 688 as those used when setting up a TE Tunnel. 690 3.1.2. Benefits of a single interface 692 The system integration effort is typically lower if a single, 693 consistent interface is used by controllers, i.e., one data modeling 694 language (i.e., YANG) and a common protocol (e.g., NETCONF or 695 RESTCONF). 697 Practical benefits of using a single, consistent interface include: 699 1. Simple authentication and authorization: The interface between 700 different components has to be secured. If different protocols 701 have different security mechanisms, ensuring a common access 702 control model may result in overhead. For instance, there may be 703 a need to deal with different security mechanisms, e.g., 704 different credentials or keys. This can result in increased 705 integration effort. 707 2. Consistency: Keeping data consistent over multiple different 708 interfaces or protocols is not trivial. For instance, the 709 sequence of actions can matter in certain use cases, or 710 transaction semantics could be desired. While ensuring 711 consistency within one protocol can already be challenging, it is 712 typically cumbersome to achieve that across different protocols. 714 3. Testing: System integration requires comprehensive testing, 715 including corner cases. The more different technologies are 716 involved, the more difficult it is to run comprehensive test 717 cases and ensure proper integration. 719 4. Middle-box friendliness: Provider and consumer of path 720 computation requests may be located in different networks, and 721 middle-boxes such as firewalls, NATs, or load balancers may be 722 deployed. In such environments it is simpler to deploy a single 723 protocol. Also, it may be easier to debug connectivity problems. 725 5. Tooling reuse: Implementers may want to implement path 726 computation requests with tools and libraries that already exist 727 in controllers and/or orchestrators, e.g., leveraging the rapidly 728 growing eco-system for YANG tooling. 730 3.1.3. Extensibility 732 Path computation is only a subset of the typical functionality of a 733 controller. In many use cases, issuing path computation requests 734 comes along with the need to access other functionality on the same 735 system. In addition to obtaining TE topology, for instance also 736 configuration of services (setup/modification/deletion) may be 737 required, as well as: 739 1. Receiving notifications for topology changes as well as 740 integration with fault management 742 2. Performance management such as retrieving monitoring and 743 telemetry data 745 3. Service assurance, e.g., by triggering OAM functionality 747 4. Other fulfilment and provisioning actions beyond tunnels and 748 services, such as changing QoS configurations 750 YANG is a very extensible and flexible data modeling language that 751 can be used for all these use cases. 753 3.2. Interactions with TE Topology 755 The use cases described in section 2 have been described assuming 756 that the topology view exported by each underlying SDN controller to 757 the orchestrator is aggregated using the "virtual node model", 758 defined in [RFC7926]. 760 TE Topology information, e.g., as provided by [TE-TOPO], could in 761 theory be used by an underlying SDN controllers to provide TE 762 information to its client thus allowing a PCE available within its 763 client to perform multi-domain path computation by its own, without 764 requesting path computations to the underlying SDN controllers. 766 In case the client does not implement a PCE function, as discussed 767 in section 1, it could not perform path computation based on TE 768 Topology information and would instead need to request path 769 computation to the underlying controllers to get the information it 770 needs to compute the optimal end-to-end path. 772 This section analyzes the need for a client to request underlying 773 SDN controllers for path computation even in case it implements a 774 PCE functionality, as well as how the TE Topology information and 775 the path computation can be complementary. 777 In nutshell, there is a scalability trade-off between providing all 778 the TE information needed by PCE, when implemented by the client, to 779 take optimal path computation decisions by its own versus sending 780 too many requests to underlying SDN Domain Controllers to compute a 781 set of feasible optimal intra-domain TE paths. 783 3.2.1. TE Topology Aggregation 785 Using the TE Topology model, as defined in [TE-TOPO], the underlying 786 SDN controller can export the whole TE domain as a single abstract 787 TE node with a "detailed connectivity matrix". 789 The concept of a "detailed connectivity matrix" is defined in [TE- 790 TOPO] to provide specific TE attributes (e.g., delay, SRLGs and 791 summary TE metrics) as an extension of the "basic connectivity 792 matrix", which is based on the "connectivity matrix" defined in 793 [RFC7446]. 795 The information provided by the "detailed connectivity matrix" would 796 be equivalent to the information that should be provided by "virtual 797 link model" as defined in [RFC7926]. 799 For example, in the Packet/Optical integration use case, described 800 in section 2.1, the Optical network controller can make the 801 information shown in Figure 3 available to the Coordinator as part 802 of the TE Topology information and the Coordinator could use this 803 information to calculate by its own the optimal path between R1 and 804 R2, without requesting any additional information to the Optical 805 network Controller. 807 However, when designing the amount of information to provide within 808 the "detailed connectivity matrix", there is a tradeoff to be 809 considered between accuracy (i.e., providing "all" the information 810 that might be needed by the PCE available to Orchestrator) and 811 scalability. 813 Figure 8 below shows another example, similar to Figure 3, where 814 there are two possible Optical paths between VP1 and VP4 with 815 different properties (e.g., available bandwidth and cost). 817 ............................ 818 : /--------------------\ : 819 : / cost=65 \ : 820 :/ available-bw=10G \: 821 O VP1 VP4 O 822 cost=10 /:\ /:\ cost=10 823 / : \----------------------/ : \ 824 +----+ / : cost=50 : \ +----+ 825 | |/ : available-bw=2G : \| | 826 | R1 | : : | R2 | 827 | |\ : : /| | 828 +----+ \ : /--------------------\ : / +----+ 829 \ : / cost=55 \ : / 830 cost=5 \:/ available-bw=3G \:/ cost=5 831 O VP2 VP5 O 832 : : 833 :..........................: 835 Figure 8 - Packet/Optical Path Computation Example with multiple 836 choices 838 Reporting all the information, as in Figure 8, using the "detailed 839 connectivity matrix", is quite challenging from a scalability 840 perspective. The amount of this information is not just based on 841 number of end points (which would scale as N-square), but also on 842 many other parameters, including client rate, user 843 constraints/policies for the service, e.g. max latency < N ms, max 844 cost, etc., exclusion policies to route around busy links, min OSNR 845 margin, max preFEC BER etc. All these constraints could be different 846 based on connectivity requirements. 848 Examples of how the "detailed connectivity matrix" can be 849 dimensioned are described in Appendix A. 851 It is also worth noting that the "connectivity matrix" has been 852 originally defined in WSON, [RFC7446], to report the connectivity 853 constrains of a physical node within the WDM network: the 854 information it contains is pretty "static" and therefore, once taken 855 and stored in the TE data base, it can be always being considered 856 valid and up-to-date in path computation request. 858 Using the "basic connectivity matrix" with an abstract node to 859 abstract the information regarding the connectivity constraints of 860 an Optical domain, would make this information more "dynamic" since 861 the connectivity constraints of an Optical domain can change over 862 time because some optical paths that are feasible at a given time 863 may become unfeasible at a later time when e.g., another optical 864 path is established. The information in the "detailed connectivity 865 matrix" is even more dynamic since the establishment of another 866 optical path may change some of the parameters (e.g., delay or 867 available bandwidth) in the "detailed connectivity matrix" while not 868 changing the feasibility of the path. 870 The "connectivity matrix" is sometimes confused with optical reach 871 table that contain multiple (e.g. k-shortest) regen-free reachable 872 paths for every A-Z node combination in the network. Optical reach 873 tables can be calculated offline, utilizing vendor optical design 874 and planning tools, and periodically uploaded to the Controller: 875 these optical path reach tables are fairly static. However, to get 876 the connectivity matrix, between any two sites, either a regen free 877 path can be used, if one is available, or multiple regen free paths 878 are concatenated to get from src to dest, which can be a very large 879 combination. Additionally, when the optical path within optical 880 domain needs to be computed, it can result in different paths based 881 on input objective, constraints, and network conditions. In summary, 882 even though "optical reachability table" is fairly static, which 883 regen free paths to build the connectivity matrix between any source 884 and destination is very dynamic, and is done using very 885 sophisticated routing algorithms. 887 There is therefore the need to keep the information in the "detailed 888 connectivity matrix" updated which means that there another tradeoff 889 between the accuracy (i.e., providing "all" the information that 890 might be needed by the client's PCE) and having up-to-date 891 information. The more the information is provided and the longer it 892 takes to keep it up-to-date which increases the likelihood that the 893 client's PCE computes paths using not updated information. 895 It seems therefore quite challenging to have a "detailed 896 connectivity matrix" that provides accurate, scalable and updated 897 information to allow the client's PCE to take optimal decisions by 898 its own. 900 Instead, if the information in the "detailed connectivity matrix" is 901 not complete/accurate, we can have the following drawbacks 902 considering for example the case in Figure 8: 904 o If only the VP1-VP4 path with available bandwidth of 2 Gb/s and 905 cost 50 is reported, the client's PCE will fail to compute a 5 906 Gb/s path between routers R1 and R2, although this would be 907 feasible; 909 o If only the VP1-VP4 path with available bandwidth of 10 Gb/s and 910 cost 60 is reported, the client's PCE will compute, as optimal, 911 the 1 Gb/s path between R1 and R2 going through the VP2-VP5 path 912 within the Optical domain while the optimal path would actually 913 be the one going thought the VP1-VP4 sub-path (with cost 50) 914 within the Optical domain. 916 Using the approach proposed in this document, the client, when it 917 needs to setup an end-to-end path, it can request the Optical domain 918 controller to compute a set of optimal paths (e.g., for VP1-VP4 and 919 VP2-VP5) and take decisions based on the information received: 921 o When setting up a 5 Gb/s path between routers R1 and R2, the 922 Optical domain controller may report only the VP1-VP4 path as the 923 only feasible path: the Orchestrator can successfully setup the 924 end-to-end path passing though this Optical path; 926 o When setting up a 1 Gb/s path between routers R1 and R2, the 927 Optical domain controller (knowing that the path requires only 1 928 Gb/s) can report both the VP1-VP4 path, with cost 50, and the 929 VP2-VP5 path, with cost 65. The Orchestrator can then compute the 930 optimal path which is passing thought the VP1-VP4 sub-path (with 931 cost 50) within the Optical domain. 933 3.2.2. TE Topology Abstraction 935 Using the TE Topology model, as defined in [TE-TOPO], the underlying 936 SDN controller can export an abstract TE Topology, composed by a set 937 of TE nodes and TE links, representing the abstract view of the 938 topology controlled by each domain controller. 940 Considering the example in Figure 4, the TE domain controller 1 can 941 export a TE Topology encompassing the TE nodes A, B, C and D and the 942 TE Link interconnecting them. In a similar way, TE domain controller 943 2 can export a TE Topology encompassing the TE nodes E, F, G and H 944 and the TE Link interconnecting them. 946 In this example, for simplicity reasons, each abstract TE node maps 947 with each physical node, but this is not necessary. 949 In order to setup a multi-domain TE path (e.g., between nodes A and 950 H), the multi-domain controller can compute by its own an optimal 951 end-to-end path based on the abstract TE topology information 952 provided by the domain controllers. For example: 954 o Multi-domain controller's PCE, based on its own information, can 955 compute the optimal multi-domain path being A-B-C-E-G-H, and then 956 request the TE domain controllers to setup the A-B-C and E-G-H 957 intra-domain paths 959 o But, during path setup, the domain controller may find out that 960 A-B-C intra-domain path is not feasible (as discussed in section 961 2.2, in optical networks it is typical to have some paths not 962 being feasible due to optical constraints that are known only by 963 the optical domain controller), while only the path A-B-D is 964 feasible 966 o So what the multi-domain controller computed is not good and need 967 to re-start the path computation from scratch 969 As discussed in section 3.2.1, providing more extensive abstract 970 information from the TE domain controllers to the multi-domain 971 controller may lead to scalability problems. 973 In a sense this is similar to the problem of routing and wavelength 974 assignment within an Optical domain. It is possible to do first 975 routing (step 1) and then wavelength assignment (step 2), but the 976 chances of ending up with a good path is low. Alternatively, it is 977 possible to do combined routing and wavelength assignment, which is 978 known to be a more optimal and effective way for Optical path setup. 979 Similarly, it is possible to first compute an abstract end-to-end 980 path within the multi-domain Orchestrator (step 1) and then compute 981 an intra-domain path within each Optical domain (step 2), but there 982 are more chances not to find a path or to get a suboptimal path that 983 performing per-domain path computation and then stitch them. 985 3.2.3. Complementary use of TE topology and path computation 987 As discussed in section 2.2, there are some scalability issues with 988 path computation requests in a multi-domain TE network with many TE 989 domains, in terms of the number of requests to send to the TE domain 990 controllers. It would therefore be worthwhile using the TE topology 991 information provided by the domain controllers to limit the number 992 of requests. 994 An example can be described considering the multi-domain abstract 995 topology shown in Figure 9. In this example, an end-to-end TE path 996 between domains A and F needs to be setup. The transit domain should 997 be selected between domains B, C, D and E. 999 .........B......... 1000 : _ _ _ _ _ _ _ _ : 1001 :/ \: 1002 +---O NOT FEASIBLE O---+ 1003 cost=5| : : | 1004 ......A...... | :.................: | ......F...... 1005 : : | | : : 1006 : O-----+ .........C......... +-----O : 1007 : : : /-------------\ : : : 1008 : : :/ \: : : 1009 : cost<=20 O---------O cost <= 30 O---------O cost<=20 : 1010 : /: cost=5 : : cost=5 :\ : 1011 : /------/ : :.................: : \------\ : 1012 : / : : \ : 1013 :/ cost<=25 : .........D......... : cost<=25 \: 1014 O-----------O-------+ : /-------------\ : +-------O-----------O 1015 :\ : cost=5| :/ \: |cost=5 : /: 1016 : \ : +-O cost <= 30 O-+ : / : 1017 : \------\ : : : : /------/ : 1018 : cost>=30 \: :.................: :/ cost>=30 : 1019 : O-----+ +-----O : 1020 :...........: | .........E......... | :...........: 1021 | : /-------------\ : | 1022 cost=5| :/ \: |cost=5 1023 +---O cost >= 30 O---+ 1024 : : 1025 :.................: 1027 Figure 9 - Multi-domain with many domains (Topology information) 1029 The actual cost of each intra-domain path is not known a priori from 1030 the abstract topology information. The Multi-domain controller only 1031 knows, from the TE topology provided by the underlying domain 1032 controllers, the feasibility of some intra-domain paths and some 1033 upper-bound and/or lower-bound cost information. With this 1034 information, together with the cost of inter-domain links, the 1035 Multi-domain controller can understand by its own that: 1037 o Domain B cannot be selected as the path connecting domains A and 1038 E is not feasible; 1040 o Domain E cannot be selected as a transit domain since it is know 1041 from the abstract topology information provided by domain 1042 controllers that the cost of the multi-domain path A-E-F (which 1043 is 100, in the best case) will be always be higher than the cost 1044 of the multi-domain paths A-D-F (which is 90, in the worst case) 1045 and A-E-F (which is 80, in the worst case) 1047 Therefore, the Multi-domain controller can understand by its own 1048 that the optimal multi-domain path could be either A-D-F or A-E-F 1049 but it cannot known which one of the two possible option actually 1050 provides the optimal end-to-end path. 1052 The Multi-domain controller can therefore request path computation 1053 only to the TE domain controllers A, D, E and F (and not to all the 1054 possible TE domain controllers). 1056 .........B......... 1057 : : 1058 +---O O---+ 1059 ......A...... | :.................: | ......F...... 1060 : : | | : : 1061 : O-----+ .........C......... +-----O : 1062 : : : /-------------\ : : : 1063 : : :/ \: : : 1064 : cost=15 O---------O cost = 25 O---------O cost=10 : 1065 : /: cost=5 : : cost=5 :\ : 1066 : /------/ : :.................: : \------\ : 1067 : / : : \ : 1068 :/ cost=10 : .........D......... : cost=15 \: 1069 O-----------O-------+ : /-------------\ : +-------O-----------O 1070 : : cost=5| :/ \: |cost=5 : : 1071 : : +-O cost = 15 O-+ : : 1072 : : : : : : 1073 : : :.................: : : 1074 : O-----+ +-----O : 1075 :...........: | .........E......... | :...........: 1076 | : : | 1077 +---O O---+ 1078 :.................: 1080 Figure 10 - Multi-domain with many domains (Path Computation 1081 information) 1083 Based on these requests, the Multi-domain controller can know the 1084 actual cost of each intra-domain paths which belongs to potential 1085 optimal end-to-end paths, as shown in Figure 10, and then compute 1086 the optimal end-to-end path (e.g., A-D-F, having total cost of 50, 1087 instead of A-C-F having a total cost of 70). 1089 3.3. Stateless and Stateful Path Computation 1091 The TE Tunnel YANG model, defined in [TE-TUNNEL], can support the 1092 need to request path computation. 1094 It is possible to request path computation by configuring a 1095 "compute-only" TE tunnel and retrieving the computed path(s) in the 1096 LSP(s) Record-Route Object (RRO) list as described in section 3.3.1 1097 of [TE-TUNNEL]. 1099 This is a stateful solution since the state of each created 1100 "compute-only" TE tunnel needs to be maintained and updated, when 1101 underlying network conditions change. 1103 It is very useful to provide options for both stateless and stateful 1104 path computation mechanisms. It is suggested to use stateless 1105 mechanisms as much as possible and to rely on stateful path 1106 computation when really needed. 1108 Stateless RPC allows requesting path computation using a simple 1109 atomic operation and it is the natural option/choice, especially 1110 with stateless PCE. The stateless path computation solution assumes 1111 that the underlying SDN controller (e.g., a PNC) will compute a path 1112 twice during the process to setup an LSP: at time T1, when its 1113 client (e.g., an MDSC) sends a path computation RPC request to it, 1114 and later, at time T2, when the same client (MDSC) creates a 1115 te-tunnel requesting the setup of the LSP. The underlying assumption 1116 is that, if network conditions have not changed, the same path that 1117 has been computed at time T1 is also computed at time T2 by the 1118 underlying SDN controller (e.g. PNC) and therefore the path that is 1119 setup at time T2 is exactly the same path that has been computed at 1120 time T1. 1122 Since the operation is stateless, there is no guarantee that the 1123 returned path would still be available when path setup is requested: 1124 this does not cause major issues in case the time between path 1125 computation and path setup is short (especially if compared with the 1126 time that would be needed to update the information of a very 1127 detailed connectivity matrix). 1129 In most of the cases, there is even no need to guarantee that the 1130 path that has been setup is the exactly same as the path that has 1131 been returned by path computation, especially if it has the same or 1132 even better metrics. Depending on the abstraction level applied by 1133 the server, the client may also not know the actual computed path. 1135 The most important requirement is that the required global 1136 objectives (e.g., multi-domain path metrics and constraints) are 1137 met. For this reason a path verification phase is necessary to 1138 verify that the actual path that has been setup meets the global 1139 objectives (for example in a multi-domain network, the resulting 1140 end-to-end path meets the required end-to-end metrics and 1141 constraints). 1143 In most of the cases, even if the setup path is not exactly the same 1144 as the path returned by path computation, its metrics and 1145 constraints are "good enough" (the path verification passes 1146 successfully). In the few corner cases where the path verification 1147 fails, it is possible repeat the whole process (path computation, 1148 path setup and path verification). 1150 In case the stateless solution is not sufficient and it would be the 1151 need to setup at T2 exactly the same path computed at T1 a stateful 1152 solution, based on "compute-only" TE tunnel, could be used to get 1153 notifications in case the computed path has been changed. In this 1154 case at time T1, the client (MDSC) creates a te-tunnel in a 1155 compute-only mode in the config DS and later, at time T2, changes 1156 the configuration of that te-tunnel (not to be any more in a 1157 compute-only mode) to trigger the setup of the LSP. 1159 It is worth noting that also the stateful solution, although 1160 increasing the likelihood that the computed path is available at 1161 path setup, does not guaranteed that because notifications may not 1162 be reliable or delivered on time. Path verification is needed also 1163 when stateful path computation is used. 1165 The stateful path computation has also the following drawbacks: 1167 o Several messages required for any path computation 1169 o Requires persistent storage in the provider controller 1171 o Need for garbage collection for stranded paths 1172 o Process burden to detect changes on the computed paths in order 1173 to provide notifications update 1175 3.3.1. Temporary reporting of the computed path state 1177 This section describes an optional extension to the stateless 1178 behavior where the underlying SDN controller, after having received 1179 a path computation RPC request, maintains some "temporary 1180 state" associated with the computed path, allowing the client to 1181 request the setup of exactly that path, if still available. 1183 This is similar to the stateful solution but, to avoid the drawbacks 1184 of the stateful approach, is leveraging the path computation RPC and 1185 the separation between configuration and operational DS, as defined 1186 in the NMDA architecture [RFC8342]. 1188 The underlying SDN controller, after having computed a path, as 1189 requested by a path computation RPC, also creates a te-tunnel 1190 instance within the operational DS, to store that computed path. 1191 This would be similar to the stateful solution with the only 1192 difference that there is no associated te-tunnel instance within the 1193 running DS. 1195 Since underlying SDN controller stores in the operational DS the 1196 computed path based on an abstract topology it exposes, it also 1197 remembers, internally, which is the actual native path (physical 1198 path), within its native topology (physical topology), associated 1199 with that compute-only te-tunnel instance. 1201 Afterwards, the client (e.g., MDSC) can request to setup that 1202 specific path by creating a te-tunnel instance (not in compute-only 1203 mode) in the running DS using the same tunnel-name of 1204 the existing te-tunnel in the operational datastore: this will 1205 trigger the underlying SDN controller to setup that path, if still 1206 available. 1208 There are still cases where the path being setup is not exactly the 1209 same as the path that has been computed: 1211 o When the tunnel is configured with path constraints which are not 1212 compatible with the computed path 1214 o When the tunnel setup is requested after the resources of the 1215 computed path are no longer available 1217 o When the tunnel setup is requested after the computed path is no 1218 longer known (e.g. due to a server reboot) by the underlying SDN 1219 controller 1221 In all these cases, the underlying SDN controller should compute and 1222 setup a new path. 1224 Therefore the "path verification" phase, as described in section 3.3 1225 above, is still needed to check that the path that has been setup is 1226 still "good enough". 1228 Since this new approach is not completely stateless, garbage 1229 collection is implemented using a timeout that, when it expires, 1230 triggers the removal of the computed path from the operational DS. 1231 This operation is fully controlled by the underlying SDN controller 1232 without the need for any action to be taken by the client that is 1233 not able to act on the operational datastore. The default value of 1234 this timeout is 10 minutes but a different value may be configured 1235 by the client. 1237 In addition, it is possible for the client to tag each path 1238 computation requests with a transaction-id allowing for a faster 1239 removal of all the paths associated with a transaction-id, without 1240 waiting for their timers to expire. 1242 The underlying SDN controller can remove from the operational DS all 1243 the paths computed with a given transaction-id which have not been 1244 setup either when it receives a Path Delete RPC request for that 1245 transaction-id or, automatically, right after the setup up of a path 1246 that have been previously computed with that transaction-id. 1248 This possibility is useful when multiple paths are computed but, at 1249 most, only one is setup (e.g., in multi-domain path computation 1250 scenario scenarios). After the selected path has been setup (e.g, in 1251 one domain during multi-domain path setup), all the other 1252 alternative computed paths can be automatically deleted by the 1253 underlying SDN controller (since no longer needed). The client can 1254 also request, using the Path Delete RPC request, the underlying SDN 1255 controller to remove all the computed paths, if none of them is 1256 going to be setup (e.g., in a transit domain not being selected by 1257 multi-domain path computation and so not being automatically 1258 deleted). 1260 This approach is complimentary and not alternative to the timer 1261 which is always needed to avoid stranded computed paths being stored 1262 in the operational DS when no path is setup and no explicit delete 1263 RPC is received. 1265 4. Path Computation and Optimization for multiple paths 1267 There are use cases, where it is advantageous to request path 1268 computation for a set of paths, through a network or through a 1269 network domain, using a single request [RFC5440]. 1271 In this case, sending a single request for multiple path 1272 computations, instead of sending multiple requests for each path 1273 computation, would reduce the protocol overhead and it would consume 1274 less resources (e.g., threads in the client and server). 1276 In the context of a typical multi-domain TE network, there could 1277 multiple choices for the ingress/egress points of a domain and the 1278 Multi-domain controller needs to request path computation between 1279 all the ingress/egress pairs to select the best pair. For example, 1280 in the example of section 2.2, the Multi-domain controller needs to 1281 request the TE network controller 1 to compute the A-C and the A-D 1282 paths and to the TE network controller 2 to compute the E-H and the 1283 F-H paths. 1285 It is also possible that the Multi-domain controller receives a 1286 request to setup a group of multiple end to end connections. The 1287 multi-domain controller needs to request each TE domain controller 1288 to compute multiple paths, one (or more) for each end to end 1289 connection. 1291 There are also scenarios where it can be needed to request path 1292 computation for a set of paths in a synchronized fashion. 1294 One example could be computing multiple diverse paths. Computing a 1295 set of diverse paths in a not-synchronized fashion, leads to the 1296 possibility of not being able to satisfy the diversity requirement. 1297 In this case, it is preferable to compute a sub-optimal primary path 1298 for which a diversely routed secondary path exists. 1300 There are also scenarios where it is needed to request optimizing a 1301 set of paths using objective functions that apply to the whole set 1302 of paths, see [RFC5541], e.g. to minimize the sum of the costs of 1303 all the computed paths in the set. 1305 5. YANG Model for requesting Path Computation 1307 This document define a YANG stateless RPC to request path 1308 computation as an "augmentation" of tunnel-rpc, defined in [TE- 1309 TUNNEL]. This model provides the RPC input attributes that are 1310 needed to request path computation and the RPC output attributes 1311 that are needed to report the computed paths. 1313 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1314 +---- path-request* [request-id] 1315 | +---- request-id uint32 1316 ........... 1318 augment /te:tunnels-rpc/te:output/te:result: 1319 +--ro response* [response-id] 1320 +--ro response-id uint32 1321 +--ro (response-type)? 1322 +--:(no-path-case) 1323 | +--ro no-path! 1324 +--:(path-case) 1325 +--ro computed-path 1326 ........... 1328 This model extensively re-uses the grouping defined in [TE-TUNNEL] 1329 to ensure maximal syntax and semantics commonality. 1331 This YANG model allows one RPC to include multiple path requests, 1332 each path request being identified by a request-id. Therefore, one 1333 RPC can return multiple responses, one for each path request, being 1334 identified by a response-id equal to the corresponding request-id. 1336 5.1. Synchronization of multiple path computation requests 1338 The YANG model permits to synchronize a set of multiple path 1339 requests (identified by specific request-id) all related to a "svec" 1340 container emulating the syntax of "SVEC" PCEP object [RFC5440]. 1342 +---- synchronization* [synchronization-id] 1343 +---- synchronization-id uint32 1344 +---- svec 1345 | +---- relaxable? boolean 1346 | +---- disjointness? te-types:te-path-disjointness 1347 | +---- request-id-number* uint32 1348 +---- svec-constraints 1349 | +---- path-metric-bound* [metric-type] 1350 | +---- metric-type identityref 1351 | +---- upper-bound? uint64 1352 +---- path-srlgs-values 1353 | +---- usage? identityref 1354 | +---- values* srlg 1355 +---- path-srlgs-names 1356 | +---- path-srlgs-name* [usage] 1357 | +---- usage identityref 1358 | +---- srlg-name* [name] 1359 | +---- name string 1360 +---- exclude-objects 1361 ........... 1362 +---- optimizations 1363 +---- (algorithm)? 1364 +--:(metric) 1365 | +---- optimization-metric* [metric-type] 1366 | +---- metric-type identityref 1367 | +---- weight? uint8 1368 +--:(objective-function) 1369 +---- objective-function 1370 +---- objective-function-type? identityref 1372 The model, in addition to the metric types, defined in [TE-TUNNEL], 1373 which can be applied to each individual path request, defines 1374 additional specific metrics types that apply to a set of 1375 synchronized requests, as referenced in [RFC5541]. 1377 identity svec-metric-type { 1378 description 1379 "Base identity for svec metric type"; 1380 } 1382 identity svec-metric-cumul-te { 1383 base svec-metric-type; 1384 description 1385 "TE cumulative path metric"; 1386 } 1387 identity svec-metric-cumul-igp { 1388 base svec-metric-type; 1389 description 1390 "IGP cumulative path metric"; 1391 } 1393 identity svec-metric-cumul-hop { 1394 base svec-metric-type; 1395 description 1396 "Hop cumulative path metric"; 1397 } 1399 identity svec-metric-aggregate-bandwidth-consumption { 1400 base svec-metric-type; 1401 description 1402 "Cumulative bandwith consumption of the set of 1403 synchronized paths"; 1404 } 1406 identity svec-metric-load-of-the-most-loaded-link { 1407 base svec-metric-type; 1408 description 1409 "Load of the most loaded link"; 1410 } 1412 5.2. Returned metric values 1414 This YANG model provides a way to return the values of the metrics 1415 computed by the path computation in the output of RPC, together with 1416 other important information (e.g. srlg, affinities, explicit route), 1417 emulating the syntax of the "C" flag of the "METRIC" PCEP object 1418 [RFC5440]: 1420 augment /te:tunnels-rpc/te:output/te:result: 1421 +--ro response* [response-id] 1422 +--ro response-id uint32 1423 +--ro (response-type)? 1424 +--:(no-path-case) 1425 | +--ro no-path! 1426 +--:(path-case) 1427 +--ro computed-path 1428 +--ro path-id? yang-types:uuid 1429 +--ro path-properties 1430 +--ro path-metric* [metric-type] 1431 | +--ro metric-type identityref 1432 | +--ro accumulative-value? uint64 1433 +--ro path-affinities-values 1434 | +--ro path-affinities-value* [usage] 1435 | +--ro usage identityref 1436 | +--ro value? admin-groups 1437 +--ro path-affinity-names 1438 | +--ro path-affinity-name* [usage] 1439 | +--ro usage identityref 1440 | +--ro affinity-name* [name] 1441 | +--ro name string 1442 +--ro path-srlgs-values 1443 | +--ro usage? identityref 1444 | +--ro values* srlg 1445 +--ro path-srlgs-names 1446 | +--ro path-srlgs-name* [usage] 1447 | +--ro usage identityref 1448 | +--ro srlg-name* [name] 1449 | +--ro name string 1450 +--ro path-route-objects 1451 ........... 1453 It also allows to request in the input of RPC which information 1454 (metrics, srlg and/or affinities) should be returned: 1456 module: ietf-te-path-computation 1457 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1458 +---- path-request* [request-id] 1459 | +---- request-id uint32 1460 ........... 1461 | +---- requested-metrics* [metric-type] 1462 | | +---- metric-type identityref 1463 | +---- return-srlgs? boolean 1464 | +---- return-affinities? boolean 1465 ........... 1467 This feature is essential for using a stateless path computation in 1468 a multi-domain TE network as described in section 2.2. In this case, 1469 the metrics returned by a path computation requested to a given TE 1470 network controller must be used by the client to compute the best 1471 end-to-end path. If they are missing the client cannot compare 1472 different paths calculated by the TE network controllers and choose 1473 the best one for the optimal e2e path. 1475 5.3. Multiple Paths Requests for the same TE Tunnel 1477 Note - This section describes the models changes that are proposed 1478 and not yet defined in section 6. See Appendix B for an overview of 1479 the YANG Tree that would results from these proposed changes. 1481 The YANG model allows including multiple requests for different 1482 paths intended to be used within the same tunnel or within different 1483 tunnels. 1485 When multiple requested paths are intended to be used within the 1486 same tunnel, the set of attributes that are usually configured on 1487 per-tunnel basis rather than on per-path basis (e.g., tunnel-name, 1488 source/destination TTP, encoding and switching-type) are common to 1489 all these path requests. 1491 Therefore, it is proposed to define, within the path computation 1492 request RPC, a tunnel-attributes list: 1494 +---- tunnel-attributes* [tunnel-name] 1495 | +---- tunnel-name string 1496 | +---- encoding? identityref 1497 | +---- switching-type? identityref 1498 | ........... 1500 The path requests that are intended to be used within the same 1501 tunnel should reference the same entry in the tunnel-attributes 1502 list. This allows: 1504 o avoiding repeating the same set of per-tunnel parameters on 1505 multiple requested paths; 1507 o the server to understand what attributes (e.g., te-bandwidth) are 1508 intended to be configured on a per-tunnel basis and what 1509 attributes (e.g., te-bandwidth) are intended to be configured on 1510 a per-path basis. This could be useful especially when the server 1511 also creates a te-tunnel instance within the operational DS to 1512 report the computed paths, as described in section 3.3.1: in this 1513 case, the tunnel-name is also used as the suggested name for that 1514 te-tunnel instance. 1516 The YANG model allows also including requests for paths intended to 1517 modify existing tunnels (e.g., adding a protection path for an 1518 existing un-protected tunnel). In this case, the per-tunnel 1519 attributes are already provided in the existing te-tunnel instance 1520 and do not need to be re-configured in the path computation request 1521 RPC. Therefore, these requests should reference an existing te- 1522 tunnel instance. 1524 Open issue: need to evaluate whether this te-tunnel instance should 1525 be within the operational DS or within the intended DS, or maybe, on 1526 either one of the two DS 1528 It is also possible to request computing paths without indicating in 1529 which tunnel they are intended to be used (e.g., in case of an 1530 unprotected tunnel). In this case, the per-tunnel attributes should 1531 be provided together with the per-path attributes, without using the 1532 tunnel-attributes list. 1534 The choices below are proposed to be added to the model to 1535 distinguish whether the per-tunnel attributes are configured by 1536 value or by reference, to either an existing te-tunnel instance or 1537 to an entry of the tunnel-attributes list: 1539 +---- (tunnel-attributes)? 1540 | +----:(reference) 1541 | | +---- (tunnel-exist)? 1542 | | | +----:(tunnel-ref) 1543 | | | | +---- tunnel-ref leafref 1544 | | | +----:(tunnel-attributes-ref) 1545 | | | | +---- tunnel-attributes-ref leafref 1546 | | ........... 1547 | +----:(values) 1548 | | +---- tunnel-name? string 1549 | | +---- encoding? identityref 1550 | | +---- switching-type? identityref 1551 | | ........... 1553 The (values) case will provide the set of attributes that are 1554 usually configured on per-tunnel basis rather than on per-path basis 1555 (e.g., tunnel-name, source/destination TTP, encoding and switching- 1556 type). 1558 The (reference) case provides the information needed to associate 1559 multiple path requests that are intended to be used within the same 1560 tunnel. 1562 In order to indicate the role of the path being requested within the 1563 intended tunnel (e.g., primary or secondary path), the following 1564 choice is proposed to be added within the (reference) case: 1566 +---- (path-role)? 1567 | +----:(candidate-primary-path) 1568 | | +---- candidate-primary-path empty 1569 | +----:(candidate-secondary-path) 1570 | | +---- candidate-secondary-path 1571 | | | ........... 1573 The candidate-secondary-path container references its associated 1574 primary path which may already exist or be requested within the same 1575 path computation RPC, as described in the proposal below: 1577 +---- candidate-secondary-path 1578 | +---- (primary-path-exist)? 1579 | | +----:(primary-path-reference) 1580 | | | +---- primary-path-ref leafref 1581 | | +----:(primary-path-request) 1582 | | | +---- primary-path-request-id uint32 1583 ........... 1585 6. YANG model for stateless TE path computation 1587 6.1. YANG Tree 1589 Figure 11 below shows the tree diagram of the YANG model defined in 1590 module ietf-te-path-computation.yang. 1592 module: ietf-te-path-computation 1593 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1594 +-- path-request* [request-id] 1595 | +-- request-id uint32 1596 | +-- encoding? identityref 1597 | +-- switching-type? identityref 1598 | +-- source? inet:ip-address 1599 | +-- destination? inet:ip-address 1600 | +-- src-tp-id? binary 1601 | +-- dst-tp-id? binary 1602 | +-- bidirectional? boolean 1603 | +-- te-topology-identifier 1604 | | +-- provider-id? te-global-id 1605 | | +-- client-id? te-global-id 1606 | | +-- topology-id? te-topology-id 1607 | +-- explicit-route-objects-always 1608 | | +-- route-object-exclude-always* [index] 1609 | | | +-- index uint32 1610 | | | +-- (type)? 1611 | | | +--:(numbered-node-hop) 1612 | | | | +-- numbered-node-hop 1613 | | | | +-- node-id te-node-id 1614 | | | | +-- hop-type? te-hop-type 1615 | | | +--:(numbered-link-hop) 1616 | | | | +-- numbered-link-hop 1617 | | | | +-- link-tp-id te-tp-id 1618 | | | | +-- hop-type? te-hop-type 1619 | | | | +-- direction? te-link-direction 1620 | | | +--:(unnumbered-link-hop) 1621 | | | | +-- unnumbered-link-hop 1622 | | | | +-- link-tp-id te-tp-id 1623 | | | | +-- node-id te-node-id 1624 | | | | +-- hop-type? te-hop-type 1625 | | | | +-- direction? te-link-direction 1626 | | | +--:(as-number) 1627 | | | | +-- as-number-hop 1628 | | | | +-- as-number inet:as-number 1629 | | | | +-- hop-type? te-hop-type 1630 | | | +--:(label) 1631 | | | +-- label-hop 1632 | | | +-- te-label 1633 | | | +-- (technology)? 1634 | | | | +--:(generic) 1635 | | | | +-- generic? rt-types:generalized- 1636 label 1637 | | | +-- direction? te-label-direction 1638 | | +-- route-object-include-exclude* [index] 1639 | | +-- explicit-route-usage? identityref 1640 | | +-- index uint32 1641 | | +-- (type)? 1642 | | +--:(numbered-node-hop) 1643 | | | +-- numbered-node-hop 1644 | | | +-- node-id te-node-id 1645 | | | +-- hop-type? te-hop-type 1646 | | +--:(numbered-link-hop) 1647 | | | +-- numbered-link-hop 1648 | | | +-- link-tp-id te-tp-id 1649 | | | +-- hop-type? te-hop-type 1650 | | | +-- direction? te-link-direction 1651 | | +--:(unnumbered-link-hop) 1652 | | | +-- unnumbered-link-hop 1653 | | | +-- link-tp-id te-tp-id 1654 | | | +-- node-id te-node-id 1655 | | | +-- hop-type? te-hop-type 1656 | | | +-- direction? te-link-direction 1657 | | +--:(as-number) 1658 | | | +-- as-number-hop 1659 | | | +-- as-number inet:as-number 1660 | | | +-- hop-type? te-hop-type 1661 | | +--:(label) 1662 | | | +-- label-hop 1663 | | | +-- te-label 1664 | | | +-- (technology)? 1665 | | | | +--:(generic) 1666 | | | | +-- generic? rt-types:generalized- 1667 label 1668 | | | +-- direction? te-label-direction 1669 | | +--:(srlg) 1670 | | +-- srlg 1671 | | +-- srlg? uint32 1672 | +-- path-constraints 1673 | | +-- te-bandwidth 1674 | | | +-- (technology)? 1675 | | | +--:(generic) 1676 | | | +-- generic? te-bandwidth 1677 | | +-- link-protection? identityref 1678 | | +-- setup-priority? uint8 1679 | | +-- hold-priority? uint8 1680 | | +-- signaling-type? identityref 1681 | | +-- path-metric-bounds 1682 | | | +-- path-metric-bound* [metric-type] 1683 | | | +-- metric-type identityref 1684 | | | +-- upper-bound? uint64 1685 | | +-- path-affinities-values 1686 | | | +-- path-affinities-value* [usage] 1687 | | | +-- usage identityref 1688 | | | +-- value? admin-groups 1689 | | +-- path-affinity-names 1690 | | | +-- path-affinity-name* [usage] 1691 | | | +-- usage identityref 1692 | | | +-- affinity-name* [name] 1693 | | | +-- name string 1694 | | +-- path-srlgs-lists 1695 | | | +-- path-srlgs-list* [usage] 1696 | | | +-- usage identityref 1697 | | | +-- values* srlg 1698 | | +-- path-srlgs-names 1699 | | | +-- path-srlgs-name* [usage] 1700 | | | +-- usage identityref 1701 | | | +-- names* string 1702 | | +-- disjointness? te-path-disjointness 1703 | +-- optimizations 1704 | | +-- (algorithm)? 1705 | | +--:(metric) {path-optimization-metric}? 1706 | | | +-- optimization-metric* [metric-type] 1707 | | | | +-- metric-type identityref 1708 | | | | +-- weight? uint8 1709 | | | | +-- explicit-route-exclude-objects 1710 | | | | | +-- route-object-exclude-object* [index] 1711 | | | | | +-- index uint32 1712 | | | | | +-- (type)? 1713 | | | | | +--:(numbered-node-hop) 1714 | | | | | | +-- numbered-node-hop 1715 | | | | | | +-- node-id te-node-id 1716 | | | | | | +-- hop-type? te-hop-type 1717 | | | | | +--:(numbered-link-hop) 1718 | | | | | | +-- numbered-link-hop 1719 | | | | | | +-- link-tp-id te-tp-id 1720 | | | | | | +-- hop-type? te-hop-type 1721 | | | | | | +-- direction? te-link- 1722 direction 1723 | | | | | +--:(unnumbered-link-hop) 1724 | | | | | | +-- unnumbered-link-hop 1725 | | | | | | +-- link-tp-id te-tp-id 1726 | | | | | | +-- node-id te-node-id 1727 | | | | | | +-- hop-type? te-hop-type 1728 | | | | | | +-- direction? te-link- 1729 direction 1730 | | | | | +--:(as-number) 1731 | | | | | | +-- as-number-hop 1732 | | | | | | +-- as-number inet:as-number 1733 | | | | | | +-- hop-type? te-hop-type 1734 | | | | | +--:(label) 1735 | | | | | | +-- label-hop 1736 | | | | | | +-- te-label 1737 | | | | | | +-- (technology)? 1738 | | | | | | | +--:(generic) 1739 | | | | | | | +-- generic? rt- 1740 types:generalized-label 1741 | | | | | | +-- direction? te-label- 1742 direction 1743 | | | | | +--:(srlg) 1744 | | | | | +-- srlg 1745 | | | | | +-- srlg? uint32 1746 | | | | +-- explicit-route-include-objects 1747 | | | | +-- route-object-include-object* [index] 1748 | | | | +-- index uint32 1749 | | | | +-- (type)? 1750 | | | | +--:(numbered-node-hop) 1751 | | | | | +-- numbered-node-hop 1752 | | | | | +-- node-id te-node-id 1753 | | | | | +-- hop-type? te-hop-type 1754 | | | | +--:(numbered-link-hop) 1755 | | | | | +-- numbered-link-hop 1756 | | | | | +-- link-tp-id te-tp-id 1757 | | | | | +-- hop-type? te-hop-type 1758 | | | | | +-- direction? te-link- 1759 direction 1760 | | | | +--:(unnumbered-link-hop) 1761 | | | | | +-- unnumbered-link-hop 1762 | | | | | +-- link-tp-id te-tp-id 1763 | | | | | +-- node-id te-node-id 1764 | | | | | +-- hop-type? te-hop-type 1765 | | | | | +-- direction? te-link- 1766 direction 1767 | | | | +--:(as-number) 1768 | | | | | +-- as-number-hop 1769 | | | | | +-- as-number inet:as-number 1770 | | | | | +-- hop-type? te-hop-type 1771 | | | | +--:(label) 1772 | | | | +-- label-hop 1773 | | | | +-- te-label 1774 | | | | +-- (technology)? 1775 | | | | | +--:(generic) 1776 | | | | | +-- generic? rt- 1777 types:generalized-label 1778 | | | | +-- direction? te-label- 1779 direction 1780 | | | +-- tiebreakers 1781 | | | +-- tiebreaker* [tiebreaker-type] 1782 | | | +-- tiebreaker-type identityref 1783 | | +--:(objective-function) {path-optimization-objective- 1784 function}? 1785 | | +-- objective-function 1786 | | +-- objective-function-type? identityref 1787 | +-- path-in-segment! 1788 | | +-- label-restrictions 1789 | | +-- label-restriction* [index] 1790 | | +-- restriction? enumeration 1791 | | +-- index uint32 1792 | | +-- label-start 1793 | | | +-- te-label 1794 | | | +-- (technology)? 1795 | | | | +--:(generic) 1796 | | | | +-- generic? rt-types:generalized- 1797 label 1798 | | | +-- direction? te-label-direction 1799 | | +-- label-end 1800 | | | +-- te-label 1801 | | | +-- (technology)? 1802 | | | | +--:(generic) 1803 | | | | +-- generic? rt-types:generalized- 1804 label 1805 | | | +-- direction? te-label-direction 1806 | | +-- label-step 1807 | | | +-- (technology)? 1808 | | | +--:(generic) 1809 | | | +-- generic? int32 1810 | | +-- range-bitmap? yang:hex-string 1811 | +-- path-out-segment! 1812 | | +-- label-restrictions 1813 | | +-- label-restriction* [index] 1814 | | +-- restriction? enumeration 1815 | | +-- index uint32 1816 | | +-- label-start 1817 | | | +-- te-label 1818 | | | +-- (technology)? 1819 | | | | +--:(generic) 1820 | | | | +-- generic? rt-types:generalized- 1821 label 1822 | | | +-- direction? te-label-direction 1823 | | +-- label-end 1824 | | | +-- te-label 1825 | | | +-- (technology)? 1826 | | | | +--:(generic) 1827 | | | | +-- generic? rt-types:generalized- 1828 label 1829 | | | +-- direction? te-label-direction 1830 | | +-- label-step 1831 | | | +-- (technology)? 1832 | | | +--:(generic) 1833 | | | +-- generic? int32 1834 | | +-- range-bitmap? yang:hex-string 1835 | +-- requested-metrics* [metric-type] 1836 | | +-- metric-type identityref 1837 | +-- return-srlgs? boolean 1838 | +-- return-affinities? boolean 1839 | +-- requested-state! 1840 | +-- timer? uint16 1841 | +-- transaction-id? string 1842 | +-- tunnel-name? string 1843 | +-- (path)? 1844 | +--:(primary) 1845 | | +-- primary-path-name? string 1846 | +--:(secondary) 1847 | +-- secondary-path-name? string 1848 +-- synchronization* [synchronization-id] 1849 +-- synchronization-id uint32 1850 +-- svec 1851 | +-- relaxable? boolean 1852 | +-- disjointness? te-path-disjointness 1853 | +-- request-id-number* uint32 1854 +-- svec-constraints 1855 | +-- path-metric-bound* [metric-type] 1856 | +-- metric-type identityref 1857 | +-- upper-bound? uint64 1858 +-- path-srlgs-lists 1859 | +-- path-srlgs-list* [usage] 1860 | +-- usage identityref 1861 | +-- values* srlg 1862 +-- path-srlgs-names 1863 | +-- path-srlgs-name* [usage] 1864 | +-- usage identityref 1865 | +-- names* string 1866 +-- exclude-objects 1867 | +-- excludes* [index] 1868 | +-- index uint32 1869 | +-- (type)? 1870 | +--:(numbered-node-hop) 1871 | | +-- numbered-node-hop 1872 | | +-- node-id te-node-id 1873 | | +-- hop-type? te-hop-type 1874 | +--:(numbered-link-hop) 1875 | | +-- numbered-link-hop 1876 | | +-- link-tp-id te-tp-id 1877 | | +-- hop-type? te-hop-type 1878 | | +-- direction? te-link-direction 1879 | +--:(unnumbered-link-hop) 1880 | | +-- unnumbered-link-hop 1881 | | +-- link-tp-id te-tp-id 1882 | | +-- node-id te-node-id 1883 | | +-- hop-type? te-hop-type 1884 | | +-- direction? te-link-direction 1885 | +--:(as-number) 1886 | | +-- as-number-hop 1887 | | +-- as-number inet:as-number 1888 | | +-- hop-type? te-hop-type 1889 | +--:(label) 1890 | +-- label-hop 1891 | +-- te-label 1892 | +-- (technology)? 1893 | | +--:(generic) 1894 | | +-- generic? rt-types:generalized- 1895 label 1896 | +-- direction? te-label-direction 1897 +-- optimizations 1898 +-- (algorithm)? 1899 +--:(metric) {te-types:path-optimization-metric}? 1900 | +-- optimization-metric* [metric-type] 1901 | +-- metric-type identityref 1902 | +-- weight? uint8 1903 +--:(objective-function) {te-types:path-optimization- 1904 objective-function}? 1905 +-- objective-function 1906 +-- objective-function-type? identityref 1907 augment /te:tunnels-rpc/te:output/te:result: 1908 +--ro response* [response-id] 1909 +--ro response-id uint32 1910 +--ro (response-type)? 1911 +--:(no-path-case) 1912 | +--ro no-path! 1913 +--:(path-case) 1914 +--ro computed-path 1915 +--ro path-properties 1916 | +--ro path-metric* [metric-type] 1917 | | +--ro metric-type identityref 1918 | | +--ro accumulative-value? uint64 1919 | +--ro path-affinities-values 1920 | | +--ro path-affinities-value* [usage] 1921 | | +--ro usage identityref 1922 | | +--ro value? admin-groups 1923 | +--ro path-affinity-names 1924 | | +--ro path-affinity-name* [usage] 1925 | | +--ro usage identityref 1926 | | +--ro affinity-name* [name] 1927 | | +--ro name string 1928 | +--ro path-srlgs-lists 1929 | | +--ro path-srlgs-list* [usage] 1930 | | +--ro usage identityref 1931 | | +--ro values* srlg 1932 | +--ro path-srlgs-names 1933 | | +--ro path-srlgs-name* [usage] 1934 | | +--ro usage identityref 1935 | | +--ro names* string 1936 | +--ro path-route-objects 1937 | +--ro path-route-object* [index] 1938 | +--ro index uint32 1939 | +--ro (type)? 1940 | +--:(numbered-node-hop) 1941 | | +--ro numbered-node-hop 1942 | | +--ro node-id te-node-id 1943 | | +--ro hop-type? te-hop-type 1944 | +--:(numbered-link-hop) 1945 | | +--ro numbered-link-hop 1946 | | +--ro link-tp-id te-tp-id 1947 | | +--ro hop-type? te-hop-type 1948 | | +--ro direction? te-link- 1949 direction 1950 | +--:(unnumbered-link-hop) 1951 | | +--ro unnumbered-link-hop 1952 | | +--ro link-tp-id te-tp-id 1953 | | +--ro node-id te-node-id 1954 | | +--ro hop-type? te-hop-type 1955 | | +--ro direction? te-link- 1956 direction 1957 | +--:(as-number) 1958 | | +--ro as-number-hop 1959 | | +--ro as-number inet:as-number 1960 | | +--ro hop-type? te-hop-type 1961 | +--:(label) 1962 | +--ro label-hop 1963 | +--ro te-label 1964 | +--ro (technology)? 1965 | | +--:(generic) 1966 | | +--ro generic? rt- 1967 types:generalized-label 1968 | +--ro direction? te- 1969 label-direction 1970 +--ro tunnel-ref? te:tunnel-ref 1971 +--ro (path)? 1972 +--:(primary) 1973 | +--ro primary-path-ref? -> 1974 /te:te/tunnels/tunnel[te:name=current()/../tunnel-ref]/p2p-primary- 1975 paths/p2p-primary-path/name 1976 +--:(secondary) 1977 +--ro secondary-path-ref? -> 1978 /te:te/tunnels/tunnel[te:name=current()/../tunnel-ref]/p2p- 1979 secondary-paths/p2p-secondary-path/name 1980 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1982 +-- deleted-paths-transaction-id* string 1983 augment /te:tunnels-rpc/te:output/te:result: 1984 +-- deleted-paths-transaction-id* string 1986 Figure 11 - TE path computation YANG tree 1988 6.2. YANG Module 1990 file "ietf-te-path-computation@2019-03-11.yang" 1991 module ietf-te-path-computation { 1992 yang-version 1.1; 1993 namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation"; 1994 // replace with IANA namespace when assigned 1996 prefix "tepc"; 1998 import ietf-inet-types { 1999 prefix "inet"; 2000 } 2002 import ietf-te { 2003 prefix "te"; 2004 } 2006 import ietf-te-types { 2007 prefix "te-types"; 2008 } 2010 organization 2011 "Traffic Engineering Architecture and Signaling (TEAS) 2012 Working Group"; 2014 contact 2015 "WG Web: 2016 WG List: 2018 WG Chair: Lou Berger 2019 2021 WG Chair: Vishnu Pavan Beeram 2022 2024 "; 2026 description "YANG model for stateless TE path computation"; 2028 revision "2019-03-11" { 2029 description 2030 "Initial revision"; 2031 reference 2032 "draft-ietf-teas-yang-path-computation"; 2033 } 2035 /* 2036 * Features 2037 */ 2039 feature stateless-path-computation { 2040 description 2041 "This feature indicates that the system supports 2042 stateless path computation."; 2043 } 2045 /* 2046 * Groupings 2047 */ 2049 grouping path-info { 2050 uses te-types:generic-path-properties; 2051 description "Path computation output information"; 2052 } 2054 grouping requested-info { 2055 description 2056 "This grouping defines the information (e.g., metrics) 2057 which must be returned in the response"; 2058 list requested-metrics { 2059 key 'metric-type'; 2060 description 2061 "The list of the requested metrics 2062 The metrics listed here must be returned in the response. 2063 Returning other metrics in the response is optional."; 2064 leaf metric-type { 2065 type identityref { 2066 base te-types:path-metric-type; 2067 } 2068 description 2069 "The metric that must be returned in the response"; 2070 } 2071 } 2072 leaf return-srlgs { 2073 type boolean; 2074 default false; 2075 description 2076 "If true, path srlgs must be returned in the response. 2077 If false, returning path srlgs in the response optional."; 2078 } 2079 leaf return-affinities { 2080 type boolean; 2081 default false; 2082 description 2083 "If true, path affinities must be returned in the response. 2084 If false, returning path affinities in the response is 2085 optional."; 2086 } 2087 } 2089 grouping requested-state { 2090 description 2091 "Configuration for the transient state used 2092 to report the computed path"; 2093 leaf timer { 2094 type uint16; 2095 units minutes; 2096 default 10; 2097 description 2098 "The timeout after which the transient state reporting 2099 the computed path should be removed."; 2101 } 2102 leaf transaction-id { 2103 type string; 2104 description 2105 " 2106 The transaction-id associated with this path computation 2107 to be used for fast deletion of the transient states 2108 associated with multiple path computations. 2110 This transaction-id can be used to explicitly delete all 2111 the transient states of all the computed paths associated 2112 with the same transaction-id. 2114 When one path associated with a transaction-id is setup, 2115 the transient states of all the other computed paths 2116 with the same transaction-id are automatically removed. 2118 If not specified, the transient state is removed only 2119 when the timer expires (when the timer is specified) 2120 or not created at all (stateless path computation, 2121 when the timer is not specified). 2122 "; 2123 } 2124 leaf tunnel-name { 2125 type string; 2126 description 2127 " 2128 The suggested name to be assigned to the te-tunnel 2129 instance which is created to report the computed path. 2131 In case multiple paths are requested with the same 2132 suggested name, the server will create only one te-tunnel 2133 instance to report all the computed paths 2134 with the same suggested name. 2136 A different name can be assigned by server (e.g., when a 2137 te-tunnel with this name already exists). 2138 "; 2139 } 2140 choice path { 2141 description 2142 "The transient state of the computed path can be reported 2143 as a primary or a secondary path of a te-tunnel"; 2144 case primary { 2145 leaf primary-path-name { 2146 type string; 2147 description 2148 " 2149 The suggested name to be assigned to the 2150 p2p-primary-path instance which is created 2151 to report the computed path. 2153 A different name can be assigned by the server 2154 (e.g., when a p2p-primary-path with this name 2155 already exists). 2156 "; 2157 } 2158 } 2159 case secondary { 2160 leaf secondary-path-name { 2161 type string; 2162 description 2163 " 2164 The suggested name to be assigned to the 2165 p2p-secondary-path instance which is created 2166 to report the computed path. 2168 A different name can be assigned by the server 2169 (e.g., when a p2p-secondary-path with this 2170 name already exists). 2172 If not specified, the a p2p-primary-path is created 2173 by the server. 2174 "; 2175 } 2176 } 2177 } 2178 } 2179 grouping reported-state { 2180 description 2181 "Information about the transient state created 2182 to report the computed path"; 2184 leaf tunnel-ref { 2185 type te:tunnel-ref; 2186 description 2187 " 2188 Reference to the tunnel that reports the transient state 2189 of the computed path. 2191 If no transient state is created, this attribute is empty. 2192 "; 2193 } 2194 choice path { 2195 description 2196 "The transient state of the computed path can be reported 2197 as a primary or a secondary path of a te-tunnel"; 2198 case primary { 2199 leaf primary-path-ref { 2200 type leafref { 2201 path "/te:te/te:tunnels/" + 2202 "te:tunnel[te:name=current()/../tunnel-ref]/" + 2203 "te:p2p-primary-paths/te:p2p-primary-path/" + 2204 "te:name"; 2205 } 2206 must "../tunnel-ref" { 2207 description 2208 "The primary-path-name can only be reported 2209 if also the tunnel is reported 2210 to provide the complete reference."; 2211 } 2212 description 2213 " 2214 Reference to the p2p-primary-path that reports 2215 the transient state of the computed path. 2217 If no transient state is created, 2218 this attribute is empty. 2219 "; 2220 } 2221 } 2222 case secondary { 2223 leaf secondary-path-ref { 2224 type leafref { 2225 path "/te:te/te:tunnels/" + 2226 "te:tunnel[te:name=current()/../tunnel-ref]/" + 2227 "te:p2p-secondary-paths/te:p2p-secondary-path/" + 2228 "te:name"; 2229 } 2230 must "../tunnel-ref" { 2231 description 2232 "The secondary-path-name can only be reported 2233 if also the tunnel is reported to provide 2234 the complete reference."; 2235 } 2236 description 2237 " 2238 Reference to the p2p-secondary-path that reports 2239 the transient state of the computed path. 2241 If no transient state is created, 2242 this attribute is empty. 2243 "; 2244 } 2245 } 2246 } 2247 } 2249 identity svec-metric-type { 2250 description 2251 "Base identity for svec metric type"; 2252 } 2254 identity svec-metric-cumul-te { 2255 base svec-metric-type; 2256 description 2257 "TE cumulative path metric"; 2258 } 2260 identity svec-metric-cumul-igp { 2261 base svec-metric-type; 2262 description 2263 "IGP cumulative path metric"; 2264 } 2266 identity svec-metric-cumul-hop { 2267 base svec-metric-type; 2268 description 2269 "Hop cumulative path metric"; 2270 } 2272 identity svec-metric-aggregate-bandwidth-consumption { 2273 base svec-metric-type; 2274 description 2275 "Cumulative bandwith consumption of the set of 2276 synchronized paths"; 2277 } 2279 identity svec-metric-load-of-the-most-loaded-link { 2280 base svec-metric-type; 2281 description 2282 "Load of the most loaded link"; 2283 } 2285 grouping svec-metrics-bounds_config { 2286 description 2287 "TE path metric bounds grouping for computing a set of 2288 synchronized requests"; 2289 leaf metric-type { 2290 type identityref { 2291 base svec-metric-type; 2292 } 2293 description "TE path metric type usable for computing a set of 2294 synchronized requests"; 2296 } 2297 leaf upper-bound { 2298 type uint64; 2299 description "Upper bound on end-to-end svec path metric"; 2300 } 2301 } 2303 grouping svec-metrics-optimization_config { 2304 description 2305 "TE path metric bounds grouping for computing a set of 2306 synchronized requests"; 2308 leaf metric-type { 2309 type identityref { 2310 base svec-metric-type; 2311 } 2312 description "TE path metric type usable for computing a set of 2313 synchronized requests"; 2314 } 2315 leaf weight { 2316 type uint8; 2317 description "Metric normalization weight"; 2318 } 2319 } 2321 grouping svec-exclude { 2322 description "List of resources to be excluded by all the paths 2323 in the SVEC"; 2324 container exclude-objects { 2325 description "resources to be excluded"; 2326 list excludes { 2327 key index; 2328 ordered-by user; 2329 leaf index { 2330 type uint32; 2331 description "XRO subobject index"; 2332 } 2333 description 2334 "List of explicit route objects to always exclude 2335 from synchronized path computation"; 2336 uses te-types:explicit-route-hop; 2337 } 2338 } 2339 } 2341 grouping synchronization-constraints { 2342 description "Global constraints applicable to synchronized 2343 path computation"; 2344 container svec-constraints { 2345 description "global svec constraints"; 2346 list path-metric-bound { 2347 key metric-type; 2348 description "list of bound metrics"; 2349 uses svec-metrics-bounds_config; 2350 } 2351 } 2352 uses te-types:generic-path-srlgs; 2353 uses svec-exclude; 2354 } 2356 grouping synchronization-optimization { 2357 description "Synchronized request optimization"; 2358 container optimizations { 2359 description 2360 "The objective function container that includes attributes 2361 to impose when computing a synchronized set of paths"; 2363 choice algorithm { 2364 description "Optimizations algorithm."; 2365 case metric { 2366 if-feature te-types:path-optimization-metric; 2367 list optimization-metric { 2368 key "metric-type"; 2369 description "svec path metric type"; 2370 uses svec-metrics-optimization_config; 2371 } 2372 } 2373 case objective-function { 2374 if-feature te-types:path-optimization-objective-function; 2375 container objective-function { 2376 description 2377 "The objective function container that includes 2378 attributes to impose when computing a TE path"; 2379 leaf objective-function-type { 2380 type identityref { 2381 base te-types:objective-function-type; 2382 } 2383 default te-types:of-minimize-cost-path; 2384 description "Objective function entry"; 2385 } 2386 } 2387 } 2388 } 2389 } 2390 } 2392 grouping synchronization-info { 2393 description "Information for sync"; 2394 list synchronization { 2395 key "synchronization-id"; 2396 description "sync list"; 2397 leaf synchronization-id { 2398 type uint32; 2399 description "index"; 2400 } 2401 container svec { 2402 description 2403 "Synchronization VECtor"; 2404 leaf relaxable { 2405 type boolean; 2406 default true; 2407 description 2408 "If this leaf is true, path computation process is 2409 free to ignore svec content. 2410 Otherwise, it must take into account this svec."; 2411 } 2412 uses te-types:generic-path-disjointness; 2413 leaf-list request-id-number { 2414 type uint32; 2415 description 2416 "This list reports the set of path computation 2417 requests that must be synchronized."; 2418 } 2419 } 2420 uses synchronization-constraints; 2421 uses synchronization-optimization; 2422 } 2423 } 2425 grouping no-path-info { 2426 description "no-path-info"; 2427 container no-path { 2428 presence "Response without path information, due to failure 2429 performing the path computation"; 2430 description "if path computation cannot identify a path, 2431 rpc returns no path."; 2432 } 2433 } 2435 /* 2436 * These groupings should be removed when defined in te-types 2437 */ 2439 grouping encoding-and-switching-type { 2440 description 2441 "Common grouping to define the LSP encoding and 2442 switching types"; 2444 leaf encoding { 2445 type identityref { 2446 base te-types:lsp-encoding-types; 2447 } 2448 description "LSP encoding type"; 2449 reference "RFC3945"; 2450 } 2451 leaf switching-type { 2452 type identityref { 2453 base te-types:switching-capabilities; 2454 } 2455 description "LSP switching type"; 2456 reference "RFC3945"; 2457 } 2458 } 2460 grouping tunnel-p2p-common-params { 2461 description 2462 "Common grouping to define the TE tunnel parameters"; 2464 uses encoding-and-switching-type; 2465 leaf source { 2466 type inet:ip-address; 2467 description "TE tunnel source address."; 2468 } 2469 leaf destination { 2470 type inet:ip-address; 2471 description "P2P tunnel destination address"; 2472 } 2473 leaf src-tp-id { 2474 type binary; 2475 description 2476 "TE tunnel source termination point identifier."; 2477 } 2478 leaf dst-tp-id { 2479 type binary; 2480 description 2481 "TE tunnel destination termination point identifier."; 2482 } 2483 leaf bidirectional { 2484 type boolean; 2485 default 'false'; 2486 description "TE tunnel bidirectional"; 2487 } 2488 } 2490 /* 2491 * AUGMENTS TO TE RPC 2492 */ 2494 augment "/te:tunnels-rpc/te:input/te:tunnel-info" { 2495 description "Path Computation RPC input"; 2496 list path-request { 2497 key "request-id"; 2498 description "request-list"; 2499 leaf request-id { 2500 type uint32; 2501 mandatory true; 2502 description 2503 "Each path computation request is uniquely identified 2504 by the request-id-number."; 2505 } 2506 uses tunnel-p2p-common-params; 2507 uses te-types:te-topology-identifier; 2508 uses te-types:path-constraints-route-objects; 2509 uses te-types:generic-path-constraints; 2510 uses te-types:generic-path-optimization; 2511 uses te:path-access-segment-info; 2512 uses requested-info; 2513 container requested-state { 2514 presence 2515 "Request temporary reporting of the computed path state"; 2516 description 2517 "Configures attributes for the temporary reporting of the 2518 computed path state (e.g., expiration timer)."; 2519 uses requested-state; 2520 } 2521 } 2522 uses synchronization-info; 2523 } 2525 augment "/te:tunnels-rpc/te:output/te:result" { 2526 description "Path Computation RPC output"; 2527 list response { 2528 key "response-id"; 2529 config false; 2530 description "response"; 2531 leaf response-id { 2532 type uint32; 2533 description 2534 "The response-id has the same value of the corresponding 2535 request-id."; 2536 } 2537 choice response-type { 2538 config false; 2539 description "response-type"; 2540 case no-path-case { 2541 uses no-path-info; 2542 } 2543 case path-case { 2544 container computed-path { 2545 uses path-info; 2546 uses reported-state; 2547 description "Path computation service."; 2548 } 2549 } 2550 } 2551 } 2552 } 2554 augment "/te:tunnels-rpc/te:input/te:tunnel-info" { 2555 description "Path Delete RPC input"; 2556 leaf-list deleted-paths-transaction-id { 2557 type string; 2558 description 2559 "The list of the transaction-id values of the 2560 transient states to be deleted"; 2561 } 2562 } 2564 augment "/te:tunnels-rpc/te:output/te:result" { 2565 description "Path Delete RPC output"; 2566 leaf-list deleted-paths-transaction-id { 2567 type string; 2568 description 2569 "The list of the transaction-id values of the 2570 transient states that have been successfully deleted"; 2571 } 2572 } 2573 } 2574 2576 Figure 12 - TE path computation YANG module 2578 7. Security Considerations 2580 This document describes use cases of requesting Path Computation 2581 using YANG models, which could be used at the ABNO Control Interface 2582 [RFC7491] and/or between controllers in ACTN [RFC8453]. As such, it 2583 does not introduce any new security considerations compared to the 2584 ones related to YANG specification, ABNO specification and ACTN 2585 Framework defined in [RFC7950], [RFC7491] and [RFC8453]. 2587 The YANG module defined in this draft is designed to be accessed via 2588 the NETCONF protocol [RFC6241] or RESTCONF protocol [RFC8040]. The 2589 lowest NETCONF layer is the secure transport layer, and the 2590 mandatory-to-implement secure transport is Secure Shell (SSH) 2591 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- 2592 implement secure transport is TLS [RFC8446]. 2594 This document also defines common data types using the YANG data 2595 modeling language. The definitions themselves have no security 2596 impact on the Internet, but the usage of these definitions in 2597 concrete YANG modules might have. The security considerations 2598 spelled out in the YANG specification [RFC7950] apply for this 2599 document as well. 2601 The NETCONF access control model [RFC8341] provides the means to 2602 restrict access for particular NETCONF or RESTCONF users to a 2603 preconfigured subset of all available NETCONF or RESTCONF protocol 2604 operations and content. 2606 Note - The security analysis of each leaf is for further study. 2608 8. IANA Considerations 2610 This document registers the following URIs in the IETF XML registry 2611 [RFC3688]. Following the format in [RFC3688], the following 2612 registration is requested to be made. 2614 URI: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 2615 XML: N/A, the requested URI is an XML namespace. 2617 This document registers a YANG module in the YANG Module Names 2618 registry [RFC7950]. 2620 name: ietf-te-path-computation 2621 namespace: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 2622 prefix: tepc 2624 9. References 2626 9.1. Normative References 2628 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 2629 2004. 2631 [RFC5440] Vasseur, JP., Le Roux, JL. et al., "Path Computation 2632 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 2633 March 2009. 2635 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 2636 "A Backward-Recursive PCE-Based Computation (BRPC) 2637 Procedure to Compute Shortest Constrained Inter-Domain 2638 Traffic Engineering Label Switched Paths", RFC 5441, 2639 DOI 10.17487/RFC5441, April 2009, . 2642 [RFC5541] Le Roux, JL. et al., " Encoding of Objective Functions in 2643 the Path Computation Element Communication Protocol 2644 (PCEP)", RFC 5541, June 2009. 2646 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2647 and A. Bierman, Ed., "Network Configuration Protocol 2648 (NETCONF)", RFC 6241, June 2011. 2650 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2651 Shell (SSH)", RFC 6242, June 2011. 2653 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2654 Protocol", RFC 8040, January 2017. 2656 [RFC8341] Bierman, A., and M. Bjorklund, "Network Configuration 2657 Access Control Model", RFC 8341, March 2018. 2659 [RFC7491] Farrel, A., King, D., "A PCE-Based Architecture for 2660 Application-Based Network Operations", RFC 7491, March 2661 2015. 2663 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 2664 Information Exchange Between Interconnected Traffic 2665 Engineered Networks", RFC 7926, July 2016. 2667 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 2668 7950, August 2016. 2670 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2671 Protocol", RFC 8040, January 2017. 2673 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2674 Version 1.3", RFC 8446, August 2018. 2676 [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction 2677 and Control of TE Networks (ACTN)", RFC8453, August 2018. 2679 [RFC8454] Lee, Y. et al., "Information Model for Abstraction and 2680 Control of TE Networks (ACTN)", RFC8454, September 2018. 2682 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 2683 draft-ietf-teas-yang-te-topo, work in progress. 2685 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 2686 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 2687 te, work in progress. 2689 9.1. Informative References 2691 [RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based 2692 Architecture", RFC 4655, August 2006. 2694 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 2695 Path Computation Element Architecture to the Determination 2696 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 2697 10.17487/RFC6805, November 2012, . 2700 [RFC7139] Zhang, F. et al., "GMPLS Signaling Extensions for Control 2701 of Evolving G.709 Optical Transport Networks", RFC 7139, 2702 March 2014. 2704 [RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment 2705 Information Model for Wavelength Switched Optical 2706 Networks", RFC 7446, February 2015. 2708 [RFC8233] Dhody, D. et al., "Extensions to the Path Computation 2709 Element Communication Protocol (PCEP) to Compute Service- 2710 Aware Label Switched Paths (LSPs)", RFC 8233, September 2711 2017 2713 [RFC8342] Bjorklund,M. et al. "Network Management Datastore 2714 Architecture (NMDA)", RFC 8342, March 2018 2716 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical 2717 Transport Network Topology", draft-ietf-ccamp-otn-topo- 2718 yang, work in progress. 2720 [ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interface 2721 for the optical transport network", June 2016. 2723 10. Acknowledgments 2725 The authors would like to thank Igor Bryskin and Xian Zhang for 2726 participating in the initial discussions that have triggered this 2727 work and providing valuable insights. 2729 The authors would like to thank the authors of the TE Tunnel YANG 2730 model [TE-TUNNEL], in particular Igor Bryskin, Vishnu Pavan Beeram, 2731 Tarek Saad and Xufeng Liu, for their inputs to the discussions and 2732 support in having consistency between the Path Computation and TE 2733 Tunnel YANG models. 2735 The authors would like to thank Adrian Farrel, Dhruv Dhody, Igor 2736 Bryskin, Julien Meuric and Lou Berger for their valuable input to 2737 the discussions that has clarified that the path being setup is not 2738 necessarily the same as the path that have been previously computed 2739 and, in particular to Dhruv Dhody, for his suggestion to describe 2740 the need for a path verification phase to check that the actual path 2741 being setup meets the required end-to-end metrics and constraints. 2743 This document was prepared using 2-Word-v2.0.template.dot. 2745 Appendix A. Examples of dimensioning the "detailed connectivity matrix" 2747 In the following table, a list of the possible constraints, 2748 associated with their potential cardinality, is reported. 2750 The maximum number of potential connections to be computed and 2751 reported is, in first approximation, the multiplication of all of 2752 them. 2754 Constraint Cardinality 2755 ---------- ------------------------------------------------------- 2757 End points N(N-1)/2 if connections are bidirectional (OTN and WDM), 2758 N(N-1) for unidirectional connections. 2760 Bandwidth In WDM networks, bandwidth values are expressed in GHz. 2762 On fixed-grid WDM networks, the central frequencies are 2763 on a 50GHz grid and the channel width of the transmitters 2764 are typically 50GHz such that each central frequency can 2765 be used, i.e., adjacent channels can be placed next to 2766 each other in terms of central frequencies. 2768 On flex-grid WDM networks, the central frequencies are on 2769 a 6.25GHz grid and the channel width of the transmitters 2770 can be multiples of 12.5GHz. 2772 For fixed-grid WDM networks typically there is only one 2773 possible bandwidth value (i.e., 50GHz) while for flex- 2774 grid WDM networks typically there are 4 possible 2775 bandwidth values (e.g., 37.5GHz, 50GHz, 62.5GHz, 75GHz). 2777 In OTN (ODU) networks, bandwidth values are expressed as 2778 pairs of ODU type and, in case of ODUflex, ODU rate in 2779 bytes/sec as described in section 5 of [RFC7139]. 2781 For "fixed" ODUk types, 6 possible bandwidth values are 2782 possible (i.e., ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4). 2784 For ODUflex(GFP), up to 80 different bandwidth values can 2785 be specified, as defined in Table 7-8 of [ITU-T G.709- 2786 2016]. 2788 For other ODUflex types, like ODUflex(CBR), the number of 2789 possible bandwidth values depends on the rates of the 2790 clients that could be mapped over these ODUflex types, as 2791 shown in Table 7.2 of [ITU-T G.709-2016], which in theory 2792 could be a countinuum of values. However, since different 2793 ODUflex bandwidths that use the same number of TSs on 2794 each link along the path are equivalent for path 2795 computation purposes, up to 120 different bandwidth 2796 ranges can be specified. 2798 Ideas to reduce the number of ODUflex bandwidth values in 2799 the detailed connectivity matrix, to less than 100, are 2800 for further study. 2802 Bandwidth specification for ODUCn is currently for 2803 further study but it is expected that other bandwidth 2804 values can be specified as integer multiples of 100Gb/s. 2806 In IP we have bandwidth values in bytes/sec. In 2807 principle, this is a countinuum of values, but in 2808 practice we can identify a set of bandwidth ranges, where 2809 any bandwidth value inside the same range produces the 2810 same path. 2811 The number of such ranges is the cardinality, which 2812 depends on the topology, available bandwidth and status 2813 of the network. Simulations (Note: reference paper 2814 submitted for publication) show that values for medium 2815 size topologies (around 50-150 nodes) are in the range 4- 2816 7 (5 on average) for each end points couple. 2818 Metrics IGP, TE and hop number are the basic objective metrics 2819 defined so far. There are also the 2 objective functions 2820 defined in [RFC5541]: Minimum Load Path (MLP) and Maximum 2821 Residual Bandwidth Path (MBP). Assuming that one only 2822 metric or objective function can be optimized at once, 2823 the total cardinality here is 5. 2825 With [RFC8233], a number of additional metrics are 2826 defined, including Path Delay metric, Path Delay 2827 Variation metric and Path Loss metric, both for point-to- 2828 point and point-to-multipoint paths. This increases the 2829 cardinality to 8. 2831 Bounds Each metric can be associated with a bound in order to 2832 find a path having a total value of that metric lower 2833 than the given bound. This has a potentially very high 2834 cardinality (as any value for the bound is allowed). In 2835 practice there is a maximum value of the bound (the one 2836 with the maximum value of the associated metric) which 2837 results always in the same path, and a range approach 2838 like for bandwidth in IP should produce also in this case 2839 the cardinality. Assuming to have a cardinality similar 2840 to the one of the bandwidth (let say 5 on average) we 2841 should have 6 (IGP, TE, hop, path delay, path delay 2842 variation and path loss; we don't consider here the two 2843 objective functions of [RFC5541] as they are conceived 2844 only for optimization)*5 = 30 cardinality. 2846 Technology 2847 constraints For further study 2849 Priority We have 8 values for setup priority, which is used in 2850 path computation to route a path using free resources 2851 and, where no free resources are available, resources 2852 used by LSPs having a lower holding priority. 2854 Local prot It's possible to ask for a local protected service, where 2855 all the links used by the path are protected with fast 2856 reroute (this is only for IP networks, but line 2857 protection schemas are available on the other 2858 technologies as well). This adds an alternative path 2859 computation, so the cardinality of this constraint is 2. 2861 Administrative 2862 Colors Administrative colors (aka affinities) are typically 2863 assigned to links but when topology abstraction is used 2864 affinity information can also appear in the detailed 2865 connectivity matrix. 2867 There are 32 bits available for the affinities. Links can 2868 be tagged with any combination of these bits, and path 2869 computation can be constrained to include or exclude any 2870 or all of them. The relevant cardinality is 3 (include- 2871 any, exclude-any, include-all) times 2^32 possible 2872 values. However, the number of possible values used in 2873 real networks is quite small. 2875 Included Resources 2877 A path computation request can be associated to an 2878 ordered set of network resources (links, nodes) to be 2879 included along the computed path. This constraint would 2880 have a huge cardinality as in principle any combination 2881 of network resources is possible. However, as far as the 2882 Orchestrator doesn't know details about the internal 2883 topology of the domain, it shouldn't include this type of 2884 constraint at all (see more details below). 2886 Excluded Resources 2888 A path computation request can be associated to a set of 2889 network resources (links, nodes, SRLGs) to be excluded 2890 from the computed path. Like for included resources, 2891 this constraint has a potentially very high cardinality, 2892 but, once again, it can't be actually used by the 2893 Orchestrator, if it's not aware of the domain topology 2894 (see more details below). 2895 As discussed above, the Orchestrator can specify include or exclude 2896 resources depending on the abstract topology information that the 2897 domain controller exposes: 2899 o In case the domain controller exposes the entire domain as a 2900 single abstract TE node with his own external terminations and 2901 detailed connectivity matrix (whose size we are estimating), no 2902 other topological details are available, therefore the size of 2903 the detailed connectivity matrix only depends on the combination 2904 of the constraints that the Orchestrator can use in a path 2905 computation request to the domain controller. These constraints 2906 cannot refer to any details of the internal topology of the 2907 domain, as those details are not known to the Orchestrator and so 2908 they do not impact size of the detailed connectivity matrix 2909 exported. 2911 o Instead in case the domain controller exposes a topology 2912 including more than one abstract TE nodes and TE links, and their 2913 attributes (e.g. SRLGs, affinities for the links), the 2914 Orchestrator knows these details and therefore could compute a 2915 path across the domain referring to them in the constraints. The 2916 detailed connectivity matrixes, whose size need to be estimated 2917 here, are the ones relevant to the abstract TE nodes exported to 2918 the Orchestrator. These detailed connectivity matrixes and 2919 therefore theirs sizes, while cannot depend on the other abstract 2920 TE nodes and TE links, which are external to the given abstract 2921 node, could depend to SRLGs (and other attributes, like 2922 affinities) which could be present also in the portion of the 2923 topology represented by the abstract nodes, and therefore 2924 contribute to the size of the related detailed connectivity 2925 matrix. 2927 We also don't consider here the possibility to ask for more than one 2928 path in diversity or for point-to-multi-point paths, which are for 2929 further study. 2931 Considering for example an IP domain without considering SRLG and 2932 affinities, we have an estimated number of paths depending on these 2933 estimated cardinalities: 2935 Endpoints = N*(N-1), Bandwidth = 5, Metrics = 6, Bounds = 20, 2936 Priority = 8, Local prot = 2 2938 The number of paths to be pre-computed by each IP domain is 2939 therefore 24960 * N(N-1) where N is the number of domain access 2940 points. 2942 This means that with just 4 access points we have nearly 300000 2943 paths to compute, advertise and maintain (if a change happens in the 2944 domain, due to a fault, or just the deployment of new traffic, a 2945 substantial number of paths need to be recomputed and the relevant 2946 changes advertised to the upper controller). 2948 This seems quite challenging. In fact, if we assume a mean length of 2949 1K for the json describing a path (a quite conservative estimate), 2950 reporting 300000 paths means transferring and then parsing more than 2951 300 Mbytes for each domain. If we assume that 20% (to be checked) of 2952 this paths change when a new deployment of traffic occurs, we have 2953 60 Mbytes of transfer for each domain traversed by a new end-to-end 2954 path. If a network has, let say, 20 domains (we want to estimate the 2955 load for a non-trivial domain setup) in the beginning a total 2956 initial transfer of 6Gigs is needed, and eventually, assuming 4-5 2957 domains are involved in mean during a path deployment we could have 2958 240-300 Mbytes of changes advertised to the higher order controller. 2960 Further bare-bone solutions can be investigated, removing some more 2961 options, if this is considered not acceptable; in conclusion, it 2962 seems that an approach based only on the information provided by the 2963 detailed connectivity matrix is hardly feasible, and could be 2964 applicable only to small networks with a limited meshing degree 2965 between domains and renouncing to a number of path computation 2966 features. 2968 Appendix B. New proposed YANG Tree overview 2970 This Appendix provides an overview of the YANG Tree that would 2971 results from the proposed changes described in section 5.3. 2973 module: ietf-te-path-computation 2974 augment /te:tunnels-rpc/te:input/te:tunnel-info: 2975 +---- path-request* [request-id] 2976 | +--- request-id uint32 2977 | +---- (tunnel-attributes)? 2978 | | +----:(reference) 2979 | | | +---- (tunnel-exist)? 2980 | | | | +----:(tunnel-ref) 2981 | | | | | +---- tunnel-ref leafref 2982 | | | | +----:(tunnel-attributes-ref) 2983 | | | | | +---- tunnel-attributes-ref leafref 2984 | | | +---- path-name? string 2985 | | | +---- (path-role)? 2986 | | | | +----:(candidate-primary-path) 2987 | | | | | +---- candidate-primary-path empty 2988 | | | | +----:(candidate-secondary-path) 2989 | | | | | +---- candidate-secondary-path 2990 | | | | | | +---- (primary-path-exist)? 2991 | | | | | | | +----:(primary-path-reference) 2992 | | | | | | | | +---- primary-path-ref 2993 leafref 2994 | | | | | | | +----:(primary-path-request) 2995 | | | | | | | | +---- primary-path-request-id 2996 uint32 2997 | | +----:(values) 2998 | | | +---- tunnel-name? string 2999 | | | +---- (path-role)? 3000 | | | | +--:(primary) 3001 | | | | | +---- primary-path-name? string 3002 | | | | +--:(secondary) 3003 | | | | +---- secondary-path-name? string 3004 | | | +--- encoding? identityref 3005 | | | +--- switching-type? identityref 3006 | | | +--- source? inet:ip- 3007 address 3008 | | | +--- destination? inet:ip- 3009 address 3010 | | | +--- src-tp-id? binary 3011 | | | +--- dst-tp-id? binary 3012 | | | +--- bidirectional? boolean 3013 | | | +--- te-topology-identifier 3014 | | | | +--- provider-id? te-global-id 3015 | | | | +--- client-id? te-global-id 3016 | | | | +--- topology-id? te-topology-id 3017 | +---- explicit-route-objects-always 3018 | | ........... 3019 | +---- path-constraints 3020 | | +---- preference? uint8 3021 | | ........... 3022 | +---- optimizations 3023 | | ........... 3024 | +---- path-in-segment! 3025 | | ........... 3026 | +---- path-out-segment! 3027 | | ........... 3028 | +---- requested-metrics* [metric-type] 3029 | | +---- metric-type identityref 3030 | +---- return-srlgs? boolean 3031 | +---- return-affinities? boolean 3032 | +---- requested-state! 3033 | +---- timer? uint16 3034 | +---- transaction-id? string 3035 +---- tunnel-attributes* [tunnel-name] 3036 | +---- tunnel-name string 3037 | +---- encoding? identityref 3038 | +---- switching-type? identityref 3039 | +---- source? inet:ip-address 3040 | +---- destination? inet:ip-address 3041 | +---- src-tp-id? binary 3042 | +---- dst-tp-id? binary 3043 | +---- bidirectional? boolean 3044 | +---- te-topology-identifier 3045 | | +---- provider-id? te-global-id 3046 | | +---- client-id? te-global-id 3047 | | +---- topology-id? te-topology-id 3048 | +---- preference? uint8 3049 | +---- association-objects 3050 | | ........... 3051 | +---- protection-type? identityref 3052 | +---- restoration-type? identityref 3053 | +---- te-bandwidth 3054 | | ........... 3055 | +---- link-protection? identityref 3056 | +---- setup-priority? uint8 3057 | +---- hold-priority? uint8 3058 | +---- signaling-type? identityref 3059 +---- synchronization* [synchronization-id] 3060 ........... 3061 ........... 3063 Contributors 3065 Dieter Beller 3066 Nokia 3067 Email: dieter.beller@nokia.com 3069 Gianmarco Bruno 3070 Ericsson 3071 Email: gianmarco.bruno@ericsson.com 3073 Francesco Lazzeri 3074 Ericsson 3075 Email: francesco.lazzeri@ericsson.com 3077 Young Lee 3078 Huawei 3079 Email: leeyoung@huawei.com 3081 Carlo Perocchio 3082 Ericsson 3083 Email: carlo.perocchio@ericsson.com 3085 Olivier Dugeon 3086 Orange Labs 3087 Email: olivier.dugeon@orange.com 3089 Julien Meuric 3090 Orange Labs 3091 Email: julien.meuric@orange.com 3093 Authors' Addresses 3095 Italo Busi (Editor) 3096 Huawei 3097 Email: italo.busi@huawei.com 3098 Sergio Belotti (Editor) 3099 Nokia 3100 Email: sergio.belotti@nokia.com 3102 Victor Lopez 3103 Telefonica 3104 Email: victor.lopezalvarez@telefonica.com 3106 Oscar Gonzalez de Dios 3107 Telefonica 3108 Email: oscar.gonzalezdedios@telefonica.com 3110 Anurag Sharma 3111 Google 3112 Email: ansha@google.com 3114 Yan Shi 3115 China Unicom 3116 Email: shiyan49@chinaunicom.cn 3118 Ricard Vilalta 3119 CTTC 3120 Email: ricard.vilalta@cttc.es 3122 Karthik Sethuraman 3123 NEC 3124 Email: karthik.sethuraman@necam.com 3126 Michael Scharf 3127 Nokia 3128 Email: michael.scharf@gmail.com 3130 Daniele Ceccarelli 3131 Ericsson 3132 Email: daniele.ceccarelli@ericsson.com