idnits 2.17.1 draft-ietf-pce-pce-initiated-lsp-01.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 are 3 instances of too long lines in the document, the longest one being 27 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-pce-stateful-pce]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 6, 2014) is 3605 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: 'TBD' is mentioned on line 277, but not defined == Unused Reference: 'RFC2205' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC5089' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC3346' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'RFC5557' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC6982' is defined on line 707, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-08 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 3 errors (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group E. Crabbe 3 Internet-Draft I. Minei 4 Intended status: Standards Track Google, Inc. 5 Expires: December 8, 2014 S. Sivabalan 6 Cisco Systems, Inc. 7 R. Varga 8 Pantheon Technologies SRO 9 June 6, 2014 11 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 12 draft-ietf-pce-pce-initiated-lsp-01 14 Abstract 16 The Path Computation Element Communication Protocol (PCEP) provides 17 mechanisms for Path Computation Elements (PCEs) to perform path 18 computations in response to Path Computation Clients (PCCs) requests. 20 The extensions described in [I-D.ietf-pce-stateful-pce] provide 21 stateful control of Multiprotocol Label Switching (MPLS) Traffic 22 Engineering Label Switched Paths (TE LSP) via PCEP, for a model where 23 the PCC delegates control over one or more locally configured LSPs to 24 the PCE. This document describes the creation and deletion of PCE- 25 initiated LSPs under the stateful PCE model. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 8, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 70 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 71 3.2. Operation overview . . . . . . . . . . . . . . . . . . . 4 72 4. Support of PCE-initiated LSPs . . . . . . . . . . . . . . . . 5 73 4.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 6 74 5. PCE-initiated LSP instantiation and deletion . . . . . . . . 6 75 5.1. The LSP Initiate Message . . . . . . . . . . . . . . . . 6 76 5.2. The R flag in the SRP Object . . . . . . . . . . . . . . 7 77 5.3. LSP instantiation . . . . . . . . . . . . . . . . . . . . 8 78 5.3.1. The Create flag . . . . . . . . . . . . . . . . . . . 10 79 5.4. LSP deletion . . . . . . . . . . . . . . . . . . . . . . 10 80 6. LSP delegation and cleanup . . . . . . . . . . . . . . . . . 11 81 7. Implementation status . . . . . . . . . . . . . . . . . . . . 12 82 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 83 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 12 84 8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 12 85 8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 13 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 13 88 9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 14 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 11.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 [RFC5440] describes the Path Computation Element Protocol PCEP. PCEP 98 defines the communication between a Path Computation Client (PCC) and 99 a Path Control Element (PCE), or between PCE and PCE, enabling 100 computation of Multiprotocol Label Switching (MPLS) for Traffic 101 Engineering Label Switched Path (TE LSP) characteristics. 103 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 104 extensions to PCEP to enable stateful control of TE LSPs between and 105 across PCEP sessions in compliance with [RFC4657]. It includes 106 mechanisms to effect LSP state synchronization between PCCs and PCEs, 107 delegation of control of LSPs to PCEs, and PCE control of timing and 108 sequence of path computations within and across PCEP sessions and 109 focuses on a model where LSPs are configured on the PCC and control 110 over them is delegated to the PCE. 112 This document describes the setup, maintenance and teardown of PCE- 113 initiated LSPs under the stateful PCE model, without the need for 114 local configuration on the PCC, thus allowing for a dynamic network 115 that is centrally controlled and deployed. 117 2. Terminology 119 This document uses the following terms defined in [RFC5440]: PCC, 120 PCE, PCEP Peer. 122 This document uses the following terms defined in 123 [I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Redelegation 124 Timeout, State Timeout Interval LSP State Report, LSP Update Request. 126 The following terms are defined in this document: 128 PCE-initiated LSP: LSP that is instantiated as a result of a request 129 from the PCE. 131 The message formats in this document are specified using Routing 132 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 134 3. Architectural Overview 136 3.1. Motivation 138 [I-D.ietf-pce-stateful-pce] provides stateful control over LSPs that 139 are locally configured on the PCC. This model relies on the LER 140 taking an active role in delegating locally configured LSPs to the 141 PCE, and is well suited in environments where the LSP placement is 142 fairly static. However, in environments where the LSP placement 143 needs to change in response to application demands, it is useful to 144 support dynamic creation and tear down of LSPs. The ability for a 145 PCE to trigger the creation of LSPs on demand can make possible agile 146 software-driven network operation, and can be seamlessly integrated 147 into a controller-based network architecture, where intelligence in 148 the controller can determine when and where to set up paths. 150 A possible use case is one of a software-driven network, where 151 applications request network resources and paths from the network 152 infrastructure. For example, an application can request a path with 153 certain constraints between two LSRs by contacting the PCE. The PCE 154 can compute a path satisfying the constraints, and instruct the head 155 end LSR to instantiate and signal it. When the path is no longer 156 required by the application, the PCE can request its teardown. 158 Another use case is one of dynamically adjusting aggregate bandwidth 159 between two points in the network using multiple LSPs. This 160 functionality is very similar to auto-bandwidth, but allows for 161 providing the desired capacity through multiple LSPs. This approach 162 overcomes two of the limitations auto-bandwidth can experience: 1) 163 growing the capacity between the endpoints beyond the capacity of 164 individual links in the path and 2) achieving good bin-packing 165 through use of several small LSPs instead of a single large one. The 166 number of LSPs varies based on the demand, and LSPs are created and 167 deleted dynamically to satisfy the bandwidth requirements. 169 Another use case is that of demand engineering, where a PCE with 170 visibility into both the network state and the demand matrix can 171 anticipate and optimize how traffic is distributed across the 172 infrastructure. Such optimizations may require creating new paths 173 across the infrastructure. 175 3.2. Operation overview 177 A PCC or PCE indicates its ability to support PCE provisioned dynamic 178 LSPs during the PCEP Initialization Phase via a new flag in the 179 STATEFUL-PCE-CAPABILITY TLV (see details in Section 4.1). 181 The decision when to instantiate or delete a PCE-initiated LSP is out 182 of the scope of this document. To instantiate or delete an LSP, the 183 PCE sends a new message, the Path Computation LSP Initiate Request 184 (PCInitiate) message to the PCC. The LSP Initiate Request MUST 185 include the SRP and LSP objects, and the LSP object MUST include the 186 Symbolic Path Name TLV and MUST have a PLSP-ID of 0. 188 For an instantiation operation, the PCE MUST include the ERO and END- 189 POINTS object and may include various attributes as per [RFC5440]. 190 The PCC creates the LSP using the attributes communicated by the PCE, 191 and local values for the unspecified parameters. It assigns a unique 192 PLSP-ID for the LSP and automatically delegates the LSP to the PCE. 193 It also generates an LSP State Report (PCRpt) for the LSP, carrying 194 the newly assigned PLSP-ID and indicating the delegation via the 195 Delegate flag in the LSP object. In addition to the Delegate flag, 196 the PCC also sets the Create flag in the LSP object (see 197 Section 5.3.1), to indicate that the LSP was created as a result of a 198 PCinitiate message. This PCRpt message MUST include the SRP object, 199 with the SRP-id-number used in the SRP object of the PCInitate 200 message. The PCE may update the attributes of the LSP via subsequent 201 PCUpd messages. Subsequent LSP State Report and LSP Update Request 202 for the LSP will carry the PCC-assigned PLSP-ID, which uniquely 203 identifies the LSP. See details in Section 5.3. 205 Once instantiated, the delegation procedures for PCE-initiated LSPs 206 are the same as for PCC initiated LSPs as described in 207 [I-D.ietf-pce-stateful-pce]. This applies to the case of a PCE 208 failure as well. In order to allow for network cleanup without 209 manual intervention, the PCC SHOULD support removal of PCE-initiated 210 LSPs as one of the behaviors applied on expiration of the State 211 Timeout Interval [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be 212 picked based on local policy, and can result either in LSP removal, 213 or into reverting to operator-defined default parameters. See 214 details in Section 6. A PCE may return a delegation to the PCC in 215 order to facilitate re-delegation of its LSPs to an alternate PCE. 217 To indicate a delete operation, the PCE MUST use the R flag in the 218 SRP object in a PCUpd message. As a result of the deletion request, 219 the PCC MUST remove all state related to the LSP, and send a PCRpt 220 with the R flag set in the LSP object for the removed state. See 221 details in Section 5.4. 223 4. Support of PCE-initiated LSPs 225 A PCC indicates its ability to support PCE provisioned dynamic LSPs 226 during the PCEP Initialization phase. The Open Object in the Open 227 message contains the "Stateful PCE Capability" TLV, defined in 228 [I-D.ietf-pce-stateful-pce]. A new flag, the I (LSP-INSTANTIATION- 229 CAPABILITY) flag is introduced to indicate support for instantiation 230 of PCE-initiated LSPs. A PCE can initiate LSPs only for PCCs that 231 advertised this capability and a PCC will follow the procedures 232 described in this document only on sessions where the PCE advertised 233 the I flag. 235 4.1. Stateful PCE Capability TLV 237 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 238 following figure: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type=16 | Length=4 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Flags |I|S|U| 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 248 Figure 1: STATEFUL-PCE-CAPABILITY TLV format 250 The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it 251 has a fixed length of 4 octets. 253 The value comprises a single field - Flags (32 bits). The U and S 254 bits are defined in [I-D.ietf-pce-stateful-pce]. 256 I (LSP-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, the 257 I Flag indicates that the PCC allows instantiation of an LSP by a 258 PCE. If set to 1 by a PCE, the I flag indicates that the PCE will 259 attempt to instantiate LSPs. The LSP-INSTANTIATION-CAPABILITY 260 flag must be set by both PCC and PCE in order to support PCE- 261 initiated LSP instantiation. 263 Unassigned bits are considered reserved. They MUST be set to 0 on 264 transmission and MUST be ignored on receipt. 266 5. PCE-initiated LSP instantiation and deletion 268 To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The 269 message format, objects and TLVs are discussed separately below for 270 the creation and the deletion cases. 272 5.1. The LSP Initiate Message 274 A Path Computation LSP Initiate Message (also referred to as 275 PCInitiate message) is a PCEP message sent by a PCE to a PCC to 276 trigger LSP instantiation or deletion. The Message-Type field of the 277 PCEP common header for the PCInitiate message is set to [TBD]. The 278 PCInitiate message MUST include the SRP and the LSP objects, and may 279 contain other objects, as discussed later in this section. If either 280 the SRP or the LSP object is missing, the PCC MUST send a PCErr as 281 described in [I-D.ietf-pce-stateful-pce]. LSP instantiation is done 282 by sending an LSP Initiate Message with an LSP object with the 283 reserved PLSP-ID 0. LSP deletion is done by sending an LSP Initiate 284 Message with an LSP object carrying the PLSP-ID of the LSP to be 285 removed and an SRP object with the R flag set (see Section 5.2). 287 The format of a PCInitiate message for LSP instantiation is as 288 follows: 290 ::= 291 292 Where: 294 ::= [] 296 ::= (|) 298 ::= 299 300 301 302 [] 304 ::= 305 307 Where: 308 is defined in [RFC5440] and extended by PCEP extensions. 310 The SRP object is used to correlate between initiation requests sent 311 by the PCE and the error reports and state reports sent by the PCC. 312 Every request from the PCE receives a new SRP-ID-number. This number 313 is unique per PCEP session and is incremented each time an operation 314 (initiation, update, etc) is requested from the PCE. The value of 315 the SRP-ID-number MUST be echoed back by the PCC in PCErr and PCRpt 316 messages to allow for correlation between requests made by the PCE 317 and errors or state reports generated by the PCC. Details of the SRP 318 object and its use can be found in [I-D.ietf-pce-stateful-pce]. 320 5.2. The R flag in the SRP Object 322 The format of the SRP object is shown Figure 2: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Flags |R| 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | SRP-ID-number | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 // Optional TLVs // 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 2: The SRP Object format 338 The type object is defined in [I-D.ietf-pce-stateful-pce]. 340 A new flag is defined to indicate a delete operation initiated by the 341 PCE: 343 R (LSP-REMOVE - 1 bit): If set to 1, it indicates a removal request 344 initiated by the PCE. 346 5.3. LSP instantiation 348 LSP instantiation is done by sending an LSP Initiate Message with an 349 LSP object with the reserved PLSP-ID 0. The LSP is set up using 350 RSVP-TE, extensions for other setup methods are outside the scope of 351 this draft. 353 Receipt of a PCInitiate Message with a non-zero PLSP-ID and the R 354 flag in the SRP object set to zero results in a PCErr message of type 355 19 (Invalid Operation) and value 8 (non-zero PLSP-ID in LSP 356 initiation request). 358 The END-POINTS Object is mandatory for an instantiation request of an 359 RSVP-signaled LSP. It contains the source and destination addresses 360 for provisioning the LSP. If the END-POINTS Object is missing, the 361 PCC MUST send a PCErr message with Error-type=6 (Mandatory Object 362 missing) and Error-value=3 (END-POINTS Object missing). 364 The ERO Object is mandatory for an instantiation request. It 365 contains the ERO for the LSP. If the ERO Object is missing, the PCC 366 MUST send a PCErr message with Error-type=6 (Mandatory Object 367 missing) and Error-value=9 (ERO Object missing). 369 The LSP Object MUST include the SYMBOLIC-PATH-NAME TLV, which will be 370 used to correlate between the PCC-assigned PLSP-ID and the LSP. If 371 the TLV is missing, the PCC MUST send a PCErr message with Error- 372 type=6(Mandatory object missing) and Error-value=14 (SYMBOLIC-PATH- 373 NAME TLV missing). The symbolic name used for provisioning PCE- 374 initiated LSPs must not have conflict with the LSP name of any 375 existing LSP in the PCC. (Existing LSPs may be either statically 376 configured, or initiated by another PCE). If there is conflict with 377 the LSP name, the PCC MUST send a PCErr message with Error-type=23 378 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). 379 The only exception to this rule is for LSPs for which the State 380 timeout timer is running (see Section 6). 382 The PCE MAY include various attributes as per [RFC5440]. The PCC 383 MUST use these values in the LSP instantiation, and local values for 384 unspecified parameters. After the LSP setup, the PCC MUST send a 385 PCRpt to the PCE, reflecting these values. The SRP object in the 386 PCRpt message MUST echo the value of the PCInitiate message that 387 triggered the setup. LSPs that were instantiated as a result of a 388 PCInitiate message MUST have the C flag set in the LSP object. 390 If the PCC determines that the LSP parameters proposed in the 391 PCInitiate message are unacceptable, it MUST trigger a PCErr with 392 error-type=TBD (PCE instantiation error) and error-value=1 393 (Unacceptable instantiation parameters). If the PCC encounters an 394 internal error during the processing of the PCInitiate message, it 395 MUST trigger a PCErr with error-type=TBD (PCE instantiation error) 396 and error-value=2 (Internal error). 398 A PCC MUST relay to the PCE errors it encounters in the setup of PCE- 399 initiated LSP by sending a PCErr with error-type=TBD (PCE 400 instantiation error) and error-value=3 (RSVP signaling error). The 401 PCErr MUST echo the SRP-id-number of the PCInitiate message. The 402 PCEP-ERROR object SHOULD include the RSVP Error Spec TLV (if an ERROR 403 SPEC was returned to the PCC by a downstream node). After the LSP is 404 set up, errors in RSVP signaling are reported in PCRpt messages, as 405 described in [I-D.ietf-pce-stateful-pce]. 407 A PCC SHOULD be able to place a limit on either the number of LSPs or 408 the percentage of resources that are allocated to honor PCE-initiated 409 LSP requests. As soon as that limit is reached, the PCC MUST send a 410 PCErr message of type 19 (Invalid Operation) and value TBD "PCE- 411 initiated limit reached" and is free to drop any incoming PCInitiate 412 messages without additional processing. 414 Similarly, the PCE SHOULD be able to place a limit on either the 415 number of LSP initiation requests pending for a particular PCC, or on 416 the time it waits for a response (positive or negative) to a 417 PCInitiate request from a PCC and MAY take further action (such as 418 closing the session or removing all its LSPs) if this limit is 419 reached. 421 On succesful completion of the LSP instantiation, the PCC assigns a 422 PLSP-ID, and immediately delegates the LSP to the PCE by sending a 423 PCRpt with the Delegate flag set. The PCRpt MUST include the SRP-ID- 424 number of the PCInitiate request that triggered its creation. PCE- 425 initiated LSPs are identified with the Create flag in the LSP Object. 427 5.3.1. The Create flag 429 The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included 430 here for easy reference. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | PLSP-ID | Flags |C| O|A|R|S|D| 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 // TLVs // 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Figure 3: The LSP Object format 443 A new flag, the Create (C) flag is introduced. On a PCRpt message, 444 the C Flag set to 1 indicates that this LSP was created via a 445 PCInitiate message. The C Flag MUST be set to 1 on each PCRpt 446 message for the duration of existence of the LSP. The Create flag 447 allows PCEs to be aware of which LSPs were PCE-initiated (a state 448 that would otherwise only be known by the PCC and the PCE that 449 initiated them). 451 5.4. LSP deletion 453 PCE-initiated removal of a PCE-initiated LSP is done by setting the R 454 (remove) flag in the SRP Object in the PCInitiate message from the 455 PCE. The LSP is identified by the PLSP-ID in the LSP object. If the 456 PLSP-ID is unknown, the PCC MUST generate a PCErr with error type 19, 457 error value 3, "Unknown PLSP-ID". A PLSP-ID of zero removes all LSPs 458 that were initiated by the PCE. If the PLSP-ID specified in the 459 PCInitiate message is not delegated to the PCE, the PCC MUST send a 460 PCErr message indicating "LSP is not delegated" (Error code 19, error 461 value 1 ([I-D.ietf-pce-stateful-pce]). If the PLSP-ID specified in 462 the PCInitiate message was not created by the PCE, the PCC MUST send 463 a PCErr message indicating "LSP is not PCE initiated" (Error code 19, 464 error value TBD). Following the removal of the LSP, the PCC MUST 465 send a PCRpt as described in [I-D.ietf-pce-stateful-pce]. The SRP 466 object in the PCRpt MUST include the SRP-ID-number from the 467 PCInitiate message that triggered the removal. The R flag in the SRP 468 object SHOULD be set. 470 6. LSP delegation and cleanup 472 PCE-initiated LSPs are automatically delegated by the PCC to the PCE 473 upon instantiation. The PCC MUST delegate the LSP to the PCE by 474 setting the delegation bit to 1 in the PCRpt that includes the 475 assigned PLSP-ID. All subsequent messages from the PCC must have the 476 delegation bit set to 1. The PCC cannot revoke the delegation for 477 PCE-initiated LSPs for an active PCEP session. Sending a PCRpt 478 message with the delegation bit set to 0 results in a PCErr message 479 of type 19 (Invalid Operation) and value TBD "Delegation for PCE- 480 initiated LSP cannot be revoked". The PCE MAY further react by 481 closing the session. 483 A PCE MAY return a delegation to the PCC, to allow for LSP transfer 484 between PCEs. Doing so MUST trigger the State Timeout Interval timer 485 ([I-D.ietf-pce-stateful-pce]). 487 In case of PCEP session failure, control over PCE-initiated LSPs 488 reverts to the PCC at the expiration of the redelegation timeout. To 489 obtain control of a PCE-initiated LSP, a PCE (either the original or 490 one of its backups) sends a PCInitiate message, including just the 491 SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to 492 take control of. Receipt of a PCInitiate message with a non-zero 493 PLSP-ID normally results in the generation of a PCErr. If the State 494 Timeout timer is running, the PCC MUST NOT generate an error and 495 redelegate the LSP to the PCE. The State Timeout timer is stopped 496 upon the redelegation. After obtaining control of the LSP, the PCE 497 may remove it using the procedures described in this document. 499 The State Timeout timer ensures that a PCE crash does not result in 500 automatic and immediate disruption for the services using PCE- 501 initiated LSPs. PCE-initiated LSPs are not be removed immediately 502 upon PCE failure. Instead, they are cleaned up on the expiration of 503 this timer. This allows for network cleanup without manual 504 intervention. The PCC SHOULD support removal of PCE-initiated LSPs 505 as one of the behaviors applied on expiration of the State Timeout 506 Interval [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be picked 507 based on local policy, and can result either in LSP removal, or into 508 reverting to operator-defined default parameters. 510 7. Implementation status 512 This section to be removed by the RFC editor. 514 This section records the status of known implementations of the 515 protocol defined by this specification at the time of posting of this 516 Internet-Draft, and is based on a proposal described in RFC 6982. 517 The description of implementations in this section is intended to 518 assist the IETF in its decision processes in progressing drafts to 519 RFCs. Please note that the listing of any individual implementation 520 here does not imply endorsement by the IETF. Furthermore, no effort 521 has been spent to verify the information presented here that was 522 supplied by IETF contributors. This is not intended as, and must not 523 be construed to be, a catalog of available implementations or their 524 features. Readers are advised to note that other implementations may 525 exist. 527 According to RFC 6982, "this will allow reviewers and working groups 528 to assign due consideration to documents that have the benefit of 529 running code, which may serve as evidence of valuable experimentation 530 and feedback that have made the implemented protocols more mature. 531 It is up to the individual working groups to use this information as 532 they see fit". 534 Two vendors are implementing the extensions described in this draft 535 and have included the functionality in releases that will be shipping 536 in the near future. An additional entity is working on implementing 537 these extensions in the scope of research projects. 539 8. IANA considerations 541 8.1. PCEP Messages 543 This document defines the following new PCEP messages: 545 Value Meaning Reference 546 12 Initiate This document 548 8.2. LSP Object 550 The following values are defined in this document for the Flags field 551 in the LSP Object. 553 Bit Description Reference 555 24 Create This document 557 8.3. PCEP-Error Object 559 This document defines new Error-Type and Error-Value for the 560 following new error conditions: 562 Error-Type Meaning 563 6 Mandatory Object missing 565 Error-value=13: LSP cleanup TLV missing 566 Error-value=14: SYMBOLIC-PATH-NAME TLV missing 567 19 Invalid operation 569 Error-value=6: PCE-initiated LSP limit reached 570 Error-value=7: Delegation for PCE-initiated LSP cannot 571 be revoked 572 Error-value=8: Non-zero PLSP-ID in LSP initiation 573 request 574 23 Bad parameter value 576 Error-value=1: SYMBOLIC-PATH-NAME in use 577 24 LSP instantiation error 579 Error-value=1: Unacceptable instantiation parameters 580 Error-value=2: Internal error 581 Error-value=3: RSVP signaling error 583 9. Security Considerations 585 The security considerations described in [I-D.ietf-pce-stateful-pce] 586 apply to the extensions described in this document. Additional 587 considerations related to a malicious PCE are introduced. 589 9.1. Malicious PCE 591 The LSP instantiation mechanism described in this document allows a 592 PCE to generate state on the PCC and throughout the network. As a 593 result, it introduces a new attack vector: an attacker may flood the 594 PCC with LSP instantiation requests and consume network and LSR 595 resources, either by spoofing messages or by compromising the PCE 596 itself. 598 A PCC can protect itself from such an attack by imposing a limit on 599 either the number of LSPs or the percentage of resources that are 600 allocated to honor PCE-initiated LSP requests. As soon as that limit 601 is reached, the PCC MUST send a PCErr message of type 19 (Invalid 602 Operation) and value 3 "PCE-initiated LSP limit reached" and is free 603 to drop any incoming PCInitiate messages for LSP instantiation 604 without additional processing. 606 Rapid flaps triggered by the PCE can also be an attack vector. This 607 will be discussed in a future version of this document. 609 9.2. Malicious PCC 611 The LSP instantiation mechanism described in this document requires 612 the PCE to keep state for LSPs that it instantiates and relies on the 613 PCC responding (with either a state report or an error message) to 614 requests for LSP instantiation. A malicious PCC or one that reached 615 the limit of the number of PCE-initiated LSPs, can ignore PCE 616 requests and consume PCE resources. A PCE can protect itself by 617 imposing a limit on the number of requests pending, or by setting a 618 timeout and it MAY take further action such as closing the session or 619 removing all the LSPs it initiated. 621 10. Acknowledgements 623 We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas, 624 Dhruv Dhody, and Raveendra Trovi for their contributions to this 625 document. 627 11. References 629 11.1. Normative References 631 [I-D.ietf-pce-stateful-pce] 632 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 633 Extensions for Stateful PCE", draft-ietf-pce-stateful- 634 pce-08 (work in progress), February 2014. 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 640 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 641 Functional Specification", RFC 2205, September 1997. 643 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 644 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 645 Tunnels", RFC 3209, December 2001. 647 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 648 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 649 2005. 651 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 652 "OSPF Protocol Extensions for Path Computation Element 653 (PCE) Discovery", RFC 5088, January 2008. 655 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 656 "IS-IS Protocol Extensions for Path Computation Element 657 (PCE) Discovery", RFC 5089, January 2008. 659 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 660 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 661 May 2008. 663 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 664 (PCE) Communication Protocol (PCEP)", RFC 5440, March 665 2009. 667 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 668 Used to Form Encoding Rules in Various Routing Protocol 669 Specifications", RFC 5511, April 2009. 671 11.2. Informative References 673 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 674 McManus, "Requirements for Traffic Engineering Over MPLS", 675 RFC 2702, September 1999. 677 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 678 Label Switching Architecture", RFC 3031, January 2001. 680 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 681 Christian, B., and W. Lai, "Applicability Statement for 682 Traffic Engineering with MPLS", RFC 3346, August 2002. 684 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 685 (TE) Extensions to OSPF Version 2", RFC 3630, September 686 2003. 688 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 689 Element (PCE)-Based Architecture", RFC 4655, August 2006. 691 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 692 Communication Protocol Generic Requirements", RFC 4657, 693 September 2006. 695 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 696 Engineering", RFC 5305, October 2008. 698 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 699 "Policy-Enabled Path Computation Framework", RFC 5394, 700 December 2008. 702 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 703 Computation Element Communication Protocol (PCEP) 704 Requirements and Protocol Extensions in Support of Global 705 Concurrent Optimization", RFC 5557, July 2009. 707 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 708 Code: The Implementation Status Section", RFC 6982, July 709 2013. 711 Authors' Addresses 713 Edward Crabbe 714 Google, Inc. 715 1600 Amphitheatre Parkway 716 Mountain View, CA 94043 717 US 719 Email: edc@google.com 721 Ina Minei 722 Google, Inc. 723 1600 Amphitheatre Parkway 724 Mountain View, CA 94043 725 US 727 Email: inaminei@google.com 729 Siva Sivabalan 730 Cisco Systems, Inc. 731 170 West Tasman Dr. 732 San Jose, CA 95134 733 US 735 Email: msiva@cisco.com 736 Robert Varga 737 Pantheon Technologies SRO 738 Mlynske Nivy 56 739 Bratislava 821 05 740 Slovakia 742 Email: robert.varga@pantheon.sk