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