idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-15.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 54 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 24, 2021) is 1035 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Y. Lee (Editor) 2 Internet-Draft Samsung 3 Intended status: Standards Track H. Zheng (Editor) 4 Expires: December 24, 2021 Huawei 5 O. G. de Dios 6 V. Lopez 7 Telefonica 8 Z. Ali 9 Cisco Systems 10 June 24, 2021 12 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 13 Usage in GMPLS-controlled Networks 15 draft-ietf-pce-pcep-stateful-pce-gmpls-15 17 Abstract 19 The Path Computation Element (PCE) facilitates Traffic Engineering 20 (TE) based path calculation in large, multi-domain, multi-region, or 21 multi-layer networks. The PCE communication Protocol (PCEP) has been 22 extended to support stateful PCE functions where the PCE retains 23 information about the paths already present in the network, but 24 those extensions are technology-agnostic. This memo provides 25 extensions required for PCEP so as to enable the usage of a stateful 26 PCE capability in GMPLS-controlled networks. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with 31 the provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. The list of current Internet-Drafts is at 37 https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on December 24, 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. Code Components extracted from this 62 document must include Simplified BSD License text as described in 63 Section 4.e of the Trust Legal Provisions and are provided without 64 warranty as described in the Simplified BSD License. 66 Table of Contents 68 Table of Contents .............................................. 2 69 1. Introduction ................................................ 3 70 2. Conventions used in this document ........................... 4 71 3. General Context of Stateful PCE and PCEP for GMPLS .......... 4 72 4. Main Requirements ........................................... 5 73 5. Overview of PCEP Extensions for GMPLS Networks .............. 6 74 5.1. Capability Advertisement for Stateful PCEP in GMPLS .... 6 75 5.2. LSP Synchronization .................................... 6 76 5.3. LSP Delegation and Cleanup ............................. 7 77 5.4. LSP Operations ......................................... 7 78 6. Extension of Existing PCEP Messages ......................... 7 79 6.1. The PCRpt Message ...................................... 7 80 6.2. The PCUpd Message ...................................... 8 81 6.3. The PCInitiate Message ................................. 9 82 7. PCEP Object Extensions ..................................... 10 83 7.1. Existing Extensions used for Stateful GMPLS ........... 10 84 7.2. New Extensions ........................................ 11 85 7.2.1. OPEN Object Extension GMPLS-CAPABILITY TLV ....... 11 86 7.2.2. XRO Subobject .................................... 12 87 7.2.3. SRP Extension .................................... 13 89 8. Update to Error Handling ................................... 13 90 8.1. Error Handling in LSP Re-optimization ................. 13 91 8.2. Error Handling in Route Exclusion ..................... 13 92 8.3. Error Handling for generalized END-POINTS ............. 14 93 9. Implementation ............................................. 14 94 9.1. Huawei Technologies ................................... 14 95 10. IANA Considerations........................................ 15 96 10.1. New GMPLS-CAPABILITY ................................. 15 97 10.2. New Subobject for the Exclude Route Object ........... 15 98 10.3. New "B" Flag in the SRP Object ....................... 15 99 10.4. New PCEP Error Codes ................................. 16 100 11. Manageability Considerations .............................. 16 101 11.1. Requirements on Other Protocols ...................... 16 102 12. Security Considerations ................................... 16 103 13. Acknowledgement ........................................... 17 104 14. References ................................................ 17 105 14.1. Normative References ................................. 17 106 14.2. Informative References ............................... 18 107 15. Contributors' Address ..................................... 19 108 Authors' Addresses ............................................ 20 110 1. Introduction 112 [RFC4655] presents the architecture of a Path Computation Element 113 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 114 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 115 Paths (TE LSPs). To perform such a constrained computation, a PCE 116 stores the network topology (i.e., TE links and nodes) and resource 117 information (i.e., TE attributes) in its TE Database (TED). Such a 118 PCE is usually referred as a stateless PCE. To request path 119 computation services to a PCE, [RFC5440] defines the PCE 120 communication Protocol (PCEP) for interaction between a Path 121 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 122 specified in [RFC5440] mainly focuses on MPLS networks and the PCEP 123 extensions needed for GMPLS-controlled networks are provided in 124 [RFC8779]. 126 Stateful PCEs are shown to be helpful in many application scenarios, 127 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. 128 Further discussion of concept of a stateful PCE can be found in 129 [RFC7399]. In order for these applications to able to exploit the 130 capability of stateful PCEs, extensions to PCEP are required. 132 [RFC8051] describes how a stateful PCE can be applicable to solve 133 various problems for MPLS-TE and GMPLS networks and the benefits it 134 brings to such deployments. 136 [RFC8231] provides the fundamental extensions needed for stateful 137 PCE to support general functionality. Furthermore, [RFC8281] 138 describes the setup and teardown of PCE-initiated LSPs under the 139 active stateful PCE model, without the need for local configuration 140 on the PCC. However, both the documents left out the specification 141 for technology-specific objects/TLVs, and does not cover the GMPLS 142 networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies). This 143 document focuses on the extensions that are necessary in order for 144 the deployment of stateful PCEs and the requirements for remote- 145 initiated LSPs in GMPLS-controlled networks. Section 3 provides 146 General context of Stateful PCE and PCEP for GMPLS are provided in 147 Section 3, and PCE initiation requirement for GMPLS is provided in 148 section 4. Protocol extensions is included in section 5, as a 149 solution to address such requirements. 151 2. Conventions used in this document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in 156 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 3. General Context of Stateful PCE and PCEP for GMPLS 161 This section is built on the basis of Stateful PCE in [RFC8231] and 162 PCEP for GMPLS in [RFC8779]. 164 The operation for Stateful PCE on LSPs can be divided into two types, 165 active stateful PCE and passive stateful PCE. 167 For active stateful PCE, PCUpd message is sent from PCE to PCC to 168 update the LSP state for the LSP delegated to PCE. Any changes to 169 the delegated LSPs generate a PCRpt message by the PCC to PCE to 170 convey the changes of the LSP. Any modifications to the Objects/TLVs 171 that are identified in this document to support GMPLS technology- 172 specific attributes will be carried in the PCRpt and PCUpd messages. 174 For passive stateful PCEs, PCReq/PCRep messages are used to convey 175 path computation instructions. GMPLS-technology specific Objects 176 and TLVs are defined in [RFC8779], so this document just points at 177 that work and only adds the stateful PCE aspects where applicable. 178 Passive Stateful PCE makes use of PCRpt messages when reporting LSP 179 State changes sent by PCC to PCEs. Any modifications to the 180 Objects/TLVs that are identified in this document to support GMPLS 181 technology-specific attributes will be carried in the PCRpt message. 183 Furthermore, the Initiation of PCEP are defined in [RFC8281] to 184 allow the PCE to initiate the LSP establishment after the path is 185 computed. PCInitiate messages are used to trigger the end node to 186 set up the LSP. Any modifications to the Objects/TLVs that are 187 identified in this document to support GMPLS technology-specific 188 attributes will be carried in the PCInitiate messages. 190 [RFC8779] defines GMPLS-technology specific Objects/TLVs in 191 stateless PCEP, and this document makes use of these Objects/TLVs 192 without modifications where applicable. Some of these Objects/TLVs 193 may require modifications to incorporate stateful PCE where 194 applicable. The remote-initiated LSP would follow the principle 195 specified in [RFC8281], and GMPLS-specific extensions are also 196 included in this document. 198 4. Main Requirements 200 This section notes the main functional requirements for PCEP 201 extensions to support stateful PCE for use in GMPLS-controlled 202 networks, based on the description in [RFC8051]. Many 203 requirements are common across a variety of network types (e.g., 204 MPLS-TE networks and GMPLS networks) and the protocol extensions to 205 meet the requirements are already described in [RFC8231]. This 206 document does not repeat the description of those protocol 207 extensions. This document presents protocol extensions for a set of 208 requirements which are specific to the use of a stateful PCE in a 209 GMPLS-controlled network. 211 The requirements for GMPLS-specific stateful PCE are as follows: 213 o Advertisement of the stateful PCE capability. This generic 214 requirement is covered in Section 5.4 of [RFC8231]. The GMPLS 215 CAPABILITY TLV in section 2.1 of [RFC8779] and its extension in 216 this document MUST be advertised as well. 218 o LSP operations, including LSP update, delegation and state 219 synchronization/report were covered in [RFC8231]. This document 220 provides extension for its application in GMPLS-controlled 221 networks. 223 o All the PCEP messages need to be capable to indicate GMPLS- 224 specific switching capabilities per TE link basis. GMPLS LSP 225 creation/modification/deletion requires knowledge of LSP 226 switching capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) and 227 the generalized payload (G-PID) to be used according to 228 [RFC3471], [RFC3473]. It also requires the specification of data 229 flow specific traffic parameters (also known as TSpec), which 230 are technology specific. Such information would be needed for 231 PCEP message. 233 o In some technologies path calculation is tightly coupled with 234 label selection along the route. For example, path calculation 235 in a WDM network may include lambda continuity and/or lambda 236 feasibility constraints and hence a path computed by the PCE is 237 associated with a specific lambda (label). Hence, in such 238 networks, the label information needs to be provided to a PCC in 239 order for a PCE to initiate GMPLS LSPs under the active stateful 240 PCE model, i.e., explicit label control may be required. 242 o Stateful PCEP message also need to indicate the protection 243 context information for the LSP specified by GMPLS, as defined 244 in [RFC4872], [RFC4873]. 246 5. Overview of PCEP Extensions for GMPLS Networks 248 5.1. Capability Advertisement for Stateful PCEP in GMPLS 250 Capability Advertisement has been specified in [RFC8231], and can be 251 achieved by using the "STATEFUL-PCE-CAPABILITY" in the PCEP TLV Type 252 Indicators. Another GMPLS-CAPABILITY TLV in the PCEP TLV Type 253 Indicators has been defined in [RFC8779]. According to [RFC8779], 254 IANA created a registry to manage the value of the GMPLS-CAPABILITY 255 TLV's Flag field. New bits, LSP-UPDATE-CAPABILITY (TBD1) and LSP- 256 INSTANTIATION-CAPABILITY (TBD2), are introduced as flag to indicate 257 the capability for LSP update and remote LSP initiation in GMPLS 258 networks. 260 5.2. LSP Synchronization 262 PCCs need to report the attributes of LSPs to the PCE to enable 263 stateful operation of a GMPLS network. This process is known as 264 LSP state synchronization. The LSP attributes include bandwidth, 265 associated route, and protection information etc., are stored by the 266 PCE in the LSP database (LSP-DB). Note that, as described in 267 [RFC8231], the LSP state synchronization covers both the bulk 268 reporting of LSPs at initialization as well the reporting of new or 269 modified LSP during normal operation. Incremental LSP-DB 270 synchronization may be desired in a GMPLS-controlled network and it 271 is specified in [RFC8232]. 273 The END-POINTS object is extended for GMPLS in [RFC8779]. The END- 274 POINTS object is carried in the PCRpt message as specified in 275 [RFC8623]. The END-POINTS object type for GMPLS is included in the 276 PCRpt message as per the same. 278 The BANDWIDTH, LSPA, IRO and XRO objects are extended for GMPLS in 279 [RFC8779]. These objects are carried in the PCRpt message as 280 specified in [RFC8231] (as the attribute-list defined in Section 6.5 281 of [RFC5440] and extended by PCEP extensions). 283 The SWITCH-LAYER object is defined in [RFC8282]. This object is 284 carried in PCRpt message as specified in section 3.2 of [RFC8282]. 286 5.3. LSP Delegation and Cleanup 288 LSP delegation and cleanup procedure specified in [RFC8231] are 289 equally applicable to GMPLS LSPs and this document does not modify 290 the associated usage. 292 5.4. LSP Operations 294 Both passive and active stateful PCE mechanism in [RFC8231] are 295 applicable in GMPLS-controlled networks. Remote LSP Initiation in 296 [RFC8281] is also applicable in GMPLS-controlled networks. 298 6. Extension of Existing PCEP Messages 300 6.1. The PCRpt Message 302 According to [RFC8231], the PCRpt Message is used to report the 303 current state of LSP. This document extends the message in reporting 304 the status of LSPs with GMPLS characteristics. 306 The format of the PCRpt message is as follows: 308 ::= 310 312 Where: 314 ::= [] 316 ::= [] 318 320 322 Where: 324 ::= 326 [] 328 330 ::=[] 332 [] 334 Where: 336 is represented by the ERO object defined in 337 Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label 338 control (ELC) and Path Keys. 340 consists of the actual computed and 341 signaled values of the and objects 342 defined in [RFC5440]. GENERALIZED-BANDWIDTH object has been defined 343 in [RFC8779] to address the limitation of the BANDWIDTH object, with 344 supporting the following: 346 o Asymmetric bandwidth (different bandwidth in forward and reverse 347 direction), as described in [RFC6387]. 349 o Technology specific GMPLS parameters (e.g., TSpec for SDH/SONET, 350 G.709, ATM, MEF, etc.). 352 is represented by the RRO object defined in 353 Section 7.10 of [RFC5440]. 355 is the attribute-list defined in 356 Section 6.5 of [RFC5440] and extended by PCEP extensions. 358 The SRP object is OPTIONAL, and the usage is extended in the 359 section 7.2.3 of this document. 361 6.2. The PCUpd Message 363 The format of a PCUpd message is as follows: 365 ::= 367 369 Where: 371 ::= [] 374 ::= 376 378 380 Where: 382 ::= 384 Where: 386 is represented by the ERO object defined in 387 Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label 388 control (ELC) and Path Keys. 390 is the attribute-list defined in 391 [RFC5440] and extended by PCEP extensions. 393 6.3. The PCInitiate Message 395 According to [RFC8281], the PCInitiate Message is used allow 396 remote LSP Initiation. This document extends the message in 397 initiating LSPs with GMPLS characteristics. The format of a 398 PCInitiate message is as follows: 400 ::= 402 404 Where: 406 is defined in [RFC5440]. 408 ::= 410 [] 412 ::= (| 415 ) 417 ::= 418 420 [] 422 424 [] 426 ::= 428 430 END-POINTS object has been extended by [RFC8779] to include a new 431 object type called "Generalized Endpoint". PCInitiate message sent 432 by a PCE to a PCC to trigger a GMPLS LSP instantiation MUST include 433 the END-POINTS with Generalized Endpoint object type. Furthermore, 434 the END-POINTS object MUST contain "label request" TLV. The label 435 request TLV is used to specify the switching type, encoding type and 436 G-PID of the LSP being instantiated by the PCE. 438 The unnumbered endpoint TLV can be used to specify unnumbered 439 endpoint addresses for the LSP being instantiated by the PCE. The 440 END-POINTS MAY contain other TLVs defined in [RFC8779]. 442 7. PCEP Object Extensions 444 7.1. Existing Extensions used for Stateful GMPLS 446 Existing extensions defined in [RFC8779] can be used in the Stateful 447 PCEP with no changes or slightly changes for GMPLS network control, 448 including the following: 450 o END-POINTS: Generalized END-POINTS was specified in [RFC8779] to 451 include GMPLS capabilities. Stateful PCEP messages MUST include the 452 END-POINTS with Generalized Endpoint object type, containing the 453 "label request" TLV. 455 o BANDWIDTH: Generalized BANDWIDTH was specified in [RFC8779] to 456 represent GMPLS features, including asymmetric bandwidth and G-PID 457 information. 459 o LSPA: LSPA Extensions in Section 2.8 of [RFC8779] is applicable 460 in Stateful PCEP for GMPLS networks. 462 o IRO: IRO Extensions in Section 2.6 of [RFC8779] is applicable in 463 Stateful PCEP for GMPLS networks. 465 o XRO: XRO Extensions in Section 2.7 of [RFC8779] is applicable in 466 Stateful PCEP for GMPLS networks. A new flag is defined in section 467 7.2.2 of this document. 469 o ERO: The ERO was not extended in [RFC8779], and not in this 470 document as well. 472 o SWITCH-LAYER: SWITCHING-LAYER definition in Section 3.2 of 473 [RFC8282] is applicable in Stateful PCEP messages for GMPLS networks. 475 7.2. New Extensions 477 7.2.1. OPEN Object Extension GMPLS-CAPABILITY TLV 479 In [RFC8779], IANA has allocated value 45 (GMPLS-CAPABILITY) from 480 the "PCEP TLV Type Indicators" sub-registry. The TLV is extended 481 with two flags to indicate the Stateful and remote initiate 482 capability. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type=45 | Length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Flags |I|S| 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 S (LSP-UPDATE-CAPABILITY -- 1 bit): if set to 1 by a PCC, the S flag 493 indicates that the PCC allows modification of LSP parameters; if set 494 to 1 by a PCE, the S flag indicates that the PCE is capable of 495 updating LSP parameters. The LSP-UPDATE-CAPABILITY flag must be 496 advertised by both a PCC and a PCE for PCUpd messages to be allowed 497 on a PCEP session. 499 I (LSP-INSTANTIATION-CAPABILITY -- 1 bit): If set to 1 by a PCC, the 500 I flag indicates that the PCC allows instantiation of an LSP by a 501 PCE. If set to 1 by a PCE, the I flag indicates that the PCE 502 supports instantiating LSPs. The LSP-INSTANTIATION-CAPABILITY flag 503 must be set by both the PCC and PCE in order to enable PCE-initiated 504 LSP instantiation. 506 7.2.2. XRO Subobject 508 [RFC5521] defines a mechanism for a PCC to request or demand that 509 specific nodes, links, or other network resources are excluded from 510 paths computed by a PCE. A PCC may wish to request the computation 511 of a path that avoids all link and nodes traversed by some other LSP. 513 To this end this document defines a new sub-object for use with 514 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 515 is as follows: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |X|Type (TBD3) | Length | Attributes | Flag | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | | 523 // Symbolic Path Name // 524 | | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 X bit and Attribute fields are defined in [RFC5521]. 529 Type: Subobject Type for an LSP exclusion sub-object. Value of 530 TBD3. To be assigned by IANA. 532 Length: The Length contains the total length of the subobject in 533 bytes, including the Type and Length fields. 535 Flags: This field may be used to further specify the exclusion 536 constraint with regard to the LSP. Currently, no values are 537 defined. 539 Symbolic Path Name: This is the identifier given to an LSP and is 540 unique in the context of the PCC address as defined in [RFC8231]. 542 Reserved: MUST be transmitted as zero and SHOULD be ignored on 543 receipt. 545 This sub-object is OPTIONAL in the exclude route object (XRO) and 546 can be present multiple times. When a stateful PCE receives a PCReq 547 message carrying this sub-object, it SHOULD search for the 548 identified LSP in its LSP-DB and then exclude from the new path 549 computation all resources used by the identified LSP. 551 7.2.3. SRP Extension 553 The format of the SRP object is defined in [RFC8231]. The object is 554 used in PCUpd and PCInitiate messages for GMPLS. 556 This document defines a new flag to be carried in the Flags field of 557 the SRP object. This flag indicates a bidirectional co-routed LSP 558 setup operation initiated by the PCE as follows: 560 o B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a 561 request to create a uni-directional LSP. If set to 1, it indicates 562 a request to create a bidirectional co-routed LSP. 564 The bit position is TBD6 as assigned by IANA. 566 8. Update to Error Handling 568 A PCEP-ERROR object is used to report a PCEP error and is 569 characterized by an Error-Type that specifies the type of error and 570 an Error-value that provides additional information about the error. 571 In this document the following Error-Type and Error-Value are 572 introduced. 574 8.1. Error Handling in LSP Re-optimization 576 When setting the R bit in RP object, the PCC is requesting re- 577 optimization of an existing LSP. A stateful PCE SHOULD perform the 578 re-optimization. 580 If no LSP state information is available to carry out re- 581 optimization, the stateful PCE should report the error "LSP state 582 information unavailable for the LSP re-optimization" (Error Type = 583 TBD5, Error value= TBD6). 585 8.2. Error Handling in Route Exclusion 587 This sub-object in XRO defined in section 7.2.2 of this document is 588 OPTIONAL and can be present multiple times. When a stateful PCE 589 receives a PCReq message carrying this sub-object, it SHOULD search 590 for the identified LSP in its LSP-DB and then exclude from the new 591 path computation all resources used by the identified LSP. 593 If the stateful PCE cannot recognize one or more of the received LSP 594 identifiers, it should send an error message PCErr reporting "The 595 LSP state information for route exclusion purpose cannot be found" 596 (Error-type = TBD5, Error-value = TBD7). Optionally, it may provide 597 with the unrecognized identifier information to the requesting PCC 598 using the error reporting techniques described in [RFC5440]. 600 8.3. Error Handling for generalized END-POINTS 602 If the END-POINTS Object of type Generalized Endpoint is missing the 603 label request TLV, the PCC MUST send a PCErr message with Error- 604 type=6 (Mandatory Object missing) and Error-value= TBD8 (label 605 request TLV missing). 607 If the PCC does not support the END-POINTS Object of type 608 Generalized Endpoint, the PCC MUST send a PCErr message with Error- 609 type = 3(Unknown Object), Error-value = 2(unknown object type). 611 9. Implementation 613 [NOTE TO RFC EDITOR : This whole section and the reference to RFC 614 7942 is to be removed before publication as an RFC] 616 This section records the status of known implementations of the 617 protocol defined by this specification at the time of posting of 618 this Internet-Draft, and is based on a proposal described in 619 [RFC7942]. The description of implementations in this section is 620 intended to assist the IETF in its decision processes in progressing 621 drafts to RFCs. Please note that the listing of any individual 622 implementation here does not imply endorsement by the IETF. 623 Furthermore, no effort has been spent to verify the information 624 presented here that was supplied by IETF contributors. This is not 625 intended as, and must not be construed to be, a catalog of available 626 implementations or their features. Readers are advised to note that 627 other implementations may exist. 629 According to [RFC7942], "this will allow reviewers and working 630 groups to assign due consideration to documents that have the 631 benefit of running code, which may serve as evidence of valuable 632 experimentation and feedback that have made the implemented 633 protocols more mature. It is up to the individual working groups to 634 use this information as they see fit". 636 9.1. Huawei Technologies 638 o Organization: Huawei Technologies, Co. LTD 640 o Implementation: Huawei NCE-T 641 o Description: PCRpt, PCUpd and PCInitiate messages for GMPLS 642 Network 644 o Maturity Level: Production 646 o Coverage: Full 648 o Contact: zhenghaomian@huawei.com 650 10. IANA Considerations 652 10.1. New GMPLS-CAPABILITY 654 [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, 655 IANA created a registry to manage the value of the STATEFUL-PCE- 656 CAPABILITY TLV's Flag field. IANA has allocated a new bit in the 657 STATEFUL-PCE-CAPABILITY TLV Flag Field registry, as follows: 659 Bit Description Reference 661 --- -------------------------------- ------------- 663 TBD1 LSP-UPDATE-CAPABILITY (S) [This.I-D] 665 TBD2 LSP-INSTANTIATION-CAPABILITY (I) [This.I-D] 667 10.2. New Subobject for the Exclude Route Object 669 IANA maintains the "PCEP Parameters" registry containing a 670 subregistry called "PCEP Objects". This registry has a subregistry 671 for the XRO (Exclude Route Object) listing the sub-objects that can 672 be carried in the XRO. IANA is requested to assign a further sub- 673 object that can be carried in the XRO as follows: 675 Value Description Reference 677 ----------+------------------------------+------------- 679 TBD3 LSP identifier sub-object [This.I-D] 681 10.3. New "B" Flag in the SRP Object 683 IANA maintains a subregistry, named the "SRP Object Flag Field", 684 within the "Path Computation Element Protocol (PCEP) Numbers" 685 registry, to manage the Flag field of the SRP object. 687 IANA is requested to make an assignment from this registry as 688 follows: 690 Bit Description Reference 691 --- ---------------------------- ---------- 693 TBD4 Bi-directional co-routed LSP [This.I-D] 695 10.4. New PCEP Error Codes 697 IANA is requested to make the following allocation in the "PCEP- 698 ERROR Object Error Types and Values" registry. 700 Error Type Meaning Reference 702 TBD5 LSP state information missing [This.I-D] 704 Error-value TBD6: LSP state information unavailable [This.I-D] 705 for the LSP re-optimization 707 Error-value TBD7: LSP state information for route 708 exclusion purpose cannot be found [This.I-D] 710 This document defines the following new Error-Value: 712 Error-Type Error-Value Reference 714 6 Error-value TBD8: Label Request TLV 715 missing [This.I-D] 717 11. Manageability Considerations 719 The description and functionality specifications presented related 720 to stateful PCEs should also comply with the manageability 721 specifications covered in Section 8 of [RFC4655]. Furthermore, a 722 further list of manageability issues presented in [RFC8231] should 723 also be considered. 725 11.1. Requirements on Other Protocols 727 When the detailed route information is included for LSP state 728 synchronization (either at the initial stage or during LSP state 729 report process), this requires the ingress node of an LSP carry the 730 RRO object in order to enable the collection of such information. 732 12. Security Considerations 734 This draft provides additional extensions to PCEP so as to 735 facilitate stateful PCE usage in GMPLS-controlled networks, on top 736 of [RFC8231]. The PCEP extensions to support GMPLS-controlled 737 networks should be considered under the same security as for MPLS 738 networks, as noted in [RFC7025]. Therefore, the security 739 considerations elaborated in [RFC5440] still apply to this draft. 740 Furthermore, [RFC8231] provides a detailed analysis of the 741 additional security issues incurred due to the new extensions and 742 possible solutions needed to support for the new stateful PCE 743 capabilities and they apply to this document as well. 745 13. Acknowledgement 747 We would like to thank Adrian Farrel, Cyril Margaria, George Swallow 748 and Jan Medved for the useful comments and discussions. 750 14. References 752 14.1. Normative References 754 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 755 requirements levels", RFC 2119, March 1997. 757 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 758 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 759 March 2009. 761 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 762 Path Computation Element Communication Protocol (PCEP) for 763 Route Exclusions", RFC 5521, April 2009. 765 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 766 Key Words", RFC 8174, May 2017. 768 [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path 769 Computation Element Communication Protocol (PCEP) 770 Extensions for Stateful PCE", RFC 8231, September 2017. 772 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 773 Computation Element Communication Protocol (PCEP) 774 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 775 Model", RFC 8281, December 2017. 777 [RFC8779] Margaria, C., Gonzalez de Dios, O., Zhang, F., "Path 778 Computation Element Communication Protocol (PCEP) 779 extensions for GMPLS", RFC 8779, July 2020. 781 14.2. Informative References 783 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of 784 Running Code: The Implementation Status Section", BCP 205, 785 RFC 7942, DOI 10.17487/RFC7942, July 2016, 786 . 788 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 789 Path Computation Element (PCE) ", RFC 8051, January 2017. 791 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 792 and D. Dhody, "Optimizations of Label Switched Path State 793 Synchronization Procedures for a Stateful PCE", RFC 8232, 794 September 2017. 796 [RFC8282] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions 797 to the Path Computation Element communication Protocol 798 (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", 799 RFC 8282, December 2017. 801 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 802 Switching (GMPLS) Signaling Functional Description", RFC 803 3471, January 2003. 805 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 806 Switching (GMPLS) Signaling Resource ReserVation Protocol 807 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 808 January 2003. 810 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 811 Computation Element (PCE)-Based Architecture", RFC 4655, 812 August 2006. 814 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 815 Ed., "RSVP-TE Extensions in Support of End-to-End 816 Generalized Multi-Protocol Label Switching (GMPLS) 817 Recovery", RFC 4872, May 2007. 819 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 820 "GMPLS Segment Recovery", RFC 4873, May 2007. 822 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 823 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 824 Switched Paths (LSPs)", RFC 6387, September 2011. 826 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 827 Margaria, "Requirements for GMPLS Applications of PCE", 828 RFC 7025, September 2013, 830 [RFC7399] Farrel, A., King, D., "Unanswered Questions in the Path 831 Computation Element Architecture", RFC 7399, October 2014. 833 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., Beeram, V., "Stateful 834 Path Computation Element (PCE) Protocol Extensions for 835 Usage with Point-to-Multipoint TE Label Switched Paths 836 (LSPs)" June 2019. 838 15. Contributors' Address 840 Xian Zhang 841 Huawei Technologies 842 Email: zhang.xian@huawei.com 844 Dhruv Dhody 845 Huawei Technology 846 India 847 Email: dhruv.ietf@gmail.com 849 Yi Lin 850 Huawei Technologies 851 Email: yi.lin@huawei.com 853 Fatai Zhang 854 Huawei Technologies 855 Email: zhangfatai@huawei.com 857 Ramon Casellas 858 CTTC 859 Av. Carl Friedrich Gauss n7 860 Castelldefels, Barcelona 08860 861 Spain 862 Email: ramon.casellas@cttc.es 864 Siva Sivabalan 865 Cisco Systems 866 Email: msiva@cisco.com 868 Clarence Filsfils 869 Cisco Systems 870 Email: cfilsfil@cisco.com 872 Robert Varga 873 Pantheon Technologies 874 Email: nite@hq.sk 876 Authors' Addresses 878 Young Lee (Editor) 879 Samsung 880 Email: younglee.tx@gmail.com 882 Haomian Zheng (Editor) 883 Huawei Technologies 884 H1, Huawei Xiliu Beipo Village, Songshan Lake 885 Dongguan, Guangdong 523808 886 P.R.China 888 Email: zhenghaomian@huawei.com 890 Oscar Gonzalez de Dios 891 Telefonica 892 Phone: +34 913374013 893 Email: oscar.gonzalezdedios@telefonica.com 895 Victor Lopez 896 Telefonica 898 Email: victor.lopezalvarez@telefonica.com 900 Zafar Ali 901 Cisco Systems 902 Email: zali@cisco.com