idnits 2.17.1 draft-ietf-pce-applicability-actn-12.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 (May 16, 2019) is 1807 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-07 == 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: November 17, 2019 D. Ceccarelli 6 Ericsson 7 May 16, 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-12 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 November 17, 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 . . . . . . . . . . . . . . . . . 17 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 Network Configuration Protocol (NETCONF) 302 [RFC6241], RESTCONF [RFC8040], or BGP - Link State (BGP-LS) [RFC7752] 303 to get access to the topology and support 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 and [RFC8253]. Security considerations as stated in Section 10.1, 636 Section 10.6, and Section 10.7 of [RFC5440] continue to apply on PCEP 637 when used as ACTN interface. Further, this document lists various 638 extensions of PCEP that are applicable, each of them specify various 639 security considerations which continue to apply here. 641 The ACTN framework described in [RFC8453] defines key components and 642 interfaces for managed traffic engineered networks. It also lists 643 various security considerations such as request and control of 644 resources, confidentially of the information, and availability of 645 function which should be taken into consideration. 647 As per [RFC8453], securing the request and control of resources, 648 confidentiality of the information, and availability of function 649 should all be critical security considerations when deploying and 650 operating ACTN platforms. From a security and reliability 651 perspective, ACTN may encounter many risks such as malicious attack 652 and rogue elements attempting to connect to various ACTN components 653 (with PCE being one of them). Furthermore, some ACTN components 654 represent a single point of failure and threat vector and must also 655 manage policy conflicts and eavesdropping of communication between 656 different ACTN components. [RFC8453] further states that all 657 protocols used to realize the ACTN framework should have rich 658 security features, and customer, application and network data should 659 be stored in encrypted data stores. When PCEP is used as an ACTN 660 interface, the security of PCEP provided by Transport Layer Security 661 (TLS) [RFC8253], as per the recommendations and best current 662 practices in [RFC7525] (unless explicitly set aside in [RFC8253]), is 663 used. 665 As per [RFC8453], regarding the MPI, a PKI- based mechanism is 666 suggested, such as building a TLS or HTTPS connection between the 667 MDSC and PNCs, to ensure trust between the physical network layer 668 control components and the MDSC. Which MDSC the PNC exports topology 669 information to, and the level of detail (full or abstracted), should 670 also be authenticated, and specific access restrictions and topology 671 views should be configurable and/or policy based. When PCEP is used 672 in MPI, the security functions as per [RFC8253] are used to fulfill 673 these requirements. 675 As per [RFC8453], regarding the CMI, suitable authentication and 676 authorization of each CNC connecting to the MDSC will be required. 677 If PCEP is used in CMI, the security functions as per [RFC8253] can 678 be used to support peer authentication, message encryption, and 679 integrity checks. 681 8. Acknowledgments 683 The authors would like to thank Jonathan Hardwick for the inspiration 684 behind this document. Further thanks to Avantika for her comments 685 with suggested text. 687 Thanks to Adrian Farrel and Daniel King for their substantial 688 reviews. 690 Thanks to Yingzhen Qu for RTGDIR review. 692 Thanks to Rifaat Shekh-Yusef for SECDIR review. 694 Thanks to Meral Shirazipour for GENART review. 696 Thanks to Roman Danyliw and Barry Leiba for IESG review comments. 698 Thanks to Deborah Brungard for being the responsible AD. 700 9. References 702 9.1. Normative References 704 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 705 Element (PCE)-Based Architecture", RFC 4655, 706 DOI 10.17487/RFC4655, August 2006, 707 . 709 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 710 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 711 DOI 10.17487/RFC5440, March 2009, 712 . 714 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 715 Path Computation Element Architecture to the Determination 716 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 717 DOI 10.17487/RFC6805, November 2012, 718 . 720 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 721 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 722 DOI 10.17487/RFC8453, August 2018, 723 . 725 9.2. Informative References 727 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 728 (TE) Extensions to OSPF Version 2", RFC 3630, 729 DOI 10.17487/RFC3630, September 2003, 730 . 732 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 733 Support of Generalized Multi-Protocol Label Switching 734 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 735 . 737 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 738 Per-Domain Path Computation Method for Establishing Inter- 739 Domain Traffic Engineering (TE) Label Switched Paths 740 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 741 . 743 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 744 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 745 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 746 DOI 10.17487/RFC5212, July 2008, 747 . 749 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 750 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 751 2008, . 753 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 754 in Support of Generalized Multi-Protocol Label Switching 755 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 756 . 758 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 759 "A Backward-Recursive PCE-Based Computation (BRPC) 760 Procedure to Compute Shortest Constrained Inter-Domain 761 Traffic Engineering Label Switched Paths", RFC 5441, 762 DOI 10.17487/RFC5441, April 2009, 763 . 765 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 766 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 767 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 768 September 2009, . 770 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 771 and A. Bierman, Ed., "Network Configuration Protocol 772 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 773 . 775 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 776 Networking: A Perspective from within a Service Provider 777 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 778 . 780 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 781 Computation Element Architecture", RFC 7399, 782 DOI 10.17487/RFC7399, October 2014, 783 . 785 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 786 Application-Based Network Operations", RFC 7491, 787 DOI 10.17487/RFC7491, March 2015, 788 . 790 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 791 "Recommendations for Secure Use of Transport Layer 792 Security (TLS) and Datagram Transport Layer Security 793 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 794 2015, . 796 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 797 S. Ray, "North-Bound Distribution of Link-State and 798 Traffic Engineering (TE) Information Using BGP", RFC 7752, 799 DOI 10.17487/RFC7752, March 2016, 800 . 802 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 803 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 804 . 806 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 807 Stateful Path Computation Element (PCE)", RFC 8051, 808 DOI 10.17487/RFC8051, January 2017, 809 . 811 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 812 Computation Element Communication Protocol (PCEP) 813 Extensions for Stateful PCE", RFC 8231, 814 DOI 10.17487/RFC8231, September 2017, 815 . 817 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 818 "PCEPS: Usage of TLS to Provide a Secure Transport for the 819 Path Computation Element Communication Protocol (PCEP)", 820 RFC 8253, DOI 10.17487/RFC8253, October 2017, 821 . 823 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 824 Computation Element Communication Protocol (PCEP) 825 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 826 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 827 . 829 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 830 Architecture for Use of PCE and the PCE Communication 831 Protocol (PCEP) in a Network with Central Control", 832 RFC 8283, DOI 10.17487/RFC8283, December 2017, 833 . 835 [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 836 Yoon, "Information Model for Abstraction and Control of TE 837 Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, 838 September 2018, . 840 [I-D.ietf-pce-stateful-hpce] 841 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 842 and O. Dios, "Hierarchical Stateful Path Computation 843 Element (PCE).", draft-ietf-pce-stateful-hpce-07 (work in 844 progress), April 2019. 846 [I-D.ietf-pce-inter-area-as-applicability] 847 King, D. and H. Zheng, "Applicability of the Path 848 Computation Element to Inter-Area and Inter-AS MPLS and 849 GMPLS Traffic Engineering", draft-ietf-pce-inter-area-as- 850 applicability-07 (work in progress), December 2018. 852 [I-D.dhodylee-pce-pcep-ls] 853 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 854 Distribution of Link-State and TE Information.", draft- 855 dhodylee-pce-pcep-ls-13 (work in progress), February 2019. 857 [I-D.lee-pce-pcep-ls-optical] 858 Lee, Y., Zheng, H., Ceccarelli, D., weiw@bupt.edu.cn, w., 859 Park, P., and B. Yoon, "PCEP Extension for Distribution of 860 Link-State and TE information for Optical Networks", 861 draft-lee-pce-pcep-ls-optical-07 (work in progress), March 862 2019. 864 [I-D.leedhody-pce-vn-association] 865 Lee, Y., Zhang, X., and D. Ceccarelli, "PCEP Extensions 866 for Establishing Relationships Between Sets of LSPs and 867 Virtual Networks", draft-leedhody-pce-vn-association-07 868 (work in progress), February 2019. 870 [I-D.litkowski-pce-state-sync] 871 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 872 Stateful Path Computation Element (PCE) Communication 873 Procedures.", draft-litkowski-pce-state-sync-05 (work in 874 progress), March 2019. 876 [I-D.ietf-pce-association-policy] 877 Litkowski, S., Sivabalan, S., Tantsura, J., Hardwick, J., 878 and M. Negi, "Path Computation Element communication 879 Protocol extension for associating Policies and LSPs", 880 draft-ietf-pce-association-policy-05 (work in progress), 881 February 2019. 883 [I-D.dugeon-pce-stateful-interdomain] 884 Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP 885 Extension for Stateful Inter-Domain Tunnels", draft- 886 dugeon-pce-stateful-interdomain-02 (work in progress), 887 March 2019. 889 [EXP] Casellas, R., Vilalta, R., Martinez, R., Munoz, R., Zheng, 890 H., and Y. Lee, "Experimental Validation of the ACTN 891 architecture for flexi-grid optical networks using Active 892 Stateful Hierarchical PCEs", 19th International Conference 893 on Transparent Optical Networks (ICTON) , July 2017, 894 . 898 Appendix A. Additional Information 900 In the paper [EXP], the application of the ACTN architecture is 901 presented to demonstrate the control of a multi-domain flexi-grid 902 optical network, by proposing, adopting and extending - 904 o the Hierarchical active stateful PCE architectures and protocols 906 o the PCEP protocol to support efficient and incremental link state 907 topological reporting, known as PCEP-LS 909 o the per link partitioning of the optical spectrum based on 910 variable-sized allocated frequency slots enabling network sharing 911 and virtualization 913 o the use of a model-based interface to dynamically request the 914 instantiation of virtual networks for specific clients / tenants. 916 The design and the implementation of the testbed are reported in 917 order to validate the approach. 919 Authors' Addresses 921 Dhruv Dhody 922 Huawei Technologies 923 Divyashree Techno Park, Whitefield 924 Bangalore, Karnataka 560066 925 India 927 EMail: dhruv.ietf@gmail.com 929 Young Lee 930 Huawei Technologies 931 5340 Legacy Drive, Building 3 932 Plano, TX 75023 933 USA 935 EMail: leeyoung@huawei.com 937 Daniele Ceccarelli 938 Ericsson 939 Torshamnsgatan,48 940 Stockholm 941 Sweden 943 EMail: daniele.ceccarelli@ericsson.com