idnits 2.17.1 draft-ietf-pce-pcep-extension-for-pce-controller-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2020) is 1402 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-13 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-06 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Zhao 3 Internet-Draft Z. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: December 23, 2020 M. Negi 6 RtBrick India 7 S. Peng 8 Huawei Technologies 9 C. Zhou 10 Cisco Systems 11 June 21, 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-05 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 (G)MPLS traffic-engineered (TE) 28 networks, and the PCE may be used to determine paths in a range of 29 use cases. PCEP has been proposed as a control protocol for use in 30 these environments to allow the PCE to be fully enabled as a central 31 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 protocol extensions 42 for using 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 December 23, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 Setup . . . . . . . . . . . . . . . . 8 91 5.5.2. Central Control 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 105 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 22 106 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 22 107 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 22 108 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 23 109 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 24 110 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 111 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 26 112 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 113 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . 27 121 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 122 11.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 123 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 28 124 11.3. New Path Setup Type Registry . . . . . . . . . . . . . . 28 125 11.4. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 28 126 11.5. CCI Object Flag Field . . . . . . . . . . . . . . . . . 28 127 11.6. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 29 128 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 129 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 130 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 131 13.2. Informative References . . . . . . . . . . . . . . . . . 31 132 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 33 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 135 1. Introduction 137 The Path Computation Element (PCE) [RFC4655] was developed to offload 138 path computation function from routers in an MPLS traffic-engineered 139 network. Since then, the role and function of the PCE has grown to 140 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 141 delegated control [RFC8231] and PCE-initiated use of network 142 resources [RFC8281]. 144 According to [RFC7399], Software-Defined Networking (SDN) refers to a 145 separation between the control elements and the forwarding components 146 so that software running in a centralized system, called a 147 controller, can act to program the devices in the network to behave 148 in specific ways. A required element in an SDN architecture is a 149 component that plans how the network resources will be used and how 150 the devices will be programmed. It is possible to view this 151 component as performing specific computations to place traffic flows 152 within the network given knowledge of the availability of network 153 resources, how other forwarding devices are programmed, and the way 154 that other flows are routed. This is the function and purpose of a 155 PCE, and the way that a PCE integrates into a wider network control 156 system (including an SDN system) is presented in [RFC7491]. 158 In early PCE implementations, where the PCE was used to derive paths 159 for MPLS Label Switched Paths (LSPs), paths were requested by network 160 elements (known as Path Computation Clients (PCCs)), and the results 161 of the path computations were supplied to network elements using the 162 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 163 This protocol was later extended to allow a PCE to send unsolicited 164 requests to the network for LSP establishment [RFC8281]. 166 [RFC8283] introduces the architecture for PCE as a central controller 167 as an extension of the architecture described in [RFC4655] and 168 assumes the continued use of PCEP as the protocol used between PCE 169 and PCC. [RFC8283] further examines the motivations and 170 applicability for PCEP as a Southbound Interface (SBI), and 171 introduces the implications for the protocol. 172 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 173 architecture. 175 A PCE-based central controller (PCECC) can simplify the processing of 176 a distributed control plane by blending it with elements of SDN and 177 without necessarily completely replacing it. Thus, the LSP can be 178 calculated/setup/initiated and the label forwarding entries can also 179 be downloaded through a centralized PCE server to each network 180 devices along the path while leveraging the existing PCE technologies 181 as much as possible. 183 This draft specify the procedures and PCEP protocol extensions for 184 using the PCE as the central controller for static LSPs, where LSPs 185 can be provisioned as explicit label instructions at each hop on the 186 end-to-end path. Each router along the path must be told what label- 187 forwarding instructions to program and what resources to reserve. 188 The PCE-based controller keeps a view of the network and determines 189 the paths of the end-to-end LSPs, and the controller uses PCEP to 190 communicate with each router along the path of the end-to-end LSP. 192 The extension for PCECC in Segment Routing (SR) is specified in a 193 separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 195 1.1. Requirements Language 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in BCP 200 14 [RFC2119] [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 2. Terminology 205 Terminologies used in this document is same as described in the draft 206 [RFC8283]. 208 3. Basic PCECC Mode 210 In this mode LSPs are provisioned as explicit label instructions at 211 each hop on the end-to-end path. Each router along the path must be 212 told what label forwarding instructions to program and what resources 213 to reserve. The controller uses PCEP to communicate with each router 214 along the path of the end-to-end LSP. 216 Note that the PCE-based controller will take responsibility for 217 managing some part of the MPLS label space for each of the routers 218 that it controls, and may take wider responsibility for partitioning 219 the label space for each router and allocating different parts for 220 different uses. This is also described in section 3.1.2. of 221 [RFC8283]. For the purpose of this document, it is assumed that 222 label range to be used by a PCE is known and set on both PCEP peers. 223 A future extension could add this capability to advertise the range 224 via possible PCEP extensions as well (see 225 [I-D.li-pce-controlled-id-space]). The rest of processing is similar 226 to the existing stateful PCE mechanism. 228 This document also allow a case where the label space is maintained 229 by PCC itself, and the labels are allocated by the PCC, in this case, 230 the PCE should request the allocation from PCC as described in 231 Section 5.5.8. 233 4. PCEP Requirements 235 Following key requirements associated PCECC should be considered when 236 designing the PCECC based solution: 238 1. PCEP speaker supporting this draft needs to have the capability 239 to advertise its PCECC capability to its peers. 241 2. PCEP speaker needs a means to identify PCECC based LSP in the 242 PCEP messages. 244 3. PCEP procedures needs to allow for PCC based label allocations. 246 4. PCEP procedures needs to provide a means to update (or cleanup) 247 the label-download entry to the PCC. 249 5. PCEP procedures needs to provide a means to synchronize the 250 labels between PCE to PCC in PCEP messages. 252 5. Procedures for Using the PCE as the Central Controller (PCECC) 254 5.1. Stateful PCE Model 256 Active stateful PCE is described in [RFC8231]. PCE as a central 257 controller (PCECC) reuses existing Active stateful PCE mechanism as 258 much as possible to control the LSP. 260 5.2. New LSP Functions 262 Several new functions are required in PCEP to support PCECC. This 263 document extends the existing messages to support the new functions 264 required by PCECC: 266 (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate 267 message is used to setup PCE-Initiated LSP based on PCECC 268 mechanism. It is also extended for Central Controller's 269 Instructions (CCI) (download or cleanup the Label forwarding 270 instructions in the context of this document) on all nodes along 271 the path. 273 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is 274 used to send PCECC LSP Reports. It is also extended to report the 275 set of Central Controller's Instructions (CCI) (label forwarding 276 instructions in the context of this document) received from the 277 PCE. See Section 5.5.6 for more details. 279 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 280 used to send PCECC LSP Update. 282 The new functions defined in this document are mapped onto the PCEP 283 messages as shown in the following table. 285 +----------------------------------------+--------------------------+ 286 | Function | Message | 287 +----------------------------------------+--------------------------+ 288 | PCECC Capability advertisement | Open | 289 | Label entry Add | PCInitiate | 290 | Label entry Cleanup | PCInitiate | 291 | PCECC Initiated LSP | PCInitiate | 292 | PCECC LSP Update | PCUpd | 293 | PCECC LSP State Report | PCRpt | 294 | PCECC LSP Delegation | PCRpt | 295 | PCECC Label Report | PCRpt | 296 +----------------------------------------+--------------------------+ 298 5.3. New PCEP Object 300 This document specify a new PCEP object called CCI (see Section 7.3) 301 for the encoding of central controller's instructions. In the scope 302 of this document this is limited to Label forwarding instructions. 303 Future documents can create new CCI object-type for other types of 304 central control instructions. The CC-ID is the unique identifier for 305 the central controller's instructions in PCEP. The PCEP messages are 306 extended in this document to handle the PCECC operations. 308 5.4. PCECC Capability Advertisement 310 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 311 advertise their support of PCECC extensions. 313 This document defines a new Path Setup Type (PST) [RFC8408] for 314 PCECC, as follows: 316 o PST = TBD1: Path is setup via PCECC mode. 318 A PCEP speaker MUST indicate its support of the function described in 319 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 320 object with this new PST included in the PST list. 322 This document also defines the PCECC Capability sub-TLV 323 Section 7.1.1. PCEP speakers use this sub-TLV to exchange 324 information about their PCECC capability. If a PCEP speaker includes 325 PST=TBD1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then 326 it MUST also include the PCECC Capability sub-TLV inside the PATH- 327 SETUP-TYPE-CAPABILITY TLV. If the sub-TLV is absent, then the PCEP 328 speaker MUST send a PCErr message with Error-Type 10 (Reception of an 329 invalid object) and Error-Value TBD2 (Missing PCECC Capability sub- 330 TLV) and MUST then close the PCEP session. If a PCEP speaker 331 receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PCECC-CAPABILITY 332 sub-TLV, but the PST list does not contain PST=TBD1, then the PCEP 333 speaker MUST ignore the PCECC-CAPABILITY sub-TLV. 335 The presence of the PST=TBD1 and PCECC Capability sub-TLV in PCC's 336 OPEN Object indicates that the PCC is willing to function as a PCECC 337 client. The presence of the PST=TBD1 and PCECC Capability sub-TLV in 338 PCE's OPEN message indicates that the PCE is interested in function 339 as a PCECC server. 341 The PCEP protocol extensions for PCECC MUST NOT be used if one or 342 both PCEP Speakers have not included the PST=TBD1 or the PCECC 343 Capability sub-TLV in their respective OPEN message. If the PCEP 344 Speakers support the extensions of this draft but did not advertise 345 this capability attempts a PCECC operation then a PCErr message with 346 Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted 347 PCECC operations when PCECC capability was not advertised) will be 348 generated and the PCEP session will be terminated. 350 A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and 351 STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with I flag set [RFC8281]) 352 in OPEN Object to support the extensions defined in this document. 353 If PCECC-CAPABILITY sub-TLV is advertised and STATEFUL-PCE-CAPABILITY 354 TLV is not advertised in OPEN Object, it MUST send a PCErr message 355 with Error-Type=19 (Invalid Operation) and Error-value=TBD4 (stateful 356 PCE capability was not advertised) and terminate the session. This 357 error is also triggered if PCECC-CAPABILITY sub-TLV is advertised and 358 I flag in the STATEFUL-PCE-CAPABILITY TLV is not set. 360 5.5. LSP Operations 362 The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE 363 TLV [RFC8408] in the SRP object to clearly identify the PCECC LSP is 364 intended. 366 5.5.1. Basic PCECC LSP Setup 368 In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate 369 the LSP by sending a PCRpt message with PST set for PCECC (see 370 Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the LSP 371 object. 373 LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the tuple uniquely 374 identifies the LSP in the network. The LSP object is included in 375 central controller's instructions (label download) to identify the 376 PCECC LSP for this instruction. The PLSP-ID is the original 377 identifier used by the ingress PCC, so the transit LSR could have 378 multiple central controller instructions that have the same PLSP-ID. 379 The PLSP-ID in combination with the source (in LSP-IDENTIFIER TLV) 380 MUST be unique. The PLSP-ID is included for maintainability reasons 381 to ease debugging. As per [RFC8281], the LSP object could include 382 SPEAKER-ENTITY-ID TLV to identify the PCE that initiated these 383 instructions. Also the CC-ID is unique on the PCEP session as 384 described in Section 7.3. 386 When a PCE receives PCRpt message with D flags and PST Type set, it 387 calculates the path and assigns labels along the path; and set up the 388 path by sending PCInitiate message to each node along the path of the 389 LSP. The PCC generates a Path Computation State Report (PCRpt) and 390 include the central controller's instruction (CCI) and the identified 391 LSP. The CC-ID is uniquely identify the central controller's 392 instruction within a PCEP session. The PCC further responds with the 393 PCRpt messages including the CCI and LSP objects. 395 The Ingress node would receive one CCI object with O bit (out-label) 396 set. The transit node(s) would receive two CCI object with the in- 397 label CCI without O bit set and the out-label CCI with O bit set. 398 The egress node would receive one CCI object without O bit set. A 399 node can determine its role based on the setting of the O bit in the 400 CCI object(s). 402 Once the central controller's instructions (label operations) are 403 completed, the PCE MUST send the PCUpd message to the Ingress PCC. 404 This PCUpd message is as per [RFC8231] SHOULD include the path 405 information as calculated by the PCE. 407 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 409 LSP deletion operation for PCECC LSP is same as defined in [RFC8231]. 410 If the PCE receives PCRpt message for LSP deletion then it does Label 411 cleanup operation as described in Section 5.5.2.2 for the 412 corresponding LSP. 414 The Basic PCECC LSP setup sequence is as shown below. 416 +-------+ +-------+ 417 |PCC | | PCE | 418 |Ingress| +-------+ 419 +------| | | 420 | PCC +-------+ | 421 | Transit| | | 422 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP 423 |PCC +--------+ | | 424 |Egress | | | | 425 +--------+ | | | 426 | | | | 427 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 428 | | | L1,O=0 | download 429 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 430 | | | | 431 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 432 | | | CC-ID=Y1,O=0,L2 | download 433 | | | CC-ID=Y2,O=1,L1 | CCI 434 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>| 435 | | | | 436 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 437 | | | L2,O=1 | download 438 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 439 | | | | 440 | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP 441 | | | | Update 442 | | | | 444 Figure 2: Basic PCECC LSP setup 446 The PCECC LSP are considered to be 'up' by default (on receipt of 447 PCUpd message from PCE). The Ingress MAY further choose to deploy a 448 data plane check mechanism and report the status back to the PCE via 449 PCRpt message. 451 In case where the label allocation are made by the PCC itself (see 452 Section 5.5.8), the PCE could request an allocation to be made by the 453 PCC, and where the PCC would send a PCRpt with the allocated label 454 encoded in the CC-ID object as shown below - 455 +-------+ +-------+ 456 |PCC | | PCE | 457 |Ingress| +-------+ 458 +------| | | 459 | PCC +-------+ | 460 | Transit| | | 461 +------| | |-- PCRpt,PLSP-ID=1, PST=TBD1, D=1--->| PCECC LSP 462 |PCC +--------+ | | 463 |Egress | | | | 464 +--------+ | | | 465 | | | | 466 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 467 | | | C=1 | download 468 |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI 469 | | | Label=L1 | 470 | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels 471 | | | CC-ID=Y1,C=1 | download 472 | | | CC-ID=Y2,C=0,L1 | CCI 473 | |----- PCRpt,PLSP-ID=1 ------------------>| 474 | | | CC-ID=Y1, Label=L2 | 475 | | | CC-ID=Y2 | 476 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label 477 | | | C=0,L2 | download 478 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI 479 | | | | 480 | | |<-- PCUpd,PLSP-ID=1,PST=TBD1, D=1----| PCECC LSP 481 | | | | Update 482 | | | | 484 - The O bit is set as before (and thus not included) 486 Figure 3: Basic PCECC LSP setup (PCC allocation) 488 It should be noted that in this example, the request is made to the 489 egress node with C bit set in the CCI object to indicate that the 490 label allocation needs to be done by the egress and it responds with 491 the allocated label to the PCE. The PCE would further inform the 492 transit PCC without setting the C bit in the CCI object for out-label 493 but the C-bit is set for in-label so the transit node make the label 494 allocation (for the in-label) and report to the PCE. Similarly C bit 495 is unset towards the ingress to complete all the label allocation for 496 the PCECC LSP. 498 5.5.2. Central Control Instructions 500 The new central controller's instructions (CCI) for the label 501 operations in PCEP is done via the PCInitiate message, by defining a 502 new PCEP Objects for CCI operations. Local label range of each PCC 503 is assumed to be known at both the PCC and the PCE. 505 5.5.2.1. Label Download CCI 507 In order to setup an LSP based on PCECC, the PCE sends a PCInitiate 508 message to each node along the path to download the Label instruction 509 as described in Section 5.5.1. 511 The CCI object MUST be included, along with the LSP object in the 512 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in LSP 513 object. The SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object. 515 If a node (PCC) receives a PCInitiate message which includes a Label 516 to download as part of CCI, that is out of the range set aside for 517 the PCE, it MUST send a PCErr message with Error-type=TBD5 (PCECC 518 failure) and Error-value=TBD6 (Label out of range) and MUST include 519 the SRP object to specify the error is for the corresponding label 520 update via PCInitiate message. If a PCC receives a PCInitiate 521 message but failed to download the Label entry, it MUST send a PCErr 522 message with Error-type=TBD5 (PCECC failure) and Error-value=TBD7 523 (instruction failed) and MUST include the SRP object to specify the 524 error is for the corresponding label update via PCInitiate message. 526 New PCEP object for central control instructions (CCI) is defined in 527 Section 7.3. 529 5.5.2.2. Label Cleanup CCI 531 In order to delete an LSP based on PCECC, the PCE sends a central 532 controller instructions via a PCInitiate message to each node along 533 the path of the LSP to cleanup the Label forwarding instruction. 535 If the PCC receives a PCInitiate message but does not recognize the 536 label in the CCI, the PCC MUST generate a PCErr message with Error- 537 Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and 538 MUST include the SRP object to specify the error is for the 539 corresponding label cleanup (via PCInitiate message). 541 The R flag in the SRP object defined in [RFC8281] specifies the 542 deletion of Label Entry in the PCInitiate message. 544 +-------+ +-------+ 545 |PCC | | PCE | 546 |Ingress| +-------+ 547 +------| | | 548 | PCC +-------+ | 549 | Transit| | | 550 +------| | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1,R=1-->| PCECC LSP 551 |PCC +--------+ | | remove 552 |Egress | | | | 553 +--------+ | | | 554 | | | | 555 |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label 556 | | | R=1 | cleanup 557 |------- PCRpt,CC-ID=X,PLSP-ID=1 ------------------>| CCI 558 | | | | 559 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1 -- | Label 560 | | | R=1 | cleanup 561 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------->| CCI 562 | | | | 563 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 -- | Label 564 | | | R=1 | cleanup 565 | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------->| CCI 566 | | | | 568 As per [RFC8281], following the removal of the Label forwarding 569 instruction, the PCC MUST send a PCRpt message. The SRP object in 570 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 571 that triggered the removal. The R flag in the SRP object MUST be 572 set. 574 In case where the label allocation are made by the PCC itself (see 575 Section 5.5.8), the removal procedure remains the same. 577 5.5.3. PCE Initiated PCECC LSP 579 The LSP Instantiation operation is same as defined in [RFC8281]. 581 In order to setup a PCE Initiated LSP based on the PCECC mechanism, a 582 PCE sends PCInitiate message with Path Setup Type set for PCECC (see 583 Section 7.2) to the Ingress PCC. 585 The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 586 (Create) flag (see [RFC8281]) in LSP object of PCRpt message. The 587 PCC responds with first PCRpt message with the status as "GOING-UP" 588 and assigned PLSP-ID. 590 Note that the label forwarding instructions from PCECC are send after 591 the initial PCInitiate and PCRpt exchange. This is done so that the 592 PLSP-ID and other LSP identifiers can be obtained from the ingress 593 and can be included in the label forwarding instruction in the next 594 PCInitiate message. The rest of the PCECC LSP setup operations are 595 same as those described in Section 5.5.1. 597 The LSP deletion operation for PCE Initiated PCECC LSP is same as 598 defined in [RFC8281]. The PCE should further perform Label entry 599 cleanup operation as described in Section 5.5.2.2 for the 600 corresponding LSP. 602 The PCE Initiated PCECC LSP setup sequence is shown below - 604 +-------+ +-------+ 605 |PCC | | PCE | 606 |Ingress| +-------+ 607 +------| | | 608 | PCC +-------+ | 609 | Transit| | | 610 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP 611 |PCC +--------+ | | Initiate 612 |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP 613 +--------+ | | (GOING-UP) | 614 | | | | 615 |<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label 616 | | | | download 617 |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI 618 | | | | 619 | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label 620 | | | | download 621 | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI 622 | | | | 623 | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label 624 | | | | download 625 | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI 626 | | | | 627 | | |<-- PCUpd, PLSP-ID=2, PST=TBD1, D=1-- | PCECC LSP 628 | | | (UP) | Update 629 | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | 630 | | | (UP) | 632 Once the label operations are completed, the PCE SHOULD send the 633 PCUpd message to the Ingress PCC. The PCUpd message is as per 634 [RFC8231]. 636 In case where the label allocation are made by the PCC itself (see 637 Section 5.5.8), the procedure remains similar. 639 5.5.4. PCECC LSP Update 641 In case of a modification of PCECC LSP with a new path, a PCE sends a 642 PCUpd message to the Ingress PCC. But to follow the make-before- 643 break procedures, the PCECC first update new instructions based on 644 the updated LSP and then update to ingress to switch traffic, before 645 cleaning up the old instructions. A new CC-ID is used to identify 646 the updated instruction, the existing identifiers in the LSP object 647 identify the existing LSP. Once new instructions are downloaded, the 648 PCE further updates the new path at the ingress which triggers the 649 traffic switch on the updated path. The Ingress PCC acknowledges 650 with a PCRpt message, on receipt of PCRpt message, the PCE does 651 cleanup operation for the old LSP as described in Section 5.5.2.2. 653 The PCECC LSP Update sequence is shown below - 654 +-------+ +-------+ 655 |PCC | | PCE | 656 |Ingress| +-------+ 657 +------| | | 658 | PCC +-------+ | 659 | Transit| | | 660 +------| | | | 661 |PCC +--------+ | | 662 |Egress | | | | 663 +--------+ | | | 664 | | | | New Path 665 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP 666 | | | | trigger 667 |------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI 668 | | | | 669 | |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label 670 | | | | download 671 | |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| CCI 672 | | | | 673 | | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label 674 | | | | download 675 | | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| CCI 676 | | | | 677 | | |<-- PCUpd, PLSP-ID=1, PST=TBD1, D=1- | PCECC 678 | | | SRP=S | LSP Update 679 | | | | 680 | | |-- PCRpt,PLSP-ID=1,PST=TBD1,D=1 -->| Trigger 681 | | | (SRP=S) | Delete old 682 | | | | CCI 683 | | | | 684 |<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label 685 | | | R=1 | cleanup 686 |------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| CCI 687 | | | | 688 | |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label 689 | | | R=1 | cleanup 690 | |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| CCI 691 | | | | 692 | | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label 693 | | | R=1 | cleanup 694 | | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| CCI 695 | | | | 697 The modified PCECC LSP are considered to be 'up' by default. The 698 Ingress MAY further choose to deploy a data plane check mechanism and 699 report the status back to the PCE via PCRpt message. 701 In case where the label allocation are made by the PCC itself (see 702 Section 5.5.8), the procedure remains similar. 704 5.5.5. Re Delegation and Cleanup 706 As described in [RFC8281], a new PCE can gain control over the 707 orphaned LSP. In case of PCECC LSP, the new PCE MUST also gain 708 control over the central controllers instructions in the same way by 709 sending a PCInitiate message that includes the SRP, LSP and CCI 710 objects and carries the CC-ID and PLSP-ID identifying the 711 instruction, it wants to take control of. 713 Further, as described in [RFC8281], the State Timeout Interval timer 714 ensures that a PCE crash does not result in automatic and immediate 715 disruption for the services using PCE-initiated LSPs. Similarly the 716 central controller instructions are not removed immediately upon PCE 717 failure. Instead, they are cleaned up on the expiration of this 718 timer. This allows for network cleanup without manual intervention. 719 The PCC MUST support removal of CCI as one of the behaviors applied 720 on expiration of the State Timeout Interval timer. 722 5.5.6. Synchronization of Central Controllers Instructions 724 The purpose of Central Controllers Instructions synchronization 725 (labels in the context of this document) is to make sure that the 726 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 727 This synchronization is performed as part of the LSP state 728 synchronization as described in [RFC8231] and [RFC8233]. 730 As per LSP State Synchronization [RFC8231], a PCC reports the state 731 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 732 would initiate any missing LSPs and/or remove any LSPs that are not 733 wanted. The same PCEP messages and procedure is also used for the 734 Central Controllers Instructions synchronization. The PCRpt message 735 includes the CCI and the LSP object to report the label forwarding 736 instructions. The PCE would further remove any unwanted instructions 737 or initiate any missing instructions. 739 5.5.7. PCECC LSP State Report 741 As mentioned before, an Ingress PCC MAY choose to apply any OAM 742 mechanism to check the status of LSP in the Data plane and MAY 743 further send its status in PCRpt message to the PCE. 745 5.5.8. PCC Based Allocations 747 The PCE can request the PCC to allocate the label using the 748 PCInitiate message. The C flag in the CCI object is set to 1 to 749 indicate that the allocation needs to be done by the PCC. The PCC 750 would allocate the Label and would report to the PCE using the PCRpt 751 message. 753 If the value of the Label is 0 and the C flag is set, it indicates 754 that the PCE is requesting the allocation to be done by the PCC. If 755 the Label is 'n' and the C flag is set in the CCI object, it 756 indicates that the PCE requests a specific value 'n' for the Label. 757 If the allocation is successful, the PCC should report via PCRpt 758 message with the CCI object. Else, it MUST send a PCErr message with 759 Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 ("Invalid 760 CCI"). If the value of the the Label in the CCI object is valid, but 761 the PCC is unable to allocate it, it MUST send a PCErr message with 762 Error-Type = TBD5 ("PCECC failure") and Error Value = TBD10 ("Unable 763 to allocate the specified CCI"). 765 If the PCC wishes to withdraw or modify the previously assigned 766 label, it MUST send a PCRpt message without any Label or with the 767 Label containing the new value respectively in the CCI object. The 768 PCE would further trigger the removal of the central controller 769 instruction as per this document. 771 5.5.9. Binding Label 773 As per [I-D.sivabalan-pce-binding-label-sid], when a stateful PCE is 774 deployed for setting up TE paths, it may be desirable to report the 775 binding label to the stateful PCE for the purpose of enforcing end- 776 to-end TE. In case of PCECC, the binding label may be allocated by 777 the PCE itself as described in this section. This procedure is thus 778 applicable for all path setup types including PCECC. 780 A P flag in LSP object is introduced in [I-D.li-pce-sr-path-segment] 781 to indicate the allocation needs to be made by the PCE. This flag is 782 used to indicate that the allocation needs to be made by the PCE. A 783 PCC would set this bit to 1 (and carry the TE-PATH-BINDING TLV 784 [I-D.sivabalan-pce-binding-label-sid] in LSP object) to request for 785 allocation of the binding label by the PCE in the PCReq or PCRpt 786 message. A PCE would also set this bit to 1 to indicate that the 787 binding label is allocated by PCE and encoded in the PCRep, PCUpd or 788 PCInitiate message (the TE-PATH-BINDING TLV is present in LSP 789 object). Further, a PCE would set this bit to 0 to indicate that the 790 allocation is done by the PCC instead. 792 The ingress PCC could request the binding label to be allocated by 793 the PCE via PCRpt message as per [RFC8231]. The delegate flag 794 (D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST 795 be included with no Binding Value. The PCECC would allocate the 796 binding label and further respond to Ingress PCC with PCUpd message 797 as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in a LSP 798 object. The P flag in the LSP object would be set to 1 to indicate 799 that the allocation is made by the PCE. 801 The PCE could allocate the binding label on its own accord for a PCE- 802 Initiated (or delegated LSP). The allocated binding label needs to 803 be informed to the PCC. The PCE would use the PCInitiate message 804 [RFC8281] or PCUpd message [RFC8231] towards the PCC and MUST include 805 the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP 806 object would be set to 1 to indicate that the allocation is made by 807 the PCE. 809 The PCECC capability MUST be exchanged on the PCEP session, before 810 PCE could allocate binding label. Note that the CCI object is not 811 used for binding allocation; this is done to maintain consistency 812 with the rest of the binding label/SID procedures as per 813 [I-D.sivabalan-pce-binding-label-sid]. 815 6. PCEP messages 817 As defined in [RFC5440], a PCEP message consists of a common header 818 followed by a variable-length body made of a set of objects that can 819 be either mandatory or optional. An object is said to be mandatory 820 in a PCEP message when the object must be included for the message to 821 be considered valid. For each PCEP message type, a set of rules is 822 defined that specify the set of objects that the message can carry. 823 An implementation MUST form the PCEP messages using the object 824 ordering specified in this document. 826 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 828 6.1. The PCInitiate message 830 The PCInitiate message [RFC8281] can be used to download or remove 831 the labels, the message has been extended as shown below - 832 ::= 833 834 Where: 835 is defined in [RFC5440] 837 ::= 838 [] 840 ::= 841 (| 842 | 843 ) 845 ::= 846 847 849 ::= 850 [] 852 Where: 853 and 854 are as per 855 [RFC8281]. 857 The LSP and SRP object is defined in [RFC8231]. 859 When PCInitiate message is used for central controller's instructions 860 (labels), the SRP, LSP and CCI objects MUST be present. The SRP 861 object is defined in [RFC8231] and if the SRP object is missing, the 862 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 863 Object missing) and Error-value=10 (SRP object missing). The LSP 864 object is defined in [RFC8231] and if the LSP object is missing, the 865 receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory 866 Object missing) and Error-value=8 (LSP object missing). The CCI 867 object is defined in Section 7.3 and if the CCI object is missing, 868 the receiving PCC MUST send a PCErr message with Error-type=6 869 (Mandatory Object missing) and Error-value=TBD11 (CCI object 870 missing). More than one CCI object MAY be included in the PCInitiate 871 message for the transit LSR. 873 To cleanup the SRP object must set the R (remove) bit and include the 874 LSP and the CCI object. 876 At max two instances of CCI object would be included in case of 877 transit LSR to encode both in-coming and out-going label forwarding 878 instructions. Other instances MUST be ignored. 880 6.2. The PCRpt message 882 The PCRpt message can be used to report the labels that were 883 allocated by the PCE, to be used during the state synchronization 884 phase. 886 ::= 887 888 Where: 890 ::= [] 892 ::= (| 893 ) 895 ::= [] 896 897 899 ::= [] 900 901 903 ::= 904 [] 906 Where: 907 is as per [RFC8231] and the LSP and SRP object are 908 also defined in [RFC8231]. 910 When PCRpt message is used to report the central controller's 911 instructions (labels), the LSP and CCI objects MUST be present. The 912 LSP object is defined in [RFC8231] and if the LSP object is missing, 913 the receiving PCE MUST send a PCErr message with Error-type=6 914 (Mandatory Object missing) and Error-value=8 (LSP object missing). 915 The CCI object is defined in Section 7.3 and if the CCI object is 916 missing, the receiving PCC MUST send a PCErr message with Error- 917 type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI object 918 missing). Two CCI object can be included in the PCRpt message for 919 the transit LSR. 921 7. PCEP Objects 923 The PCEP objects defined in this document are compliant with the PCEP 924 object format defined in [RFC5440]. 926 7.1. OPEN Object 928 This document defines a new optional TLVs for use in the OPEN Object. 930 7.1.1. PCECC Capability sub-TLV 932 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 933 Object for PCECC capability advertisement in PATH-SETUP-TYPE- 934 CAPABILITY TLV. Advertisement of the PCECC capability implies 935 support of LSPs that are setup through PCECC as per PCEP extensions 936 defined in this document. 938 Its format is shown in the following figure: 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Type=TBD12 | Length=4 | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Flags | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 The type of the TLV is TBD12 and it has a fixed length of 4 octets. 950 The value comprises a single field - Flags (32 bits). 952 No flags are assigned right now. 954 Unassigned bits are considered reserved. They MUST be set to 0 on 955 transmission and MUST be ignored on receipt. 957 7.2. PATH-SETUP-TYPE TLV 959 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document 960 defines a new PST value: 962 o PST = TBD1: Path is setup via PCECC mode. 964 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in PATH-SETUP-TYPE 965 TLV in SRP object indicates that this LSP was setup via a PCECC based 966 mechanism. 968 7.3. CCI Object 970 The Central Control Instructions (CCI) Object is used by the PCE to 971 specify the forwarding instructions (Label information in the context 972 of this document) to the PCC, and MAY be carried within PCInitiate or 973 PCRpt message for label download. 975 CCI Object-Class is TBD13. 977 CCI Object-Type is 1 for the MPLS Label. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | CC-ID | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Reserved | Flags |C|O| 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Label | Reserved | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | | 989 // Optional TLV // 990 | | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 The fields in the CCI object are as follows: 995 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 996 creates an CC-ID for each instruction, the value is unique within 997 the scope of the PCE and is constant for the lifetime of a PCEP 998 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 999 used. 1001 Flags: is used to carry any additional information pertaining to the 1002 CCI. Currently, the following flag bit is defined: 1004 * O bit(Out-label) : If the bit is set, it specifies the label is 1005 the OUT label and it is mandatory to encode the next-hop 1006 information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or 1007 UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit 1008 is not set, it specifies the label is the IN label and it is 1009 optional to encode the local interface information (via 1010 IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- 1011 ADDRESS TLV in the CCI object). 1013 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates 1014 that the allocation needs to be done by the PCC for this 1015 central controller instruction. A PCE set this bit to request 1016 the PCC to make an allocation from its label space. A PCC 1017 would set this bit to indicate that it has allocated the CC-ID 1018 and report it to the PCE. 1020 Label (20-bit): The Label information. 1022 Reserved (12 bit): Set to zero while sending, ignored on receive. 1024 7.3.1. Address TLVs 1026 This document defines the following TLVs for the CCI object to 1027 associate the next-hop information in case of an outgoing label and 1028 local interface information in case of an incoming label. 1030 IPV4-ADDRESS TLV: 1032 0 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Type=TBD14 | Length = 4 | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | IPv4 address | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 IPV6-ADDRESS TLV: 1042 0 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Type=TBD15 | Length = 16 | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | | 1048 // IPv6 address (16 bytes) // 1049 | | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 UNNUMBERED-IPV4-ID-ADDRESS TLV: 1054 0 1 2 3 1055 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 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Type=TBD16 | Length = 8 | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Node-ID | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Interface ID | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 LINKLOCAL-IPV6-ID-ADDRESS TLV: 1066 0 1 2 3 1067 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 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Type=TBD17 | Length = 40 | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 // Local IPv6 address (16 octets) // 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Local Interface ID | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 // Remote IPv6 address (16 octets) // 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Remote Interface ID | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 The address TLVs are as follows: 1082 IPV4-ADDRESS TLV: an IPv4 address. 1084 IPV6-ADDRESS TLV: an IPv6 address. 1086 UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple. 1088 LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address, 1089 interface ID) tuples. 1091 8. Implementation Status 1093 [Note to the RFC Editor - remove this section before publication, as 1094 well as remove the reference to RFC 7942.] 1096 This section records the status of known implementations of the 1097 protocol defined by this specification at the time of posting of this 1098 Internet-Draft, and is based on a proposal described in [RFC7942]. 1099 The description of implementations in this section is intended to 1100 assist the IETF in its decision processes in progressing drafts to 1101 RFCs. Please note that the listing of any individual implementation 1102 here does not imply endorsement by the IETF. Furthermore, no effort 1103 has been spent to verify the information presented here that was 1104 supplied by IETF contributors. This is not intended as, and must not 1105 be construed to be, a catalog of available implementations or their 1106 features. Readers are advised to note that other implementations may 1107 exist. 1109 According to [RFC7942], "this will allow reviewers and working groups 1110 to assign due consideration to documents that have the benefit of 1111 running code, which may serve as evidence of valuable experimentation 1112 and feedback that have made the implemented protocols more mature. 1113 It is up to the individual working groups to use this information as 1114 they see fit". 1116 8.1. Huawei's Proof of Concept based on ONOS 1118 The PCE function was developed in the ONOS open source platform. 1119 This extension was implemented on a private version as a proof of 1120 concept for PCECC. 1122 o Organization: Huawei 1124 o Implementation: Huawei's PoC based on ONOS 1126 o Description: PCEP as a southbound plugin was added to ONOS. To 1127 support PCECC, an earlier version of this I-D was implemented. 1128 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 1130 o Maturity Level: Prototype 1132 o Coverage: Partial 1134 o Contact: satishk@huawei.com 1136 9. Security Considerations 1138 The security considerations described in [RFC8231] and [RFC8281] 1139 apply to the extensions described in this document. Additional 1140 considerations related to a malicious PCE are introduced. 1142 9.1. Malicious PCE 1144 PCE has complete control over PCC to update the labels and can cause 1145 the LSP's to behave inappropriate and cause major impact to the 1146 network. As a general precaution, it is RECOMMENDED that these PCEP 1147 extensions only be activated on authenticated and encrypted sessions 1148 across PCEs and PCCs belonging to the same administrative authority, 1149 using Transport Layer Security (TLS) [RFC8253], as per the 1150 recommendations and best current practices in [RFC7525]. 1152 10. Manageability Considerations 1154 10.1. Control of Function and Policy 1156 A PCE or PCC implementation SHOULD allow to configure to enable/ 1157 disable PCECC capability as a global configuration. 1159 10.2. Information and Data Models 1161 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1162 PCECC capability status. 1164 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1165 enable/disable PCECC capability. 1167 10.3. Liveness Detection and Monitoring 1169 Mechanisms defined in this document do not imply any new liveness 1170 detection and monitoring requirements in addition to those already 1171 listed in [RFC5440]. 1173 10.4. Verify Correct Operations 1175 Mechanisms defined in this document do not imply any new operation 1176 verification requirements in addition to those already listed in 1177 [RFC5440] and [RFC8231]. 1179 10.5. Requirements On Other Protocols 1181 PCEP extensions defined in this document do not put new requirements 1182 on other protocols. 1184 10.6. Impact On Network Operations 1186 PCEP extensions defined in this document do not put new requirements 1187 on network operations. 1189 11. IANA Considerations 1191 11.1. PCEP TLV Type Indicators 1193 IANA is requested to allocate the following TLV Type Indicator values 1194 within the "PCEP TLV Type Indicators" sub- registry of the PCEP 1195 Numbers registry: 1197 Value Meaning Reference 1198 TBD14 IPV4-ADDRESS TLV This document 1199 TBD15 IPV6-ADDRESS TLV This document 1200 TBD16 UNNUMBERED-IPV4-ID-ADDRESS TLV This document 1201 TBD17 LINKLOCAL-IPV6-ID-ADDRESS TLV This document 1203 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 1205 [RFC8408] requested creation of "PATH-SETUP- TYPE-CAPABILITY Sub-TLV 1206 Type Indicators" sub-registry. Further IANA is requested to allocate 1207 the following code-point: 1209 Value Meaning Reference 1210 TBD12 PCECC-CAPABILITY This document 1212 11.3. New Path Setup Type Registry 1214 [RFC8408] created a sub-registry within the "Path Computation Element 1215 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1216 IANA is requested to allocate a new code point within this registry, 1217 as follows: 1219 Value Description Reference 1220 TBD1 Traffic engineering path is This document 1221 setup using PCECC mode 1223 11.4. PCEP Object 1225 IANA is requested to allocate new code-point in the "PCEP Objects" 1226 sub-registry for the CCI object as follows: 1228 Object-Class Value Name Reference 1229 TBD13 CCI Object-Type This document 1230 0 Reserved 1231 1 MPLS Label 1233 11.5. CCI Object Flag Field 1235 IANA is requested to create a new sub-registry to manage the Flag 1236 field of the CCI object called "CCI Object Flag Field". New values 1237 are to be assigned by Standards Action [RFC8126]. Each bit should be 1238 tracked with the following qualities: 1240 o Bit number (counting from bit 0 as the most significant bit) 1242 o Capability description 1244 o Defining RFC 1245 Two bits to be defined for the CCI Object flag field in this document 1246 as follows: 1248 Bit Description Reference 1249 0-13 Unassigned This document 1250 14 C Bit - PCC allocation This document 1251 15 O Bit - Specifies label This document 1252 is out-label 1254 11.6. PCEP-Error Object 1256 IANA is requested to allocate new error types and error values within 1257 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1258 PCEP Numbers registry for the following errors: 1260 Error-Type Meaning 1261 ---------- ------- 1262 10 Reception of an invalid object. 1264 Error-value = TBD2 : Missing PCECC 1265 Capability sub-TLV 1266 19 Invalid operation. 1268 Error-value = TBD3 : Attempted PCECC 1269 operations when 1270 PCECC capability 1271 was not advertised 1272 Error-value = TBD4 : Stateful PCE 1273 capability was not 1274 advertised 1275 Error-value = TBD8 : Unknown Label 1276 6 Mandatory Object missing. 1278 Error-value = TBD11 : CCI object missing 1279 TBD5 PCECC failure. 1281 Error-value = TBD6 : Label out of range. 1282 Error-value = TBD7 : Instruction failed. 1283 Error-value = TBD9 : Invalid CCI. 1284 Error-value = TBD10 : Unable to allocate 1285 the specified CCI. 1287 12. Acknowledgments 1289 We would like to thank Robert Tao, Changjing Yan, Tieying Huang and 1290 Avantika for their useful comments and suggestions. 1292 13. References 1294 13.1. Normative References 1296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1297 Requirement Levels", BCP 14, RFC 2119, 1298 DOI 10.17487/RFC2119, March 1997, 1299 . 1301 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1302 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1303 DOI 10.17487/RFC5440, March 2009, 1304 . 1306 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1307 Hardwick, "Path Computation Element Communication Protocol 1308 (PCEP) Management Information Base (MIB) Module", 1309 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1310 . 1312 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1313 "Recommendations for Secure Use of Transport Layer 1314 Security (TLS) and Datagram Transport Layer Security 1315 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1316 2015, . 1318 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1319 Writing an IANA Considerations Section in RFCs", BCP 26, 1320 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1321 . 1323 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1324 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1325 May 2017, . 1327 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1328 Computation Element Communication Protocol (PCEP) 1329 Extensions for Stateful PCE", RFC 8231, 1330 DOI 10.17487/RFC8231, September 2017, 1331 . 1333 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 1334 "Extensions to the Path Computation Element Communication 1335 Protocol (PCEP) to Compute Service-Aware Label Switched 1336 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 1337 2017, . 1339 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1340 Computation Element Communication Protocol (PCEP) 1341 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1342 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1343 . 1345 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1346 Hardwick, "Conveying Path Setup Type in PCE Communication 1347 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1348 July 2018, . 1350 13.2. Informative References 1352 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1353 Element (PCE)-Based Architecture", RFC 4655, 1354 DOI 10.17487/RFC4655, August 2006, 1355 . 1357 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1358 Margaria, "Requirements for GMPLS Applications of PCE", 1359 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1360 . 1362 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1363 Computation Element Architecture", RFC 7399, 1364 DOI 10.17487/RFC7399, October 2014, 1365 . 1367 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1368 Application-Based Network Operations", RFC 7491, 1369 DOI 10.17487/RFC7491, March 2015, 1370 . 1372 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1373 Code: The Implementation Status Section", BCP 205, 1374 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1375 . 1377 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1378 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1379 Path Computation Element Communication Protocol (PCEP)", 1380 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1381 . 1383 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1384 Architecture for Use of PCE and the PCE Communication 1385 Protocol (PCEP) in a Network with Central Control", 1386 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1387 . 1389 [I-D.ietf-teas-pcecc-use-cases] 1390 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 1391 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1392 Gulida, "The Use Cases for Path Computation Element (PCE) 1393 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1394 use-cases-05 (work in progress), March 2020. 1396 [I-D.ietf-pce-pcep-yang] 1397 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1398 YANG Data Model for Path Computation Element 1399 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1400 yang-13 (work in progress), October 2019. 1402 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 1403 Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP 1404 Procedures and Protocol Extensions for Using PCE as a 1405 Central Controller (PCECC) of SR-LSPs", draft-zhao-pce- 1406 pcep-extension-pce-controller-sr-06 (work in progress), 1407 March 2020. 1409 [I-D.li-pce-controlled-id-space] 1410 Li, C., Chen, M., Dong, J., Li, Z., Wang, A., Cheng, W., 1411 and C. Zhou, "PCE Controlled ID Space", draft-li-pce- 1412 controlled-id-space-04 (work in progress), January 2020. 1414 [I-D.sivabalan-pce-binding-label-sid] 1415 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1416 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1417 in PCE-based Networks.", draft-sivabalan-pce-binding- 1418 label-sid-07 (work in progress), July 2019. 1420 [I-D.li-pce-sr-path-segment] 1421 Li, C., Chen, M., Cheng, W., Dong, J., Li, Z., Gandhi, R., 1422 and Q. Xiong, "Path Computation Element Communication 1423 Protocol (PCEP) Extension for Path Segment in Segment 1424 Routing (SR)", draft-li-pce-sr-path-segment-08 (work in 1425 progress), August 2019. 1427 Appendix A. Contributor Addresses 1429 Dhruv Dhody 1430 Huawei Technologies 1431 Divyashree Techno Park, Whitefield 1432 Bangalore, Karnataka 560066 1433 India 1435 EMail: dhruv.ietf@gmail.com 1437 Satish Karunanithi 1438 Huawei Technologies 1439 Divyashree Techno Park, Whitefield 1440 Bangalore, Karnataka 560066 1441 India 1443 EMail: satishk@huawei.com 1445 Adrian Farrel 1446 Juniper Networks, Inc 1447 UK 1449 EMail: adrian@olddog.co.uk 1451 Xuesong Geng 1452 Huawei Technologies 1453 China 1455 Email: gengxuesong@huawei.com 1457 Udayasree Palle 1459 EMail: udayasreereddy@gmail.com 1461 Katherine Zhao 1462 Futurewei Technologies 1464 EMail: katherine.zhao@futurewei.com 1466 Boris Zhang 1467 Telus Ltd. 1468 Toronto 1469 Canada 1471 EMail: boris.zhang@telus.com 1473 Alex Tokar 1474 Cisco Systems 1475 Slovak Republic 1477 EMail: atokar@cisco.com 1479 Authors' Addresses 1481 Quintin Zhao 1482 Huawei Technologies 1483 125 Nagog Technology Park 1484 Acton, MA 01719 1485 USA 1487 EMail: quintin.zhao@huawei.com 1489 Zhenbin Li 1490 Huawei Technologies 1491 Huawei Bld., No.156 Beiqing Rd. 1492 Beijing 100095 1493 China 1495 EMail: lizhenbin@huawei.com 1497 Mahendra Singh Negi 1498 RtBrick India 1499 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 1500 Bangalore, Karnataka 560102 1501 India 1503 EMail: mahend.ietf@gmail.com 1505 Shuping Peng 1506 Huawei Technologies 1507 Huawei Bld., No.156 Beiqing Rd. 1508 Beijing 100095 1509 China 1511 EMail: pengshuping@huawei.com 1513 Chao Zhou 1514 Cisco Systems 1516 EMail: chao.zhou@cisco.com