idnits 2.17.1 draft-ietf-pce-applicability-actn-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 6, 2019) is 1847 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-06 == Outdated reference: A later version (-08) exists of draft-ietf-pce-inter-area-as-applicability-07 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-13 == Outdated reference: A later version (-13) exists of draft-lee-pce-pcep-ls-optical-07 == Outdated reference: A later version (-08) exists of draft-leedhody-pce-vn-association-07 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-05 == Outdated reference: A later version (-16) exists of draft-ietf-pce-association-policy-05 == Outdated reference: A later version (-04) exists of draft-dugeon-pce-stateful-interdomain-02 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Y. Lee 4 Intended status: Informational Huawei Technologies 5 Expires: October 8, 2019 D. Ceccarelli 6 Ericsson 7 April 6, 2019 9 Applicability of the Path Computation Element (PCE) to the Abstraction 10 and Control of TE Networks (ACTN) 11 draft-ietf-pce-applicability-actn-11 13 Abstract 15 Abstraction and Control of TE Networks (ACTN) refers to the set of 16 virtual network (VN) operations needed to orchestrate, control and 17 manage large-scale multi-domain TE networks so as to facilitate 18 network programmability, automation, efficient resource sharing, and 19 end-to-end virtual service aware connectivity and network function 20 virtualization services. 22 The Path Computation Element (PCE) is a component, application, or 23 network node that is capable of computing a network path or route 24 based on a network graph and applying computational constraints. The 25 PCE serves requests from Path Computation Clients (PCCs) that 26 communicate with it over a local API or using the Path Computation 27 Element Communication Protocol (PCEP). 29 This document examines the applicability of PCE to the ACTN 30 framework. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 8, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Background Information . . . . . . . . . . . . . . . . . . . 3 68 2.1. Path Computation Element (PCE) . . . . . . . . . . . . . 3 69 2.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 4 70 2.1.2. PCE in Multi-domain and Multi-layer Deployments . . . 4 71 2.1.3. Relationship to PCE Based Central Control . . . . . . 5 72 2.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5 73 3. Architectural Considerations . . . . . . . . . . . . . . . . 7 74 3.1. Multi-Domain Coordination via Hierarchy . . . . . . . . . 7 75 3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9 77 3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10 78 4. Interface Considerations . . . . . . . . . . . . . . . . . . 10 79 5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 9.2. Informative References . . . . . . . . . . . . . . . . . 16 86 Appendix A. Additional Information . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 Abstraction and Control of TE Networks (ACTN) [RFC8453] refers to the 92 set of virtual network (VN) operations needed to orchestrate, control 93 and manage large-scale multi-domain TE networks so as to facilitate 94 network programmability, automation, efficient resource sharing, and 95 end-to-end virtual service aware connectivity and network function 96 virtualization services. 98 The Path Computation Element (PCE) [RFC4655] is a component, 99 application, or network node that is capable of computing a network 100 path or route based on a network graph and applying computational 101 constraints. The PCE serves requests from Path Computation Clients 102 (PCCs) that communicate with it over a local API or using the Path 103 Computation Element Communication Protocol (PCEP). 105 This document examines the PCE and ACTN architecture and describes 106 how PCE architecture is applicable to ACTN. It also lists the PCEP 107 extensions that are needed to use PCEP as an ACTN interface. This 108 document also identifies any gaps in PCEP, that exist at the time of 109 publication of this document. 111 Further, ACTN, stateful H-PCE [I-D.ietf-pce-stateful-hpce], and PCE 112 as a central controller (PCECC) [RFC8283] are based on the same basic 113 hierarchy framework and thus compatible with each other. 115 2. Background Information 117 2.1. Path Computation Element (PCE) 119 The Path Computation Element Communication Protocol (PCEP) [RFC5440] 120 provides mechanisms for Path Computation Clients (PCCs) to request a 121 Path Computation Element (PCE) [RFC4655] to perform path 122 computations. 124 The ability to compute shortest constrained TE LSPs in Multiprotocol 125 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 126 multiple domains has been identified as a key motivation for PCE 127 development. 129 A stateful PCE [RFC8231] is capable of considering, for the purposes 130 of path computation, not only the network state in terms of links and 131 nodes (referred to as the Traffic Engineering Database or TED) but 132 also the status of active services (previously computed paths), and 133 currently reserved resources, stored in the Label Switched Paths 134 Database (LSP-DB). 136 [RFC8051] describes general considerations for a stateful PCE 137 deployment and examines its applicability and benefits, as well as 138 its challenges and limitations through a number of use cases. 140 [RFC8231] describes a set of extensions to PCEP to provide stateful 141 control. A stateful PCE has access to not only the information 142 carried by the network's Interior Gateway Protocol (IGP), but also 143 the set of active paths and their reserved resources for its 144 computations. The additional state allows the PCE to compute 145 constrained paths while considering individual LSPs and their 146 interactions. [RFC8281] describes the setup, maintenance and 147 teardown of PCE-initiated LSPs under the stateful PCE model. 149 [RFC8231] also describes the active stateful PCE. The active PCE 150 functionality allows a PCE to reroute an existing LSP or make changes 151 to the attributes of an existing LSP, or a PCC to delegate control of 152 specific LSPs to a new PCE. 154 2.1.1. Role of PCE in SDN 156 Software-Defined Networking (SDN) [RFC7149] refers to a separation 157 between the control elements and the forwarding components so that 158 software running in a centralized system called a controller, can act 159 to program the devices in the network to behave in specific ways. A 160 required element in an SDN architecture is a component that plans how 161 the network resources will be used and how the devices will be 162 programmed. It is possible to view this component as performing 163 specific computations to place flows within the network given 164 knowledge of the availability of network resources, how other 165 forwarding devices are programmed, and the way that other flows are 166 routed. It is concluded in [RFC7399], that this is the same function 167 that a PCE might offer in a network operated using a dynamic control 168 plane. This is the function and purpose of a PCE, and the way that a 169 PCE integrates into a wider network control system including SDN is 170 presented in Application-Based Network Operation (ABNO) [RFC7491]. 172 2.1.2. PCE in Multi-domain and Multi-layer Deployments 174 Computing paths across large multi-domain environments requires 175 special computational components and cooperation between entities in 176 different domains capable of complex path computation. The PCE 177 provides an architecture and a set of functional components to 178 address this problem space. A PCE may be used to compute end-to-end 179 paths across multi-domain environments using a per-domain path 180 computation technique [RFC5152]. The Backward Recursive PCE based 181 path computation (BRPC) mechanism [RFC5441] defines a PCE-based path 182 computation procedure to compute inter-domain constrained MPLS and 183 GMPLS TE networks. However, per-domain technique assumes that the 184 sequence of domains to be crossed from source to destination is 185 known, either fixed by the network operator or obtained by other 186 means. BRPC can work best with a known domain sequence, and it will 187 also work nicely with a small set of interconnected domains. 188 However, it doesn't work well for is a large set of interconnected 189 domains. 191 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can 192 be used for computing end-to-end paths for inter-domain MPLS Traffic 193 Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the 194 domain sequence is not known. Within the Hierarchical PCE (H-PCE) 195 architecture, the Parent PCE (P-PCE) is used to compute a multi- 196 domain path based on the domain connectivity information. A Child 197 PCE (C-PCE) may be responsible for a single domain or multiple 198 domains, it is used to compute the intra-domain path based on its 199 domain topology information. 201 [I-D.ietf-pce-stateful-hpce] state the considerations for stateful 202 PCEs in hierarchical PCE architecture. In particular, the behavior 203 changes and additions to the existing stateful PCE mechanisms 204 (including PCE- initiated LSP setup and active PCE usage) in the 205 context of networks using the H-PCE architecture. 207 [RFC5623] describes a framework for applying the PCE-based 208 architecture to inter-layer to (G)MPLS TE. It provides suggestions 209 for the deployment of PCE in support of multi-layer networks. It 210 also describes the relationship between PCE and a functional 211 component in charge of the control and management of the Virtual 212 Network Topology (VNT) [RFC5212], called the VNT Manager (VNTM). 214 2.1.3. Relationship to PCE Based Central Control 216 [RFC8283] introduces the architecture for PCE as a central controller 217 (PCECC), it further examines the motivations and applicability for 218 PCEP as a southbound interface, and introduces the implications for 219 the protocol. Section 2.1.3 of [RFC8283] describe a hierarchy of 220 PCE-based controller as per the Hierarchy of PCE framework defined in 221 [RFC6805]. 223 2.2. Abstraction and Control of TE Networks (ACTN) 225 [RFC8453] describes the high-level ACTN requirements and the 226 architecture model for ACTN including the entities Customer Network 227 Controller (CNC), Multi-domain Service Coordinator (MDSC), and 228 Provisioning Network Controller (PNC) and their interfaces. 230 The ACTN reference architecture is shown in Figure 1 which is 231 reproduced here from [RFC8453] for convenience. [RFC8453] remains 232 the definitive reference for the ACTN architecture. As depicted in 233 Figure 1, the ACTN architecture identifies a three-tier hierarchy. 235 +---------+ +---------+ +---------+ 236 | CNC | | CNC | | CNC | 237 +---------+ +---------+ +---------+ 238 \ | / 239 \ | / 240 Boundary =============\==============|==============/============ 241 Between \ | / 242 Customer & ------- | CMI ------- 243 Network Operator \ | / 244 +---------------+ 245 | MDSC | 246 +---------------+ 247 / | \ 248 ------------ | MPI ------------- 249 / | \ 250 +-------+ +-------+ +-------+ 251 | PNC | | PNC | | PNC | 252 +-------+ +-------+ +-------+ 253 | SBI / | / \ 254 | / | SBI / \ 255 --------- ----- | / \ 256 ( ) ( ) | / \ 257 - Control - ( Phys. ) | / ----- 258 ( Plane ) ( Net ) | / ( ) 259 ( Physical ) ----- | / ( Phys. ) 260 ( Network ) ----- ----- ( Net ) 261 - - ( ) ( ) ----- 262 ( ) ( Phys. ) ( Phys. ) 263 --------- ( Net ) ( Net ) 264 ----- ----- 266 CMI - (CNC-MDSC Interface) 267 MPI - (MDSC-PNC Interface) 269 Figure 1: ACTN Hierarchy 271 There are two interfaces with respect to the MDSC: one north of the 272 MDSC (the CNC-MDSC Interface : CMI), and one south (the MDSC-PNC 273 Interface : MPI). A hierarchy of MDSCs is possible with a recursive 274 MPI interface. 276 [RFC8454] provides an information model for ACTN interfaces. 278 3. Architectural Considerations 280 The ACTN architecture [RFC8453] is based on hierarchy and 281 recursiveness of controllers. It defines three types of controllers 282 (depending on the functionalities they implement). The main 283 functionalities are - 285 o Multi-domain coordination 287 o Abstraction 289 o Customer mapping/translation 291 o Virtual service coordination 293 Section 3 of [RFC8453] describes these functions. 295 It should be noted that this document lists all possible ways in 296 which PCE could be used for each of the above functions, but all 297 functions are not required to be implemented via PCE. Similarly, 298 this document presents the ways in which PCEP could be used as the 299 communications medium between functional components. Operators may 300 choose to use the PCEP for multi-domain coordination via stateful 301 H-PCE, but alternatively use NETCONF [RFC6241], RESTCONF [RFC8040], 302 or BGP-LS [RFC7752] to get access to the topology and support 303 abstraction function. 305 3.1. Multi-Domain Coordination via Hierarchy 307 With the definition of domain being "everything that is under the 308 control of the single logical controller", as per [RFC8453], it is 309 needed to have a control entity that oversees the specific aspects of 310 the different domains and to build a single abstracted end-to-end 311 network topology in order to coordinate end-to-end path computation 312 and path/service provisioning. 314 The MDSC in ACTN framework realizes this function by coordinating the 315 per-domain PNCs in a hierarchy of controllers. It also needs to 316 detach from the underlying network technology and express customer 317 concerns by business needs. 319 [RFC6805] and [I-D.ietf-pce-stateful-hpce] describe a hierarchy of 320 PCEs with the Parent PCE coordinating multi-domain path computation 321 function between Child PCEs. It is easy to see how these principles 322 align, and thus how the stateful H-PCE architecture can be used to 323 realize ACTN. 325 The per domain stitched LSP in the Hierarchical stateful PCE 326 architecture, described in Section 3.3.1 of 327 [I-D.ietf-pce-stateful-hpce] is well suited for multi-domain 328 coordination function. This includes domain sequence selection; End- 329 to-End (E2E) path computation; Controller (PCE) initiated path setup 330 and reporting. This is also applicable to multi-layer coordination 331 in case of IP+optical networks. 333 [I-D.litkowski-pce-state-sync] describes the procedures to allow a 334 stateful communication between PCEs for various use-cases. The 335 procedures and extensions are also applicable to Child and Parent PCE 336 communication and thus useful for ACTN as well. 338 3.2. Abstraction 340 To realize ACTN, an abstracted view of the underlying network 341 resources needs to be built. This includes global network-wide 342 abstracted topology based on the underlying network resources of each 343 domain. This also includes abstract topology created as per the 344 customer service connectivity requests and represented as a VN slice 345 allocated to each customer. 347 In order to compute and provide optimal paths, PCEs require an 348 accurate and timely Traffic Engineering Database (TED). 349 Traditionally this TED has been obtained from a link state (LS) 350 routing protocol supporting traffic engineering extensions. PCE may 351 construct its TED by participating in the IGP ([RFC3630] and 352 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 353 alternative is offered by BGP-LS [RFC7752]. 355 In case of H-PCE [RFC6805], the Parent PCE needs to build the domain 356 topology map of the child domains and their interconnectivity. 357 [RFC6805] and [I-D.ietf-pce-inter-area-as-applicability] suggest that 358 BGP-LS could be used as a "northbound" TE advertisement from the 359 Child PCE to the Parent PCE. 361 [I-D.dhodylee-pce-pcep-ls] proposes another approach for learning and 362 maintaining the Link-State and TE information as an alternative to 363 IGPs and BGP flooding, using PCEP itself. The Child PCE can use this 364 mechanism to transport Link-State and TE information from Child PCE 365 to a Parent PCE using PCEP. 367 In ACTN, there is a need to control the level of abstraction based on 368 the deployment scenario and business relationship between the 369 controllers. The mechanism used to disseminate information from PNC 370 (Child PCE) to MDSC (Parent PCE) should support abstraction. 371 [RFC8453] describes a few alternative approaches of abstraction. The 372 resulting abstracted topology can be encoded using the PCEP-LS 373 mechanisms [I-D.dhodylee-pce-pcep-ls] and its optical network 374 extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS is an attractive 375 option when the operator would wish to have a single control plane 376 protocol (PCEP) to achieve ACTN functions. 378 [RFC8453] discusses two ways to build abstract topology from an MDSC 379 standpoint with interaction with PNCs. The primary method is called 380 automatic generation of abstract topology by configuration. With 381 this method, automatic generation is based on the abstraction/ 382 summarization of the whole domain by the PNC and its advertisement on 383 the MPI. The secondary method is called on-demand generation of 384 supplementary topology via Path Compute Request/Reply. This method 385 may be needed to obtain further complementary information such as 386 potential connectivity from Child PCEs in order to facilitate an end- 387 to-end path provisioning. PCEP is well suited to support both 388 methods. 390 3.3. Customer Mapping 392 In ACTN, there is a need to map customer virtual network (VN) 393 requirements into a network provisioning request to the PNC. That 394 is, the customer requests/commands are mapped by the MDSC into 395 network provisioning requests that can be sent to the PNC. 396 Specifically, the MDSC provides mapping and translation of a 397 customer's service request into a set of parameters that are specific 398 to a network type and technology such that network configuration 399 process is made possible. 401 [RFC8281] describes the setup, maintenance and teardown of PCE- 402 initiated LSPs under the stateful PCE model, without the need for 403 local configuration on the PCC, thus allowing for a dynamic network 404 that is centrally controlled and deployed. To instantiate or delete 405 an LSP, the PCE sends the Path Computation LSP Initiate Request 406 (PCInitiate) message to the PCC. As described in 407 [I-D.ietf-pce-stateful-hpce], for inter-domain LSP in Hierarchical 408 PCE architecture, the initiation operations can be carried out at the 409 Parent PCE. In which case, after Parent PCE finishes the E2E path 410 computation, it can send the PCInitiate message to the Child PCE, the 411 Child PCE further propagates the initiate request to the Label 412 Switching Router (LSR). The customer request is received by the MDSC 413 (Parent PCE) and based on the business logic, global abstracted 414 topology, network conditions and local policy, the MDSC (Parent PCE) 415 translates this into per domain LSP initiation request that a PNC 416 (Child PCE) can understand and act on. This can be done via the 417 PCInitiate message. 419 PCEP extensions for associating opaque policy between PCEP peer 420 [I-D.ietf-pce-association-policy] can be used. 422 3.4. Virtual Service Coordination 424 Virtual service coordination function in ACTN incorporates customer 425 service-related information into the virtual network service 426 operations in order to seamlessly operate virtual networks while 427 meeting customer's service requirements. 429 [I-D.leedhody-pce-vn-association] describes the need for associating 430 a set of LSPs with a VN "construct" to facilitate VN operations in 431 PCE architecture. This association allows the PCEs to identify which 432 LSPs belong to a certain VN. 434 This association based on VN is useful for various optimizations at 435 the VN level which can be applied to all the LSPs that are part of 436 the VN slice. During path computation, the impact of a path for an 437 LSP is compared against the paths of other LSPs in the VN. This is 438 to make sure that the overall optimization and SLA of the VN rather 439 than of a single LSP. Similarly, during re-optimization, advanced 440 path computation algorithm and optimization technique can be 441 considered for all the LSPs belonging to a VN/customer and optimize 442 them all together. 444 4. Interface Considerations 446 As per [RFC8453], to allow virtualization and multi-domain 447 coordination, the network has to provide open, programmable 448 interfaces, in which customer applications can create, replace and 449 modify virtual network resources and services in an interactive, 450 flexible and dynamic fashion while having no impact on other 451 customers. The two ACTN interfaces are - 453 o The CNC-MDSC Interface (CMI) is an interface between a Customer 454 Network Controller and a Multi-Domain Service Coordinator. It 455 requests the creation of the network resources, topology or 456 services for the applications. The MDSC may also report potential 457 network topology availability if queried for current capability 458 from the Customer Network Controller. 460 o The MDSC-PNC Interface (MPI) is an interface between a Multi- 461 Domain Service Coordinator and a Provisioning Network Controller. 462 It communicates the creation request, if required, of new 463 connectivity of bandwidth changes in the physical network, via the 464 PNC. In multi-domain environments, the MDSC needs to establish 465 multiple MPIs, one for each PNC, as there are multiple PNCs 466 responsible for its domain control. 468 In the case of hierarchy MDSCs, the MPI is applied recursively. From 469 an abstraction point of view, the top level MDSC which interfaces the 470 CNC operates on a higher level of abstraction (i.e., less granular 471 level) than the lower level MSDCs. 473 PCEP is especially suitable on the MPI as it meets the requirement 474 and the functions as set out in the ACTN framework [RFC8453]. Its 475 recursive nature is well suited via the multi-level hierarchy of PCE. 476 PCEP can also be applied to the CMI as the CNC can be a path 477 computation client while the MDSC can be a path computation server. 478 Section 5 describes how PCE and PCEP could help realize ACTN on the 479 MPI. 481 5. Realizing ACTN with PCE (and PCEP) 483 As per the example in Figure 2, there are 4 domains, each with its 484 own PNC and an MDSC on top. The PNC and MDSC need PCE as an 485 important function. The PNC (or Child PCE) already uses PCEP to 486 communicate to the network device. It can utilize the PCEP as the 487 MPI to communicate between controllers too. 489 ****** 490 ..........*MDSC*.............................. 491 . ****** .. MPI . 492 . . . . 493 . . . . 494 . . . . 495 . . . . 496 . . . . 497 . . . . 498 v v v . 499 ****** ****** ****** . 500 *PNC1* *PNC2* *PNC4* . 501 ****** ****** ****** . 502 +---------------+ +---------------+ +---------------+ . 503 |A |----| |----| C| . 504 | | | | | | . 505 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . 506 +------------B13+ +---------------+ +B43------------+ . 507 \ / . 508 \ ****** / . 509 \ *PNC3*<............/..................... 510 \ ****** / 511 \+---------------+/ 512 B31 B34 513 | | 514 |DOMAIN 3 B| 515 +---------------+ 517 MDSC -> Parent PCE 518 PNC -> Child PCE 519 MPI -> PCEP 521 Figure 2: ACTN with PCE 523 o Building Domain Topology at MDSC: PNC (or Child PCE) needs to have 524 the TED to compute path in its domain. As described in 525 Section 3.2, it can learn the topology via IGP or BGP-LS. PCEP-LS 526 is also a proposed mechanism to carry link state and traffic 527 engineering information within PCEP. A mechanism to carry 528 abstracted topology while hiding technology specific information 529 between PNC and MDSC is described in [I-D.dhodylee-pce-pcep-ls]. 530 At the end of this step the MDSC (or Parent PCE) has the 531 abstracted topology from each of its PNC (or Child PCE). This 532 could be as simple as a domain topology map as described in 533 [RFC6805] or it can have full topology information of all domains. 534 The latter is not scalable and thus an abstracted topology of each 535 domain interconnected by inter-domain links is the most common 536 case. 538 * Topology Change: When the PNC learns of any topology change, 539 the PNC needs to decide if the change needs to be notified to 540 the MDSC. This is dependent on the level of abstraction 541 between the MDSC and the PNC. 543 o VN Instantiate: When an MDSC is requested to instantiate a VN, the 544 minimal information that is required would be a VN identifier and 545 a set of end points. Various path computation, setup constraints 546 and objective functions may also be provided. In PCE terms, a VN 547 Instantiate can be considered as a set of paths belonging to the 548 same VN. As described in Section 3.4 and 549 [I-D.leedhody-pce-vn-association] the VN association can help in 550 identifying the set of paths that belong to a VN. The rest of the 551 information like the endpoints, constraints and objective function 552 (OF) is already defined in PCEP in terms of a single path. 554 * Path Computation: As per the example in Figure 2, the VN 555 instantiate requires two end to end paths between (A in Domain 556 1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The 557 MDSC (or Parent PCE) triggers the end to end path computation 558 for these two paths. MDSC can do path computation based on the 559 abstracted domain topology that it already has or it may use 560 the H-PCE procedures (Section 3.1) using the PCReq and PCRep 561 messages to get the end to end path with the help of the Child 562 PCEs (PNC). Either way, the resultant E2E paths may be broken 563 into per-domain paths. 565 * A-B: (A-B13,B13-B31,B31-B) 567 * A-C: (A-B13,B13-B31,B31-B34,B34-B43,B43-C) 569 * Per Domain Path Instantiation: Based on the above path 570 computation, MDSC can issue the path instantiation request to 571 each PNC via PCInitiate message (see 572 [I-D.ietf-pce-stateful-hpce] and 573 [I-D.leedhody-pce-vn-association]). A suitable stitching 574 mechanism would be used to stitch these per domain LSPs. One 575 such mechanism is described in 576 [I-D.dugeon-pce-stateful-interdomain], where PCEP is extended 577 to support stitching in stateful H-PCE context. 579 * Per Domain Path Report: Each PNC should report the status of 580 the per-domain LSP to the MDSC via PCRpt message, as per the 581 Hierarchy of stateful PCE ([I-D.ietf-pce-stateful-hpce]). The 582 status of the end to end LSP (A-B and A-C) is made up when all 583 the per domain LSP are reported up by the PNCs. 585 * Delegation: It is suggested that the per domain LSPs are 586 delegated to respective PNC, so that they can control the path 587 and attributes based on each domain network conditions. 589 * State Synchronization: The state needs to be synchronized 590 between the Parent PCE and Child PCE. The mechanism described 591 in [I-D.litkowski-pce-state-sync] can be used. 593 o VN Modify: MDSC is requested to modify a VN, for example the 594 bandwidth for VN is increased. This may trigger path computation 595 at MDSC as described in the previous step and can trigger an 596 update to existing per-intra-domain path (via PCUpd message) or 597 creation (or deletion) of a per-domain path (via PCInitiate 598 message). As described in [I-D.ietf-pce-stateful-hpce], this 599 should be done in make-before-break fashion. 601 o VN Delete: MDSC is requested to delete a VN, in this case, based 602 on the E2E paths and the resulting per-domain paths need to be 603 removed (via PCInitiate message). 605 o VN Update (based on network changes): Any change in the per-domain 606 LSP is reported to the MDSC (via PCRpt message) as per 607 [I-D.ietf-pce-stateful-hpce]. This may result in changes in the 608 E2E path or VN status. This may also trigger a re-optimization 609 leading to a new per-domain path, update to existing path, or 610 deletion of the path. 612 o VN Protection: The VN protection/restoration requirements, need to 613 be applied to each E2E path as well as each per domain path. The 614 MDSC needs to play a crucial role in coordinating the right 615 protection/restoration policy across each PNC. The existing 616 protection/restoration mechanism of PCEP can be applied on each 617 path. 619 o In case a PNC generates an abstract topology towards the MDSC, the 620 PCInitiate/PCUpd messages from the MDSC to a PNC will contain a 621 path with abstract nodes and links. A PNC would need to take that 622 as an input for path computation to get a path with physical nodes 623 and links. Similarly, a PNC would convert the path received from 624 the device (with physical nodes and links) into an abstract path 625 (based on the abstract topology generated before with abstract 626 nodes and links) and report it to the MDSC. 628 6. IANA Considerations 630 This document makes no requests for IANA action. 632 7. Security Considerations 634 Various security considerations for PCEP are described in [RFC5440], 635 [RFC6952], and [RFC8253]. Further, this document lists various 636 extensions of PCEP that are applicable, each of them specify various 637 security considerations which continue to apply here. 639 The ACTN framework described in [RFC8453] defines key components and 640 interfaces for managed traffic engineered networks. It also lists 641 various security considerations such as request and control of 642 resources, confidentially of the information, and availability of 643 function which should be taken into consideration. 645 As per [RFC8453], securing the request and control of resources, 646 confidentiality of the information, and availability of function 647 should all be critical security considerations when deploying and 648 operating ACTN platforms. From a security and reliability 649 perspective, ACTN may encounter many risks such as malicious attack 650 and rogue elements attempting to connect to various ACTN components 651 (with PCE being one of them). Furthermore, some ACTN components 652 represent a single point of failure and threat vector and must also 653 manage policy conflicts and eavesdropping of communication between 654 different ACTN components. [RFC8453] further states that all 655 protocols used to realize the ACTN framework should have rich 656 security features, and customer, application and network data should 657 be stored in encrypted data stores. 659 When PCEP is used as an ACTN interface, the security of PCEP provided 660 by Transport Layer Security (TLS) [RFC8253], as per the 661 recommendations and best current practices in [RFC7525], is used. 663 As per [RFC8453], regarding the MPI, a PKI- based mechanism is 664 suggested, such as building a TLS or HTTPS connection between the 665 MDSC and PNCs, to ensure trust between the physical network layer 666 control components and the MDSC. Which MDSC the PNC exports topology 667 information to, and the level of detail (full or abstracted), should 668 also be authenticated, and specific access restrictions and topology 669 views should be configurable and/or policy based. When PCEP is used 670 in MPI, the security functions as per [RFC8253] are used to fulfill 671 these requirements. 673 As per [RFC8453], regarding the CMI, suitable authentication and 674 authorization of each CNC connecting to the MDSC will be required. 675 If PCEP is used in CMI, the security functions as per [RFC8253] can 676 be used to support peer authentication, message encryption, and 677 integrity checks. 679 8. Acknowledgments 681 The authors would like to thank Jonathan Hardwick for the inspiration 682 behind this document. Further thanks to Avantika for her comments 683 with suggested text. 685 Thanks to Adrian Farrel and Daniel King for their substantial 686 reviews. 688 Thanks to Yingzhen Qu for RTGDIR reviews. 690 9. References 692 9.1. Normative References 694 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 695 Element (PCE)-Based Architecture", RFC 4655, 696 DOI 10.17487/RFC4655, August 2006, 697 . 699 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 700 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 701 DOI 10.17487/RFC5440, March 2009, 702 . 704 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 705 Path Computation Element Architecture to the Determination 706 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 707 DOI 10.17487/RFC6805, November 2012, 708 . 710 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 711 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 712 DOI 10.17487/RFC8453, August 2018, 713 . 715 9.2. Informative References 717 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 718 (TE) Extensions to OSPF Version 2", RFC 3630, 719 DOI 10.17487/RFC3630, September 2003, 720 . 722 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 723 Support of Generalized Multi-Protocol Label Switching 724 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 725 . 727 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 728 Per-Domain Path Computation Method for Establishing Inter- 729 Domain Traffic Engineering (TE) Label Switched Paths 730 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 731 . 733 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 734 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 735 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 736 DOI 10.17487/RFC5212, July 2008, 737 . 739 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 740 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 741 2008, . 743 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 744 in Support of Generalized Multi-Protocol Label Switching 745 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 746 . 748 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 749 "A Backward-Recursive PCE-Based Computation (BRPC) 750 Procedure to Compute Shortest Constrained Inter-Domain 751 Traffic Engineering Label Switched Paths", RFC 5441, 752 DOI 10.17487/RFC5441, April 2009, 753 . 755 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 756 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 757 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 758 September 2009, . 760 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 761 and A. Bierman, Ed., "Network Configuration Protocol 762 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 763 . 765 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 766 BGP, LDP, PCEP, and MSDP Issues According to the Keying 767 and Authentication for Routing Protocols (KARP) Design 768 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 769 . 771 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 772 Networking: A Perspective from within a Service Provider 773 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 774 . 776 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 777 Computation Element Architecture", RFC 7399, 778 DOI 10.17487/RFC7399, October 2014, 779 . 781 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 782 Application-Based Network Operations", RFC 7491, 783 DOI 10.17487/RFC7491, March 2015, 784 . 786 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 787 "Recommendations for Secure Use of Transport Layer 788 Security (TLS) and Datagram Transport Layer Security 789 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 790 2015, . 792 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 793 S. Ray, "North-Bound Distribution of Link-State and 794 Traffic Engineering (TE) Information Using BGP", RFC 7752, 795 DOI 10.17487/RFC7752, March 2016, 796 . 798 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 799 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 800 . 802 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 803 Stateful Path Computation Element (PCE)", RFC 8051, 804 DOI 10.17487/RFC8051, January 2017, 805 . 807 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 808 Computation Element Communication Protocol (PCEP) 809 Extensions for Stateful PCE", RFC 8231, 810 DOI 10.17487/RFC8231, September 2017, 811 . 813 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 814 "PCEPS: Usage of TLS to Provide a Secure Transport for the 815 Path Computation Element Communication Protocol (PCEP)", 816 RFC 8253, DOI 10.17487/RFC8253, October 2017, 817 . 819 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 820 Computation Element Communication Protocol (PCEP) 821 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 822 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 823 . 825 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 826 Architecture for Use of PCE and the PCE Communication 827 Protocol (PCEP) in a Network with Central Control", 828 RFC 8283, DOI 10.17487/RFC8283, December 2017, 829 . 831 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 832 Yoon, "Information Model for Abstraction and Control of TE 833 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 834 September 2018, . 836 [I-D.ietf-pce-stateful-hpce] 837 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 838 and O. Dios, "Hierarchical Stateful Path Computation 839 Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in 840 progress), October 2018. 842 [I-D.ietf-pce-inter-area-as-applicability] 843 King, D. and H. Zheng, "Applicability of the Path 844 Computation Element to Inter-Area and Inter-AS MPLS and 845 GMPLS Traffic Engineering", draft-ietf-pce-inter-area-as- 846 applicability-07 (work in progress), December 2018. 848 [I-D.dhodylee-pce-pcep-ls] 849 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 850 Distribution of Link-State and TE Information.", draft- 851 dhodylee-pce-pcep-ls-13 (work in progress), February 2019. 853 [I-D.lee-pce-pcep-ls-optical] 854 Lee, Y., Zheng, H., Ceccarelli, D., weiw@bupt.edu.cn, w., 855 Park, P., and B. Yoon, "PCEP Extension for Distribution of 856 Link-State and TE information for Optical Networks", 857 draft-lee-pce-pcep-ls-optical-07 (work in progress), March 858 2019. 860 [I-D.leedhody-pce-vn-association] 861 Lee, Y., Zhang, X., and D. Ceccarelli, "PCEP Extensions 862 for Establishing Relationships Between Sets of LSPs and 863 Virtual Networks", draft-leedhody-pce-vn-association-07 864 (work in progress), February 2019. 866 [I-D.litkowski-pce-state-sync] 867 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 868 Stateful Path Computation Element (PCE) Communication 869 Procedures.", draft-litkowski-pce-state-sync-05 (work in 870 progress), March 2019. 872 [I-D.ietf-pce-association-policy] 873 Litkowski, S., Sivabalan, S., Tantsura, J., Hardwick, J., 874 and M. Negi, "Path Computation Element communication 875 Protocol extension for associating Policies and LSPs", 876 draft-ietf-pce-association-policy-05 (work in progress), 877 February 2019. 879 [I-D.dugeon-pce-stateful-interdomain] 880 Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP 881 Extension for Stateful Inter-Domain Tunnels", draft- 882 dugeon-pce-stateful-interdomain-02 (work in progress), 883 March 2019. 885 [EXP] Casellas, R., Vilalta, R., Martinez, R., Munoz, R., Zheng, 886 H., and Y. Lee, "Experimental Validation of the ACTN 887 architecture for flexi-grid optical networks using Active 888 Stateful Hierarchical PCEs", 19th International Conference 889 on Transparent Optical Networks (ICTON) , July 2017, 890 . 894 Appendix A. Additional Information 896 In the paper [EXP], the application of the ACTN architecture is 897 presented to demonstrate the control of a multi-domain flexi-grid 898 optical network, by proposing, adopting and extending - 900 o the Hierarchical active stateful PCE architectures and protocols 902 o the PCEP protocol to support efficient and incremental link state 903 topological reporting, known as PCEP-LS 905 o the per link partitioning of the optical spectrum based on 906 variable-sized allocated frequency slots enabling network sharing 907 and virtualization 909 o the use of a model-based interface to dynamically request the 910 instantiation of virtual networks for specific clients / tenants. 912 The design and the implementation of the testbed are reported in 913 order to validate the approach. 915 Authors' Addresses 917 Dhruv Dhody 918 Huawei Technologies 919 Divyashree Techno Park, Whitefield 920 Bangalore, Karnataka 560066 921 India 923 EMail: dhruv.ietf@gmail.com 925 Young Lee 926 Huawei Technologies 927 5340 Legacy Drive, Building 3 928 Plano, TX 75023 929 USA 931 EMail: leeyoung@huawei.com 933 Daniele Ceccarelli 934 Ericsson 935 Torshamnsgatan,48 936 Stockholm 937 Sweden 939 EMail: daniele.ceccarelli@ericsson.com