idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-17.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 (February 10, 2022) is 805 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: 0 errors (**), 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 2 Internet-Draft Samsung 3 Intended status: Standards Track H. Zheng 4 Expires: August 10, 2022 Huawei Technologies 5 O. G. de Dios 6 Telefonica 7 Victor Lopez 8 Nokia 9 Z. Ali 10 Cisco Systems 11 February 10, 2022 13 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 14 Usage in GMPLS-controlled Networks 16 draft-ietf-pce-pcep-stateful-pce-gmpls-17 18 Abstract 20 The Path Computation Element (PCE) facilitates Traffic Engineering 21 (TE) based path calculation in large, multi-domain, multi-region, or 22 multi-layer networks. The PCE communication Protocol (PCEP) has been 23 extended to support stateful PCE functions where the PCE retains 24 information about the paths already present in the network, but 25 those extensions are technology-agnostic. This memo provides 26 extensions required for PCEP so as to enable the usage of a stateful 27 PCE capability in GMPLS-controlled networks. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with 32 the provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. The list of current Internet-Drafts is at 38 https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as 43 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on August 10, 2022. 52 Copyright Notice 54 Copyright (c) 2022 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 Table of Contents .............................................. 2 70 1. Introduction ................................................ 3 71 2. Conventions used in this document ........................... 4 72 3. General Context of Stateful PCE and PCEP for GMPLS .......... 4 73 4. Main Requirements ........................................... 5 74 5. Overview of Stateful PCEP Extensions for GMPLS Networks ..... 6 75 5.1. Capability Advertisement for Stateful PCEP in GMPLS .... 6 76 5.2. LSP Synchronization .................................... 6 77 5.3. LSP Delegation and Cleanup ............................. 7 78 5.4. LSP Operations ......................................... 7 79 6. Extension of Existing PCEP Messages ......................... 7 80 6.1. The PCRpt Message ...................................... 7 81 6.2. The PCUpd Message ...................................... 9 82 6.3. The PCInitiate Message ................................. 9 83 7. PCEP Object Extensions ..................................... 11 84 7.1. Existing Extensions used for Stateful GMPLS ........... 11 85 7.2. New Extensions ........................................ 11 86 7.2.1. OPEN Object Extension GMPLS-CAPABILITY TLV ....... 11 87 7.2.2. New LSP Exclusion Sub-object in the XRO .......... 12 88 7.2.3. SRP Extension .................................... 13 90 8. Update to Error Handling .................................... 13 91 8.1. Error Handling in LSP Re-optimization .................. 13 92 8.2. Error Handling in Route Exclusion ...................... 13 93 8.3. Error Handling for generalized END-POINTS .............. 14 94 9. Implementation .............................................. 14 95 9.1. Huawei Technologies .................................... 14 96 10. IANA Considerations......................................... 15 97 10.1. New GMPLS-CAPABILITY .................................. 15 98 10.2. New Sub-object for the Exclude Route Object ........... 15 99 10.3. Flag Field for new XRO Sub-object ..................... 15 100 10.4. New "B" Flag in the SRP Object ........................ 16 101 10.5. New PCEP Error Codes .................................. 16 102 11. Manageability Considerations ............................... 16 103 11.1. Requirements on Other Protocols ....................... 17 104 12. Security Considerations .................................... 17 105 13. Acknowledgement ............................................ 17 106 14. References ................................................. 17 107 14.1. Normative References .................................. 17 108 14.2. Informative References ................................ 18 109 15. Contributors' Address ...................................... 19 110 Authors' Addresses ............................................. 21 112 1. Introduction 114 [RFC4655] presents the architecture of a Path Computation Element 115 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 116 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 117 Paths (TE LSPs). To perform such a constrained computation, a PCE 118 stores the network topology (i.e., TE links and nodes) and resource 119 information (i.e., TE attributes) in its TE Database (TED). Such a 120 PCE is usually referred as a stateless PCE. To request path 121 computation services to a PCE, [RFC5440] defines the PCE 122 communication Protocol (PCEP) for interaction between a Path 123 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 124 specified in [RFC5440] mainly focuses on MPLS networks and the PCEP 125 extensions needed for GMPLS-controlled networks are provided in 126 [RFC8779]. 128 Stateful PCEs are shown to be helpful in many application scenarios, 129 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. 130 Further discussion of concept of a stateful PCE can be found in 131 [RFC7399]. In order for these applications to able to exploit the 132 capability of stateful PCEs, extensions to PCEP are required. 134 [RFC8051] describes how a stateful PCE can be applicable to solve 135 various problems for MPLS-TE and GMPLS networks and the benefits it 136 brings to such deployments. 138 [RFC8231] provides the fundamental extensions needed for stateful 139 PCE to support general functionality. Furthermore, [RFC8281] 140 describes the setup and teardown of PCE-initiated LSPs under the 141 active stateful PCE model, without the need for local configuration 142 on the PCC. However, both the documents left out the specification 143 for technology-specific objects/TLVs, and do not cover the GMPLS 144 networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies). 146 This document focuses on the extensions that are necessary in order 147 for the deployment of stateful PCEs and the requirements for remote- 148 initiated LSPs in GMPLS-controlled networks. Section 3 provides 149 General context of Stateful PCE and PCEP for GMPLS are provided in 150 Section 3, and PCE initiation requirement for GMPLS is provided in 151 section 4. Protocol extensions are included in section 5, as a 152 solution to address such requirements. 154 2. Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in 159 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 3. General Context of Stateful PCE and PCEP for GMPLS 164 This section is built on the basis of Stateful PCE in [RFC8231] and 165 PCEP for GMPLS in [RFC8779]. 167 The operation for Stateful PCE on LSPs can be divided into two types, 168 active stateful PCE and passive stateful PCE. 170 For active stateful PCE, a PCUpd message is sent from PCE to PCC to 171 update the LSP state for the LSP delegated to the PCE. Any changes 172 to the delegated LSPs generate a PCRpt message from the PCC to PCE 173 to convey the changes of the LSP. Any modifications to the 174 Objects/TLVs that are identified in this document to support GMPLS 175 technology-specific attributes will be carried in the PCRpt and 176 PCUpd messages. 178 For passive stateful PCEs, PCReq/PCRep messages are used to convey 179 path computation instructions. GMPLS-technology specific Objects 180 and TLVs are defined in [RFC8779], so this document just points at 181 that work and only adds the stateful PCE aspects where applicable. 182 Passive Stateful PCE makes use of PCRpt messages when reporting LSP 183 State changes sent by PCC to PCEs. Any modifications to the 184 Objects/TLVs that are identified in this document to support GMPLS 185 technology-specific attributes will be carried in the PCRpt message. 187 Furthermore, the LSP Initiation function of PCEP is defined in 188 [RFC8281] to allow the PCE to initiate LSP establishment after the 189 path is computed. PCInitiate messages are used to trigger the end 190 node to set up the LSP. Any modifications to the Objects/TLVs that 191 are identified in this document to support GMPLS technology-specific 192 attributes will be carried in the PCInitiate messages. 194 [RFC8779] defines GMPLS-technology specific Objects/TLVs in 195 stateless PCEP, and this document makes use of these Objects/TLVs 196 without modifications where applicable. Where these Objects/TLVs 197 require modifications to incorporate stateful PCE, they are 198 described in this document. The remote-initiated LSP would follow 199 the principle specified in [RFC8281], and GMPLS-specific extensions 200 are also included in this document. 202 4. Main Requirements 204 This section notes the main functional requirements for PCEP 205 extensions to support stateful PCE for use in GMPLS-controlled 206 networks, based on the description in [RFC8051]. Many 207 requirements are common across a variety of network types (e.g., 208 MPLS-TE networks and GMPLS networks) and the protocol extensions to 209 meet the requirements are already described in [RFC8231]. This 210 document does not repeat the description of those protocol 211 extensions. This document presents protocol extensions for a set of 212 requirements which are specific to the use of a stateful PCE in a 213 GMPLS-controlled network. 215 The requirements for GMPLS-specific stateful PCE are as follows: 217 o Advertisement of the stateful PCE capability. This generic 218 requirement is covered in Section 5.4 of [RFC8231]. The GMPLS 219 CAPABILITY TLV in section 2.1 of [RFC8779] and its extension in 220 this document MUST be advertised as well. 222 o LSP operations, including LSP update, delegation and state 223 synchronization/report are covered in [RFC8231]. This document 224 provides extensions for its application in GMPLS-controlled 225 networks. 227 o All the PCEP messages need to be capable of indicating GMPLS- 228 specific switching capabilities a per TE link basis. GMPLS LSP 229 creation/modification/deletion requires knowledge of LSP 230 switching capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) and 231 the generalized payload (G-PID) to be used according to 233 [RFC3471], [RFC3473]. It also requires the specification of data 234 flow specific traffic parameters (also known as TSpec), which 235 are technology specific. Such information would need to be 236 included in various PCEP messages. 238 o In some technologies, path calculation is tightly coupled with 239 label selection along the route. For example, path calculation 240 in a WDM network may include lambda continuity and/or lambda 241 feasibility constraints and hence a path computed by the PCE is 242 associated with a specific lambda (label). Hence, in such 243 networks, the label information needs to be provided to a PCC in 244 order for a PCE to initiate GMPLS LSPs under the active stateful 245 PCE model, i.e., explicit label control may be required. 247 o Stateful PCEP messages also need to indicate the protection 248 context information for the LSP specified by GMPLS, as defined 249 in [RFC4872], [RFC4873]. 251 5. Overview of Stateful PCEP Extensions for GMPLS Networks 253 5.1. Capability Advertisement for Stateful PCEP in GMPLS 255 Capability Advertisement has been specified in [RFC8231], and can be 256 achieved by using the "STATEFUL-PCE-CAPABILITY" in the PCEP TLV Type 257 Indicators. Another GMPLS-CAPABILITY TLV in the PCEP TLV Type 258 Indicators has been defined in [RFC8779]. According to [RFC8779], 259 IANA created a registry to manage the value of the GMPLS-CAPABILITY 260 TLV's Flag field. New bits, LSP-UPDATE-CAPABILITY (TBD1) and LSP- 261 INSTANTIATION-CAPABILITY (TBD2), are introduced as flags to indicate 262 the capability for LSP update and remote LSP initiation in GMPLS 263 networks. 265 5.2. LSP Synchronization 267 PCCs need to report the attributes of LSPs to the PCE to enable 268 stateful operation of a GMPLS network. This process is known as 269 LSP state synchronization. The LSP attributes including bandwidth, 270 associated route, and protection information etc., are stored by the 271 PCE in the LSP database (LSP-DB). Note that, as described in 272 [RFC8231], the LSP state synchronization covers both the bulk 273 reporting of LSPs at initialization as well the reporting of new or 274 modified LSPs during normal operation. Incremental LSP-DB 275 synchronization may be desired in a GMPLS-controlled network and it 276 is specified in [RFC8232]. 278 The END-POINTS object is extended for GMPLS in [RFC8779]. The END- 279 POINTS object is carried in the PCRpt message as specified in 281 [RFC8623]. The END-POINTS object type for GMPLS is included in the 282 PCRpt message as per the same. 284 The BANDWIDTH, LSPA, IRO and XRO objects are extended for GMPLS in 285 [RFC8779]. These objects are carried in the PCRpt message as 286 specified in [RFC8231] (as the attribute-list defined in Section 6.5 287 of [RFC5440] and extended by many other documents that define PCEP 288 extensions for specific scenarios). 290 The SWITCH-LAYER object is defined in [RFC8282]. This object is 291 carried in PCRpt message as specified in section 3.2 of [RFC8282]. 293 5.3. LSP Delegation and Cleanup 295 LSP delegation and cleanup procedure specified in [RFC8231] are 296 equally applicable to GMPLS LSPs and this document does not modify 297 the associated usage. 299 5.4. LSP Operations 301 Both passive and active stateful PCE mechanisms in [RFC8231] are 302 applicable in GMPLS-controlled networks. Remote LSP Initiation in 303 [RFC8281] is also applicable in GMPLS-controlled networks. 305 6. Extension of Existing PCEP Messages 307 This section describes how the PCEP messages are extended by using 308 Routing Backus-Naur Form (RBNF) [RFC5511] formats. Contents in this 309 section are for informative purpose. 311 6.1. The PCRpt Message 313 According to [RFC8231], the PCRpt Message is used to report the 314 current state of an LSP. This document extends the message in 315 reporting the status of LSPs with GMPLS characteristics. 317 The format of the PCRpt message is as follows: 319 ::= 321 323 Where: 325 ::= [] 327 ::= [] 328 330 332 Where: 334 ::= 336 [] 338 340 ::=[] 342 [] 344 Where: 346 is represented by the ERO object defined in 347 Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label 348 control (ELC) and Path Keys. 350 consists of the actual computed and 351 signaled values of the and objects 352 defined in [RFC5440]. GENERALIZED-BANDWIDTH object has been defined 353 in [RFC8779] to address the limitation of the BANDWIDTH object, with 354 supporting the following: 356 o Asymmetric bandwidth (different bandwidth in forward and reverse 357 direction), as described in [RFC6387]. 359 o Technology specific GMPLS parameters (e.g., TSpec for SDH/SONET, 360 G.709, ATM, MEF, etc.). 362 is represented by the RRO object defined in 363 Section 7.10 of [RFC5440]. 365 is the attribute-list defined in 366 Section 6.5 of [RFC5440] and extended by many other documents that 367 define PCEP extensions for specific scenarios. 369 The SRP object is OPTIONAL, and the usage is extended in the 370 section 7.2.3 of this document. 372 6.2. The PCUpd Message 374 The format of a PCUpd message is as follows: 376 ::= 378 380 Where: 382 ::= [] 385 ::= 387 389 391 Where: 393 ::= 395 Where: 397 is represented by the ERO object defined in 398 Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label 399 control (ELC) and Path Keys. 401 is the attribute-list defined in 402 [RFC5440] and extended by many other documents that define PCEP 403 extensions for specific scenarios. 405 The SRP object is OPTIONAL, and the usage is extended in the 406 section 7.2.3 of this document. 408 6.3. The PCInitiate Message 410 According to [RFC8281], the PCInitiate Message is used allow 411 remote LSP Initiation. This document extends the message in 412 initiating LSPs with GMPLS characteristics. The format of a 413 PCInitiate message is as follows: 415 ::= 417 419 Where: 421 is defined in [RFC5440]. 423 ::= 425 [] 427 ::= (| 430 ) 432 ::= 434 436 [] 438 440 [] 442 ::= 444 446 The format of the PCInitiate message is unchanged from Section 5.1 447 of [RFC8281]. However, note the following: 449 o The END-POINTS object was been extended by [RFC8779] to 450 include a new object type called "Generalized Endpoint". A 451 PCInitiate message used to trigger a GMPLS LSP instantiation MUST 452 use that extension. 454 o A PCInitiate message sent by a PCE to a PCC to trigger a GMPLS 455 LSP instantiation MUST include the END-POINTS with Generalized 456 Endpoint object type (even though it is marked as optional in the 457 message definition. 459 o The END-POINTS object MUST contain a "label request" TLV per 460 [RFC8779]. The label request TLV is used to specify the switching 461 type, encoding type and G-PID of the LSP being instantiated by the 462 PCE. 464 o If unnumbered endpoint addresses are used for the LSP being 465 instantiated by the PCE, the unnumbered endpoint TLV [RFC8779] 466 MUST be use to specify the unnumbered endpoint addresses. 468 o The END-POINTS MAY contain other TLVs defined in [RFC8779]. 470 7. PCEP Object Extensions 472 7.1. Existing Extensions used for Stateful GMPLS 474 Existing extensions defined in [RFC8779] can be used in the Stateful 475 PCEP with no changes or slightly changes for GMPLS network control, 476 including the following: 478 o END-POINTS: Generalized END-POINTS was specified in [RFC8779] to 479 include GMPLS capabilities. Stateful PCEP messages MUST include the 480 END-POINTS with Generalized Endpoint object type, containing the 481 "label request" TLV. 483 o BANDWIDTH: Generalized BANDWIDTH was specified in [RFC8779] to 484 represent GMPLS features, including asymmetric bandwidth and G-PID 485 information. 487 o LSPA: LSPA Extensions in Section 2.8 of [RFC8779] is applicable 488 in Stateful PCEP for GMPLS networks. 490 o IRO: IRO Extensions in Section 2.6 of [RFC8779] is applicable in 491 Stateful PCEP for GMPLS networks. 493 o XRO: XRO Extensions in Section 2.7 of [RFC8779] is applicable in 494 Stateful PCEP for GMPLS networks. A new flag is defined in section 495 7.2.2 of this document. 497 o ERO: The ERO was not extended in [RFC8779], and not in this 498 document as well. 500 o SWITCH-LAYER: SWITCHING-LAYER definition in Section 3.2 of 501 [RFC8282] is applicable in Stateful PCEP messages for GMPLS networks. 503 7.2. New Extensions 505 7.2.1. OPEN Object Extension GMPLS-CAPABILITY TLV 507 In [RFC8779], IANA has allocated value 45 (GMPLS-CAPABILITY) from 508 the "PCEP TLV Type Indicators" sub-registry. The TLV is extended 509 with two flags to indicate the Stateful and remote initiate 510 capability. 512 S (LSP-UPDATE-CAPABILITY(TBD1) -- 1 bit): if set to 1 by a PCC, the 513 S flag indicates that the PCC allows modification of LSP parameters; 514 if set to 1 by a PCE, the S flag indicates that the PCE is capable 515 of updating LSP parameters. The LSP-UPDATE-CAPABILITY flag must be 516 advertised by both a PCC and a PCE for PCUpd messages to be allowed 517 on a PCEP session. 519 I (LSP-INSTANTIATION-CAPABILITY(TBD2) -- 1 bit): If set to 1 by a 520 PCC, the I flag indicates that the PCC allows instantiation of an 521 LSP by a PCE. If set to 1 by a PCE, the I flag indicates that the 522 PCE supports instantiating LSPs. The LSP-INSTANTIATION-CAPABILITY 523 flag must be set by both the PCC and PCE in order to enable PCE- 524 initiated LSP instantiation. 526 7.2.2. New LSP Exclusion Sub-object in the XRO 528 [RFC5521] defines a mechanism for a PCC to request or demand that 529 specific nodes, links, or other network resources are excluded from 530 paths computed by a PCE. A PCC may wish to request the computation 531 of a path that avoids all link and nodes traversed by some other LSP. 533 To this end this document defines a new sub-object for use with 534 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 535 is as follows: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |X|Type (TBD3) | Length | Attributes | Flags | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | | 543 // Symbolic Path Name // 544 | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 X bit and Attribute fields are defined in [RFC5521]. 549 Type: Sub-object Type for an LSP exclusion sub-object. Value of 550 TBD3. To be assigned by IANA. 552 Length: The Length contains the total length of the sub-object in 553 bytes, including the Type and Length fields. 555 Flags: This field may be used to further specify the exclusion 556 constraint with regard to the LSP. Currently, no values are 557 defined. 559 Symbolic Path Name: This is the identifier given to an LSP and is 560 unique in the context of the PCC address as defined in [RFC8231]. 562 This sub-object is OPTIONAL in the exclude route object (XRO) and 563 can be present multiple times. When a stateful PCE receives a PCReq 564 message carrying this sub-object, it MUST search for the identified 565 LSP in its LSP-DB and then exclude from the new path computation all 566 resources used by the identified LSP. 568 7.2.3. SRP Extension 570 The format of the SRP object is defined in [RFC8231]. The object is 571 used in PCUpd and PCInitiate messages for GMPLS. 573 This document defines a new flag to be carried in the Flags field of 574 the SRP object. This flag indicates a bidirectional co-routed LSP 575 setup operation initiated by the PCE as follows: 577 o B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a 578 request to create a uni-directional LSP. If set to 1, it indicates 579 a request to create a bidirectional co-routed LSP. 581 The bit position is TBD4 as assigned by IANA. 583 8. Update to Error Handling 585 A PCEP-ERROR object is used to report a PCEP error and is 586 characterized by an Error-Type that specifies the type of error and 587 an Error-value that provides additional information about the error. 588 In this document the following Error-Type and Error-Value are 589 introduced. 591 8.1. Error Handling in LSP Re-optimization 593 A stateful PCE performs the re-optimization when the R bit is set in 594 RP object. If no LSP state information is available to carry out re- 595 optimization, the stateful PCE SHOULD report the error "LSP state 596 information unavailable for the LSP re-optimization" (Error Type = 597 TBD5, Error value= TBD6). The PCE MAY suppress this error message 598 on a configurable threshold. 600 8.2. Error Handling in Route Exclusion 602 This sub-object in XRO defined in section 7.2.2 of this document is 603 OPTIONAL and can be present multiple times. When a stateful PCE 604 receives a PCReq message carrying this sub-object, it searches for 605 the identified LSP in its LSP-DB and then excludes from the new path 606 computation all resources used by the identified LSP. If the 607 stateful PCE cannot recognize one or more of the received LSP 608 identifiers, it SHOULD send an error message PCErr reporting "The 609 LSP state information for route exclusion purpose cannot be found" 610 (Error-type = TBD5, Error-value = TBD7). Optionally, it may also 611 provide with the unrecognized identifier information to the 612 requesting PCC using the error reporting techniques described in 613 [RFC5440]. However, the PCE MAY suppress this error message on a 614 configurable threshold. 616 8.3. Error Handling for generalized END-POINTS 618 If the END-POINTS Object of type Generalized Endpoint is missing the 619 label request TLV, the PCC MUST send a PCErr message with Error- 620 type=6 (Mandatory Object missing) and Error-value= TBD8 (label 621 request TLV missing). 623 9. Implementation 625 [NOTE TO RFC EDITOR : This whole section and the reference to RFC 626 7942 is to be removed before publication as an RFC] 628 This section records the status of known implementations of the 629 protocol defined by this specification at the time of posting of 630 this Internet-Draft, and is based on a proposal described in 631 [RFC7942]. The description of implementations in this section is 632 intended to assist the IETF in its decision processes in progressing 633 drafts to RFCs. Please note that the listing of any individual 634 implementation here does not imply endorsement by the IETF. 635 Furthermore, no effort has been spent to verify the information 636 presented here that was supplied by IETF contributors. This is not 637 intended as, and must not be construed to be, a catalog of available 638 implementations or their features. Readers are advised to note that 639 other implementations may exist. 641 According to [RFC7942], "this will allow reviewers and working 642 groups to assign due consideration to documents that have the 643 benefit of running code, which may serve as evidence of valuable 644 experimentation and feedback that have made the implemented 645 protocols more mature. It is up to the individual working groups to 646 use this information as they see fit". 648 9.1. Huawei Technologies 650 o Organization: Huawei Technologies, Co. LTD 652 o Implementation: Huawei NCE-T 654 o Description: PCRpt, PCUpd and PCInitiate messages for GMPLS 655 Network 656 o Maturity Level: Production 658 o Coverage: Full 660 o Contact: zhenghaomian@huawei.com 662 10. IANA Considerations 664 10.1. New GMPLS-CAPABILITY 666 [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, 667 IANA created a registry to manage the value of the STATEFUL-PCE- 668 CAPABILITY TLV's Flag field. IANA has allocated a new bit in the 669 STATEFUL-PCE-CAPABILITY TLV Flag Field registry, as follows: 671 Bit Description Reference 673 --- -------------------------------- ------------- 675 TBD1 LSP-UPDATE-CAPABILITY (S) [This.I-D] 677 TBD2 LSP-INSTANTIATION-CAPABILITY (I) [This.I-D] 679 10.2. New Sub-object for the Exclude Route Object 681 IANA maintains the "PCEP Parameters" registry containing a 682 subregistry called "PCEP Objects". This registry has a subregistry 683 for the XRO (Exclude Route Object) listing the sub-objects that can 684 be carried in the XRO. IANA is requested to assign a further sub- 685 object that can be carried in the XRO as follows: 687 Value Description Reference 689 ----------+------------------------------+------------- 691 TBD3 LSP Exclusion sub-object [This.I-D] 693 10.3. Flag Field for new XRO Sub-object 695 IANA has created a registry to manage the Flag field of the LSP 696 Exclusion sub-object in XRO object. No Flag is currently defined 697 for this flag field in this document. 699 Codespace of the Flag field (LSP Exclusion sub-object) 701 Bit Description Reference 703 0-7 Unassigned [This.I-D] 705 10.4. New "B" Flag in the SRP Object 707 IANA maintains a subregistry, named the "SRP Object Flag Field", 708 within the "Path Computation Element Protocol (PCEP) Numbers" 709 registry, to manage the Flag field of the SRP object. 711 IANA is requested to make an assignment from this registry as 712 follows: 714 Bit Description Reference 715 --- ---------------------------- ---------- 717 TBD4 Bi-directional co-routed LSP [This.I-D] 719 10.5. New PCEP Error Codes 721 IANA is requested to make the following allocation in the "PCEP- 722 ERROR Object Error Types and Values" registry. 724 Error Type Meaning Reference 726 TBD5 LSP state information missing [This.I-D] 728 Error-value TBD6: LSP state information unavailable [This.I-D] 729 for the LSP re-optimization 731 Error-value TBD7: LSP state information for route 732 exclusion purpose cannot be found [This.I-D] 734 This document defines the following new Error-Value: 736 Error-Type Error-Value Reference 738 6 Error-value TBD8: Label Request TLV 739 missing [This.I-D] 741 11. Manageability Considerations 743 The description and functionality specifications presented related 744 to stateful PCEs should also comply with the manageability 745 specifications covered in Section 8 of [RFC4655]. Furthermore, a 746 further list of manageability issues presented in [RFC8231] should 747 also be considered. 749 11.1. Requirements on Other Protocols 751 When the detailed route information is included for LSP state 752 synchronization (either at the initial stage or during LSP state 753 report process), this requires the ingress node of an LSP carry the 754 RRO object in order to enable the collection of such information. 756 12. Security Considerations 758 This draft provides additional extensions to PCEP so as to 759 facilitate stateful PCE usage in GMPLS-controlled networks, on top 760 of [RFC8231]. The PCEP extensions to support GMPLS-controlled 761 networks should be considered under the same security as for MPLS 762 networks, as noted in [RFC7025]. Therefore, the security 763 considerations elaborated in [RFC5440] still apply to this draft. 764 Furthermore, [RFC8231] provides a detailed analysis of the 765 additional security issues incurred due to the new extensions and 766 possible solutions needed to support for the new stateful PCE 767 capabilities and they apply to this document as well. 769 13. Acknowledgement 771 We would like to thank Adrian Farrel, Cyril Margaria, George Swallow 772 and Jan Medved for the useful comments and discussions. 774 14. References 776 14.1. Normative References 778 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 779 requirements levels", RFC 2119, March 1997. 781 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 782 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 783 March 2009. 785 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 786 Path Computation Element Communication Protocol (PCEP) for 787 Route Exclusions", RFC 5521, April 2009. 789 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 790 Key Words", RFC 8174, May 2017. 792 [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path 793 Computation Element Communication Protocol (PCEP) 794 Extensions for Stateful PCE", RFC 8231, September 2017. 796 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 797 Computation Element Communication Protocol (PCEP) 798 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 799 Model", RFC 8281, December 2017. 801 [RFC8779] Margaria, C., Gonzalez de Dios, O., Zhang, F., "Path 802 Computation Element Communication Protocol (PCEP) 803 extensions for GMPLS", RFC 8779, July 2020. 805 14.2. Informative References 807 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of 808 Running Code: The Implementation Status Section", BCP 205, 809 RFC 7942, DOI 10.17487/RFC7942, July 2016, 810 . 812 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 813 Path Computation Element (PCE) ", RFC 8051, January 2017. 815 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 816 and D. Dhody, "Optimizations of Label Switched Path State 817 Synchronization Procedures for a Stateful PCE", RFC 8232, 818 September 2017. 820 [RFC8282] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions 821 to the Path Computation Element communication Protocol 822 (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", 823 RFC 8282, December 2017. 825 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 826 Switching (GMPLS) Signaling Functional Description", RFC 827 3471, January 2003. 829 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 830 Switching (GMPLS) Signaling Resource ReserVation Protocol 831 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 832 January 2003. 834 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 835 Computation Element (PCE)-Based Architecture", RFC 4655, 836 August 2006. 838 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 839 Ed., "RSVP-TE Extensions in Support of End-to-End 840 Generalized Multi-Protocol Label Switching (GMPLS) 841 Recovery", RFC 4872, May 2007. 843 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 844 "GMPLS Segment Recovery", RFC 4873, May 2007. 846 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 847 Used to Form Encoding Rules in Various Routing Protocol 848 Specifications", RFC5511, April 2005. 850 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 851 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 852 Switched Paths (LSPs)", RFC 6387, September 2011. 854 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 855 Margaria, "Requirements for GMPLS Applications of PCE", 856 RFC 7025, September 2013, 858 [RFC7399] Farrel, A., King, D., "Unanswered Questions in the Path 859 Computation Element Architecture", RFC 7399, October 2014. 861 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., Beeram, V., "Stateful 862 Path Computation Element (PCE) Protocol Extensions for 863 Usage with Point-to-Multipoint TE Label Switched Paths 864 (LSPs)" June 2019. 866 15. Contributors' Address 868 Xian Zhang 869 Huawei Technologies 870 Email: zhang.xian@huawei.com 872 Dhruv Dhody 873 Huawei Technology 874 India 875 Email: dhruv.ietf@gmail.com 877 Yi Lin 878 Huawei Technologies 879 Email: yi.lin@huawei.com 880 Fatai Zhang 881 Huawei Technologies 882 Email: zhangfatai@huawei.com 884 Ramon Casellas 885 CTTC 886 Av. Carl Friedrich Gauss n7 887 Castelldefels, Barcelona 08860 888 Spain 889 Email: ramon.casellas@cttc.es 891 Siva Sivabalan 892 Cisco Systems 893 Email: msiva@cisco.com 895 Clarence Filsfils 896 Cisco Systems 897 Email: cfilsfil@cisco.com 899 Robert Varga 900 Pantheon Technologies 901 Email: nite@hq.sk 903 Authors' Addresses 905 Young Lee 906 Samsung 907 Email: younglee.tx@gmail.com 909 Haomian Zheng 910 Huawei Technologies 911 H1, Huawei Xiliu Beipo Village, Songshan Lake 912 Dongguan, Guangdong 523808 913 China 914 Email: zhenghaomian@huawei.com 916 Oscar Gonzalez de Dios 917 Telefonica 918 Phone: +34 913374013 919 Email: oscar.gonzalezdedios@telefonica.com 921 Victor Lopez 922 Nokia 923 Email: victor.lopez@nokia.com 925 Zafar Ali 926 Cisco Systems 927 Email: zali@cisco.com