idnits 2.17.1 draft-ietf-pce-pce-initiated-lsp-05.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 19, 2015) is 3110 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-11 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-03 -- 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 21, 2016 Google, Inc. 6 S. Sivabalan 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 October 19, 2015 12 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 13 draft-ietf-pce-pce-initiated-lsp-05 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 21, 2016. 50 Copyright Notice 52 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . 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.3.1. The Create flag . . . . . . . . . . . . . . . . . . . 11 79 5.3.2. The SPEAKER-IDENTITY-ID TLV . . . . . . . . . . . . . 11 80 5.4. LSP deletion . . . . . . . . . . . . . . . . . . . . . . 11 81 6. LSP delegation and cleanup . . . . . . . . . . . . . . . . . 12 82 7. Implementation status . . . . . . . . . . . . . . . . . . . . 13 83 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 84 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 13 85 8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 13 86 8.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 14 87 8.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 14 88 8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 14 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 15 91 9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 15 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 11.2. Informative References . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 [RFC5440] describes the Path Computation Element Protocol PCEP. PCEP 102 defines the communication between a Path Computation Client (PCC) and 103 a Path Control Element (PCE), or between PCE and PCE, enabling 104 computation of Multiprotocol Label Switching (MPLS) for Traffic 105 Engineering Label Switched Path (TE LSP) characteristics. 107 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 108 extensions to PCEP to enable stateful control of TE LSPs between and 109 across PCEP sessions in compliance with [RFC4657]. It includes 110 mechanisms to effect LSP state synchronization between PCCs and PCEs, 111 delegation of control of LSPs to PCEs, and PCE control of timing and 112 sequence of path computations within and across PCEP sessions and 113 focuses on a model where LSPs are configured on the PCC and control 114 over them is delegated to the PCE. 116 This document describes the setup, maintenance and teardown of PCE- 117 initiated LSPs under the stateful PCE model, without the need for 118 local configuration on the PCC, thus allowing for a dynamic network 119 that is centrally controlled and deployed. 121 2. Terminology 123 This document uses the following terms defined in [RFC5440]: PCC, 124 PCE, PCEP Peer. 126 This document uses the following terms defined in 127 [I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Redelegation 128 Timeout, State Timeout Interval LSP State Report, LSP Update Request. 130 The following terms are defined in this document: 132 PCE-initiated LSP: LSP that is instantiated as a result of a request 133 from the PCE. 135 The message formats in this document are specified using Routing 136 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 138 3. Architectural Overview 140 3.1. Motivation 142 [I-D.ietf-pce-stateful-pce] provides stateful control over LSPs that 143 are locally configured on the PCC. This model relies on the Label 144 Edge Router (LER) taking an active role in delegating locally 145 configured LSPs to the PCE, and is well suited in environments where 146 the LSP placement is fairly static. However, in environments where 147 the LSP placement needs to change in response to application demands, 148 it is useful to support dynamic creation and tear down of LSPs. The 149 ability for a PCE to trigger the creation of LSPs on demand can make 150 possible agile software-driven network operation, and can be 151 seamlessly integrated into a controller-based network architecture, 152 where intelligence in the controller can determine when and where to 153 set up paths. 155 A possible use case is one of a software-driven network, where 156 applications request network resources and paths from the network 157 infrastructure. For example, an application can request a path with 158 certain constraints between two LSRs by contacting the PCE. The PCE 159 can compute a path satisfying the constraints, and instruct the head 160 end LSR to instantiate and signal it. When the path is no longer 161 required by the application, the PCE can request its teardown. 163 Another use case is one of dynamically adjusting aggregate bandwidth 164 between two points in the network using multiple LSPs. This 165 functionality is very similar to auto-bandwidth, but allows for 166 providing the desired capacity through multiple LSPs. This approach 167 overcomes two of the limitations auto-bandwidth can experience: 1) 168 growing the capacity between the endpoints beyond the capacity of 169 individual links in the path and 2) achieving good bin-packing 170 through use of several small LSPs instead of a single large one. The 171 number of LSPs varies based on the demand, and LSPs are created and 172 deleted dynamically to satisfy the bandwidth requirements. 174 Another use case is that of demand engineering, where a PCE with 175 visibility into both the network state and the demand matrix can 176 anticipate and optimize how traffic is distributed across the 177 infrastructure. Such optimizations may require creating new paths 178 across the infrastructure. 180 3.2. Operation overview 182 A PCC or PCE indicates its ability to support PCE provisioned dynamic 183 LSPs during the PCEP Initialization Phase via a new flag in the 184 STATEFUL-PCE-CAPABILITY TLV (see details in Section 4.1). 186 The decision when to instantiate or delete a PCE-initiated LSP is out 187 of the scope of this document. To instantiate or delete an LSP, the 188 PCE sends a new message, the Path Computation LSP Initiate Request 189 (PCInitiate) message to the PCC. The LSP Initiate Request MUST 190 include the SRP and LSP objects ([I-D.ietf-pce-stateful-pce]), and 191 the LSP object MUST include the Symbolic Path Name TLV and MUST have 192 a PLSP-ID ([I-D.ietf-pce-stateful-pce]) of 0. 194 For an instantiation operation, the PCE MUST include the ERO and END- 195 POINTS object and may include various attributes as per [RFC5440]. 196 The PCC creates the LSP using the attributes communicated by the PCE, 197 and local values for the unspecified parameters. It assigns a unique 198 PLSP-ID for the LSP and automatically delegates the LSP to the PCE. 199 It also generates an LSP State Report (PCRpt) for the LSP, carrying 200 the newly assigned PLSP-ID and indicating the delegation via the 201 Delegate flag in the LSP object. In addition to the Delegate flag, 202 the PCC also sets the Create flag in the LSP object (see 203 Section 5.3.1), to indicate that the LSP was created as a result of a 204 PCInitiate message and SHOULD include the optional SPEAKER-IDENTITY- 205 ID TLV defined in [I-D.ietf-pce-stateful-sync-optimizations] 206 identifying the PCE that requested the LSP creation. This PCRpt 207 message MUST include the SRP object, with the SRP-id-number used in 208 the SRP object of the PCInitate message. The PCE may update the 209 attributes of the LSP via subsequent PCUpd messages. Subsequent LSP 210 State Report and LSP Update Request for the LSP will carry the PCC- 211 assigned PLSP-ID, which uniquely identifies the LSP. See details in 212 Section 5.3. 214 Once instantiated, the delegation procedures for PCE-initiated LSPs 215 are the same as for PCC initiated LSPs as described in 216 [I-D.ietf-pce-stateful-pce], with the exception that the PCC cannot 217 revoke a delegation for a PCE-initiated LSP. This applies to the 218 case of a PCE failure as well. In order to allow for network cleanup 219 without manual intervention, the PCC SHOULD support removal of PCE- 220 initiated LSPs as one of the behaviors applied on expiration of the 221 State Timeout Interval [I-D.ietf-pce-stateful-pce]. The behavior 222 SHOULD be picked based on local policy, and can result either in LSP 223 removal, or into reverting to operator-defined default parameters. 224 See details in Section 6. A PCE MAY return a delegation to the PCC 225 in order to facilitate re-delegation of its LSPs to an alternate PCE. 227 To indicate a delete operation, the PCE MUST use the new R flag in 228 the SRP object in a PCInitiate message as described in Section 5.2. 229 As a result of the deletion request, the PCC MUST remove all state 230 related to the LSP, and send a PCRpt with the R flag set in the LSP 231 object for the removed state. See details in Section 5.4. 233 LSP State Synchronization procedures are described in section 5.4 of 234 [I-D.ietf-pce-stateful-pce]. During State Synchronization, a PCC 235 reports the state of its LSPs to the PCE using PCRpt messages and 236 setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the 237 PCC MUST also include the Create Flag in the LSP Object and SHOULD 238 include the SPEAKER-IDENTITY-ID TLV identifying the PCE that 239 requested the LSP creation. At the end of state synchronization, the 240 PCE SHOULD do a sanity check between the reported PCE-Initiated LSPs 241 and local configurations at PCE to initiate LSPs. For any mismatch, 242 the PCE SHOULD send a PCInitiate message to either initiate (again) 243 or remove the LSP. 245 4. Support of PCE-initiated LSPs 247 A PCEP speaker indicates its ability to support PCE provisioned 248 dynamic LSPs during the PCEP Initialization phase. The Open Object 249 in the Open message contains the "Stateful PCE Capability" TLV, 250 defined in [I-D.ietf-pce-stateful-pce]. A new flag, the I (LSP- 251 INSTANTIATION-CAPABILITY) flag is introduced to indicate support for 252 instantiation of PCE-initiated LSPs. A PCE can initiate LSPs only 253 for PCCs that advertised this capability and a PCC will follow the 254 procedures described in this document only on sessions where the PCE 255 advertised the I flag. 257 4.1. Stateful PCE Capability TLV 259 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 260 following figure: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type | Length=4 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Flags |I|S|U| 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 270 Figure 1: STATEFUL-PCE-CAPABILITY TLV format 272 The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it 273 has a fixed length of 4 octets. 275 The value comprises a single field - Flags (32 bits). The U and S 276 bits are defined in [I-D.ietf-pce-stateful-pce] and 277 [I-D.ietf-pce-stateful-sync-optimizations] respectively. 279 I (LSP-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, the 280 I Flag indicates that the PCC allows instantiation of an LSP by a 281 PCE. If set to 1 by a PCE, the I flag indicates that the PCE may 282 attempt to instantiate LSPs. The LSP-INSTANTIATION-CAPABILITY 283 flag must be set by both PCC and PCE in order to support PCE- 284 initiated LSP instantiation. 286 Unassigned bits are considered reserved. They MUST be set to 0 on 287 transmission and MUST be ignored on receipt. 289 5. PCE-initiated LSP instantiation and deletion 291 To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The 292 message format, objects and TLVs are discussed separately below for 293 the creation and the deletion cases. 295 5.1. The LSP Initiate Message 297 A Path Computation LSP Initiate Message (also referred to as 298 PCInitiate message) is a PCEP message sent by a PCE to a PCC to 299 trigger LSP instantiation or deletion. The Message-Type field of the 300 PCEP common header for the PCInitiate message is set to 12 (suggested 301 value, to be assigned by IANA). The PCInitiate message MUST include 302 the SRP and the LSP objects, and may contain other objects, as 303 discussed later in this section. If the SRP object is missing, the 304 PCC MUST send a PCErr with error-type 6 (Mandatory Object missing) 305 and error-value=10 (SRP Object missing) (per 306 [I-D.ietf-pce-stateful-pce]). If the LSP object is missing, the PCC 307 MUST send a PCErr with error-type 6 (Mandatory Object missing) and 308 error-value=8 (LSP Object missing) (per [I-D.ietf-pce-stateful-pce]). 309 LSP instantiation is done by sending an LSP Initiate Message with an 310 LSP object with the reserved PLSP-ID 0. LSP deletion is done by 311 sending an LSP Initiate Message with an LSP object carrying the PLSP- 312 ID of the LSP to be removed and an SRP object with the R flag set 313 (see Section 5.2). 315 The format of a PCInitiate message for LSP instantiation is as 316 follows: 318 ::= 319 320 Where: 322 ::= [] 324 ::= (|) 326 ::= 327 328 329 330 [] 332 ::= 333 335 Where: 336 is defined in [RFC5440] and extended by PCEP extensions. 338 The SRP object is used to correlate between initiation requests sent 339 by the PCE and the error reports and state reports sent by the PCC. 340 Every request from the PCE receives a new SRP-ID-number. This number 341 is unique per PCEP session and is incremented each time an operation 342 (initiation, update, etc) is requested from the PCE. The value of 343 the SRP-ID-number MUST be echoed back by the PCC in PCErr and PCRpt 344 messages to allow for correlation between requests made by the PCE 345 and errors or state reports generated by the PCC. Details of the SRP 346 object and its use can be found in [I-D.ietf-pce-stateful-pce]. 348 5.2. The R flag in the SRP Object 350 The format of the SRP object is shown Figure 2: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Flags |R| 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | SRP-ID-number | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | | 360 // Optional TLVs // 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 2: The SRP Object format 366 The type object is defined in [I-D.ietf-pce-stateful-pce]. 368 A new flag is defined to indicate a delete operation initiated by the 369 PCE: 371 R (LSP-REMOVE - 1 bit): If set to 1, it indicates a removal request 372 initiated by the PCE. 374 5.3. LSP instantiation 376 LSP instantiation is done by sending an LSP Initiate Message with an 377 LSP object with the reserved PLSP-ID 0. The LSP is set up using 378 RSVP-TE, extensions for other setup methods are outside the scope of 379 this draft. 381 Receipt of a PCInitiate Message with a non-zero PLSP-ID and the R 382 flag in the SRP object set to zero results in a PCErr message of type 383 19 (Invalid Operation) and value to be assigned by IANA, suggested 384 value 8 (Non-zero PLSP-ID in LSP initiation request). 386 The END-POINTS Object is mandatory for an instantiation request of an 387 RSVP-signaled LSP. It contains the source and destination addresses 388 for provisioning the LSP. If the END-POINTS Object is missing, the 389 PCC MUST send a PCErr message with Error-type=6 (Mandatory Object 390 missing) and Error-value=3 (END-POINTS Object missing). 392 The ERO Object is mandatory for an instantiation request. It 393 contains the ERO for the LSP. If the ERO Object is missing, the PCC 394 MUST send a PCErr message with Error-type=6 (Mandatory Object 395 missing) and Error-value=9 (ERO Object missing). 397 The LSP Object MUST include the SYMBOLIC-PATH-NAME TLV, which will be 398 used to correlate between the PCC-assigned PLSP-ID and the LSP. If 399 the TLV is missing, the PCC MUST send a PCErr message with Error- 400 type=10 (Invalid object) and Error-value to be assigned by IANA, 401 suggested value 8, (SYMBOLIC-PATH-NAME TLV missing). The symbolic 402 name used for provisioning PCE-initiated LSPs must not have conflict 403 with the LSP name of any existing LSP in the PCC. (Existing LSPs may 404 be either statically configured, or initiated by another PCE). If 405 there is conflict with the LSP name, the PCC MUST send a PCErr 406 message with Error-type to be assigned by IANA, suggested value 23 407 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). 408 The only exception to this rule is for LSPs for which the State 409 timeout timer is running (see Section 6). 411 The PCE MAY include various attributes as per [RFC5440]. The PCC 412 MUST use these values in the LSP instantiation, and local values for 413 unspecified parameters. After the LSP setup, the PCC MUST send a 414 PCRpt to the PCE, reflecting these values. The SRP object in the 415 PCRpt message MUST echo the value of the PCInitiate message that 416 triggered the setup. LSPs that were instantiated as a result of a 417 PCInitiate message MUST have the C flag (Section 5.3.1) set in the 418 LSP object. 420 If the PCC determines that the LSP parameters proposed in the 421 PCInitiate message are unacceptable, it MUST trigger a PCErr with 422 error-type to be assigned by IANA, suggested value 24 (PCE 423 instantiation error) and error-value=1 (Unacceptable instantiation 424 parameters). If the PCC encounters an internal error during the 425 processing of the PCInitiate message, it MUST trigger a PCErr with 426 error-type to be assigned by IANA, suggested vlaue 24 (PCE 427 instantiation error) and error-value=2 (Internal error). 429 A PCC MUST relay to the PCE errors it encounters in the setup of PCE- 430 initiated LSP by sending a PCErr with error-type to be assigned by 431 IANA, suggeseted value 24 (PCE instantiation error) and error-value=3 432 (Signaling error). The PCErr MUST echo the SRP-id-number of the 433 PCInitiate message. The PCEP-ERROR object SHOULD include the RSVP 434 Error Spec TLV (if an ERROR SPEC was returned to the PCC by a 435 downstream node). After the LSP is set up, errors in RSVP signaling 436 are reported in PCRpt messages, as described in 437 [I-D.ietf-pce-stateful-pce]. 439 A PCC SHOULD be able to place a limit on either the number of LSPs or 440 the percentage of resources that are allocated to honor PCE-initiated 441 LSP requests. As soon as that limit is reached, the PCC MUST send a 442 PCErr message of type 19 (Invalid Operation) and value to be assigned 443 by IANA (PCE-initiated limit reached) and is free to drop any 444 incoming PCInitiate messages without additional processing. 446 Similarly, the PCE SHOULD be able to place a limit on either the 447 number of LSP initiation requests pending for a particular PCC, or on 448 the time it waits for a response (positive or negative) to a 449 PCInitiate request from a PCC and MAY take further action (such as 450 closing the session or removing all its LSPs) if this limit is 451 reached. 453 On succesful completion of the LSP instantiation, the PCC assigns a 454 PLSP-ID, and immediately delegates the LSP to the PCE by sending a 455 PCRpt with the Delegate flag set. The PCRpt MUST include the SRP-ID- 456 number of the PCInitiate request that triggered its creation. PCE- 457 initiated LSPs are identified with the Create flag in the LSP Object. 459 5.3.1. The Create flag 461 The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included 462 here for easy reference. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | PLSP-ID |Flags |C| O|A|R|S|D| 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 // TLVs // 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 3: The LSP Object format 475 A new flag, the Create (C) flag is introduced. On a PCRpt message, 476 the C Flag set to 1 indicates that this LSP was created via a 477 PCInitiate message. The C Flag MUST be set to 1 on each PCRpt 478 message for the duration of existence of the LSP. The Create flag 479 allows PCEs to be aware of which LSPs were PCE-initiated (a state 480 that would otherwise only be known by the PCC and the PCE that 481 initiated them). 483 5.3.2. The SPEAKER-IDENTITY-ID TLV 485 The optional SPEAKER-IDENTITY-ID TLV defined in 486 [I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP 487 object in a PCRpt message, as an optional TLV for LSPs for which the 488 C-flag is 1. The SPEAKER-IDENTITY-ID TLV identifies the PCE who 489 initiated the creation of the LSP on all PCEP sessions, a state that 490 would otherwise only be known by the PCC and the PCE that initiated 491 the LSP. If the TLV appears in a PCRpt for an LSP for which the C 492 flag is 0, the TLV MUST be ignored the and the PCE MUST send a PCErr 493 message with Error-type 23 ("Bad parameter value") and error value 2 494 ("Speaker identity included for an LSP that is not PCE-initiated"). 496 5.4. LSP deletion 498 PCE-initiated removal of a PCE-initiated LSP is done by setting the R 499 (remove) flag in the SRP Object in the PCInitiate message from the 500 PCE. The LSP is identified by the PLSP-ID in the LSP object. If the 501 PLSP-ID is unknown, the PCC MUST generate a PCErr with error type 19, 502 error value 3, "Unknown PLSP-ID" ([I-D.ietf-pce-stateful-pce]). A 503 PLSP-ID of zero removes all LSPs that were initiated by the PCE. If 504 the PLSP-ID specified in the PCInitiate message is not delegated to 505 the PCE, the PCC MUST send a PCErr message indicating "LSP is not 506 delegated" (Error code 19, error value 1 507 ([I-D.ietf-pce-stateful-pce]). If the PLSP-ID specified in the 508 PCInitiate message was not created by a PCE, the PCC MUST send a 509 PCErr message indicating that the LSP is not PCE-initiated, Error 510 code 19, error value to be assigned by IANA, suggested value 9 (LSP 511 is not PCE-initiated). Following the removal of the LSP, the PCC 512 MUST send a PCRpt as described in [I-D.ietf-pce-stateful-pce]. The 513 SRP object in the PCRpt MUST include the SRP-ID-number from the 514 PCInitiate message that triggered the removal. The R flag in the SRP 515 object SHOULD be set. 517 6. LSP delegation and cleanup 519 PCE-initiated LSPs are automatically delegated by the PCC to the PCE 520 upon instantiation. The PCC MUST set the delegation bit to 1 in the 521 PCRpt that includes the assigned PLSP-ID. All subsequent messages 522 from the PCC to the PCE that initiated the LSP must have the 523 delegation bit set to 1. The PCC cannot revoke the delegation for 524 PCE-initiated LSPs for an active PCEP session. Sending a PCRpt 525 message with the delegation bit set to 0 to the PCE that initiated 526 the LSP results in a PCErr message of type 19 (Invalid Operation) and 527 error-value value to be assigned by IANA, suggested value 7, 528 (Delegation for PCE-initiated LSP cannot be revoked). The PCE MAY 529 further react by closing the session. 531 A PCE MAY return a delegation to the PCC, to allow for LSP transfer 532 between PCEs. Doing so MUST trigger the State Timeout Interval timer 533 ([I-D.ietf-pce-stateful-pce]) for that particular LSP. 535 In case of PCEP session failure, control over PCE-initiated LSPs 536 reverts to the PCC at the expiration of the redelegation timeout. At 537 this point, the LSP is an "orphan" until the expiration of the State 538 Timeout timer. To obtain control of a PCE-initiated LSP, a PCE 539 (either the original or one of its backups) sends a PCInitiate 540 message, including just the SRP and LSP objects, and carrying the 541 PLSP-ID of the LSP it wants to take control of. Receipt of a 542 PCInitiate message with a non-zero PLSP-ID normally results in the 543 generation of a PCErr. If the LSP is an orphan, the PCC MUST NOT 544 generate an error and MUST redelegate the LSP to the PCE. The State 545 Timeout timer for the LSP is stopped upon the redelegation. After 546 obtaining control of the LSP, the PCE may remove it using the 547 procedures described in this document. 549 The State Timeout timer ensures that a PCE crash does not result in 550 automatic and immediate disruption for the services using PCE- 551 initiated LSPs. PCE-initiated LSPs are not be removed immediately 552 upon PCE failure. Instead, they are cleaned up on the expiration of 553 this timer. This allows for network cleanup without manual 554 intervention. The PCC SHOULD support removal of PCE-initiated LSPs 555 as one of the behaviors applied on expiration of the State Timeout 556 Interval [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be picked 557 based on local policy, and can result either in LSP removal, or into 558 reverting to operator-defined default parameters. 560 7. Implementation status 562 This section to be removed by the RFC editor. 564 This section records the status of known implementations of the 565 protocol defined by this specification at the time of posting of this 566 Internet-Draft, and is based on a proposal described in [RFC6982]. 567 The description of implementations in this section is intended to 568 assist the IETF in its decision processes in progressing drafts to 569 RFCs. Please note that the listing of any individual implementation 570 here does not imply endorsement by the IETF. Furthermore, no effort 571 has been spent to verify the information presented here that was 572 supplied by IETF contributors. This is not intended as, and must not 573 be construed to be, a catalog of available implementations or their 574 features. Readers are advised to note that other implementations may 575 exist. 577 According to RFC 6982, "this will allow reviewers and working groups 578 to assign due consideration to documents that have the benefit of 579 running code, which may serve as evidence of valuable experimentation 580 and feedback that have made the implemented protocols more mature. 581 It is up to the individual working groups to use this information as 582 they see fit". 584 Two vendors are implementing the extensions described in this draft 585 and have included the functionality in releases that will be shipping 586 in the near future. An additional entity is working on implementing 587 these extensions in the scope of research projects. 589 8. IANA considerations 591 8.1. PCEP Messages 593 This document defines the following new PCEP messages: 595 Value Meaning Reference 596 12 Initiate This document 598 8.2. LSP Object 600 The following values are defined in this document for the Flags field 601 in the LSP Object. 603 Bit Description Reference 605 4 Create This document 607 8.3. SRP object 609 The following values are defined in this document for the Flags field 610 in the SRP Object. 612 Bit Description Reference 614 31 LSP-Remove This document 616 8.4. STATEFUL-PCE-CAPABILITY TLV 618 The following values are defined in this document for the Flags field 619 in the STATEFUL-PCE-CAPABILITY TLV 621 Bit Description Reference 623 29 I (LSP-INSTANTIATION- This document 624 CAPABILITY) 626 8.5. PCEP-Error Object 628 This document defines new Error-Type and Error-Value for the 629 following new error conditions: 631 Error-Type Meaning 632 10 Invalid Object 634 Error-value=8: SYMBOLIC-PATH-NAME TLV missing 635 19 Invalid operation 637 Error-value=6: PCE-initiated LSP limit reached 638 Error-value=7: Delegation for PCE-initiated LSP cannot 639 be revoked 640 Error-value=8: Non-zero PLSP-ID in LSP initiation 641 request 642 Error-value=9: LSP is not PCE-initiated 643 Error-value=10: PCE-initiated operation-frequency limit 644 reached 645 23 Bad parameter value 647 Error-value=1: SYMBOLIC-PATH-NAME in use 648 Error-value=2: Speaker identity included for an LSP 649 that is not PCE-initiated 651 24 LSP instantiation error 653 Error-value=1: Unacceptable instantiation parameters 654 Error-value=2: Internal error 655 Error-value=3: Signaling error 657 9. Security Considerations 659 The security considerations described in [I-D.ietf-pce-stateful-pce] 660 apply to the extensions described in this document. Additional 661 considerations related to a malicious PCE are introduced. 663 9.1. Malicious PCE 665 The LSP instantiation mechanism described in this document allows a 666 PCE to generate state on the PCC and throughout the network. As a 667 result, it introduces a new attack vector: an attacker may flood the 668 PCC with LSP instantiation requests and consume network and LSR 669 resources, either by spoofing messages or by compromising the PCE 670 itself. 672 A PCC can protect itself from such an attack by imposing a limit on 673 either the number of LSPs or the percentage of resources that are 674 allocated to honor PCE-initiated LSP requests. As soon as that limit 675 is reached, the PCC MUST send a PCErr message of type 19 (Invalid 676 Operation) and value to be assigned by IANA, suggested value 6 (PCE- 677 initiated LSP limit reached) and is free to drop any incoming 678 PCInitiate messages for LSP instantiation without additional 679 processing. 681 Rapid flaps triggered by the PCE can also be an attack vector. A PCC 682 can protect itself from such an attack by imposing a limit on the 683 number of flaps per unit of time that it allows a PCE to generate. 684 As soon as that limit is reached, a PCC MUST send a PCErr message of 685 type 19 (Invalid Operation) and value to be assigned by IANA, 686 suggested value 10 (PCE-initiated operation frequency reached) and is 687 free to treat the session as having reached the limit in terms of 688 resources allocated to honor PCE-initiated LSP requests, either 689 permanently or for a locally-defined cool-off period. 691 9.2. Malicious PCC 693 The LSP instantiation mechanism described in this document requires 694 the PCE to keep state for LSPs that it instantiates and relies on the 695 PCC responding (with either a state report or an error message) to 696 requests for LSP instantiation. A malicious PCC or one that reached 697 the limit of the number of PCE-initiated LSPs, can ignore PCE 698 requests and consume PCE resources. A PCE can protect itself by 699 imposing a limit on the number of requests pending, or by setting a 700 timeout and it MAY take further action such as closing the session or 701 removing all the LSPs it initiated. 703 10. Acknowledgements 705 We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas, 706 Cyril Margaria, Dhruv Dhody, and Raveendra Trovi for their 707 contributions to this document. 709 11. References 711 11.1. Normative References 713 [I-D.ietf-pce-stateful-pce] 714 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 715 Extensions for Stateful PCE", draft-ietf-pce-stateful- 716 pce-11 (work in progress), April 2015. 718 [I-D.ietf-pce-stateful-sync-optimizations] 719 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 720 and D. Dhody, "Optimizations of Label Switched Path State 721 Synchronization Procedures for a Stateful PCE", draft- 722 ietf-pce-stateful-sync-optimizations-03 (work in 723 progress), October 2015. 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, 727 DOI 10.17487/RFC2119, March 1997, 728 . 730 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 731 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 732 DOI 10.17487/RFC5440, March 2009, 733 . 735 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 736 Used to Form Encoding Rules in Various Routing Protocol 737 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 738 2009, . 740 11.2. Informative References 742 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 743 Element (PCE) Communication Protocol Generic 744 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 745 2006, . 747 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 748 Code: The Implementation Status Section", RFC 6982, 749 DOI 10.17487/RFC6982, July 2013, 750 . 752 Authors' Addresses 754 Edward Crabbe 756 Email: edward.crabbe@gmail.com 758 Ina Minei 759 Google, Inc. 760 1600 Amphitheatre Parkway 761 Mountain View, CA 94043 762 US 764 Email: inaminei@google.com 766 Siva Sivabalan 767 Cisco Systems, Inc. 768 170 West Tasman Dr. 769 San Jose, CA 95134 770 US 772 Email: msiva@cisco.com 774 Robert Varga 775 Pantheon Technologies SRO 776 Mlynske Nivy 56 777 Bratislava 821 05 778 Slovakia 780 Email: robert.varga@pantheon.sk