idnits 2.17.1 draft-ietf-pce-pcep-extension-for-pce-controller-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 1, 2020) is 1332 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-05 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-14 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-07 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-04 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-06 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-03 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-01 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: March 5, 2021 M. Negi 6 RtBrick India 7 Q. Zhao 8 Etheric Networks 9 C. Zhou 10 HPE 11 September 1, 2020 13 PCEP Procedures and Protocol Extensions for Using PCE as a Central 14 Controller (PCECC) of LSPs 15 draft-ietf-pce-pcep-extension-for-pce-controller-07 17 Abstract 19 The Path Computation Element (PCE) is a core component of Software- 20 Defined Networking (SDN) systems. It can compute optimal paths for 21 traffic across a network and can also update the paths to reflect 22 changes in the network or traffic demands. 24 PCE was developed to derive paths for MPLS Label Switched Paths 25 (LSPs), which are supplied to the head end of the LSP using the Path 26 Computation Element Communication Protocol (PCEP). But SDN has a 27 broader applicability than signaled MPLS and GMPLS traffic-engineered 28 (TE) networks, and the PCE may be used to determine paths in a range 29 of use cases. PCEP has been proposed as a control protocol for use 30 in these environments to allow the PCE to be fully enabled as a 31 central controller. 33 A PCE-based central controller (PCECC) can simplify the processing of 34 a distributed control plane by blending it with elements of SDN and 35 without necessarily completely replacing it. Thus, the LSP can be 36 calculated/setup/initiated and the label forwarding entries can also 37 be downloaded through a centralized PCE server to each network 38 devices along the path while leveraging the existing PCE technologies 39 as much as possible. 41 This document specifies the procedures and PCEP extensions for using 42 the PCE as the central controller. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on March 5, 2021. 61 Copyright Notice 63 Copyright (c) 2020 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 82 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 83 5. Procedures for Using the PCE as the Central Controller 84 (PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 86 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 87 5.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 7 88 5.4. PCECC Capability Advertisement . . . . . . . . . . . . . 7 89 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 90 5.5.1. Basic PCECC LSP set up . . . . . . . . . . . . . . . 8 91 5.5.2. Central Controller Instructions . . . . . . . . . . . 12 92 5.5.2.1. Label Download CCI . . . . . . . . . . . . . . . 12 93 5.5.2.2. Label Cleanup CCI . . . . . . . . . . . . . . . . 12 94 5.5.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 13 95 5.5.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 15 96 5.5.5. Re-Delegation and Cleanup . . . . . . . . . . . . . . 17 97 5.5.6. Synchronization of Central Controllers Instructions . 17 98 5.5.7. PCECC LSP State Report . . . . . . . . . . . . . . . 17 99 5.5.8. PCC Based Allocations . . . . . . . . . . . . . . . . 18 100 5.5.9. Binding Label . . . . . . . . . . . . . . . . . . . . 18 101 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 19 102 6.1. The PCInitiate message . . . . . . . . . . . . . . . . . 19 103 6.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 21 104 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 22 105 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 22 106 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 22 107 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 23 108 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 23 109 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 24 110 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 111 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 26 112 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 113 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 27 114 10. Manageability Considerations . . . . . . . . . . . . . . . . 27 115 10.1. Control of Function and Policy . . . . . . . . . . . . . 27 116 10.2. Information and Data Models . . . . . . . . . . . . . . 27 117 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 27 118 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 27 119 10.5. Requirements On Other Protocols . . . . . . . . . . . . 27 120 10.6. Impact On Network Operations . . . . . . . . . . . . . . 28 121 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 122 11.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28 123 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 28 124 11.3. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 28 125 11.4. Path Setup Type Registry . . . . . . . . . . . . . . . . 29 126 11.5. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 29 127 11.6. CCI Object Flag Field . . . . . . . . . . . . . . . . . 29 128 11.7. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 29 129 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 131 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 132 13.2. Informative References . . . . . . . . . . . . . . . . . 32 133 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 34 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 136 1. Introduction 138 The Path Computation Element (PCE) [RFC4655] was developed to offload 139 path computation function from routers in an MPLS traffic-engineered 140 network. Since then, the role and function of the PCE has grown to 141 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 142 delegated control [RFC8231] and PCE-initiated use of network 143 resources [RFC8281]. 145 According to [RFC7399], Software-Defined Networking (SDN) refers to a 146 separation between the control elements and the forwarding components 147 so that software running in a centralized system, called a 148 controller, can act to program the devices in the network to behave 149 in specific ways. A required element in an SDN architecture is a 150 component that plans how the network resources will be used and how 151 the devices will be programmed. It is possible to view this 152 component as performing specific computations to place traffic flows 153 within the network given knowledge of the availability of network 154 resources, how other forwarding devices are programmed, and the way 155 that other flows are routed. This is the function and purpose of a 156 PCE, and the way that a PCE integrates into a wider network control 157 system (including an SDN system) is presented in [RFC7491]. 159 In early PCE implementations, where the PCE was used to derive paths 160 for MPLS Label Switched Paths (LSPs), paths were requested by network 161 elements (known as Path Computation Clients (PCCs)), and the results 162 of the path computations were supplied to network elements using the 163 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 164 This protocol was later extended to allow a PCE to send unsolicited 165 requests to the network for LSP establishment [RFC8281]. 167 [RFC8283] introduces the architecture for PCE as a central controller 168 as an extension of the architecture described in [RFC4655] and 169 assumes the continued use of PCEP as the protocol used between PCE 170 and PCC. [RFC8283] further examines the motivations and 171 applicability for PCEP as a Southbound Interface (SBI), and 172 introduces the implications for the protocol. 173 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 174 architecture. 176 A PCE-based central controller (PCECC) can simplify the processing of 177 a distributed control plane by blending it with elements of SDN and 178 without necessarily completely replacing it. Thus, the LSP can be 179 calculated/setup/initiated and the label forwarding entries can also 180 be downloaded through a centralized PCE server to each network 181 devices along the path while leveraging the existing PCE technologies 182 as much as possible. 184 This document specifies the procedures and PCEP protocol extensions 185 for using the PCE as the central controller for static LSPs, where 186 LSPs can be provisioned as explicit label instructions at each hop on 187 the end-to-end path. Each router along the path must be told what 188 label-forwarding instructions to program and what resources to 189 reserve. The PCE-based controller keeps a view of the network and 190 determines the paths of the end-to-end LSPs, and the controller uses 191 PCEP to communicate with each router along the path of the end-to-end 192 LSP. 194 While this document is focused on the procedures for the static LSPs 195 (referred to as basic PCECC mode in Section 3), the mechanism and 196 protocol encoding are specified in such a way that, extensions for 197 other use cases is easy to achieve. For example, the extensions for 198 PCECC for Segment Routing (SR) are specified in 199 [I-D.zhao-pce-pcep-extension-pce-controller-sr] and 200 [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 202 1.1. Requirements Language 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 206 "OPTIONAL" in this document are to be interpreted as described in BCP 207 14 [RFC2119] [RFC8174] when, and only when, they appear in all 208 capitals, as shown here. 210 2. Terminology 212 The terminology used in this document is the same as that described 213 in the draft [RFC8283]. 215 3. Basic PCECC Mode 217 In this mode, LSPs are provisioned as explicit label instructions at 218 each hop on the end-to-end path. Each router along the path must be 219 told what label forwarding instructions to program and what resources 220 to reserve. The controller uses PCEP to communicate with each router 221 along the path of the end-to-end LSP. 223 Note that the PCE-based controller will take responsibility for 224 managing some part of the MPLS label space for each of the routers 225 that it controls, and may take wider responsibility for partitioning 226 the label space for each router and allocating different parts for 227 different uses. This is also described in section 3.1.2. of 228 [RFC8283]. For the purpose of this document, it is assumed that the 229 label range to be used by a PCE is known and set on both PCEP peers. 230 A future extension could add the capability to advertise the range 231 via possible PCEP extensions as well (see 232 [I-D.li-pce-controlled-id-space]). The rest of the processing is 233 similar to the existing stateful PCE mechanism. 235 This document also allows a case where the label space is maintained 236 by the PCC itself, and the labels are allocated by the PCC, in this 237 case, the PCE should request the allocation from PCC as described in 238 Section 5.5.8. 240 4. PCEP Requirements 242 The following key requirements should be considered when designing 243 the PCECC based solution: 245 1. PCEP speaker supporting this draft needs to have the capability 246 to advertise its PCECC capability to its peers. 248 2. PCEP speaker needs the means to identify PCECC based LSP in the 249 PCEP messages. 251 3. PCEP procedures need to allow for PCC based label allocations. 253 4. PCEP procedures need to provide a means to update (or cleanup) 254 the label-download entry to the PCC. 256 5. PCEP procedures need to provide a means to synchronize the labels 257 between PCE and PCC via PCEP messages. 259 5. Procedures for Using the PCE as the Central Controller (PCECC) 261 5.1. Stateful PCE Model 263 Active stateful PCE is described in [RFC8231]. PCE as a central 264 controller (PCECC) reuses existing Active stateful PCE mechanism as 265 much as possible to control the LSP. 267 5.2. New LSP Functions 269 Several new functions are required in PCEP to support PCECC. This 270 document extends the existing messages to support the new functions 271 required by PCECC: 273 (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate 274 message is used to set up PCE-Initiated LSP based on PCECC 275 mechanism. It is also extended for Central Controller 276 Instructions (CCI) (download or cleanup the Label forwarding 277 instructions in the context of this document) on all nodes along 278 the path. 280 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is 281 used to send PCECC LSP Reports. It is also extended to report the 282 set of Central Controller Instructions (CCI) (label forwarding 283 instructions in the context of this document) received from the 284 PCE. See Section 5.5.6 for more details. 286 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 287 used to send PCECC LSP Update. 289 The new functions defined in this document are mapped onto the PCEP 290 messages as shown in Table 1. 292 Function Message 293 PCECC Capability advertisement Open 294 Label entry Add PCInitiate 295 Label entry Cleanup PCInitiate 296 PCECC Initiated LSP PCInitiate 297 PCECC LSP Update PCUpd 298 PCECC LSP State Report PCRpt 299 PCECC LSP Delegation PCRpt 300 PCECC Label Report PCRpt 302 Table 1: Functions mapped to the PCEP messages 304 5.3. New PCEP Object 306 This document specifies a new PCEP object called CCI (see 307 Section 7.3) for the encoding of the central controller instructions. 308 In the scope of this document, this is limited to Label forwarding 309 instructions. Future documents can create new CCI object-types for 310 other types of central controller instructions. The CC-ID is the 311 unique identifier for the central controller instructions in PCEP. 312 The PCEP messages are extended in this document to handle the PCECC 313 operations. 315 5.4. PCECC Capability Advertisement 317 During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 318 advertise their support of PCECC extensions. 320 This document defines a new Path Setup Type (PST) [RFC8408] for 321 PCECC, as follows: 323 o PST = TBD1: Path is set up via PCECC mode. 325 A PCEP speaker MUST indicate its support of the function described in 326 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 327 object with this new PST included in the PST list. 329 This document also defines the PCECC Capability sub-TLV 330 Section 7.1.1. PCEP speakers use this sub-TLV to exchange 331 information about their PCECC capability. If a PCEP speaker includes 332 PST=TBD1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then 333 it MUST also include the PCECC Capability sub-TLV inside the PATH- 334 SETUP-TYPE-CAPABILITY TLV. If the sub-TLV is absent, then the PCEP 335 speaker MUST send a PCErr message with Error-Type 10 (Reception of an 336 invalid object) and Error-Value TBD2 (Missing PCECC Capability sub- 337 TLV) and MUST then close the PCEP session. If a PCEP speaker 338 receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PCECC-CAPABILITY 339 sub-TLV, but the PST list does not contain PST=TBD1, then the PCEP 340 speaker MUST ignore the PCECC-CAPABILITY sub-TLV. 342 The presence of the PST=TBD1 and PCECC Capability sub-TLV in a PCC's 343 OPEN Object indicates that the PCC is willing to function as a PCECC 344 client. The presence of the PST=TBD1 and PCECC Capability sub-TLV in 345 a PCE's OPEN message indicates that the PCE is interested in function 346 as a PCECC server. 348 The PCEP protocol extensions for PCECC MUST NOT be used if one or 349 both PCEP Speakers have not included the PST=TBD1 or the PCECC 350 Capability sub-TLV in their respective OPEN message. If the PCEP 351 Speakers support the extensions of this draft but did not advertise 352 this capability attempts a PCECC operation then a PCErr message with 353 Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted 354 PCECC operations when PCECC capability was not advertised) will be 355 generated and the PCEP session will be terminated. If a PCEP speaker 356 does not recognize the PCECC Capability sub-TLV, it will ignore the 357 sub-TLV in accordance with [RFC8408] and [RFC5440]. 359 A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and 360 STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with I flag set [RFC8281]) 361 in OPEN Object to support the extensions defined in this document. 362 If PCECC-CAPABILITY sub-TLV is advertised and STATEFUL-PCE-CAPABILITY 363 TLV is not advertised in OPEN Object, it MUST send a PCErr message 364 with Error-Type=19 (Invalid Operation) and Error-value=TBD4 (stateful 365 PCE capability was not advertised) and terminate the session. This 366 error is also triggered if PCECC-CAPABILITY sub-TLV is advertised and 367 I flag in the STATEFUL-PCE-CAPABILITY TLV is not set. 369 5.5. LSP Operations 371 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 372 TLV [RFC8408] in the SRP object to clearly identify the PCECC LSP is 373 intended. 375 5.5.1. Basic PCECC LSP set up 377 In order to set up an LSP based on the PCECC mechanism, a PCC MUST 378 delegate the LSP by sending a PCRpt message with PST set for PCECC 379 (see Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the 380 LSP object. 382 An LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the tuple 383 uniquely identifies the LSP in the network. The LSP object is 384 included in the central controller instructions (label download) to 385 identify the PCECC LSP for this instruction. The PLSP-ID is the 386 original identifier used by the ingress PCC, so the transit LSR could 387 have multiple central controller instructions that have the same 388 PLSP-ID. The PLSP-ID in combination with the source (in LSP- 389 IDENTIFIER TLV) MUST be unique. The PLSP-ID is included for 390 maintainability reasons to ease debugging. As per [RFC8281], the LSP 391 object could include SPEAKER-ENTITY-ID TLV to identify the PCE that 392 initiated these instructions. Also, the CC-ID is unique in the PCEP 393 session as described in Section 7.3. 395 When a PCE receives a PCRpt message with D flag and PST Type set, it 396 calculates the path and assigns labels along the path; and sets up 397 the path by sending PCInitiate message to each node along the path of 398 the LSP. The PCC generates a Path Computation State Report (PCRpt) 399 and includes the central controller instruction (CCI) and the 400 identified LSP. The CC-ID uniquely identifies the central controller 401 instruction within a PCEP session. The PCC further responds with the 402 PCRpt messages including the CCI and LSP objects. 404 The Ingress node would receive one CCI object with O bit (out-label) 405 set. The transit node(s) would receive two CCI objects with the in- 406 label CCI without an O bit set and the out-label CCI with O bit set. 407 The egress node would receive one CCI object without O bit set. A 408 node can determine its role based on the setting of the O bit in the 409 CCI object(s) and the LSP-IDENTIFIER TLV in the LSP object. 411 Once the central controller instructions (label operations) are 412 completed, the PCE MUST send the PCUpd message to the Ingress PCC. 413 Per [RFC8231], this PCUpd message should include the path information 414 calculated by the PCE. 416 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 418 LSP deletion operation for PCECC LSP is the same as defined in 419 [RFC8231]. If the PCE receives a PCRpt message for LSP deletion then 420 it does Label cleanup operation as described in Section 5.5.2.2 for 421 the corresponding LSP. 423 The Basic PCECC LSP setup sequence is as shown in Figure 1. 425 +-------+ +-------+ 426 |PCC | | PCE | 427 |Ingress| +-------+ 428 +------| | | 429 | PCC +-------+ | 430 | Transit| | | 431 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP 432 |PCC +--------+ | | 433 |Egress | | | | 434 +--------+ | | | 435 | | | | 436 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 437 | | | L1,O=0 | download 438 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 439 | | | | 440 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 441 | | | CC-ID=Y1,O=0,L2 | download 442 | | | CC-ID=Y2,O=1,L1 | CCI 443 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>| 444 | | | | 445 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 446 | | | L2,O=1 | download 447 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 448 | | | | 449 | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP 450 | | | | Update 451 | | | | 453 Figure 1: Basic PCECC LSP setup 455 The PCECC LSPs are considered to be 'up' by default (on receipt of 456 PCUpd message from PCE). The Ingress MAY further choose to deploy a 457 data plane check mechanism and report the status back to the PCE via 458 a PCRpt message to make sure that the correct label instructions are 459 made along the path of the PCECC LSP (and it is ready to carry 460 traffic). 462 In the case where the label allocations are made by the PCC itself 463 (see Section 5.5.8), the PCE could request an allocation to be made 464 by the PCC, and where the PCC would send a PCRpt with the allocated 465 label encoded in the CC-ID object as shown in Figure 2. 467 +-------+ +-------+ 468 |PCC | | PCE | 469 |Ingress| +-------+ 470 +------| | | 471 | PCC +-------+ | 472 | Transit| | | 473 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP 474 |PCC +--------+ | | 475 |Egress | | | | 476 +--------+ | | | 477 | | | | 478 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 479 | | | C=1 | download 480 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 481 | | | Label=L1 | 482 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 483 | | | CC-ID=Y1,C=1 | download 484 | | | CC-ID=Y2,C=0,L1 | CCI 485 | |----- PCRpt,PLSP-ID=1 ------------------>| 486 | | | CC-ID=Y1, Label=L2 | 487 | | | CC-ID=Y2 | 488 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 489 | | | C=0,L2 | download 490 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 491 | | | | 492 | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP 493 | | | | Update 494 | | | | 496 - The O bit is set as before (and thus not included) 498 Figure 2: Basic PCECC LSP setup (PCC allocation) 500 It should be noted that in this example, the request is made to the 501 egress node with the C bit set in the CCI object to indicate that the 502 label allocation needs to be done by the egress and the egress 503 responds with the allocated label to the PCE. The PCE would further 504 inform the transit PCC without setting the C bit in the CCI object 505 for out-label but the C-bit is set for in-label so the transit node 506 make the label allocation (for the in-label) and report to the PCE. 507 Similarly, the C bit is unset towards the ingress to complete all the 508 label allocation for the PCECC LSP. 510 5.5.2. Central Controller Instructions 512 The new central controller instructions (CCI) for the label 513 operations in PCEP is done via the PCInitiate message, by defining a 514 new PCEP Object for CCI operations. The local label range of each 515 PCC is assumed to be known at both the PCC and the PCE. 517 5.5.2.1. Label Download CCI 519 In order to set up an LSP based on PCECC, the PCE sends a PCInitiate 520 message to each node along the path to download the Label instruction 521 as described in Section 5.5.1. 523 The CCI object MUST be included, along with the LSP object in the 524 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in the 525 LSP object. The SPEAKER-ENTITY-ID TLV SHOULD be included in the LSP 526 object. 528 If a node (PCC) receives a PCInitiate message which includes a Label 529 to download as part of CCI, that is out of the range set aside for 530 the PCE, it MUST send a PCErr message with Error-type=TBD5 (PCECC 531 failure) and Error-value=TBD6 (Label out of range) and MUST include 532 the SRP object to specify the error is for the corresponding label 533 update via PCInitiate message. If a PCC receives a PCInitiate 534 message but failed to download the Label entry, it MUST send a PCErr 535 message with Error-type=TBD5 (PCECC failure) and Error-value=TBD7 536 (instruction failed) and MUST include the SRP object to specify the 537 error is for the corresponding label update via PCInitiate message. 539 A new PCEP object for central controller instructions (CCI) is 540 defined in Section 7.3. 542 5.5.2.2. Label Cleanup CCI 544 In order to delete an LSP based on PCECC, the PCE sends a central 545 controller instructions via a PCInitiate message to each node along 546 the path of the LSP to cleanup the Label forwarding instruction. 548 If the PCC receives a PCInitiate message but does not recognize the 549 label in the CCI, the PCC MUST generate a PCErr message with Error- 550 Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and 551 MUST include the SRP object to specify the error is for the 552 corresponding label cleanup (via PCInitiate message). 554 The R flag in the SRP object defined in [RFC8281] specifies the 555 deletion of Label Entry in the PCInitiate message. 557 +-------+ +-------+ 558 |PCC | | PCE | 559 |Ingress| +-------+ 560 +------| | | 561 | PCC +-------+ | 562 | Transit| | | 563 +------| | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1,R=1-->| PCECC LSP 564 |PCC +--------+ | | remove 565 |Egress | | | | 566 +--------+ | | | 567 | | | | 568 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 569 | | | R=1 | cleanup 570 |------- PCRpt,CC-ID=X,PLSP-ID=1 ------------------>| CCI 571 | | | | 572 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1 -- | Label 573 | | | R=1 | cleanup 574 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------->| CCI 575 | | | | 576 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 -- | Label 577 | | | R=1 | cleanup 578 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------->| CCI 579 | | | | 581 Figure 3: Label Cleanup 583 As per [RFC8281], following the removal of the Label forwarding 584 instruction, the PCC MUST send a PCRpt message. The SRP object in 585 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 586 that triggered the removal. The R flag in the SRP object MUST be 587 set. 589 In the case where the label allocation is made by the PCC itself (see 590 Section 5.5.8), the removal procedure remains the same. 592 5.5.3. PCE Initiated PCECC LSP 594 The LSP Instantiation operation is the same as defined in [RFC8281]. 596 In order to set up a PCE Initiated LSP based on the PCECC mechanism, 597 a PCE sends PCInitiate message with Path Setup Type set for PCECC 598 (see Section 7.2) to the Ingress PCC. 600 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 601 (Create) flag (see [RFC8281]) in the LSP object of PCRpt message. 602 The PCC responds with a PCRpt message with the status set to "GOING- 603 UP" and carrying the assigned PLSP-ID. 605 Note that the label forwarding instructions from PCECC are sent after 606 the initial PCInitiate and PCRpt exchange. This is done so that the 607 PLSP-ID and other LSP identifiers can be obtained from the ingress 608 and can be included in the label forwarding instruction in the next 609 PCInitiate message. The rest of the PCECC LSP setup operations are 610 the same as those described in Section 5.5.1. 612 The LSP deletion operation for PCE Initiated PCECC LSP is the same as 613 defined in [RFC8281]. The PCE should further perform Label entry 614 cleanup operation as described in Section 5.5.2.2 for the 615 corresponding LSP. 617 The PCE Initiated PCECC LSP setup sequence is shown in Figure 4. 619 +-------+ +-------+ 620 |PCC | | PCE | 621 |Ingress| +-------+ 622 +------| | | 623 | PCC +-------+ | 624 | Transit| | | 625 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP 626 |PCC +--------+ | | Initiate 627 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 628 +--------+ | | (GOING-UP) | 629 | | | | 630 |<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label 631 | | | | download 632 |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI 633 | | | | 634 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label 635 | | | | download 636 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI 637 | | | | 638 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label 639 | | | | download 640 | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI 641 | | | | 642 | | |<-- PCUpd, PLSP-ID=2, PST=TBD1, D=1-- | PCECC LSP 643 | | | (UP) | Update 644 | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | 645 | | | (UP) | 647 Figure 4: PCE Initiated PCECC LSP 649 Once the label operations are completed, the PCE SHOULD send a PCUpd 650 message to the Ingress PCC. The PCUpd message is as per [RFC8231]. 652 In the case where the label allocations are made by the PCC itself 653 (see Section 5.5.8), the procedure remains the same. 655 5.5.4. PCECC LSP Update 657 In case of a modification of a PCECC LSP with a new path, a PCE sends 658 a PCUpd message to the Ingress PCC. But to follow the make-before- 659 break procedures, the PCECC first update new instructions based on 660 the updated LSP and then update to ingress to switch traffic, before 661 cleaning up the old instructions. A new CC-ID is used to identify 662 the updated instruction, the existing identifiers in the LSP object 663 identify the existing LSP. Once new instructions are downloaded, the 664 PCE further updates the new path at the ingress which triggers the 665 traffic switch on the updated path. The Ingress PCC acknowledges 666 with a PCRpt message, on receipt of the PCRpt message, the PCE does 667 cleanup operation for the old LSP as described in Section 5.5.2.2. 669 The PCECC LSP Update sequence is shown in Figure 5. 671 +-------+ +-------+ 672 |PCC | | PCE | 673 |Ingress| +-------+ 674 +------| | | 675 | PCC +-------+ | 676 | Transit| | | 677 +------| | | | 678 |PCC +--------+ | | 679 |Egress | | | | 680 +--------+ | | | 681 | | | | New Path 682 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP 683 | | | | trigger 684 |------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI 685 | | | | 686 | |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label 687 | | | | download 688 | |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| CCI 689 | | | | 690 | | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label 691 | | | | download 692 | | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| CCI 693 | | | | 694 | | |<-- PCUpd, PLSP-ID=1, PST=TBD1, D=1- | PCECC 695 | | | SRP=S | LSP Update 696 | | | | 697 | | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1 -->| Trigger 698 | | | (SRP=S) | Delete old 699 | | | | CCI 700 | | | | 701 |<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label 702 | | | R=1 | cleanup 703 |------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| CCI 704 | | | | 705 | |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label 706 | | | R=1 | cleanup 707 | |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| CCI 708 | | | | 709 | | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label 710 | | | R=1 | cleanup 711 | | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| CCI 712 | | | | 714 Figure 5: PCECC LSP Update 716 The modified PCECC LSPs are considered to be 'up' by default. The 717 Ingress MAY further choose to deploy a data plane check mechanism and 718 report the status back to the PCE via a PCRpt message. 720 In the case where the label allocations are made by the PCC itself 721 (see Section 5.5.8), the procedure remains the same. 723 5.5.5. Re-Delegation and Cleanup 725 As described in [RFC8281], a new PCE can gain control over an 726 orphaned LSP. In the case of a PCECC LSP, the new PCE MUST also gain 727 control over the central controller instructions in the same way by 728 sending a PCInitiate message that includes the SRP, LSP, and CCI 729 objects and carries the CC-ID and PLSP-ID identifying the 730 instruction, it wants to take control of. 732 Further, as described in [RFC8281], the State Timeout Interval timer 733 ensures that a PCE crash does not result in automatic and immediate 734 disruption for the services using PCE-initiated LSPs. Similarly the 735 central controller instructions are not removed immediately upon PCE 736 failure. Instead, they are cleaned up on the expiration of this 737 timer. This allows for network cleanup without manual intervention. 738 The PCC MUST support the removal of CCI as one of the behaviors 739 applied on expiration of the State Timeout Interval timer. 741 5.5.6. Synchronization of Central Controllers Instructions 743 The purpose of Central Controllers Instructions synchronization 744 (labels in the context of this document) is to make sure that the 745 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 746 This synchronization is performed as part of the LSP state 747 synchronization as described in [RFC8231] and [RFC8233]. 749 As per LSP State Synchronization [RFC8231], a PCC reports the state 750 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 751 would initiate any missing LSPs and/or remove any LSPs that are not 752 wanted. The same PCEP messages and procedures are also used for the 753 Central Controllers Instructions synchronization. The PCRpt message 754 includes the CCI and the LSP object to report the label forwarding 755 instructions. The PCE would further remove any unwanted instructions 756 or initiate any missing instructions. 758 5.5.7. PCECC LSP State Report 760 As mentioned before, an Ingress PCC MAY choose to apply any OAM 761 mechanism to check the status of LSP in the Data plane and MAY 762 further send its status in a PCRpt message to the PCE. 764 5.5.8. PCC Based Allocations 766 The PCE can request the PCC to allocate the label using the 767 PCInitiate message. The C flag in the CCI object is set to 1 to 768 indicate that the allocation needs to be done by the PCC. The PCC 769 would allocate the Label and would report to the PCE using the PCRpt 770 message. 772 If the value of the Label is 0 and the C flag is set, it indicates 773 that the PCE is requesting the allocation to be done by the PCC. If 774 the Label is 'n' and the C flag is set in the CCI object, it 775 indicates that the PCE requests a specific value 'n' for the Label. 776 If the allocation is successful, the PCC should report via the PCRpt 777 message with the CCI object. Else, it MUST send a PCErr message with 778 Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 ("Invalid 779 CCI"). If the value of the Label in the CCI object is valid, but the 780 PCC is unable to allocate it, it MUST send a PCErr message with 781 Error-Type = TBD5 ("PCECC failure") and Error Value = TBD10 ("Unable 782 to allocate the specified CCI"). 784 If the PCC wishes to withdraw or modify the previously assigned 785 label, it MUST send a PCRpt message without any Label or with the 786 Label containing the new value respectively in the CCI object. The 787 PCE would further trigger the removal of the central controller 788 instruction as per this document. 790 5.5.9. Binding Label 792 As per [I-D.ietf-pce-binding-label-sid], when a stateful PCE is 793 deployed for setting up TE paths, it may be desirable to report the 794 binding label to the stateful PCE for the purpose of enforcing end- 795 to-end TE. In the case of the PCECC, the binding label may be 796 allocated by the PCE itself as described in this section. This 797 procedure is thus applicable for all path setup types including 798 PCECC. 800 A P flag in the LSP object is introduced in 801 [I-D.ietf-pce-sr-path-segment] to indicate the allocation needs to be 802 made by the PCE. This flag is used to indicate that the allocation 803 needs to be made by the PCE. A PCC would set this bit to 1 (and 804 carry the TE-PATH-BINDING TLV [I-D.ietf-pce-binding-label-sid] in the 805 LSP object) to request for allocation of the binding label by the PCE 806 in the PCReq or PCRpt message. A PCE would also set this bit to 1 to 807 indicate that the binding label is allocated by PCE and encoded in 808 the PCRep, PCUpd, or PCInitiate message (the TE-PATH-BINDING TLV is 809 present in LSP object). Further, a PCE would set this bit to 0 to 810 indicate that the allocation is done by the PCC instead. 812 The ingress PCC could request the binding label to be allocated by 813 the PCE via a PCRpt message as per [RFC8231]. The delegate flag 814 (D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST 815 be included with no Binding Value. The PCECC would allocate the 816 binding label and further respond to Ingress PCC with PCUpd message 817 as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in an LSP 818 object. The P flag in the LSP object would be set to 1 to indicate 819 that the allocation is made by the PCE. 821 The PCE could allocate the binding label on its own accord for a PCE- 822 Initiated (or delegated LSP). The allocated binding label needs to 823 be informed to the PCC. The PCE would use the PCInitiate message 824 [RFC8281] or PCUpd message [RFC8231] towards the PCC and MUST include 825 the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP 826 object would be set to 1 to indicate that the allocation is made by 827 the PCE. 829 Before a PCE can allocate a binding label the PCECC capability MUST 830 be exchanged on the PCEP session. Note that the CCI object is not 831 used for binding allocation; this is done to maintain consistency 832 with the rest of the binding label/SID procedures as per 833 [I-D.ietf-pce-binding-label-sid]. 835 6. PCEP messages 837 As defined in [RFC5440], a PCEP message consists of a common header 838 followed by a variable-length body made of a set of objects that can 839 be either mandatory or optional. An object is said to be mandatory 840 in a PCEP message when the object must be included for the message to 841 be considered valid. For each PCEP message type, a set of rules is 842 defined that specify the set of objects that the message can carry. 843 An implementation MUST form the PCEP messages using the object 844 ordering specified in this document. 846 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 848 The message formats in this document are specified using Routing 849 Backus-Naur Form (RBNF) encoding as specified in [RFC5511]. 851 6.1. The PCInitiate message 853 The PCInitiate message [RFC8281] can be used to download or remove 854 the labels, this document extends the message as shown below - 855 ::= 856 857 Where: 858 is defined in [RFC5440] 860 ::= 861 [] 863 ::= 864 (| 865 | 866 ) 868 ::= 869 870 872 ::= 873 [] 875 Where: 876 and 877 are as per 878 [RFC8281]. 880 The LSP and SRP object is defined in [RFC8231]. 882 When PCInitiate message is used for the central controller 883 instructions (labels), the SRP, LSP, and CCI objects MUST be present. 884 The SRP object is defined in [RFC8231] and if the SRP object is 885 missing, the receiving PCC MUST send a PCErr message with Error- 886 type=6 (Mandatory Object missing) and Error-value=10 (SRP object 887 missing). The LSP object is defined in [RFC8231] and if the LSP 888 object is missing, the receiving PCC MUST send a PCErr message with 889 Error-type=6 (Mandatory Object missing) and Error-value=8 (LSP object 890 missing). The CCI object is defined in Section 7.3 and if the CCI 891 object is missing, the receiving PCC MUST send a PCErr message with 892 Error-type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI 893 object missing). More than one CCI object MAY be included in the 894 PCInitiate message for the transit LSR. 896 To cleanup, the SRP object must set the R (remove) bit and include 897 the LSP and the CCI object. 899 The CCI object received at the Ingress node MUST have the O bit (out- 900 label) set. The CCI Object received at the egress MUST have the O 901 bit unset. If this is not the case, PCC MUST send a PCErr message 902 with Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 903 ("Invalid CCI"). Other instances of the CCI object if present, MUST 904 be ignored. 906 At most two instances of CCI object would be included in the case of 907 transit LSR to encode both in-coming and out-going label forwarding 908 instructions. Other instances MUST be ignored. If the transit LSR 909 did not receive two CCI object with one of them having the O bit set 910 and another with O bit unset, it MUST send a PCErr message with 911 Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 ("Invalid 912 CCI"). 914 6.2. The PCRpt message 916 The PCRpt message can be used to report the labels that were 917 allocated by the PCE, to be used during the state synchronization 918 phase. 920 ::= 921 922 Where: 924 ::= [] 926 ::= (| 927 ) 929 ::= [] 930 931 933 ::= [] 934 935 937 ::= 938 [] 940 Where: 941 is as per [RFC8231] and the LSP and SRP object are 942 also defined in [RFC8231]. 944 When PCRpt message is used to report the central controller 945 instructions (labels), the LSP and CCI objects MUST be present. The 946 LSP object is defined in [RFC8231] and if the LSP object is missing, 947 the receiving PCE MUST send a PCErr message with Error-type=6 948 (Mandatory Object missing) and Error-value=8 (LSP object missing). 950 The CCI object is defined in Section 7.3 and if the CCI object is 951 missing, the receiving PCC MUST send a PCErr message with Error- 952 type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI object 953 missing). Two CCI objects can be included in the PCRpt message for 954 the transit LSR. 956 7. PCEP Objects 958 The PCEP object defined in this document are compliant with the PCEP 959 object format defined in [RFC5440]. 961 7.1. OPEN Object 963 This document defines new optional TLVs for use in the OPEN Object. 965 7.1.1. PCECC Capability sub-TLV 967 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 968 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 969 CAPABILITY TLV. Advertisement of the PCECC capability implies 970 support of LSPs that are set up through PCECC as per PCEP extensions 971 defined in this document. 973 Its format is shown in Figure 6. 975 0 1 2 3 976 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Type=TBD12 | Length=4 | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Flags | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 Figure 6: PCECC Capability sub-TLV 985 The type of the TLV is TBD12 and it has a fixed length of 4 octets. 987 The value comprises a single field - Flags (32 bits). 989 No flags are defined in this document. 991 Unassigned bits MUST be set to 0 on transmission and MUST be ignored 992 on receipt. 994 7.2. PATH-SETUP-TYPE TLV 996 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document 997 defines a new PST value: 999 o PST = TBD1: Path is set up via PCECC mode. 1001 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in PATH-SETUP-TYPE 1002 TLV in SRP object indicates that this LSP was set up via a PCECC 1003 based mechanism. 1005 7.3. CCI Object 1007 The Central Controller Instructions (CCI) Object is used by the PCE 1008 to specify the forwarding instructions (Label information in the 1009 context of this document) to the PCC, and MAY be carried within 1010 PCInitiate or PCRpt message for label download. 1012 CCI Object-Class is TBD13. 1014 CCI Object-Type is 1 for the MPLS Label. 1016 0 1 2 3 1017 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | CC-ID | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Reserved | Flags |C|O| 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Label | Reserved | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | | 1026 // Optional TLV // 1027 | | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 Figure 7: CCI Object 1032 The fields in the CCI object are as follows: 1034 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 1035 creates a CC-ID for each instruction, the value is unique within 1036 the scope of the PCE and is constant for the lifetime of a PCEP 1037 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 1038 used. 1040 Flags: is used to carry any additional information pertaining to the 1041 CCI. Currently, the following flag bits are defined: 1043 * O bit(Out-label) : If the bit is set, it specifies the label is 1044 the OUT label and it is mandatory to encode the next-hop 1045 information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or 1046 UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit 1047 is not set, it specifies the label is the IN label and it is 1048 optional to encode the local interface information (via 1049 IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- 1050 ADDRESS TLV in the CCI object). 1052 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates 1053 that the allocation needs to be done by the PCC for this 1054 central controller instruction. A PCE sets this bit to request 1055 the PCC to make an allocation from its label space. A PCC 1056 would set this bit to indicate that it has allocated the CC-ID 1057 and report it to the PCE. 1059 * All unassigned bits MUST be set to zero at transmission and 1060 ignored at receipt. 1062 Label (20-bit): The Label information. 1064 Reserved (12 bit): Set to zero while sending, ignored on receive. 1066 7.3.1. Address TLVs 1068 This document defines the following TLVs for the CCI object to 1069 associate the next-hop information in the case of an outgoing label 1070 and local interface information in the case of an incoming label. 1072 IPV4-ADDRESS TLV: 1074 0 1 2 3 1075 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Type=TBD14 | Length = 4 | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | IPv4 address | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 IPV6-ADDRESS TLV: 1084 0 1 2 3 1085 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Type=TBD15 | Length = 16 | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | | 1090 // IPv6 address (16 bytes) // 1091 | | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 UNNUMBERED-IPV4-ID-ADDRESS TLV: 1096 0 1 2 3 1097 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Type=TBD16 | Length = 8 | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Node-ID | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Interface ID | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 LINKLOCAL-IPV6-ID-ADDRESS TLV: 1108 0 1 2 3 1109 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Type=TBD17 | Length = 40 | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 // Local IPv6 address (16 octets) // 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Local Interface ID | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 // Remote IPv6 address (16 octets) // 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Remote Interface ID | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 Figure 8: Address TLVs 1124 The address TLVs are as follows: 1126 IPV4-ADDRESS TLV: an IPv4 address. 1128 IPV6-ADDRESS TLV: an IPv6 address. 1130 UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple. 1132 LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address, 1133 interface ID) tuples. 1135 8. Implementation Status 1137 [Note to the RFC Editor - remove this section before publication, as 1138 well as remove the reference to RFC 7942.] 1140 This section records the status of known implementations of the 1141 protocol defined by this specification at the time of posting of this 1142 Internet-Draft, and is based on a proposal described in [RFC7942]. 1143 The description of implementations in this section is intended to 1144 assist the IETF in its decision processes in progressing drafts to 1145 RFCs. Please note that the listing of any individual implementation 1146 here does not imply endorsement by the IETF. Furthermore, no effort 1147 has been spent to verify the information presented here that was 1148 supplied by IETF contributors. This is not intended as, and must not 1149 be construed to be, a catalog of available implementations or their 1150 features. Readers are advised to note that other implementations may 1151 exist. 1153 According to [RFC7942], "this will allow reviewers and working groups 1154 to assign due consideration to documents that have the benefit of 1155 running code, which may serve as evidence of valuable experimentation 1156 and feedback that have made the implemented protocols more mature. 1157 It is up to the individual working groups to use this information as 1158 they see fit". 1160 8.1. Huawei's Proof of Concept based on ONOS 1162 The PCE function was developed in the ONOS open source platform. 1163 This extension was implemented on a private version as a proof of 1164 concept for PCECC. 1166 o Organization: Huawei 1168 o Implementation: Huawei's PoC based on ONOS 1170 o Description: PCEP as a southbound plugin was added to ONOS. To 1171 support PCECC, an earlier version of this I-D was implemented. 1172 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 1174 o Maturity Level: Prototype 1176 o Coverage: Partial 1178 o Contact: satishk@huawei.com 1180 9. Security Considerations 1182 The security considerations described in [RFC8231] and [RFC8281] 1183 apply to the extensions described in this document. Additional 1184 considerations related to a malicious PCE are introduced. 1186 9.1. Malicious PCE 1188 PCE has complete control over PCC to update the labels and can cause 1189 the LSP's to behave inappropriately and cause major impact to the 1190 network. As a general precaution, it is RECOMMENDED that this PCEP 1191 extension be activated on authenticated and encrypted sessions across 1192 PCEs and PCCs belonging to the same administrative authority, using 1193 Transport Layer Security (TLS) [RFC8253], as per the recommendations 1194 and best current practices in [RFC7525]. 1196 10. Manageability Considerations 1198 10.1. Control of Function and Policy 1200 A PCE or PCC implementation SHOULD allow to configure to enable/ 1201 disable PCECC capability as a global configuration. 1203 10.2. Information and Data Models 1205 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1206 PCECC capability status. 1208 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1209 enable/disable PCECC capability. 1211 10.3. Liveness Detection and Monitoring 1213 Mechanisms defined in this document do not imply any new liveness 1214 detection and monitoring requirements in addition to those already 1215 listed in [RFC5440]. 1217 10.4. Verify Correct Operations 1219 Mechanisms defined in this document do not imply any new operation 1220 verification requirements in addition to those already listed in 1221 [RFC5440] and [RFC8231]. 1223 10.5. Requirements On Other Protocols 1225 PCEP extensions defined in this document do not put new requirements 1226 on other protocols. 1228 10.6. Impact On Network Operations 1230 PCEP extensions defined in this document do not put new requirements 1231 on network operations. 1233 11. IANA Considerations 1235 11.1. PCEP TLV Type Indicators 1237 IANA is requested to allocate the following TLV Type Indicator values 1238 within the "PCEP TLV Type Indicators" sub- registry of the PCEP 1239 Numbers registry: 1241 Value Meaning Reference 1242 TBD14 IPV4-ADDRESS TLV This document 1243 TBD15 IPV6-ADDRESS TLV This document 1244 TBD16 UNNUMBERED-IPV4-ID-ADDRESS TLV This document 1245 TBD17 LINKLOCAL-IPV6-ID-ADDRESS TLV This document 1247 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 1249 [RFC8408] requested the creation of "PATH-SETUP- TYPE-CAPABILITY Sub- 1250 TLV Type Indicators" sub-registry. Further IANA is requested to 1251 allocate the following code-point: 1253 Value Meaning Reference 1254 TBD12 PCECC-CAPABILITY This document 1256 11.3. PCECC-CAPABILITY sub-TLV's Flag field 1258 This document defines the PCECC-CAPABILITY sub-TLV and requests that 1259 IANA to create a new sub-registry to manage the value of the PCECC- 1260 CAPABILITY sub-TLV's 32-bits Flag field. New values are to be 1261 assigned by Standards Action [RFC8126]. Each bit should be tracked 1262 with the following qualities: 1264 o Bit number (counting from bit 0 as the most significant bit) 1266 o Capability description 1268 o Defining RFC 1270 Currently, there are no allocations in this registry. 1272 Bit Name Reference 1273 0-31 Unassigned This document 1275 11.4. Path Setup Type Registry 1277 [RFC8408] created a sub-registry within the "Path Computation Element 1278 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1279 IANA is requested to allocate a new code point within this registry, 1280 as follows: 1282 Value Description Reference 1283 TBD1 Traffic engineering path is This document 1284 set up using PCECC mode 1286 11.5. PCEP Object 1288 IANA is requested to allocate new code-point in the "PCEP Objects" 1289 sub-registry for the CCI object as follows: 1291 Object-Class Value Name Reference 1292 TBD13 CCI Object-Type This document 1293 0 Reserved 1294 1 MPLS Label 1296 11.6. CCI Object Flag Field 1298 IANA is requested to create a new sub-registry to manage the Flag 1299 field of the CCI object called "CCI Object 16-bits Flag Field". New 1300 values are to be assigned by Standards Action [RFC8126]. Each bit 1301 should be tracked with the following qualities: 1303 o Bit number (counting from bit 0 as the most significant bit) 1305 o Capability description 1307 o Defining RFC 1309 Two bits to be defined for the CCI Object flag field in this document 1310 as follows: 1312 Bit Description Reference 1313 0-13 Unassigned This document 1314 14 C Bit - PCC allocation This document 1315 15 O Bit - Specifies label This document 1316 is out-label 1318 11.7. PCEP-Error Object 1320 IANA is requested to allocate new error types and error values within 1321 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1322 PCEP Numbers registry for the following errors: 1324 Error-Type Meaning 1325 ---------- ------- 1326 6 Mandatory Object missing. 1328 Error-value = TBD11 : CCI object missing 1329 10 Reception of an invalid object. 1331 Error-value = TBD2 : Missing PCECC 1332 Capability sub-TLV 1333 19 Invalid operation. 1335 Error-value = TBD3 : Attempted PCECC 1336 operations when 1337 PCECC capability 1338 was not advertised 1339 Error-value = TBD4 : Stateful PCE 1340 capability was not 1341 advertised 1342 Error-value = TBD8 : Unknown Label 1343 TBD5 PCECC failure. 1345 Error-value = TBD6 : Label out of range. 1346 Error-value = TBD7 : Instruction failed. 1347 Error-value = TBD9 : Invalid CCI. 1348 Error-value = TBD10 : Unable to allocate 1349 the specified CCI. 1351 12. Acknowledgments 1353 We would like to thank Robert Tao, Changjing Yan, Tieying Huang, 1354 Avantika, and Aijun Wang for their useful comments and suggestions. 1356 13. References 1358 13.1. Normative References 1360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1361 Requirement Levels", BCP 14, RFC 2119, 1362 DOI 10.17487/RFC2119, March 1997, 1363 . 1365 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1366 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1367 DOI 10.17487/RFC5440, March 2009, 1368 . 1370 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1371 Used to Form Encoding Rules in Various Routing Protocol 1372 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1373 2009, . 1375 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1376 Hardwick, "Path Computation Element Communication Protocol 1377 (PCEP) Management Information Base (MIB) Module", 1378 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1379 . 1381 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1382 "Recommendations for Secure Use of Transport Layer 1383 Security (TLS) and Datagram Transport Layer Security 1384 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1385 2015, . 1387 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1388 Writing an IANA Considerations Section in RFCs", BCP 26, 1389 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1390 . 1392 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1393 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1394 May 2017, . 1396 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1397 Computation Element Communication Protocol (PCEP) 1398 Extensions for Stateful PCE", RFC 8231, 1399 DOI 10.17487/RFC8231, September 2017, 1400 . 1402 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1403 "Extensions to the Path Computation Element Communication 1404 Protocol (PCEP) to Compute Service-Aware Label Switched 1405 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1406 2017, . 1408 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1409 Computation Element Communication Protocol (PCEP) 1410 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1411 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1412 . 1414 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1415 Hardwick, "Conveying Path Setup Type in PCE Communication 1416 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1417 July 2018, . 1419 13.2. Informative References 1421 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1422 Element (PCE)-Based Architecture", RFC 4655, 1423 DOI 10.17487/RFC4655, August 2006, 1424 . 1426 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1427 Margaria, "Requirements for GMPLS Applications of PCE", 1428 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1429 . 1431 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1432 Computation Element Architecture", RFC 7399, 1433 DOI 10.17487/RFC7399, October 2014, 1434 . 1436 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1437 Application-Based Network Operations", RFC 7491, 1438 DOI 10.17487/RFC7491, March 2015, 1439 . 1441 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1442 Code: The Implementation Status Section", BCP 205, 1443 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1444 . 1446 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1447 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1448 Path Computation Element Communication Protocol (PCEP)", 1449 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1450 . 1452 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1453 Architecture for Use of PCE and the PCE Communication 1454 Protocol (PCEP) in a Network with Central Control", 1455 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1456 . 1458 [I-D.ietf-teas-pcecc-use-cases] 1459 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 1460 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1461 Gulida, "The Use Cases for Path Computation Element (PCE) 1462 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1463 use-cases-05 (work in progress), March 2020. 1465 [I-D.ietf-pce-pcep-yang] 1466 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1467 YANG Data Model for Path Computation Element 1468 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1469 yang-14 (work in progress), July 2020. 1471 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 1472 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 1473 Procedures and Protocol Extensions for Using PCE as a 1474 Central Controller (PCECC) of SR-LSPs", draft-zhao-pce- 1475 pcep-extension-pce-controller-sr-07 (work in progress), 1476 July 2020. 1478 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 1479 Li, Z., Peng, S., Geng, X., and M. Negi, "PCEP Procedures 1480 and Protocol Extensions for Using PCE as a Central 1481 Controller (PCECC) for SRv6", draft-dhody-pce-pcep- 1482 extension-pce-controller-srv6-04 (work in progress), July 1483 2020. 1485 [I-D.li-pce-controlled-id-space] 1486 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 1487 Controlled ID Space", draft-li-pce-controlled-id-space-06 1488 (work in progress), July 2020. 1490 [I-D.ietf-pce-binding-label-sid] 1491 Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., 1492 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1493 in PCE-based Networks.", draft-ietf-pce-binding-label- 1494 sid-03 (work in progress), June 2020. 1496 [I-D.ietf-pce-sr-path-segment] 1497 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 1498 "Path Computation Element Communication Protocol (PCEP) 1499 Extension for Path Segment in Segment Routing (SR)", 1500 draft-ietf-pce-sr-path-segment-01 (work in progress), May 1501 2020. 1503 Appendix A. Contributor Addresses 1505 Dhruv Dhody 1506 Huawei Technologies 1507 Divyashree Techno Park, Whitefield 1508 Bangalore, Karnataka 560066 1509 India 1511 EMail: dhruv.ietf@gmail.com 1513 Satish Karunanithi 1514 Huawei Technologies 1515 Divyashree Techno Park, Whitefield 1516 Bangalore, Karnataka 560066 1517 India 1519 EMail: satishk@huawei.com 1521 Adrian Farrel 1522 Old Dog Consulting 1523 UK 1525 EMail: adrian@olddog.co.uk 1527 Xuesong Geng 1528 Huawei Technologies 1529 China 1531 Email: gengxuesong@huawei.com 1533 Udayasree Palle 1535 EMail: udayasreereddy@gmail.com 1537 Katherine Zhao 1538 Futurewei Technologies 1540 EMail: katherine.zhao@futurewei.com 1542 Boris Zhang 1543 Telus Ltd. 1544 Toronto 1545 Canada 1547 EMail: boris.zhang@telus.com 1549 Alex Tokar 1550 Cisco Systems 1551 Slovak Republic 1553 EMail: atokar@cisco.com 1555 Authors' Addresses 1557 Zhenbin Li 1558 Huawei Technologies 1559 Huawei Bld., No.156 Beiqing Rd. 1560 Beijing 100095 1561 China 1563 EMail: lizhenbin@huawei.com 1565 Shuping Peng 1566 Huawei Technologies 1567 Huawei Bld., No.156 Beiqing Rd. 1568 Beijing 100095 1569 China 1571 EMail: pengshuping@huawei.com 1573 Mahendra Singh Negi 1574 RtBrick India 1575 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 1576 Bangalore, Karnataka 560102 1577 India 1579 EMail: mahend.ietf@gmail.com 1581 Quintin Zhao 1582 Etheric Networks 1583 1009 S CLAREMONT ST 1584 SAN MATEO, CA 94402 1585 USA 1587 EMail: qzhao@ethericnetworks.com 1589 Chao Zhou 1590 HPE 1592 EMail: chaozhou_us@yahoo.com