idnits 2.17.1 draft-crabbe-pce-pce-initiated-lsp-02.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 13 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 (July 12, 2013) is 3940 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 265, but not defined == Unused Reference: 'RFC2205' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RFC5089' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC3346' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC5557' is defined on line 586, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-05 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Crabbe 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track I. Minei 5 Expires: January 13, 2014 Juniper Networks, Inc. 6 S. Sivabalan 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 July 12, 2013 12 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 13 draft-crabbe-pce-pce-initiated-lsp-02 15 Abstract 17 The Path Computation Element Communication Protocol (PCEP) provides 18 mechanisms for Path Computation Elements (PCEs) to perform path 19 computations in response to Path Computation Clients (PCCs) requests. 21 The extensions described in [I-D.ietf-pce-stateful-pce] provide 22 stateful control of Multiprotocol Label Switching (MPLS) Traffic 23 Engineering Label Switched Paths (TE LSP) via PCEP, for a model where 24 the PCC delegates control over one or more locally configured LSPs to 25 the PCE. This document describes the creation and deletion of PCE- 26 initiated LSPs under the stateful PCE model. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 13, 2014. 50 Copyright Notice 52 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Operation overview . . . . . . . . . . . . . . . . . . . . 5 72 4. Support of PCE-initiated LSPs . . . . . . . . . . . . . . . . 6 73 4.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 6 74 5. PCE-initiated LSP instantiation and deletion . . . . . . . . . 7 75 5.1. The LSP Initiate Message . . . . . . . . . . . . . . . . . 7 76 5.2. The R flag in the SRP Object . . . . . . . . . . . . . . . 8 77 5.3. LSP instantiation . . . . . . . . . . . . . . . . . . . . 9 78 5.4. LSP deletion . . . . . . . . . . . . . . . . . . . . . . . 10 79 6. LSP delegation and cleanup . . . . . . . . . . . . . . . . . . 10 80 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 11 82 7.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 11 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 8.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 12 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 [RFC5440] describes the Path Computation Element Protocol PCEP. PCEP 94 defines the communication between a Path Computation Client (PCC) and 95 a Path Control Element (PCE), or between PCE and PCE, enabling 96 computation of Multiprotocol Label Switching (MPLS) for Traffic 97 Engineering Label Switched Path (TE LSP) characteristics. 99 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 100 extensions to PCEP to enable stateful control of TE LSPs between and 101 across PCEP sessions in compliance with [RFC4657]. It includes 102 mechanisms to effect LSP state synchronization between PCCs and PCEs, 103 delegation of control of LSPs to PCEs, and PCE control of timing and 104 sequence of path computations within and across PCEP sessions and 105 focuses on a model where LSPs are configured on the PCC and control 106 over them is delegated to the PCE. 108 This document describes the setup, maintenance and teardown of PCE- 109 initiated LSPs under the stateful PCE model, without the need for 110 local configuration on the PCC, thus allowing for a dynamic network 111 that is centrally controlled and deployed. 113 2. Terminology 115 This document uses the following terms defined in [RFC5440]: PCC, 116 PCE, PCEP Peer. 118 This document uses the following terms defined in 119 [I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Redelegation 120 Timeout, State Timeout Interval LSP State Report, LSP Update Request. 122 The following terms are defined in this document: 124 PCE-initiated LSP: LSP that is instantiated as a result of a request 125 from the PCE. 127 The message formats in this document are specified using Routing 128 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 130 3. Architectural Overview 132 3.1. Motivation 134 [I-D.ietf-pce-stateful-pce] provides stateful control over LSPs that 135 are locally configured on the PCC. This model relies on the LER 136 taking an active role in delegating locally configured LSPs to the 137 PCE, and is well suited in environments where the LSP placement is 138 fairly static. However, in environments where the LSP placement 139 needs to change in response to application demands, it is useful to 140 support dynamic creation and tear down of LSPs. The ability for a 141 PCE to trigger the creation of LSPs on demand can make possible agile 142 software-driven network operation, and can be seamlessly integrated 143 into a controller-based network architecture, where intelligence in 144 the controller can determine when and where to set up paths. 146 A possible use case is one of a software-driven network, where 147 applications request network resources and paths from the network 148 infrastructure. For example, an application can request a path with 149 certain constraints between two LSRs by contacting the PCE. The PCE 150 can compute a path satisfying the constraints, and instruct the head 151 end LSR to instantiate and signal it. When the path is no longer 152 required by the application, the PCE can request its teardown. 154 Another use case is one of dynamically adjusting aggregate bandwidth 155 between two points in the network using multiple LSPs. This 156 functionality is very similar to auto-bandwidth, but allows for 157 providing the desired capacity through multiple LSPs. This approach 158 overcomes two of the limitations auto-bandwidth can experience: 1) 159 growing the capacity between the endpoints beyond the capacity of 160 individual links in the path and 2) achieving good bin-packing 161 through use of several small LSPs instead of a single large one. The 162 number of LSPs varies based on the demand, and LSPs are created and 163 deleted dynamically to satisfy the bandwidth requirements. 165 Another use case is that of demand engineering, where a PCE with 166 visibility into both the network state and the demand matrix can 167 anticipate and optimize how traffic is distributed across the 168 infrastructure. Such optimizations may require creating new paths 169 across the infrastructure. 171 3.2. Operation overview 173 A PCC indicates its ability to support PCE provisioned dynamic LSPs 174 during the PCEP Initialization Phase via a new flag in the STATEFUL- 175 PCE-CAPABILITY TLV (see details in Section 4.1). 177 The decision when to instantiate or delete a PCE-initiated LSP is out 178 of the scope of this document. To instantiate or delete an LSP, the 179 PCE sends a new message, the Path Computation LSP Initiate Request 180 (PCInitiate) message to the PCC. The LSP Initiate Request MUST 181 include the SRP and LSP objects, and the LSP object MUST include the 182 Symbolic Path Name TLV. 184 For an instantiation operation, the PCE MUST include the ERO and END- 185 POINTS object and may include various attributes as per [RFC5440]. 186 The PCC creates the LSP using the attributes communicated by the PCE, 187 and local values for the unspecified parameters. It assigns a unique 188 PLSP-ID for the LSP and automatically delegates the LSP to the PCE. 189 It also generates an LSP State Report (PCRpt) for the LSP, carrying 190 the newly assigned PLSP-ID and indicating the delegation via the 191 delegation bit. The PCE may update the attributes of the LSP via 192 subsequent PCUpd messages. Subsequent LSP State Report and LSP 193 Update Request for the LSP will carry the PCC-assigned PLSP-ID, which 194 uniquely identifies the LSP. See details in Section 5.3. 196 Once instantiated, the delegation procedures for PCE-initiated LSPs 197 are the same as for PCC initiated LSPs. This applies to the case of 198 a PCE failure as well. In order to allow for network cleanup without 199 manual intervention, the PCC SHOULD support removal of PCE-initiated 200 LSPs as one of the behaviors applied on expiration of the State 201 Timeout Interval [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be 202 picked based on local policy, and can result either in LSP removal, 203 or into reverting to operator-defined default parameters. See 204 details in Section 6. 206 To indicate a delete operation, the PCE MUST use the R flag in the 207 SRP object. As a result of the deletion request, the PCC MUST remove 208 all state related to the LSP, and send a PCRpt with the R flag set 209 for the removed state. See details in Section 5.3. 211 4. Support of PCE-initiated LSPs 213 A PCC indicates its ability to support PCE provisioned dynamic LSPs 214 during the PCEP Initialization phase. The Open Object in the Open 215 message contains the "Stateful PCE Capability" TLV, defined in 216 [I-D.ietf-pce-stateful-pce]. A new flag, the I (LSP-INSTANTIATION- 217 CAPABILITY) flag is introduced to indicate support for instantiation 218 of PCE-initiated LSPs. A PCE can initiate LSPs only for PCCs that 219 advertised this capability and a PCC will follow the procedures 220 described in this document only on sessions where the PCE advertised 221 the I flag. 223 4.1. Stateful PCE Capability TLV 225 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 226 following figure: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type=16 | Length=4 | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Flags |I|S|U| 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 236 Figure 1: STATEFUL-PCE-CAPABILITY TLV format 238 The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it 239 has a fixed length of 4 octets. 241 The value comprises a single field - Flags (32 bits). The U and S 242 bits are defined in [I-D.ietf-pce-stateful-pce]. 244 I (LSP-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, the 245 I Flag indicates that the PCC allows instantiation of an LSP by a 246 PCE. If set to 1 by a PCE, the I flag indicates that the PCE will 247 attempt to instantiate LSPs. The LSP-INSTANTIATION-CAPABILITY 248 flag must be set by both PCC and PCE in order to support PCE- 249 initiated LSP instantiation. 251 Unassigned bits are considered reserved. They MUST be set to 0 on 252 transmission and MUST be ignored on receipt. 254 5. PCE-initiated LSP instantiation and deletion 256 To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The 257 message format, objects and TLVs are discussed separately below for 258 the creation and the deletion cases. 260 5.1. The LSP Initiate Message 262 A Path Computation LSP Initiate Message (also referred to as 263 PCInitiate message) is a PCEP message sent by a PCE to a PCC to 264 trigger LSP instantiation or deletion. The Message-Type field of the 265 PCEP common header for the PCInitiate message is set to [TBD]. The 266 PCInitiate message MUST include the SRP and the LSP objects, and may 267 contain other objects, as discussed later in this section. If either 268 the SRP or the LSP object is missing, the PCC MUST send a PCErr as 269 described in [I-D.ietf-pce-stateful-pce]. LSP instantiation is done 270 by sending an LSP Initiate Message with an LSP object with the 271 reserved PLSP-ID 0. LSP deletion is done by sending an LSP Initiate 272 Message with an LSP object carrying the PLSP-ID of the LSP to be 273 removed and an SRP object with the R flag set (see Section 5.2). 275 The format of a PCInitiate message for LSP instantiation is as 276 follows: 278 ::= 279 280 Where: 282 ::= [] 284 ::= 285 286 287 288 [] 290 Where: 291 is defined in [RFC5440] and extended by PCEP extensions. 293 The SRP object is used to correlate between initiation requests sent 294 by the PCE and the error reports and state reports sent by the PCC. 295 Every request from the PCE receives a new SRP-ID-number. This number 296 is unique per PCEP session and is incremented each time an operation 297 (initiation, update, etc) is requested from the PCE. The value of 298 the SRP-ID-number MUST be echoed back by the PCC in PCErr and PCRpt 299 messages to allow for correlation between requests made by the PCE 300 and errors or state reports generated by the PCC. Details of the SRP 301 object and its use can be found in [I-D.ietf-pce-stateful-pce]. 303 5.2. The R flag in the SRP Object 305 The format of the SRP object is shown Figure 2: 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Flags |R| 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | SRP-ID-number | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | 315 // Optional TLVs // 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Figure 2: The SRP Object format 321 The type object is defined in [I-D.ietf-pce-stateful-pce]. 323 A new flag is defined to indicate a delete operation initiated by the 324 PCE: 326 R (LSP-REMOVE - 1 bit): If set to 1, it indicates a removal request 327 initiated by the PCE. 329 5.3. LSP instantiation 331 LSP instantiation is done by sending an LSP Initiate Message with an 332 LSP object with the reserved PLSP-ID 0. 334 Receipt of a PCInitiate Message with a non-zero PLSP-ID and the R 335 flag in the SRP object set to zero results in a PCErr message of type 336 19 (Invalid Operation) and value 8 (non-zero PLSP-ID in LSP 337 initiation request). 339 The LSP-sig-type field in the LSP is set to the signaling type that 340 is requested for the LSP setup. This draft defines procedures for 341 RSVP-signaled LSPs. 343 The END-POINTS Object is mandatory for an instantiation request of an 344 RSVP-signaled LSP. It contains the source and destination addresses 345 for provisioning the LSP. If the END-POINTS Object is missing, the 346 PCC MUST send a PCErr message with Error-type=6 (Mandatory Object 347 missing) and Error-value=3 (END-POINTS Object missing). 349 The ERO Object is mandatory for an instantiation request. It 350 contains the ERO for the LSP. If the ERO Object is missing, the PCC 351 MUST send a PCErr message with Error-type=6 (Mandatory Object 352 missing) and Error-value=9 (ERO Object missing). 354 The LSP Object MUST include the SYMBOLIC-PATH-NAME TLV, which will be 355 used to correlate between the PCC-assigned PLSP-ID and the LSP. If 356 the TLV is missing, the PCC MUST send a PCErr message with Error- 357 type=6(Mandatory object missing) and Error-value=14 (SYMBOLIC-PATH- 358 NAME TLV missing). The symbolic name used for provisioning PCE- 359 initiated LSPs must not have conflict with the LSP name of any 360 existing LSP in the PCC. (Existing LSPs may be either statically 361 configured, or initiated by another PCE). If there is conflict with 362 the LSP name, the PCC MUST send a PCErr message with Error-type=23 363 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). 364 The only exception to this rule is for LSPs for which the State 365 timeout timer is running (see Section 6). 367 The PCE MAY include various attributes as per [RFC5440]. The PCC 368 MUST use these values in the LSP instantiation, and local values for 369 unspecified parameters. After the LSP setup, the PCC MUST send a 370 PCRpt to the PCE, reflecting these values. The SRP object in the 371 PCRpt message MUST echo the value of the PCInitiate message that 372 triggered the setup. 374 If the PCC determines that the LSP parameters proposed in the 375 PCInitiate message are unacceptable, it MUST trigger a PCErr with 376 error-type=TBD (PCE instantiation error) and error-value=1 377 (Unacceptable instantiation parameters). If the PCC encounters an 378 internal error during the processing of the PCInitiate message, it 379 MUST trigger a PCErr with error-type=TBD (PCE instantiation error) 380 and error-value=2 (Internal error). 382 A PCC MUST relay to the PCE errors it encounters in the setup of PCE- 383 initiated LSP by sending a PCErr with error-type=TBD (PCE 384 instantiation error) and error-value=3 (RSVP signaling error). The 385 PCErr MUST echo the SRP-id-number of the PCInitiate message. The 386 PCEP-ERROR object SHOULD include the RSVP Error Spec TLV (if an ERROR 387 SPEC was returned to the PCC by a downstream node). 389 A PCC SHOULD be able to place a limit on either the number of LSPs or 390 the percentage of resources that are allocated to honor PCE-initiated 391 LSP requests. As soon as that limit is reached, the PCC MUST send a 392 PCErr message of type 19 (Invalid Operation) and value TBD "PCE- 393 initiated limit reached" and is free to drop any incoming PCInitiate 394 messages without additional processing. 396 5.4. LSP deletion 398 PCE-initiated removal of a PCE-initiated LSP is done by setting the R 399 (remove) flag in the SRP Object in the PCInitiate message from the 400 PCE. The LSP is identified by the PLSP-ID in the LSP object. If the 401 PLSP-ID is unknown, the PCC MUST generate a PCErr with error type 19, 402 error value 3, "Unknown PLSP-ID". A PLSP-ID of zero removes all LSPs 403 that were initiated by the PCE. If the PLSP-ID specified in the 404 PCInitiate message is not delegated to the PCE, the PCC MUST send a 405 PCErr message indicating "LSP is not delegated" (Error code 19, error 406 value 1 ([I-D.ietf-pce-stateful-pce]). Following the removal of the 407 LSP, the PCC MUST send a PCRpt as described in 408 [I-D.ietf-pce-stateful-pce]. 410 6. LSP delegation and cleanup 412 PCE-initiated LSPs are automatically delegated by the PCC to the PCE 413 upon instantiation. The PCC MUST delegate the LSP to the PCE by 414 setting the delegation bit to 1 in the PCRpt that includes the 415 assigned PLSP-ID. All subsequent messages from the PCC must have the 416 delegation bit set to 1. The PCC cannot revoke the delegation for 417 PCE-initiated LSPs for an active PCEP session. Sending a PCRpt 418 message with the delegation bit set to 0 results in a PCErr message 419 of type 19 (Invalid Operation) and value TBD "Delegation for PCE- 420 initiated LSP cannot be revoked". 422 A PCE MAY return a delegation to the PCC, to allow for LSP transfer 423 between PCEs. Doing so MUST trigger the State Timeout Interval timer 424 ([I-D.ietf-pce-stateful-pce]). 426 In case of PCEP session failure, control over PCE-initiated LSPs 427 reverts to the PCC at the expiration of the redelegation timeout. To 428 obtain control of a PCE-initiated LSP, a PCE (either the original or 429 one of its backups) sends a PCInitiate message, including just the 430 SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to 431 take control of. Receipt of a PCInitiate message with a non-zero 432 PLSP-ID normally results in the generation of a PCErr. If the State 433 Timeout timer is running, the PCC MUST NOT generate an error and 434 redelegate the LSP to the PCE. The State Timeout timer is stopped 435 upon the redelegation. 437 The State Timeout timer ensures that a PCE crash does not result in 438 automatic and immediate disruption for the services using PCE- 439 initiated LSPs. PCE-initiated LSPs are not be removed immediately 440 upon PCE failure. Instead, they are cleaned up on the expiration of 441 this timer. This allows for network cleanup without manual 442 intervention. The PCC SHOULD support removal of PCE-initiated LSPs 443 as one of the behaviors applied on expiration of the State Timeout 444 Interval [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be picked 445 based on local policy, and can result either in LSP removal, or into 446 reverting to operator-defined default parameters. 448 7. IANA considerations 450 7.1. PCEP Messages 452 This document defines the following new PCEP messages: 454 Value Meaning Reference 455 12 Initiate This document 457 7.2. PCEP-Error Object 459 This document defines new Error-Type and Error-Value for the 460 following new error conditions: 462 Error-Type Meaning 463 6 Mandatory Object missing 464 Error-value=13: LSP cleanup TLV missing 465 Error-value=14: SYMBOLIC-PATH-NAME TLV missing 466 19 Invalid operation 467 Error-value=6: PCE-initiated LSP limit reached 468 Error-value=7: Delegation for PCE-initiated LSP cannot 469 be revoked 470 Error-value=8: Non-zero PLSP-ID in LSP initiation 471 request 472 23 Bad parameter value 473 Error-value=1: SYMBOLIC-PATH-NAME in use 474 24 LSP instantiation error 475 Error-value=1: Unacceptable instantiation parameters 476 Error-value=2: Internal error 477 Error-value=3: RSVP signaling error 479 8. Security Considerations 481 The security considerations described in [I-D.ietf-pce-stateful-pce] 482 apply to the extensions described in this document. Additional 483 considerations related to a malicious PCE are introduced. 485 8.1. Malicious PCE 487 The LSP instantiation mechanism described in this document allows a 488 PCE to generate state on the PCC and throughout the network. As a 489 result, it introduces a new attack vector: an attacker may flood the 490 PCC with LSP instantiation requests and consume network and LSR 491 resources, either by spoofing messages or by compromising the PCE 492 itself. 494 A PCC can protect itself from such an attack by imposing a limit on 495 either the number of LSPs or the percentage of resources that are 496 allocated to honor PCE-initiated LSP requests. As soon as that limit 497 is reached, the PCC MUST send a PCErr message of type 19 (Invalid 498 Operation) and value 3 "PCE-initiated LSP limit reached" and is free 499 to drop any incoming PCInitiate messages without additional 500 processing. 502 Rapid flaps triggered by the PCE can also be an attack vector. This 503 will be discussed in a future version of this document. 505 9. Acknowledgements 507 We would like to thank Jan Medved, Ambrose Kwong and Raveendra Trovi 508 for their contributions to this document. 510 10. References 512 10.1. Normative References 514 [I-D.ietf-pce-stateful-pce] 515 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 516 Extensions for Stateful PCE", 517 draft-ietf-pce-stateful-pce-05 (work in progress), 518 July 2013. 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, March 1997. 523 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 524 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 525 Functional Specification", RFC 2205, September 1997. 527 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 528 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 529 Tunnels", RFC 3209, December 2001. 531 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 532 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 533 May 2005. 535 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 536 "OSPF Protocol Extensions for Path Computation Element 537 (PCE) Discovery", RFC 5088, January 2008. 539 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 540 "IS-IS Protocol Extensions for Path Computation Element 541 (PCE) Discovery", RFC 5089, January 2008. 543 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 544 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 545 May 2008. 547 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 548 (PCE) Communication Protocol (PCEP)", RFC 5440, 549 March 2009. 551 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 552 Used to Form Encoding Rules in Various Routing Protocol 553 Specifications", RFC 5511, April 2009. 555 10.2. Informative References 557 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 558 McManus, "Requirements for Traffic Engineering Over MPLS", 559 RFC 2702, September 1999. 561 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 562 Label Switching Architecture", RFC 3031, January 2001. 564 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 565 Christian, B., and W. Lai, "Applicability Statement for 566 Traffic Engineering with MPLS", RFC 3346, August 2002. 568 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 569 (TE) Extensions to OSPF Version 2", RFC 3630, 570 September 2003. 572 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 573 Element (PCE)-Based Architecture", RFC 4655, August 2006. 575 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 576 Communication Protocol Generic Requirements", RFC 4657, 577 September 2006. 579 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 580 Engineering", RFC 5305, October 2008. 582 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 583 "Policy-Enabled Path Computation Framework", RFC 5394, 584 December 2008. 586 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 587 Computation Element Communication Protocol (PCEP) 588 Requirements and Protocol Extensions in Support of Global 589 Concurrent Optimization", RFC 5557, July 2009. 591 Authors' Addresses 593 Edward Crabbe 594 Google, Inc. 595 1600 Amphitheatre Parkway 596 Mountain View, CA 94043 597 US 599 Email: edc@google.com 600 Ina Minei 601 Juniper Networks, Inc. 602 1194 N. Mathilda Ave. 603 Sunnyvale, CA 94089 604 US 606 Email: ina@juniper.net 608 Siva Sivabalan 609 Cisco Systems, Inc. 610 170 West Tasman Dr. 611 San Jose, CA 95134 612 US 614 Email: msiva@cisco.com 616 Robert Varga 617 Pantheon Technologies SRO 618 Mlynske Nivy 56 619 Bratislava 821 05 620 Slovakia 622 Email: robert.varga@pantheon.sk