idnits 2.17.1 draft-ietf-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 27 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2014) is 3471 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) == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-09 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-01 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 3 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 4 Intended status: Standards Track I. Minei 5 Expires: April 28, 2015 Google, Inc. 6 S. Sivabalan 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 October 25, 2014 12 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 13 draft-ietf-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 for stateful PCE provide stateful control of 22 Multiprotocol Label Switching (MPLS) Traffic Engineering Label 23 Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates 24 control over one or more locally configured LSPs to the PCE. This 25 document describes the creation and deletion of PCE-initiated LSPs 26 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 April 28, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . 15 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 and SHOULD include the optional SPEAKER-IDENTITY- 199 ID TLV defined in [I-D.ietf-pce-stateful-sync-optimizations] 200 identifying the PCE that requested the LSP creation. This PCRpt 201 message MUST include the SRP object, with the SRP-id-number used in 202 the SRP object of the PCInitate message. The PCE may update the 203 attributes of the LSP via subsequent PCUpd messages. Subsequent LSP 204 State Report and LSP Update Request for the LSP will carry the PCC- 205 assigned PLSP-ID, which uniquely identifies the LSP. See details in 206 Section 5.3. 208 Once instantiated, the delegation procedures for PCE-initiated LSPs 209 are the same as for PCC initiated LSPs as described in 210 [I-D.ietf-pce-stateful-pce]. This applies to the case of a PCE 211 failure as well. In order to allow for network cleanup without 212 manual intervention, the PCC SHOULD support removal of PCE-initiated 213 LSPs as one of the behaviors applied on expiration of the State 214 Timeout Interval [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be 215 picked based on local policy, and can result either in LSP removal, 216 or into reverting to operator-defined default parameters. See 217 details in Section 6. A PCE may return a delegation to the PCC in 218 order to facilitate re-delegation of its LSPs to an alternate PCE. 220 To indicate a delete operation, the PCE MUST use the R flag in the 221 SRP object in a PCUpd message. As a result of the deletion request, 222 the PCC MUST remove all state related to the LSP, and send a PCRpt 223 with the R flag set in the LSP object for the removed state. See 224 details in Section 5.4. 226 4. Support of PCE-initiated LSPs 228 A PCC indicates its ability to support PCE provisioned dynamic LSPs 229 during the PCEP Initialization phase. The Open Object in the Open 230 message contains the "Stateful PCE Capability" TLV, defined in 231 [I-D.ietf-pce-stateful-pce]. A new flag, the I (LSP-INSTANTIATION- 232 CAPABILITY) flag is introduced to indicate support for instantiation 233 of PCE-initiated LSPs. A PCE can initiate LSPs only for PCCs that 234 advertised this capability and a PCC will follow the procedures 235 described in this document only on sessions where the PCE advertised 236 the I flag. 238 4.1. Stateful PCE Capability TLV 240 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 241 following figure: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type=16 | Length=4 | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Flags |I|S|U| 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 251 Figure 1: STATEFUL-PCE-CAPABILITY TLV format 253 The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it 254 has a fixed length of 4 octets. 256 The value comprises a single field - Flags (32 bits). The U and S 257 bits are defined in [I-D.ietf-pce-stateful-pce] and 258 [I-D.ietf-pce-stateful-sync-optimizations] respectively. 260 I (LSP-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, the 261 I Flag indicates that the PCC allows instantiation of an LSP by a 262 PCE. If set to 1 by a PCE, the I flag indicates that the PCE will 263 attempt to instantiate LSPs. The LSP-INSTANTIATION-CAPABILITY 264 flag must be set by both PCC and PCE in order to support PCE- 265 initiated LSP instantiation. 267 Unassigned bits are considered reserved. They MUST be set to 0 on 268 transmission and MUST be ignored on receipt. 270 5. PCE-initiated LSP instantiation and deletion 272 To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The 273 message format, objects and TLVs are discussed separately below for 274 the creation and the deletion cases. 276 5.1. The LSP Initiate Message 278 A Path Computation LSP Initiate Message (also referred to as 279 PCInitiate message) is a PCEP message sent by a PCE to a PCC to 280 trigger LSP instantiation or deletion. The Message-Type field of the 281 PCEP common header for the PCInitiate message is set to 12 (suggested 282 value, to be assigned by IANA). The PCInitiate message MUST include 283 the SRP and the LSP objects, and may contain other objects, as 284 discussed later in this section. If either the SRP or the LSP object 285 is missing, the PCC MUST send a PCErr as described in 287 [I-D.ietf-pce-stateful-pce]. LSP instantiation is done by sending an 288 LSP Initiate Message with an LSP object with the reserved PLSP-ID 0. 289 LSP deletion is done by sending an LSP Initiate Message with an LSP 290 object carrying the PLSP-ID of the LSP to be removed and an SRP 291 object with the R flag set (see Section 5.2). 293 The format of a PCInitiate message for LSP instantiation is as 294 follows: 296 ::= 297 298 Where: 300 ::= [] 302 ::= (|) 304 ::= 305 306 307 308 [] 310 ::= 311 313 Where: 314 is defined in [RFC5440] and extended by PCEP extensions. 316 The SRP object is used to correlate between initiation requests sent 317 by the PCE and the error reports and state reports sent by the PCC. 318 Every request from the PCE receives a new SRP-ID-number. This number 319 is unique per PCEP session and is incremented each time an operation 320 (initiation, update, etc) is requested from the PCE. The value of 321 the SRP-ID-number MUST be echoed back by the PCC in PCErr and PCRpt 322 messages to allow for correlation between requests made by the PCE 323 and errors or state reports generated by the PCC. Details of the SRP 324 object and its use can be found in [I-D.ietf-pce-stateful-pce]. 326 5.2. The R flag in the SRP Object 328 The format of the SRP object is shown Figure 2: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Flags |R| 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | SRP-ID-number | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 // Optional TLVs // 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 2: The SRP Object format 344 The type object is defined in [I-D.ietf-pce-stateful-pce]. 346 A new flag is defined to indicate a delete operation initiated by the 347 PCE: 349 R (LSP-REMOVE - 1 bit): If set to 1, it indicates a removal request 350 initiated by the PCE. 352 5.3. LSP instantiation 354 LSP instantiation is done by sending an LSP Initiate Message with an 355 LSP object with the reserved PLSP-ID 0. The LSP is set up using 356 RSVP-TE, extensions for other setup methods are outside the scope of 357 this draft. 359 Receipt of a PCInitiate Message with a non-zero PLSP-ID and the R 360 flag in the SRP object set to zero results in a PCErr message of type 361 19 (Invalid Operation) and value 8 (non-zero PLSP-ID in LSP 362 initiation request). 364 The END-POINTS Object is mandatory for an instantiation request of an 365 RSVP-signaled LSP. It contains the source and destination addresses 366 for provisioning the LSP. If the END-POINTS Object is missing, the 367 PCC MUST send a PCErr message with Error-type=6 (Mandatory Object 368 missing) and Error-value=3 (END-POINTS Object missing). 370 The ERO Object is mandatory for an instantiation request. It 371 contains the ERO for the LSP. If the ERO Object is missing, the PCC 372 MUST send a PCErr message with Error-type=6 (Mandatory Object 373 missing) and Error-value=9 (ERO Object missing). 375 The LSP Object MUST include the SYMBOLIC-PATH-NAME TLV, which will be 376 used to correlate between the PCC-assigned PLSP-ID and the LSP. If 377 the TLV is missing, the PCC MUST send a PCErr message with Error- 378 type=6(Mandatory object missing) and Error-value=14 (SYMBOLIC-PATH- 379 NAME TLV missing). The symbolic name used for provisioning PCE- 380 initiated LSPs must not have conflict with the LSP name of any 381 existing LSP in the PCC. (Existing LSPs may be either statically 382 configured, or initiated by another PCE). If there is conflict with 383 the LSP name, the PCC MUST send a PCErr message with Error-type=23 384 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). 385 The only exception to this rule is for LSPs for which the State 386 timeout timer is running (see Section 6). 388 The PCE MAY include various attributes as per [RFC5440]. The PCC 389 MUST use these values in the LSP instantiation, and local values for 390 unspecified parameters. After the LSP setup, the PCC MUST send a 391 PCRpt to the PCE, reflecting these values. The SRP object in the 392 PCRpt message MUST echo the value of the PCInitiate message that 393 triggered the setup. LSPs that were instantiated as a result of a 394 PCInitiate message MUST have the C flag set in the LSP object. 396 If the PCC determines that the LSP parameters proposed in the 397 PCInitiate message are unacceptable, it MUST trigger a PCErr with 398 error-type=TBD (PCE instantiation error) and error-value=1 399 (Unacceptable instantiation parameters). If the PCC encounters an 400 internal error during the processing of the PCInitiate message, it 401 MUST trigger a PCErr with error-type=TBD (PCE instantiation error) 402 and error-value=2 (Internal error). 404 A PCC MUST relay to the PCE errors it encounters in the setup of PCE- 405 initiated LSP by sending a PCErr with error-type=TBD (PCE 406 instantiation error) and error-value=3 (RSVP signaling error). The 407 PCErr MUST echo the SRP-id-number of the PCInitiate message. The 408 PCEP-ERROR object SHOULD include the RSVP Error Spec TLV (if an ERROR 409 SPEC was returned to the PCC by a downstream node). After the LSP is 410 set up, errors in RSVP signaling are reported in PCRpt messages, as 411 described in [I-D.ietf-pce-stateful-pce]. 413 A PCC SHOULD be able to place a limit on either the number of LSPs or 414 the percentage of resources that are allocated to honor PCE-initiated 415 LSP requests. As soon as that limit is reached, the PCC MUST send a 416 PCErr message of type 19 (Invalid Operation) and value TBD "PCE- 417 initiated limit reached" and is free to drop any incoming PCInitiate 418 messages without additional processing. 420 Similarly, the PCE SHOULD be able to place a limit on either the 421 number of LSP initiation requests pending for a particular PCC, or on 422 the time it waits for a response (positive or negative) to a 423 PCInitiate request from a PCC and MAY take further action (such as 424 closing the session or removing all its LSPs) if this limit is 425 reached. 427 On succesful completion of the LSP instantiation, the PCC assigns a 428 PLSP-ID, and immediately delegates the LSP to the PCE by sending a 429 PCRpt with the Delegate flag set. The PCRpt MUST include the SRP-ID- 430 number of the PCInitiate request that triggered its creation. PCE- 431 initiated LSPs are identified with the Create flag in the LSP Object. 433 5.3.1. The Create flag 435 The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included 436 here for easy reference. 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | PLSP-ID |Flags |C| O|A|R|S|D| 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 // TLVs // 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 3: The LSP Object format 449 A new flag, the Create (C) flag is introduced. On a PCRpt message, 450 the C Flag set to 1 indicates that this LSP was created via a 451 PCInitiate message. The C Flag MUST be set to 1 on each PCRpt 452 message for the duration of existence of the LSP. The Create flag 453 allows PCEs to be aware of which LSPs were PCE-initiated (a state 454 that would otherwise only be known by the PCC and the PCE that 455 initiated them). 457 The optional SPEAKER-IDENTITY-ID TLV defined in 458 [I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP 459 object as an optional TLV for LSPs for which the C-flag is 1, to 460 identify the PCE who initiated the creation of the LSP on all PCEP 461 sessions. If the TLV appears for an LSP for which the C flag is 0, 462 the TLV MUST be ignored the PCC MUST send a PCErr message with Error- 463 type 23 ("Bad parameter value") and error value 2 ("Speaker identity 464 included for an LSP that is not PCE-initiated"). 466 5.4. LSP deletion 468 PCE-initiated removal of a PCE-initiated LSP is done by setting the R 469 (remove) flag in the SRP Object in the PCInitiate message from the 470 PCE. The LSP is identified by the PLSP-ID in the LSP object. If the 471 PLSP-ID is unknown, the PCC MUST generate a PCErr with error type 19, 472 error value 3, "Unknown PLSP-ID". A PLSP-ID of zero removes all LSPs 473 that were initiated by the PCE. If the PLSP-ID specified in the 474 PCInitiate message is not delegated to the PCE, the PCC MUST send a 475 PCErr message indicating "LSP is not delegated" (Error code 19, error 476 value 1 ([I-D.ietf-pce-stateful-pce]). If the PLSP-ID specified in 477 the PCInitiate message was not created by the PCE, the PCC MUST send 478 a PCErr message indicating "LSP is not PCE initiated" (Error code 19, 479 error value TBD). Following the removal of the LSP, the PCC MUST 480 send a PCRpt as described in [I-D.ietf-pce-stateful-pce]. The SRP 481 object in the PCRpt MUST include the SRP-ID-number from the 482 PCInitiate message that triggered the removal. The R flag in the SRP 483 object SHOULD be set. 485 6. LSP delegation and cleanup 487 PCE-initiated LSPs are automatically delegated by the PCC to the PCE 488 upon instantiation. The PCC MUST set the delegation bit to 1 in the 489 PCRpt that includes the assigned PLSP-ID. All subsequent messages 490 from the PCC must have the delegation bit set to 1. The PCC cannot 491 revoke the delegation for PCE-initiated LSPs for an active PCEP 492 session. Sending a PCRpt message with the delegation bit set to 0 493 results in a PCErr message of type 19 (Invalid Operation) and value 494 TBD "Delegation for PCE-initiated LSP cannot be revoked". The PCE 495 MAY further react by closing the session. 497 A PCE MAY return a delegation to the PCC, to allow for LSP transfer 498 between PCEs. Doing so MUST trigger the State Timeout Interval timer 499 ([I-D.ietf-pce-stateful-pce]). 501 In case of PCEP session failure, control over PCE-initiated LSPs 502 reverts to the PCC at the expiration of the redelegation timeout. To 503 obtain control of a PCE-initiated LSP, a PCE (either the original or 504 one of its backups) sends a PCInitiate message, including just the 505 SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to 506 take control of. Receipt of a PCInitiate message with a non-zero 507 PLSP-ID normally results in the generation of a PCErr. If the State 508 Timeout timer is running, the PCC MUST NOT generate an error and 509 redelegate the LSP to the PCE. The State Timeout timer is stopped 510 upon the redelegation. After obtaining control of the LSP, the PCE 511 may remove it using the procedures described in this document. 513 The State Timeout timer ensures that a PCE crash does not result in 514 automatic and immediate disruption for the services using PCE- 515 initiated LSPs. PCE-initiated LSPs are not be removed immediately 516 upon PCE failure. Instead, they are cleaned up on the expiration of 517 this timer. This allows for network cleanup without manual 518 intervention. The PCC SHOULD support removal of PCE-initiated LSPs 519 as one of the behaviors applied on expiration of the State Timeout 520 Interval [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be picked 521 based on local policy, and can result either in LSP removal, or into 522 reverting to operator-defined default parameters. 524 7. Implementation status 526 This section to be removed by the RFC editor. 528 This section records the status of known implementations of the 529 protocol defined by this specification at the time of posting of this 530 Internet-Draft, and is based on a proposal described in [RFC6982]. 531 The description of implementations in this section is intended to 532 assist the IETF in its decision processes in progressing drafts to 533 RFCs. Please note that the listing of any individual implementation 534 here does not imply endorsement by the IETF. Furthermore, no effort 535 has been spent to verify the information presented here that was 536 supplied by IETF contributors. This is not intended as, and must not 537 be construed to be, a catalog of available implementations or their 538 features. Readers are advised to note that other implementations may 539 exist. 541 According to RFC 6982, "this will allow reviewers and working groups 542 to assign due consideration to documents that have the benefit of 543 running code, which may serve as evidence of valuable experimentation 544 and feedback that have made the implemented protocols more mature. 545 It is up to the individual working groups to use this information as 546 they see fit". 548 Two vendors are implementing the extensions described in this draft 549 and have included the functionality in releases that will be shipping 550 in the near future. An additional entity is working on implementing 551 these extensions in the scope of research projects. 553 8. IANA considerations 555 8.1. PCEP Messages 557 This document defines the following new PCEP messages: 559 Value Meaning Reference 560 12 Initiate This document 562 8.2. LSP Object 564 The following values are defined in this document for the Flags field 565 in the LSP Object. 567 Bit Description Reference 569 4 Create This document 571 8.3. PCEP-Error Object 573 This document defines new Error-Type and Error-Value for the 574 following new error conditions: 576 Error-Type Meaning 577 6 Mandatory Object missing 579 Error-value=13: LSP cleanup TLV missing 580 Error-value=14: SYMBOLIC-PATH-NAME TLV missing 581 19 Invalid operation 583 Error-value=6: PCE-initiated LSP limit reached 584 Error-value=7: Delegation for PCE-initiated LSP cannot 585 be revoked 586 Error-value=8: Non-zero PLSP-ID in LSP initiation 587 request 588 23 Bad parameter value 590 Error-value=1: SYMBOLIC-PATH-NAME in use 591 Error-value=2: Speaker identity included for an LSP 592 that is not PCE-initiated 593 24 LSP instantiation error 595 Error-value=1: Unacceptable instantiation parameters 596 Error-value=2: Internal error 597 Error-value=3: RSVP signaling error 599 9. Security Considerations 601 The security considerations described in [I-D.ietf-pce-stateful-pce] 602 apply to the extensions described in this document. Additional 603 considerations related to a malicious PCE are introduced. 605 9.1. Malicious PCE 607 The LSP instantiation mechanism described in this document allows a 608 PCE to generate state on the PCC and throughout the network. As a 609 result, it introduces a new attack vector: an attacker may flood the 610 PCC with LSP instantiation requests and consume network and LSR 611 resources, either by spoofing messages or by compromising the PCE 612 itself. 614 A PCC can protect itself from such an attack by imposing a limit on 615 either the number of LSPs or the percentage of resources that are 616 allocated to honor PCE-initiated LSP requests. As soon as that limit 617 is reached, the PCC MUST send a PCErr message of type 19 (Invalid 618 Operation) and value 3 "PCE-initiated LSP limit reached" and is free 619 to drop any incoming PCInitiate messages for LSP instantiation 620 without additional processing. 622 Rapid flaps triggered by the PCE can also be an attack vector. This 623 will be discussed in a future version of this document. 625 9.2. Malicious PCC 627 The LSP instantiation mechanism described in this document requires 628 the PCE to keep state for LSPs that it instantiates and relies on the 629 PCC responding (with either a state report or an error message) to 630 requests for LSP instantiation. A malicious PCC or one that reached 631 the limit of the number of PCE-initiated LSPs, can ignore PCE 632 requests and consume PCE resources. A PCE can protect itself by 633 imposing a limit on the number of requests pending, or by setting a 634 timeout and it MAY take further action such as closing the session or 635 removing all the LSPs it initiated. 637 10. Acknowledgements 639 We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas, 640 Dhruv Dhody, and Raveendra Trovi for their contributions to this 641 document. 643 11. References 645 11.1. Normative References 647 [I-D.ietf-pce-stateful-pce] 648 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 649 Extensions for Stateful PCE", draft-ietf-pce-stateful- 650 pce-09 (work in progress), June 2014. 652 [I-D.ietf-pce-stateful-sync-optimizations] 653 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 654 and D. Dhody, "Optimizations of Label Switched Path State 655 Synchronization Procedures for a Stateful PCE", draft- 656 ietf-pce-stateful-sync-optimizations-01 (work in 657 progress), June 2014. 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, March 1997. 662 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 663 (PCE) Communication Protocol (PCEP)", RFC 5440, March 664 2009. 666 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 667 Used to Form Encoding Rules in Various Routing Protocol 668 Specifications", RFC 5511, April 2009. 670 11.2. Informative References 672 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 673 Communication Protocol Generic Requirements", RFC 4657, 674 September 2006. 676 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 677 Code: The Implementation Status Section", RFC 6982, July 678 2013. 680 Authors' Addresses 682 Edward Crabbe 684 Email: edward.crabbe@gmail.com 686 Ina Minei 687 Google, Inc. 688 1600 Amphitheatre Parkway 689 Mountain View, CA 94043 690 US 692 Email: inaminei@google.com 694 Siva Sivabalan 695 Cisco Systems, Inc. 696 170 West Tasman Dr. 697 San Jose, CA 95134 698 US 700 Email: msiva@cisco.com 701 Robert Varga 702 Pantheon Technologies SRO 703 Mlynske Nivy 56 704 Bratislava 821 05 705 Slovakia 707 Email: robert.varga@pantheon.sk