idnits 2.17.1 draft-ietf-teas-yang-path-computation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** 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 1085 has weird spacing: '...tion-id uin...' == Line 1092 has weird spacing: '...ic-type ide...' == Line 1103 has weird spacing: '...ic-type ide...' == Line 1170 has weird spacing: '...o usage ide...' == Line 1185 has weird spacing: '...ic-type ide...' == (8 more instances...) -- The document date (June 29, 2018) is 2126 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ACTN-frame' is mentioned on line 1909, but not defined == Missing Reference: 'RFC5440' is mentioned on line 1016, but not defined == Missing Reference: 'RFC 5440' is mentioned on line 1153, but not defined == Missing Reference: 'RFC6242' is mentioned on line 1915, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1916, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RF7950' is mentioned on line 1922, but not defined == Missing Reference: 'RFC6536' is mentioned on line 1925, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 1935, but not defined == Unused Reference: 'ACTN-Frame' is defined on line 1980, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7491 -- No information found for draft-ietf-actn-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ACTN-Frame' -- No information found for draft-ietf-teas-actn-info - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ACTN-Info' Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 5 comments (--). 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: December 2018 Nokia 5 Victor Lopez 6 Oscar Gonzalez de Dios 7 Telefonica 8 Anurag Sharma 9 Google 10 Yan Shi 11 China Unicom 12 Ricard Vilalta 13 CTTC 14 Karthik Sethuraman 15 NEC 17 June 29, 2018 19 Yang model for requesting Path Computation 20 draft-ietf-teas-yang-path-computation-02.txt 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on December 29, 2016. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Abstract 61 There are scenarios, typically in a hierarchical SDN context, where 62 the topology information provided by a TE network provider may not 63 be sufficient for its client to perform end-to-end path computation. 64 In these cases the client would need to request the provider to 65 calculate some (partial) feasible paths. 67 This document defines a YANG data model for a stateless RPC to 68 request path computation. This model complements the stateful 69 solution defined in [TE-TUNNEL]. 71 Moreover this document describes some use cases where a path 72 computation request, via YANG-based protocols (e.g., NETCONF or 73 RESTCONF), can be needed. 75 Table of Contents 77 1. Introduction...................................................3 78 1.1. Terminology...............................................5 79 2. Use Cases......................................................5 80 2.1. Packet/Optical Integration................................5 81 2.2. Multi-domain TE Networks.................................10 82 2.3. Data center interconnections.............................12 84 3. Motivations...................................................14 85 3.1. Motivation for a YANG Model..............................14 86 3.1.1. Benefits of common data models......................14 87 3.1.2. Benefits of a single interface......................15 88 3.1.3. Extensibility.......................................15 89 3.2. Interactions with TE Topology............................16 90 3.2.1. TE Topology Aggregation.............................17 91 3.2.2. TE Topology Abstraction.............................20 92 3.2.3. Complementary use of TE topology and path computation21 93 3.3. Stateless and Stateful Path Computation..................24 94 4. Path Computation and Optimization for multiple paths..........25 95 5. YANG Model for requesting Path Computation....................26 96 5.1. Synchronization of multiple path computation requests....26 97 5.2. Returned metric values...................................28 98 6. YANG model for stateless TE path computation..................29 99 6.1. YANG Tree................................................29 100 6.2. YANG Module..............................................38 101 7. Security Considerations.......................................47 102 8. IANA Considerations...........................................48 103 9. References....................................................48 104 9.1. Normative References.....................................48 105 9.2. Informative References...................................49 106 10. Acknowledgments..............................................50 107 Appendix A. Examples of dimensioning the "detailed connectivity 108 matrix"..........................................................51 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 [ACTN-frame], where a controller hierarchy is defined, the 127 need for path computation arises on both interfaces CMI 128 (interface between Customer Network Controller (CNC) and Multi 129 Domain Service Coordinator (MDSC)) and/or MPI (interface between 130 MSDC-PNC). [ACTN-Info] describes an information model for the 131 Path 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 different use cases, where a client needs to 185 request underlying SDN controllers for path computation. 187 The presented uses cases have been grouped, depending on the 188 different underlying topologies: a) Packet-Optical integration; b) 189 Multi-domain Traffic Engineered (TE) Networks; and c) Data center 190 interconnections. 192 2.1. Packet/Optical Integration 194 In this use case, an Optical network is used to provide connectivity 195 to some nodes of a Packet network (see Figure 1). 197 A possible example could be the case where an Optical network 198 provides connectivity to same IP routers of an IP network. 200 +----------------+ 201 | | 202 | Packet/Optical | 203 | Coordinator | 204 | | 205 +---+------+-----+ 206 | | 207 +------------+ | 208 | +-----------+ 209 +------V-----+ | 210 | | +------V-----+ 211 | Packet | | | 212 | Network | | Optical | 213 | CONTROLLER | | Network | 214 | | | CONTROLLER | 215 +------+-----+ +-------+----+ 216 | | 217 .........V......................... | 218 : Packet Network : | 219 +----+ +----+ | 220 | R1 |= = = = = = = = = = = = = = = =| R2 | | 221 +-+--+ +--+-+ | 222 | : : | | 223 | :................................ : | | 224 | | | 225 | +-----+ | | 226 | ...........| Opt |........... | | 227 | : | C | : | | 228 | : /+--+--+\ : | | 229 | : / | \ : | | 230 | : / | \ : | | 231 | +-----+ / +--+--+ \ +-----+ | | 232 | | Opt |/ | Opt | \| Opt | | | 233 +---| A | | D | | B |---+ | 234 +-----+\ +--+--+ /+-----+ | 235 : \ | / : | 236 : \ | / : | 237 : \ +--+--+ / Optical<---------+ 238 : \| Opt |/ Network: 239 :..........| E |..........: 240 +-----+ 242 Figure 1 - Packet/Optical Integration Use Case 244 Figure 1 as well as Figure 2 below only show a partial view of the 245 packet network connectivity, before additional packet connectivity 246 is provided by the Optical network. 248 It is assumed that the Optical network controller provides to the 249 packet/optical coordinator an abstracted view of the Optical 250 network. A possible abstraction could be to represent the whole 251 optical network as one "virtual node" with "virtual ports" connected 252 to the access links, as shown in Figure 2. 254 It is also assumed that Packet network controller can provide the 255 packet/optical coordinator the information it needs to setup 256 connectivity between packet nodes through the Optical network (e.g., 257 the access links). 259 The path computation request helps the coordinator to know the real 260 connections that can be provided by the optical network. 262 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,. 263 , Packet/Optical Coordinator view , 264 , +----+ , . 265 , | | , 266 , | R2 | , . 267 , +----+ +------------ + /+----+ , 268 , | | | |/-----/ / / , . 269 , | R1 |--O VP1 VP4 O / / , 270 , | |\ | | /----/ / , . 271 , +----+ \| |/ / , 272 , / O VP2 VP5 O / , . 273 , / | | +----+ , 274 , / | | | | , . 275 , / O VP3 VP6 O--| R4 | , 276 , +----+ /-----/|_____________| +----+ , . 277 , | |/ +------------ + , 278 , | R3 | , . 279 , +----+ ,,,,,,,,,,,,,,,,, 280 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,. 281 . Packet Network Controller view +----+ , 282 only packet nodes and packet links | | , . 283 . with access links to the optical network | R2 | , 284 , +----+ /+----+ , . 285 . , | | /-----/ / / , 286 , | R1 |--- / / , . 287 . , +----+\ /----/ / , 288 , / \ / / , . 289 . , / / , 290 , / +----+ , . 291 . , / | | , 292 , / ---| R4 | , . 293 . , +----+ /-----/ +----+ , 294 , | |/ , . 295 . , | R3 | , 296 , +----+ ,,,,,,,,,,,,,,,,,. 297 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 298 Optical Network Controller view , . 299 . only optical nodes, +--+ , 300 optical links and /|OF| , . 301 . access links from the +--++--+ / , 302 packet network |OA| \ /-----/ / , . 303 . , ---+--+--\ +--+/ / , 304 , \ | \ \-|OE|-------/ , . 305 . , \ | \ /-+--+ , 306 , \+--+ X | , . 308 . , |OB|-/ \ | , 309 , +--+-\ \+--+ , . 310 . , / \ \--|OD|--- , 311 , /-----/ +--+ +--+ , . 312 . , / |OC|/ , 313 , +--+ , . 314 ., ,,,,,,,,,,,,,,,,,, 315 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, , 316 . Actual Physical View +----+ , 317 , +--+ | | , 318 . , /|OF| | R2 | , 319 , +----+ +--++--+ /+----+ , 320 . , | | |OA| \ /-----/ / / , 321 , | R1 |---+--+--\ +--+/ / / , 322 . , +----+\ | \ \-|OE|-------/ / , 323 , / \ | \ /-+--+ / , 324 . , / \+--+ X | / , 325 , / |OB|-/ \ | +----+ , 326 . , / +--+-\ \+--+ | | , 327 , / / \ \--|OD|---| R4 | , 328 . , +----+ /-----/ +--+ +--+ +----+ , 329 , | |/ |OC|/ , 330 . , | R3 | +--+ , 331 , +----+ , 332 .,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 334 Figure 2 - Packet and Optical Topology Abstractions 336 In this use case, the coordinator needs to setup an optimal 337 underlying path for an IP link between R1 and R2. 339 As depicted in Figure 2, the coordinator has only an "abstracted 340 view" of the physical network, and it does not know the feasibility 341 or the cost of the possible optical paths (e.g., VP1-VP4 and VP2- 342 VP5), which depend from the current status of the physical resources 343 within the optical network and on vendor-specific optical 344 attributes. 346 The coordinator can request the underlying Optical domain controller 347 to compute a set of potential optimal paths, taking into account 348 optical constraints. Then, based on its own constraints, policy and 349 knowledge (e.g. cost of the access links), it can choose which one 350 of these potential paths to use to setup the optimal end-to-end path 351 crossing optical network. 353 ............................ 354 : : 355 O VP1 VP4 O 356 cost=10 /:\ /:\ cost=10 357 / : \----------------------/ : \ 358 +----+ / : cost=50 : \ +----+ 359 | |/ : : \| | 360 | R1 | : : | R2 | 361 | |\ : : /| | 362 +----+ \ : /--------------------\ : / +----+ 363 \ : / cost=55 \ : / 364 cost=5 \:/ \:/ cost=5 365 O VP2 VP5 O 366 : : 367 :..........................: 369 Figure 3 - Packet/Optical Path Computation Example 371 For example, in Figure 3, the Coordinator can request the Optical 372 network controller to compute the paths between VP1-VP4 and VP2-VP5 373 and then decide to setup the optimal end-to-end path using the VP2- 374 VP5 Optical path even this is not the optimal path from the Optical 375 domain perspective. 377 Considering the dynamicity of the connectivity constraints of an 378 Optical domain, it is possible that a path computed by the Optical 379 network controller when requested by the Coordinator is no longer 380 valid/available when the Coordinator requests it to be setup up. 381 This is further discussed in section 3.3. 383 2.2. Multi-domain TE Networks 385 In this use case there are two TE domains which are interconnected 386 together by multiple inter-domains links. 388 A possible example could be a multi-domain optical network. 390 +--------------+ 391 | Multi-domain | 392 | CONTROLLER | 393 +---+------+---+ 394 | | 395 +------------+ | 396 | +-----------+ 397 +------V-----+ | 398 | | | 399 | TE Network | +------V-----+ 400 | CONTROLLER | | | 401 | 1 | | TE Network | 402 +------+-----+ | CONTROLLER | 403 | | 2 | 404 | +------+-----+ 405 .........V.......... | 406 : : | 407 +-----+ : | 408 | | : .........V.......... 409 | X | : : : 410 | | +-----+ +-----+ : 411 +-----+ | | | | : 412 : | C |------| E | : 413 +-----+ +-----+ /| | | |\ +-----+ +-----+ 414 | | | |/ +-----+ +-----+ \| | | | 415 | A |----| B | : : | G |----| H | 416 | | | |\ : : /| | | | 417 +-----+ +-----+ \+-----+ +-----+/ +-----+ +-----+ 418 : | | | | : 419 : | D |------| F | : 420 : | | | | +-----+ 421 : +-----+ +-----+ | | 422 : : : | Y | 423 : : : | | 424 : Domain 1 : : Domain 2 +-----+ 425 :..................: :.................: 427 Figure 4 - Multi-domain multi-link interconnection 429 In order to setup an end-to-end multi-domain TE path (e.g., between 430 nodes A and H), the multi-domaon controller needs to know the 431 feasibility or the cost of the possible TE paths within the two TE 432 domains, which depend from the current status of the physical 433 resources within each TE network. This is more challenging in case 434 of optical networks because the optimal paths depend also on vendor- 435 specific optical attributes (which may be different in the two 436 domains if they are provided by different vendors). 438 In order to setup a multi-domain TE path (e.g., between nodes A and 439 H), the multi-domain controller can request the TE domain 440 controllers to compute a set of intra-domain optimal paths and take 441 decisions based on the information received. For example: 443 o The Orchestrator asks TE domain controllers to provide set of 444 paths between A-C, A-D, E-H and F-H 446 o TE domain controllers return a set of feasible paths with the 447 associated costs: the path A-C is not part of this set(in optical 448 networks, it is typical to have some paths not being feasible due 449 to optical constraints that are known only by the optical domain 450 controller) 452 o The multi-domain controller will select the path A-D-F-H since it 453 is the only feasible multi-domain path and then request the TE 454 domain controllers to setup the A-D and F-H intra-domain paths 456 o If there are multiple feasible paths, the multi-domain controller 457 can select the optimal path knowing the cost of the intra-domain 458 paths (provided by the TE domain controllers) and the cost of the 459 inter-domain links (known by the multi-domain controller) 461 This approach may have some scalability issues when the number of TE 462 domains is quite big (e.g. 20). 464 In this case, it would be worthwhile using the abstract TE topology 465 information provided by the domain controllers to limit the number of 466 potential optimal end-to-end paths and then request path computation 467 to fewer domain controllers in order to decide what the optimal path 468 within this limited set is. 470 For more details, see section 3.2.3. 472 2.3. Data center interconnections 474 In these use case, there is a TE domain which is used to provide 475 connectivity between data centers which are connected with the TE 476 domain using access links. 478 +--------------+ 479 | CLOUD | 480 | ORCHESTRATOR | 481 +--------------+ 482 | | | | 483 +-------------+ | | +------------------------+ 484 | | +------------------+ | 485 | +--------V---+ | | 486 | | | | | 487 | | TE Network | | | 488 +------V-----+ | CONTROLLER | +------V-----+ | 489 | DC | |____________| | DC | | 490 | CONTROLLER | | | CONTROLLER | | 491 +------------+ | +-----+ +------------+ | 492 | ....V...| |........ | | 493 | : | P | : | | 494 .....V..... : /+-----+\ : .....V..... | 495 : : +-----+ / | \ +-----+ : : | 496 : DC1 || : | |/ | \| | : DC2 || : | 497 : ||||----| PE1 | | | PE2 |---- |||| : | 498 : _|||||| : | |\ | /| | : _|||||| : | 499 : : +-----+ \ +-----+ / +-----+ : : | 500 :.........: : \| |/ : :.........: | 501 :.......| PE3 |.......: | 502 | | | 503 +-----+ +---------V--+ 504 .....|..... | DC | 505 : : | CONTROLLER | 506 : DC3 || : +------------+ 507 : |||| : | 508 : _|||||| <------------------+ 509 : : 510 :.........: 512 Figure 5 - Data Center Interconnection Use Case 514 In this use case, there is need to transfer data from Data Center 1 515 (DC1) to either DC2 or DC3 (e.g. workload migration). 517 The optimal decision depends both on the cost of the TE path (DC1- 518 DC2 or DC1-DC3) and of the data center resources within DC2 or DC3. 520 The Cloud Orchestrator needs to make a decision for optimal 521 connection based on TE Network constraints and data centers 522 resources. It may not be able to make this decision because it has 523 only an abstract view of the TE network (as in use case in 2.1). 525 The cloud orchestrator can request to the TE domain controller to 526 compute the cost of the possible TE paths (e.g., DC1-DC2 and DC1- 527 DC3) and to the DC controller to provide the information it needs 528 about the required data center resources within DC2 and DC3 and then 529 it can take the decision about the optimal solution based on this 530 information and its policy. 532 3. Motivations 534 This section provides the motivation for the YANG model defined in 535 this document. 537 Section 3.1 describes the motivation for a YANG model to request 538 path computation. 540 Section 3.2 describes the motivation for a YANG model which 541 complements the TE Topology YANG model defined in [TE-TOPO]. 543 Section 3.3 describes the motivation for a stateless YANG RPC which 544 complements the TE Tunnel YANG model defined in [TE-TUNNEL]. 546 3.1. Motivation for a YANG Model 548 3.1.1. Benefits of common data models 550 The YANG data model for requesting path computation is closely 551 aligned with the YANG data models that provide (abstract) TE 552 topology information, i.e., [TE-TOPO] as well as that are used to 553 configure and manage TE Tunnels, i.e., [TE-TUNNEL]. 555 There are many benefits in aligning the data model used for path 556 computation requests with the YANG data models used for TE topology 557 information and for TE Tunnels configuration and management: 559 o There is no need for an error-prone mapping or correlation of 560 information. 562 o It is possible to use the same endpoint identifiers in path 563 computation requests and in the topology modeling. 565 o The attributes used for path computation constraints are the same 566 as those used when setting up a TE Tunnel. 568 3.1.2. Benefits of a single interface 570 The system integration effort is typically lower if a single, 571 consistent interface is used by controllers, i.e., one data modeling 572 language (i.e., YANG) and a common protocol (e.g., NETCONF or 573 RESTCONF). 575 Practical benefits of using a single, consistent interface include: 577 1. Simple authentication and authorization: The interface between 578 different components has to be secured. If different protocols 579 have different security mechanisms, ensuring a common access 580 control model may result in overhead. For instance, there may 581 be a need to deal with different security mechanisms, e.g., 582 different credentials or keys. This can result in increased 583 integration effort. 584 2. Consistency: Keeping data consistent over multiple different 585 interfaces or protocols is not trivial. For instance, the 586 sequence of actions can matter in certain use cases, or 587 transaction semantics could be desired. While ensuring 588 consistency within one protocol can already be challenging, it 589 is typically cumbersome to achieve that across different 590 protocols. 591 3. Testing: System integration requires comprehensive testing, 592 including corner cases. The more different technologies are 593 involved, the more difficult it is to run comprehensive test 594 cases and ensure proper integration. 595 4. Middle-box friendliness: Provider and consumer of path 596 computation requests may be located in different networks, and 597 middle-boxes such as firewalls, NATs, or load balancers may be 598 deployed. In such environments it is simpler to deploy a single 599 protocol. Also, it may be easier to debug connectivity 600 problems. 601 5. Tooling reuse: Implementers may want to implement path 602 computation requests with tools and libraries that already 603 exist in controllers and/or orchestrators, e.g., leveraging the 604 rapidly growing eco-system for YANG tooling. 606 3.1.3. Extensibility 608 Path computation is only a subset of the typical functionality of a 609 controller. In many use cases, issuing path computation requests 610 comes along with the need to access other functionality on the same 611 system. In addition to obtaining TE topology, for instance also 612 configuration of services (setup/modification/deletion) may be 613 required, as well as: 615 1. Receiving notifications for topology changes as well as 616 integration with fault management 617 2. Performance management such as retrieving monitoring and 618 telemetry data 619 3. Service assurance, e.g., by triggering OAM functionality 620 4. Other fulfilment and provisioning actions beyond tunnels and 621 services, such as changing QoS configurations 623 YANG is a very extensible and flexible data modeling language that 624 can be used for all these use cases. 626 3.2. Interactions with TE Topology 628 The use cases described in section 2 have been described assuming 629 that the topology view exported by each underlying SDN controller to 630 the orchestrator is aggregated using the "virtual node model", 631 defined in [RFC7926]. 633 TE Topology information, e.g., as provided by [TE-TOPO], could in 634 theory be used by an underlying SDN controllers to provide TE 635 information to its client thus allowing a PCE available within its 636 client to perform multi-domain path computation by its own, without 637 requesting path computations to the underlying SDN controllers. 639 In case the client does not implement a PCE function, as discussed 640 in section 1, it could not perform path computation based on TE 641 Topology information and would instead need to request path 642 computation to the underlying controllers to get the information it 643 needs to compute the optimal end-to-end path. 645 This section analyzes the need for a client to request underlying 646 SDN controllers for path computation even in case it implements a 647 PCE functionality, as well as how the TE Topology information and 648 the path computation can be complementary. 650 In nutshell, there is a scalability trade-off between providing all 651 the TE information needed by PCE, when implemented by the client, to 652 take optimal path computation decisions by its own versus sending 653 too many requests to underlying SDN Domain Controllers to compute a 654 set of feasible optimal intra-domain TE paths. 656 3.2.1. TE Topology Aggregation 658 Using the TE Topology model, as defined in [TE-TOPO], the underlying 659 SDN controller can export the whole TE domain as a single abstract 660 TE node with a "detailed connectivity matrix". 662 The concept of a "detailed connectivity matrix" is defined in [TE- 663 TOPO] to provide specific TE attributes (e.g., delay, SRLGs and 664 summary TE metrics) as an extension of the "basic connectivity 665 matrix", which is based on the "connectivity matrix" defined in 666 [RFC7446]. 668 The information provided by the "detailed connectivity matrix" would 669 be equivalent to the information that should be provided by "virtual 670 link model" as defined in [RFC7926]. 672 For example, in the Packet/Optical integration use case, described 673 in section 2.1, the Optical network controller can make the 674 information shown in Figure 3 available to the Coordinator as part 675 of the TE Topology information and the Coordinator could use this 676 information to calculate by its own the optimal path between R1 and 677 R2, without requesting any additional information to the Optical 678 network Controller. 680 However, when designing the amount of information to provide within 681 the "detailed connectivity matrix", there is a tradeoff to be 682 considered between accuracy (i.e., providing "all" the information 683 that might be needed by the PCE available to Orchestrator) and 684 scalability. 686 Figure 6 below shows another example, similar to Figure 3, where 687 there are two possible Optical paths between VP1 and VP4 with 688 different properties (e.g., available bandwidth and cost). 690 ............................ 691 : /--------------------\ : 692 : / cost=65 \ : 693 :/ available-bw=10G \: 694 O VP1 VP4 O 695 cost=10 /:\ /:\ cost=10 696 / : \----------------------/ : \ 697 +----+ / : cost=50 : \ +----+ 698 | |/ : available-bw=2G : \| | 699 | R1 | : : | R2 | 700 | |\ : : /| | 701 +----+ \ : /--------------------\ : / +----+ 702 \ : / cost=55 \ : / 703 cost=5 \:/ available-bw=3G \:/ cost=5 704 O VP2 VP5 O 705 : : 706 :..........................: 708 Figure 6 - Packet/Optical Path Computation Example with multiple 709 choices 711 Reporting all the information, as in Figure 6, using the "detailed 712 connectivity matrix", is quite challenging from a scalability 713 perspective. The amount of this information is not just based on 714 number of end points (which would scale as N-square), but also on 715 many other parameters, including client rate, user 716 constraints/policies for the service, e.g. max latency < N ms, max 717 cost, etc., exclusion policies to route around busy links, min OSNR 718 margin, max preFEC BER etc. All these constraints could be different 719 based on connectivity requirements. 721 Examples of how the "detailed connectivity matrix" can be 722 dimensioned are described in Appendix A. 724 It is also worth noting that the "connectivity matrix" has been 725 originally defined in WSON, [RFC7446], to report the connectivity 726 constrains of a physical node within the WDM network: the 727 information it contains is pretty "static" and therefore, once taken 728 and stored in the TE data base, it can be always being considered 729 valid and up-to-date in path computation request. 731 Using the "basic connectivity matrix" with an abstract node to 732 abstract the information regarding the connectivity constraints of 733 an Optical domain, would make this information more "dynamic" since 734 the connectivity constraints of an Optical domain can change over 735 time because some optical paths that are feasible at a given time 736 may become unfeasible at a later time when e.g., another optical 737 path is established. The information in the "detailed connectivity 738 matrix" is even more dynamic since the establishment of another 739 optical path may change some of the parameters (e.g., delay or 740 available bandwidth) in the "detailed connectivity matrix" while not 741 changing the feasibility of the path. 743 The "connectivity matrix" is sometimes confused with optical reach 744 table that contain multiple (e.g. k-shortest) regen-free reachable 745 paths for every A-Z node combination in the network. Optical reach 746 tables can be calculated offline, utilizing vendor optical design 747 and planning tools, and periodically uploaded to the Controller: 748 these optical path reach tables are fairly static. However, to get 749 the connectivity matrix, between any two sites, either a regen free 750 path can be used, if one is available, or multiple regen free paths 751 are concatenated to get from src to dest, which can be a very large 752 combination. Additionally, when the optical path within optical 753 domain needs to be computed, it can result in different paths based 754 on input objective, constraints, and network conditions. In summary, 755 even though "optical reachability table" is fairly static, which 756 regen free paths to build the connectivity matrix between any source 757 and destination is very dynamic, and is done using very 758 sophisticated routing algorithms. 760 There is therefore the need to keep the information in the "detailed 761 connectivity matrix" updated which means that there another tradeoff 762 between the accuracy (i.e., providing "all" the information that 763 might be needed by the client's PCE) and having up-to-date 764 information. The more the information is provided and the longer it 765 takes to keep it up-to-date which increases the likelihood that the 766 client's PCE computes paths using not updated information. 768 It seems therefore quite challenging to have a "detailed 769 connectivity matrix" that provides accurate, scalable and updated 770 information to allow the client's PCE to take optimal decisions by 771 its own. 773 Instead, if the information in the "detailed connectivity matrix" is 774 not complete/accurate, we can have the following drawbacks 775 considering for example the case in Figure 6: 777 o If only the VP1-VP4 path with available bandwidth of 2 Gb/s and 778 cost 50 is reported, the client's PCE will fail to compute a 5 779 Gb/s path between routers R1 and R2, although this would be 780 feasible; 782 o If only the VP1-VP4 path with available bandwidth of 10 Gb/s and 783 cost 60 is reported, the client's PCE will compute, as optimal, 784 the 1 Gb/s path between R1 and R2 going through the VP2-VP5 path 785 within the Optical domain while the optimal path would actually 786 be the one going thought the VP1-VP4 sub-path (with cost 50) 787 within the Optical domain. 789 Using the approach proposed in this document, the client, when it 790 needs to setup an end-to-end path, it can request the Optical domain 791 controller to compute a set of optimal paths (e.g., for VP1-VP4 and 792 VP2-VP5) and take decisions based on the information received: 794 o When setting up a 5 Gb/s path between routers R1 and R2, the 795 Optical domain controller may report only the VP1-VP4 path as the 796 only feasible path: the Orchestrator can successfully setup the 797 end-to-end path passing though this Optical path; 799 o When setting up a 1 Gb/s path between routers R1 and R2, the 800 Optical domain controller (knowing that the path requires only 1 801 Gb/s) can report both the VP1-VP4 path, with cost 50, and the 802 VP2-VP5 path, with cost 65. The Orchestrator can then compute the 803 optimal path which is passing thought the VP1-VP4 sub-path (with 804 cost 50) within the Optical domain. 806 3.2.2. TE Topology Abstraction 808 Using the TE Topology model, as defined in [TE-TOPO], the underlying 809 SDN controller can export an abstract TE Topology, composed by a set 810 of TE nodes and TE links, representing the abstract view of the 811 topology controlled by each domain controller. 813 Considering the example in Figure 4, the TE domain controller 1 can 814 export a TE Topology encompassing the TE nodes A, B, C and D and the 815 TE Link interconnecting them. In a similar way, TE domain controller 816 2 can export a TE Topology encompassing the TE nodes E, F, G and H 817 and the TE Link interconnecting them. 819 In this example, for simplicity reasons, each abstract TE node maps 820 with each physical node, but this is not necessary. 822 In order to setup a multi-domain TE path (e.g., between nodes A and 823 H), the multi-domain controller can compute by its own an optimal 824 end-to-end path based on the abstract TE topology information 825 provided by the domain controllers. For example: 827 o Multi-domain controller's PCE, based on its own information, can 828 compute the optimal multi-domain path being A-B-C-E-G-H, and then 829 request the TE domain controllers to setup the A-B-C and E-G-H 830 intra-domain paths 832 o But, during path setup, the domain controller may find out that 833 A-B-C intra-domain path is not feasible (as discussed in section 834 2.2, in optical networks it is typical to have some paths not 835 being feasible due to optical constraints that are known only by 836 the optical domain controller), while only the path A-B-D is 837 feasible 839 o So what the multi-domain controller computed is not good and need 840 to re-start the path computation from scratch 842 As discussed in section 3.2.1, providing more extensive abstract 843 information from the TE domain controllers to the multi-domain 844 controller may lead to scalability problems. 846 In a sense this is similar to the problem of routing and wavelength 847 assignment within an Optical domain. It is possible to do first 848 routing (step 1) and then wavelength assignment (step 2), but the 849 chances of ending up with a good path is low. Alternatively, it is 850 possible to do combined routing and wavelength assignment, which is 851 known to be a more optimal and effective way for Optical path setup. 852 Similarly, it is possible to first compute an abstract end-to-end 853 path within the multi-domain Orchestrator (step 1) and then compute 854 an intra-domain path within each Optical domain (step 2), but there 855 are more chances not to find a path or to get a suboptimal path that 856 performing per-domain path computation and then stitch them. 858 3.2.3. Complementary use of TE topology and path computation 860 As discussed in section 2.2, there are some scalability issues with 861 path computation requests in a multi-domain TE network with many TE 862 domains, in terms of the number of requests to send to the TE domain 863 controllers. It would therefore be worthwhile using the TE topology 864 information provided by the domain controllers to limit the number 865 of requests. 867 An example can be described considering the multi-domain abstract 868 topology shown in Figure 7. In this example, an end-to-end TE path 869 between domains A and F needs to be setup. The transit domain should 870 be selected between domains B, C, D and E. 872 .........B......... 873 : _ _ _ _ _ _ _ _ : 874 :/ \: 875 +---O NOT FEASIBLE O---+ 876 cost=5| : : | 877 ......A...... | :.................: | ......F...... 878 : : | | : : 879 : O-----+ .........C......... +-----O : 880 : : : /-------------\ : : : 881 : : :/ \: : : 882 : cost<=20 O---------O cost <= 30 O---------O cost<=20 : 883 : /: cost=5 : : cost=5 :\ : 884 : /------/ : :.................: : \------\ : 885 : / : : \ : 886 :/ cost<=25 : .........D......... : cost<=25 \: 887 O-----------O-------+ : /-------------\ : +-------O-----------O 888 :\ : cost=5| :/ \: |cost=5 : /: 889 : \ : +-O cost <= 30 O-+ : / : 890 : \------\ : : : : /------/ : 891 : cost>=30 \: :.................: :/ cost>=30 : 892 : O-----+ +-----O : 893 :...........: | .........E......... | :...........: 894 | : /-------------\ : | 895 cost=5| :/ \: |cost=5 896 +---O cost >= 30 O---+ 897 : : 898 :.................: 900 Figure 7 - Multi-domain with many domains (Topology information) 902 The actual cost of each intra-domain path is not known a priori from 903 the abstract topology information. The Multi-domain controller only 904 knows, from the TE topology provided by the underlying domain 905 controllers, the feasibility of some intra-domain paths and some 906 upper-bound and/or lower-bound cost information. With this 907 information, together with the cost of inter-domain links, the 908 Multi-domain controller can understand by its own that: 910 o Domain B cannot be selected as the path connecting domains A and 911 E is not feasible; 913 o Domain E cannot be selected as a transit domain since it is know 914 from the abstract topology information provided by domain 915 controllers that the cost of the multi-domain path A-E-F (which 916 is 100, in the best case) will be always be higher than the cost 917 of the multi-domain paths A-D-F (which is 90, in the worst case) 918 and A-E-F (which is 80, in the worst case) 920 Therefore, the Multi-domain controller can understand by its own 921 that the optimal multi-domain path could be either A-D-F or A-E-F 922 but it cannot known which one of the two possible option actually 923 provides the optimal end-to-end path. 925 The Multi-domain controller can therefore request path computation 926 only to the TE domain controllers A, D, E and F (and not to all the 927 possible TE domain controllers). 929 .........B......... 930 : : 931 +---O O---+ 932 ......A...... | :.................: | ......F...... 933 : : | | : : 934 : O-----+ .........C......... +-----O : 935 : : : /-------------\ : : : 936 : : :/ \: : : 937 : cost=15 O---------O cost = 25 O---------O cost=10 : 938 : /: cost=5 : : cost=5 :\ : 939 : /------/ : :.................: : \------\ : 940 : / : : \ : 941 :/ cost=10 : .........D......... : cost=15 \: 942 O-----------O-------+ : /-------------\ : +-------O-----------O 943 : : cost=5| :/ \: |cost=5 : : 944 : : +-O cost = 15 O-+ : : 945 : : : : : : 946 : : :.................: : : 947 : O-----+ +-----O : 948 :...........: | .........E......... | :...........: 949 | : : | 950 +---O O---+ 951 :.................: 953 Figure 8 - Multi-domain with many domains (Path Computation 954 information) 956 Based on these requests, the Multi-domain controller can know the 957 actual cost of each intra-domain paths which belongs to potential 958 optimal end-to-end paths, as shown in Figure 8, and then compute the 959 optimal end-to-end path (e.g., A-D-F, having total cost of 50, 960 instead of A-C-F having a total cost of 70). 962 3.3. Stateless and Stateful Path Computation 964 The TE Tunnel YANG model, defined in [TE-TUNNEL], can support the 965 need to request path computation. 967 It is possible to request path computation by configuring a 968 "compute-only" TE tunnel and retrieving the computed path(s) in the 969 LSP(s) Record-Route Object (RRO) list as described in section 3.3.1 970 of [TE-TUNNEL]. 972 This is a stateful solution since the state of each created 973 "compute-only" TE tunnel needs to be maintained and updated, when 974 underlying network conditions change. 976 It is very useful to provide options for both stateless and stateful 977 path computation mechanisms. It is suggested to use stateless 978 mechanisms as much as possible and to rely on stateful path 979 computation when really needed. 981 Stateless RPC allows requesting path computation using a simple 982 atomic operation and it is the natural option/choice, especially 983 with stateless PCE. 985 Since the operation is stateless, there is no guarantee that the 986 returned path would still be available when path setup is requested: 987 this is not a major issue in case the time between path computation 988 and path setup is short (especially if compared with the time that 989 would be needed to update the information of a very detailed 990 connectivity matrix). 992 In case the stateless solution is not sufficient, a stateful 993 solution, based on "compute-only" TE tunnel, could be used to get 994 notifications in case the computed path has been changed. 996 It is worth noting that also the stateful solution, although 997 increasing the likelihood that the computed path is available at 998 path setup, it does not guaranteed that because notifications may 999 not be reliable or delivered on time. 1001 The stateful path computation has also the following drawbacks: 1003 o Several messages required for any path computation 1005 o Requires persistent storage in the provider controller 1007 o Need for garbage collection for stranded paths 1009 o Process burden to detect changes on the computed paths in order 1010 to provide notifications update 1012 4. Path Computation and Optimization for multiple paths 1014 There are use cases, where it is advantageous to request path 1015 computation for a set of paths, through a network or through a 1016 network domain, using a single request [RFC5440]. 1018 In this case, sending a single request for multiple path 1019 computations, instead of sending multiple requests for each path 1020 computation, would reduce the protocol overhead and it would consume 1021 less resources (e.g., threads in the client and server). 1023 In the context of a typical multi-domain TE network, there could 1024 multiple choices for the ingress/egress points of a domain and the 1025 Multi-domain controller needs to request path computation between 1026 all the ingress/egress pairs to select the best pair. For example, 1027 in the example of section 2.2, the Multi-domain controller needs to 1028 request the TE network controller 1 to compute the A-C and the A-D 1029 paths and to the TE network controller 2 to compute the E-H and the 1030 F-H paths. 1032 It is also possible that the Multi-domain controller receives a 1033 request to setup a group of multiple end to end connections. The 1034 multi-domain controller needs to request each TE domain controller 1035 to compute multiple paths, one (or more) for each end to end 1036 connection. 1038 There are also scenarios where it can be needed to request path 1039 computation for a set of paths in a synchronized fashion. 1041 One example could be computing multiple diverse paths. Computing a 1042 set of diverse paths in a not-synchronized fashion, leads to the 1043 possibility of not being able to satisfy the diversity requirement. 1044 In this case, it is preferable to compute a sub-optimal primary path 1045 for which a diversely routed secondary path exists. 1047 There are also scenarios where it is needed to request optimizing a 1048 set of paths using objective functions that apply to the whole set 1049 of paths, see [RFC5541], e.g. to minimize the sum of the costs of 1050 all the computed paths in the set. 1052 5. YANG Model for requesting Path Computation 1054 This document define a YANG stateless RPC to request path 1055 computation as an "augmentation" of tunnel-rpc, defined in [TE- 1056 TUNNEL]. This model provides the RPC input attributes that are 1057 needed to request path computation and the RPC output attributes 1058 that are needed to report the computed paths. 1060 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1061 +---- path-request* [request-id] 1062 ........... 1064 augment /te:tunnels-rpc/te:output/te:result: 1065 +--ro response* [response-id] 1066 +--ro response-id uint32 1067 +--ro (response-type)? 1068 +--:(no-path-case) 1069 | +--ro no-path! 1070 +--:(path-case) 1071 +--ro computed-path 1072 +--ro path-id? yang-types:uuid 1073 +--ro path-properties 1074 ........... 1075 This model extensively re-uses the grouping defined in [TE-TUNNEL] 1076 to ensure maximal syntax and semantics commonality. 1078 5.1. Synchronization of multiple path computation requests 1080 The YANG model permits to synchronize a set of multiple path 1081 requests (identified by specific request-id) all related to a "svec" 1082 container emulating the syntax of "SVEC" PCEP object [RFC 5440]. 1084 +---- synchronization* [synchronization-id] 1085 +---- synchronization-id uint32 1086 +---- svec 1087 | +---- relaxable? boolean 1088 | +---- disjointness? te-types:te-path-disjointness 1089 | +---- request-id-number* uint32 1090 +---- svec-constraints 1091 | +---- path-metric-bound* [metric-type] 1092 | +---- metric-type identityref 1093 | +---- upper-bound? uint64 1094 +---- path-srlgs 1095 | +---- usage? identityref 1096 | +---- values* srlg 1097 +---- exclude-objects 1098 ........... 1099 +---- optimizations 1100 +---- (algorithm)? 1101 +--:(metric) 1102 | +---- optimization-metric* [metric-type] 1103 | +---- metric-type identityref 1104 | +---- weight? uint8 1105 +--:(objective-function) 1106 +---- objective-function 1107 +---- objective-function-type? identityref 1108 The model, in addition to the metric types, defined in [TE-TUNNEL], 1109 which can be applied to each individual path request, defines 1110 additional specific metrics types that apply to a set of 1111 synchronized requests, as referenced in [RFC5541]. 1113 identity svec-metric-type { 1114 description 1115 "Base identity for svec metric type"; 1116 } 1118 identity svec-metric-cumul-te { 1119 base svec-metric-type; 1120 description 1121 "TE cumulative path metric"; 1122 } 1124 identity svec-metric-cumul-igp { 1125 base svec-metric-type; 1126 description 1127 "IGP cumulative path metric"; 1128 } 1129 identity svec-metric-cumul-hop { 1130 base svec-metric-type; 1131 description 1132 "Hop cumulative path metric"; 1133 } 1135 identity svec-metric-aggregate-bandwidth-consumption { 1136 base svec-metric-type; 1137 description 1138 "Cumulative bandwith consumption of the set of synchronized 1139 paths"; 1140 } 1142 identity svec-metric-load-of-the-most-loaded-link { 1143 base svec-metric-type; 1144 description 1145 "Load of the most loaded link"; 1146 } 1147 5.2. Returned metric values 1149 This YANG model provides a way to return the values of the metrics 1150 computed by the path computation in the output of RPC, together with 1151 other important information (e.g. srlg, affinities, explicit route), 1152 emulating the syntax of the "C" flag of the "METRIC" PCEP object 1153 [RFC 5440]: 1155 augment /te:tunnels-rpc/te:output/te:result: 1156 +--ro response* [response-id] 1157 +--ro response-id uint32 1158 +--ro (response-type)? 1159 +--:(no-path-case) 1160 | +--ro no-path! 1161 +--:(path-case) 1162 +--ro computed-path 1163 +--ro path-id? yang-types:uuid 1164 +--ro path-properties 1165 +--ro path-metric* [metric-type] 1166 | +--ro metric-type identityref 1167 | +--ro accumulative-value? uint64 1168 +--ro path-affinities 1169 | +--ro constraint* [usage] 1170 | +--ro usage identityref 1171 | +--ro value? admin-groups 1172 +--ro path-srlgs 1173 | +--ro usage? identityref 1174 | +--ro values* srlg 1175 +--ro path-route-objects 1176 ........... 1177 It also allows to request which metric should returned in the input 1178 of RPC: 1180 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1181 +---- path-request* [request-id] 1182 | +---- request-id uint32 1183 ........... 1184 | +---- requested-metrics* [metric-type] 1185 | +---- metric-type identityref 1186 ........... 1187 This feature is essential for using a stateless path computation in 1188 a multi-domain TE network as described in section 2.2. In this case, 1189 the metrics returned by a path computation requested to a given TE 1190 network controller must be used by the client to compute the best 1191 end-to-end path. If they are missing the client cannot compare 1192 different paths calculated by the TE network controllers and choose 1193 the best one for the optimal e2e path. 1195 6. YANG model for stateless TE path computation 1197 6.1. YANG Tree 1199 Figure 9 below shows the tree diagram of the YANG model defined in 1200 module ietf-te-path-computation.yang. 1202 module: ietf-te-path-computation 1203 augment /te:tunnels-rpc/te:input/te:tunnel-info: 1204 +---- path-request* [request-id] 1205 | +---- request-id uint32 1206 | +---- te-topology-identifier 1207 | | +---- provider-id? te-types:te-global-id 1208 | | +---- client-id? te-types:te-global-id 1209 | | +---- topology-id? te-types:te-topology-id 1210 | +---- source? inet:ip-address 1211 | +---- destination? inet:ip-address 1212 | +---- src-tp-id? binary 1213 | +---- dst-tp-id? binary 1214 | +---- bidirectional? boolean 1215 | +---- encoding? identityref 1216 | +---- switching-type? identityref 1217 | +---- explicit-route-objects 1218 | | +---- route-object-exclude-always* [index] 1219 | | | +---- index uint32 1220 | | | +---- (type)? 1221 | | | +--:(num-unnum-hop) 1222 | | | | +---- num-unnum-hop 1223 | | | | +---- node-id? te-types:te-node-id 1224 | | | | +---- link-tp-id? te-types:te-tp-id 1225 | | | | +---- hop-type? te-hop-type 1226 | | | | +---- direction? te-link-direction 1227 | | | +--:(as-number) 1228 | | | | +---- as-number-hop 1229 | | | | +---- as-number? binary 1230 | | | | +---- hop-type? te-hop-type 1231 | | | +--:(label) 1232 | | | +---- label-hop 1233 | | | +---- te-label 1234 | | | +---- (technology)? 1235 | | | | +--:(generic) 1236 | | | | +---- generic? rt- 1237 types:generalized-label 1238 | | | +---- direction? te-label-direction 1239 | | +---- route-object-include-exclude* [index] 1240 | | +---- explicit-route-usage? identityref 1241 | | +---- index uint32 1242 | | +---- (type)? 1243 | | +--:(num-unnum-hop) 1244 | | | +---- num-unnum-hop 1245 | | | +---- node-id? te-types:te-node-id 1246 | | | +---- link-tp-id? te-types:te-tp-id 1247 | | | +---- hop-type? te-hop-type 1248 | | | +---- direction? te-link-direction 1249 | | +--:(as-number) 1250 | | | +---- as-number-hop 1251 | | | +---- as-number? binary 1252 | | | +---- hop-type? te-hop-type 1253 | | +--:(label) 1254 | | | +---- label-hop 1255 | | | +---- te-label 1256 | | | +---- (technology)? 1257 | | | | +--:(generic) 1258 | | | | +---- generic? rt- 1259 types:generalized-label 1260 | | | +---- direction? te-label-direction 1261 | | +--:(srlg) 1262 | | +---- srlg 1263 | | +---- srlg? uint32 1264 | +---- path-constraints 1265 | | +---- te-bandwidth 1266 | | | +---- (technology)? 1267 | | | +--:(generic) 1268 | | | +---- generic? te-bandwidth 1269 | | +---- setup-priority? uint8 1270 | | +---- hold-priority? uint8 1271 | | +---- signaling-type? identityref 1272 | | +---- path-metric-bounds 1273 | | | +---- path-metric-bound* [metric-type] 1274 | | | +---- metric-type identityref 1275 | | | +---- upper-bound? uint64 1276 | | +---- path-affinities 1277 | | | +---- constraint* [usage] 1278 | | | +---- usage identityref 1279 | | | +---- value? admin-groups 1280 | | +---- path-srlgs 1281 | | +---- usage? identityref 1282 | | +---- values* srlg 1283 | +---- optimizations 1284 | | +---- (algorithm)? 1285 | | +--:(metric) {path-optimization-metric}? 1286 | | | +---- optimization-metric* [metric-type] 1287 | | | | +---- metric-type 1288 identityref 1289 | | | | +---- weight? uint8 1290 | | | | +---- explicit-route-exclude-objects 1291 | | | | | +---- route-object-exclude-object* [index] 1292 | | | | | +---- index uint32 1293 | | | | | +---- (type)? 1294 | | | | | +--:(num-unnum-hop) 1295 | | | | | | +---- num-unnum-hop 1296 | | | | | | +---- node-id? te-types:te- 1297 node-id 1298 | | | | | | +---- link-tp-id? te-types:te- 1299 tp-id 1300 | | | | | | +---- hop-type? te-hop-type 1301 | | | | | | +---- direction? te-link- 1302 direction 1303 | | | | | +--:(as-number) 1304 | | | | | | +---- as-number-hop 1305 | | | | | | +---- as-number? binary 1306 | | | | | | +---- hop-type? te-hop-type 1307 | | | | | +--:(label) 1308 | | | | | | +---- label-hop 1309 | | | | | | +---- te-label 1310 | | | | | | +---- (technology)? 1311 | | | | | | | +--:(generic) 1312 | | | | | | | +---- generic? rt- 1313 types:generalized-label 1314 | | | | | | +---- direction? te- 1315 label-direction 1316 | | | | | +--:(srlg) 1317 | | | | | +---- srlg 1318 | | | | | +---- srlg? uint32 1319 | | | | +---- explicit-route-include-objects 1320 | | | | +---- route-object-include-object* [index] 1321 | | | | +---- index uint32 1322 | | | | +---- (type)? 1323 | | | | +--:(num-unnum-hop) 1324 | | | | | +---- num-unnum-hop 1325 | | | | | +---- node-id? te-types:te- 1326 node-id 1327 | | | | | +---- link-tp-id? te-types:te- 1328 tp-id 1329 | | | | | +---- hop-type? te-hop-type 1330 | | | | | +---- direction? te-link- 1331 direction 1332 | | | | +--:(as-number) 1333 | | | | | +---- as-number-hop 1334 | | | | | +---- as-number? binary 1335 | | | | | +---- hop-type? te-hop-type 1336 | | | | +--:(label) 1337 | | | | +---- label-hop 1338 | | | | +---- te-label 1339 | | | | +---- (technology)? 1340 | | | | | +--:(generic) 1341 | | | | | +---- generic? rt- 1342 types:generalized-label 1343 | | | | +---- direction? te- 1344 label-direction 1345 | | | +---- tiebreakers 1346 | | | +---- tiebreaker* [tiebreaker-type] 1347 | | | +---- tiebreaker-type identityref 1348 | | +--:(objective-function) {path-optimization-objective- 1349 function}? 1350 | | +---- objective-function 1351 | | +---- objective-function-type? identityref 1352 | +---- requested-metrics* [metric-type] 1353 | | +---- metric-type identityref 1354 | +---- path-in-segment! 1355 | | +---- forward 1356 | | | +---- label-restrictions 1357 | | | +---- label-restriction* [index] 1358 | | | +---- restriction? enumeration 1359 | | | +---- index uint32 1360 | | | +---- label-start 1361 | | | | +---- te-label 1362 | | | | +---- (technology)? 1363 | | | | | +--:(generic) 1364 | | | | | +---- generic? rt- 1365 types:generalized-label 1366 | | | | +---- direction? te-label-direction 1367 | | | +---- label-end 1368 | | | | +---- te-label 1369 | | | | +---- (technology)? 1370 | | | | | +--:(generic) 1371 | | | | | +---- generic? rt- 1372 types:generalized-label 1373 | | | | +---- direction? te-label-direction 1374 | | | +---- range-bitmap? binary 1375 | | +---- reverse 1376 | | +---- label-restrictions 1377 | | +---- label-restriction* [index] 1378 | | +---- restriction? enumeration 1379 | | +---- index uint32 1380 | | +---- label-start 1381 | | | +---- te-label 1382 | | | +---- (technology)? 1383 | | | | +--:(generic) 1384 | | | | +---- generic? rt- 1385 types:generalized-label 1386 | | | +---- direction? te-label-direction 1387 | | +---- label-end 1388 | | | +---- te-label 1389 | | | +---- (technology)? 1390 | | | | +--:(generic) 1391 | | | | +---- generic? rt- 1392 types:generalized-label 1393 | | | +---- direction? te-label-direction 1394 | | +---- range-bitmap? binary 1395 | +---- path-out-segment! 1396 | +---- forward 1397 | | +---- label-restrictions 1398 | | +---- label-restriction* [index] 1399 | | +---- restriction? enumeration 1400 | | +---- index uint32 1401 | | +---- label-start 1402 | | | +---- te-label 1403 | | | +---- (technology)? 1404 | | | | +--:(generic) 1405 | | | | +---- generic? rt- 1406 types:generalized-label 1407 | | | +---- direction? te-label-direction 1408 | | +---- label-end 1409 | | | +---- te-label 1410 | | | +---- (technology)? 1411 | | | | +--:(generic) 1412 | | | | +---- generic? rt- 1413 types:generalized-label 1414 | | | +---- direction? te-label-direction 1415 | | +---- range-bitmap? binary 1416 | +---- reverse 1417 | +---- label-restrictions 1418 | +---- label-restriction* [index] 1419 | +---- restriction? enumeration 1420 | +---- index uint32 1421 | +---- label-start 1422 | | +---- te-label 1423 | | +---- (technology)? 1424 | | | +--:(generic) 1425 | | | +---- generic? rt- 1426 types:generalized-label 1427 | | +---- direction? te-label-direction 1428 | +---- label-end 1429 | | +---- te-label 1430 | | +---- (technology)? 1431 | | | +--:(generic) 1432 | | | +---- generic? rt- 1433 types:generalized-label 1434 | | +---- direction? te-label-direction 1435 | +---- range-bitmap? binary 1436 +---- synchronization* [synchronization-id] 1437 +---- synchronization-id uint32 1438 +---- svec 1439 | +---- relaxable? boolean 1440 | +---- disjointness? te-types:te-path-disjointness 1441 | +---- request-id-number* uint32 1442 +---- svec-constraints 1443 | +---- path-metric-bound* [metric-type] 1444 | +---- metric-type identityref 1445 | +---- upper-bound? uint64 1446 +---- path-srlgs 1447 | +---- usage? identityref 1448 | +---- values* srlg 1449 +---- exclude-objects 1450 | +---- excludes* [index] 1451 | +---- index uint32 1452 | +---- (type)? 1453 | +--:(num-unnum-hop) 1454 | | +---- num-unnum-hop 1455 | | +---- node-id? te-types:te-node-id 1456 | | +---- link-tp-id? te-types:te-tp-id 1457 | | +---- hop-type? te-hop-type 1458 | | +---- direction? te-link-direction 1459 | +--:(as-number) 1460 | | +---- as-number-hop 1461 | | +---- as-number? binary 1462 | | +---- hop-type? te-hop-type 1463 | +--:(label) 1464 | +---- label-hop 1465 | +---- te-label 1466 | +---- (technology)? 1467 | | +--:(generic) 1468 | | +---- generic? rt- 1469 types:generalized-label 1470 | +---- direction? te-label-direction 1471 +---- optimizations 1472 +---- (algorithm)? 1473 +--:(metric) 1474 | +---- optimization-metric* [metric-type] 1475 | +---- metric-type identityref 1476 | +---- weight? uint8 1477 +--:(objective-function) 1478 +---- objective-function 1479 +---- objective-function-type? identityref 1480 augment /te:tunnels-rpc/te:output/te:result: 1482 +--ro response* [response-id] 1483 +--ro response-id uint32 1484 +--ro (response-type)? 1485 +--:(no-path-case) 1486 | +--ro no-path! 1487 +--:(path-case) 1488 +--ro computed-path 1489 +--ro path-id? yang-types:uuid 1490 +--ro path-properties 1491 +--ro path-metric* [metric-type] 1492 | +--ro metric-type identityref 1493 | +--ro accumulative-value? uint64 1494 +--ro path-affinities 1495 | +--ro constraint* [usage] 1496 | +--ro usage identityref 1497 | +--ro value? admin-groups 1498 +--ro path-srlgs 1499 | +--ro usage? identityref 1500 | +--ro values* srlg 1501 +--ro path-route-objects 1502 +--ro path-route-object* [index] 1503 +--ro index uint32 1504 +--ro (type)? 1505 +--:(num-unnum-hop) 1506 | +--ro num-unnum-hop 1507 | +--ro node-id? te-types:te- 1508 node-id 1509 | +--ro link-tp-id? te-types:te- 1510 tp-id 1511 | +--ro hop-type? te-hop-type 1512 | +--ro direction? te-link- 1513 direction 1514 +--:(as-number) 1515 | +--ro as-number-hop 1516 | +--ro as-number? binary 1517 | +--ro hop-type? te-hop-type 1518 +--:(label) 1519 +--ro label-hop 1520 +--ro te-label 1521 +--ro (technology)? 1522 | +--:(generic) 1523 | +--ro generic? rt- 1524 types:generalized-label 1525 +--ro direction? te- 1526 label-direction 1528 Figure 9 - TE path computation YANG tree 1530 6.2. YANG Module 1532 file "ietf-te-path-computation@2018-06-19.yang" 1533 module ietf-te-path-computation { 1534 yang-version 1.1; 1535 namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation"; 1536 // replace with IANA namespace when assigned 1538 prefix "tepc"; 1540 import ietf-inet-types { 1541 prefix "inet"; 1542 } 1544 import ietf-yang-types { 1545 prefix "yang-types"; 1546 } 1548 import ietf-te { 1549 prefix "te"; 1550 } 1552 import ietf-te-types { 1553 prefix "te-types"; 1554 } 1556 organization 1557 "Traffic Engineering Architecture and Signaling (TEAS) 1558 Working Group"; 1560 contact 1561 "WG Web: 1562 WG List: 1564 WG Chair: Lou Berger 1565 1567 WG Chair: Vishnu Pavan Beeram 1568 1570 "; 1572 description "YANG model for stateless TE path computation"; 1574 revision "2018-06-19" { 1575 description "Merging pull requests #45, #47 and #48"; 1576 reference "YANG model for stateless TE path computation"; 1577 } 1579 /* 1580 * Features 1581 */ 1583 feature stateless-path-computation { 1584 description 1585 "This feature indicates that the system supports 1586 stateless path computation."; 1587 } 1589 /* 1590 * Groupings 1591 */ 1593 grouping path-info { 1594 leaf path-id { 1595 type yang-types:uuid; 1596 config false; 1597 description "path-id ref."; 1598 } 1599 uses te-types:generic-path-properties; 1600 description "Path computation output information"; 1601 } 1603 grouping requested-metrics-info { 1604 description "requested metric"; 1605 list requested-metrics { 1606 key 'metric-type'; 1607 description "list of requested metrics"; 1608 leaf metric-type { 1609 type identityref { 1610 base te-types:path-metric-type; 1611 } 1612 description "the requested metric"; 1613 } 1614 } 1615 } 1617 identity svec-metric-type { 1618 description 1619 "Base identity for svec metric type"; 1620 } 1622 identity svec-metric-cumul-te { 1623 base svec-metric-type; 1624 description 1625 "TE cumulative path metric"; 1626 } 1628 identity svec-metric-cumul-igp { 1629 base svec-metric-type; 1630 description 1631 "IGP cumulative path metric"; 1632 } 1634 identity svec-metric-cumul-hop { 1635 base svec-metric-type; 1636 description 1637 "Hop cumulative path metric"; 1639 } 1641 identity svec-metric-aggregate-bandwidth-consumption { 1642 base svec-metric-type; 1643 description 1644 "Cumulative bandwith consumption of the set of synchronized 1645 paths"; 1646 } 1648 identity svec-metric-load-of-the-most-loaded-link { 1649 base svec-metric-type; 1650 description 1651 "Load of the most loaded link"; 1652 } 1654 grouping svec-metrics-bounds_config { 1655 description "TE path metric bounds grouping for computing a set 1656 of 1657 synchronized requests"; 1658 leaf metric-type { 1659 type identityref { 1660 base svec-metric-type; 1661 } 1662 description "TE path metric type usable for computing a set of 1663 synchronized requests"; 1664 } 1665 leaf upper-bound { 1666 type uint64; 1667 description "Upper bound on end-to-end svec path metric"; 1668 } 1669 } 1671 grouping svec-metrics-optimization_config { 1672 description "TE path metric bounds grouping for computing a set 1673 of 1674 synchronized requests"; 1675 leaf metric-type { 1676 type identityref { 1677 base svec-metric-type; 1679 } 1680 description "TE path metric type usable for computing a set of 1681 synchronized requests"; 1682 } 1683 leaf weight { 1684 type uint8; 1685 description "Metric normalization weight"; 1686 } 1687 } 1689 grouping svec-exclude { 1690 description "List of resources to be excluded by all the paths 1691 in the SVEC"; 1692 container exclude-objects { 1693 description "resources to be excluded"; 1694 list excludes { 1695 key index; 1696 description 1697 "List of explicit route objects to always exclude 1698 from synchronized path computation"; 1699 uses te-types:explicit-route-hop; 1700 } 1701 } 1702 } 1704 grouping synchronization-constraints { 1705 description "Global constraints applicable to synchronized 1706 path computation"; 1707 container svec-constraints { 1708 description "global svec constraints"; 1709 list path-metric-bound { 1710 key metric-type; 1711 description "list of bound metrics"; 1712 uses svec-metrics-bounds_config; 1713 } 1714 } 1715 uses te-types:generic-path-srlgs; 1716 uses svec-exclude; 1717 } 1718 grouping synchronization-optimization { 1719 description "Synchronized request optimization"; 1720 container optimizations { 1721 description 1722 "The objective function container that includes 1723 attributes to impose when computing a synchronized set of 1724 paths"; 1726 choice algorithm { 1727 description "Optimizations algorithm."; 1728 case metric { 1729 list optimization-metric { 1730 key "metric-type"; 1731 description "svec path metric type"; 1732 uses svec-metrics-optimization_config; 1733 } 1734 } 1735 case objective-function { 1736 container objective-function { 1737 description 1738 "The objective function container that includes 1739 attributes to impose when computing a TE path"; 1740 uses te-types:path-objective-function_config; 1741 } 1742 } 1743 } 1744 } 1745 } 1747 grouping synchronization-info { 1748 description "Information for sync"; 1749 list synchronization { 1750 key "synchronization-id"; 1751 description "sync list"; 1752 leaf synchronization-id { 1753 type uint32; 1754 description "index"; 1755 } 1756 container svec { 1757 description 1758 "Synchronization VECtor"; 1759 leaf relaxable { 1760 type boolean; 1761 default true; 1762 description 1763 "If this leaf is true, path computation process is free 1764 to ignore svec content. 1765 otherwise it must take into account this svec."; 1766 } 1767 uses te-types:generic-path-disjointness; 1768 leaf-list request-id-number { 1769 type uint32; 1770 description "This list reports the set of M path 1771 computation 1772 requests that must be synchronized."; 1773 } 1774 } 1775 uses synchronization-constraints; 1776 uses synchronization-optimization; 1777 } 1778 } 1780 grouping no-path-info { 1781 description "no-path-info"; 1782 container no-path { 1783 presence "Response without path information, due to failure 1784 performing the path computation"; 1785 description "if path computation cannot identify a path, 1786 rpc returns no path."; 1787 } 1788 } 1790 /* 1791 * These groupings should be removed when defined in te-types 1792 */ 1794 grouping encoding-and-switching-type { 1795 description 1796 "Common grouping to define the LSP encoding and switching 1797 types"; 1799 leaf encoding { 1800 type identityref { 1801 base te-types:lsp-encoding-types; 1802 } 1803 description "LSP encoding type"; 1804 reference "RFC3945"; 1805 } 1806 leaf switching-type { 1807 type identityref { 1808 base te-types:switching-capabilities; 1809 } 1810 description "LSP switching type"; 1811 reference "RFC3945"; 1812 } 1813 } 1815 grouping end-points { 1816 description 1817 "Common grouping to define the TE tunnel end-points"; 1819 leaf source { 1820 type inet:ip-address; 1821 description "TE tunnel source address."; 1822 } 1823 leaf destination { 1824 type inet:ip-address; 1825 description "P2P tunnel destination address"; 1826 } 1827 leaf src-tp-id { 1828 type binary; 1829 description "TE tunnel source termination point identifier."; 1830 } 1831 leaf dst-tp-id { 1832 type binary; 1833 description "TE tunnel destination termination point 1834 identifier."; 1835 } 1836 leaf bidirectional { 1837 type boolean; 1838 default 'false'; 1839 description "TE tunnel bidirectional"; 1840 } 1841 } 1843 /** 1844 * AUGMENTS TO TE RPC 1845 */ 1847 augment "/te:tunnels-rpc/te:input/te:tunnel-info" { 1848 description "statelessComputeP2PPath input"; 1849 list path-request { 1850 key "request-id"; 1851 description "request-list"; 1852 leaf request-id { 1853 type uint32; 1854 mandatory true; 1855 description "Each path computation request is uniquely 1856 identified by the request-id-number. 1857 It must be present also in rpcs."; 1858 } 1859 uses te-types:te-topology-identifier; 1860 uses end-points; 1861 uses encoding-and-switching-type; 1862 uses te-types:path-route-objects; 1863 uses te-types:generic-path-constraints; 1864 uses te-types:generic-path-optimization; 1865 uses requested-metrics-info; 1866 uses te:path-access-segment-info; 1867 } 1868 uses synchronization-info; 1869 } 1871 augment "/te:tunnels-rpc/te:output/te:result" { 1872 description "statelessComputeP2PPath output"; 1873 list response { 1874 key response-id; 1875 config false; 1876 description "response"; 1877 leaf response-id { 1878 type uint32; 1879 description 1880 "The list key that has to reuse request-id-number."; 1881 } 1882 choice response-type { 1883 config false; 1884 description "response-type"; 1885 case no-path-case { 1886 uses no-path-info; 1887 } 1888 case path-case { 1889 container computed-path { 1890 uses path-info; 1891 description "Path computation service."; 1892 } 1893 } 1894 } 1895 } 1896 } 1897 } 1898 1900 Figure 10 - TE path computation YANG module 1902 7. Security Considerations 1904 This document describes use cases of requesting Path Computation 1905 using YANG models, which could be used at the ABNO Control Interface 1906 [RFC7491] and/or between controllers in ACTN [ACTN-frame]. As such, 1907 it does not introduce any new security considerations compared to 1908 the ones related to YANG specification, ABNO specification and ACTN 1909 Framework defined in [RFC7950], [RFC7491] and [ACTN-frame]. 1911 The YANG module defined in this draft is designed to be accessed via 1912 the NETCONF protocol [RFC6241] or RESTCONF protocol [RFC8040]. The 1913 lowest NETCONF layer is the secure transport layer, and the 1914 mandatory-to-implement secure transport is Secure Shell (SSH) 1915 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- 1916 implement secure transport is TLS [RFC5246]. 1918 This document also defines common data types using the YANG data 1919 modeling language. The definitions themselves have no security 1920 impact on the Internet, but the usage of these definitions in 1921 concrete YANG modules might have. The security considerations 1922 spelled out in the YANG specification [RF7950] apply for this 1923 document as well. 1925 The NETCONF access control model [RFC6536] provides the means to 1926 restrict access for particular NETCONF or RESTCONF users to a 1927 preconfigured subset of all available NETCONF or RESTCONF protocol 1928 operations and content. 1930 Note - The security analysis of each leaf is for further study. 1932 8. IANA Considerations 1934 This document registers the following URIs in the IETF XML registry 1935 [RFC3688]. Following the format in [RFC3688], the following 1936 registration is requested to be made. 1938 URI: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 1939 XML: N/A, the requested URI is an XML namespace. 1941 This document registers a YANG module in the YANG Module Names 1942 registry [RFC7950]. 1944 name: ietf-te-path-computation 1945 namespace: urn:ietf:params:xml:ns:yang:ietf-te-path-computation 1946 prefix: tepc 1948 9. References 1950 9.1. Normative References 1952 [RFC5541] Le Roux, JL. et al., " Encoding of Objective Functions in 1953 the Path Computation Element Communication Protocol 1954 (PCEP)", RFC 5541, June 2009. 1956 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1957 and A. Bierman, Ed., "Network Configuration Protocol 1958 (NETCONF)", RFC 6241, June 2011. 1960 [RFC7491] Farrel, A., King, D., "A PCE-Based Architecture for 1961 Application-Based Network Operations", RFC 7491, March 2015. 1963 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 1964 Information Exchange Between Interconnected Traffic 1965 Engineered Networks", RFC 7926, July 2016. 1967 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 1968 7950, August 2016. 1970 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1971 Protocol", RFC 8040, January 2017. 1973 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 1974 draft-ietf-teas-yang-te-topo, work in progress. 1976 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 1977 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1978 te, work in progress. 1980 [ACTN-Frame] Ceccarelli, D., Lee, Y. et al., "Framework for 1981 Abstraction and Control of Traffic Engineered Networks" 1982 draft-ietf-actn-framework, work in progress. 1984 [ACTN-Info] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., 1985 "Information Model for Abstraction and Control of 1986 Transport Networks", draft-ietf-teas-actn-info, work in 1987 progress. 1989 9.2. Informative References 1991 [RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based 1992 Architecture", RFC 4655, August 2006. 1994 [RFC7139] Zhang, F. et al., "GMPLS Signaling Extensions for Control 1995 of Evolving G.709 Optical Transport Networks", RFC 7139, 1996 March 2014. 1998 [RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment 1999 Information Model for Wavelength Switched Optical 2000 Networks", RFC 7446, February 2015. 2002 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical 2003 Transport Network Topology", draft-ietf-ccamp-otn-topo- 2004 yang, work in progress. 2006 [PCEP-Service-Aware] Dhody, D. et al., "Extensions to the Path 2007 Computation Element Communication Protocol (PCEP) to 2008 compute service aware Label Switched Path (LSP)", draft- 2009 ietf-pce-pcep-service-aware, work in progress. 2011 [ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interface 2012 for the optical transport network", June 2016. 2014 10. Acknowledgments 2016 The authors would like to thank Igor Bryskin and Xian Zhang for 2017 participating in discussions and providing valuable insights. 2019 The authors would like to thank the authors of the TE Tunnel YANG 2020 model [TE-TUNNEL], in particular Igor Bryskin, Vishnu Pavan Beeram, 2021 Tarek Saad and Xufeng Liu, for their inputs to the discussions and 2022 support in having consistency between the Path Computation and TE 2023 Tunnel YANG models. 2025 This document was prepared using 2-Word-v2.0.template.dot. 2027 Appendix A. Examples of dimensioning the "detailed connectivity matrix" 2029 In the following table, a list of the possible constraints, 2030 associated with their potential cardinality, is reported. 2032 The maximum number of potential connections to be computed and 2033 reported is, in first approximation, the multiplication of all of 2034 them. 2036 Constraint Cardinality 2037 ---------- ------------------------------------------------------- 2039 End points N(N-1)/2 if connections are bidirectional (OTN and WDM), 2040 N(N-1) for unidirectional connections. 2042 Bandwidth In WDM networks, bandwidth values are expressed in GHz. 2044 On fixed-grid WDM networks, the central frequencies are 2045 on a 50GHz grid and the channel width of the transmitters 2046 are typically 50GHz such that each central frequency can 2047 be used, i.e., adjacent channels can be placed next to 2048 each other in terms of central frequencies. 2050 On flex-grid WDM networks, the central frequencies are on 2051 a 6.25GHz grid and the channel width of the transmitters 2052 can be multiples of 12.5GHz. 2054 For fixed-grid WDM networks typically there is only one 2055 possible bandwidth value (i.e., 50GHz) while for flex- 2056 grid WDM networks typically there are 4 possible 2057 bandwidth values (e.g., 37.5GHz, 50GHz, 62.5GHz, 75GHz). 2059 In OTN (ODU) networks, bandwidth values are expressed as 2060 pairs of ODU type and, in case of ODUflex, ODU rate in 2061 bytes/sec as described in section 5 of [RFC7139]. 2063 For "fixed" ODUk types, 6 possible bandwidth values are 2064 possible (i.e., ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4). 2066 For ODUflex(GFP), up to 80 different bandwidth values can 2067 be specified, as defined in Table 7-8 of [ITU-T G.709- 2068 2016]. 2070 For other ODUflex types, like ODUflex(CBR), the number of 2071 possible bandwidth values depends on the rates of the 2072 clients that could be mapped over these ODUflex types, as 2073 shown in Table 7.2 of [ITU-T G.709-2016], which in theory 2074 could be a countinuum of values. However, since different 2075 ODUflex bandwidths that use the same number of TSs on 2076 each link along the path are equivalent for path 2077 computation purposes, up to 120 different bandwidth 2078 ranges can be specified. 2080 Ideas to reduce the number of ODUflex bandwidth values in 2081 the detailed connectivity matrix, to less than 100, are 2082 for further study. 2084 Bandwidth specification for ODUCn is currently for 2085 further study but it is expected that other bandwidth 2086 values can be specified as integer multiples of 100Gb/s. 2088 In IP we have bandwidth values in bytes/sec. In 2089 principle, this is a countinuum of values, but in 2090 practice we can identify a set of bandwidth ranges, where 2091 any bandwidth value inside the same range produces the 2092 same path. 2093 The number of such ranges is the cardinality, which 2094 depends on the topology, available bandwidth and status 2095 of the network. Simulations (Note: reference paper 2096 submitted for publication) show that values for medium 2097 size topologies (around 50-150 nodes) are in the range 4- 2098 7 (5 on average) for each end points couple. 2100 Metrics IGP, TE and hop number are the basic objective metrics 2101 defined so far. There are also the 2 objective functions 2102 defined in [RFC5541]: Minimum Load Path (MLP) and Maximum 2103 Residual Bandwidth Path (MBP). Assuming that one only 2104 metric or objective function can be optimized at once, 2105 the total cardinality here is 5. 2107 With [PCEP-Service-Aware], a number of additional metrics 2108 are defined, including Path Delay metric, Path Delay 2109 Variation metric and Path Loss metric, both for point-to- 2110 point and point-to-multipoint paths. This increases the 2111 cardinality to 8. 2113 Bounds Each metric can be associated with a bound in order to 2114 find a path having a total value of that metric lower 2115 than the given bound. This has a potentially very high 2116 cardinality (as any value for the bound is allowed). In 2117 practice there is a maximum value of the bound (the one 2118 with the maximum value of the associated metric) which 2119 results always in the same path, and a range approach 2120 like for bandwidth in IP should produce also in this case 2121 the cardinality. Assuming to have a cardinality similar 2122 to the one of the bandwidth (let say 5 on average) we 2123 should have 6 (IGP, TE, hop, path delay, path delay 2124 variation and path loss; we don't consider here the two 2125 objective functions of [RFC5541] as they are conceived 2126 only for optimization)*5 = 30 cardinality. 2128 Technology 2129 constraints For further study 2131 Priority We have 8 values for setup priority, which is used in 2132 path computation to route a path using free resources 2133 and, where no free resources are available, resources 2134 used by LSPs having a lower holding priority. 2136 Local prot It's possible to ask for a local protected service, where 2137 all the links used by the path are protected with fast 2138 reroute (this is only for IP networks, but line 2139 protection schemas are available on the other 2140 technologies as well). This adds an alternative path 2141 computation, so the cardinality of this constraint is 2. 2143 Administrative 2144 Colors Administrative colors (aka affinities) are typically 2145 assigned to links but when topology abstraction is used 2146 affinity information can also appear in the detailed 2147 connectivity matrix. 2149 There are 32 bits available for the affinities. Links can 2150 be tagged with any combination of these bits, and path 2151 computation can be constrained to include or exclude any 2152 or all of them. The relevant cardinality is 3 (include- 2153 any, exclude-any, include-all) times 2^32 possible 2154 values. However, the number of possible values used in 2155 real networks is quite small. 2157 Included Resources 2159 A path computation request can be associated to an 2160 ordered set of network resources (links, nodes) to be 2161 included along the computed path. This constraint would 2162 have a huge cardinality as in principle any combination 2163 of network resources is possible. However, as far as the 2164 Orchestrator doesn't know details about the internal 2165 topology of the domain, it shouldn't include this type of 2166 constraint at all (see more details below). 2168 Excluded Resources 2170 A path computation request can be associated to a set of 2171 network resources (links, nodes, SRLGs) to be excluded 2172 from the computed path. Like for included resources, 2173 this constraint has a potentially very high cardinality, 2174 but, once again, it can't be actually used by the 2175 Orchestrator, if it's not aware of the domain topology 2176 (see more details below). 2177 As discussed above, the Orchestrator can specify include or exclude 2178 resources depending on the abstract topology information that the 2179 domain controller exposes: 2181 o In case the domain controller exposes the entire domain as a 2182 single abstract TE node with his own external terminations and 2183 detailed connectivity matrix (whose size we are estimating), no 2184 other topological details are available, therefore the size of 2185 the detailed connectivity matrix only depends on the combination 2186 of the constraints that the Orchestrator can use in a path 2187 computation request to the domain controller. These constraints 2188 cannot refer to any details of the internal topology of the 2189 domain, as those details are not known to the Orchestrator and so 2190 they do not impact size of the detailed connectivity matrix 2191 exported. 2193 o Instead in case the domain controller exposes a topology 2194 including more than one abstract TE nodes and TE links, and their 2195 attributes (e.g. SRLGs, affinities for the links), the 2196 Orchestrator knows these details and therefore could compute a 2197 path across the domain referring to them in the constraints. The 2198 detailed connectivity matrixes, whose size need to be estimated 2199 here, are the ones relevant to the abstract TE nodes exported to 2200 the Orchestrator. These detailed connectivity matrixes and 2201 therefore theirs sizes, while cannot depend on the other abstract 2202 TE nodes and TE links, which are external to the given abstract 2203 node, could depend to SRLGs (and other attributes, like 2204 affinities) which could be present also in the portion of the 2205 topology represented by the abstract nodes, and therefore 2206 contribute to the size of the related detailed connectivity 2207 matrix. 2209 We also don't consider here the possibility to ask for more than one 2210 path in diversity or for point-to-multi-point paths, which are for 2211 further study. 2213 Considering for example an IP domain without considering SRLG and 2214 affinities, we have an estimated number of paths depending on these 2215 estimated cardinalities: 2217 Endpoints = N*(N-1), Bandwidth = 5, Metrics = 6, Bounds = 20, 2218 Priority = 8, Local prot = 2 2220 The number of paths to be pre-computed by each IP domain is 2221 therefore 24960 * N(N-1) where N is the number of domain access 2222 points. 2224 This means that with just 4 access points we have nearly 300000 2225 paths to compute, advertise and maintain (if a change happens in the 2226 domain, due to a fault, or just the deployment of new traffic, a 2227 substantial number of paths need to be recomputed and the relevant 2228 changes advertised to the upper controller). 2230 This seems quite challenging. In fact, if we assume a mean length of 2231 1K for the json describing a path (a quite conservative estimate), 2232 reporting 300000 paths means transferring and then parsing more than 2233 300 Mbytes for each domain. If we assume that 20% (to be checked) of 2234 this paths change when a new deployment of traffic occurs, we have 2235 60 Mbytes of transfer for each domain traversed by a new end-to-end 2236 path. If a network has, let say, 20 domains (we want to estimate the 2237 load for a non-trivial domain setup) in the beginning a total 2238 initial transfer of 6Gigs is needed, and eventually, assuming 4-5 2239 domains are involved in mean during a path deployment we could have 2240 240-300 Mbytes of changes advertised to the higher order controller. 2242 Further bare-bone solutions can be investigated, removing some more 2243 options, if this is considered not acceptable; in conclusion, it 2244 seems that an approach based only on the information provided by the 2245 detailed connectivity matrix is hardly feasible, and could be 2246 applicable only to small networks with a limited meshing degree 2247 between domains and renouncing to a number of path computation 2248 features. 2250 Contributors 2252 Dieter Beller 2253 Nokia 2254 Email: dieter.beller@nokia.com 2256 Gianmarco Bruno 2257 Ericsson 2258 Email: gianmarco.bruno@ericsson.com 2260 Francesco Lazzeri 2261 Ericsson 2262 Email: francesco.lazzeri@ericsson.com 2264 Young Lee 2265 Huawei 2266 Email: leeyoung@huawei.com 2268 Carlo Perocchio 2269 Ericsson 2270 Email: carlo.perocchio@ericsson.com 2272 Authors' Addresses 2274 Italo Busi (Editor) 2275 Huawei 2276 Email: italo.busi@huawei.com 2278 Sergio Belotti (Editor) 2279 Nokia 2280 Email: sergio.belotti@nokia.com 2282 Victor Lopez 2283 Telefonica 2284 Email: victor.lopezalvarez@telefonica.com 2285 Oscar Gonzalez de Dios 2286 Telefonica 2287 Email: oscar.gonzalezdedios@telefonica.com 2289 Anurag Sharma 2290 Google 2291 Email: ansha@google.com 2293 Yan Shi 2294 China Unicom 2295 Email: shiyan49@chinaunicom.cn 2297 Ricard Vilalta 2298 CTTC 2299 Email: ricard.vilalta@cttc.es 2301 Karthik Sethuraman 2302 NEC 2303 Email: karthik.sethuraman@necam.com 2305 Michael Scharf 2306 Nokia 2307 Email: michael.scharf@nokia.com 2309 Daniele Ceccarelli 2310 Ericsson 2311 Email: daniele.ceccarelli@ericsson.com