idnits 2.17.1 draft-ietf-pce-pcep-stateful-pce-gmpls-03.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 1 character 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...' -- The document date (July 06, 2015) is 3210 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: 'Stateful-PCE' is mentioned on line 398, but not defined == Missing Reference: 'RFC5521' is mentioned on line 311, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 2 errors (**), 0 flaws (~~), 8 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: January 05, 2016 July 06, 2015 14 Path Computation Element (PCE) Protocol Extensions for Stateful PCE 15 Usage in GMPLS-controlled Networks 17 draft-ietf-pce-pcep-stateful-pce-gmpls-03.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 January 5, 2016. 54 Copyright Notice 56 Copyright (c) 2015 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 ............................................. 9 94 7. References ................................................. 10 95 7.1. Normative References................................... 10 96 7.2. Informative References................................. 10 97 8. Contributors' Address....................................... 10 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 [Stateful-APP]. 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 [Stateful-APP]. 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 7.1.1. 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.4. 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 7.3. 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 a optional 201 RRO object. In order to report LSP states in GMPLS networks, this 202 specification allows the use within a PCRpt message of technology- 203 and GMPLS-specific attribute objects and TLVs defined in [PCEP-GMPLS] 204 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: 228 ::= [] 229 [] 230 [] 231 [] 232 [] 233 [] 235 ::= [] 237 If the LSP being reported protects another LSP, the PROTECTION- 238 ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to 239 describe its attributes and restrictions. Moreover, if the status 240 of the protecting LSP changes from non-operational to operational, 241 this SHOULD to be synchronized to the stateful PCE using a PCRpt 242 message. 244 2.4. Modification of Existing PCEP Messages and Procedures 246 One of the advantages mentioned in [Stateful-APP] is that the 247 stateful nature of a PCE simplifies the information conveyed in PCEP 248 messages, notably between PCC and PCE, since it is possible to refer 249 to PCE managed state for active LSPs. To be more specific, with a 250 stateful PCE, it is possible to refer to a LSP with a unique 251 identifier in the scope of the PCC-PCEP session and thus use such 252 identifier to refer to that LSP. 254 2.4.1. Modification for LSP Re-optimization 256 The Request Parameters (RP) object on a Path Computation Request 257 (PCReq) message carries the R bit. When set, this indicates that 258 the PCC is requesting reoptimization of an existing LSP. Upon 259 receiving such a PCReq, a stateful PCE SHOULD perform the 260 reoptimization in the following cases: 262 - The existing bandwidth and route information of the LSP to be 263 reoptimized is provided in the PCReq message using the BANDWIDTH 264 object and the ERO. 266 - The existing bandwidth and route information is not supplied in 267 the PCReq message, but can be found in the PCE's LSP-DB. In this 268 case, the LSP MUST be identified using an LSP identifier carried in 269 the PCReq message, and that fact requires that the LSP identifier 270 was previously supplied either by the PCC in a PCRpt message or by 271 the PCE in a PCRep. [Stateful-PCE] defines how this is achieved 272 using a combination of the per-node LSP identifier (PLSP-ID) and the 273 PCC's address. 275 If no LSP state information is available to carry out 276 reoptimization, the stateful PCE should report the error "LSP state 277 information unavailable for the LSP reoptimization" (Error Type = 278 TBD1, Error value= TBD2). 280 2.4.2. Modification for Route Exclusion 282 [RFC5521] defines a mechanism for a PCC to request or demand that 283 specific nodes, links, or other network resources are excluded from 284 paths computed by a PCE. A PCC may wish to request the computation 285 of a path that avoids all link and nodes traversed by some other LSP. 287 To this end this document defines a new sub-object for use with 288 route exclusion defined in [RFC5521]. The LSP exclusion sub-object 289 is as follows: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |X|Type (TBD3) | Length | Attributes | Flag | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | PLSP-ID | Reserved | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 X bit and Attribute fields are defined in [RFC5521]. 300 X bit: indicates whether the exclusion is mandatory (X=1) and 301 MUST be accommodated, or desired (X=0) and SHOULD be accommodated. 303 Type: Subobject Type for an LSP exclusion sub-object. Value of 304 TBD3. To be assigned by IANA. 306 Length: The Length contains the total length of the subobject in 307 bytes, including the Type and Length fields. 309 Attributes: indicates how the exclusion object is to be 310 interpreted. Currently, Interface (Attributes = 0), Node (Attributes 311 =1) and SRLG (Attributes =2) are defined in [RFC5521] and this 312 document does not define new values. 314 Flags: This field may be used to further specify the exclusion 315 constraint with regard to the LSP. Currently, no values are defined. 317 PLSP-ID: This is the identifier given to a LSP and is unique in 318 the context of the PCC address as defined in [Stateful-PCE]. 320 Reserved: MUST be transmitted as zero and SHOULD be ignored on 321 receipt. 323 This sub-object is OPTIONAL in the exclude route object (XRO) and 324 can be present multiple times. When a stateful PCE receives a PCReq 325 message carrying this sub-object, it SHOULD search for the 326 identified LSP in its LSP-DB and then exclude it from the new path 327 computation all resources used by the identified LSP. If the 328 stateful PCE cannot recognize one or more of the received LSP 329 identifiers, it should send an error message PCErr reporting "The 330 LSP state information for route exclusion purpose cannot be found" 331 (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide 332 with the unrecognized identifier information to the requesting PCC 333 using the error reporting techniques described in [RFC5440]. 335 2.5. Object Encoding 337 Note that, as is stated in Section 7 of [Stateful-PCE], the P flag 338 and the I flag of the PCEP objects used on PCUpd and PCRpt messages 339 SHOULD be set to 0 on transmission and SHOULD be ignored on receipt 340 since these flags are exclusively related to path computation 341 requests. 343 3. IANA Considerations 345 IANA is requested to allocate new Types for the TLV/Object defined 346 in this document. 348 3.1. New PCEP Error Codes 350 IANA is requested to make the following allocation in the "PCEP- 351 ERROR Object Error Types and Values" registry. 353 Error Type Meaning Reference 355 TBD1 LSP state information missing [This.I-D] 357 Error-value TBD2: LSP state information unavailable [This.I-D] 359 for the LSP re-optimization 361 Error-value TBD4: LSP state information for route 363 exclusion purpose cannot be found [This.I-D] 365 3.2. New Subobject for the Exclude Route Object 367 IANA maintains the "PCEP Parameters" registry containing a 368 subregistry called "PCEP Objects". This registry has a subregistry 369 for the XRO (Exclude Route Object) listing the sub-objects that can 370 be carried in the XRO. IANA is requested to assign a further sub- 371 object that can be carried in the XRO as follows: 373 Value Description Reference 375 ----------+------------------------------+------------- 377 TBD3 LSP identifier sub-object [This.I-D] 379 4. Manageability Considerations 381 The description and functionality specifications presented related 382 to stateful PCEs should also comply with the manageability 383 specifications covered in Section 8 of [RFC4655]. Furthermore, a 384 further list of manageability issues presented in [Stateful-PCE] 385 should also be considered. 387 Additional considerations are presented in the next sections. 389 4.1. Requirements on Other Protocols and Functional Components 391 When the detailed route information is included for LSP state 392 synchronization (either at the initial stage or during LSP state 393 report process), this require the ingress node of an LSP carry the 394 RRO object in order to enable the collection of such information. 396 5. Security Considerations 398 The security issues presented in [RFC5440] and [Stateful-PCE] apply 399 to this document. 401 6. Acknowledgement 403 We would like to thank Adrian Farrel and Cyril Margaria for the 404 useful comments and discussions. 406 7. References 408 7.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 411 requirements levels", RFC 2119, March 1997. 413 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 414 Computation Element (PCE)-Based Architecture", RFC 4655, 415 August 2006. 417 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 418 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 419 March 2009. 421 [Stateful-PCE]Crabbe, E., Medved, J., Varga, R., Minei, I., "PCEP 422 Extensions for Stateful PCE", draft-ietf-pce-stateful-pce, 423 work in progress. 425 [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., "PCEP 426 extensions for GMPLS", draft-ietf-pce-gmpls-pcep- 427 extensions, work in progress. 429 7.2. Informative References 431 [Stateful-APP] Zhang, X., Minei, I., et al, "Applicability of 432 Stateful Path Computation Element (PCE) ", draft-ietf-pce- 433 stateful-pce-app, work in progress. 435 [Sync-OPT] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 436 and D. Dhody, "Optimizations of Label Switched Path State 437 Synchronization Procedures for a Stateful PCE", draft- 438 ietf-pce-stateful-sync-optimizations, work in progress. 440 8. Contributors' Address 442 Dhruv Dhody 443 Huawei Technology 444 Leela Palace 445 Bangalore, Karnataka 560008 446 INDIA 448 EMail: dhruvd@huawei.com 450 Yi Lin 451 Huawei Technologies 452 F3-5-B R&D Center, Huawei Base 453 Bantian, Longgang District 454 Shenzhen 518129 P.R.China 456 Phone: +86-755-28972914 457 Email: yi.lin@huawei.com 459 Authors' Addresses 461 Xian Zhang 462 Huawei Technologies 463 F3-5-B R&D Center, Huawei Base 464 Bantian, Longgang District 465 Shenzhen 518129 P.R.China 467 Phone: +86-755-28972645 468 Email: zhang.xian@huawei.com 470 Young Lee 471 Huawei 472 1700 Alma Drive, Suite 100 473 Plano, TX 75075 474 US 476 Phone: +1 972 509 5599 x2240 477 Fax: +1 469 229 5397 478 EMail: ylee@huawei.com 480 Fatai Zhang 481 Huawei 482 F3-5-B R&D Center, Huawei Base 483 Bantian, Longgang District 484 P.R. China 486 Phone: +86-755-28972912 487 Email: zhangfatai@huawei.com 489 Ramon Casellas 490 CTTC 491 Av. Carl Friedrich Gauss n7 492 Castelldefels, Barcelona 08860 493 Spain 495 Phone: 496 Email: ramon.casellas@cttc.es 498 Oscar Gonzalez de Dios 499 Telefonica Investigacion y Desarrollo 500 Emilio Vargas 6 501 Madrid, 28045 502 Spain 503 Phone: +34 913374013 504 Email: ogondio@tid.es 506 Zafar Ali 507 Cisco Systems 508 Email: zali@cisco.com