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