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