idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-06.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 == Line 41 has weird spacing: '... months and ...' == Line 42 has weird spacing: '... at any time...' == Line 43 has weird spacing: '...ference mate...' == Line 261 has weird spacing: '...orm the re-...' == Line 277 has weird spacing: '...rry out re-...' -- The document date (November 13, 2017) is 2327 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 112, but not defined == Missing Reference: 'RFC7399' is mentioned on line 119, but not defined == Missing Reference: 'RFC5521' is mentioned on line 313, but not defined == Missing Reference: 'RFC7025' is mentioned on line 404, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Xian Zhang 2 Internet-Draft Young Lee 3 Intended status: Standards Track Fatai Zhang 4 Huawei 5 Ramon Casellas 6 CTTC 7 Oscar Gonzalez de Dios 8 Telefonica I+D 9 Zafar Ali 10 Cisco Systems 12 Expires: May 13, 2018 November 13, 2017 14 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 15 Usage in GMPLS-controlled Networks 17 draft-ietf-pce-pcep-stateful-pce-gmpls-06.txt 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 May 13, 2018. 54 Copyright Notice 56 Copyright (c) 2017 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 Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC-2119 [RFC2119]. 75 Table of Contents 77 Table of Contents.................................................2 78 1. Introduction...................................................3 79 2. PCEP Extensions................................................3 80 2.1. Overview of Requirements..................................3 81 2.2. LSP Delegation in GMPLS-controlled Networks...............4 82 2.3. LSP Synchronization in GMPLS-controlled Networks..........5 83 2.4. Modification of Existing PCEP Messages and Procedures.....6 84 2.4.1. Modification for LSP Re-optimization.................6 85 2.4.2. Modification for Route Exclusion.....................7 86 2.5. Object Encoding...........................................8 87 3. IANA Considerations............................................8 88 3.1. New PCEP Error Codes......................................8 89 3.2. New Subobject for the Exclude Route Object................9 90 4. Manageability Considerations...................................9 91 4.1. Requirements on Other Protocols and Functional Components.9 92 5. Security Considerations........................................9 93 6. Acknowledgement...............................................10 94 7. References....................................................10 95 7.1. Normative References.....................................10 96 7.2. Informative References...................................10 97 8. Contributors' Address.........................................11 98 Authors' Addresses...............................................12 100 1. Introduction 102 [RFC4655] presents the architecture of a Path Computation Element 103 (PCE)-based model for computing Multiprotocol Label Switching (MPLS) 104 and Generalized MPLS (GMPLS) Traffic Engineering Label Switched 105 Paths (TE LSPs). To perform such a constrained computation, a PCE 106 stores the network topology (i.e., TE links and nodes) and resource 107 information (i.e., TE attributes) in its TE Database (TED). Such a 108 PCE is usually referred as a stateless PCE. To request path 109 computation services to a PCE, [RFC5440] defines the PCE 110 communication Protocol (PCEP) for interaction between a Path 111 Computation Client (PCC) and a PCE, or between two PCEs. PCEP as 112 specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP 113 extensions needed for GMPLS-controlled networks are provided in 114 [PCEP-GMPLS]. 116 Stateful PCEs are shown to be helpful in many application scenarios, 117 in both MPLS and GMPLS networks, as illustrated in [RFC8051]. 118 Further discussion of concept of a stateful PCE can be found in 119 [RFC7399]. In order for these applications to able to exploit the 120 capability of stateful PCEs, extensions to PCEP are required. 122 [Stateful-PCE] provides the fundamental extensions needed for 123 stateful PCE to support general functionality, but leaves out the 124 specification for technology-specific objects/TLVs. This document 125 focuses on the extensions that are necessary in order for the 126 deployment of stateful PCEs in GMPLS-controlled networks. 128 2. PCEP Extensions 130 2.1. Overview of Requirements 131 This section notes the main functional requirements for PCEP 132 extensions to support stateful PCE for use in GMPLS-controlled 133 networks, based on the description in [RFC8051]. Many 134 requirements are common across a variety of network types (e.g., 135 MPLS-TE networks and GMPLS networks) and the protocol extensions to 136 meet the requirements are already described in [Stateful-PCE]. This 137 document does not repeat the description of those protocol 138 extensions. This document presents protocol extensions for a set of 139 requirements which are specific to the use of a stateful PCE in a 140 GMPLS-controlled network. 142 The basic requirements are as follows: 144 o Advertisement of the stateful PCE capability. This generic 145 requirement is covered in Section 5.4. of [Stateful-PCE]. This 146 document does not provide any further extensions. 148 o LSP delegation is already covered in Section 5.5. of [Stateful- 149 PCE]. Section 2.3. of this document provides extension for its 150 application in GMPLS-controlled networks. Moreover, further 151 discussion of some generic details that need additional 152 consideration is provided. 154 o LSP state synchronization and LSP state report. This is a generic 155 requirement already covered in Section 5.6. of [Stateful-PCE]. 156 However, there are further extensions required specifically for 157 GMPLS-controlled networks and discussed in Section 2.4. Reference 158 to LSPs by identifiers is discussed in Section 5.6. of [Stateful- 159 PCE]. This feature can be applied to reduce the data carried in 160 PCEP messages. Use cases and additional Error Codes are necessary, 161 as described in Section 2.5. of this document. 163 2.2. LSP Delegation in GMPLS-controlled Networks 165 [Stateful-PCE] defines the Path Computation LSP Update Request 166 (PCUpd) message to enable to update the attributes of an LSP. 167 However, that document does not define technology-specific 168 parameters. 170 A key element of the PCUpd message is the attribute-list construct 171 defined in [RFC5440] and extended by many other PCEP specifications. 173 For GMPLS purposes we note that the BANDWIDTH object used in the 174 attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional 175 TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be 176 included to indicate technology-specific attributes. 178 LSP parameter update controlled by a stateful PCE in a multi-domain 179 network is complex and requires well-defined operational procedures 180 as well as protocol design and is out of scope of this document and 181 left for further study. 183 2.3. LSP Synchronization in GMPLS-controlled Networks 185 PCCs need to report the attributes of LSPs to the PCE to enable 186 stateful operation of a GMPLS network. This process is known as 187 LSP state synchronization. The LSP attributes include bandwidth, 188 associated route, and protection information etc., are stored by the 189 PCE in the LSP database (LSP-DB). Note that, as described in 190 [Stateful-PCE], the LSP state synchronization covers both the bulk 191 reporting of LSPs at initialization as well the reporting of new or 192 modified LSP during normal operation. Incremental LSP-DB 193 synchronization may be desired in a GMPLS-controlled network and it 194 is specified in [Sync-OPT]. 196 [Stateful-PCE] describes mechanisms for LSP synchronization using 197 the Path Computation State Report (PCRpt) message, but does not 198 cover reporting of technology-specific attributes. As stated in 199 [Stateful-PCE], the construct is further composed of a 200 compulsory ERO object and a compulsory attribute-list and an 201 optional RRO object. In order to report LSP states in GMPLS networks, 202 this specification allows the use within a PCRpt message both of 203 technology- and GMPLS-specific attribute objects and TLVs defined in 204 [PCEP-GMPLS] as follows: 206 o Extensions to the ERO, RRO, IRO, and XRO to carry label sub- 207 objects for SDH/SONET, OTN, and DWDM networks. 209 o Extended objects to support the inclusion of the label and 210 unnumbered links. 212 o END-POINTS (Generalized END-POINTS Object Type) 214 o BANDWIDTH (Generalized BANDWIDTH Object Type) 216 o PROTECTION ATTRIBUTE TLV 218 o IF_ID_ERROR_SPEC (extending [Stateful-PCE] section 7.3.4 that 219 only considers the use of RSVP ERROR_SPEC) 221 The END-POINTS object SHOULD be carried within the attribute-list to 222 specify the endpoints pertaining to the reported LSP. The XRO object 223 MAY be carried to specify the network resources that the reported 224 LSP avoids and a PCE SHOULD consider avoid these network resources 225 during the process of re-optimizing after this LSP is delegated to 226 the PCE. To be more specific, the is updated as 227 follows: 229 ::= [] 230 [] 231 [] 232 [] 233 [] 234 [] 236 ::= [] 238 If the LSP being reported protects another LSP, the PROTECTION- 239 ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to 240 describe its attributes and restrictions. Moreover, if the status 241 of the protecting LSP changes from non-operational to operational, 242 this SHOULD to be synchronized to the stateful PCE using a PCRpt 243 message. 245 2.4. Modification of Existing PCEP Messages and Procedures 247 One of the advantages mentioned in [RFC8051] is that the stateful 248 nature of a PCE simplifies the information conveyed in PCEP messages, 249 notably between PCC and PCE, since it is possible to refer to PCE 250 managed state for active LSPs. To be more specific, with a stateful 251 PCE, it is possible to refer to an LSP with a unique identifier in 252 the scope of the PCC-PCE session and thus use such identifier to 253 refer to that LSP. Note this MAY also be applicable to packet 254 networks. 256 2.4.1. Modification for LSP Re-optimization 258 The Request Parameters (RP) object on a Path Computation Request 259 (PCReq) message carries the R bit. When set, this indicates that 260 the PCC is requesting re-optimization of an existing LSP. Upon 261 receiving such a PCReq, a stateful PCE SHOULD perform the re- 262 optimization in the following cases: 264 - The existing bandwidth and route information of the LSP to be 265 re-optimized is provided in the PCReq message using the BANDWIDTH 266 object and the ERO. 268 - The existing bandwidth and route information is not supplied in 269 the PCReq message, but can be found in the PCE's LSP-DB. In this 270 case, the LSP MUST be identified using an LSP identifier carried in 271 the PCReq message, and that fact requires that the LSP identifier 272 was previously supplied either by the PCC in a PCRpt message or by 273 the PCE in a PCRep. [Stateful-PCE] defines how this is achieved 274 using a combination of the per-node LSP identifier (PLSP-ID) and the 275 PCC's address. 277 If no LSP state information is available to carry out re- 278 optimization, the stateful PCE should report the error "LSP state 279 information unavailable for the LSP re-optimization" (Error Type = 280 TBD1, Error value= TBD2). 282 2.4.2. Modification for Route Exclusion 284 [RFC5521] defines a mechanism for a PCC to request or demand that 285 specific nodes, links, or other network resources are excluded from 286 paths computed by a PCE. A PCC may wish to request the computation 287 of a path that avoids all link and nodes traversed by some other LSP. 289 To this end this document defines a new sub-object for use with 290 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 291 is as follows: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |X|Type (TBD3) | Length | Attributes | Flag | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | PLSP-ID | Reserved | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 X bit and Attribute fields are defined in [RFC5521]. 302 X bit: indicates whether the exclusion is mandatory (X=1) and 303 MUST be accommodated, or desired (X=0) and SHOULD be accommodated. 305 Type: Subobject Type for an LSP exclusion sub-object. Value of 306 TBD3. To be assigned by IANA. 308 Length: The Length contains the total length of the subobject in 309 bytes, including the Type and Length fields. 311 Attributes: indicates how the exclusion object is to be 312 interpreted. Currently, Interface (Attributes = 0), Node (Attributes 313 =1) and SRLG (Attributes =2) are defined in [RFC5521] and this 314 document does not define new values. 316 Flags: This field may be used to further specify the exclusion 317 constraint with regard to the LSP. Currently, no values are defined. 319 PLSP-ID: This is the identifier given to a LSP and is unique in 320 the context of the PCC address as defined in [Stateful-PCE]. 322 Reserved: MUST be transmitted as zero and SHOULD be ignored on 323 receipt. 325 This sub-object is OPTIONAL in the exclude route object (XRO) and 326 can be present multiple times. When a stateful PCE receives a PCReq 327 message carrying this sub-object, it SHOULD search for the 328 identified LSP in its LSP-DB and then exclude it from the new path 329 computation all resources used by the identified LSP. If the 330 stateful PCE cannot recognize one or more of the received LSP 331 identifiers, it should send an error message PCErr reporting "The 332 LSP state information for route exclusion purpose cannot be found" 333 (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide 334 with the unrecognized identifier information to the requesting PCC 335 using the error reporting techniques described in [RFC5440]. 337 2.5. Object Encoding 339 Note that, as is stated in Section 7 of [Stateful-PCE], the P flag 340 and the I flag of the PCEP objects used on PCUpd and PCRpt messages 341 SHOULD be set to 0 on transmission and SHOULD be ignored on receipt 342 since these flags are exclusively related to path computation 343 requests. 345 3. IANA Considerations 347 IANA is requested to allocate new Types for the TLV/Object defined 348 in this document. 350 3.1. New PCEP Error Codes 352 IANA is requested to make the following allocation in the "PCEP- 353 ERROR Object Error Types and Values" registry. 355 Error Type Meaning Reference 357 TBD1 LSP state information missing [This.I-D] 359 Error-value TBD2: LSP state information unavailable [This.I-D] 361 for the LSP re-optimization 363 Error-value TBD4: LSP state information for route 365 exclusion purpose cannot be found [This.I-D] 367 3.2. New Subobject for the Exclude Route Object 369 IANA maintains the "PCEP Parameters" registry containing a 370 subregistry called "PCEP Objects". This registry has a subregistry 371 for the XRO (Exclude Route Object) listing the sub-objects that can 372 be carried in the XRO. IANA is requested to assign a further sub- 373 object that can be carried in the XRO as follows: 375 Value Description Reference 377 ----------+------------------------------+------------- 379 TBD3 LSP identifier sub-object [This.I-D] 381 4. Manageability Considerations 383 The description and functionality specifications presented related 384 to stateful PCEs should also comply with the manageability 385 specifications covered in Section 8 of [RFC4655]. Furthermore, a 386 further list of manageability issues presented in [Stateful-PCE] 387 should also be considered. 389 Additional considerations are presented in the next sections. 391 4.1. Requirements on Other Protocols and Functional Components 393 When the detailed route information is included for LSP state 394 synchronization (either at the initial stage or during LSP state 395 report process), this requires the ingress node of an LSP carry the 396 RRO object in order to enable the collection of such information. 398 5. Security Considerations 400 This draft provides additional extensions to PCEP so as to 401 facilitate stateful PCE usage in GMPLS-controlled networks, on top 402 of [Stateful-PCE]. The PCEP extensions to support GMPLS-controlled 403 networks should be considered under the same security as for MPLS 404 networks, as noted in [RFC7025]. Therefore, the security 405 considerations elaborated in [RFC5440] still apply to this draft. 406 Furthermore, [Stateful-PCE] provides a detailed analysis of the 407 additional security issues incurred due to the new extensions and 408 possible solutions needed to support for the new stateful PCE 409 capabilities and they apply to this document as well. 411 6. Acknowledgement 413 We would like to thank Adrian Farrel and Cyril Margaria for the 414 useful comments and discussions. 416 7. References 418 7.1. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 421 requirements levels", RFC 2119, March 1997. 423 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 424 Computation Element (PCE)-Based Architecture", RFC 4655, 425 August 2006. 427 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 428 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 429 March 2009. 431 [Stateful-PCE] Crabbe, E., Medved, J., Varga, R., Minei, I., "PCEP 432 Extensions for Stateful PCE", draft-ietf-pce-stateful-pce, 433 work in progress. 435 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 436 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 437 extensions, work in progress. 439 7.2. Informative References 441 [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 442 Path Computation Element (PCE) ", RFC 8051, January 2017. 444 [Sync-OPT] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 445 and D. Dhody, "Optimizations of Label Switched Path State 446 Synchronization Procedures for a Stateful PCE", draft- 447 ietf-pce-stateful-sync-optimizations, work in progress. 449 8. Contributors' Address 451 Dhruv Dhody 452 Huawei Technology 453 Leela Palace 454 Bangalore, Karnataka 560008 455 INDIA 457 EMail: dhruvd@huawei.com 459 Yi Lin 460 Huawei Technologies 461 F3-5-B R&D Center, Huawei Base 462 Bantian, Longgang District 463 Shenzhen 518129 P.R.China 465 Phone: +86-755-28972914 466 Email: yi.lin@huawei.com 468 Authors' Addresses 470 Xian Zhang 471 Huawei Technologies 472 F3-5-B R&D Center, Huawei Base 473 Bantian, Longgang District 474 Shenzhen 518129 P.R.China 476 Phone: +86-755-28972645 477 Email: zhang.xian@huawei.com 479 Young Lee 480 Huawei 481 5340 Legacy Drive, Suite 170 482 Plano, TX 75023 483 US 485 Phone: +1 469 278 5838 486 EMail: ylee@huawei.com 488 Fatai Zhang 489 Huawei 490 F3-5-B R&D Center, Huawei Base 491 Bantian, Longgang District 492 P.R. China 494 Phone: +86-755-28972912 495 Email: zhangfatai@huawei.com 497 Ramon Casellas 498 CTTC 499 Av. Carl Friedrich Gauss n7 500 Castelldefels, Barcelona 08860 501 Spain 503 Phone: 504 Email: ramon.casellas@cttc.es 506 Oscar Gonzalez de Dios 507 Telefonica Investigacion y Desarrollo 508 Emilio Vargas 6 509 Madrid, 28045 510 Spain 512 Phone: +34 913374013 513 Email: ogondio@tid.es 515 Zafar Ali 516 Cisco Systems 517 Email: zali@cisco.com