idnits 2.17.1 draft-ietf-pce-pce-initiated-lsp-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2017) is 2601 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-18 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-09 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 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 Individual Contributor 4 Intended status: Standards Track I. Minei 5 Expires: September 8, 2017 Google, Inc. 6 S. Sivabalan 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 March 7, 2017 12 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 13 draft-ietf-pce-pce-initiated-lsp-09 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 active 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 September 8, 2017. 50 Copyright Notice 52 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . 4 70 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 12 81 6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 12 82 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 14 85 8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 14 86 8.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 14 87 8.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 14 88 8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 15 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 15 91 9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 16 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 11.2. Informative References . . . . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 99 1. Introduction 101 [RFC5440] describes the Path Computation Element Communication 102 Protocol (PCEP). PCEP defines the communication between a Path 103 Computation Client (PCC) and a Path Control Element (PCE), or between 104 PCE and PCE, enabling computation of Multiprotocol Label Switching 105 (MPLS) for Traffic Engineering Label Switched Path (TE LSP) 106 characteristics. 108 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 109 extensions to PCEP to enable stateful control of TE LSPs between and 110 across PCEP sessions in compliance with [RFC4657]. It includes 111 mechanisms to effect LSP state synchronization between PCCs and PCEs, 112 delegation of control of LSPs to PCEs, and PCE control of timing and 113 sequence of path computations within and across PCEP sessions and 114 focuses on a model where LSPs are configured on the PCC and control 115 over them is delegated to the PCE. 117 This document describes the setup, maintenance and teardown of PCE- 118 initiated LSPs under the stateful PCE model, without the need for 119 local configuration on the PCC, thus allowing for a dynamic network 120 that is centrally controlled and deployed. 122 2. Terminology 124 This document uses the following terms defined in [RFC5440]: PCC, 125 PCE, PCEP Peer. 127 This document uses the following terms defined in [RFC8051]: Stateful 128 PCE, Delegation. 130 This document uses the following terms defined in 131 [I-D.ietf-pce-stateful-pce]: Redelegation Timeout Interval, State 132 Timeout Interval, LSP State Report, LSP Update Request. 134 The following terms are defined in this document: 136 PCE-initiated LSP: LSP that is instantiated as a result of a request 137 from the PCE. 139 The message formats in this document are specified using Routing 140 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 142 3. Architectural Overview 144 3.1. Motivation 146 [I-D.ietf-pce-stateful-pce] provides active control over LSPs that 147 are locally configured on the PCC. This model relies on the Label 148 Edge Router (LER) taking an active role in delegating locally 149 configured LSPs to the PCE, and is well suited in environments where 150 the LSP placement is fairly static. However, in environments where 151 the LSP placement needs to change in response to application demands, 152 it is useful to support dynamic creation and tear down of LSPs. The 153 ability for a PCE to trigger the creation of LSPs on demand can make 154 possible agile software-driven network operation, and can be 155 seamlessly integrated into a controller-based network architecture, 156 where intelligence in the controller can determine when and where to 157 set up paths. 159 A possible use case is a software-driven network, where applications 160 request network resources and paths from the network infrastructure. 161 For example, an application can request a path with certain 162 constraints between two LSRs by contacting the PCE. The PCE can 163 compute a path satisfying the constraints, and instruct the head end 164 LSR to instantiate and signal it. When the path is no longer 165 required by the application, the PCE can request its teardown. 167 Another use case is dynamically adjusting aggregate bandwidth between 168 two points in the network using multiple LSPs. This functionality is 169 very similar to auto-bandwidth, but allows for providing the desired 170 capacity through multiple LSPs. This approach overcomes two of the 171 limitations auto-bandwidth can experience: 1) growing the capacity 172 between the endpoints beyond the capacity of individual links in the 173 path and 2) achieving good bin-packing through use of several small 174 LSPs instead of a single large one. The number of LSPs varies based 175 on the demand, and LSPs are created and deleted dynamically to 176 satisfy the bandwidth requirements. 178 Another use case is demand engineering, where a PCE with visibility 179 into both the network state and the demand matrix can anticipate and 180 optimize how traffic is distributed across the infrastructure. Such 181 optimizations may require creating new paths across the 182 infrastructure. 184 3.2. Operation Overview 186 A PCC or PCE indicates its ability to support PCE-provisioned dynamic 187 LSPs during the PCEP Initialization Phase via a new flag in the 188 STATEFUL-PCE-CAPABILITY TLV (see details in Section 4.1). 190 The decision when to instantiate or delete a PCE-initiated LSP is out 191 of the scope of this document. To instantiate or delete an LSP, the 192 PCE sends a new message, the Path Computation LSP Initiate Request 193 (PCInitiate) message to the PCC. The LSP Initiate Request MUST 194 include the SRP and LSP objects ([I-D.ietf-pce-stateful-pce]), and 195 the LSP object MUST include the Symbolic Path Name TLV and MUST have 196 a PLSP-ID ([I-D.ietf-pce-stateful-pce]) of 0. 198 For an instantiation operation, the PCE MUST include the ERO and END- 199 POINTS object and may include various attributes as per [RFC5440]. 200 The PCC creates the LSP using the attributes communicated by the PCE, 201 and local values for the unspecified parameters. It assigns a unique 202 PLSP-ID for the LSP and automatically delegates the LSP to the PCE. 203 It MUST also generate an LSP State Report (PCRpt) for the LSP, 204 carrying the newly assigned PLSP-ID and indicating the delegation via 205 the Delegate flag in the LSP object. In addition to the Delegate 206 flag, the PCC MUST also set the Create flag in the LSP object (see 207 Section 5.3.1), to indicate that the LSP was created as a result of a 208 PCInitiate message and SHOULD include the optional SPEAKER-IDENTITY- 209 ID TLV defined in [I-D.ietf-pce-stateful-sync-optimizations] 210 identifying the PCE that requested the LSP creation. This PCRpt 211 message MUST include the SRP object, with the SRP-id-number used in 212 the SRP object of the PCInitate message. The PCE MAY update the 213 attributes of the LSP via subsequent PCUpd messages. Subsequent LSP 214 State Report and LSP Update Request for the LSP will carry the PCC- 215 assigned PLSP-ID, which uniquely identifies the LSP. See details in 216 Section 5.3. 218 Once instantiated, the delegation procedures for PCE-initiated LSPs 219 are the same as for PCC-initiated LSPs as described in 220 [I-D.ietf-pce-stateful-pce], with the exception that the PCC cannot 221 revoke a delegation for a PCE-initiated LSP. This applies to the 222 case of a PCE failure as well. In order to allow for network cleanup 223 without manual intervention, the PCC SHOULD support removal of PCE- 224 initiated LSPs as one of the behaviors applied on expiration of the 225 State Timeout Interval [I-D.ietf-pce-stateful-pce]. The behavior 226 SHOULD be picked based on local policy, and can result either in LSP 227 removal, or into reverting to operator-defined default parameters. 228 See details in Section 6. A PCE MAY return a delegation to the PCC 229 in order to facilitate re-delegation of its LSPs to an alternate PCE. 231 To indicate a delete operation, the PCE MUST use the new R flag in 232 the SRP object in a PCInitiate message as described in Section 5.2. 233 As a result of the deletion request, the PCC MUST remove all state 234 related to the LSP, and send a PCRpt with the R flag set in the LSP 235 object for the removed state. See details in Section 5.4. 237 LSP State Synchronization procedures are described in section 5.4 of 238 [I-D.ietf-pce-stateful-pce]. During State Synchronization, a PCC 239 reports the state of its LSPs to the PCE using PCRpt messages and 240 setting the SYNC flag in the LSP Object. For PCE-initiated LSPs, the 241 PCC MUST also include the Create Flag in the LSP Object and SHOULD 242 include the SPEAKER-IDENTITY-ID TLV identifying the PCE that 243 requested the LSP creation. At the end of state synchronization, the 244 PCE SHOULD do a sanity check between the reported PCE-Initiated LSPs 245 and local configurations at PCE to initiate LSPs. For any mismatch, 246 the PCE SHOULD send a PCInitiate message to either initiate (again) 247 or remove the LSP. 249 4. Support of PCE-initiated LSPs 251 A PCEP speaker indicates its ability to support PCE-provisioned 252 dynamic LSPs during the PCEP Initialization phase. The Open Object 253 in the Open message contains the "Stateful PCE Capability" TLV, 254 defined in [I-D.ietf-pce-stateful-pce]. A new flag, the I (LSP- 255 INSTANTIATION-CAPABILITY) flag is introduced to indicate support for 256 instantiation of PCE-initiated LSPs. A PCE can initiate LSPs only 257 for PCCs that advertised this capability and a PCC will follow the 258 procedures described in this document only on sessions where the PCE 259 advertised the I flag. 261 4.1. Stateful PCE Capability TLV 263 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 264 following figure: 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type | Length=4 | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Flags |I|S|U| 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 274 Figure 1: STATEFUL-PCE-CAPABILITY TLV format 276 The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it 277 has a fixed length of 4 octets. 279 The value comprises a single field - Flags (32 bits). The U and S 280 bits are defined in [I-D.ietf-pce-stateful-pce] and 281 [I-D.ietf-pce-stateful-sync-optimizations] respectively. 283 I (LSP-INSTANTIATION-CAPABILITY - 1 bit): If set to 1 by a PCC, the 284 I Flag indicates that the PCC allows instantiation of an LSP by a 285 PCE. If set to 1 by a PCE, the I flag indicates that the PCE may 286 attempt to instantiate LSPs. The LSP-INSTANTIATION-CAPABILITY 287 flag must be set by both PCC and PCE in order to support PCE- 288 initiated LSP instantiation. 290 Unassigned bits are considered reserved. They MUST be set to 0 on 291 transmission and MUST be ignored on receipt. 293 5. PCE-initiated LSP Instantiation and Deletion 295 To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The 296 message format, objects and TLVs are discussed separately below for 297 the creation and the deletion cases. 299 5.1. The LSP Initiate Message 301 A Path Computation LSP Initiate Message is referred to as PCInitiate 302 message. It is a PCEP message sent by a PCE to a PCC to trigger LSP 303 instantiation or deletion. The Message-Type field of the PCEP common 304 header for the PCInitiate message is set to 12 (suggested value, to 305 be assigned by IANA). The PCInitiate message MUST include the SRP 306 and the LSP objects, and MAY contain other objects, as discussed 307 later in this section. Missing SRP and LSP objects in the PCInitiate 308 message MUST trigger the same PCErr procedures as specified in 309 [I-D.ietf-pce-stateful-pce] for PCUpd. LSP instantiation is done by 310 sending a PCInitiate message with an LSP object with the reserved 311 PLSP-ID 0. LSP deletion is done by sending a PCInitiate message with 312 an LSP object carrying the PLSP-ID of the LSP to be removed and an 313 SRP object with the R flag set (see Section 5.2). 315 The format of a PCInitiate message for LSP instantiation is as 316 follows: 318 ::= 319 320 Where: 322 ::= 323 [] 325 ::= (| 326 ) 328 ::= 329 330 [] 331 332 [] 334 ::= 335 337 Where: 338 is defined in [RFC5440] and extended by 339 PCEP extensions. 341 The SRP object is used to correlate between initiation requests sent 342 by the PCE and the error reports and state reports sent by the PCC. 343 Every request from the PCE receives a new SRP-ID-number. This number 344 is unique per PCEP session and is incremented each time an operation 345 (initiation, update, etc) is requested from the PCE. The value of 346 the SRP-ID-number MUST be echoed back by the PCC in PCErr and PCRpt 347 messages to allow for correlation between requests made by the PCE 348 and errors or state reports generated by the PCC. Details of the SRP 349 object and its use can be found in [I-D.ietf-pce-stateful-pce]. 351 5.2. The R flag in the SRP Object 353 The format of the SRP object is shown Figure 2: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Flags |R| 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | SRP-ID-number | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 // Optional TLVs // 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 2: The SRP Object format 369 The type object is defined in [I-D.ietf-pce-stateful-pce]. 371 A new flag is defined to indicate a delete operation initiated by the 372 PCE: 374 R (LSP-REMOVE - 1 bit): If set to 1, it indicates a removal request 375 initiated by the PCE. 377 5.3. LSP Instantiation 379 LSP instantiation is done by sending an PCInitiate Message with an 380 LSP object with the reserved PLSP-ID 0. The LSP is set up using 381 RSVP-TE, extensions for other setup methods are outside the scope of 382 this draft. 384 Receipt of a PCInitiate Message with a non-zero PLSP-ID and the R 385 flag in the SRP object set to zero MUST result in a PCErr message of 386 type 19 (Invalid Operation) and value to be assigned by IANA, 387 suggested value 8 (Non-zero PLSP-ID in LSP initiation request). 389 For an instantiation request of an RSVP-signaled LSP, the destination 390 address may be needed. The PCC may determine it from a provided 391 object (e.g., ERO) or a local decision. Alternatively, the END- 392 POINTS object MAY be included to explicitly convey the destination 393 addresses to be used in the RSVP-TE signaling. The source address 394 may be either specified or left up to the PCC decision using the 395 0.0.0.0 value. For LSPs to be setup by other means, the END-POINTS 396 object MAY be omitted; the exact behavior for other types of LSPs 397 will be specified in further documents. 399 The ERO Object is mandatory for an instantiation request. It 400 contains the ERO for the LSP. If the ERO Object is missing, the PCC 401 MUST send a PCErr message with Error-type=6 (Mandatory Object 402 missing) and Error-value=9 (ERO Object missing). 404 The LSP Object MUST include the SYMBOLIC-PATH-NAME TLV, which will be 405 used to correlate between the PCC-assigned PLSP-ID and the LSP. If 406 the TLV is missing, the PCC MUST send a PCErr message with Error- 407 type=10 (Invalid object) and Error-value to be assigned by IANA, 408 suggested value 8, (SYMBOLIC-PATH-NAME TLV missing). The symbolic 409 name used for provisioning PCE-initiated LSPs must not have conflict 410 with the LSP name of any existing LSP in the PCC. (Existing LSPs may 411 be either statically configured, or initiated by another PCE). If 412 there is conflict with the LSP name, the PCC MUST send a PCErr 413 message with Error-type to be assigned by IANA, suggested value 23 414 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). 415 The only exception to this rule is for LSPs for which the State 416 timeout timer is running (see Section 6). 418 The PCE MAY include various attributes as per [RFC5440]. The PCC 419 MUST use these values in the LSP instantiation, and local values for 420 unspecified parameters. After the LSP setup, the PCC MUST send a 421 PCRpt to the PCE, reflecting these values. The SRP object in the 422 PCRpt message MUST echo the value of the PCInitiate message that 423 triggered the setup. LSPs that were instantiated as a result of a 424 PCInitiate message MUST have the Create flag (Section 5.3.1) set in 425 the LSP object. 427 If the PCC determines that the LSP parameters proposed in the 428 PCInitiate message are unacceptable, it MUST trigger a PCErr with 429 error-type to be assigned by IANA, suggested value 24 (PCE 430 instantiation error) and error-value=1 (Unacceptable instantiation 431 parameters). If the PCC encounters an internal error during the 432 processing of the PCInitiate message, it MUST trigger a PCErr with 433 error-type to be assigned by IANA, suggested vlaue 24 (PCE 434 instantiation error) and error-value=2 (Internal error). 436 A PCC MUST relay to the PCE errors it encounters in the setup of PCE- 437 initiated LSP by sending a PCErr with error-type to be assigned by 438 IANA, suggeseted value 24 (PCE instantiation error) and error-value=3 439 (Signaling error). The PCErr MUST echo the SRP-ID-number of the 440 PCInitiate message. The PCEP-ERROR object SHOULD include the RSVP 441 Error Spec TLV (if an ERROR SPEC was returned to the PCC by a 442 downstream node). After the LSP is set up, errors in RSVP signaling 443 are reported in PCRpt messages, as described in 444 [I-D.ietf-pce-stateful-pce]. 446 A PCC SHOULD be able to place a limit on either the number of LSPs or 447 the percentage of resources that are allocated to honor PCE-initiated 448 LSP requests. As soon as that limit is reached, the PCC MUST send a 449 PCErr message of type 19 (Invalid Operation) and value to be assigned 450 by IANA (PCE-initiated limit reached) and is free to drop any 451 incoming PCInitiate messages without additional processing. 453 Similarly, the PCE SHOULD be able to place a limit on either the 454 number of LSP initiation requests pending for a particular PCC, or on 455 the time it waits for a response (positive or negative) to a 456 PCInitiate request from a PCC and MAY take further action (such as 457 closing the session or removing all its LSPs) if this limit is 458 reached. 460 On successful completion of the LSP instantiation, the PCC assigns a 461 PLSP-ID, and immediately delegates the LSP to the PCE by sending a 462 PCRpt with the Delegate flag set. 464 5.3.1. The Create Flag 466 The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included 467 here for easy reference. 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | PLSP-ID |Flags |C| O |A|R|S|D| 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 // TLVs // 475 | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 3: The LSP Object format 480 A new flag, the Create (C) flag is introduced. On a PCRpt message, 481 the C Flag set to 1 indicates that this LSP was created via a 482 PCInitiate message. The C Flag MUST be set to 1 on each PCRpt 483 message for the duration of existence of the LSP. The Create flag 484 allows PCEs to be aware of which LSPs were PCE-initiated (a state 485 that would otherwise only be known by the PCC and the PCE that 486 initiated them). 488 5.3.2. The SPEAKER-IDENTITY-ID TLV 490 The optional SPEAKER-IDENTITY-ID TLV defined in 491 [I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP 492 object in a PCRpt message, as an optional TLV for LSPs for which the 493 C flag is 1. The SPEAKER-IDENTITY-ID TLV identifies the PCE which 494 initiated the creation of the LSP on all PCEP sessions, a state that 495 would otherwise only be known by the PCC and the PCE that initiated 496 the LSP. If the TLV appears in a PCRpt for an LSP for which the C 497 flag is 0, the TLV MUST be ignored the and the PCE MUST send a PCErr 498 message with Error-type 23 ("Bad parameter value") and error value 2 499 ("Speaker identity included for an LSP that is not PCE-initiated"). 501 5.4. LSP Deletion 503 PCE-initiated removal of a PCE-initiated LSP is done by setting the R 504 (remove) flag in the SRP Object in the PCInitiate message from the 505 PCE. The LSP is identified by the PLSP-ID in the LSP object. If the 506 PLSP-ID is unknown, the PCC MUST generate a PCErr with error type 19, 507 error value 3, "Unknown PLSP-ID" ([I-D.ietf-pce-stateful-pce]). A 508 PLSP-ID of zero removes all LSPs that were initiated by the PCE. If 509 the PLSP-ID specified in the PCInitiate message is not delegated to 510 the PCE, the PCC MUST send a PCErr message indicating "LSP is not 511 delegated" (Error code 19, error value 1 as per 512 [I-D.ietf-pce-stateful-pce]). If the PLSP-ID specified in the 513 PCInitiate message was not created by a PCE, the PCC MUST send a 514 PCErr message indicating that the LSP is not PCE-initiated, Error 515 code 19, error value to be assigned by IANA, suggested value 9 (LSP 516 is not PCE-initiated). Following the removal of the LSP, the PCC 517 MUST send a PCRpt as described in [I-D.ietf-pce-stateful-pce]. The 518 SRP object in the PCRpt MUST include the SRP-ID-number from the 519 PCInitiate message that triggered the removal. The R flag in the SRP 520 object MUST be set. 522 6. LSP Delegation and Cleanup 524 PCE-initiated LSPs are automatically delegated by the PCC to the PCE 525 upon instantiation. The PCC MUST set the delegation bit to 1 in the 526 PCRpt that includes the assigned PLSP-ID. All subsequent messages 527 from the PCC to the PCE that initiated the LSP MUST have the 528 delegation bit set to 1. The PCC cannot revoke the delegation for 529 PCE-initiated LSPs for an active PCEP session. Sending a PCRpt 530 message with the delegation bit set to 0 to the PCE that initiated 531 the LSP results in a PCErr message of type 19 (Invalid Operation) and 532 error-value value to be assigned by IANA, suggested value 7, 533 (Delegation for PCE-initiated LSP cannot be revoked). The PCE MAY 534 further react by closing the session. 536 A PCE MAY return a delegation to the PCC, to allow for LSP transfer 537 between PCEs. Doing so MUST trigger the State Timeout Interval timer 538 ([I-D.ietf-pce-stateful-pce]) for that particular LSP. 540 In case of PCEP session failure, control over PCE-initiated LSPs 541 reverts to the PCC at the expiration of the redelegation timeout. At 542 this point, the LSP is an "orphan" until the expiration of the State 543 Timeout timer. To obtain control of a PCE-initiated LSP, a PCE 544 (either the original or one of its backups) sends a PCInitiate 545 message, including just the SRP and LSP objects, and carrying the 546 PLSP-ID of the LSP it wants to take control of. On receipt of a 547 PCInitiate message with a PLSP-ID pointing to an orphan LSP, the PCC 548 MUST redelegate that LSP to the PCE. Any other non-zero PLSP-ID MUST 549 result in the generation of a PCErr. The State Timeout timer for the 550 LSP is stopped upon the redelegation. After obtaining control of the 551 LSP, the PCE may remove it using the procedures described in this 552 document. 554 The State Timeout timer ensures that a PCE crash does not result in 555 automatic and immediate disruption for the services using PCE- 556 initiated LSPs. PCE-initiated LSPs are not be removed immediately 557 upon PCE failure. Instead, they are cleaned up on the expiration of 558 this timer. This allows for network cleanup without manual 559 intervention. The PCC SHOULD support removal of PCE-initiated LSPs 560 as one of the behaviors applied on expiration of the State Timeout 561 Interval [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be picked 562 based on local policy, and can result either in LSP removal, or into 563 reverting to operator-defined default parameters. 565 7. Implementation Status 567 This section to be removed by the RFC editor. 569 This section records the status of known implementations of the 570 protocol defined by this specification at the time of posting of this 571 Internet-Draft, and is based on a proposal described in [RFC7942]. 572 The description of implementations in this section is intended to 573 assist the IETF in its decision processes in progressing drafts to 574 RFCs. Please note that the listing of any individual implementation 575 here does not imply endorsement by the IETF. Furthermore, no effort 576 has been spent to verify the information presented here that was 577 supplied by IETF contributors. This is not intended as, and must not 578 be construed to be, a catalog of available implementations or their 579 features. Readers are advised to note that other implementations may 580 exist. 582 According to RFC 7942, "this will allow reviewers and working groups 583 to assign due consideration to documents that have the benefit of 584 running code, which may serve as evidence of valuable experimentation 585 and feedback that have made the implemented protocols more mature. 586 It is up to the individual working groups to use this information as 587 they see fit". 589 Two vendors are implementing the extensions described in this draft 590 and have included the functionality in releases that will be shipping 591 in the near future. An additional entity is working on implementing 592 these extensions in the scope of research projects. 594 8. IANA Considerations 596 8.1. PCEP Messages 598 IANA is requested to allocate a new message type within the "PCEP 599 Messages" sub-registry of the PCEP Numbers registry, as follows: 601 Value Meaning Reference 602 12 Initiate This document 604 8.2. LSP Object 606 [I-D.ietf-pce-stateful-pce] defines the LSP Object and requests that 607 IANA creates a registry to manage the value of the LSP Object's Flag 608 field. IANA is requested to allocate a new bit in the LSP Object 609 Flag Field registry, as follows: 611 Bit Description Reference 613 4 Create This document 615 8.3. SRP object 617 This document requests that a new sub-registry, named "SRP Object 618 Flag Field", is created within the "Path Computation Element Protocol 619 (PCEP) Numbers" registry to manage the Flag field of the SRP object. 620 New values are to be assigned by Standards Action [RFC5226]. Each 621 bit should be tracked with the following qualities: bit number 622 (counting from bit 0 as the most significant bit), description and 623 defining RFC. 625 The following values are defined in this document: 627 Bit Description Reference 629 31 LSP-Remove This document 631 8.4. STATEFUL-PCE-CAPABILITY TLV 633 [I-D.ietf-pce-stateful-pce] defines the STATEFUL-PCE-CAPABILITY TLV 634 and requests that IANA creates a registry to manage the value of the 635 STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA is requested to 636 allocate a new bit in the STATEFUL-PCE-CAPABILITY TLV Flag Field 637 registry, as follows: 639 Bit Description Reference 641 29 I (LSP-INSTANTIATION- This document 642 CAPABILITY) 644 8.5. PCEP-Error Object 646 IANA is requested to allocate new error types and error values within 647 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 648 PCEP Numbers registry, as follows: 650 Error-Type Meaning 651 10 Invalid Object 653 Error-value=8: SYMBOLIC-PATH-NAME TLV missing 654 19 Invalid operation 656 Error-value=6: PCE-initiated LSP limit reached 657 Error-value=7: Delegation for PCE-initiated LSP cannot 658 be revoked 659 Error-value=8: Non-zero PLSP-ID in LSP initiation 660 request 661 Error-value=9: LSP is not PCE-initiated 662 Error-value=10: PCE-initiated operation-frequency limit 663 reached 664 23 Bad parameter value 666 Error-value=1: SYMBOLIC-PATH-NAME in use 667 Error-value=2: Speaker identity included for an LSP 668 that is not PCE-initiated 669 24 LSP instantiation error 671 Error-value=1: Unacceptable instantiation parameters 672 Error-value=2: Internal error 673 Error-value=3: Signaling error 675 9. Security Considerations 677 The security considerations described in [I-D.ietf-pce-stateful-pce] 678 apply to the extensions described in this document. Additional 679 considerations related to a malicious PCE are introduced. 681 9.1. Malicious PCE 683 The LSP instantiation mechanism described in this document allows a 684 PCE to generate state on the PCC and throughout the network. As a 685 result, it introduces a new attack vector: an attacker may flood the 686 PCC with LSP instantiation requests and consume network and LSR 687 resources, either by spoofing messages or by compromising the PCE 688 itself. 690 A PCC can protect itself from such an attack by imposing a limit on 691 either the number of LSPs or the percentage of resources that are 692 allocated to honor PCE-initiated LSP requests. As soon as that limit 693 is reached, the PCC MUST send a PCErr message of type 19 (Invalid 694 Operation) and value to be assigned by IANA, suggested value 6 (PCE- 695 initiated LSP limit reached) and is free to drop any incoming 696 PCInitiate messages for LSP instantiation without additional 697 processing. 699 Rapid flaps triggered by the PCE can also be an attack vector. A PCC 700 can protect itself from such an attack by imposing a limit on the 701 number of flaps per unit of time that it allows a PCE to generate. 702 As soon as that limit is reached, a PCC MUST send a PCErr message of 703 type 19 (Invalid Operation) and value to be assigned by IANA, 704 suggested value 10 (PCE-initiated operation frequency reached) and is 705 free to treat the session as having reached the limit in terms of 706 resources allocated to honor PCE-initiated LSP requests, either 707 permanently or for a locally-defined cool-off period. 709 9.2. Malicious PCC 711 The LSP instantiation mechanism described in this document requires 712 the PCE to keep state for LSPs that it instantiates and relies on the 713 PCC responding (with either a state report or an error message) to 714 requests for LSP instantiation. A malicious PCC or one that reached 715 the limit of the number of PCE-initiated LSPs, can ignore PCE 716 requests and consume PCE resources. A PCE can protect itself by 717 imposing a limit on the number of requests pending, or by setting a 718 timeout and it MAY take further action such as closing the session or 719 removing all the LSPs it initiated. 721 10. Acknowledgements 723 We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas, 724 Cyril Margaria, Dhruv Dhody, and Raveendra Trovi for their 725 contributions to this document. 727 11. References 729 11.1. Normative References 731 [I-D.ietf-pce-stateful-pce] 732 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 733 Extensions for Stateful PCE", draft-ietf-pce-stateful- 734 pce-18 (work in progress), December 2016. 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, 738 DOI 10.17487/RFC2119, March 1997, 739 . 741 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 742 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 743 DOI 10.17487/RFC5440, March 2009, 744 . 746 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 747 Used to Form Encoding Rules in Various Routing Protocol 748 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 749 2009, . 751 11.2. Informative References 753 [I-D.ietf-pce-stateful-sync-optimizations] 754 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 755 and D. Dhody, "Optimizations of Label Switched Path State 756 Synchronization Procedures for a Stateful PCE", draft- 757 ietf-pce-stateful-sync-optimizations-09 (work in 758 progress), February 2017. 760 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 761 Element (PCE) Communication Protocol Generic 762 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 763 2006, . 765 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 766 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 767 DOI 10.17487/RFC5226, May 2008, 768 . 770 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 771 Code: The Implementation Status Section", BCP 205, 772 RFC 7942, DOI 10.17487/RFC7942, July 2016, 773 . 775 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 776 Stateful Path Computation Element (PCE)", RFC 8051, 777 DOI 10.17487/RFC8051, January 2017, 778 . 780 Authors' Addresses 782 Edward Crabbe 783 Individual Contributor 785 Email: edward.crabbe@gmail.com 787 Ina Minei 788 Google, Inc. 789 1600 Amphitheatre Parkway 790 Mountain View, CA 94043 791 US 793 Email: inaminei@google.com 795 Siva Sivabalan 796 Cisco Systems, Inc. 797 170 West Tasman Dr. 798 San Jose, CA 95134 799 US 801 Email: msiva@cisco.com 803 Robert Varga 804 Pantheon Technologies SRO 805 Mlynske Nivy 56 806 Bratislava 821 05 807 Slovakia 809 Email: robert.varga@pantheon.tech