idnits 2.17.1 draft-ietf-teas-pce-central-control-05.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 (September 4, 2017) is 2426 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-10 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-16 == Outdated reference: A later version (-17) exists of draft-ietf-pce-wson-rwa-ext-06 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-12 == Outdated reference: A later version (-08) exists of draft-zhao-pce-pcep-extension-for-pce-controller-05 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group A. Farrel, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Informational Q. Zhao, Ed. 5 Expires: March 8, 2018 R. Li 6 Huawei Technologies 7 C. Zhou 8 Cisco Systems 9 September 4, 2017 11 An Architecture for Use of PCE and PCEP in a Network with Central 12 Control 13 draft-ietf-teas-pce-central-control-05 15 Abstract 17 The Path Computation Element (PCE) is a core component of Software 18 Defined Networking (SDN) systems. It can compute optimal paths for 19 traffic across a network and can also update the paths to reflect 20 changes in the network or traffic demands. 22 PCE was developed to derive paths for MPLS Label Switched Paths 23 (LSPs) supplying them to the head end of the LSP using the Path 24 Computation Element Communication Protocol (PCEP). 26 SDN has a broader applicability than signaled MPLS traffic engineered 27 networks, and the PCE may be used to determine paths in a range of 28 use cases including static LSPs, segment routing, service function 29 chaining, and most forms of routed or switched network. It is, 30 therefore, reasonable to consider PCEP as a control protocol for use 31 in these environments to allow the PCE to be fully enabled as a 32 central controller. 34 This document briefly introduces the architecture for PCE as a 35 central controller, examines the motivations and applicability for 36 PCEP as a control protocol in this environment, and introduces the 37 implications for the protocol. A PCE-based central controller can 38 simplify the processing of distributed control plane by blending it 39 with elements of SDN and without necessarily completely replacing it. 41 This document does not describe use cases in detail and does not 42 define protocol extensions: that work is left for other documents. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on March 8, 2018. 61 Copyright Notice 63 Copyright (c) 2017 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 7 81 2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 8 82 2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 9 83 2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 12 84 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 85 3.1. Technology-Oriented Applicability . . . . . . . . . . . . 14 86 3.1.1. Applicability to Control Plane Operated Networks . . 14 87 3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 14 88 3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 15 89 3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 15 90 3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 15 91 3.1.6. Service Function Chaining . . . . . . . . . . . . . . 16 92 3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16 93 3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16 94 3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17 95 3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17 96 4. Protocol Implications / Guidance for Solution Developers . . 18 97 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 98 6. Manageability Considerations . . . . . . . . . . . . . . . . 19 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 100 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 104 10.2. Informative References . . . . . . . . . . . . . . . . . 22 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 107 1. Introduction 109 The Path Computation Element (PCE) [RFC4655] was developed to offload 110 path computation function from routers in an MPLS traffic engineered 111 network. Since then, the role and function of the PCE has grown to 112 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 113 delegated control [I-D.ietf-pce-stateful-pce] and PCE-initiated use 114 of network resources [I-D.ietf-pce-pce-initiated-lsp]. 116 According to [RFC7399], Software Defined Networking (SDN) refers to a 117 separation between the control elements and the forwarding components 118 so that software running in a centralized system, called a 119 controller, can act to program the devices in the network to behave 120 in specific ways. A required element in an SDN architecture is a 121 component that plans how the network resources will be used and how 122 the devices will be programmed. It is possible to view this 123 component as performing specific computations to place traffic flows 124 within the network given knowledge of the availability of network 125 resources, how other forwarding devices are programmed, and the way 126 that other flows are routed. This is the function and purpose of a 127 PCE, and the way that a PCE integrates into a wider network control 128 system (including an SDN system) is presented in [RFC7491]. 130 In early PCE implementations, where the PCE was used to derive paths 131 for MPLS Label Switched Paths (LSPs), paths were requested by network 132 elements (known as Path Computation Clients - PCCs) and the results 133 of the path computations were supplied to network elements using the 134 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 135 This protocol was later extended to allow a PCE to send unsolicited 136 requests to the network for LSP establishment 137 [I-D.ietf-pce-pce-initiated-lsp]. 139 SDN has a far broader applicability than just signaled MPLS or GMPLS 140 traffic engineered networks. The PCE component in an SDN system may 141 be used to determine paths in a wide range of use cases including 142 static LSPs, segment routing [I-D.ietf-spring-segment-routing], 143 service function chaining (SFC) [RFC7665], and indeed any form of 144 routed or switched network. It is, therefore, reasonable to consider 145 PCEP as a general southbound control protocol (i.e., a control 146 protocol for communicating from the central controller to network 147 elements) for use in these environments to allow the PCE to be fully 148 enabled as a central controller. 150 This document introduces the architecture for PCE as a central 151 controller as an extension of the architecture described in [RFC4655] 152 and assumes the continued use of PCEP as the protocol used between 153 PCE and PCC. The document also examines the motivations and 154 applicability for PCEP as a southbound interface and introduces the 155 implications for the protocol used in this way. A PCE-based central 156 controller can simplify the processing of distributed control plane 157 by blending it with elements of SDN and without necessarily 158 completely replacing it. 160 This document does not describe use cases in detail and does not 161 define protocol extensions: that work is left for other documents. 163 2. Architecture 165 The architecture for the use of PCE within centralized control of a 166 network is based on the understanding that a PCE can determine how 167 connections should be placed and how resources should be used within 168 the network, and that the PCE can then cause those connections to be 169 established. Figure 1 shows how this control relationship works in a 170 network with an active control plane. This is a familiar view for 171 those who have read and understood [RFC4655] and 172 [I-D.ietf-pce-pce-initiated-lsp]. 174 In this mode of operation, the central controller is asked to create 175 connectivity by a network orchestrator, a service manager, an 176 Operations Support System (OSS), a Network Management Station (NMS), 177 or some other application. The PCE-based controller computes paths 178 with awareness of the network topology, the available resources, and 179 the other services supported in the network. This information is 180 held in the Traffic Engineering Database (TED) and other databases 181 available to the PCE. Then the PCE sends a request using PCEP to one 182 of the Network Elements (NEs), and that NE uses a control plane to 183 establish the requested connections and reserve the network 184 resources. 186 Note that other databases (such as a database of LSPs - the LSP-DB) 187 might also be used, but for simplicity of illustration, just the TED 188 is shown. 190 -------------------------------------------- 191 | Orchestrator / Service Manager / OSS / NMS | 192 -------------------------------------------- 193 ^ 194 | 195 v 196 ------------ 197 | | ----- 198 | PCE-based |<---| TED | 199 | Controller | ----- 200 | | 201 ------------ 202 ^ 203 PCEP| 204 v 205 ---- ---- ---- ---- 206 | NE |<--------->| NE |<--->| NE |<--->| NE | 207 ---- Signaling ---- ---- ---- 208 Protocol 210 Figure 1: Architecture for Central Controller with Control Plane 212 Although the architecture shown in Figure 1 represents a form of SDN, 213 one objective of SDN in some environments is to remove the dependency 214 on a control plane. A transition architecture toward this goal is 215 presented in [RFC7491] and is shown in Figure 2. In this case, 216 services are still requested in the same way, and the PCE-based 217 controller still requests use of the network using PCEP. The main 218 difference is that the consumer of the PCEP messages is a Network 219 Controller that provisions the resources and instructs the data plane 220 using a Southbound Interface (SBI) that provides an interface to each 221 NE. 223 -------------------------------------------- 224 | Orchestrator / Service Manager / OSS / NMS | 225 -------------------------------------------- 226 ^ 227 | 228 v 229 ------------ 230 | | ----- 231 | PCE-based |<---| TED | 232 | Controller | ----- 233 | | 234 ------------ 235 ^ 236 | PCEP 237 v 238 ------------ 239 | Network | 240 | Controller | 241 /------------\ 242 SBI / ^ ^ \ 243 / | | \ 244 / v v \ 245 ----/ ---- ---- \---- 246 | NE | | NE | | NE | | NE | 247 ---- ---- ---- ---- 249 Figure 2: Architecture Including a Network Controller 251 The approach in Figure 2 delivers the SDN functionality but is overly 252 complicated and insufficiently flexible. 254 o The complication is created by the use of two controllers in a 255 hierarchical organization, and the resultant use of two protocols 256 in a southbound direction. 258 o The lack of flexibility arises from the assumed or required lack 259 of a control plane. 261 This document describes an architecture that reduces the number of 262 components and is flexible to a number of deployment models and use 263 cases. In this hybrid approach (shown in Figure 3) the network 264 controller is PCE-enabled and can also speak PCEP as the SBI (i.e., 265 it can communicate with each node along the path using PCEP). That 266 means that the controller can communicate with a conventional control 267 plane-enabled NE using PCEP and can also use the same protocol to 268 program individual NEs. In this way the PCE-based controller can 269 control a wider range of networks and deliver many different 270 functions as described in Section 3. 272 There will be a trade-off in different application scenarios. In 273 some cases the use of a control plane will simplify deployment (for 274 example, by distributing recovery actions), and in other cases a 275 control plane may add operational complexity. 277 PCEP is essentially already capable of acting as an SBI and only 278 small, use case specific modifications to the protocol are needed to 279 support this architecture. The implications for the protocol are 280 discussed further in Section 4. 282 -------------------------------------------- 283 | Orchestrator / Service Manager / OSS / NMS | 284 -------------------------------------------- 285 ^ 286 | 287 v 288 ------------ 289 | | ----- 290 | PCE-based |<---| TED | 291 | Controller | ----- 292 | | 293 /------------\ 294 PCEP / ^ ^ \ 295 / | | \ 296 / v v \ 297 / ---- ---- \ 298 / | NE | | NE | \ 299 ----/ ---- ---- \---- 300 | NE | | NE | 301 ---- ---- 302 ^ ---- ---- ^ 303 :......>| NE |...| NE |<....: 304 Signaling Protocol ---- ---- 306 Figure 3: Architecture for Node-by-Node Central Control 308 2.1. Resilience and Scaling 310 Systems with central controllers are vulnerable to two problems: 311 failure of the controller or overload of the controller. These 312 concerns are not unique to the use of a PCE-based controller, but 313 need to be addressed in this document before the PCE-based controller 314 architecture can be considered for use in all but the smallest 315 networks. 317 There are three architectural mechanisms that can be applied to 318 address these issues. The mechanisms are described separately for 319 clarity, but a deployment use may any combination of the approaches. 321 For simplicity of illustration, these three approaches are shown in 322 the sections that follow without a control plane. However, the 323 general, hybrid approach of Figure 3 is applicable in each case. 325 2.1.1. Partitioned Network 327 The first and simplest approach to handling controller overload or 328 scalability is to use multiple controllers, each responsible for a 329 part of the network. We can call the resultant areas of control 330 "domains" [RFC4655]. 332 This approach is shown in Figure 4. It can clearly address some of 333 the scaling and overload concerns since each controller now only has 334 responsibility for a subset of the network elements. But this comes 335 at a cost because end-to-end connections require coordination between 336 the controllers. Furthermore, this technique does not remove the 337 single-point-of-failure concern even if it does reduce the impact on 338 the network of the failure of a single controller. 340 Note that PCEP is designed to work as a PCE-to-PCE protocol as well 341 as a PCE-to-PCC protocol, so it should be possible to use it to 342 coordinate between PCE-based controllers in this model. 344 -------------------------------------------- 345 | Orchestrator / Service Manager / OSS / NMS | 346 -------------------------------------------- 347 ^ ^ 348 | | 349 v v 350 ------------ Coord- ------------ 351 ----- | | ination | | ----- 352 | TED |--->| PCE-based |<-------->| PCE-based |<---| TED | 353 ----- | Controller | | Controller | ----- 354 | | :: | | 355 /------------ :: ------------\ 356 / ^ ^ :: ^ ^ \ 357 / | | :: | | \ 358 | | | :: | | | 359 v v v :: v v v 360 ---- ---- ---- :: ---- ---- ---- 361 | NE | | NE | | NE | :: | NE | | NE | | NE | 362 ---- ---- ---- :: ---- ---- ---- 363 :: 364 Domain 1 :: Domain 2 365 :: 367 Figure 4: Multiple Controllers on a Partitioned Network 369 2.1.2. Multiple Parallel Controllers 371 Multiple controllers may be deployed where each controller is capable 372 of controlling all of the network elements. Thus the failure of any 373 one controller will not leave the network unmanageable and, in normal 374 circumstances, the load can be distributed across the controllers. 376 Multiple parallel controllers may be deployed as shown in Figure 5. 377 Each controller is capable of controlling all of the network elements 378 thus the failure of any one controller will not leave the network 379 unmanageable and, in normal circumstances, the load can be 380 distributed across the controllers. In this model, the orchestrator 381 (or any requester) must select a controller to consume its request. 383 -------------------------------------------- 384 | Orchestrator / Service Manager / OSS / NMS | 385 -------------------------------------------- 386 ^ ^ 387 | ___________________ | 388 | | Synchronization | | 389 v v v v 390 ------------ ------------ 391 | | ----- | | 392 | PCE-based |<---| TED |--->| PCE-based | 393 | Controller | ----- | Controller | 394 | |__ ...........| | 395 ------------\ \_:__ :------------ 396 ^ ^ \___: \ .....: ^ ^ 397 | | .....:\ \_:___ ..: : 398 | |__:___ \___:_ \_:___ : 399 | ....: | .....: | ..: | : 400 | : | : | : | : 401 v v v v v v v v 402 ---- ---- ---- ---- 403 | NE | | NE | | NE | | NE | 404 ---- ---- ---- ---- 406 Figure 5: Multiple Redundant Controllers 408 An alternate approach is to present the controllers as a "cluster" 409 that represents itself externally as a single controller as in 410 Figure 3 but which is actually comprised of multiple controllers. 411 The size of the cluster may be varied according to load in the manner 412 of network functions virtualization (NFV) and the cluster is 413 responsible for sharing load among the members of the cluster. This 414 approach is shown in Figure 6. 416 -------------------------------------------- 417 | Orchestrator / Service Manager / OSS / NMS | 418 -------------------------------------------- 419 ^ 420 | 421 --------------------------+------------------------- 422 | Controller ______________|_____________ | 423 | Cluster | | | 424 | | ___________________ | | 425 | | | Synchronization | | | 426 | v v v v | 427 | ------------ ----- ------------ | 428 | | PCE-based |<---| TED |--->| PCE-based | | 429 | | Controller | ----- | Controller | | 430 | | Instance | | Instance | | 431 | ------------ ------------ | 432 | ^ ^ | 433 | |____________________________| | 434 | | | 435 --------------------------+------------------------- 436 _____________|_____________ 437 | | | | 438 v v v v 439 ---- ---- ---- ---- 440 | NE | | NE | | NE | | NE | 441 ---- ---- ---- ---- 443 Figure 6: Multiple Controllers Presented as a Cluster 445 To achieve full redundancy and to be able to continue to provide full 446 function in the event of the failure a controller, the controllers 447 must synchronize with each other. This is nominally a simple task if 448 there are just two controllers, but can actually be quite complex if 449 state changes in the network are not to be lost. Furthermore, if 450 there are more than two controllers, the synchronization between 451 controllers can become a hard problem. 453 Synchronization issues are often off-loaded as "database 454 synchronization" problems because distributed database packages have 455 already had to address these challenges, or by using a shared 456 database. In networking the problem may also be addressed by 457 collecting the state from the network (effectively using the network 458 as a database) using normal routing protocols such as OSPF, IS-IS, 459 and BGP. It should be noted that addressing the synchronization 460 problem through a shared database may be hiding the issues of 461 congestion and of a single point of failure: whole the controllers 462 may have been made resilient by allowing redundancy, the shared 463 database is still a problem and so the whole system is still 464 vulnerable. 466 2.1.3. Hierarchical Controllers 468 Figure 7 shows an approach with hierarchical controllers. This 469 approach was developed for PCEs in [RFC6805] and appears in various 470 SDN architectures where a "parent PCE", an "orchestrator", or "super 471 controller" takes responsibility for a high-level view of the network 472 before distributing tasks to lower level PCEs or controllers. 474 On its own, this approach does little to protect against the failure 475 of a controller, but it can make significant improvements in loading 476 and scaling of the individual controllers. It also offers a good way 477 to support end-to-end connectivity across multiple administrative or 478 technology-specific domains. 480 Note that this model can be arbitrarily recursive with a PCE-based 481 controller being the child of one parent PCE-based controller while 482 acting as the parent of another set of PCE-based controllers. 484 -------------------------------------------- 485 | Orchestrator / Service Manager / OSS / NMS | 486 -------------------------------------------- 487 ^ 488 | 489 v 490 ------------ 491 | Parent | ----- 492 | PCE-based |<---| TED | 493 | Controller | ----- 494 | | 495 ------------ 496 ^ ^ 497 | | 498 v :: v 499 ------------ :: ------------ 500 ----- | | :: | | ----- 501 | TED |--->| PCE-based | :: | PCE-based |<---| TED | 502 ----- | Controller | :: | Controller | ----- 503 /| | :: | |\ 504 / ------------ :: ------------ \ 505 / ^ ^ :: ^ ^ \ 506 / | | :: | | \ 507 / | | :: | | \ 508 | | | :: | | | 509 v v v :: v v v 510 ---- ---- ---- :: ---- ---- ---- 511 | NE | | NE | | NE | :: | NE | | NE | | NE | 512 ---- ---- ---- :: ---- ---- ---- 513 :: 514 Domain 1 :: Domain 2 515 :: 517 Figure 7: Hierarchical Controllers 519 3. Applicability 521 This section gives a very high-level introduction to the 522 applicability of a PCE-based centralized controller. There is no 523 attempt to explain each use case in detail, and the inclusion of a 524 use case is not intended to suggest that deploying a PCE-based 525 controller is a mandatory or recommended approach. The sections 526 below are provided as a stimulus to discussion of the applicability 527 of a PCE-based controller and it is expected that separate documents 528 will be written to develop the use cases in which there is interest 529 for implementation and deployment. As described in Section 4 530 specific enhancements to PCEP may be needed for some of these use 531 cases and it is expected that the documents that develop each use 532 case will also address any extensions to PCEP. 534 The rest of this section is divided into two sub-sections. The first 535 approaches the question of applicability from a consideration of the 536 network technology. The second looks at the high-level functions 537 that can be delivered by using a PCE-based controller. 539 As previously mentioned, this section is intended to just make 540 suggestions. Thus the material supplied is very brief. The omission 541 of a use case is in no way meant to imply some limit on the 542 applicability of PCE-based control. 544 3.1. Technology-Oriented Applicability 546 This section provides a list of use cases based on network 547 technology. 549 3.1.1. Applicability to Control Plane Operated Networks 551 This mode of operation is the common approach for an active, stateful 552 PCE to control a traffic engineered MPLS or GMPLS network 553 [I-D.ietf-pce-stateful-pce]. Note that the PCE-based controller 554 determines what LSPs are needed and where to place them. PCEP is 555 used to instruct the head end of each LSP, and the head end signals 556 in the control plane to set up the LSP. 558 In this mode of operation, the PCE may construct its TED in a number 559 of ways as described in [RFC4655] including (but not limited to) 560 participating in the IGP or receiving information from a network 561 element via BGP-LS [RFC7752]. 563 3.1.2. Static LSPs in MPLS 565 Static LSPs are provisioned without the use of a control plane. This 566 means that they are established using management plane or "manual" 567 configuration. 569 Static LSPs can be provisioned as explicit label instructions at each 570 hop on the end-to-end path LSP. Each router along the path must be 571 told what label forwarding instructions to program and what resources 572 to reserve. The PCE-based controller keeps a view of the network and 573 determines the paths of the end-to-end LSPs just as it does for the 574 use case described in Section 3.1.1, but the controller uses PCEP to 575 communicate with each router along the path of the end-to-end LSP. 576 In this case the PCE-based controller will take responsibility for 577 managing some part of the MPLS label space for each of the routers 578 that it controls, and may taker wider responsibility for partitioning 579 the label space for each router and allocating different parts for 580 different uses communicating the ranges to the router using PCEP. 582 3.1.3. MPLS Multicast 584 Multicast LSPs may be provisioned with a control plane or as static 585 LSPs. No extra considerations apply above those in Section 3.1.1 and 586 Section 3.1.2 except, of course, to note that the PCE must also 587 include the instructions about where the LSP branches, i.e., where 588 packets must be copied. 590 3.1.4. Transport SDN 592 Transport SDN (T-SDN) is the application of SDN techniques to 593 transport networks. In this respect a transport network is a network 594 built from any technology below the IP layer and designed to carry 595 traffic transparently in a connection-oriented way. Thus, an MPLS 596 traffic engineering network is a transport network although it is 597 more common to consider technologies such as Time Division 598 Multiplexing (TDM) and Optical Transport Networks (OTN). 600 Transport networks may be operated with or without a control plane 601 and may have point-to-point or point-to-multipoint connections. 602 Thus, all of the considerations in Section 3.1.1, Section 3.1.2, and 603 Section 3.1.3 apply so that the normal PCEP message allow a PCE-based 604 central controller to provision a transport network. It is usually 605 the case that additional technology-specific parameters are needed to 606 configure the NEs or LSPs in transport networks: parameters such as 607 optical characteristic. Such parameters will need to be carried in 608 the PCEP messages: new protocol extensions may be needed, as 609 described, for example,in [I-D.ietf-pce-wson-rwa-ext]. 611 3.1.5. Segment Routing 613 Segment routing is described in [I-D.ietf-spring-segment-routing]. 614 It relies on a series of forwarding instructions being placed in the 615 header of a packet. At each hop in the network a router looks at the 616 first instruction and may: continue to forward the packet unchanged; 617 strip the top instruction and forward the packet; or strip the top 618 instruction, insert some additional instructions, and forward the 619 packet. 621 The segment routing architecture supports operations that can be used 622 to steer packet flows in a network thus providing a form of traffic 623 engineering. A PCE-based controller can be responsible for computing 624 the paths for packet flows in a segment routing network, for 625 configuring the forwarding actions on the routers, and for telling 626 the edge routers what instructions to attach to packets as they enter 627 the network. These last two operations can be achieved using PCEP 628 and the PCE-based controller will assume responsibility for managing 629 the space of labels or path identifiers used to determine how packets 630 are forwarded. 632 3.1.6. Service Function Chaining 634 Service Function Chaining (SFC) is described in [RFC7665]. It is the 635 process of directing traffic in a network such that it passes through 636 specific hardware devices or virtual machines (known as service 637 function nodes) that can perform particular desired functions on the 638 traffic. The set of functions to be performed and the order in which 639 they are to be performed is known as a Service Function Chain. The 640 chain is enhanced with the locations at which the service functions 641 are to be performed to derive a Service Function Path (SFP). Each 642 packet is marked as belonging to a specific SFP and that marking lets 643 each successive service function node know which functions to perform 644 and to which service function node to send the packet next. 646 To operate an SFC network the service function nodes must be 647 configured to understand the packet markings and the edge nodes must 648 be told how to mark packets entering the network. Additionally it 649 may be necessary to establish tunnels between service function nodes 650 to carry the traffic. 652 Planning an SFC network requires load balancing between service 653 function nodes and traffic engineering across the network that 654 connects them. These are operations that can be performed by a PCE- 655 based controller, and that controller can use PCEP to program the 656 network and install the service function chains and any required 657 tunnels. 659 3.2. High-Level Applicability 661 This section provides a list of the high-level functions that can be 662 delivered by using a PCE-based controller. 664 3.2.1. Traffic Engineering 666 According to [RFC2702], Traffic Engineering (TE) is concerned with 667 performance optimization of operational networks. In general, it 668 encompasses the application of technology and scientific principles 669 to the measurement, modeling, characterization, control of Internet 670 traffic, and the application of such knowledge and techniques to 671 achieve specific performance objectives. 673 From a practical point of view this involves having an understanding 674 of the topology of the network, the characteristics of the nodes and 675 links in the network, and the traffic demands and flows across the 676 network. It also requires that actions can be taken to ensure that 677 traffic follows specific paths through the network. 679 PCE was specifically developed to address TE in an MPLS network, and 680 so a PCE-based controller is well suited to analyze TE problems and 681 supply answers that can be installed in the network using PCEP. PCEP 682 can be responsible for initiating paths across the network through a 683 control plane, or for installing state in the network node by node 684 such as in a Segment Routed network (see Section 3.1.5) or by 685 configuring IGP metrics. 687 3.2.2. Traffic Classification 689 Traffic classification is an important part of traffic engineering. 690 It is the process of looking at a packet to determine how it should 691 be treated as it is forwarded through the network. It applies in 692 many scenarios including MPLS traffic engineering (where it 693 determines what traffic is forwarded onto which LSPs), segment 694 routing (where it is used to select which set of forwarding 695 instructions to add to a packet), and service function chaining 696 (where it indicates along which service function path a packet should 697 be forwarded). In conjunction with traffic engineering, traffic 698 classification is an important enabler for load balancing. 700 Traffic classification is closely linked to the computational 701 elements of planning for the network functions just listed because it 702 determines how traffic load is balanced and distributed through the 703 network. Therefore, selecting what traffic classification should be 704 performed by a router is an important part of the work done by a PCE- 705 based controller. 707 Instructions can be passed from the controller to the routers using 708 PCEP. These instructions tell the routers how to map traffic to 709 paths or connections. 711 3.2.3. Service Delivery 713 Various network services may be offered over a network. These 714 include protection services (including end-to-end protection 715 [RFC4427], restoration after failure, and fast reroute [RFC4090]), 716 Virtual Private Network (VPN) service (such as Layer 3 VPNs [RFC4364] 717 or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. 719 Delivering services over a network in an optimal way requires 720 coordination in the way that network resources are allocated to 721 support the services. A PCE-based central controller can consider 722 the whole network and all components of a service at once when 723 planning how to deliver the service. It can then use PCEP to manage 724 the network resources and to install the necessary associations 725 between those resources. 727 4. Protocol Implications / Guidance for Solution Developers 729 PCEP is a push-pull protocol that is designed to move requests and 730 responses between a server (the PCE) and clients (the PCCs, i.e., the 731 network elements). In particular, it has a message (PCInitiate 732 [I-D.ietf-pce-pce-initiated-lsp]) that can be sent by the PCE to 733 install state or cause actions at the PCC, and a response message 734 (PCRpt) that is used to confirm the request. 736 As such, there is an expectation that only relatively minor changes 737 to PCEP are required to support the concept of a PCE-based 738 controller. The only work expected to be needed is extensions to 739 existing PCEP messages to carry additional or specific information 740 elements for the individual use cases, which maintain backward 741 compatibility and do not impact existing PCEP deployments. [RFC5440] 742 already describes how legacy implementations handle unknown protocol 743 extensions and how to use the PCEP Open message to indicate support 744 for PCEP features. Where possible, consistent with the general 745 principles of how protocols are extended, any additions to the 746 protocol should be made in a generic way such that they are open to 747 use in a range of applications. 749 It is anticipated that new documents (such as 750 [I-D.zhao-pce-pcep-extension-for-pce-controller]) will be produced 751 for each use case dependent on support and demand. Such documents 752 will explain the use case and define the necessary protocol 753 extensions. 755 Protocol extensions could have impact on existing PCEP deployments 756 and the interoperability between different implementations. It is 757 anticipated that changes of the PCEP protocol or addition of 758 information elements could require additional testing to ensure 759 interoperability between different PCEP implementations. 761 It is reasonable to expect that implementations are able to select a 762 subset or profile of the protocol extensions and PCEP features that 763 are relevant for the application scenario in which they will be 764 deployed. Identification of these profiles should form part of the 765 protocol itself so that interoperability can be easily determined and 766 so that testing can be limited to the specific profiles. 768 Note that protocol mechanisms to handle synchronization of state in 769 parallel PCE-based controllers will also be required if parallel 770 controllers are used as described in Section 2.1.2. There is a 771 discussion of mechanisms to achieve PCE state synchronization in 772 [I-D.ietf-pce-stateful-pce]. 774 5. Security Considerations 776 Security considerations for a PCE-based controller are little 777 different from those for any other PCE system. That is, the 778 operation relies heavily on the use and security of PCEP and so 779 consideration should be given to the security features discussed in 780 [RFC5440] and the additional mechanisms described in 781 [I-D.ietf-pce-pceps]. 783 It should be observed that the trust model of a network that operates 784 without a control plane is different from one with a control plane. 785 The conventional "chain of trust" used with a control plane is 786 replaced by individual trust relationships between the controller and 787 each individual NE. This model may be considerably easier to manage 788 and so is more likely to be operated with a high level of security. 790 However, an architecture with a central controller has a central 791 point of failure and this is also a security weakness since the 792 network can be vulnerable to denial of service attacks on the 793 controller. Similarly, the central controller provides a focus for 794 interception and modification of messages sent to individual NEs. In 795 short, while the interactions with a PCE-based controller are not 796 substantially different to those in any other SDN architecture, the 797 security implications of SDN have not been fully discussed or 798 described. Therefore, protocol and applicability work around 799 solutions for this architecture must take proper account of these 800 concerns. 802 It is expected that each new document that is produced for a specific 803 use case will also include considerations of the security impacts of 804 the use of a PCE-based central controller on the network type and 805 services being managed. 807 6. Manageability Considerations 809 The architecture described in this document is a management 810 architecture: the PCE-based controller is a management component that 811 controls the network through a southbound management protocol (PCEP). 813 An implementation of a PCE-based controller will require access to 814 information about the state of the network, its nodes, and its links. 815 Some of this will be the TED as is normal for a PCE and can be 816 collected using the mechanisms already in place (such as listening to 817 the IGPs, using BGP-LS [RFC7752], or northbound export of YANG- 818 encoded data [I-D.ietf-teas-yang-te-topo] from the network elements 819 to the controller). More information may be collected in the LSP 820 database as described for stateful PCEs as described in [RFC7399] and 821 [I-D.ietf-pce-stateful-pce]. Additional information may be needed 822 for other specific use cases and will need to be collected and passed 823 to the controller. This may require protocol extensions for the 824 mechanisms listed in this paragraph. 826 The use of different PCEP options and protocol extensions may have an 827 impact on interoperability, which is a management issue. As noted in 828 Section 4, protocol extensions should be done in a way that makes it 829 possible to identify profiles of PCEP to aid interoperability and 830 this will aid deployment and manageability. 832 RFC 5440 [RFC5440] contains a substantive manageability 833 considerations section that examines how a PCE-based system and a 834 PCE-enabled system may be managed. A MIB module for PCEP was 835 published as RFC 7420 [RFC7420] and a YANG module for PCEP has also 836 been proposed [I-D.pkd-pce-pcep-yang]. 838 7. IANA Considerations 840 This document makes no requests for IANA action. 842 8. Contributors 844 The following people contributed to discussions that led to the 845 development of this document: 847 Cyril Margaria 848 Email: cmargaria@juniper.net 850 Sudhir Cheruathur 851 Email: scheruathur@juniper.net 853 Dhruv Dhody 854 Email: dhruv.dhody@huawei.com 856 Daniel King 857 Email: daniel@olddog.co.uk 859 Iftekhar Hussain 860 Email: IHussain@infinera.com 862 Anurag Sharma 863 Email: AnSharma@infinera.com 865 Eric Wu 866 Email: eric.wu@huawei.com 868 9. Acknowledgements 870 The ideas in this document owe a lot to the work started by the 871 authors of [I-D.zhao-teas-pcecc-use-cases] and 872 [I-D.zhao-pce-pcep-extension-for-pce-controller]. The authors of 873 this document fully acknowledge the prior work and thank those 874 involved for opening the discussion. The individuals concerned are: 875 King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, Zhenbin Li. 877 This document has benefited from the discussions within a small ad 878 hoc design team the members of which are listed as document 879 contributors. 881 Thanks to Michael Scharf and Andy Malis for a lively discussion of 882 this document. 884 Thanks to Phil Bedard, Aijun Wang, and Elwyn Davies for last call 885 comments on this document. 887 Spencer Dawkins, Adam Roach, and Ben Campbell provided helpful 888 comments during IESG review. 890 10. References 892 10.1. Normative References 894 [I-D.ietf-pce-pce-initiated-lsp] 895 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 896 Extensions for PCE-initiated LSP Setup in a Stateful PCE 897 Model", draft-ietf-pce-pce-initiated-lsp-10 (work in 898 progress), June 2017. 900 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 901 Element (PCE)-Based Architecture", RFC 4655, 902 DOI 10.17487/RFC4655, August 2006, . 905 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 906 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 907 DOI 10.17487/RFC5440, March 2009, . 910 10.2. Informative References 912 [I-D.ietf-pce-pceps] 913 Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure 914 Transport for PCEP", draft-ietf-pce-pceps-16 (work in 915 progress), August 2017. 917 [I-D.ietf-pce-stateful-pce] 918 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 919 Extensions for Stateful PCE", draft-ietf-pce-stateful- 920 pce-21 (work in progress), June 2017. 922 [I-D.ietf-pce-wson-rwa-ext] 923 Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing 924 and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-06 925 (work in progress), December 2016. 927 [I-D.ietf-spring-segment-routing] 928 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 929 and R. Shakir, "Segment Routing Architecture", draft-ietf- 930 spring-segment-routing-12 (work in progress), June 2017. 932 [I-D.ietf-teas-yang-te-topo] 933 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 934 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 935 teas-yang-te-topo-12 (work in progress), July 2017. 937 [I-D.pkd-pce-pcep-yang] 938 Dhody, D., Hardwick, J., Beeram, V., and j. 939 jefftant@gmail.com, "A YANG Data Model for Path 940 Computation Element Communications Protocol (PCEP)", 941 draft-pkd-pce-pcep-yang-06 (work in progress), July 2016. 943 [I-D.zhao-pce-pcep-extension-for-pce-controller] 944 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 945 and C. Zhou, "PCEP Procedures and Protocol Extensions for 946 Using PCE as a Central Controller (PCECC) of LSPs", draft- 947 zhao-pce-pcep-extension-for-pce-controller-05 (work in 948 progress), June 2017. 950 [I-D.zhao-teas-pcecc-use-cases] 951 Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou, 952 C., Communications, T., Rachitskiy, A., and A. Gulida, 953 "The Use Cases for Using PCE as the Central 954 Controller(PCECC) of LSPs", draft-zhao-teas-pcecc-use- 955 cases-02 (work in progress), October 2016. 957 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 958 McManus, "Requirements for Traffic Engineering Over MPLS", 959 RFC 2702, DOI 10.17487/RFC2702, September 1999, 960 . 962 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 963 Edge-to-Edge (PWE3) Architecture", RFC 3985, 964 DOI 10.17487/RFC3985, March 2005, . 967 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 968 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 969 DOI 10.17487/RFC4090, May 2005, . 972 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 973 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 974 2006, . 976 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery 977 (Protection and Restoration) Terminology for Generalized 978 Multi-Protocol Label Switching (GMPLS)", RFC 4427, 979 DOI 10.17487/RFC4427, March 2006, . 982 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 983 Path Computation Element Architecture to the Determination 984 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 985 DOI 10.17487/RFC6805, November 2012, . 988 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 989 Margaria, "Requirements for GMPLS Applications of PCE", 990 RFC 7025, DOI 10.17487/RFC7025, September 2013, 991 . 993 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 994 Computation Element Architecture", RFC 7399, 995 DOI 10.17487/RFC7399, October 2014, . 998 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 999 Hardwick, "Path Computation Element Communication Protocol 1000 (PCEP) Management Information Base (MIB) Module", 1001 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1002 . 1004 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1005 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1006 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1007 2015, . 1009 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1010 Application-Based Network Operations", RFC 7491, 1011 DOI 10.17487/RFC7491, March 2015, . 1014 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1015 Chaining (SFC) Architecture", RFC 7665, 1016 DOI 10.17487/RFC7665, October 2015, . 1019 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1020 S. Ray, "North-Bound Distribution of Link-State and 1021 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1022 DOI 10.17487/RFC7752, March 2016, . 1025 Authors' Addresses 1026 Adrian Farrel (editor) 1027 Juniper Networks 1029 Email: afarrel@juniper.net 1031 Quintin Zhao (editor) 1032 Huawei Technologies 1033 125 Nagog Technology Park 1034 Acton, MA 01719 1035 USA 1037 Email: quintin.zhao@huawei.com 1039 Robin Li 1040 Huawei Technologies 1041 Huawei Bld., No.156 Beiqing Road 1042 Beijing 100095 1043 China 1045 Email: lizhenbin@huawei.com 1047 Chao Zhou 1048 Cisco Systems 1050 Email: chao.zhou@cisco.com