idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-11.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 57 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 41 has weird spacing: '... months and ...' == Line 42 has weird spacing: '... at any time...' == Line 43 has weird spacing: '...ference mate...' == Line 357 has weird spacing: '...orm the re-...' == Line 447 has weird spacing: '... P flag and...' -- The document date (March 25, 2019) is 1860 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) == Missing Reference: 'RFC 5440' is mentioned on line 120, but not defined == Missing Reference: 'RFC7399' is mentioned on line 127, but not defined == Missing Reference: 'RFC5521' is mentioned on line 400, but not defined == Missing Reference: 'RFC7025' is mentioned on line 665, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 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 H. Zheng (Editor) 3 Intended status: Standards Track Huawei 4 Expires: September 26, 2019. 5 O. G. de Dios 6 V. Lopez 7 Telefonica 9 Zafar Ali 10 Cisco Systems 12 March 25, 2019 14 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 15 Usage in GMPLS-controlled Networks 17 draft-ietf-pce-pcep-stateful-pce-gmpls-11 19 Abstract 21 The Path Computation Element (PCE) facilitates Traffic Engineering 22 (TE) based path calculation in large, multi-domain, multi-region, or 23 multi-layer networks. The PCE communication Protocol (PCEP) has been 24 extended to support stateful PCE functions where the PCE retains 25 information about the paths already present in the network, but 26 those extensions are technology-agnostic. This memo provides 27 extensions required for PCEP so as to enable the usage of a stateful 28 PCE capability in GMPLS-controlled networks. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with 33 the provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other 42 documents at any time. It is inappropriate to use Internet-Drafts 43 as reference material or to cite them other than as "work in 44 progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on September 26, 2019. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with 64 respect to this document. Code Components extracted from this 65 document must include Simplified BSD License text as described in 66 Section 4.e of the Trust Legal Provisions and are provided without 67 warranty as described in the Simplified BSD License. 69 Table of Contents 71 Table of Contents.................................................2 72 1. Introduction...................................................3 73 2. Conventions used in this document..............................4 74 3. Context of Stateful PCE and PCEP for GMPLS.....................4 75 4. Main Requirements..............................................5 76 5. PCEP Extensions for Generic Stateful GMPLS.....................6 77 5.1. LSP Update in GMPLS-controlled Networks...................6 78 5.2. LSP Synchronization in GMPLS-controlled Networks..........7 79 5.3. Modification of Existing PCEP Messages and Procedures.....8 80 5.3.1. Modification for LSP Re-optimization.................8 81 5.3.2. Modification for Route Exclusion.....................9 82 5.3.3. Modification for SRP Object to indicate Bi-directional 83 LSP........................................................10 84 5.4. Object Encoding..........................................10 85 6. PCEP Extensions for Remote-Initiated GMPLS LSPs...............10 86 6.1. Generalized Endpoint in LSP Initiate Message.............10 87 6.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message.....11 88 6.3. Protection Attributes in LSP Initiate Message............12 89 6.4. ERO in LSP Initiate Object...............................12 90 6.4.1. ERO with explicit label control.....................12 91 6.4.2. ERO with Path Keys..................................12 92 6.4.3. Switch Layer Object.................................13 93 6.5. LSP Delegation and Cleanup...............................13 94 7. IANA Considerations...........................................14 95 7.1. New PCEP Error Codes.....................................14 96 7.2. New Subobject for the Exclude Route Object...............14 97 7.3. New "B" Flag in the SRP Object...........................14 98 8. Manageability Considerations..................................15 99 8.1. Requirements on Other Protocols and Functional Components15 100 9. Security Considerations.......................................15 101 10. Acknowledgement..............................................15 102 11. References...................................................15 103 11.1. Normative References....................................15 104 11.2. Informative References..................................16 105 12. Contributors' Address........................................18 106 Authors' Addresses...............................................20 108 1. Introduction 110 [RFC4655] presents the architecture of a Path Computation Element 111 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 112 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 113 Paths (TE LSPs). To perform such a constrained computation, a PCE 114 stores the network topology (i.e., TE links and nodes) and resource 115 information (i.e., TE attributes) in its TE Database (TED). Such a 116 PCE is usually referred as a stateless PCE. To request path 117 computation services to a PCE, [RFC5440] defines the PCE 118 communication Protocol (PCEP) for interaction between a Path 119 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 120 specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP 121 extensions needed for GMPLS-controlled networks are provided in 122 [PCEP-GMPLS]. 124 Stateful PCEs are shown to be helpful in many application scenarios, 125 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. 126 Further discussion of concept of a stateful PCE can be found in 127 [RFC7399]. In order for these applications to able to exploit the 128 capability of stateful PCEs, extensions to PCEP are required. 130 [RFC8051] describes how a stateful PCE can be applicable to solve 131 various problems for MPLS-TE and GMPLS networks and the benefits it 132 brings to such deployments. 134 [RFC8231] provides the fundamental extensions needed for stateful 135 PCE to support general functionality, but leaves out the 136 specification for technology-specific objects/TLVs. This document 137 focuses on the extensions that are necessary in order for the 138 deployment of stateful PCEs in GMPLS-controlled networks. Section 3 139 provides general context of Stateful PCE and PCEP for GMPLS. 141 [RFC8281] describes the setup and teardown of PCE-initiated LSPs 142 under the active stateful PCE model, without the need for local 143 configuration on the PCC. This enables realization of a dynamic 144 network that is centrally controlled and deployed. However, this 145 specification is focused on MPLS networks, and does not cover the 146 GMPLS networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies). 147 This document complements [RFC8281] by addressing the requirements 148 for remote-initiated GMPLS LSPs. These requirements are covered in 149 Section 4 of this draft. The PCEP extensions for remote initiated 150 GMPLS LSPs are specified in Section 5.5. 152 2. Conventions used in this document 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in 157 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 3. Context of Stateful PCE and PCEP for GMPLS 162 This document is built on the basis of Stateful PCE [RFC8231] and 163 PCEP for GMPLS [PCEP-GMPLS]. 165 There are two types of LSP operation for 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 [PCEP-GMPLS], so this document just points 177 at 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 [PCEP-GMPLS] defines GMPLS-technology specific Objects/TLVs and this 184 document makes use of these Objects/TLVs without modifications where 185 applicable. Some of these Objects/TLVs may require modifications to 186 incorporate stateful PCE element where applicable. 188 4. Main Requirements 190 This section notes the main functional requirements for PCEP 191 extensions to support stateful PCE for use in GMPLS-controlled 192 networks, based on the description in [RFC8051]. Many 193 requirements are common across a variety of network types (e.g., 194 MPLS-TE networks and GMPLS networks) and the protocol extensions to 195 meet the requirements are already described in [RFC8231]. This 196 document does not repeat the description of those protocol 197 extensions. This document presents protocol extensions for a set of 198 requirements which are specific to the use of a stateful PCE in a 199 GMPLS-controlled network. 201 The basic requirements are as follows: 203 o Advertisement of the stateful PCE capability. This generic 204 requirement is covered in Section 5.4. of [RFC8231]. This 205 document assumes that STATEFUL-PCE-CAPABILITY TLV can be used 206 for GMPLS Stateful PCE capability and therefore does not 207 provide any further extensions. 209 o LSP delegation is already covered in Section 5.7. of [RFC8231]. 210 Section 2.2. of this document does not provide any further 211 extensions. 213 o Active LSP update is covered in Section 6.2 of [RFC8231]. 214 Section 5.1. of this document provides extension for its 215 application in GMPLS-controlled networks. 217 o LSP state synchronization and LSP state report. This is a 218 generic requirement already covered in Section 5.6. of 219 [RFC8231]. However, there are further extensions required 220 specifically for GMPLS-controlled networks and discussed in 221 Section 5.2. 223 The requirements for Remote-Initiated GMPLS LSPs are as follows: 225 o GMPLS support multiple switching capabilities on per TE link 226 basis. GMPLS LSP creation requires knowledge of LSP switching 227 capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) to be used 228 [RFC3471], [RFC3473]. 230 o GMPLS LSP creation requires knowledge of the encoding type (e.g., 231 lambda photonic, Ethernet, SONET/ SDH, G709 OTN, etc.) to be 232 used by the LSP [RFC3471], [RFC3473]. 234 o GMPLS LSP creation requires information of the generalized 235 payload (G-PID) to be carried by the LSP [RFC3471], [RFC3473]. 237 o GMPLS LSP creation requires specification of data flow specific 238 traffic parameters (also known as Tspec), which are technology 239 specific. 241 o GMPLS also specifics support for asymmetric bandwidth requests 242 [RFC6387]. 244 o GMPLS extends the addressing to include unnumbered interface 245 identifiers, as defined in [RFC3477]. 247 o In some technologies path calculation is tightly coupled with 248 label selection along the route. For example, path calculation 249 in a WDM network may include lambda continuity and/ or lambda 250 feasibility constraints and hence a path computed by the PCE is 251 associated with a specific lambda (label). Hence, in such 252 networks, the label information needs to be provided to a PCC in 253 order for a PCE to initiate GMPLS LSPs under the active stateful 254 PCE model. I.e., explicit label control may be required. 256 o GMPLS specifics protection context for the LSP, as defined in 257 [RFC4872], [RFC4873]. 259 5. PCEP Extensions for Generic Stateful GMPLS 261 5.1. LSP Update in GMPLS-controlled Networks 263 [RFC8231] defines the Path Computation LSP Update Request (PCUpd) 264 message to enable to update the attributes of an LSP. However, that 265 document does not define technology-specific parameters. 267 A key element of the PCUpd message is the attribute-list construct 268 defined in [RFC5440] and extended by many other PCEP specifications. 270 For GMPLS purposes we note that the BANDWIDTH object used in the 271 attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional 272 TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be 273 included to indicate technology-specific attributes. There are other 274 technology-specific attributes that need to be conveyed in the 275 of the construct in the PCUpd 276 message. Note that these path details in the PCUpd message are the 277 same as the of the PCRep message. See Section 4.2 278 for the details. 280 5.2. LSP Synchronization in GMPLS-controlled Networks 282 PCCs need to report the attributes of LSPs to the PCE to enable 283 stateful operation of a GMPLS network. This process is known as 284 LSP state synchronization. The LSP attributes include bandwidth, 285 associated route, and protection information etc., are stored by the 286 PCE in the LSP database (LSP-DB). Note that, as described in 287 [RFC8231], the LSP state synchronization covers both the bulk 288 reporting of LSPs at initialization as well the reporting of new or 289 modified LSP during normal operation. Incremental LSP-DB 290 synchronization may be desired in a GMPLS-controlled network and it 291 is specified in [RFC8232]. 293 [RFC8231] describes mechanisms for LSP synchronization using the 294 Path Computation State Report (PCRpt) message, but does not cover 295 reporting of technology-specific attributes. As stated in [RFC8231], 296 the construct is further composed of a compulsory Explicit 297 Route Object (ERO) and a compulsory attribute-list and an optional 298 Record Route Object (RRO). In order to report LSP states in GMPLS 299 networks, this specification allows the use within a PCRpt message 300 both of technology- and GMPLS-specific attribute objects and TLVs 301 defined in [PCEP-GMPLS] as follows: 303 o Include Route Object (IRO)/ Exclude Route Object (XRO) 304 Extensions to support the inclusion/exclusion of labels and 305 label sub-objects for GMPLS. (See Section 2.6 and 2.7 in [PCEP- 306 GMPLS]) 308 o END-POINTS (Generalized END-POINTS Object Type. See Section 2.5 309 in [PCEP-GMPLS]) 311 o BANDWIDTH (Generalized BANDWIDTH Object Type. See Section 2.3 312 in [PCEP-GMPLS]) 314 o LSPA (PROTECTION ATTRIBUTE TLV, See Section 2.8 in [PCEP-GMPLS]. 316 The END-POINTS object SHOULD be carried within the attribute-list to 317 specify the endpoints pertaining to the reported LSP. The XRO object 318 MAY be carried to specify the network resources that the reported 319 LSP avoids and a PCE SHOULD consider avoid these network resources 320 during the process of re-optimizing after this LSP is delegated to 321 the PCE. To be more specific, the is updated as 322 follows using the notations of [RFC5511]: 324 ::= [] 325 [] 326 [] 327 [] 328 [] 329 [] 331 ::= [] 333 If the LSP being reported protects another LSP, the PROTECTION- 334 ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to 335 describe its attributes and restrictions. Moreover, if the status of 336 the protecting LSP changes from non-operational to operational, the 337 PCC SHOULD synchronize the state change of the LSPs to the stateful 338 PCE using a PCRpt message. This use case arises, for example, when 339 the protecting LSP becomes operational due to the failure of the 340 primary LSP. 342 5.3. Modification of Existing PCEP Messages and Procedures 344 One of the advantages mentioned in [RFC8051] is that the stateful 345 nature of a PCE simplifies the information conveyed in PCEP messages, 346 notably between PCC and PCE, since it is possible to refer to PCE 347 managed state for active LSPs. To be more specific, with a stateful 348 PCE, it is possible to refer to an LSP with a unique identifier in 349 the scope of the PCC-PCE session and thus use such identifier to 350 refer to that LSP. Note this is also applicable to packet networks. 352 5.3.1. Modification for LSP Re-optimization 354 The Request Parameters (RP) object on a Path Computation Request 355 (PCReq) message carries the R bit. When set, this indicates that 356 the PCC is requesting re-optimization of an existing LSP. Upon 357 receiving such a PCReq, a stateful PCE SHOULD perform the re- 358 optimization in the following cases: 360 o The existing bandwidth and route information of the LSP to be 361 re-optimized is provided in the PCReq message using the 362 BANDWIDTH object and the ERO. 364 o The existing bandwidth and route information is not supplied 365 in the PCReq message, but can be found in the PCE's LSP-DB. 366 In this case, the LSP MUST be identified using an LSP 367 identifier carried in the PCReq message, and that fact 368 requires that the LSP identifier was previously supplied 369 either by the PCC in a PCRpt message or by the PCE in a PCRep 370 message. [RFC8231] defines how this is achieved using a 371 combination of the per-node LSP identifier (PLSP-ID) and the 372 PCC's address. 374 If no LSP state information is available to carry out re- 375 optimization, the stateful PCE should report the error "LSP state 376 information unavailable for the LSP re-optimization" (Error Type = 377 TBD1, Error value= TBD2). 379 5.3.2. Modification for Route Exclusion 381 [RFC5521] defines a mechanism for a PCC to request or demand that 382 specific nodes, links, or other network resources are excluded from 383 paths computed by a PCE. A PCC may wish to request the computation 384 of a path that avoids all link and nodes traversed by some other LSP. 386 To this end this document defines a new sub-object for use with 387 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 388 is as follows: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 |X|Type (TBD3) | Length | Attributes | Flag | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | | 396 // Symbolic Path Name // 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 X bit and Attribute fields are defined in [RFC5521]. 402 Type: Subobject Type for an LSP exclusion sub-object. Value of 403 TBD3. To be assigned by IANA. 405 Length: The Length contains the total length of the subobject in 406 bytes, including the Type and Length fields. 408 Flags: This field may be used to further specify the exclusion 409 constraint with regard to the LSP. Currently, no values are 410 defined. 412 Symbolic Path Name: This is the identifier given to an LSP and is 413 unique in the context of the PCC address as defined in [RFC8231]. 415 Reserved: MUST be transmitted as zero and SHOULD be ignored on 416 receipt. 418 This sub-object is OPTIONAL in the exclude route object (XRO) and 419 can be present multiple times. When a stateful PCE receives a PCReq 420 message carrying this sub-object, it SHOULD search for the 421 identified LSP in its LSP-DB and then exclude from the new path 422 computation all resources used by the identified LSP. If the 423 stateful PCE cannot recognize one or more of the received LSP 424 identifiers, it should send an error message PCErr reporting "The 425 LSP state information for route exclusion purpose cannot be found" 426 (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide 427 with the unrecognized identifier information to the requesting PCC 428 using the error reporting techniques described in [RFC5440]. 430 5.3.3. Modification for SRP Object to indicate Bi-directional LSP 432 The format of the SRP object is defined in [RFC8231]. The object is 433 used in PCUpd and PCInit messages for GMPLS. 435 This document defines a new flag to be carried in the Flags field of 436 the SRP object. This flag indicates a bidirectional co-routed LSP 437 setup operation initiated by the PCE as follows: 439 o B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a 440 request to create a uni-directional LSP. If set to 1, it 441 indicates a request to create a bidirectional co-routed LSP. 443 The bit position is TBD5 as assigned by IANA (see Section 5.3) 445 5.4. Object Encoding 447 Note that, as is stated in Section 7 of [RFC8231], the P flag and 448 the I flag of the PCEP objects used on PCUpd and PCRpt messages 449 SHOULD be set to 0 on transmission and SHOULD be ignored on receipt 450 since these flags are exclusively related to path computation 451 requests. 453 6. PCEP Extensions for Remote-Initiated GMPLS LSPs 455 LSP initiate (PCInitiate) message defined in [RFC8281] needs to be 456 extended to include GMPLS specific PCEP objects as follows: 458 6.1. Generalized Endpoint in LSP Initiate Message 460 This document does not modify the usage of END-POINTS object for PCE 461 initiated LSPs as specified in [RFC8281] . It augments the usage as 462 specified below. 464 END-POINTS object has been extended by [PCEP-GMPLS] to include a new 465 object type called "Generalized Endpoint". PCInitiate message sent 466 by a PCE to a PCC to trigger a GMPLS LSP instantiation SHOULD 467 include the END-POINTS with Generalized Endpoint object type. 468 Furthermore, the END-POINTS object MUST contain "label request" TLV. 469 The label request TLV is used to specify the switching type, 470 encoding type and GPID of the LSP being instantiated by the PCE. 472 If the END-POINTS Object of type Generalized Endpoint is missing the 473 label request TLV, the PCC MUST send a PCErr message with Error- 474 type=6 (Mandatory Object missing) and Error-value= TBA (label 475 request TLV missing). 477 If the PCC does not support the END-POINTS Object of type 478 Generalized Endpoint, the PCC MUST send a PCErr message with Error- 479 type = 3(Unknown Object), Error-value = 2(unknown object type). 481 The unnumbered endpoint TLV can be used to specify unnumbered 482 endpoint addresses for the LSP being instantiated by the PCE. The 483 END-POINTS MAY contain other TLVs defined in [PCEP-GMPLS]. 485 6.2. GENERALIZED-BANDWIDTH object in LSP Initiate Message 487 LSP initiate message defined in [RFC8281] can optionally include the 488 BANDWIDTH object. However, the following possibilities cannot be 489 represented in the BANDWIDTH object: 491 o Asymmetric bandwidth (different bandwidth in forward and 492 reverse direction), as described in [RFC6387]. 494 o Technology specific GMPLS parameters (e.g., Tspec for 495 SDH/SONET, G.709, ATM, MEF, etc.) are not supported. 497 GENERALIZED-BANDWIDTH object has been defined in 498 [PCEP-GMPLS] to address the above-mentioned 499 limitation of the BANDWIDTH object. 501 This document specifies the use of GENERALIZED-BANDWIDTH object in 502 PCInitiate message. Specifically, GENERALIZED-BANDWIDTHobject MAY 503 be included in the PCInitiate message. The GENERALIZED-BANDWIDTH 504 object in PCInitiate message is used to specify technology specific 505 Tspec and asymmetrical bandwidth values for the LSP being 506 instantiated by the PCE. 508 6.3. Protection Attributes in LSP Initiate Message 510 This document does not modify the usage of LSPA object for PCE 511 initiated LSPs as specified in [RFC8281] . It augments the usage of 512 LSPA object in LSP Initiate Message to carry the end-to-end 513 protection context this also includes the protection state 514 information. 516 The LSP Protection Information TLV of LSPA in the PCInitiate message 517 can be used to specify protection attributes of the LSP being 518 instantiated by the PCE. 520 6.4. ERO in LSP Initiate Object 522 This document does not modify the usage of ERO object for PCE 523 initiated LSPs as specified in [RFC8281]. It augments the usage as 524 specified in the following sections. 526 6.4.1. ERO with explicit label control 528 As mentioned earlier, there are technologies and scenarios where 529 active stateful PCE requires explicit label control in order to 530 instantiate an LSP. 532 Explicit label control (ELC) is a procedure supported by RSVP-TE, 533 where the outgoing label(s) is (are) encoded in the ERO. [PCEP-GMPLS] 534 extends the ERO object of PCEP to include explicit label control. 535 The ELC procedure enables the PCE to provide such label(s) directly 536 in the path ERO. 538 The extended ERO object in PCInitiate message can be used to specify 539 label along with ERO to PCC for the LSP being instantiated by the 540 active stateful PCE. 542 6.4.2. ERO with Path Keys 544 There are many scenarios in packet and optical networks where the 545 route information of an LSP may not be provided to the PCC for 546 confidentiality reasons. A multi-domain or multi-layer network is 547 an example of such networks. Similarly, a GMPLS User- Network 548 Interface (UNI) [RFC4208] is also an example of such networks. 550 In such scenarios, ERO containing the entire route cannot be 551 provided to PCC (by PCE). Instead, PCE provides an ERO with Path 552 Keys to the PCC. For example, in the case UNI interface between the 553 router and the optical nodes, the ERO in the LSP Initiate Message 554 may be constructed as follows: 556 o The first hop is a strict hop that provides the egress 557 interface information at PCC. This interface information is 558 used to get to a network node that can extend the rest of the 559 ERO. (Please note that in the cases where the network node is 560 not directly connected with the PCC, this part of ERO may 561 consist of multiple hops and may be loose). 563 o The following(s) hop in the ERO may provide the network node 564 with the path key [RFC5520] that can be resolved to get the 565 contents of the route towards the destination. 567 o There may be further hops but these hops may also be encoded 568 with the path keys (if needed). 570 This document does not change encoding or processing roles for the 571 path keys, which are defined in [RFC5520]. 573 6.4.3. Switch Layer Object 575 [I-D.ietf-pce-inter-layer-ext] specifies the SWITCH-LAYER object 576 which defines and specifies the switching layer (or layers) in which 577 a path MUST or MUST NOT be established. A switching layer is 578 expressed as a switching type and encoding type. [PCEP-GMPLS], which 579 defines the GMPLS extensions for PCEP, suggests using the SWITCH- 580 LAYER object. Thus, SWITCH-LAYER object can be used in the 581 PCInitiate message to specify the switching layer (or layers) of the 582 LSP being remotely initiated. 584 6.5. LSP Delegation and Cleanup 586 LSP delegation and cleanup procedure specified in [PCEP-GMPLS] are 587 equally applicable to GMPLS LSPs and this document does not modify 588 the associated usage. 590 7. IANA Considerations 592 7.1. New PCEP Error Codes 594 IANA is requested to make the following allocation in the "PCEP- 595 ERROR Object Error Types and Values" registry. 597 Error Type Meaning Reference 599 TBD1 LSP state information missing [This.I-D] 601 Error-value TBD2: LSP state information unavailable [This.I-D] 602 for the LSP re-optimization 604 Error-value TBD4: LSP state information for route 605 exclusion purpose cannot be found [This.I-D] 607 This document defines the following new Error-Value: 609 Error-Type Error-Value Reference 611 6 Error-value TBD5: Label Request TLV 612 missing [This.I-D] 614 7.2. New Subobject for the Exclude Route Object 616 IANA maintains the "PCEP Parameters" registry containing a 617 subregistry called "PCEP Objects". This registry has a subregistry 618 for the XRO (Exclude Route Object) listing the sub-objects that can 619 be carried in the XRO. IANA is requested to assign a further sub- 620 object that can be carried in the XRO as follows: 622 Value Description Reference 624 ----------+------------------------------+------------- 626 TBD3 LSP identifier sub-object [This.I-D] 628 7.3. New "B" Flag in the SRP Object 630 IANA maintains a subregistry, named the "SRP Object Flag Field", 631 within the "Path Computation Element Protocol (PCEP) Numbers" 632 registry, to manage the Flag field of the SRP object. 634 IANA is requested to make an assignment from this registry as 635 follows: 637 Bit Description Reference 638 --- ---------------------------- ---------- 640 TDB5 Bi-directional co-routed LSP [This.I-D] 642 8. Manageability Considerations 644 The description and functionality specifications presented related 645 to stateful PCEs should also comply with the manageability 646 specifications covered in Section 8 of [RFC4655]. Furthermore, a 647 further list of manageability issues presented in [RFC8231] should 648 also be considered. 650 Additional considerations are presented in the next section. 652 8.1. Requirements on Other Protocols and Functional Components 654 When the detailed route information is included for LSP state 655 synchronization (either at the initial stage or during LSP state 656 report process), this requires the ingress node of an LSP carry the 657 RRO object in order to enable the collection of such information. 659 9. Security Considerations 661 This draft provides additional extensions to PCEP so as to 662 facilitate stateful PCE usage in GMPLS-controlled networks, on top 663 of [RFC8231]. The PCEP extensions to support GMPLS-controlled 664 networks should be considered under the same security as for MPLS 665 networks, as noted in [RFC7025]. Therefore, the security 666 considerations elaborated in [RFC5440] still apply to this draft. 667 Furthermore, [RFC8231] provides a detailed analysis of the 668 additional security issues incurred due to the new extensions and 669 possible solutions needed to support for the new stateful PCE 670 capabilities and they apply to this document as well. 672 10. Acknowledgement 674 We would like to thank Adrian Farrel, Cyril Margaria, George Swallow 675 and Jan Medved for the useful comments and discussions. 677 11. References 679 11.1. Normative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 682 requirements levels", RFC 2119, March 1997. 684 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 685 Computation Element (PCE)-Based Architecture", RFC 4655, 686 August 2006. 688 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 689 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 690 March 2009. 692 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 693 Key Words", RFC 8174, May 2017. 695 [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path 696 Computation Element Communication Protocol (PCEP) 697 Extensions for Stateful PCE", RFC 8231, September 2017. 699 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 700 Computation Element Communication Protocol (PCEP) 701 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 702 Model", RFC 8281, December 2017. 704 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 705 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 706 extensions, work in progress. 708 11.2. Informative References 710 [RFC5511] A. Farrel, "Routing Backus-Naur Form (RBNF): A Syntax Used 711 to Form Encoding Rules in Various Routing Protocol 712 Specifications", RFC 5511, April 2009. 714 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 715 Path Computation Element (PCE) ", RFC 8051, January 2017. 717 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 718 and D. Dhody, "Optimizations of Label Switched Path State 719 Synchronization Procedures for a Stateful PCE", RFC 8232, 720 September 2017. 722 [I-D.ietf-pce-inter-layer-ext] Oki, E., Takeda, T., Farrel, A., and 723 F. Zhang, "Extensions to the Path Computation Element 724 communication Protocol (PCEP) for Inter-Layer MPLS and 725 GMPLS Traffic Engineering", draft-ietf-pce-inter-layer-ext. 726 work in progress. 728 [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label 729 Switching (GMPLS) Signaling Functional Description", RFC 730 3471, January 2003. 732 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 733 Switching (GMPLS) Signaling Resource ReserVation Protocol 734 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 735 January 2003. 737 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 738 in Resource ReSerVation Protocol - Traffic Engineering 739 (RSVP-TE)", RFC 3477, January 2003. 741 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 742 "Generalized Multiprotocol Label Switching (GMPLS) User 743 Network Interface (UNI): Resource ReserVation Protocol- 744 Traffic Engineering (RSVP-TE) Support for the Overlay 745 Model", RFC 4208, October 2005. 747 [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 748 Ed., "RSVP-TE Extensions in Support of End-to-End 749 Generalized Multi-Protocol Label Switching (GMPLS) 750 Recovery", RFC 4872, May 2007. 752 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 753 "GMPLS Segment Recovery", RFC 4873, May 2007. 755 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 756 "Preserving Topology Confidentiality in Inter-Domain Path 757 Computation Using a Path-Key-Based Mechanism", RFC 5520, 758 April 2009. 760 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 761 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 762 Switched Paths (LSPs)", RFC 6387, September 2011. 764 12. Contributors' Address 766 Xian Zhang 767 Huawei Technologies 768 F3-5-B R&D Center, Huawei Base 769 Bantian, Longgang District 770 Shenzhen 518129 P.R.China 772 Phone: +86-755-28972645 773 Email: zhang.xian@huawei.com 775 Dhruv Dhody 776 Huawei Technology 777 India 779 Email: dhruv.ietf@gmail.com 781 Yi Lin 782 Huawei Technologies 783 F3-5-B R&D Center, Huawei Base 784 Bantian, Longgang District 785 Shenzhen 518129 P.R.China 787 Phone: +86-755-28972914 788 Email: yi.lin@huawei.com 790 Fatai Zhang 791 Huawei 792 F3-5-B R&D Center, Huawei Base 793 Bantian, Longgang District 794 P.R. China 796 Phone: +86-755-28972912 797 Email: zhangfatai@huawei.com 799 Ramon Casellas 800 CTTC 801 Av. Carl Friedrich Gauss n7 802 Castelldefels, Barcelona 08860 803 Spain 805 Phone: 806 Email: ramon.casellas@cttc.es 808 Siva Sivabalan 809 Cisco Systems 810 Email: msiva@cisco.com 812 Clarence Filsfils 813 Cisco Systems 815 Email: cfilsfil@cisco.com 817 Robert Varga 818 Pantheon Technologies 820 Email: nite@hq.sk 822 Authors' Addresses 824 Young Lee (Editor) 825 Huawei 826 5340 Legacy Drive, Suite 170 827 Plano, TX 75023 828 US 830 Phone: +1 469 278 5838 831 EMail: leeyoung@huawei.com 833 Haomian Zheng (Editor) 834 Huawei Technologies 835 H1-1-A043S Huawei Industrial Base, Songshanhu 836 Dongguan, Guangdong 523808 837 P.R.China 839 Email: zhenghaomian@huawei.com 841 Oscar Gonzalez de Dios 842 Telefonica Investigacion y Desarrollo 843 Emilio Vargas 6 844 Madrid, 28045 845 Spain 847 Phone: +34 913374013 848 Email: ogondio@tid.es 850 Victor Lopez 851 Telefonica 853 Email: victor.lopezalvarez@telefonica.com 855 Zafar Ali 856 Cisco Systems 857 Email: zali@cisco.com