idnits 2.17.1 draft-ietf-pce-pce-initiated-lsp-08.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 4, 2017) is 2608 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 ** Downref: Normative reference to an Informational RFC: RFC 8051 == 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) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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 5, 2017 Google, Inc. 6 S. Sivabalan 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 March 4, 2017 12 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 13 draft-ietf-pce-pce-initiated-lsp-08 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 5, 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 310 by 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 (e.g., Segment 396 Routing), the END-POINTS object SHOULD be omitted. 398 The ERO Object is mandatory for an instantiation request. It 399 contains the ERO for the LSP. If the ERO Object is missing, the PCC 400 MUST send a PCErr message with Error-type=6 (Mandatory Object 401 missing) and Error-value=9 (ERO Object missing). 403 The LSP Object MUST include the SYMBOLIC-PATH-NAME TLV, which will be 404 used to correlate between the PCC-assigned PLSP-ID and the LSP. If 405 the TLV is missing, the PCC MUST send a PCErr message with Error- 406 type=10 (Invalid object) and Error-value to be assigned by IANA, 407 suggested value 8, (SYMBOLIC-PATH-NAME TLV missing). The symbolic 408 name used for provisioning PCE-initiated LSPs must not have conflict 409 with the LSP name of any existing LSP in the PCC. (Existing LSPs may 410 be either statically configured, or initiated by another PCE). If 411 there is conflict with the LSP name, the PCC MUST send a PCErr 412 message with Error-type to be assigned by IANA, suggested value 23 413 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). 414 The only exception to this rule is for LSPs for which the State 415 timeout timer is running (see Section 6). 417 The PCE MAY include various attributes as per [RFC5440]. The PCC 418 MUST use these values in the LSP instantiation, and local values for 419 unspecified parameters. After the LSP setup, the PCC MUST send a 420 PCRpt to the PCE, reflecting these values. The SRP object in the 421 PCRpt message MUST echo the value of the PCInitiate message that 422 triggered the setup. LSPs that were instantiated as a result of a 423 PCInitiate message MUST have the Create flag (Section 5.3.1) set in 424 the LSP object. 426 If the PCC determines that the LSP parameters proposed in the 427 PCInitiate message are unacceptable, it MUST trigger a PCErr with 428 error-type to be assigned by IANA, suggested value 24 (PCE 429 instantiation error) and error-value=1 (Unacceptable instantiation 430 parameters). If the PCC encounters an internal error during the 431 processing of the PCInitiate message, it MUST trigger a PCErr with 432 error-type to be assigned by IANA, suggested vlaue 24 (PCE 433 instantiation error) and error-value=2 (Internal error). 435 A PCC MUST relay to the PCE errors it encounters in the setup of PCE- 436 initiated LSP by sending a PCErr with error-type to be assigned by 437 IANA, suggeseted value 24 (PCE instantiation error) and error-value=3 438 (Signaling error). The PCErr MUST echo the SRP-ID-number of the 439 PCInitiate message. The PCEP-ERROR object SHOULD include the RSVP 440 Error Spec TLV (if an ERROR SPEC was returned to the PCC by a 441 downstream node). After the LSP is set up, errors in RSVP signaling 442 are reported in PCRpt messages, as described in 443 [I-D.ietf-pce-stateful-pce]. 445 A PCC SHOULD be able to place a limit on either the number of LSPs or 446 the percentage of resources that are allocated to honor PCE-initiated 447 LSP requests. As soon as that limit is reached, the PCC MUST send a 448 PCErr message of type 19 (Invalid Operation) and value to be assigned 449 by IANA (PCE-initiated limit reached) and is free to drop any 450 incoming PCInitiate messages without additional processing. 452 Similarly, the PCE SHOULD be able to place a limit on either the 453 number of LSP initiation requests pending for a particular PCC, or on 454 the time it waits for a response (positive or negative) to a 455 PCInitiate request from a PCC and MAY take further action (such as 456 closing the session or removing all its LSPs) if this limit is 457 reached. 459 On successful completion of the LSP instantiation, the PCC assigns a 460 PLSP-ID, and immediately delegates the LSP to the PCE by sending a 461 PCRpt with the Delegate flag set. 463 5.3.1. The Create Flag 465 The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included 466 here for easy reference. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | PLSP-ID |Flags |C| O |A|R|S|D| 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 // TLVs // 474 | | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Figure 3: The LSP Object format 479 A new flag, the Create (C) flag is introduced. On a PCRpt message, 480 the C Flag set to 1 indicates that this LSP was created via a 481 PCInitiate message. The C Flag MUST be set to 1 on each PCRpt 482 message for the duration of existence of the LSP. The Create flag 483 allows PCEs to be aware of which LSPs were PCE-initiated (a state 484 that would otherwise only be known by the PCC and the PCE that 485 initiated them). 487 5.3.2. The SPEAKER-IDENTITY-ID TLV 489 The optional SPEAKER-IDENTITY-ID TLV defined in 490 [I-D.ietf-pce-stateful-sync-optimizations] MAY be included in the LSP 491 object in a PCRpt message, as an optional TLV for LSPs for which the 492 C flag is 1. The SPEAKER-IDENTITY-ID TLV identifies the PCE which 493 initiated the creation of the LSP on all PCEP sessions, a state that 494 would otherwise only be known by the PCC and the PCE that initiated 495 the LSP. If the TLV appears in a PCRpt for an LSP for which the C 496 flag is 0, the TLV MUST be ignored the and the PCE MUST send a PCErr 497 message with Error-type 23 ("Bad parameter value") and error value 2 498 ("Speaker identity included for an LSP that is not PCE-initiated"). 500 5.4. LSP Deletion 502 PCE-initiated removal of a PCE-initiated LSP is done by setting the R 503 (remove) flag in the SRP Object in the PCInitiate message from the 504 PCE. The LSP is identified by the PLSP-ID in the LSP object. If the 505 PLSP-ID is unknown, the PCC MUST generate a PCErr with error type 19, 506 error value 3, "Unknown PLSP-ID" ([I-D.ietf-pce-stateful-pce]). A 507 PLSP-ID of zero removes all LSPs that were initiated by the PCE. If 508 the PLSP-ID specified in the PCInitiate message is not delegated to 509 the PCE, the PCC MUST send a PCErr message indicating "LSP is not 510 delegated" (Error code 19, error value 1 as per 511 [I-D.ietf-pce-stateful-pce]. If the PLSP-ID specified in the 512 PCInitiate message was not created by a PCE, the PCC MUST send a 513 PCErr message indicating that the LSP is not PCE-initiated, Error 514 code 19, error value to be assigned by IANA, suggested value 9 (LSP 515 is not PCE-initiated). Following the removal of the LSP, the PCC 516 MUST send a PCRpt as described in [I-D.ietf-pce-stateful-pce]. The 517 SRP object in the PCRpt MUST include the SRP-ID-number from the 518 PCInitiate message that triggered the removal. The R flag in the SRP 519 object MUST be set. 521 6. LSP delegation and Cleanup 523 PCE-initiated LSPs are automatically delegated by the PCC to the PCE 524 upon instantiation. The PCC MUST set the delegation bit to 1 in the 525 PCRpt that includes the assigned PLSP-ID. All subsequent messages 526 from the PCC to the PCE that initiated the LSP MUST have the 527 delegation bit set to 1. The PCC cannot revoke the delegation for 528 PCE-initiated LSPs for an active PCEP session. Sending a PCRpt 529 message with the delegation bit set to 0 to the PCE that initiated 530 the LSP results in a PCErr message of type 19 (Invalid Operation) and 531 error-value value to be assigned by IANA, suggested value 7, 532 (Delegation for PCE-initiated LSP cannot be revoked). The PCE MAY 533 further react by closing the session. 535 A PCE MAY return a delegation to the PCC, to allow for LSP transfer 536 between PCEs. Doing so MUST trigger the State Timeout Interval timer 537 ([I-D.ietf-pce-stateful-pce]) for that particular LSP. 539 In case of PCEP session failure, control over PCE-initiated LSPs 540 reverts to the PCC at the expiration of the redelegation timeout. At 541 this point, the LSP is an "orphan" until the expiration of the State 542 Timeout timer. To obtain control of a PCE-initiated LSP, a PCE 543 (either the original or one of its backups) sends a PCInitiate 544 message, including just the SRP and LSP objects, and carrying the 545 PLSP-ID of the LSP it wants to take control of. On receipt of a 546 PCInitiate message with a PLSP-ID pointing to an orphan LSP, the PCC 547 MUST redelegate that LSP to the PCE. Any other non-zero PLSP-ID MUST 548 result in the generation of a PCErr. The State Timeout timer for the 549 LSP is stopped upon the redelegation. After obtaining control of the 550 LSP, the PCE may remove it using the procedures described in this 551 document. 553 The State Timeout timer ensures that a PCE crash does not result in 554 automatic and immediate disruption for the services using PCE- 555 initiated LSPs. PCE-initiated LSPs are not be removed immediately 556 upon PCE failure. Instead, they are cleaned up on the expiration of 557 this timer. This allows for network cleanup without manual 558 intervention. The PCC SHOULD support removal of PCE-initiated LSPs 559 as one of the behaviors applied on expiration of the State Timeout 560 Interval [I-D.ietf-pce-stateful-pce]. The behavior SHOULD be picked 561 based on local policy, and can result either in LSP removal, or into 562 reverting to operator-defined default parameters. 564 7. Implementation Status 566 This section to be removed by the RFC editor. 568 This section records the status of known implementations of the 569 protocol defined by this specification at the time of posting of this 570 Internet-Draft, and is based on a proposal described in [RFC6982]. 571 The description of implementations in this section is intended to 572 assist the IETF in its decision processes in progressing drafts to 573 RFCs. Please note that the listing of any individual implementation 574 here does not imply endorsement by the IETF. Furthermore, no effort 575 has been spent to verify the information presented here that was 576 supplied by IETF contributors. This is not intended as, and must not 577 be construed to be, a catalog of available implementations or their 578 features. Readers are advised to note that other implementations may 579 exist. 581 According to RFC 6982, "this will allow reviewers and working groups 582 to assign due consideration to documents that have the benefit of 583 running code, which may serve as evidence of valuable experimentation 584 and feedback that have made the implemented protocols more mature. 585 It is up to the individual working groups to use this information as 586 they see fit". 588 Two vendors are implementing the extensions described in this draft 589 and have included the functionality in releases that will be shipping 590 in the near future. An additional entity is working on implementing 591 these extensions in the scope of research projects. 593 8. IANA Considerations 595 8.1. PCEP Messages 597 IANA is requested to allocate a new message type within the "PCEP 598 Messages" sub-registry of the PCEP Numbers registry, as follows: 600 Value Meaning Reference 601 12 Initiate This document 603 8.2. LSP Object 605 [I-D.ietf-pce-stateful-pce] defines the LSP Object and requests that 606 IANA creates a registry to manage the value of the LSP Object's Flag 607 field. IANA is requested to allocate a new bit in the LSP Object 608 Flag Field registry, as follows: 610 Bit Description Reference 612 4 Create This document 614 8.3. SRP object 616 This document requests that a new sub-registry, named "SRP Object 617 Flag Field", is created within the "Path Computation Element Protocol 618 (PCEP) Numbers" registry to manage the Flag field of the SRP object. 619 New values are to be assigned by Standards Action [RFC5226]. Each 620 bit should be tracked with the following qualities: bit number 621 (counting from bit 0 as the most significant bit), description and 622 defining RFC. 624 The following values are defined in this document: 626 Bit Description Reference 628 31 LSP-Remove This document 630 8.4. STATEFUL-PCE-CAPABILITY TLV 632 [I-D.ietf-pce-stateful-pce] defines the STATEFUL-PCE-CAPABILITY TLV 633 and requests that IANA creates a registry to manage the value of the 634 STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA is requested to 635 allocate a new bit in the STATEFUL-PCE-CAPABILITY TLV Flag Field 636 registry, as follows: 638 Bit Description Reference 640 29 I (LSP-INSTANTIATION- This document 641 CAPABILITY) 643 8.5. PCEP-Error Object 645 IANA is requested to allocate new error types and error values within 646 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 647 PCEP Numbers registry, as follows: 649 Error-Type Meaning 650 10 Invalid Object 652 Error-value=8: SYMBOLIC-PATH-NAME TLV missing 653 19 Invalid operation 655 Error-value=6: PCE-initiated LSP limit reached 656 Error-value=7: Delegation for PCE-initiated LSP cannot 657 be revoked 658 Error-value=8: Non-zero PLSP-ID in LSP initiation 659 request 660 Error-value=9: LSP is not PCE-initiated 661 Error-value=10: PCE-initiated operation-frequency limit 662 reached 663 23 Bad parameter value 665 Error-value=1: SYMBOLIC-PATH-NAME in use 666 Error-value=2: Speaker identity included for an LSP 667 that is not PCE-initiated 668 24 LSP instantiation error 670 Error-value=1: Unacceptable instantiation parameters 671 Error-value=2: Internal error 672 Error-value=3: Signaling error 674 9. Security Considerations 676 The security considerations described in [I-D.ietf-pce-stateful-pce] 677 apply to the extensions described in this document. Additional 678 considerations related to a malicious PCE are introduced. 680 9.1. Malicious PCE 682 The LSP instantiation mechanism described in this document allows a 683 PCE to generate state on the PCC and throughout the network. As a 684 result, it introduces a new attack vector: an attacker may flood the 685 PCC with LSP instantiation requests and consume network and LSR 686 resources, either by spoofing messages or by compromising the PCE 687 itself. 689 A PCC can protect itself from such an attack by imposing a limit on 690 either the number of LSPs or the percentage of resources that are 691 allocated to honor PCE-initiated LSP requests. As soon as that limit 692 is reached, the PCC MUST send a PCErr message of type 19 (Invalid 693 Operation) and value to be assigned by IANA, suggested value 6 (PCE- 694 initiated LSP limit reached) and is free to drop any incoming 695 PCInitiate messages for LSP instantiation without additional 696 processing. 698 Rapid flaps triggered by the PCE can also be an attack vector. A PCC 699 can protect itself from such an attack by imposing a limit on the 700 number of flaps per unit of time that it allows a PCE to generate. 701 As soon as that limit is reached, a PCC MUST send a PCErr message of 702 type 19 (Invalid Operation) and value to be assigned by IANA, 703 suggested value 10 (PCE-initiated operation frequency reached) and is 704 free to treat the session as having reached the limit in terms of 705 resources allocated to honor PCE-initiated LSP requests, either 706 permanently or for a locally-defined cool-off period. 708 9.2. Malicious PCC 710 The LSP instantiation mechanism described in this document requires 711 the PCE to keep state for LSPs that it instantiates and relies on the 712 PCC responding (with either a state report or an error message) to 713 requests for LSP instantiation. A malicious PCC or one that reached 714 the limit of the number of PCE-initiated LSPs, can ignore PCE 715 requests and consume PCE resources. A PCE can protect itself by 716 imposing a limit on the number of requests pending, or by setting a 717 timeout and it MAY take further action such as closing the session or 718 removing all the LSPs it initiated. 720 10. Acknowledgements 722 We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas, 723 Cyril Margaria, Dhruv Dhody, and Raveendra Trovi for their 724 contributions to this document. 726 11. References 728 11.1. Normative References 730 [I-D.ietf-pce-stateful-pce] 731 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 732 Extensions for Stateful PCE", draft-ietf-pce-stateful- 733 pce-18 (work in progress), December 2016. 735 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 736 Requirement Levels", BCP 14, RFC 2119, 737 DOI 10.17487/RFC2119, March 1997, 738 . 740 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 741 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 742 DOI 10.17487/RFC5440, March 2009, 743 . 745 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 746 Used to Form Encoding Rules in Various Routing Protocol 747 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 748 2009, . 750 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 751 Stateful Path Computation Element (PCE)", RFC 8051, 752 DOI 10.17487/RFC8051, January 2017, 753 . 755 11.2. Informative References 757 [I-D.ietf-pce-stateful-sync-optimizations] 758 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 759 and D. Dhody, "Optimizations of Label Switched Path State 760 Synchronization Procedures for a Stateful PCE", draft- 761 ietf-pce-stateful-sync-optimizations-09 (work in 762 progress), February 2017. 764 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 765 Element (PCE) Communication Protocol Generic 766 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 767 2006, . 769 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 770 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 771 DOI 10.17487/RFC5226, May 2008, 772 . 774 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 775 Code: The Implementation Status Section", RFC 6982, 776 DOI 10.17487/RFC6982, July 2013, 777 . 779 Authors' Addresses 781 Edward Crabbe 782 Individual Contributor 784 Email: edward.crabbe@gmail.com 786 Ina Minei 787 Google, Inc. 788 1600 Amphitheatre Parkway 789 Mountain View, CA 94043 790 US 792 Email: inaminei@google.com 794 Siva Sivabalan 795 Cisco Systems, Inc. 796 170 West Tasman Dr. 797 San Jose, CA 95134 798 US 800 Email: msiva@cisco.com 802 Robert Varga 803 Pantheon Technologies SRO 804 Mlynske Nivy 56 805 Bratislava 821 05 806 Slovakia 808 Email: robert.varga@pantheon.tech