idnits 2.17.1 draft-ietf-teas-pce-central-control-01.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 (December 5, 2016) is 2699 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-07 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-10 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-10 == Outdated reference: A later version (-08) exists of draft-zhao-pce-pcep-extension-for-pce-controller-03 Summary: 0 errors (**), 0 flaws (~~), 6 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: June 8, 2017 R. Li 6 Huawei Technologies 7 C. Zhou 8 Cisco Systems 9 December 5, 2016 11 An Architecture for Use of PCE and PCEP in a Network with Central 12 Control 13 draft-ietf-teas-pce-central-control-01 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 June 8, 2017. 60 Copyright Notice 62 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 18 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 PCEP is essentially already capable of acting as an SBI and only 261 small, use case- specific modifications to the protocol are needed to 262 support this architecture. The implications for the protocol are 263 discussed further in Section 4. 265 -------------------------------------------- 266 | Orchestrator / Service Manager / OSS / NMS | 267 -------------------------------------------- 268 ^ 269 | 270 v 271 ------------ 272 | | ----- 273 | PCE-based |<---| TED | 274 | Controller | ----- 275 | | 276 /------------\ 277 PCEP / ^ ^ \ 278 / | | \ 279 / v v \ 280 / ---- ---- \ 281 / | NE | | NE | \ 282 ----/ ---- ---- \---- 283 | NE | | NE | 284 ---- ---- 285 ^ ---- ---- ^ 286 :......>| NE |...| NE |<....: 287 Control Plane ---- ---- 289 Figure 3: Architecture for Node-by-Node Central Control 291 2.1. Resilience and Scaling 293 Systems with central controllers are vulnerable to two problems: 294 failure or overload of the single controller. These concerns are not 295 unique to the use of a PCE-based controller, but need to be addressed 296 in this document before the PCE-based controller architecture can be 297 considered for use in all but the smallest networks. 299 There are three architectural mechanisms that can be applied to 300 address these issues. The mechanisms are described separately for 301 clarity, but a deployment use may any combination of the approaches. 303 For simplicity of illustration, these three approaches are shown in 304 the sections that follow without a control plane. However, the 305 general, hybrid approach of Figure 3 is applicable in each case. 307 2.1.1. Partitioned Network 309 The first and simplest approach to handling controller overload or 310 scalability is to use multiple controllers, each responsible for a 311 part of the network. We can call the resultant areas of control 312 "domains." 314 This approach is shown in Figure 4. It can clearly address some of 315 the scaling and overload concerns since each controller now only has 316 responsibility for a subset of the network elements. But this comes 317 at a cost because end-to-end connections require coordination between 318 the controllers. Furthermore, this technique does not remove the 319 single-point-of-failure concern even if it does reduce the impact on 320 the network of the failure of a single controller. 322 Note that PCEP is designed to work as a PCE-to-PCE protocol as well 323 as a PCE-to-PCC protocol, so it should be possible to use it to 324 coordinate between PCE-based controllers in this model. 326 -------------------------------------------- 327 | Orchestrator / Service Manager / OSS / NMS | 328 -------------------------------------------- 329 ^ ^ 330 | | 331 v v 332 ------------ Coord- ------------ 333 ----- | | ination | | ----- 334 | TED |--->| PCE-based |<-------->| PCE-based |<---| TED | 335 ----- | Controller | | Controller | ----- 336 | | :: | | 337 /------------ :: ------------\ 338 / ^ ^ :: ^ ^ \ 339 / | | :: | | \ 340 | | | :: | | | 341 v v v :: v v v 342 ---- ---- ---- :: ---- ---- ---- 343 | NE | | NE | | NE | :: | NE | | NE | | NE | 344 ---- ---- ---- :: ---- ---- ---- 345 :: 346 Domain 1 :: Domain 2 347 :: 349 Figure 4: Multiple Controllers on a Partitioned Network 351 2.1.2. Multiple Parallel Controllers 353 Multiple parallel controllers may be deployed as shown in Figure 5. 354 Each controller is capable of controlling all of the network elements 355 thus the failure of any one controller will not leave the network 356 unmanageable and, in normal circumstances, the load can be 357 distributed across the controllers. 359 To achieve full redundancy and to be able to continue to provide full 360 function in the event of the failure a controller, the controllers 361 must synchronize with each other. This is nominally a simple task if 362 there are just two controllers, but can actually be quite complex if 363 state changes in the network are not to be lost. Furthermore, if 364 there are more than two controllers, the synchronization between 365 controllers can become a hard problem. 367 Synchronization issues are often off-loaded as "database 368 synchronization" problems because distributed database packages have 369 already had to address these challenges. In networking the problem 370 may also be addressed by collecting the state from the network 371 (effectively using the network as a database) using normal routing 372 protocols such as OSPF, IS-IS, and BGP. 374 -------------------------------------------- 375 | Orchestrator / Service Manager / OSS / NMS | 376 -------------------------------------------- 377 ^ ^ 378 | ___________________ | 379 | | Synchronization | | 380 v v v v 381 ------------ ------------ 382 | | ----- | | 383 | PCE-based |<---| TED |--->| PCE-based | 384 | Controller | ----- | Controller | 385 | |__ ...........| | 386 ------------\ \_:__ :------------ 387 ^ ^ \___: \ .....: ^ ^ 388 | | .....:\ \_:___ ..: : 389 | |__:___ \___:_ \_:___ : 390 | ....: | .....: | ..: | : 391 | : | : | : | : 392 v v v v v v v v 393 ---- ---- ---- ---- 394 | NE | | NE | | NE | | NE | 395 ---- ---- ---- ---- 397 Figure 5: Multiple Redundant Controllers 399 2.1.3. Hierarchical Controllers 401 Figure 6 shows an approach with hierarchical controllers. This 402 approach was developed for PCEs in [RFC6805] and appears in various 403 SDN architectures where a "parent PCE", an "orchestrator", or "super 404 controller" takes responsibility for a high-level view of the network 405 before distributing tasks to lower level PCEs or controllers. 407 On its own, this approach does little to protect against the failure 408 of a controller, but it can make significant improvements in loading 409 and scaling of the individual controllers. It also offers a good way 410 to support end-to-end connectivity across multiple administrative or 411 technology-specific domains. 413 Note that this model can be arbitrarily recursive with a PCE-based 414 controller being the child of one parent PCE-based controller while 415 acting as the parent of another set of PCE-based controllers. 417 -------------------------------------------- 418 | Orchestrator / Service Manager / OSS / NMS | 419 -------------------------------------------- 420 ^ 421 | 422 v 423 ------------ 424 | Parent | ----- 425 | PCE-based |<---| TED | 426 | Controller | ----- 427 | | 428 ------------ 429 ^ ^ 430 | | 431 v :: v 432 ------------ :: ------------ 433 ----- | | :: | | ----- 434 | TED |--->| PCE-based | :: | PCE-based |<---| TED | 435 ----- | Controller | :: | Controller | ----- 436 /| | :: | |\ 437 / ------------ :: ------------ \ 438 / ^ ^ :: ^ ^ \ 439 / | | :: | | \ 440 / | | :: | | \ 441 | | | :: | | | 442 v v v :: v v v 443 ---- ---- ---- :: ---- ---- ---- 444 | NE | | NE | | NE | :: | NE | | NE | | NE | 445 ---- ---- ---- :: ---- ---- ---- 446 :: 447 Domain 1 :: Domain 2 448 :: 450 Figure 6: Hierarchical Controllers 452 3. Applicability 454 This section gives a very high-level introduction to the 455 applicability of a PCE-based centralized controller. There is no 456 attempt to explain each use case in detail, and the inclusion of a 457 use case is not intended to suggest that deploying a PCE-based 458 controller is a mandatory or recommended approach. The sections 459 below are provided as a stimulus to discussion of the applicability 460 of a PCE-based controller and it is expected that separate documents 461 will be written to develop the use cases in which there is interest 462 for implementation and deployment. As described in Section 4 463 specific enhancements to PCEP may be needed for some of these use 464 cases and it is expected that the documents that develop each use 465 case will also address any extensions to PCEP. 467 The rest of this section is divided into two sub-sections. The first 468 approaches the question of applicability from a consideration of the 469 network technology. The second looks at the high-level functions 470 that can be delivered by using a PCE-based controller. 472 As previously mentioned, this section is intended to just make 473 suggestions. Thus the material supplied is very brief. The omission 474 of a use case is in no way meant to imply some limit on the 475 applicability of PCE-based control. 477 3.1. Technology-Oriented Applicability 479 This section provides a list of use cases based on network 480 technology. 482 3.1.1. Applicability to Control Plane Operated Networks 484 This mode of operation is the common approach for an active, stateful 485 PCE to control a traffic engineered MPLS or GMPLS network 486 [I-D.ietf-pce-stateful-pce]. Note that the PCE-based controller 487 determines what LSPs are needed and where to place them. PCEP is 488 used to instruct the head end of each LSP, and the head end signals 489 in the control plane to set up the LSP. 491 3.1.2. Static LSPs in MPLS 493 Static LSPs are provisioned without the use of a control plane. This 494 means that they are established using management plane or "manual" 495 configuration. 497 Static LSPs can be provisioned as 1-hop, micro-LSPs at each node 498 along the path of an end-to-end path LSP. Each router along the path 499 must be told what label forwarding instructions to program and what 500 resources to reserve. The PCE-based controller keeps a view of the 501 network and determines the paths of the end-to-end LSPs just as it 502 does for the use case described in Section 3.1.1, but the controller 503 uses PCEP to communicate with each router along the path of the end- 504 to-end LSP. In this case the PCE-based controller will take 505 responsibility for managing some part of the MPLS label space for 506 each of the routers that it controls, and may taker wider 507 responsibility for partitioning the label space for each router and 508 allocating different parts for different uses communicating the 509 ranges to the router using PCEP. 511 3.1.3. MPLS Multicast 513 Multicast LSPs may be provisioned with a control plane or as static 514 LSPs. No extra considerations apply above those in Section 3.1.1 and 515 Section 3.1.2 except, of course, to note that the PCE must also 516 include the instructions about where the LSP branches, i.e., where 517 packets must be copied. 519 3.1.4. Transport SDN 521 Transport SDN (T-SDN) is the application of SDN techniques to 522 transport networks. In this respect a transport network is a network 523 built from any technology below the IP layer and designed to carry 524 traffic transparently in a connection-oriented way. Thus, an MPLS 525 traffic engineering network is a transport network although it is 526 more common to consider technologies such as Time Division 527 Multiplexing (TDM) and Optical Transport Networks (OTN). 529 Transport networks may be operated with or without a control plane 530 and may have point-to-point or point-to-multipoint connections. 531 Thus, all of the considerations in Section 3.1.1, Section 3.1.2, and 532 Section 3.1.3 apply. It may be the case that additional technology- 533 specific parameters are needed to configure the NEs and these 534 parameters will need to be carried in the PCEP messages. 536 3.1.5. Segment Routing 538 Segment routing is described in [I-D.ietf-spring-segment-routing]. 539 It relies on a series of forwarding instructions being placed in the 540 header or a packet. At each hop in the network a router looks at the 541 first instruction and may: continue to forward the packet unchanged; 542 strip the top instruction and forward the packet; or strip the top 543 instruction, insert some additional instructions, and forward the 544 packet. 546 The segment routing architecture supports operations that can be used 547 to steer packet flows in a network thus providing a form of traffic 548 engineering. A PCE-based controller can be responsible for computing 549 the paths for packet flows in a segment routing network, for 550 configuring the forwarding actions on the routers, and for telling 551 the edge routers what instructions to attach to packets as they enter 552 the network. These last two operations can be achieved using PCEP 553 and the PCE-based controller will assume responsibility for managing 554 the space of labels or path identifiers used to determine how packets 555 are forwarded. 557 3.1.6. Service Function Chaining 559 Service Function Chaining (SFC) is described in [RFC7665]. It is the 560 process of directing traffic in a network such that it passes through 561 specific hardware devices or virtual machines (known as service 562 function nodes) that can perform particular desired functions on the 563 traffic. The set of functions to be performed and the order in which 564 they are to be performed is known as a Service Function Chain. The 565 chain is enhanced with the locations at which the service functions 566 are to be performed to derive a Service Function Path (SFP). Each 567 packet is marked as belonging to a specific SFP and that marking lets 568 each successive service function node know which functions to perform 569 and to which service function node to send the packet next. 571 To operate an SFC network the service function nodes must be 572 configured to understand the packet markings and the edge nodes must 573 be told how to mark packets entering the network. Additionally it 574 may be necessary to establish tunnels between service function nodes 575 to carry the traffic. 577 Planning an SFC network requires load balancing between service 578 function nodes and traffic engineering across the network that 579 connects them. These are operations that can be performed by a PCE- 580 based controller, and that controller can use PCEP to program the 581 network and install the service function chains and any required 582 tunnels. 584 3.2. High-Level Applicability 586 This section provides a list of the high-level functions that can be 587 delivered by using a PCE-based controller. 589 3.2.1. Traffic Engineering 591 According to [RFC2702], Traffic Engineering (TE) is concerned with 592 performance optimization of operational networks. In general, it 593 encompasses the application of technology and scientific principles 594 to the measurement, modeling, characterization, control of Internet 595 traffic, and the application of such knowledge and techniques to 596 achieve specific performance objectives. 598 From a practical point of view this involves having an understanding 599 of the topology of the network, the characteristics of the nodes and 600 links in the network, and the traffic demands and flows across the 601 network. It also requires that actions can be taken to ensure that 602 traffic follows specific paths through the network. 604 PCE was specifically developed to address TE in an MPLS network, and 605 so a PCE-based controller is well suited to analyze TE problems and 606 supply answers that can be installed in the network using PCEP. PCEP 607 can be responsible for initiating paths across the network through a 608 control plane, or for installing state in the network node by node 609 such as in a Segment Routed network (see Section 3.1.5) or by 610 configuring IGP metrics. 612 3.2.2. Traffic Classification 614 Traffic classification is an important part of traffic engineering. 615 It is the process of looking at a packet to determine how it should 616 be treated as it is forwarded through the network. It applies in 617 many scenarios including MPLS traffic engineering (where it 618 determines what traffic is forwarded onto which LSPs), segment 619 routing (where it is used to select which set of forwarding 620 instructions to add to a packet), and service function chaining 621 (where it indicates along which service function path a packet should 622 be forwarded). In conjunction with traffic engineering, traffic 623 classification is an important enabler for load balancing. 625 Traffic classification is closely linked to the computational 626 elements of planning for the network functions just listed because it 627 determines how traffic load is balanced and distributed through the 628 network. Therefore, selecting what traffic classification should be 629 performed by a router is an important part of the work done by a PCE- 630 based controller. 632 Instructions can be passed from the controller to the routers using 633 PCEP. These instructions tell the routers how to map traffic to 634 paths or connections. The instructions may use the concept of a 635 Forwarding Equivalence Class (FEC). 637 3.2.3. Service Delivery 639 Various network services may be offered over a network. These 640 include protection services (including end-to-end protection 641 [RFC4427], restoration after failure, and fast reroute [RFC4090]), 642 Virtual Private Network (VPN) service (such as Layer 3 VPNs [RFC4364] 643 or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. 645 Delivering services over a network in an optimal way requires 646 coordination in the way that network resources are allocated to 647 support the services. A PCE-based central controller can consider 648 the whole network and all components of a service at once when 649 planning how to deliver the service. It can then use PCEP to manage 650 the network resources and to install the necessary associations 651 between those resources. 653 4. Protocol Implications 655 PCEP is a push-pull protocol that is designed to move requests and 656 responses between a server (the PCE) and clients (the PCCs, i.e., the 657 network elements). In particular, it has a message (PCInitiate 658 [I-D.ietf-pce-pce-initiated-lsp]) that can be sent by the PCE to 659 install state or cause actions at the PCC, and a response message 660 (PCRpt) that is used to confirm the request. 662 As such, there is an expectation that only relatively minor changes 663 to PCEP are required to support the concept of a PCE-based 664 controller. The only work expected to be needed is small extensions 665 to carry additional or specific information elements for the 666 individual use cases. Where possible, consistent with the general 667 principles of how protocols are extended, any additions to the 668 protocol should be made in a generic way such that they are open to 669 use in a range of applications. 671 It is anticipated that new documents will be produced for each use 672 case dependent on support and demand. Such documents will explain 673 the use case and define the necessary protocol extensions. 675 5. Security Considerations 677 Security considerations for a PCE-based controller are little 678 different from those for any other PCE system. That is, the 679 operation relies heavily on the use and security of PCEP and so 680 consideration should be given to the security features discussed in 681 [RFC5440] and the additional mechanisms described in 682 [I-D.ietf-pce-pceps]. 684 It should be observed that the trust model of a network that operates 685 without a control plane is different from one with a control plane. 686 The conventional "chain of trust" used with a control plane is 687 replaced by individual trust relationships between the controller and 688 each individual NE. This model may be considerably easier to manage 689 and so is more likely to be operated with a high level of security. 690 However, debate will rage over overall system security and the 691 opportunity for attacks in an architecture with a central controller 692 since the network can be vulnerable to denial of service attacks on 693 the controller, and the forwarding system may be harmed by attacks on 694 the messages sent to individual NEs. In short, while the 695 interactions with a PCE-based controller are not substantially 696 different from those in any other SDN architecture, the security 697 implications of SDN are still open for discussion. The IRTF's SDN 698 Research Group (SDNRG) continues to discuss this topic. 700 It is expected that each new document that is produced for a specific 701 use case will also include considerations of the security impacts of 702 the use of a PCE-based central controller on the network type and 703 services being managed. 705 6. Manageability Considerations 707 The architecture described in this document is a management 708 architecture: the PCE-based controller is a management component that 709 controls the network through a southbound management protocol (PCEP). 711 RFC 5440 [RFC5440] contains a substantive manageability 712 considerations section that examines how a PCE-based system and a 713 PCE-enabled system may be managed. A MIB module for PCEP was 714 published as RFC 7420 [RFC7420] and a YANG module for PCEP has also 715 been proposed [I-D.pkd-pce-pcep-yang]. 717 7. IANA Considerations 719 This document makes no requests for IANA action. 721 8. Contributors 723 The following people contributed to discussions that led to the 724 development of this document: 726 Cyril Margaria 727 Email: cmargaria@juniper.net 729 Sudhir Cheruathur 730 Email: scheruathur@juniper.net 732 Dhruv Dhody 733 Email: dhruv.dhody@huawei.com 735 Daniel King 736 Email: daniel@olddog.co.uk 738 Iftekhar Hussain 739 Email: IHussain@infinera.com 741 Anurag Sharma 742 Email: AnSharma@infinera.com 744 Eric Wu 745 Email: eric.wu@huawei.com 747 9. Acknowledgements 749 The ideas in this document owe a lot to the work started by the 750 authors of [I-D.zhao-teas-pcecc-use-cases] and 751 [I-D.zhao-pce-pcep-extension-for-pce-controller]. The authors of 752 this document fully acknowledge the prior work and thank those 753 involved for opening the discussion. The individuals concerned are: 754 King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, Zhenbin Li. 756 This document has benefited from the discussions within a small ad 757 hoc design team the members of which are listed as document 758 contributors. 760 Thanks to Michael Scharf and Andy Malis for a lively discussion of 761 this document. 763 10. References 765 10.1. Normative References 767 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 768 Element (PCE)-Based Architecture", RFC 4655, 769 DOI 10.17487/RFC4655, August 2006, 770 . 772 10.2. Informative References 774 [I-D.ietf-pce-pce-initiated-lsp] 775 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 776 Extensions for PCE-initiated LSP Setup in a Stateful PCE 777 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 778 progress), July 2016. 780 [I-D.ietf-pce-pceps] 781 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 782 Transport for PCEP", draft-ietf-pce-pceps-10 (work in 783 progress), July 2016. 785 [I-D.ietf-pce-stateful-pce] 786 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 787 Extensions for Stateful PCE", draft-ietf-pce-stateful- 788 pce-18 (work in progress), December 2016. 790 [I-D.ietf-spring-segment-routing] 791 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 792 and R. Shakir, "Segment Routing Architecture", draft-ietf- 793 spring-segment-routing-10 (work in progress), November 794 2016. 796 [I-D.pkd-pce-pcep-yang] 797 Dhody, D., Hardwick, J., Beeram, V., and j. 798 jefftant@gmail.com, "A YANG Data Model for Path 799 Computation Element Communications Protocol (PCEP)", 800 draft-pkd-pce-pcep-yang-06 (work in progress), July 2016. 802 [I-D.zhao-pce-pcep-extension-for-pce-controller] 803 Zhao, Q., Li, Z., Dhody, D., and C. Zhou, "PCEP Procedures 804 and Protocol Extensions for Using PCE as a Central 805 Controller (PCECC) of LSPs", draft-zhao-pce-pcep- 806 extension-for-pce-controller-03 (work in progress), March 807 2016. 809 [I-D.zhao-teas-pcecc-use-cases] 810 Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou, 811 C., Communications, T., Rachitskiy, A., and A. Gulida, 812 "The Use Cases for Using PCE as the Central 813 Controller(PCECC) of LSPs", draft-zhao-teas-pcecc-use- 814 cases-02 (work in progress), October 2016. 816 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 817 McManus, "Requirements for Traffic Engineering Over MPLS", 818 RFC 2702, DOI 10.17487/RFC2702, September 1999, 819 . 821 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 822 Edge-to-Edge (PWE3) Architecture", RFC 3985, 823 DOI 10.17487/RFC3985, March 2005, 824 . 826 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 827 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 828 DOI 10.17487/RFC4090, May 2005, 829 . 831 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 832 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 833 2006, . 835 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery 836 (Protection and Restoration) Terminology for Generalized 837 Multi-Protocol Label Switching (GMPLS)", RFC 4427, 838 DOI 10.17487/RFC4427, March 2006, 839 . 841 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 842 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 843 DOI 10.17487/RFC5440, March 2009, 844 . 846 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 847 Path Computation Element Architecture to the Determination 848 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 849 DOI 10.17487/RFC6805, November 2012, 850 . 852 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 853 Margaria, "Requirements for GMPLS Applications of PCE", 854 RFC 7025, DOI 10.17487/RFC7025, September 2013, 855 . 857 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 858 Computation Element Architecture", RFC 7399, 859 DOI 10.17487/RFC7399, October 2014, 860 . 862 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 863 Hardwick, "Path Computation Element Communication Protocol 864 (PCEP) Management Information Base (MIB) Module", 865 RFC 7420, DOI 10.17487/RFC7420, December 2014, 866 . 868 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 869 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 870 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 871 2015, . 873 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 874 Application-Based Network Operations", RFC 7491, 875 DOI 10.17487/RFC7491, March 2015, 876 . 878 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 879 Chaining (SFC) Architecture", RFC 7665, 880 DOI 10.17487/RFC7665, October 2015, 881 . 883 Authors' Addresses 885 Adrian Farrel (editor) 886 Juniper Networks 888 Email: afarrel@juniper.net 889 Quintin Zhao (editor) 890 Huawei Technologies 891 125 Nagog Technology Park 892 Acton, MA 01719 893 USA 895 Email: quintin.zhao@huawei.com 897 Robin Li 898 Huawei Technologies 899 Huawei Bld., No.156 Beiqing Road 900 Beijing 100095 901 China 903 Email: lizhenbin@huawei.com 905 Chao Zhou 906 Cisco Systems 908 Email: chao.zhou@cisco.com