idnits 2.17.1 draft-ietf-pce-stateful-pce-18.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 (December 2, 2016) is 2701 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 (-16) exists of draft-ietf-pce-gmpls-pcep-extensions-11 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-06 -- 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 Oracle 4 Intended status: Standards Track I. Minei 5 Expires: June 5, 2017 Google, Inc. 6 J. Medved 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 December 2, 2016 12 PCEP Extensions for Stateful PCE 13 draft-ietf-pce-stateful-pce-18 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 Although PCEP explicitly makes no assumptions regarding the 22 information available to the PCE, it also makes no provisions for PCE 23 control of timing and sequence of path computations within and across 24 PCEP sessions. This document describes a set of extensions to PCEP 25 to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 5, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Motivation and Objectives for Stateful PCE . . . . . . . . . 5 65 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 5 67 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6 68 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7 69 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8 71 5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 8 72 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 73 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 9 74 5.3. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10 75 5.4. Capability Advertisement . . . . . . . . . . . . . . . . 10 76 5.5. IGP Extensions for Stateful PCE Capabilities 77 Advertisement . . . . . . . . . . . . . . . . . . . . . . 11 78 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12 79 5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15 80 5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 81 5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16 82 5.7.3. Returning a Delegation . . . . . . . . . . . . . . . 18 83 5.7.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18 84 5.7.5. Redelegation on PCE Failure . . . . . . . . . . . . . 19 85 5.8. LSP Operations . . . . . . . . . . . . . . . . . . . . . 19 86 5.8.1. Passive Stateful PCE Path Computation 87 Request/Response . . . . . . . . . . . . . . . . . . 19 88 5.8.2. Switching from Passive Stateful to Active Stateful . 21 89 5.8.3. Active Stateful PCE LSP Update . . . . . . . . . . . 22 90 5.9. LSP Protection . . . . . . . . . . . . . . . . . . . . . 23 91 5.10. PCEP Sessions . . . . . . . . . . . . . . . . . . . . . . 23 92 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 23 93 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 24 94 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 26 95 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 28 96 6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 29 97 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 30 98 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 30 99 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 30 100 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 30 101 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 31 102 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 33 103 7.3.1. LSP-IDENTIFIERS TLVs . . . . . . . . . . . . . . . . 35 104 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 38 105 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 39 106 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 39 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 108 8.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 40 109 8.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 41 110 8.3. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 41 111 8.4. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 41 112 8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 42 113 8.6. Notification Object . . . . . . . . . . . . . . . . . . . 42 114 8.7. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 43 115 8.8. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 43 116 8.9. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 43 117 9. Manageability Considerations . . . . . . . . . . . . . . . . 44 118 9.1. Control Function and Policy . . . . . . . . . . . . . . . 44 119 9.2. Information and Data Models . . . . . . . . . . . . . . . 45 120 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 45 121 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 45 122 9.5. Requirements on Other Protocols and Functional Components 46 123 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 46 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 125 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 46 126 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 47 127 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 47 128 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 48 129 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 48 130 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 131 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 132 13.1. Normative References . . . . . . . . . . . . . . . . . . 49 133 13.2. Informative References . . . . . . . . . . . . . . . . . 50 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 136 1. Introduction 138 [RFC5440] describes the Path Computation Element Communication 139 Protocol (PCEP). PCEP defines the communication between a Path 140 Computation Client (PCC) and a Path Computation Element (PCE), or 141 between PCEs, enabling computation of Multiprotocol Label Switching 142 (MPLS) for Traffic Engineering Label Switched Path (TE LSP) 143 characteristics. Extensions for support of Generalized MPLS (GMPLS) 144 in PCEP are defined in [I-D.ietf-pce-gmpls-pcep-extensions] 145 This document specifies a set of extensions to PCEP to enable 146 stateful control of LSPs within and across PCEP sessions in 147 compliance with [RFC4657]. It includes mechanisms to effect Label 148 Switched Path (LSP) state synchronization between PCCs and PCEs, 149 delegation of control over LSPs to PCEs, and PCE control of timing 150 and sequence of path computations within and across PCEP sessions. 152 1.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 2. Terminology 160 This document uses the following terms defined in [RFC5440]: PCC, 161 PCE, PCEP Peer, PCEP Speaker. 163 This document uses the following terms defined in [RFC4655]: TED. 165 This document uses the following terms defined in [RFC3031]: LSP. 167 This document uses the following terms defined in 168 [I-D.ietf-pce-stateful-pce-app]: Stateful PCE, Passive Stateful PCE, 169 Active Stateful PCE, Delegation, LSP State Database. 171 The following terms are defined in this document: 173 Revocation: an operation performed by a PCC on a previously 174 delegated LSP. Revocation revokes the rights granted to the PCE 175 in the delegation operation. 177 Redelegation Timeout Interval: the period of time a PCC waits for, 178 when a PCEP session is terminated, before revoking LSP delegation 179 to a PCE and attempting to redelegate LSPs associated with the 180 terminated PCEP session to an alternate PCE. The Redelegation 181 Timeout Interval is a PCC-local value that can be either operator- 182 configured or dynamically computed by the PCC based on local 183 policy. 185 State Timeout Interval: the period of time a PCE waits for, when a 186 PCEP session is terminated, before flushing LSP state associated 187 with that PCEP session and reverting to operator-defined default 188 parameters or behaviors. The State Timeout Interval is a PCC- 189 local value that can be either operator-configured or dynamically 190 computed by the PCC based on local policy. 192 LSP State Report: an operation to send LSP state (Operational / 193 Admin Status, LSP attributes configured at the PCC and set by a 194 PCE, etc.) from a PCC to a PCE. 196 LSP Update Request: an operation where an Active Stateful PCE 197 requests a PCC to update one or more attributes of an LSP and to 198 re-signal the LSP with updated attributes. 200 SRP-ID-number: a number used to correlate errors and LSP State 201 Reports to LSP Update Requests. It is carried in the SRP 202 (Stateful PCE Request Parameters) Object described in Section 7.2. 204 Within this document, PCEP communications are described through PCC- 205 PCE relationship. The PCE architecture also supports the PCE-PCE 206 communication, by having the requesting PCE fill the role of a PCC, 207 as usual. 209 The message formats in this document are specified using Routing 210 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 212 3. Motivation and Objectives for Stateful PCE 214 3.1. Motivation 216 [I-D.ietf-pce-stateful-pce-app] presents several use cases, 217 demonstrating scenarios that benefit from the deployment of a 218 stateful PCE. The scenarios apply equally to MPLS-TE and GMPLS 219 deployments. 221 3.1.1. Background 223 Traffic engineering has been a goal of the MPLS architecture since 224 its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic 225 engineering system provided by [RFC3630], [RFC5305], and [RFC3209] 226 information about network resources utilization is only available as 227 total reserved capacity by traffic class on a per interface basis; 228 individual LSP state is available only locally on each LER for its 229 own LSPs. In most cases, this makes good sense, as distribution and 230 retention of total LSP state for all LERs within in the network would 231 be prohibitively costly. 233 Unfortunately, this visibility in terms of global LSP state may 234 result in a number of issues for some demand patterns, particularly 235 within a common setup and hold priority. This issue affects online 236 traffic engineering systems. 238 A sufficiently over-provisioned system will by definition have no 239 issues routing its demand on the shortest path. However, lowering 240 the degree to which network over-provisioning is required in order to 241 run a healthy, functioning network is a clear and explicit promise of 242 MPLS architecture. In particular, it has been a goal of MPLS to 243 provide mechanisms to alleviate congestion scenarios in which 244 "traffic streams are inefficiently mapped onto available resources; 245 causing subsets of network resources to become over-utilized while 246 others remain underutilized" ([RFC2702]). 248 3.1.2. Why a Stateful PCE? 250 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 251 "strict synchronization between the PCE and not only the network 252 states (in term of topology and resource information), but also the 253 set of computed paths and reserved resources in use in the network." 254 [RFC4655] also expressed a number of concerns with regard to a 255 stateful PCE, specifically: 257 o Any reliable synchronization mechanism would result in significant 258 control plane overhead 260 o Out-of-band TED synchronization would be complex and prone to race 261 conditions 263 o Path calculations incorporating total network state would be 264 highly complex 266 In general, stress on the control plane will be directly proportional 267 to the size of the system being controlled and the tightness of the 268 control loop, and indirectly proportional to the amount of over- 269 provisioning in terms of both network capacity and reservation 270 overhead. 272 Despite these concerns in terms of implementation complexity and 273 scalability, several TE algorithms exist today that have been 274 demonstrated to be extremely effective in large TE systems, providing 275 both rapid convergence and significant benefits in terms of 276 optimality of resource usage [MXMN-TE]. All of these systems share 277 at least two common characteristics: the requirement for both global 278 visibility of a flow (or in this case, a TE LSP) state and for 279 ordered control of path reservations across devices within the system 280 being controlled. While some approaches have been suggested in order 281 to remove the requirements for ordered control (See [MPLS-PC]), these 282 approaches are highly dependent on traffic distribution, and do not 283 allow for multiple simultaneous LSP priorities representing diffserv 284 classes. 286 The use cases described in [I-D.ietf-pce-stateful-pce-app] 287 demonstrate a need for visibility into global inter-PCC LSP state in 288 PCE path computations, and for PCE control of sequence and timing in 289 altering LSP path characteristics within and across PCEP sessions. 291 3.1.3. Protocol vs. Configuration 293 Note that existing configuration tools and protocols can be used to 294 set LSP state. However, this solution has several shortcomings: 296 o Scale & Performance: configuration operations often have 297 transactional semantics which are typically heavyweight and often 298 require processing of additional configuration portions beyond the 299 state being directly acted upon, with corresponding cost in CPU 300 cycles, negatively impacting both PCC stability LSP update rate 301 capacity. 303 o Security: when a PCC opens a configuration channel allowing a PCE 304 to send configuration, a malicious PCE may take advantage of this 305 ability to take over the PCC. In contrast, the PCEP extensions 306 described in this document only allow a PCE control over a very 307 limited set of LSP attributes. 309 o Interoperability: each vendor has a proprietary information model 310 for configuring LSP state, which limits interoperability of a 311 stateful PCE with PCCs from different vendors. The PCEP 312 extensions described in this document allow for a common 313 information model for LSP state for all vendors. 315 o Efficient State Synchronization: configuration channels may be 316 heavyweight and unidirectional, therefore efficient state 317 synchronization between a PCC and a PCE may be a problem. 319 3.2. Objectives 321 The objectives for the protocol extensions to support stateful PCE 322 described in this document are as follows: 324 o Allow a single PCC to interact with a mix of stateless and 325 stateful PCEs simultaneously using the same protocol, i.e. PCEP. 327 o Support efficient LSP state synchronization between the PCC and 328 one or more active or passive stateful PCEs. 330 o Allow a PCC to delegate control of its LSPs to an active stateful 331 PCE such that a given LSP is under the control of a single PCE at 332 any given time. A PCC may revoke this delegation at any time 333 during the lifetime of the LSP. If LSP delegation is revoked 334 while the PCEP session is up, the PCC MUST notify the PCE about 335 the revocation. A PCE may return an LSP delegation at any point 336 during the lifetime of the PCEP session. 338 o Allow a PCE to control computation timing and update timing across 339 all LSPs that have been delegated to it. 341 o Enable uninterrupted operation of PCC's LSPs in the event of a PCE 342 failure or while control of LSPs is being transferred between 343 PCEs. 345 4. New Functions to Support Stateful PCEs 347 Several new functions are required in PCEP to support stateful PCEs. 348 A function can be initiated either from a PCC towards a PCE (C-E) or 349 from a PCE towards a PCC (E-C). The new functions are: 351 Capability advertisement (E-C,C-E): both the PCC and the PCE must 352 announce during PCEP session establishment that they support PCEP 353 Stateful PCE extensions defined in this document. 355 LSP state synchronization (C-E): after the session between the PCC 356 and a stateful PCE is initialized, the PCE must learn the state of 357 a PCC's LSPs before it can perform path computations or update LSP 358 attributes in a PCC. 360 LSP Update Request (E-C): a PCE requests modification of attributes 361 on a PCC's LSP. 363 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 364 whenever the state of an LSP changes. 366 LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 367 update LSP attributes on one or more LSPs; the PCE becomes the 368 authoritative source of the LSP's attributes as long as the 369 delegation is in effect (See Section 5.7); the PCC may withdraw 370 the delegation or the PCE may give up the delegation at any time. 372 Similarly to [RFC5440], no assumption is made about the discovery 373 method used by a PCC to discover a set of PCEs (e.g., via static 374 configuration or dynamic discovery) and on the algorithm used to 375 select a PCE. 377 5. Overview of Protocol Extensions 378 5.1. LSP State Ownership 380 In PCEP (defined in [RFC5440]), LSP state and operation are under the 381 control of a PCC (a PCC may be an LSR or a management station). 382 Attributes received from a PCE are subject to PCC's local policy. 383 The PCEP extensions described in this document do not change this 384 behavior. 386 An active stateful PCE may have control of a PCC's LSPs that were 387 delegated to it, but the LSP state ownership is retained by the PCC. 388 In particular, in addition to specifying values for LSP's attributes, 389 an active stateful PCE also decides when to make LSP modifications. 391 Retaining LSP state ownership on the PCC allows for: 393 o a PCC to interact with both stateless and stateful PCEs at the 394 same time 396 o a stateful PCE to only modify a small subset of LSP parameters, 397 i.e. to set only a small subset of the overall LSP state; other 398 parameters may be set by the operator, for example through command 399 line interface (CLI) commands 401 o a PCC to revert delegated LSP to an operator-defined default or to 402 delegate the LSPs to a different PCE, if the PCC get disconnected 403 from a PCE with currently delegated LSPs 405 5.2. New Messages 407 In this document, we define the following new PCEP messages: 409 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 410 to a PCE to report the status of one or more LSPs. Each LSP 411 Status Report in a PCRpt message MAY contain the actual LSP's 412 path, bandwidth, operational and administrative status, etc. An 413 LSP Status Report carried on a PCRpt message is also used in 414 delegation or revocation of control of an LSP to/from a PCE. The 415 PCRpt message is described in Section 6.1. 417 Path Computation Update Request (PCUpd): a PCEP message sent by a 418 PCE to a PCC to update LSP parameters, on one or more LSPs. Each 419 LSP Update Request on a PCUpd message MUST contain all LSP 420 parameters that a PCE wishes to be set for a given LSP. An LSP 421 Update Request carried on a PCUpd message is also used to return 422 LSP delegations if at any point PCE no longer desires control of 423 an LSP. The PCUpd message is described in Section 6.2. 425 The new functions defined in Section 4 are mapped onto the new 426 messages as shown in the following table. 428 +----------------------------------------+--------------+ 429 | Function | Message | 430 +----------------------------------------+--------------+ 431 | Capability Advertisement (E-C,C-E) | Open | 432 | State Synchronization (C-E) | PCRpt | 433 | LSP State Report (C-E) | PCRpt | 434 | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | 435 | LSP Update Request (E-C) | PCUpd | 436 +----------------------------------------+--------------+ 438 Table 1: New Function to Message Mapping 440 5.3. Error Reporting 442 Error reporting is done using the procedures defined in [RFC5440], 443 and reusing the applicable error types and error values of [RFC5440] 444 wherever appropriate. The current document defines new error values 445 for several error types to cover failures specific to stateful PCE. 447 5.4. Capability Advertisement 449 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 450 advertise their support of stateful PCEP extensions. A PCEP Speaker 451 includes the "Stateful PCE Capability" TLV, described in 452 Section 7.1.1, in the OPEN Object to advertise its support for PCEP 453 stateful extensions. The Stateful Capability TLV includes the 'LSP 454 Update' Flag that indicates whether the PCEP Speaker supports LSP 455 parameter updates. 457 The presence of the Stateful PCE Capability TLV in PCC's OPEN Object 458 indicates that the PCC is willing to send LSP State Reports whenever 459 LSP parameters or operational status changes. 461 The presence of the Stateful PCE Capability TLV in PCE's OPEN message 462 indicates that the PCE is interested in receiving LSP State Reports 463 whenever LSP parameters or operational status changes. 465 The PCEP extensions for stateful PCEs MUST NOT be used if one or both 466 PCEP Speakers have not included the Stateful PCE Capability TLV in 467 their respective OPEN message. If the PCEP Speaker on the PCC 468 supports the extensions of this draft but did not advertise this 469 capability, then upon receipt of PCUpd message from the PCE, it MUST 470 generate a PCErr with error-type 19 (Invalid Operation), error-value 471 2 (Attempted LSP Update Request if the stateful PCE capability was 472 not advertised)(see Section 8.5) and it SHOULD terminate the PCEP 473 session. If the PCEP Speaker on the PCE supports the extensions of 474 this draft but did not advertise this capability, then upon receipt 475 of a PCRpt message from the PCC, it MUST generate a PCErr with error- 476 type 19 (Invalid Operation), error-value 5 (Attempted LSP State 477 Report if active stateful PCE capability was not advertised) (see 478 Section 8.5) and it SHOULD terminate the PCEP session. 480 LSP delegation and LSP update operations defined in this document may 481 only be used if both PCEP Speakers set the LSP-UPDATE Flag in the 482 "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this 483 is not the case and LSP delegation or LSP update operations are 484 attempted, then a PCErr with error-type 19 (Invalid Operation) and 485 error-value 1 (Attempted LSP Update Request for a non-delegated LSP) 486 (see Section 8.5) MUST be generated. Note that even if the update 487 capability has not been advertised, a PCE can still accept LSP Status 488 Reports from a PCC and build and maintain an up to date view of the 489 state of the PCC's LSPs. 491 5.5. IGP Extensions for Stateful PCE Capabilities Advertisement 493 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 494 are either LSRs or servers also participating in the IGP, an 495 effective mechanism for PCE discovery within an IGP routing domain 496 consists of utilizing IGP advertisements. Extensions for the 497 advertisement of PCE Discovery Information are defined for OSPF and 498 for IS-IS in [RFC5088] and [RFC5089] respectively. 500 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 501 TLV used to advertise PCE capabilities. It MAY be present within the 502 PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] 503 provide the description and processing rules for this sub-TLV when 504 carried within OSPF and IS-IS, respectively. 506 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 507 reference: 509 Type: 5 511 Length: Multiple of 4. 513 Value: This contains an array of units of 32 bit flags with the most 514 significant bit as 0. Each bit represents one PCE capability. 516 PCE capability bits are defined in [RFC5088]. This document defines 517 new capability bits for the stateful PCE as follows: 519 Bit Capability 520 TBD Active Stateful PCE capability 521 TBD Passive Stateful PCE capability 523 Note that while active and passive stateful PCE capabilities may be 524 advertised during discovery, PCEP Speakers that wish to use stateful 525 PCEP MUST negotiate stateful PCEP capabilities during PCEP session 526 setup, as specified in the current document. A PCC MAY initiate 527 stateful PCEP capability negotiation at PCEP session setup even if it 528 did not receive any IGP PCE capability advertisements. 530 5.6. State Synchronization 532 The purpose of State Synchronization is to provide a checkpoint-in- 533 time state replica of a PCC's LSP state in a PCE. State 534 Synchronization is performed immediately after the Initialization 535 phase ([RFC5440]). 537 During State Synchronization, a PCC first takes a snapshot of the 538 state of its LSPs state, then sends the snapshot to a PCE in a 539 sequence of LSP State Reports. Each LSP State Report sent during 540 State Synchronization has the SYNC Flag in the LSP Object set to 1. 541 The set of LSPs for which state is synchronized with a PCE is 542 determined by advertised stateful PCEP capabilities and PCC's local 543 configuration (see more details in Section 9.1). 545 The end of synchronization marker is a PCRpt message with the SYNC 546 Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved 547 value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT 548 include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- 549 IDENTIFIERS TLV with the special value of all zeroes. The PCRpt 550 message MUST include an empty ERO as its intended path and SHOULD NOT 551 include the optional RRO object for its actual path. If the PCC has 552 no state to synchronize, it SHOULD only send the end of 553 synchronization marker. 555 A PCE SHOULD NOT send PCUpd messages to a PCC before State 556 Synchronization is complete. A PCC SHOULD NOT send PCReq messages to 557 a PCE before State Synchronization is complete. This is to allow the 558 PCE to get the best possible view of the network before it starts 559 computing new paths. 561 Either the PCE or the PCC MAY terminate the session using the PCEP 562 session termination procedures during the synchronization phase. If 563 the session is terminated, the PCE MUST clean up state it received 564 from this PCC. The session reestablishment MUST be re-attempted per 565 the procedures defined in [RFC5440], including use of a back-off 566 timer. 568 If the PCC encounters a problem which prevents it from completing the 569 state transfer, it MUST send a PCErr message with error-type 20 (LSP 570 State Synchronization Error) and error-value 5 (indicating an 571 internal PCC error) to the PCE and terminate the session. 573 The PCE does not send positive acknowledgements for properly received 574 synchronization messages. It MUST respond with a PCErr message with 575 error-type 20 (LSP State Synchronization Error) and error-value 1 576 (indicating an error in processing the PCRpt) (see Section 8.5) if it 577 encounters a problem with the LSP State Report it received from the 578 PCC and it MUST terminate the session. 580 A PCE implementing a limit on the resources a single PCC can occupy, 581 MUST send a PCNtf message with Notification Type to be allocated by 582 IANA (Stateful PCE resource limit exceeded) and Notification Value to 583 be allocated by IANA (Entering resource limit exceeded state) in 584 response to the PCRpt message triggering this condition in the 585 synchronization phase and MUST terminate the session. 587 The successful State Synchronization sequence is shown in Figure 1. 589 +-+-+ +-+-+ 590 |PCC| |PCE| 591 +-+-+ +-+-+ 592 | | 593 |-----PCRpt, SYNC=1----->| (Sync start) 594 | | 595 |-----PCRpt, SYNC=1----->| 596 | . | 597 | . | 598 | . | 599 |-----PCRpt, SYNC=1----->| 600 | . | 601 | . | 602 | . | 603 | | 604 |-----PCRpt, SYNC=0----->| (End of sync marker 605 | | LSP State Report 606 | | for PLSP-ID=0) 607 | | (Sync done) 609 Figure 1: Successful state synchronization 611 The sequence where the PCE fails during the State Synchronization 612 phase is shown in Figure 2. 614 +-+-+ +-+-+ 615 |PCC| |PCE| 616 +-+-+ +-+-+ 617 | | 618 |-----PCRpt, SYNC=1----->| 619 | | 620 |-----PCRpt, SYNC=1----->| 621 | . | 622 | . | 623 | . | 624 |-----PCRpt, SYNC=1----->| 625 | | 626 |-PCRpt, SYNC=1 | 627 | \ ,-PCErr | 628 | \ / | 629 | \/ | 630 | /\ | 631 | / `-------->| (Ignored) 632 |<--------` | 634 Figure 2: Failed state synchronization (PCE failure) 636 The sequence where the PCC fails during the State Synchronization 637 phase is shown in Figure 3. 639 +-+-+ +-+-+ 640 |PCC| |PCE| 641 +-+-+ +-+-+ 642 | | 643 |-----PCRpt, SYNC=1----->| 644 | | 645 |-----PCRpt, SYNC=1----->| 646 | . | 647 | . | 648 | . | 649 |-------- PCErr=? ------>| 650 | | 652 Figure 3: Failed state synchronization (PCC failure) 654 Optimizations to the synchronization procedures and alternate 655 mechanisms of providing the synchronization function are outside the 656 scope of this document and are discussed elsewhere (see 657 [I-D.ietf-pce-stateful-sync-optimizations]). 659 5.7. LSP Delegation 661 If during Capability advertisement both the PCE and the PCC have 662 indicated that they support LSP Update, then the PCC may choose to 663 grant the PCE a temporary right to update (a subset of) LSP 664 attributes on one or more LSPs. This is called "LSP Delegation", and 665 it MAY be performed at any time after the Initialization phase, 666 including during the State Synchronization phase. 668 A PCE MAY return an LSP delegation at any time if it no longer wishes 669 to update the LSP's state. A PCC MAY revoke an LSP delegation at any 670 time. Delegation, Revocation, and Return are done individually for 671 each LSP. 673 In the event of a delegation being rejected or returned by a PCE, the 674 PCC SHOULD react based on local policy. It can, for example, either 675 retry delegating to the same PCE using an exponentially increasing 676 timer or delegate to an alternate PCE. 678 5.7.1. Delegating an LSP 680 A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP 681 State Report to 1. If the PCE does not accept the LSP Delegation, it 682 MUST immediately respond with an empty LSP Update Request which has 683 the Delegate flag set to 0. If the PCE accepts the LSP Delegation, 684 it MUST set the Delegate flag to 1 when it sends an LSP Update 685 Request for the delegated LSP (note that this may occur at a later 686 time). The PCE MAY also immediately acknowledge a delegation by 687 sending an empty LSP Update Request which has the Delegate flag set 688 to 1. 690 The delegation sequence is shown in Figure 4. 692 +-+-+ +-+-+ 693 |PCC| |PCE| 694 +-+-+ +-+-+ 695 | | 696 |---PCRpt, Delegate=1--->| LSP Delegated 697 | | 698 |---PCRpt, Delegate=1--->| 699 | . | 700 | . | 701 | . | 702 |<--(PCUpd,Delegate=1)---| Delegation confirmed 703 | | 704 |---PCRpt, Delegate=1--->| 705 | | 707 Figure 4: Delegating an LSP 709 Note that for an LSP to remain delegated to a PCE, the PCC MUST set 710 the Delegate flag to 1 on each LSP Status Report sent to the PCE. 712 5.7.2. Revoking a Delegation 714 5.7.2.1. Explicit Revocation 716 When a PCC decides that a PCE is no longer permitted to modify an 717 LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke 718 an LSP delegation at any time during the LSP's life time. A PCC 719 revoking an LSP delegation MAY immediately clear the LSP state 720 provided by the PCE, but to avoid traffic loss, it SHOULD do so in a 721 make-before-break fashion. If the PCC has received but not yet acted 722 on PCUpd messages from the PCE for the LSP whose delegation is being 723 revoked, then it SHOULD ignore these PCUpd messages when processing 724 the message queue. All effects of all messages for which processing 725 started before the revocation took place MUST be allowed to complete 726 and the result MUST be given the same treatment as any LSP that had 727 been previously delegated to the PCE (e.g. the state MAY be 728 immediately cleared). Any further PCUpd messages from the PCE are 729 handled according to the PCUpd procedures described in this document. 731 If a PCEP session with the PCE to which the LSP is delegated exists 732 in the UP state during the revocation, the PCC MUST notify that PCE 733 by sending an LSP State Report with the Delegate flag set to 0, as 734 shown in Figure 5. 736 +-+-+ +-+-+ 737 |PCC| |PCE| 738 +-+-+ +-+-+ 739 | | 740 |---PCRpt, Delegate=1--->| 741 | | 742 |<--(PCUpd,Delegate=1)---| Delegation confirmed 743 | . | 744 | . | 745 | . | 746 |---PCRpt, Delegate=0--->| PCC revokes delegation 747 | | 749 Figure 5: Revoking a Delegation 751 After an LSP delegation has been revoked, a PCE can no longer update 752 LSP's parameters; an attempt to update parameters of a non-delegated 753 LSP will result in the PCC sending a PCErr message with error-type 19 754 (Invalid Operation), error-value 1 (attempted LSP Update Request for 755 a non-delegated LSP) (see Section 8.5). 757 5.7.2.2. Revocation on Redelegation Timeout 759 When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC 760 MUST wait the time interval specified in Redelegation Timeout 761 Interval before revoking LSP delegations to that PCE and attempting 762 to redelegate LSPs to an alternate PCE. If a PCEP session with the 763 original PCE can be reestablished before the Redelegation Timeout 764 Interval timer expires, LSP delegations to the PCE remain intact. 766 Likewise, when a PCC's PCEP session with a PCE terminates 767 unexpectedly, the PCC MUST wait for the State Timeout Interval before 768 flushing any LSP state associated with that PCE. Note that the State 769 Timeout Interval timer may expire before the PCC has redelegated the 770 LSPs to another PCE, for example if a PCC is not connected to any 771 active stateful PCE or if no connected active stateful PCE accepts 772 the delegation. In this case, the PCC MUST flush any LSP state set 773 by the PCE upon expiration of the State Timeout Interval and revert 774 to operator-defined default parameters or behaviors. This operation 775 SHOULD be done in a make-before-break fashion. 777 The State Timeout Interval MUST be greater than or equal to the 778 Redelegation Timeout Interval and MAY be set to infinity (meaning 779 that until the PCC specifically takes action to change the parameters 780 set by the PCE, they will remain intact). 782 5.7.3. Returning a Delegation 784 In order to keep a delegation, a PCE MUST set the Delegate flag to 1 785 on each LSP Update Request sent to the PCC. A PCE that no longer 786 wishes to update an LSP's parameters SHOULD return the LSP delegation 787 back to the PCC by sending an empty LSP Update Request which has the 788 Delegate flag set to 0. If a PCC receives an LSP Update Request with 789 the Delegate flag set to 0 (whether the LSP Update Request is empty 790 or not), it MUST treat this as a delegation return. 792 +-+-+ +-+-+ 793 |PCC| |PCE| 794 +-+-+ +-+-+ 795 | | 796 |---PCRpt, Delegate=1--->| LSP delegated 797 | . | 798 | . | 799 | . | 800 |<--PCUpd, Delegate=0----| Delegation returned 801 | | 802 |---PCRpt, Delegate=0--->| No delegation for LSP 803 | | 805 Figure 6: Returning a Delegation 807 If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is 808 not connected to any active stateful PCE or if no connected active 809 stateful PCE accepts the delegation), the LSP delegation on the PCC 810 will time out within a configurable Redelegation Timeout Interval and 811 the PCC MUST flush any LSP state set by a PCE at the expiration of 812 the State Timeout Interval. 814 5.7.4. Redundant Stateful PCEs 816 In a redundant configuration where one PCE is backing up another PCE, 817 the backup PCE may have only a subset of the LSPs in the network 818 delegated to it. The backup PCE does not update any LSPs that are 819 not delegated to it. In order to allow the backup to operate in a 820 hot-standby mode and avoid the need for state synchronization in case 821 the primary fails, the backup receives all LSP State Reports from a 822 PCC. When the primary PCE for a given LSP set fails, after expiry of 823 the Redelegation Timeout Interval, the PCC SHOULD delegate to the 824 redundant PCE all LSPs that had been previously delegated to the 825 failed PCE. Assuming that the State Timeout Interval had been 826 configured to be greater than the Redelegation Timeout Interval (as 827 MANDATORY), and assuming that the primary and redundant PCEs take 828 similar decisions, this delegation change will not cause any changes 829 to the LSP parameters. 831 5.7.5. Redelegation on PCE Failure 833 On failure, the goal is to: 1) avoid any traffic loss on the LSPs 834 that were updated by the PCE that crashed 2) minimize the churn in 835 the network in terms of ownership of the LSPs, 3) not leave any 836 "orphan" (undelegated) LSPs and 4) be able to control when the state 837 that was set by the PCE can be changed or purged. The values chosen 838 for the Redelegation Timeout and State Timeout values affect the 839 ability to accomplish these goals. 841 This section summarizes the behaviour with regards to LSP delegation 842 and LSP state on a PCE failure. 844 If the PCE crashes but recovers within the Redelegation Timeout, both 845 the delegation state and the LSP state are kept intact. 847 If the PCE crashes but does not recover within the Redelegation 848 Timeout, the delegation state is returned to the PCC. If the PCC can 849 redelegate the LSPs to another PCE, and that PCE accepts the 850 delegations, there will be no change in LSP state. If the PCC cannot 851 redelegate the LSPs to another PCE, then upon expiration of the State 852 Timeout Interval, the state set by the PCE is flushed, which may 853 cause change in the LSP state. Note that an operator may choose to 854 use an infinite State Timeout Interval if he wishes to maintain the 855 PCE state indefinitely. Note also that flushing the state should be 856 implemented using make-before-break to avoid traffic loss. 858 If there is a standby PCE, the Redelegation Timeout may be set to 0 859 through policy on the PCC, causing the LSPs to be redelegated 860 immediately to the PCC, which can delegate them immediately to the 861 standby PCE. Assuming the State Timeout Interval is greater than the 862 Redelegation Timeout, and assuming the standby PCE takes similar 863 decisions as the failed PCE, the LSP state will be kept intact. 865 5.8. LSP Operations 867 5.8.1. Passive Stateful PCE Path Computation Request/Response 868 +-+-+ +-+-+ 869 |PCC| |PCE| 870 +-+-+ +-+-+ 871 | | 872 1) Path computation |----- PCReq message --->| 873 request sent to | |2) Path computation 874 PCE | | request received, 875 | | path computed 876 | | 877 |<---- PCRep message ----|3) Computed paths 878 | (Positive reply) | sent to the PCC 879 | (Negative reply) | 880 4) LSP Status change| | 881 event | | 882 | | 883 5) LSP Status Report|----- PCRpt message --->| 884 sent to all | . | 885 stateful PCEs | . | 886 | . | 887 6) Repeat for each |----- PCRpt message --->| 888 LSP status change| | 889 | | 891 Figure 7: Passive Stateful PCE Path Computation Request/Response 893 Once a PCC has successfully established a PCEP session with a passive 894 stateful PCE and the PCC's LSP state is synchronized with the PCE 895 (i.e. the PCE knows about all PCC's existing LSPs), if an event is 896 triggered that requires the computation of a set of paths, the PCC 897 sends a path computation request to the PCE ([RFC5440], 898 Section 4.2.3). The PCReq message MAY contain the LSP Object to 899 identify the LSP for which the path computation is requested. 901 Upon receiving a path computation request from a PCC, the PCE 902 triggers a path computation and returns either a positive or a 903 negative reply to the PCC ([RFC5440], Section 4.2.4). 905 Upon receiving a positive path computation reply, the PCC receives a 906 set of computed paths and starts to setup the LSPs. For each LSP, it 907 MAY send an LSP State Report carried on a PCRpt message to the PCE, 908 indicating that the LSP's status is "Going-up". 910 Once an LSP is up or active, the PCC MUST send an LSP State Report 911 carried on a PCRpt message to the PCE, indicating that the LSP's 912 status is 'Up' or 'Active' respectively. If the LSP could not be set 913 up, the PCC MUST send an LSP State Report indicating that the LSP is 914 "Down' and stating the cause of the failure. Note that due to timing 915 constraints, the LSP status may change from 'Going-up' to 'Up' (or 916 'Down') before the PCC has had a chance to send an LSP State Report 917 indicating that the status is 'Going-up'. In such cases, the PCC MAY 918 choose to only send the PCRpt indicating the latest status ('Active', 919 'Up' or 'Down'). 921 Upon receiving a negative reply from a PCE, a PCC MAY resend a 922 modified request or take any other appropriate action. For each 923 requested LSP, it SHOULD also send an LSP State Report carried on a 924 PCRpt message to the PCE, indicating that the LSP's status is 'Down'. 926 There is no direct correlation between PCRep and PCRpt messages. For 927 a given LSP, multiple LSP State Reports will follow a single PCRep 928 message, as a PCC notifies a PCE of the LSP's state changes. 930 A PCC MUST send each LSP State Report to each stateful PCE that is 931 connected to the PCC. 933 Note that a single PCRpt message MAY contain multiple LSP State 934 Reports. 936 The passive stateful PCE is the model for stateful PCEs is described 937 in [RFC4655], Section 6.8. 939 5.8.2. Switching from Passive Stateful to Active Stateful 941 This section deals with the scenario of an LSP transitioning from a 942 passive stateful to an active stateful mode of operation. When the 943 LSP has no working path, prior to delegating the LSP, the PCC MUST 944 first use the procedure defined in Section 5.8.1 to request the 945 initial path from the PCE. This is required because the action of 946 delegating the LSP to a PCE using a PCRpt message is not an explicit 947 request to the PCE to compute a path for the LSP. The only explicit 948 way for a PCC to request a path from PCE is to send a PCReq message. 949 The PCRpt message MUST NOT be used by the PCC to attempt to request a 950 path from the PCE. 952 When the LSP is delegated after its setup, it may be useful for the 953 PCC to communicate to the PCE the locally configured intended 954 configuration parameters, so that the PCE may reuse them in its 955 computations. Such parameters MAY be acquired through an out of band 956 channel, or MAY be communicated in the PCRpt message delegating the 957 LSPs, by including them as part of the intented-attribute-list as 958 explained in Section 6.1. An implementation MAY allow policies on 959 the PCC to determine the configuration parameters to be sent to the 960 PCE. 962 5.8.3. Active Stateful PCE LSP Update 964 +-+-+ +-+-+ 965 |PCC| |PCE| 966 +-+-+ +-+-+ 967 | | 968 1) LSP State |-- PCRpt, Delegate=1 -->| 969 Synchronization | . | 970 | . |2) PCE decides to 971 | . | update the LSP 972 | | 973 |<---- PCUpd message ----|3) PCUpd message sent 974 | | to PCC 975 | | 976 | | 977 4) LSP Status Report|---- PCRpt message ---->| 978 sent(->Going-up) | . | 979 | . | 980 | . | 981 5) LSP Status Report|---- PCRpt message ---->| 982 sent (->Up|Down) | | 983 | | 985 Figure 8: Active Stateful PCE 987 Once a PCC has successfully established a PCEP session with an active 988 stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. 989 the PCE knows about all PCC's existing LSPs). After LSPs have been 990 delegated to the PCE, the PCE can modify LSP parameters of delegated 991 LSPs. 993 To update an LSP, a PCE MUST send the PCC an LSP Update Request using 994 a PCUpd message. The LSP Update Request contains a variety of 995 objects that specify the set of constraints and attributes for the 996 LSP's path. Each LSP Update Request MUST have a unique identifier, 997 the SRP-ID-number, carried in the SRP (Stateful PCE Request 998 Parameters) Object described in Section 7.2. The SRP-ID-number is 999 used to correlate errors and state reports to LSP Update Requests. A 1000 single PCUpd message MAY contain multiple LSP Update Requests. 1002 Upon receiving a PCUpd message the PCC starts to setup LSPs specified 1003 in LSP Update Requests carried in the message. For each LSP, it MAY 1004 send an LSP State Report carried on a PCRpt message to the PCE, 1005 indicating that the LSP's status is 'Going-up'. If the PCC decides 1006 that the LSP parameters proposed in the PCUpd message are 1007 unacceptable, it MUST report this error by including the LSP-ERROR- 1008 CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable 1009 parameters" in the LSP object in the PCRpt message to the PCE. Based 1010 on local policy, it MAY react further to this error by revoking the 1011 delegation. If the PCC receives a PCUpd message for an LSP object 1012 identified with a PLSP-ID that does not exist on the PCC, it MUST 1013 generate a PCErr with error-type 19 (Invalid Operation), error-value 1014 3, (Attempted LSP Update Request for an LSP identified by an unknown 1015 PSP-ID) (see Section 8.5). 1017 Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt 1018 message) to the PCE, indicating that the LSP's status is 'Up'. If 1019 the LSP could not be set up, the PCC MUST send an LSP State Report 1020 indicating that the LSP is 'Down' and stating the cause of the 1021 failure. A PCC MAY compress LSP State Reports to only reflect the 1022 most up to date state, as discussed in the previous section. 1024 A PCC MUST send each LSP State Report to each stateful PCE that is 1025 connected to the PCC. 1027 PCErr and PCRpt messages triggered as a result of a PCUpd message 1028 MUST include the SRP-ID-number from the PCUpd. This provides 1029 correlation of requests and errors and acknowledgement of state 1030 processing. The PCC MAY compress state when processing PCUpd. In 1031 this case, receipt of a higher SRP-ID-number implicitly acknowledges 1032 processing all the updates with lower SRP-ID-number for the specific 1033 LSP (as per Section 7.2). 1035 A PCC MUST NOT send to any PCE a Path Computation Request for a 1036 delegated LSP. Should the PCC decide it wants to issue a Path 1037 Computation Request on a delegated LSP, it MUST perform Delegation 1038 Revocation procedure first. 1040 5.9. LSP Protection 1042 LSP protection and interaction with stateful PCE, as well as the 1043 extensions necessary to implement this functionality will be 1044 discussed in a separate document. 1046 5.10. PCEP Sessions 1048 A permanent PCEP session MUST be established between a stateful PCE 1049 and the PCC. In the case of session failure, session reestablishment 1050 MUST be re-attempted per the procedures defined in [RFC5440]. 1052 6. PCEP Messages 1054 As defined in [RFC5440], a PCEP message consists of a common header 1055 followed by a variable-length body made of a set of objects. For 1056 each PCEP message type, a set of rules is defined that specify the 1057 set of objects that the message can carry. 1059 6.1. The PCRpt Message 1061 A Path Computation LSP State Report message (also referred to as 1062 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 1063 current state of an LSP. A PCRpt message can carry more than one LSP 1064 State Reports. A PCC can send an LSP State Report either in response 1065 to an LSP Update Request from a PCE, or asynchronously when the state 1066 of an LSP changes. The Message-Type field of the PCEP common header 1067 for the PCRpt message is to be assigned by IANA. 1069 The format of the PCRpt message is as follows: 1071 ::= 1072 1073 Where: 1075 ::= [] 1077 ::= [] 1078 1079 1080 Where: 1081 ::= 1082 [] 1083 1085 ::=[] 1086 [] 1088 Where: 1089 is represented by the ERO object defined in 1090 section 7.9 of [RFC5440]. 1091 consists of the actual computed and 1092 signaled values of the and objects 1093 defined in [RFC5440]. 1094 is represented by the RRO object defined in 1095 section 7.10 of [RFC5440]. 1096 is the attribute-list defined in 1097 section 6.5 of [RFC5440] and extended by PCEP extensions. 1099 The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message 1100 is not in response to a PCupd message, the SRP object MAY be omitted. 1101 When the PCC does not include the SRP object, the PCE MUST treat this 1102 as an SRP object with an SRP-ID-number equal to the reserved value 1103 0x00000000. The reserved value 0x00000000 indicates that the state 1104 reported is not as a result of processing a PCUpd message. 1106 If the PCRpt message is in response to a PCUpd message, the SRP 1107 object MUST be included and the value of the SRP-ID-number in the SRP 1108 Object MUST be the same as that sent in the PCUpd message that 1109 triggered the state that is reported. If the PCC compressed several 1110 PCUpd messages for the same LSP by only processing the one with the 1111 highest number, then it should use the SRP-ID-number of that request. 1112 No state compression is allowed for state reporting, e.g. PCRpt 1113 messages MUST NOT be pruned from the PCC's egress queue even if 1114 subsequent operations on the same LSP have been completed before the 1115 PCRpt message has been sent to the TCP stack. The PCC MUST 1116 explicitly report state changes (including removal) for paths it 1117 manages. 1119 The LSP object (see Section 7.3) is REQUIRED, and it MUST be included 1120 in each LSP State Report on the PCRpt message. If the LSP object is 1121 missing, the receiving PCE MUST send a PCErr message with Error- 1122 type=6 (Mandatory Object missing) and Error-value to be assigned by 1123 IANA (LSP object missing). 1125 If the LSP transitioned to non-operational state, the PCC SHOULD 1126 include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error 1127 Code to report the error to the PCE. 1129 The intended path, represented by the ERO object, is REQUIRED. If 1130 the ERO object is missing, the receiving PCE MUST send a PCErr 1131 message with Error-type=6 (Mandatory Object missing) and Error-value 1132 to be assigned by IANA (ERO object missing). The ERO may be empty if 1133 the PCE does not have a path for a delegated LSP. 1135 The actual path, represented by the RRO object, SHOULD be included in 1136 PCRpt by the PCC when the path is up or active, but MAY be omitted if 1137 the path is down due to a signaling error or another failure. 1139 The intended_attribute_list maps to the attribute_list in Section 6.5 1140 of [RFC5440] and is used to convey the requested parameters of the 1141 LSP path. This is needed in order to support the switch from passive 1142 to active stateful PCE as described in Section 5.8.2. When included 1143 as part of the intended_attribute_list, the meaning of the BANDWIDTH 1144 object is the requested bandwidth as intended by the operator. In 1145 this case, the BANDWIDTH Object-Type of 1 SHOULD be used. Similarly, 1146 to indicate a limiting constraint, the METRIC object SHOULD be 1147 included as part of the intended_attribute_list with the B flag set 1148 and with a specific metric value. To indicate the optimization 1149 metric, the METRIC object SHOULD be included as part of the 1150 intended_attribute_list with the B flag unset and the metric value 1151 set to zero. Note that the intended_attribute_list is optional and 1152 thus may be omitted. In this case, the PCE MAY use the values in the 1153 actual_attribute_list as the requested parameters for the path. 1155 The actual_attribute_list consists of the actual computed and 1156 signaled values of the BANDWIDTH and METRIC objects defined in 1157 [RFC5440]. When included as part of the actual_attribute_list, 1158 Object-Type 2 ([RFC5440]) SHOULD be used for the BANDWIDTH object and 1159 the C flag SHOULD be set in the METRIC object ([RFC5440]). 1161 A PCE may choose to implement a limit on the resources a single PCC 1162 can occupy. If a PCRpt is received that causes the PCE to exceed 1163 this limit, the PCE MUST notify the PCC using a PCNtf message with 1164 Notification Type to be allocated by IANA (Stateful PCE resource 1165 limit exceeded) and Notification Value to be allocated by IANA 1166 (Entering resource limit exceeded state) and MAY terminate the 1167 session. 1169 6.2. The PCUpd Message 1171 A Path Computation LSP Update Request message (also referred to as 1172 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 1173 attributes of an LSP. A PCUpd message can carry more than one LSP 1174 Update Request. The Message-Type field of the PCEP common header for 1175 the PCUpd message is to be assigned by IANA. 1177 The format of a PCUpd message is as follows: 1179 ::= 1180 1181 Where: 1183 ::= [] 1185 ::= 1186 1187 1188 Where: 1189 ::= 1191 Where: 1192 is represented by the ERO object defined in 1193 section 7.9 of [RFC5440]. 1194 is defined in [RFC5440] and extended by 1195 PCEP extensions. 1197 There are three mandatory objects that MUST be included within each 1198 LSP Update Request in the PCUpd message: the SRP Object (see 1199 Section 7.2), the LSP object (see Section 7.3) and the ERO object (as 1200 defined in [RFC5440], which represents the intended path. If the SRP 1201 object is missing, the receiving PCC MUST send a PCErr message with 1202 Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP 1203 object missing). If the LSP object is missing, the receiving PCC 1204 MUST send a PCErr message with Error-type=6 (Mandatory Object 1205 missing) and Error-value=8 (LSP object missing). If the ERO object 1206 is missing, the receiving PCC MUST send a PCErr message with Error- 1207 type=6 (Mandatory Object missing) and Error-value=9 (ERO object 1208 missing). 1210 The ERO in the PCUpd may be empty if the PCE cannot find a valid path 1211 for a delegated LSP. One typical situation resulting in this empty 1212 ERO carried in the PCUpd message is that a PCE can no longer find a 1213 strict SRLG-disjoint path for a delegated LSP after a link failure. 1214 The PCC SHOULD implement a local policy to decide the appropriate 1215 action to be taken: either tear down the LSP, or revoke the 1216 delegation and use a locally computed path, or keep the existing LSP. 1218 A PCC only acts on an LSP Update Request if permitted by the local 1219 policy configured by the network manager. Each LSP Update Request 1220 that the PCC acts on results in an LSP setup operation. An LSP 1221 Update Request MUST contain all LSP parameters that a PCE wishes to 1222 be set for the LSP. A PCC MAY set missing parameters from locally 1223 configured defaults. If the LSP specified in the Update Request is 1224 already up, it will be re-signaled. 1226 The PCC SHOULD minimize the traffic interruption, and MAY use the 1227 make-before-break procedures described in [RFC3209] in order to 1228 achieve this goal. If the make-before-break procedures are used, two 1229 paths will briefly co-exist. The PCC MUST send separate PCRpt 1230 messages for each, identified by the LSP-IDENTIFIERS TLV. When the 1231 old path is torn down after the head end switches over the traffic, 1232 this event MUST be reported by sending a PCRpt message with the LSP- 1233 IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number 1234 that the PCC associates with this PCRpt MUST be 0x00000000. Thus, a 1235 make-before-break operation will typically result in at least two 1236 PCRpt messages, one for the new path and one for the removal of the 1237 old path (more messages may be possible if intermediate states are 1238 reported). 1240 If the path setup fails due to an RSVP signaling error, the error is 1241 reported to the PCE. The PCC will not attempt to resignal the path 1242 until it is prompted again by the PCE with a subsequent PCUpd 1243 message. 1245 A PCC MUST respond with an LSP State Report to each LSP Update 1246 Request it processed to indicate the resulting state of the LSP in 1247 the network (even if this processing did not result in changing the 1248 state of the LSP). The SRP-ID-number included in the PCRpt MUST 1249 match that in the PCUpd. A PCC MAY respond with multiple LSP State 1250 Reports to report LSP setup progress of a single LSP. In that case, 1251 the SRP-ID-number MUST be included for the first message, for 1252 subsequent messages the reserved value 0x00000000 SHOULD be used. 1254 Note that a PCC MUST process all LSP Update Requests - for example, 1255 an LSP Update Request is sent when a PCE returns delegation or puts 1256 an LSP into non-operational state. The protocol relies on TCP for 1257 message-level flow control. 1259 If the rate of PCUpd messages sent to a PCC for the same target LSP 1260 exceeds the rate at which the PCC can signal LSPs into the network, 1261 the PCC MAY perform state compression on its ingress queue. The 1262 compression algorithm is based on the fact that each PCUpd request 1263 contains the complete LSP state the PCE wishes to be set and works as 1264 follows: when the PCC starts processing a PCUpd message at the head 1265 of its ingress queue, it may search the queue forward for more recent 1266 PCUpd messages pertaining that particular LSP, prune all but the 1267 latest one from the queue and process only the last one as that 1268 request contains the most up-to-date desired state for the LSP. The 1269 PCC MUST NOT send PCRpt nor PCErr messages for requests which were 1270 pruned from the queue in this way. This compression step may be 1271 performed only while the LSP is not being signaled, e.g. if two PCUpd 1272 arrive for the same LSP in quick succession and the PCC started the 1273 signaling of the changes relevant to the first PCUpd, then it MUST 1274 wait until the signaling finishes (and report the new state via a 1275 PCRpt) before attempting to apply the changes indicated in the second 1276 PCUpd. 1278 Note also that it is up to the PCE to handle inter-LSP dependencies; 1279 for example, if ordering of LSP set-ups is required, the PCE has to 1280 wait for an LSP State Report for a previous LSP before starting the 1281 update of the next LSP. 1283 If the PCUpd cannot be satisfied (for example due to unsupported 1284 object or TLV), the PCC MUST respond with a PCErr message indicating 1285 the failure (see Section 7.3.3). 1287 6.3. The PCErr Message 1289 If the stateful PCE capability has been advertised on the PCEP 1290 session, the PCErr message MAY include the SRP object. If the error 1291 reported is the result of an LSP update request, then the SRP-ID- 1292 number MUST be the one from the PCUpd that triggered the error. If 1293 the error is unsolicited, the SRP object MAY be omitted. This is 1294 equivalent to including an SRP object with SRP-ID-number equal to the 1295 reserved value 0x00000000. 1297 The format of a PCErr message from [RFC5440] is extended as follows: 1299 ::= 1300 ( [] ) | 1301 [] 1303 ::=[] 1305 ::=[ | ] 1306 1308 ::=[] 1310 ::=[] 1312 ::=[] 1314 6.4. The PCReq Message 1316 A PCC MAY include the LSP object in the PCReq message (see 1317 Section 7.3) if the stateful PCE capability has been negotiated on a 1318 PCEP session between the PCC and a PCE. 1320 The definition of the PCReq message from [RFC5440] is extended to 1321 optionally include the LSP object after the END-POINTS object. The 1322 encoding from [RFC5440] will become: 1324 ::= 1325 [] 1326 1327 Where: 1329 ::=[] 1330 ::=[] 1332 ::= 1333 1334 [] 1335 [] 1336 [] 1337 [] 1338 [[]] 1339 [] 1340 [] 1342 6.5. The PCRep Message 1344 A PCE MAY include the LSP object in the PCRep message (see 1345 (Section 7.3) if the stateful PCE capability has been negotiated on a 1346 PCEP session between the PCC and the PCE and the LSP object was 1347 included in the corresponding PCReq message from the PCC. 1349 The definition of the PCRep message from [RFC5440] is extended to 1350 optionally include the LSP object after the RP object. The encoding 1351 from [RFC5440] will become: 1353 ::= 1354 1356 Where: 1358 ::=[] 1360 ::= 1361 [] 1362 [] 1363 [] 1364 [] 1366 7. Object Formats 1368 The PCEP objects defined in this document are compliant with the PCEP 1369 object format defined in [RFC5440]. The P flag and the I flag of the 1370 PCEP objects defined in the current document MUST be set to 0 on 1371 transmission and SHOULD be ignored on receipt since the P and I flags 1372 are exclusively related to path computation requests. 1374 7.1. OPEN Object 1376 This document defines one new optional TLVs for use in the OPEN 1377 Object. 1379 7.1.1. Stateful PCE Capability TLV 1381 The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the 1382 OPEN Object for stateful PCE capability advertisement. Its format is 1383 shown in the following figure: 1385 0 1 2 3 1386 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 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | Type=[TBD] | Length=4 | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Flags |U| 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 Figure 9: STATEFUL-PCE-CAPABILITY TLV format 1395 The type (16 bits) of the TLV is to be assigned by IANA. The length 1396 field is 16 bit-long and has a fixed value of 4. 1398 The value comprises a single field - Flags (32 bits): 1400 U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag 1401 indicates that the PCC allows modification of LSP parameters; if 1402 set to 1 by a PCE, the U Flag indicates that the PCE is capable of 1403 updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be 1404 advertised by both a PCC and a PCE for PCUpd messages to be 1405 allowed on a PCEP session. 1407 Unassigned bits are considered reserved. They MUST be set to 0 on 1408 transmission and MUST be ignored on receipt. 1410 Advertisement of the stateful PCE capability implies support of LSPs 1411 that are signaled via RSVP, as well as the objects, TLVs and 1412 procedures defined in this document. 1414 7.2. SRP Object 1416 The SRP (Stateful PCE Request Parameters) object MUST be carried 1417 within PCUpd messages and MAY be carried within PCRpt and PCErr 1418 messages. The SRP object is used to correlate between update 1419 requests sent by the PCE and the error reports and state reports sent 1420 by the PCC. 1422 SRP Object-Class is to be assigned by IANA. 1424 SRP Object-Type is 1. 1426 The format of the SRP object body is shown in Figure 10: 1428 0 1 2 3 1429 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 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | Flags | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | SRP-ID-number | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | | 1436 // Optional TLVs // 1437 | | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 Figure 10: The SRP Object format 1442 The SRP object body has a variable length and may contain additional 1443 TLVs. 1445 Flags (32 bits): None defined yet. 1447 SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the 1448 current PCEP session uniquely identify the operation that the PCE has 1449 requested the PCC to perform on a given LSP. The SRP-ID-number is 1450 incremented each time a new request is sent to the PCC, and may wrap 1451 around. 1453 The values 0x00000000 and 0xFFFFFFFF are reserved. 1455 Every request to update an LSP receives a new SRP-ID-number. This 1456 number is unique per PCEP session and is incremented each time an 1457 operation is requested from the PCE. Thus, for a given LSP there may 1458 be more than one SRP-ID-number unacknowledged at a given time. The 1459 value of the SRP-ID-number is echoed back by the PCC in PCErr and 1460 PCRpt messages to allow for correlation between requests made by the 1461 PCE and errors or state reports generated by the PCC. If the error 1462 or report were not as a result of a PCE operation (for example in the 1463 case of a link down event), the reserved value of 0x00000000 is used 1464 for the SRP-ID-number. The absence of the SRP object is equivalent 1465 to an SRP object with the reserved value of 0x00000000. An SRP-ID- 1466 number is considered unacknowledged and cannot be reused until a 1467 PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the 1468 same LSP. In case of SRP-ID-number wrapping the last SRP-ID-number 1469 before the wrapping MUST be explicitly acknowledged, to avoid a 1470 situation where SRP-ID-numbers remain unacknowledged after the wrap. 1471 This means that the PCC may need to issue two PCUpd messages on 1472 detecting a wrap. 1474 7.3. LSP Object 1476 The LSP object MUST be present within PCRpt and PCUpd messages. The 1477 LSP object MAY be carried within PCReq and PCRep messages if the 1478 stateful PCE capability has been negotiated on the session. The LSP 1479 object contains a set of fields used to specify the target LSP, the 1480 operation to be performed on the LSP, and LSP Delegation. It also 1481 contains a flag indicating to a PCE that the LSP state 1482 synchronization is in progress. This document focuses on LSPs that 1483 are signaled with RSVP, many of the TLVs used with the LSP object 1484 mirror RSVP state. 1486 LSP Object-Class is to be assigned by IANA. 1488 LSP Object-Type is 1. 1490 The format of the LSP object body is shown in Figure 11: 1492 0 1 2 3 1493 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 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | PLSP-ID | Flag | O|A|R|S|D| 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 // TLVs // 1498 | | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 Figure 11: The LSP Object format 1503 PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC 1504 creates a unique PLSP-ID for each LSP that is constant for the 1505 lifetime of a PCEP session. The PCC will advertise the same PLSP-ID 1506 on all PCEP sessions it maintains at a given times. The mapping of 1507 the Symbolic Path Name to PLSP-ID is communicated to the PCE by 1508 sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All 1509 subsequent PCEP messages then address the LSP by the PLSP-ID. The 1510 values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a 1511 value that is constant for the lifetime of the PCEP session, during 1512 which time for an RSVP-signaled LSP there might be a different RSVP 1513 identifiers (LSP-id, tunnel-id) allocated to it. 1515 Flags (12 bits), starting from the least significant bit: 1517 D (Delegate - 1 bit): On a PCRpt message, the D Flag set to 1 1518 indicates that the PCC is delegating the LSP to the PCE. On a 1519 PCUpd message, the D flag set to 1 indicates that the PCE is 1520 confirming the LSP Delegation. To keep an LSP delegated to the 1521 PCE, the PCC must set the D flag to 1 on each PCRpt message for 1522 the duration of the delegation - the first PCRpt with the D flag 1523 set to 0 revokes the delegation. To keep the delegation, the PCE 1524 must set the D flag to 1 on each PCUpd message for the duration of 1525 the delegation - the first PCUpd with the D flag set to 0 returns 1526 the delegation. 1528 S (SYNC - 1 bit): The S Flag MUST be set to 1 on each PCRpt sent 1529 from a PCC during State Synchronization. The S Flag MUST be set 1530 to 0 in other messages sent from the PCC. 1532 R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1533 LSP has been removed from the PCC and the PCE SHOULD remove all 1534 state from its database. Upon receiving an LSP State Report with 1535 the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD 1536 remove all state for the path identified by the LSP-IDENTIFIERS 1537 TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is 1538 used, the PCE SHOULD remove all state for the PLSP-ID from its 1539 database. 1541 A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates 1542 the PCC's target operational status for this LSP. On PCUpd 1543 messages, the A Flag indicates the LSP status that the PCE desires 1544 for this LSP. In both cases, a value of '1' means that the 1545 desired operational state is active, and a value of '0' means that 1546 the desired operational state is inactive. A PCC ignores the A 1547 flag on a PCUpd message unless the operator's policy allows the 1548 PCE to control the corresponding LSP's administrative state. 1550 O(Operational - 3 bits): On PCRpt messages, the O Field represents 1551 the operational status of the LSP. 1553 The following values are defined: 1555 0 - DOWN: not active. 1557 1 - UP: signalled. 1559 2 - ACTIVE: up and carrying traffic. 1561 3 - GOING-DOWN: LSP is being torn down, resources are being 1562 released. 1564 4 - GOING-UP: LSP is being signalled. 1566 5-7 - Reserved: these values are reserved for future use. 1568 Unassigned bits are considered reserved. They MUST be set to 0 on 1569 transmission and MUST be ignored on receipt. 1571 TLVs that may be included in the LSP Object are described in the 1572 following sections. 1574 7.3.1. LSP-IDENTIFIERS TLVs 1576 The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt 1577 messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will 1578 generate an error with error-type 6 (mandatory object missing) and 1579 error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. 1580 The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd 1581 messages for RSVP-signaled LSPs. The special value of all zeros for 1582 this TLV is used to refer to all paths pertaining to a particular 1583 PLSP-ID. There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one 1584 for IPv6. 1586 It is the responsibility of the PCC to send to the PCE the 1587 identifiers for each RSVP incarnation of the tunnel. For example, in 1588 a make-before-break scenario, the PCC MUST send a separate PCRpt for 1589 the old and for the reoptimized paths, and explicitly report removal 1590 of any of these paths using the R bit in the LSP object. 1592 The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 1593 figure: 1595 0 1 2 3 1596 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 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Type=[TBD] | Length=16 | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | IPv4 Tunnel Sender Address | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | LSP ID | Tunnel ID | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Extended Tunnel ID | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 | IPv4 Tunnel Endpoint Address | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 Figure 12: IPV4-LSP-IDENTIFIERS TLV format 1611 The type (16 bits) of the TLV is to be assigned by IANA. The length 1612 field is 16 bit-long and has a fixed value of 16. The value contains 1613 the following fields: 1615 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 1616 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 1617 Sender Template Object. 1619 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1620 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 1621 Object. A value of 0 MUST be used if the LSP is not yet signaled. 1623 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1624 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 1626 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 1627 identifier defined in [RFC3209], Section 4.6.1.1 for the 1628 LSP_TUNNEL_IPv4 Session Object. 1630 IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 1631 address, as defined in [RFC3209], Section 4.6.1.1 for the 1632 LSP_TUNNEL_IPv4 Sender Template Object. 1634 The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following 1635 figure: 1637 0 1 2 3 1638 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 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Type=[TBD] | Length=52 | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | | 1643 + + 1644 | IPv6 tunnel sender address | 1645 + (16 octets) + 1646 | | 1647 + + 1648 | | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 | LSP ID | Tunnel ID | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 | | 1653 + + 1654 | Extended Tunnel ID | 1655 + (16 octets) + 1656 | | 1657 + + 1658 | | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | | 1661 + + 1662 | IPv6 tunnel endpoint address | 1663 + (16 octets) + 1664 | | 1665 + + 1666 | | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 Figure 13: IPV6-LSP-IDENTIFIERS TLV format 1671 The type (16 bits) of the TLV is to be assigned by IANA. The length 1672 field is 16 bit-long and has a fixed value of 52. The value contains 1673 the following fields: 1675 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 1676 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 1677 Sender Template Object. 1679 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1680 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 1681 Object. A value of 0 MUST be used if the LSP is not yet signaled. 1683 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1684 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 1686 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 1687 identifier defined in [RFC3209], Section 4.6.1.2 for the 1688 LSP_TUNNEL_IPv6 Session Object. 1690 IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 1691 address, as defined in [RFC3209], Section 4.6.1.2 for the 1692 LSP_TUNNEL_IPv6 Session Object. 1694 The Tunnel ID remains constant over the life time of a tunnel. 1696 7.3.2. Symbolic Path Name TLV 1698 Each LSP (path) MUST have a symbolic name that is unique in the PCC. 1699 This symbolic path name MUST remain constant throughout an LSP's 1700 lifetime, which may span across multiple consecutive PCEP sessions 1701 and/or PCC restarts. The symbolic path name MAY be specified by an 1702 operator in a PCC's configuration. If the operator does not specify 1703 a unique symbolic name for a path, the PCC MUST auto-generate one. 1705 The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the 1706 LSP State Report (PCRpt) message when during a given PCEP session an 1707 LSP is first reported to a PCE. A PCC sends to a PCE the first LSP 1708 State Report either during State Synchronization, or when a new LSP 1709 is configured at the PCC. The symbolic path name MAY be included in 1710 the LSP object in subsequent LSP State Reports for the LSP. 1712 The format of the SYMBOLIC-PATH-NAME TLV is shown in the following 1713 figure: 1715 0 1 2 3 1716 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 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Type=[TBD] | Length (variable) | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | | 1721 // Symbolic Path Name // 1722 | | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 Figure 14: SYMBOLIC-PATH-NAME TLV format 1727 Type (16 bits): to be assigned by IANA. 1729 Length (16 bits): indicates the total length of the TLV in octets and 1730 MUST be greater than 0. The TLV MUST be zero-padded so that the TLV 1731 is 4-octet aligned. 1733 Symbolic Path Name (variable): symbolic name for the LSP, unique in 1734 the PCC. 1736 7.3.3. LSP Error Code TLV 1738 The LSP Error code TLV is an optional TLV for use in the LSP object 1739 to convey error information. When an LSP Update Request fails, an 1740 LSP State Report MUST be sent to report the current state of the LSP, 1741 and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for 1742 the failure. Similarly, when a PCRpt is sent as a result of an LSP 1743 transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD 1744 be included to indicate the reason for the transition. 1746 The format of the LSP-ERROR-CODE TLV is shown in the following 1747 figure: 1749 0 1 2 3 1750 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 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Type=[TBD] | Length=4 | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | LSP Error Code | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 Figure 15: LSP-ERROR-CODE TLV format 1759 The type (16 bits) of the TLV is to be assigned by IANA. The length 1760 field is 16 bit-long and has a fixed value of 4. The value contains 1761 an error code that indicates the cause of the failure. 1763 The following LSP Error Codes are currently defined: 1765 Value Meaning 1766 1 Unknown reason 1767 2 Limit reached for PCE-controlled LSPs 1768 3 Too many pending LSP update requests 1769 4 Unacceptable parameters 1770 5 Internal error 1771 6 LSP administratively brought down 1772 7 LSP preempted 1773 8 RSVP signaling error 1775 7.3.4. RSVP Error Spec TLV 1777 The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object 1778 to carry RSVP error information. It includes the RSVP ERROR_SPEC or 1779 USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned 1780 to the PCC from a downstream node. If the set up of an LSP fails at 1781 a downstream node which returned an ERROR_SPEC to the PCC, the PCC 1782 SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with 1783 LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV 1784 with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object. 1786 The format of the RSVP-ERROR-SPEC TLV is shown in the following 1787 figure: 1789 0 1 2 3 1790 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 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Type=[TBD] | Length (variable) | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | | 1795 + RSVP ERROR_SPEC or USER_ERROR_SPEC Object + 1796 | | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 Figure 16: RSVP-ERROR-SPEC TLV format 1801 Type (16 bits):to be assigned by IANA. 1803 Length (16 bits): indicates the total length of the TLV in octets. 1804 The TLV MUST be zero-padded so that the TLV is 4-octet aligned. 1806 Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC 1807 Object: as specified in [RFC2205] and [RFC5284], including the object 1808 header. 1810 8. IANA Considerations 1812 This document requests IANA actions to allocate code points for the 1813 protocol elements defined in this document. Values shown here are 1814 suggested for use by IANA. 1816 8.1. PCE Capabilities in IGP Advertisements 1818 IANA is requested to allocate new bits in the OSPF Parameters "PCE 1819 Capability Flags" registry, as follows: 1821 Bit Meaning Reference 1822 11 Active Stateful PCE This document 1823 capability 1824 12 Passive Stateful PCE This document 1825 capability 1827 8.2. PCEP Messages 1829 IANA is requested to allocate new message types within the "PCEP 1830 Messages" sub-registry of the PCEP Numbers registry, as follows: 1832 Value Meaning Reference 1833 10 Report This document 1834 11 Update This document 1836 8.3. PCEP Objects 1838 IANA is requested to allocate new object-class values and object 1839 types within the "PCEP Objects" sub-registry of the PCEP Numbers 1840 registry, as follows. 1842 Object-Class Value Name Reference 1844 32 LSP This document 1845 Object-Type 1846 1 1847 33 SRP This document 1848 Object-Type 1849 1 1851 8.4. LSP Object 1853 This document requests that a new sub-registry, named "LSP Object 1854 Flag Field", is created within the "Path Computation Element Protocol 1855 (PCEP) Numbers" registry to manage the Flag field of the LSP 1856 object.New values are to be assigned by Standards Action [RFC5226]. 1857 Each bit should be tracked with the following qualities: 1859 o Bit number (counting from bit 0 as the most significant bit) 1861 o Capability description 1863 o Defining RFC 1865 The following values are defined in this document: 1867 Bit Description Reference 1869 0-4 Reserved This document 1870 5-7 Operational (3 bits) This document 1871 8 Administrative This document 1872 9 Remove This document 1873 10 SYNC This document 1874 11 Delegate This document 1876 8.5. PCEP-Error Object 1878 IANA is requested to allocate new Error Types and Error Values within 1879 the " PCEP-ERROR Object Error Types and Values" sub-registry of the 1880 PCEP Numbers registry, as follows: 1882 Error-Type Meaning 1883 6 Mandatory Object missing 1885 Error-value=8: LSP Object missing 1886 Error-value=9: ERO Object missing 1887 Error-value=10: SRP Object missing 1888 Error-value=11: LSP-IDENTIFIERS TLV missing 1889 19 Invalid Operation 1891 Error-value=1: Attempted LSP Update Request for a non- 1892 delegated LSP. The PCEP-ERROR Object 1893 is followed by the LSP Object that 1894 identifies the LSP. 1895 Error-value=2: Attempted LSP Update Request if the 1896 stateful PCE capability was not 1897 advertised. 1898 Error-value=3: Attempted LSP Update Request for an LSP 1899 identified by an unknown PLSP-ID. 1900 Error-value=5: Attempted LSP State Report if active 1901 stateful PCE capability was not 1902 advertised. 1903 20 LSP State synchronization error. 1905 Error-value=1: A PCE indicates to a PCC that it can 1906 not process (an otherwise valid) LSP 1907 State Report. The PCEP-ERROR Object is 1908 followed by the LSP Object that 1909 identifies the LSP. 1910 Error-value=5: A PCC indicates to a PCE that it can 1911 not complete the state synchronization, 1913 8.6. Notification Object 1915 IANA is requested to allocate new Notification Types and Notification 1916 Values within the "Notification Object" sub-registry of the PCEP 1917 Numbers registry, as follows: 1919 Notification-Type Meaning 1920 4 Stateful PCE resource limit exceeded 1921 Notification-value=1: Entering resource limit 1922 exceeded state 1923 Notification-value=2: Exiting resource limit exceeded 1924 state 1926 8.7. PCEP TLV Type Indicators 1928 IANA is requested to allocate new TLV Type Indicator values within 1929 the " PCEP TLV Type Indicators" sub-registry of the PCEP Numbers 1930 registry, as follows: 1932 Value Meaning Reference 1933 16 STATEFUL-PCE-CAPABILITY This document 1934 17 SYMBOLIC-PATH-NAME This document 1935 18 IPV4-LSP-IDENTIFIERS This document 1936 19 IPV6-LSP-IDENTIFIERS This document 1937 20 LSP-ERROR-CODE This document 1938 21 RSVP-ERROR-SPEC This document 1940 8.8. STATEFUL-PCE-CAPABILITY TLV 1942 This document requests that a new sub-registry, named "STATEFUL-PCE- 1943 CAPABILITY TLV Flag Field", is created within the "Path Computation 1944 Element Protocol (PCEP) Numbers" registry to manage the Flag field in 1945 the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = 1). 1946 New values are to be assigned by Standards Action [RFC5226]. Each 1947 bit should be tracked with the following qualities: 1949 o Bit number (counting from bit 0 as the most significant bit) 1951 o Capability description 1953 o Defining RFC 1955 The following values are defined in this document: 1957 Bit Description Reference 1959 31 LSP-UPDATE-CAPABILITY This document 1961 8.9. LSP-ERROR-CODE TLV 1963 This document requests that a new sub-registry, named "LSP-ERROR-CODE 1964 TLV Error Code Field", is created within the "Path Computation 1965 Element Protocol (PCEP) Numbers" registry to manage the LSP Error 1966 code field of the LSP-ERROR-CODE TLV. This field specifies the 1967 reason for failure to update the LSP. 1969 New values are to be assigned by Standards Action [RFC5226]. Each 1970 value should be tracked with the following qualities: value, 1971 description and defining RFC. The following values are defined in 1972 this document: 1974 Value Meaning 1975 1 Unknown reason 1976 2 Limit reached for PCE-controlled LSPs 1977 3 Too many pending LSP update requests 1978 4 Unacceptable parameters 1979 5 Internal error 1980 6 LSP administratively brought down 1981 7 LSP preempted 1982 8 RSVP signaling error 1984 9. Manageability Considerations 1986 All manageability requirements and considerations listed in [RFC5440] 1987 apply to PCEP extensions defined in this document. In addition, 1988 requirements and considerations listed in this section apply. 1990 9.1. Control Function and Policy 1992 In addition to configuring specific PCEP session parameters, as 1993 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 1994 allow configuring the stateful PCEP capability and the LSP Update 1995 capability. A PCC implementation SHOULD allow the operator to 1996 specify multiple candidate PCEs for and a delegation preference for 1997 each candidate PCE. A PCC SHOULD allow the operator to specify an 1998 LSP delegation policy where LSPs are delegated to the most-preferred 1999 online PCE. A PCC MAY allow the operator to specify different LSP 2000 delegation policies. 2002 A PCC implementation which allows concurrent connections to multiple 2003 PCEs SHOULD allow the operator to group the PCEs by administrative 2004 domains and it MUST NOT advertise LSP existence and state to a PCE if 2005 the LSP is delegated to a PCE in a different group. 2007 A PCC implementation SHOULD allow the operator to specify whether the 2008 PCC will advertise LSP existence and state for LSPs that are not 2009 controlled by any PCE (for example, LSPs that are statically 2010 configured at the PCC). 2012 A PCC implementation SHOULD allow the operator to specify both the 2013 Redelegation Timeout Interval and the State Timeout Interval. The 2014 default value of the Redelegation Timeout Interval SHOULD be set to 2015 30 seconds. An operator MAY also configure a policy that will 2016 dynamically adjust the Redelegation Timeout Interval, for example 2017 setting it to zero when the PCC has an established session to a 2018 backup PCE. The default value for the State Timeout Interval SHOULD 2019 be set to 60 seconds. 2021 After the expiration of the State Timeout Interval, the LSP reverts 2022 to operator-defined default parameters. A PCC implementation MUST 2023 allow the operator to specify the default LSP parameters. To achieve 2024 a behavior where the LSP retains the parameters set by the PCE until 2025 such time that the PCC makes a change to them, a State Timeout 2026 Interval of infinity SHOULD be used. Any changes to LSP parameters 2027 SHOULD be done in make-before-break fashion. 2029 LSP Delegation is controlled by operator-defined policies on a PCC. 2030 LSPs are delegated individually - different LSPs may be delegated to 2031 different PCEs. An LSP is delegated to at most one PCE at any given 2032 point in time. A PCC implementation SHOULD support the delegation 2033 policy, when all PCC's LSPs are delegated to a single PCE at any 2034 given time. Conversely, the policy revoking the delegation for all 2035 PCC's LSPs SHOULD also be supported. 2037 A PCC implementation SHOULD allow the operator to specify delegation 2038 priority for PCEs. This effectively defines the primary PCE and one 2039 or more backup PCEs to which primary PCE's LSPs can be delegated when 2040 the primary PCE fails. 2042 Policies defined for stateful PCEs and PCCs should eventually fit in 2043 the Policy-Enabled Path Computation Framework defined in [RFC5394], 2044 and the framework should be extended to support Stateful PCEs. 2046 9.2. Information and Data Models 2048 PCEP session configuration and information in the PCEP MIB module 2049 SHOULD be extended to include advertised stateful capabilities, 2050 synchronization status, and delegation status (at the PCC list PCEs 2051 with delegated LSPs). 2053 9.3. Liveness Detection and Monitoring 2055 PCEP extensions defined in this document do not require any new 2056 mechanisms beyond those already defined in [RFC5440], Section 8.3. 2058 9.4. Verifying Correct Operation 2060 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 2061 extensions defined in this document. In addition to monitoring 2062 parameters defined in [RFC5440], a stateful PCC-side PCEP 2063 implementation SHOULD provide the following parameters: 2065 o Total number of LSP updates 2067 o Number of successful LSP updates 2069 o Number of dropped LSP updates 2071 o Number of LSP updates where LSP setup failed 2073 A PCC implementation SHOULD provide a command to show for each LSP 2074 whether it is delegated, and if so, to which PCE. 2076 A PCC implementation SHOULD allow the operator to manually revoke LSP 2077 delegation. 2079 9.5. Requirements on Other Protocols and Functional Components 2081 PCEP extensions defined in this document do not put new requirements 2082 on other protocols. 2084 9.6. Impact on Network Operation 2086 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 2087 extensions defined in this document. 2089 Additionally, a PCEP implementation SHOULD allow a limit to be placed 2090 on the number of LSPs delegated to the PCE and on the rate of PCUpd 2091 and PCRpt messages sent by a PCEP speaker and processed from a peer. 2092 It SHOULD also allow sending a notification when a rate threshold is 2093 reached. 2095 A PCC implementation SHOULD allow a limit to be placed on the rate of 2096 LSP Updates to the same LSP to avoid signaling overload discussed in 2097 Section 10.3. 2099 10. Security Considerations 2101 10.1. Vulnerability 2103 This document defines extensions to PCEP to enable stateful PCEs. 2104 The nature of these extensions and the delegation of path control to 2105 PCEs results in more information being available for a hypothetical 2106 adversary and a number of additional attack surfaces which must be 2107 protected. 2109 The security provisions described in [RFC5440] remain applicable to 2110 these extensions. However, because the protocol modifications 2111 outlined in this document allow the PCE to control path computation 2112 timing and sequence, the PCE defense mechanisms described in 2113 [RFC5440] section 7.2 are also now applicable to PCC security. 2115 As a general precaution, it is RECOMMENDED that these PCEP extensions 2116 only be activated on authenticated and encrypted sessions across PCEs 2117 and PCCs belonging to the same administrative authority. 2119 The following sections identify specific security concerns that may 2120 result from the PCEP extensions outlined in this document along with 2121 recommended mechanisms to protect PCEP infrastructure against related 2122 attacks. 2124 10.2. LSP State Snooping 2126 The stateful nature of this extension explicitly requires LSP status 2127 updates to be sent from PCC to PCE. While this gives the PCE the 2128 ability to provide more optimal computations to the PCC, it also 2129 provides an adversary with the opportunity to eavesdrop on decisions 2130 made by network systems external to PCE. This is especially true if 2131 the PCC delegates LSPs to multiple PCEs simultaneously. 2133 Adversaries may gain access to this information by eavesdropping on 2134 unsecured PCEP sessions, and might then use this information in 2135 various ways to target or optimize attacks on network infrastructure. 2136 For example by flexibly countering anti-DDoS measures being taken to 2137 protect the network, or by determining choke points in the network 2138 where the greatest harm might be caused. 2140 PCC implementations which allow concurrent connections to multiple 2141 PCEs SHOULD allow the operator to group the PCEs by administrative 2142 domains and they MUST NOT advertise LSP existence and state to a PCE 2143 if the LSP is delegated to a PCE in a different group. 2145 10.3. Malicious PCE 2147 The LSP delegation mechanism described in this document allows a PCC 2148 to grant effective control of an LSP to the PCE for the duration of a 2149 PCEP session. While this enables PCE control of the timing and 2150 sequence of path computations within and across PCEP sessions, it 2151 also introduces a new attack vector: an attacker may flood the PCC 2152 with PCUpd messages at a rate which exceeds either the PCC's ability 2153 to process them or the network's ability to signal the changes, 2154 either by spoofing messages or by compromising the PCE itself. 2156 A PCC is free to revoke an LSP delegation at any time without needing 2157 any justification. A defending PCC can do this by enqueueing the 2158 appropriate PCRpt message. As soon as that message is enqueued in 2159 the session, the PCC is free to drop any incoming PCUpd messages 2160 without additional processing. 2162 10.4. Malicious PCC 2164 A stateful session also results in an increased attack surface by 2165 placing a requirement for the PCE to keep an LSP state replica for 2166 each PCC. It is RECOMMENDED that PCE implementations provide a limit 2167 on resources a single PCC can occupy. A PCE implementing such a 2168 limit MUST send a PCNtf message with notification-type to be assigned 2169 by IANA (Stateful PCE resource limit exceeded) and notification-value 2170 to be assigned by IANA (Entering resource limit exceeded state) upon 2171 receiving an LSP state report causing it to exceed this threshold. 2173 Delegation of LSPs can create further strain on PCE resources and a 2174 PCE implementation MAY preemptively give back delegations if it finds 2175 itself lacking the resources needed to effectively manage the 2176 delegation. Since the delegation state is ultimately controlled by 2177 the PCC, PCE implementations SHOULD provide throttling mechanisms to 2178 prevent strain created by flaps of either a PCEP session or an LSP 2179 delegation. 2181 11. Contributing Authors 2183 Xian Zhang 2184 Huawei Technology 2185 F3-5-B R&D Center 2186 Huawei Industrial Base, Bantian, Longgang District 2187 Shenzhen, Guangdong 518129 2188 P.R.China 2189 EMail: zhang.xian@huawei.com 2191 Dhruv Dhody 2192 Huawei Technology 2193 Leela Palace 2194 Bangalore, Karnataka 560008 2195 INDIA 2196 EMail: dhruv.dhody@huawei.com 2198 Siva Sivabalan 2199 Cisco Systems, Inc. 2200 2000 Innovation Drive 2201 Kanata, Ontario K2K 3E8 2202 Canada 2203 EMail: msiva@cisco.com 2205 12. Acknowledgements 2207 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 2208 Casellas for their contributions to this document. 2210 We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, 2211 Paul Schultz and Raveendra Torvi for their comments and suggestions. 2212 Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga, 2213 Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, 2214 Ambrose Kwong, Ashwin Sampath, Calvin Ying, Mustapha Aissaoui, 2215 Stephane Litkowski and Olivier Dugeon for helpful comments and 2216 discussions. 2218 13. References 2220 13.1. Normative References 2222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2223 Requirement Levels", BCP 14, RFC 2119, 2224 DOI 10.17487/RFC2119, March 1997, 2225 . 2227 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2228 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2229 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2230 September 1997, . 2232 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2233 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2234 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2235 . 2237 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 2238 Zhang, "OSPF Protocol Extensions for Path Computation 2239 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 2240 January 2008, . 2242 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 2243 Zhang, "IS-IS Protocol Extensions for Path Computation 2244 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 2245 January 2008, . 2247 [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", 2248 RFC 5284, DOI 10.17487/RFC5284, August 2008, 2249 . 2251 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 2252 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 2253 DOI 10.17487/RFC5440, March 2009, 2254 . 2256 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2257 Used to Form Encoding Rules in Various Routing Protocol 2258 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2259 2009, . 2261 13.2. Informative References 2263 [I-D.ietf-pce-gmpls-pcep-extensions] 2264 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 2265 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in 2266 progress), October 2015. 2268 [I-D.ietf-pce-stateful-pce-app] 2269 Zhang, X. and I. Minei, "Applicability of a Stateful Path 2270 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 2271 app-08 (work in progress), October 2016. 2273 [I-D.ietf-pce-stateful-sync-optimizations] 2274 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 2275 and D. Dhody, "Optimizations of Label Switched Path State 2276 Synchronization Procedures for a Stateful PCE", draft- 2277 ietf-pce-stateful-sync-optimizations-06 (work in 2278 progress), October 2016. 2280 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2281 LSP Path Computation using Preemption", Global 2282 Information Infrastructure Symposium, July 2007. 2284 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2285 programming algorithm for balancing the max-min fairness 2286 and throughput objectives in traffic engineering", 2287 INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012. 2289 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2290 McManus, "Requirements for Traffic Engineering Over MPLS", 2291 RFC 2702, DOI 10.17487/RFC2702, September 1999, 2292 . 2294 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2295 Label Switching Architecture", RFC 3031, 2296 DOI 10.17487/RFC3031, January 2001, 2297 . 2299 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2300 Christian, B., and W. Lai, "Applicability Statement for 2301 Traffic Engineering with MPLS", RFC 3346, 2302 DOI 10.17487/RFC3346, August 2002, 2303 . 2305 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2306 (TE) Extensions to OSPF Version 2", RFC 3630, 2307 DOI 10.17487/RFC3630, September 2003, 2308 . 2310 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2311 Element (PCE)-Based Architecture", RFC 4655, 2312 DOI 10.17487/RFC4655, August 2006, 2313 . 2315 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 2316 Element (PCE) Communication Protocol Generic 2317 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2318 2006, . 2320 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2321 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2322 DOI 10.17487/RFC5226, May 2008, 2323 . 2325 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2326 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2327 2008, . 2329 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2330 "Policy-Enabled Path Computation Framework", RFC 5394, 2331 DOI 10.17487/RFC5394, December 2008, 2332 . 2334 Authors' Addresses 2336 Edward Crabbe 2337 Oracle 2338 1501 4th Ave, suite 1800 2339 Seattle, WA 98101 2340 US 2342 Email: edward.crabbe@oracle.com 2343 Ina Minei 2344 Google, Inc. 2345 1600 Amphitheatre Parkway 2346 Mountain View, CA 94043 2347 US 2349 Email: inaminei@google.com 2351 Jan Medved 2352 Cisco Systems, Inc. 2353 170 West Tasman Dr. 2354 San Jose, CA 95134 2355 US 2357 Email: jmedved@cisco.com 2359 Robert Varga 2360 Pantheon Technologies SRO 2361 Mlynske Nivy 56 2362 Bratislava 821 05 2363 Slovakia 2365 Email: robert.varga@pantheon.tech