idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-20.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 27, 2022) is 669 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 information found for draft-ietf-pce-lsp-extended-flags - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-pce-lsp-extended-flags' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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: December 27, 2022 Huawei Technologies 5 O. G. de Dios 6 Telefonica 7 Victor Lopez 8 Nokia 9 Z. Ali 10 Cisco Systems 11 June 27, 2022 13 Path Computation Element Communication Protocol (PCEP) Extensions for 14 Stateful PCE Usage in GMPLS-controlled Networks 16 draft-ietf-pce-pcep-stateful-pce-gmpls-20 18 Abstract 20 The PCE communication Protocol (PCEP) has been extended to support 21 stateful PCE functions where the Stateful PCE maintains information 22 about paths and resource usage within a network, but these 23 extensions do not cover all requirements for GMPLS networks. 25 This document provides the extensions required for PCEP so as to 26 enable the usage of a stateful PCE capability in GMPLS-controlled 27 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 December 27, 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 Revised 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 Revised BSD License. 67 Table of Contents 69 Table of Contents ............................................... 2 70 1. Introduction ................................................. 3 71 1.1. Conventions used in this document ....................... 4 72 2. Terminology .................................................. 4 73 3. General Context of Stateful PCE and PCEP for GMPLS ........... 4 74 4. Main Requirements ............................................ 5 75 5. Overview of Stateful PCEP Extensions for GMPLS Networks ...... 6 76 5.1. Capability Advertisement for Stateful PCEP in GMPLS ..... 6 77 5.2. LSP Synchronization ..................................... 7 78 5.3. LSP Delegation and Cleanup .............................. 7 79 5.4. LSP Operations .......................................... 7 80 6. PCEP Object Extensions ....................................... 8 81 6.1. Existing Extensions used for Stateful GMPLS ............. 8 82 6.2. New Extensions .......................................... 9 83 6.2.1. GMPLS-CAPABILITY TLV in OPEN Object ................ 9 84 6.2.2. New LSP Exclusion Sub-object in the XRO ............ 9 85 6.2.3. New flags in the LSP-EXTENDED-FLAG TLV in LSP Object10 86 7. Update to Error Handling .................................... 11 87 7.1. Error Handling in PCEP Capabilities Advertisement ...... 11 88 7.2. Error Handling in LSP Re-optimization .................. 12 89 7.3. Error Handling in Route Exclusion ...................... 12 90 7.4. Error Handling for generalized END-POINTS .............. 12 91 8. Implementation .............................................. 13 92 8.1. Huawei Technologies .................................... 13 93 9. IANA Considerations ......................................... 14 94 9.1. New Flags in GMPLS-CAPABILITY TLV ...................... 14 95 9.2. New Sub-object for the Exclude Route Object ............ 14 96 9.3. Flags Field for LSP exclusion Sub-object ............... 14 97 9.4. New Flags in the LSP-EXTENDED-FLAGS TLV ............... 15 98 9.5. New PCEP Error Codes ................................... 15 99 10. Manageability Considerations ............................... 16 100 10.1. Control of Function through Configuration and Policy .. 16 101 10.2. Information and Data Models ........................... 16 102 10.3. Liveness Detection and Monitoring ..................... 17 103 10.4. Verifying Correct Operation ........................... 17 104 10.5. Requirements on Other Protocols and Functional Components17 105 10.6. Impact on Network Operation ........................... 17 106 11. Security Considerations .................................... 17 107 12. Acknowledgement ............................................ 18 108 13. References ................................................. 18 109 13.1. Normative References .................................. 18 110 13.2. Informative References ................................ 19 111 14. Contributors' Address ...................................... 21 112 Appendix A: PCEP Messages ...................................... 21 113 A.1 The PCRpt Message ...................................... 22 114 A.2 The PCUpd Message ....................................... 23 115 A.3 The PCInitiate Message .................................. 23 116 Authors' Addresses ............................................. 25 118 1. Introduction 120 [RFC4655] presents the architecture of a Path Computation Element 121 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 122 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 123 Paths (TE LSPs). To perform such a constrained computation, a PCE 124 stores the network topology (i.e., TE links and nodes) and resource 125 information (i.e., TE attributes) in its TE Database (TED). A PCE 126 that only maintains TED is referred to as a stateless PCE. [RFC5440] 127 describes the Path Computation Element Communication Protocol (PCEP) 128 for interaction between a Path Computation Client (PCC) and a PCE, 129 or between two PCEs, enabling computation of TE LSPs. PCEP is 130 further extended to support GMPLS-controlled networks as per 131 [RFC8779]. 133 Stateful PCEs are shown to be helpful in many application scenarios, 134 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. 135 Further discussion of concept of a stateful PCE can be found in 136 [RFC7399]. In order for these applications to able to exploit the 137 capability of stateful PCEs, extensions to stateful PCEP for GMPLS 138 are required. 140 [RFC8051] describes how a stateful PCE can be applicable to solve 141 various problems for MPLS-TE and GMPLS networks and the benefits it 142 brings to such deployments. 144 [RFC8231] specifies a set of extensions to PCEP to enable stateful 145 control of TE LSPs where they are configured on the PCC, and control 146 over them could be delegated to the PCE. Furthermore, [RFC8281] 147 describes the setup and teardown of PCE-initiated LSPs under the 148 active stateful PCE model, without the need for local configuration 149 on the PCC. However, both the documents left out the specification 150 for technology-specific objects/TLVs, and do not cover the GMPLS- 151 controlled networks (e.g., Wavelength Switched Optical Network 152 (WSON), Optical Transport Network (OTN), Synchronous Optical Network 153 (SONET)/Synchronous Digital Hierarchy (SDH), etc. technologies). 155 This document focuses on the extensions that are necessary in order 156 for the deployment of stateful PCEs and the requirements for PCE- 157 initiated LSPs in GMPLS-controlled networks. Section 3 provides a 158 general context of the usage of Stateful PCE and PCEP for GMPLS. 159 The various requirements for stateful GMPLS, including PCE- 160 initiation for GMPLS LSPs, are provided in Section 4. An overview of 161 the PCEP extensions are specified in Section 5, as a solution to 162 address such requirements with PCEP object extensions in Section 6. 164 1.1. Conventions used in this document 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in 169 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 2. Terminology 174 Terminology used in this document is the same as terminology used in 175 [RFC5440], [RFC8231], [RFC8281], and [RFC8779] 177 3. General Context of Stateful PCE and PCEP for GMPLS 179 This section is built on the basis of Stateful PCE specified in 180 [RFC8231] and PCEP for GMPLS specified in [RFC8779]. 182 The operation for Stateful PCE on LSPs can be divided into two types, 183 active stateful PCE and passive stateful PCE as described in 184 [RFC8051]. 186 For active stateful PCE, a Path Computation Update Request (PCUpd) 187 message is sent from PCE to PCC to update the LSP state for the LSPs 188 delegated to the PCE. Any changes to the delegated LSPs generate a 189 Path Computation State Report (PCRpt) message from the PCC to PCE to 190 convey the changes of the LSPs. Any modifications to the 191 Objects/TLVs that are identified in this document to support GMPLS 192 technology-specific attributes will be carried in the PCRpt and 193 PCUpd messages. 195 For passive stateful PCEs, PCReq/PCRep messages are used to request 196 for path computation. GMPLS-technology specific Objects and TLVs 197 are defined in [RFC8779], this document builds on it and adds the 198 stateful PCE aspects where applicable. Passive Stateful PCE makes 199 use of PCRpt messages when reporting LSP State changes sent by PCCs 200 to PCEs. Any modifications to the Objects/TLVs that are identified 201 in this document to support GMPLS technology-specific attributes 202 will be carried in the PCRpt message. 204 Furthermore, the LSP Initiation function of PCEP is defined in 205 [RFC8281] to allow the PCE to initiate LSP establishment after the 206 path is computed. An LSP Initiate Request (PCInitiate) message is 207 used to trigger the end node to set up the LSP. Any modifications to 208 the Objects/TLVs that are identified in this document to support 209 GMPLS technology-specific attributes will be carried in the 210 PCInitiate messages. 212 [RFC8779] defines GMPLS-technology specific Objects/TLVs in 213 stateless PCEP, and this document makes use of these Objects/TLVs 214 without modifications where applicable. Where these Objects/TLVs 215 require modifications to incorporate stateful PCE, they are 216 described in this document. PCE-Initiated LSPs follow the principle 217 specified in [RFC8281], and the GMPLS-specific extensions are also 218 included in this document. 220 4. Main Requirements 222 This section notes the main functional requirements for PCEP 223 extensions to support stateful PCE for use in GMPLS-controlled 224 networks, based on the description in [RFC8051]. Many 225 requirements are common across a variety of network types (e.g., 226 MPLS-TE networks and GMPLS networks) and the protocol extensions to 227 meet the requirements are already described in [RFC8231], such as 228 LSP update, delegation and state synchronization/report. Protection 229 context information that describes the GMPLS requirement can also 230 follow the description in [RFC8745]. This document does not repeat 231 the description of those protocol extensions. This document 232 presents protocol extensions for a set of requirements which are 233 specific to the use of a stateful PCE in a GMPLS-controlled network. 235 The requirements for GMPLS-specific stateful PCE are as follows: 237 o Advertisement of the stateful PCE capability. This generic 238 requirement is covered in Section 5.4 of [RFC8231]. The GMPLS- 239 CAPABILITY TLV specified in section 2.1 of [RFC8779] and its 240 extension in this document needs to be advertised as well. 242 o All the PCEP messages need to be capable of indicating GMPLS- 243 specific switching capabilities. GMPLS LSP 244 creation/modification/deletion requires knowledge of LSP 245 switching capability (e.g., Time-Division Multiplex Capable 246 (TDM), Layer 2 Switch Capable (L2SC), OTN-TDM, Lambda Switch 247 Capable (LSC), etc.) and the generalized payload (G-PID) to be 248 used according to [RFC3471], [RFC3473]. It also requires the 249 specification of data flow specific traffic parameters (also 250 known as Traffic Specification (Tspec)), which are technology 251 specific. Such information would need to be included in various 252 PCEP messages. 254 o In some technologies, path calculation is tightly coupled with 255 label selection along the route. For example, path calculation 256 in a Wavelength Division Multiplexing (WDM) network may include 257 lambda continuity and/or lambda feasibility constraints and 258 hence a path computed by the PCE is associated with a specific 259 lambda (label). Hence, in such networks, the label information 260 needs to be provided to a PCC in order for a PCE to initiate 261 GMPLS LSPs under the active stateful PCE model, i.e., explicit 262 label control may be required. 264 o Stateful PCEP messages also need to indicate the protection 265 context information for the LSP specified by GMPLS, as defined 266 in [RFC4872], [RFC4873]. 268 5. Overview of Stateful PCEP Extensions for GMPLS Networks 270 5.1. Capability Advertisement for Stateful PCEP in GMPLS 272 Capability Advertisement has been specified in [RFC8231], and can be 273 achieved by using the "STATEFUL-PCE-CAPABILITY TLV" in the Open 274 message. Another GMPLS-CAPABILITY TLV has been defined in [RFC8779]. 275 A subregistry to manage the Flag field of the GMPLS-CAPABILITY TLV 276 is created by the IANA as requested by [RFC8779]. The following 277 bits are introduced by this document in the GMPLS-CAPABILITY TLV as 278 flags to indicate the capability for LSP report, update and 279 initiation in GMPLS networks: LSP-REPORT-CAPABILITY(TBDa), LSP- 280 UPDATE-CAPABILITY (TBD1), and LSP-INSTANTIATION-CAPABILITY (TBD2). 282 5.2. LSP Synchronization 284 After the session between the PCC and a stateful PCE is initialized, 285 the PCE must learn the state of a PCC's LSPs (including its 286 attributes) before it can perform path computations or update LSP 287 attributes in a PCC. This process is known as LSP state 288 synchronization. The LSP attributes including bandwidth, associated 289 route, and protection information etc., are stored by the PCE in the 290 LSP database (LSP-DB). Note that, as described in [RFC8231], the 291 LSP state synchronization covers both the bulk reporting of LSPs at 292 initialization as well the reporting of new or modified LSPs during 293 normal operation. Incremental LSP-DB synchronization may be desired 294 in a GMPLS-controlled network and it is specified in [RFC8232]. 296 The format of the PCRpt message is specified in [RFC8231] and 297 extended in [RFC8623] to include the END-POINTS object. The END- 298 POINTS object is extended for GMPLS in [RFC8779]. The END-POINTS 299 object can be carried in the PCRpt message as specified in [RFC8623]. 300 The END-POINTS object type for GMPLS is included in the PCRpt 301 message as per the same. 303 The BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO) and 304 Exclude Route Object (XRO) objects are extended for GMPLS in 305 [RFC8779] and are also used in the PCRpt in the same manner. These 306 objects are carried in the PCRpt message as specified in [RFC8231] 307 (as the attribute-list defined in Section 6.5 of [RFC5440] and 308 extended by many other documents that define PCEP extensions for 309 specific scenarios). 311 The SWITCH-LAYER object is defined in [RFC8282]. This object is 312 carried in PCRpt message as specified in section 3.2 of [RFC8282]. 314 5.3. LSP Delegation and Cleanup 316 LSP delegation and cleanup procedure specified in [RFC8231] are 317 equally applicable to GMPLS LSPs and this document does not modify 318 the associated usage. 320 5.4. LSP Operations 322 Both passive and active stateful PCE mechanisms in [RFC8231] are 323 applicable in GMPLS-controlled networks. Remote LSP Initiation in 324 [RFC8281] is also applicable in GMPLS-controlled networks. 326 6. PCEP Object Extensions 328 6.1. Existing Extensions used for Stateful GMPLS 330 Existing extensions defined in [RFC8779] can be used in the Stateful 331 PCEP with no changes or slightly changes for GMPLS network control, 332 including the following: 334 o END-POINTS: Generalized END-POINTS was specified in [RFC8779] to 335 include GMPLS capabilities. All Stateful PCEP messages MUST include 336 the END-POINTS with Generalized Endpoint object type, containing the 337 LABEL-REQUEST TLV. Further note that 339 * As per [RFC8779] for stateless GMPLS path computation, the 340 Generalized END-POINTS object may contain a LABEL-REQUEST TLV 341 and/or LABEL-SET. In this document, only the LABEL-REQUEST TLV is 342 used to specify the switching type, encoding type and G-PID of the 343 LSP. 345 * If unnumbered endpoint addresses are used for the LSP, the 346 UNNUMBERED-ENDPOINT TLV [RFC8779] MUST be used to specify the 347 unnumbered endpoint addresses. 349 * The Generalized END-POINTS MAY contain other TLVs defined in 350 [RFC8779]. 352 o RP: RP object extension, together with the Routing Granularity 353 (RG) flag defined in [RFC8779], are applicable in the Stateful PCEP 354 for GMPLS networks. 356 o BANDWIDTH: Generalized BANDWIDTH was specified in [RFC8779] to 357 represent GMPLS features, including asymmetric bandwidth and G-PID 358 information. 360 o LSPA: LSPA Extensions in Section 2.8 of [RFC8779] is applicable 361 in Stateful PCEP for GMPLS networks. 363 o IRO: IRO Extensions in Section 2.6 of [RFC8779] is applicable in 364 Stateful PCEP for GMPLS networks. 366 o XRO: XRO Extensions in Section 2.7 of [RFC8779] is applicable in 367 Stateful PCEP for GMPLS networks. A new flag is defined in section 368 7.2.2 of this document. 370 o ERO: The Explicit Route Object (ERO) was not extended in 371 [RFC8779], and nor in this document. 373 o SWITCH-LAYER: SWITCHING-LAYER definition in Section 3.2 of 374 [RFC8282] is applicable in Stateful PCEP messages for GMPLS networks. 376 6.2. New Extensions 378 6.2.1. GMPLS-CAPABILITY TLV in OPEN Object 380 In [RFC8779], IANA has allocated value 45 (GMPLS-CAPABILITY) from 381 the "PCEP TLV Type Indicators" sub-registry. The TLV is extended 382 with three flags to indicate the Report, Update, and Initiation 383 capabilities. 385 R (LSP-REPORT-CAPABILITY(TBDa) -- 1 bit): if set to 1 by a PCC, the 386 R flag indicates that the PCC is capable of reporting the current 387 state of an GMPLS LSP, whenever there's a change to the parameters 388 or operational status of the GMPLS LSP; if set to 1 by a PCE, the R 389 Flag indicates that the PCE is interested in receiving GMPLS LSP 390 State Reports whenever there is a parameter or operational status 391 change to the LSP. The LSP-REPORT-CAPABILITY flag must be 392 advertised by both a PCC and a PCE for PCRpt messages to be allowed 393 on a PCEP session for GMPLS LSP. 395 U (LSP-UPDATE-CAPABILITY(TBD1) -- 1 bit): if set to 1 by a PCC, the 396 U flag indicates that the PCC allows modification of GMPLS LSP 397 parameters; if set to 1 by a PCE, the U flag indicates that the PCE 398 is capable of updating GMPLS LSP parameters. The LSP-UPDATE- 399 CAPABILITY flag must be advertised by both a PCC and a PCE for PCUpd 400 messages to be allowed on a PCEP session for GMPLS LSP. 402 I (LSP-INSTANTIATION-CAPABILITY(TBD2) -- 1 bit): If set to 1 by a 403 PCC, the I flag indicates that the PCC allows instantiation of a 404 GMPLS LSP by a PCE. If set to 1 by a PCE, the I flag indicates that 405 the PCE supports instantiating GMPLS LSPs. The LSP-INSTANTIATION- 406 CAPABILITY flag must be set by both the PCC and PCE in order to 407 enable PCE-initiated LSP instantiation. 409 6.2.2. New LSP Exclusion Sub-object in the XRO 411 [RFC5521] defines a mechanism for a PCC to request or demand that 412 specific nodes, links, or other network resources are excluded from 413 paths computed by a PCE. A PCC may wish to request the computation 414 of a path that avoids all link and nodes traversed by some other LSP. 416 To this end this document defines a new sub-object for use with 417 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 418 is as follows: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |X|Type (TBD3) | Length | Reserved | Flags | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | | 426 // Symbolic Path Name // 427 | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Figure 1: New LSP Exclusion Sub-object Format 432 X bit: Same as the X bit defined in XRO sub-objects by [RFC5521] 433 (i.e., mandatory vs. desired). 435 Type: Sub-object Type for an LSP exclusion sub-object. Value of 436 TBD3. To be assigned by IANA. 438 Length: The Length contains the total length of the sub-object in 439 bytes, including the Type and Length fields. 441 Reserved: MUST be set to zero on transmission and ignored on 442 receipt. 444 Flags: This field may be used to further specify the exclusion 445 constraint with regard to the LSP. Currently, no flags are defined. 447 Symbolic Path Name: This is the identifier given to an LSP and is 448 unique in the context of the PCC address as defined in [RFC8231]. 449 It is worth noting that given that the Symbolic Path Name is 450 unique in the context of the headnode, only LSPs that share the 451 same headnode/PCC could be excluded. 453 This sub-object MAY be present multiple times in the exclude route 454 object (XRO) to exclude resources from multiple LSPs. When a 455 stateful PCE receives a PCReq message carrying this sub-object, it 456 MUST search for the identified LSP in its LSP-DB and then exclude 457 from the new path computation all resources used by the identified 458 LSP. 460 Note that this XRO Sub-object could also be used by non-GMPLS LSPs. 461 The description of usage of non-GMPLS LSPs is not in the scope of 462 this document. 464 6.2.3. New flags in the LSP-EXTENDED-FLAG TLV in LSP Object 466 The LSP Object is defined in Section 7.3 of [RFC8231], and the new 467 extended flags TLV is defined in [I-D.ietf-pce-lsp-extended-flags]. 469 This TLV is used in PCUpd, PCRpt and PCInitiate messages for GMPLS, 470 with the following flags defined in this document. 472 o G (GMPLS LSP(TBDb) -- 1 bit) : If set to 1, it indicates the LSP 473 is a GMPLS LSP. 475 o B (Bidirectional LSP(TBD4) -- 1 bit): If set to 0, it indicates 476 a request to create a uni-directional LSP. If set to 1, it 477 indicates a request to create a bidirectional co-routed LSP. 479 o RG (Routing Granularity(TBDc) -- 2 bits) : RG flag for GMPLS is 480 also defined in the LSP-EXTENDED-FLAG TLV The value are defined as 481 per [RFC8779]: 483 00: reserved 484 01: node 485 10: link 486 11: label 488 7. Update to Error Handling 490 A PCEP-ERROR object is used to report a PCEP error and is 491 characterized by an Error-Type that specifies the type of error and 492 an Error-value that provides additional information about the error. 493 In this document the following error handling procedures are 494 introduced. All the error handling specified in section 3 of 495 [RFC8779] is applicable and MUST be supported for stateful PCE in 496 GMPLS networks. 498 7.1. Error Handling in PCEP Capabilities Advertisement 500 The PCEP extensions described in this document for stateful PCEs 501 with GMPLS capability MUST NOT be used if the PCE has not advertised 502 its stateful capability with GMPLS as per Section 5.2. If the PCC 503 understands the U flag that indicates the stateful LSP-UPDATE- 504 CAPABILITY but did not advertise this capability, then upon receipt 505 of a PCUpd message for GMPLS LSP from the PCE, it SHOULD generate a 506 PCErr with error-type 19 ("Invalid Operation"), error-value TBDx 507 ("Attempted LSP Update Request for GMPLS if stateful PCE capability 508 for GMPLS was not advertised"), and terminate the PCEP session. 510 If the PCE understands the R flag that indicates the stateful LSP- 511 REPORT-CAPABILITY but did not advertise this capability, then upon 512 receipt of a PCRpt message for GMPLS LSP from the PCC, it SHOULD 513 generate a PCErr with error-type 19 ("Invalid Operation"), error- 514 value TBDy ("Attempted LSP Report Request for GMPLS if stateful PCE 515 capability for GMPLS was not advertised"), and terminate the PCEP 516 session. 518 The PCEP extensions described in this document for PCC or PCE with 519 the PCE-Initiation capability for GMPLS LSPs MUST NOT be used if the 520 PCC or PCE has not advertised its stateful capability with 521 Instantiation and GMPLS-CAPABILITY as per [RFC8779]. If the PCC 522 understands the I flag that indicates LSP-INSTANTIATION-CAPABILITY 523 but did not advertise this capability, then upon receipt of a 524 PCInitiate message for GMPLS LSP from the PCE, it SHOULD generate a 525 PCErr with error-type 19 ("Invalid Operation"), error-value TBDz 526 ("Attempted LSP Instantiation Request for GMPLS if stateful PCE 527 instantiation capability for GMPLS was not advertised"), and 528 terminate the PCEP session. 530 7.2. Error Handling in LSP Re-optimization 532 A stateful PCE is expected to perform an LSP re-optimization when 533 receiving a message with the R bit set in the RP object. If no LSP 534 state information is available to carry out re-optimization, the 535 stateful PCE SHOULD report the error "LSP state information 536 unavailable for the LSP re-optimization" (Error Type = 19, Error 537 value= TBD6). Note that this error message could also be used by 538 non-GMPLS LSPs. The PCE MAY suppress this error message by a 539 configurable threshold. 541 7.3. Error Handling in Route Exclusion 543 The LSP exclusion sub-object in XRO is defined in section 6.2.2 of 544 this document MAY be present multiple times. When a stateful PCE 545 receives a PCEP message carrying this sub-object, it searches for 546 the identified LSP in its LSP-DB and then excludes from the new path 547 computation all the resources used by the identified LSP. If the 548 stateful PCE cannot recognize symbolic path name of the identified 549 LSP, it SHOULD send an error message PCErr reporting Error-type = 19 550 ("Invalid Operation"), Error-value = TBD7 ("The LSP state 551 information for route exclusion purpose cannot be found"). 552 Optionally, it may also provide with the unrecognized symbolic path 553 name information to the requesting PCC using the error reporting 554 techniques described in [RFC5440]. However, the PCE MAY suppress 555 this error message by a configurable threshold. 557 7.4. Error Handling for generalized END-POINTS 559 Note that the ENDPOINT object in the Stateful PCEP messages was 560 introduced for P2MP [RFC8623]. Similarly, the END-POINTS object MUST 561 be carried for the GMPLS LSP. If the END-POINTS object is missing 562 and the GMPLS flag in LSP-EXTENDED-FLAG is set, the receiving PCE or 563 PCC MUST send a PCErr message with Error-type=6 ("Mandatory Object 564 missing") and Error-value=3 ("END-POINTS object missing") (defined 565 in [RFC5440]). Similarly, if the END-POINTS object with the 566 Generalized Endpoint object type is received but if the LSP- 567 EXTENDED-FLAG TLV is missing in the LSP object or if the G flag in 568 the LSP-EXTENDED-FLAG TLV is not set, the receiving PCE or PCC MUST 569 send a PCErr message with Error-type = 19 ("Invalid Operation"), 570 Error-value = TBD9 ("Use of Generalized Endpoint object type for 571 non-GMPLS LSP"). 573 If the ENDPOINT object with Generalized Endpoint Object Type is 574 missing the LABEL-REQUEST TLV, the receiving PCE or PCC MUST send a 575 PCErr message with Error-type=6 ("Mandatory Object missing") and 576 Error-value=TBD8 ("LABEL-REQUEST TLV missing"). 578 8. Implementation 580 [NOTE TO RFC EDITOR : This whole section and the reference to RFC 581 7942 is to be removed before publication as an RFC] 583 This section records the status of known implementations of the 584 protocol defined by this specification at the time of posting of 585 this Internet-Draft, and is based on a proposal described in 586 [RFC7942]. The description of implementations in this section is 587 intended to assist the IETF in its decision processes in progressing 588 drafts to RFCs. Please note that the listing of any individual 589 implementation here does not imply endorsement by the IETF. 590 Furthermore, no effort has been spent to verify the information 591 presented here that was supplied by IETF contributors. This is not 592 intended as, and must not be construed to be, a catalog of available 593 implementations or their features. Readers are advised to note that 594 other implementations may exist. 596 According to [RFC7942], "this will allow reviewers and working 597 groups to assign due consideration to documents that have the 598 benefit of running code, which may serve as evidence of valuable 599 experimentation and feedback that have made the implemented 600 protocols more mature. It is up to the individual working groups to 601 use this information as they see fit". 603 8.1. Huawei Technologies 605 o Organization: Huawei Technologies, Co. LTD 606 o Implementation: Huawei NCE-T 607 o Description: PCRpt, PCUpd and PCInitiate messages for GMPLS 608 Network 609 o Maturity Level: Production 610 o Coverage: Full 611 o Contact: zhenghaomian@huawei.com 613 9. IANA Considerations 615 9.1. New Flags in GMPLS-CAPABILITY TLV 617 [RFC8779] defines the GMPLS-CAPABILITY TLV; per that RFC, IANA 618 created a registry to manage the value of the GMPLS-CAPABILITY TLV's 619 Flag field. This document requests IANA to allocate new bits in the 620 GMPLS-CAPABILITY TLV Flag Field registry, as follows: 622 Bit Description Reference 623 --- -------------------------------- ------------- 624 TBDa LSP-REPORT-CAPABILITY (R) [This.I-D] 625 TBD1 LSP-UPDATE-CAPABILITY (U) [This.I-D] 626 TBD2 LSP-INSTANTIATION-CAPABILITY (I) [This.I-D] 628 9.2. New Sub-object for the Exclude Route Object 630 IANA maintains the various XRO Subobjects types within the "XRO 631 Subobjects" subregistry of the PCEP Numbers registry. IANA is 632 requested to allocate a codepoint for another XRO subobject as 633 follows: 635 Value Description Reference 636 ----------+------------------------------+------------- 637 TBD3 LSP [This.I-D] 639 9.3. Flags Field for LSP exclusion Sub-object 641 IANA is requested to create a registry to manage the Flag field of 642 the LSP Exclusion sub-object in the XRO. No Flag is currently 643 defined for this flag field in this document. 645 Codespace of the Flag field (LSP Exclusion sub-object) 646 Bit Description Reference 647 0-7 Unassigned [This.I-D] 649 New values are to be assigned by Standards Action [RFC8126]. 650 Each bit should be tracked with the following qualities: 652 o Bit number (counting from bit 0 as the most significant bit) 653 o Capability description 654 o Defining RFC 656 9.4. New Flags in the LSP-EXTENDED-FLAGS TLV 658 [I-D.ietf-pce-lsp-extended-flags] requested IANA to create a 659 subregistry, named the "LSP-EXTENDED-FLAG TLV Flag Field", within 660 the "Path Computation Element Protocol (PCEP) Numbers" registry, to 661 manage the Flag field of the LSP-EXTENDED-FLAG TLV. 663 IANA is requested to make following assignment from this registry as 664 follows: 666 Bit Description Reference 667 --- ---------------------------- ---------- 668 TBDb GMPLS LSP (G) [This.I-D] 669 TBD4 Bi-directional co-routed LSP (B) [This.I-D] 670 TBDc* Routing Granularity Flag (RG) [This.I-D] 672 * - 2 bits needs to be allocated 674 9.5. New PCEP Error Codes 676 IANA is requested to make the following allocation in the "PCEP- 677 ERROR Object Error Types and Values" registry. 679 +===========+================+=========================+===========+ 680 | Error-Type| Meaning | Error-value | Reference | 681 +===========+================+=========================+===========+ 682 | 6 | Mandatory | TBD8: LABEL-REQUEST TLV | This I-D | 683 | | Object missing | missing | | 684 |-----------|----------------+-------------------------+-----------+ 685 |19 | Invalid | TBD6: LSP state info | This I-D | 686 | | Operation | unavailable for the | | 687 | | | Re-optimization | | 688 | | +-------------------------+-----------+ 689 | | |TBD7: LSP state info for | This I-D | 690 | | |route exclusion not found| | 691 | | +-------------------------+-----------+ 692 | | | TBDx: Attempted LSP | This I-D | 693 | | | Update Request for GMPLS| | 694 | | | if stateful PCE | | 695 | | |capability not advertised| | 696 | | +-------------------------+-----------+ 697 | | |TBDy: Attempted LSP State| This I-D | 698 | | |Report for GMPLS if | | 699 | | |stateful PCE capability | | 700 | | |not advertised | | 701 | | +-------------------------+-----------+ 702 | | |TBDz: Attempted LSP | This I-D | 703 | | |Instantiation Request for| | 704 | | |GMPLS if stateful PCE | | 705 | | |instantiation capability | | 706 | | |not advertised | | 707 | | +-------------------------+-----------+ 708 | | | TBD9: use of Generalized| This I-D | 709 | | | Endpoint object type for| | 710 | | | non-GMPLS LSP | | 711 +-----------+----------------+-------------------------+-----------+ 713 10. Manageability Considerations 715 General PCE management considerations are discussed in [RFC4655] and 716 [RFC5440], and GMPLS specific PCEP management considerations are 717 described in [RFC8779]. In this document the management 718 considerations for stateful PCEP extension in GMPLS are described. 720 This section follows the guidance of [RFC6123]. 722 10.1. Control of Function through Configuration and Policy 724 In addition to the parameters already listed in Section 8.1 of 725 [RFC5440], a PCEP implementation SHOULD allow configuration of the 726 following PCEP session parameters on a PCC: 728 o The ability to send stateful PCEP messages for GMPLS LSPs. 730 o The ability to use path computation constraints (e.g, XRO). 732 In addition to the parameters already listed in Section 8.1 of 733 [RFC5440], a PCEP implementation SHOULD allow configuration of the 734 following PCEP session parameters on a PCE: 736 o The ability to compute path in a stateful manner in GMPLS 737 networks. 739 o A set of GMPLS-specific constraint. 741 These parameters may be configured as default parameters for any 742 PCEP session the PCEP speaker participates in, or they may apply to 743 a specific session with a given PCEP peer or a specific group of 744 sessions with a specific group of PCEP peers. 746 10.2. Information and Data Models 748 The YANG model in [I-D.ietf-pce-pcep-yang] can be used to configure 749 and monitor PCEP states and messages. To make sure that the YANG 750 model is useful for the extensions as described in this document, it 751 would need to include advertised GMPLS stateful capabilities etc. A 752 future version of [I-D.ietf-pce-pcep-yang] will include this. 754 As described in [I-D.ietf-teas-yang-path-computation], a YANG-based 755 interface can be used in some cases to request GMPLS path 756 computations, instead of PCEP. Refer [I-D.ietf-teas-yang-path- 757 computation] for details. 759 10.3. Liveness Detection and Monitoring 761 This document makes no change to the basic operation of PCEP, so 762 there are no changes to the requirements for liveness detection and 763 monitoring in [RFC4657] and [RFC5440], Section 8.3. 765 10.4. Verifying Correct Operation 767 This document makes no change to the basic operations of PCEP and 768 the considerations described in [RFC5440], Section 8.4. New errors 769 defined by this document should satisfy the requirement to log error 770 events. 772 10.5. Requirements on Other Protocols and Functional Components 774 When the detailed route information is included for LSP state 775 synchronization (either at the initial stage or during LSP state 776 report process), this requires the ingress node of an LSP carry the 777 RRO object in order to enable the collection of such information. 779 10.6. Impact on Network Operation 781 This document makes no change to the basic operations of PCEP and 782 the considerations described in [RFC5440], Section 8.6. In addition 783 to the limit on the rate of messages sent by a PCEP speaker, a limit 784 MAY be placed on the size of the PCEP messages. 786 11. Security Considerations 788 The security considerations elaborated in [RFC5440] apply to this 789 document. The PCEP extensions to support GMPLS-controlled networks 790 should be considered under the same security as for MPLS networks, 791 as noted in [RFC7025]. So the PCEP extension to support GMPLS 792 specified in [RFC8779] is used as the foundation of this document 793 and the security considerations in [RFC8779] should also be 794 applicable to this document. The secure transport of PCEP specified 795 in [RFC8253] allows the usage of Transport Layer Security (TLS). 796 The same can also be used by the PCEP extension defined in this 797 document. 799 This draft provides additional extensions to PCEP so as to 800 facilitate stateful PCE usage in GMPLS-controlled networks, on top 801 of [RFC8231] and [RFC8281]. Security issues caused by the extension 802 in [RFC8231] and RFC8281] are not altered by the additions in this 803 draft. The security considerations in [RFC8231] and [RFC8281], 804 including both issues and solutions, apply to this document as well. 806 12. Acknowledgement 808 We would like to thank Adrian Farrel, Cyril Margaria, George Swallow 809 and Jan Medved for the useful comments and discussions. 811 Thanks to Dhruv Dhody for Shepherding this document and providing 812 useful comments. 814 13. References 816 13.1. Normative References 818 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 819 requirements levels", RFC 2119, March 1997. 821 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 822 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 823 March 2009. 825 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 826 Path Computation Element Communication Protocol (PCEP) for 827 Route Exclusions", RFC 5521, April 2009. 829 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 830 Key Words", RFC 8174, May 2017. 832 [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path 833 Computation Element Communication Protocol (PCEP) 834 Extensions for Stateful PCE", RFC 8231, September 2017. 836 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., Dhody, D., "PCEPS: 837 Usage of TLS to Provide a Secure Transport for the Path 838 Computation Element Communication Protocol (PCEP)", RFC 839 8253, October 2017. 841 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 842 Computation Element Communication Protocol (PCEP) 843 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 844 Model", RFC 8281, December 2017. 846 [RFC8779] Margaria, C., Gonzalez de Dios, O., Zhang, F., "Path 847 Computation Element Communication Protocol (PCEP) 848 extensions for GMPLS", RFC 8779, July 2020. 850 [I-D.ietf-pce-lsp-extended-flags] Xiong, Q., "LSP Object Flag 851 Extension of Stateful PCE", Work in progress. 853 13.2. Informative References 855 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of 856 Running Code: The Implementation Status Section", BCP 205, 857 RFC 7942, DOI 10.17487/RFC7942, July 2016, 858 . 860 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 861 Path Computation Element (PCE) ", RFC 8051, January 2017. 863 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 864 and D. Dhody, "Optimizations of Label Switched Path State 865 Synchronization Procedures for a Stateful PCE", RFC 8232, 866 September 2017. 868 [RFC8282] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions 869 to the Path Computation Element communication Protocol 870 (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", 871 RFC 8282, December 2017. 873 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 874 Switching (GMPLS) Signaling Functional Description", RFC 875 3471, January 2003. 877 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 878 Switching (GMPLS) Signaling Resource ReserVation Protocol 879 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 880 January 2003. 882 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 883 Computation Element (PCE)-Based Architecture", RFC 4655, 884 August 2006. 886 [RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation 887 Element (PCE) Communication Protocol Generic Requirements", 888 RFC 4657, September 2006. 890 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 891 Ed., "RSVP-TE Extensions in Support of End-to-End 892 Generalized Multi-Protocol Label Switching (GMPLS) 893 Recovery", RFC 4872, May 2007. 895 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 896 "GMPLS Segment Recovery", RFC 4873, May 2007. 898 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 899 Used to Form Encoding Rules in Various Routing Protocol 900 Specifications", RFC5511, April 2005. 902 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 903 Computation Element (PCE) Working Group Drafts", RFC 6123, 904 February 2011, 906 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 907 Margaria, "Requirements for GMPLS Applications of PCE", 908 RFC 7025, September 2013, 910 [RFC7399] Farrel, A., King, D., "Unanswered Questions in the Path 911 Computation Element Architecture", RFC 7399, October 2014. 913 [RFC8126] Cotton M., Leiba, B., Narten, T., "Guidelines for Writing 914 an IANA Considerations Section in RFCs ", June, 2017. 916 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., Beeram, V., "Stateful 917 Path Computation Element (PCE) Protocol Extensions for 918 Usage with Point-to-Multipoint TE Label Switched Paths 919 (LSPs)" June 2019. 921 [RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 922 Negi, M., "Path Computation Element Communication Protocol 923 (PCEP) Extensions for Associating Working and Protection 924 Label Switched Paths (LSPs) with Stateful PCE", March 2020. 926 [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., 927 Tantsura, J., "A YANG Data Model for Path Computation 928 Element Communications Protocol (PCEP)", Work in progress. 930 [I-D.ietf-teas-yang-path-computation] Busi, I., Belotti, S., 931 Gonzalez de Dios, O., Sharma. A., Ceccarelli, D., "A YANG 932 Data Model for requesting path computation", Work in 933 progress. 935 14. Contributors' Address 937 Xian Zhang 938 Huawei Technologies 939 Email: zhang.xian@huawei.com 941 Dhruv Dhody 942 Huawei Technology 943 India 944 Email: dhruv.ietf@gmail.com 946 Yi Lin 947 Huawei Technologies 948 Email: yi.lin@huawei.com 950 Fatai Zhang 951 Huawei Technologies 952 Email: zhangfatai@huawei.com 954 Ramon Casellas 955 CTTC 956 Av. Carl Friedrich Gauss n7 957 Castelldefels, Barcelona 08860 958 Spain 959 Email: ramon.casellas@cttc.es 961 Siva Sivabalan 962 Cisco Systems 963 Email: msiva@cisco.com 965 Clarence Filsfils 966 Cisco Systems 967 Email: cfilsfil@cisco.com 969 Robert Varga 970 Pantheon Technologies 971 Email: nite@hq.sk 973 Appendix A: PCEP Messages 975 This section uses the Routing Backus-Naur Form (RBNF) [RFC5511] to 976 illustrate the PCEP messages. The RBNF in this section is reproduced 977 for informative purposes. It is also expanded to show the GMPLS 978 specific objects. 980 A.1 The PCRpt Message 982 According to [RFC8231], the PCRpt Message is used to report the 983 current state of an LSP. This document extends the message in 984 reporting the status of LSPs with GMPLS characteristics. 986 The format of the PCRpt message is as follows: 987 ::= 988 989 Where: 991 ::= [] 992 ::= [] 993 994 [] 995 996 Where: 997 ::= 998 [] 999 1000 ::=[] 1001 [] 1003 Where: 1005 The END-POINTS object MUST be carried in a PCRpt message when the 1006 G flag is set in the LSP-EXTENDED-FLAG TLV in the LSP object for a 1007 GMPLS LSP. 1009 is represented by the ERO object defined in 1010 Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label 1011 control (ELC) and Path Keys. 1013 consists of the actual computed and 1014 signaled values of the and objects 1015 defined in [RFC5440]. 1017 is represented by the RRO object defined in 1018 Section 7.10 of [RFC5440]. 1020 is the attribute-list defined in 1021 Section 6.5 of [RFC5440] and extended by many other documents that 1022 define PCEP extensions for specific scenarios as shown below: 1024 ::=[] 1025 [] 1027 [] 1028 [] 1029 [][] 1030 [] 1031 [] 1032 [] 1033 [] 1035 A.2 The PCUpd Message 1037 The format of a PCUpd message is as follows: 1039 ::= 1040 1041 Where: 1042 ::= [] 1044 ::= 1045 1046 [] 1047 1048 Where: 1049 ::= 1051 Where: 1053 The END-POINTS object MUST be carried in a PCUpd message for the 1054 GMPLS LSP. 1056 is represented by the ERO object defined in 1057 Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label 1058 control (ELC) and Path Keys. 1060 is the attribute-list defined in 1061 [RFC5440] and extended by many other documents that define PCEP 1062 extensions for specific scenarios and as shown for PCRpt above. 1064 A.3 The PCInitiate Message 1066 According to [RFC8281], the PCInitiate Message is used allow LSP 1067 Initiation. This document extends the message in initiating LSPs 1068 with GMPLS characteristics. The format of a PCInitiate message is 1069 as follows: 1071 ::= 1072 1073 Where: 1075 is defined in [RFC5440]. 1077 ::= 1078 [] 1079 ::= (| 1081 ) 1082 ::= 1083 1084 [] 1085 1086 [] 1087 ::= 1088 1090 The format of the PCInitiate message is unchanged from Section 5.1 1091 of [RFC8281]. All fields are similar to the PCRpt and the PCUpd 1092 message. 1094 Authors' Addresses 1096 Young Lee 1097 Samsung 1098 Email: younglee.tx@gmail.com 1100 Haomian Zheng 1101 Huawei Technologies 1102 H1, Huawei Xiliu Beipo Village, Songshan Lake 1103 Dongguan, Guangdong 523808 1104 China 1105 Email: zhenghaomian@huawei.com 1107 Oscar Gonzalez de Dios 1108 Telefonica 1109 Phone: +34 913374013 1110 Email: oscar.gonzalezdedios@telefonica.com 1112 Victor Lopez 1113 Nokia 1114 Email: victor.lopez@nokia.com 1116 Zafar Ali 1117 Cisco Systems 1118 Email: zali@cisco.com