idnits 2.17.1 draft-ietf-pce-stateful-pce-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 1, 2016) is 2787 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 (-08) exists of draft-ietf-pce-stateful-pce-app-06 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-05 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 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: March 5, 2017 Google, Inc. 6 J. Medved 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 September 1, 2016 12 PCEP Extensions for Stateful PCE 13 draft-ietf-pce-stateful-pce-16 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 March 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 . . . . . . . . . 6 65 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 6 67 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6 68 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7 69 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8 71 5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 9 72 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 73 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 10 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 The following terms are defined in this document: 169 Stateful PCE: a PCE that has access to not only the network state, 170 but also to the set of active paths and their reserved resources 171 for its computations. A stateful PCE might also retain 172 information regarding LSPs under construction in order to reduce 173 churn and resource contention. The additional state allows the 174 PCE to compute constrained paths while considering individual LSPs 175 and their interactions. Note that this requires reliable state 176 synchronization mechanisms between the PCE and the network, PCE 177 and PCC, and between cooperating PCEs. 179 Passive Stateful PCE: a PCE that uses LSP state information learned 180 from PCCs to optimize path computations. It does not actively 181 update LSP state. A PCC maintains synchronization with the PCE. 183 Active Stateful PCE: a PCE that may issue recommendations to the 184 network.For example, an Active Stateful PCE may utilize the 185 Delegation mechanism to update LSP parameters in those PCCs that 186 delegated control over their LSPs to the PCE. 188 Delegation: an operation to grant a PCE temporary rights to modify a 189 subset of LSP parameters on one or more PCC's LSPs. LSPs are 190 delegated from a PCC to a PCE, and are referred to as delegated 191 LSPs. The PCC that owns the PCE state for the LSP has the right 192 to delegate it. An LSP is owned by a single PCC at any given 193 point in time. For intra-domain LSPs, this PCC should be the LSP 194 head end. 196 Revocation: an operation performed by a PCC on a previously 197 delegated LSP. Revocation revokes the rights granted to the PCE 198 in the delegation operation. 200 Redelegation Timeout Interval: the period of time a PCC waits for, 201 when a PCEP session is terminated, before revoking LSP delegation 202 to a PCE and attempting to redelegate LSPs associated with the 203 terminated PCEP session to an alternate PCE. The Redelegation 204 Timeout Interval is a PCC-local value that can be either operator- 205 configured or dynamically computed by the PCC based on local 206 policy. 208 State Timeout Interval: the period of time a PCE waits for, when a 209 PCEP session is terminated, before flushing LSP state associated 210 with that PCEP session and reverting to operator-defined default 211 parameters or behaviors. The State Timeout Interval is a PCC- 212 local value that can be either operator-configured or dynamically 213 computed by the PCC based on local policy. 215 LSP State Report: an operation to send LSP state (Operational / 216 Admin Status, LSP attributes configured at the PCC and set by a 217 PCE, etc.) from a PCC to a PCE. 219 LSP Update Request: an operation where an Active Stateful PCE 220 requests a PCC to update one or more attributes of an LSP and to 221 re-signal the LSP with updated attributes. 223 SRP-ID-number: a number used to correlate errors and LSP State 224 Reports to LSP Update Requests. It is carried in the SRP 225 (Stateful PCE Request Parameters) Object described in Section 7.2. 227 LSP State Database: information about all LSPs and their attributes. 229 Within this document, PCEP communications are described through PCC- 230 PCE relationship. The PCE architecture also supports the PCE-PCE 231 communication, by having the requesting PCE fill the role of a PCC, 232 as usual. 234 The message formats in this document are specified using Routing 235 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 237 3. Motivation and Objectives for Stateful PCE 239 3.1. Motivation 241 [I-D.ietf-pce-stateful-pce-app] presents several use cases, 242 demonstrating scenarios that benefit from the deployment of a 243 stateful PCE. The scenarios apply equally to MPLS-TE and GMPLS 244 deployments. 246 3.1.1. Background 248 Traffic engineering has been a goal of the MPLS architecture since 249 its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic 250 engineering system provided by [RFC3630], [RFC5305], and [RFC3209] 251 information about network resources utilization is only available as 252 total reserved capacity by traffic class on a per interface basis; 253 individual LSP state is available only locally on each LER for its 254 own LSPs. In most cases, this makes good sense, as distribution and 255 retention of total LSP state for all LERs within in the network would 256 be prohibitively costly. 258 Unfortunately, this visibility in terms of global LSP state may 259 result in a number of issues for some demand patterns, particularly 260 within a common setup and hold priority. This issue affects online 261 traffic engineering systems. 263 A sufficiently over-provisioned system will by definition have no 264 issues routing its demand on the shortest path. However, lowering 265 the degree to which network over-provisioning is required in order to 266 run a healthy, functioning network is a clear and explicit promise of 267 MPLS architecture. In particular, it has been a goal of MPLS to 268 provide mechanisms to alleviate congestion scenarios in which 269 "traffic streams are inefficiently mapped onto available resources; 270 causing subsets of network resources to become over-utilized while 271 others remain underutilized" ([RFC2702]). 273 3.1.2. Why a Stateful PCE? 275 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 276 "strict synchronization between the PCE and not only the network 277 states (in term of topology and resource information), but also the 278 set of computed paths and reserved resources in use in the network." 279 [RFC4655] also expressed a number of concerns with regard to a 280 stateful PCE, specifically: 282 o Any reliable synchronization mechanism would result in significant 283 control plane overhead 285 o Out-of-band TED synchronization would be complex and prone to race 286 conditions 288 o Path calculations incorporating total network state would be 289 highly complex 291 In general, stress on the control plane will be directly proportional 292 to the size of the system being controlled and the tightness of the 293 control loop, and indirectly proportional to the amount of over- 294 provisioning in terms of both network capacity and reservation 295 overhead. 297 Despite these concerns in terms of implementation complexity and 298 scalability, several TE algorithms exist today that have been 299 demonstrated to be extremely effective in large TE systems, providing 300 both rapid convergence and significant benefits in terms of 301 optimality of resource usage [MXMN-TE]. All of these systems share 302 at least two common characteristics: the requirement for both global 303 visibility of a flow (or in this case, a TE LSP) state and for 304 ordered control of path reservations across devices within the system 305 being controlled. While some approaches have been suggested in order 306 to remove the requirements for ordered control (See [MPLS-PC]), these 307 approaches are highly dependent on traffic distribution, and do not 308 allow for multiple simultaneous LSP priorities representing diffserv 309 classes. 311 The use cases described in [I-D.ietf-pce-stateful-pce-app] 312 demonstrate a need for visibility into global inter-PCC LSP state in 313 PCE path computations, and for PCE control of sequence and timing in 314 altering LSP path characteristics within and across PCEP sessions. 316 3.1.3. Protocol vs. Configuration 318 Note that existing configuration tools and protocols can be used to 319 set LSP state. However, this solution has several shortcomings: 321 o Scale & Performance: configuration operations often have 322 transactional semantics which are typically heavyweight and often 323 require processing of additional configuration portions beyond the 324 state being directly acted upon, with corresponding cost in CPU 325 cycles, negatively impacting both PCC stability LSP update rate 326 capacity. 328 o Security: when a PCC opens a configuration channel allowing a PCE 329 to send configuration, a malicious PCE may take advantage of this 330 ability to take over the PCC. In contrast, the PCEP extensions 331 described in this document only allow a PCE control over a very 332 limited set of LSP attributes. 334 o Interoperability: each vendor has a proprietary information model 335 for configuring LSP state, which limits interoperability of a 336 stateful PCE with PCCs from different vendors. The PCEP 337 extensions described in this document allow for a common 338 information model for LSP state for all vendors. 340 o Efficient State Synchronization: configuration channels may be 341 heavyweight and unidirectional, therefore efficient state 342 synchronization between a PCC and a PCE may be a problem. 344 3.2. Objectives 346 The objectives for the protocol extensions to support stateful PCE 347 described in this document are as follows: 349 o Allow a single PCC to interact with a mix of stateless and 350 stateful PCEs simultaneously using the same protocol, i.e. PCEP. 352 o Support efficient LSP state synchronization between the PCC and 353 one or more active or passive stateful PCEs. 355 o Allow a PCC to delegate control of its LSPs to an active stateful 356 PCE such that a given LSP is under the control of a single PCE at 357 any given time. A PCC may revoke this delegation at any time 358 during the lifetime of the LSP. If LSP delegation is revoked 359 while the PCEP session is up, the PCC MUST notify the PCE about 360 the revocation. A PCE may return an LSP delegation at any point 361 during the lifetime of the PCEP session. 363 o Allow a PCE to control computation timing and update timing across 364 all LSPs that have been delegated to it. 366 o Enable uninterrupted operation of PCC's LSPs in the event of a PCE 367 failure or while control of LSPs is being transferred between 368 PCEs. 370 4. New Functions to Support Stateful PCEs 372 Several new functions are required in PCEP to support stateful PCEs. 373 A function can be initiated either from a PCC towards a PCE (C-E) or 374 from a PCE towards a PCC (E-C). The new functions are: 376 Capability advertisement (E-C,C-E): both the PCC and the PCE must 377 announce during PCEP session establishment that they support PCEP 378 Stateful PCE extensions defined in this document. 380 LSP state synchronization (C-E): after the session between the PCC 381 and a stateful PCE is initialized, the PCE must learn the state of 382 a PCC's LSPs before it can perform path computations or update LSP 383 attributes in a PCC. 385 LSP Update Request (E-C): a PCE requests modification of attributes 386 on a PCC's LSP. 388 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 389 whenever the state of an LSP changes. 391 LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 392 update LSP attributes on one or more LSPs; the PCE becomes the 393 authoritative source of the LSP's attributes as long as the 394 delegation is in effect (See Section 5.7); the PCC may withdraw 395 the delegation or the PCE may give up the delegation at any time. 397 Similarly to [RFC5440], no assumption is made about the discovery 398 method used by a PCC to discover a set of PCEs (e.g., via static 399 configuration or dynamic discovery) and on the algorithm used to 400 select a PCE. 402 5. Overview of Protocol Extensions 404 5.1. LSP State Ownership 406 In PCEP (defined in [RFC5440]), LSP state and operation are under the 407 control of a PCC (a PCC may be an LSR or a management station). 408 Attributes received from a PCE are subject to PCC's local policy. 409 The PCEP extensions described in this document do not change this 410 behavior. 412 An active stateful PCE may have control of a PCC's LSPs that were 413 delegated to it, but the LSP state ownership is retained by the PCC. 414 In particular, in addition to specifying values for LSP's attributes, 415 an active stateful PCE also decides when to make LSP modifications. 417 Retaining LSP state ownership on the PCC allows for: 419 o a PCC to interact with both stateless and stateful PCEs at the 420 same time 422 o a stateful PCE to only modify a small subset of LSP parameters, 423 i.e. to set only a small subset of the overall LSP state; other 424 parameters may be set by the operator, for example through command 425 line interface (CLI) commands 427 o a PCC to revert delegated LSP to an operator-defined default or to 428 delegate the LSPs to a different PCE, if the PCC get disconnected 429 from a PCE with currently delegated LSPs 431 5.2. New Messages 433 In this document, we define the following new PCEP messages: 435 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 436 to a PCE to report the status of one or more LSPs. Each LSP 437 Status Report in a PCRpt message MAY contain the actual LSP's 438 path, bandwidth, operational and administrative status, etc. An 439 LSP Status Report carried on a PCRpt message is also used in 440 delegation or revocation of control of an LSP to/from a PCE. The 441 PCRpt message is described in Section 6.1. 443 Path Computation Update Request (PCUpd): a PCEP message sent by a 444 PCE to a PCC to update LSP parameters, on one or more LSPs. Each 445 LSP Update Request on a PCUpd message MUST contain all LSP 446 parameters that a PCE wishes to be set for a given LSP. An LSP 447 Update Request carried on a PCUpd message is also used to return 448 LSP delegations if at any point PCE no longer desires control of 449 an LSP. The PCUpd message is described in Section 6.2. 451 The new functions defined in Section 4 are mapped onto the new 452 messages as shown in the following table. 454 +----------------------------------------+--------------+ 455 | Function | Message | 456 +----------------------------------------+--------------+ 457 | Capability Advertisement (E-C,C-E) | Open | 458 | State Synchronization (C-E) | PCRpt | 459 | LSP State Report (C-E) | PCRpt | 460 | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | 461 | LSP Update Request (E-C) | PCUpd | 462 +----------------------------------------+--------------+ 464 Table 1: New Function to Message Mapping 466 5.3. Error Reporting 468 Error reporting is done using the procedures defined in [RFC5440], 469 and reusing the applicable error types and error values of [RFC5440] 470 wherever appropriate. The current document defines new error values 471 for several error types to cover failures specific to stateful PCE. 473 5.4. Capability Advertisement 475 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 476 advertise their support of stateful PCEP extensions. A PCEP Speaker 477 includes the "Stateful PCE Capability" TLV, described in 478 Section 7.1.1, in the OPEN Object to advertise its support for PCEP 479 stateful extensions. The Stateful Capability TLV includes the 'LSP 480 Update' Flag that indicates whether the PCEP Speaker supports LSP 481 parameter updates. 483 The presence of the Stateful PCE Capability TLV in PCC's OPEN Object 484 indicates that the PCC is willing to send LSP State Reports whenever 485 LSP parameters or operational status changes. 487 The presence of the Stateful PCE Capability TLV in PCE's OPEN message 488 indicates that the PCE is interested in receiving LSP State Reports 489 whenever LSP parameters or operational status changes. 491 The PCEP extensions for stateful PCEs MUST NOT be used if one or both 492 PCEP Speakers have not included the Stateful PCE Capability TLV in 493 their respective OPEN message. If the PCEP Speaker on the PCC 494 supports the extensions of this draft but did not advertise this 495 capability, then upon receipt of PCUpd message from the PCE, it MUST 496 generate a PCErr with error-type 19 (Invalid Operation), error-value 497 2 (Attempted LSP Update Request if the stateful PCE capability was 498 not advertised)(see Section 8.5) and it SHOULD terminate the PCEP 499 session. If the PCEP Speaker on the PCE supports the extensions of 500 this draft but did not advertise this capability, then upon receipt 501 of a PCRpt message from the PCC, it MUST generate a PCErr with error- 502 type 19 (Invalid Operation), error-value 5 (Attempted LSP State 503 Report if active stateful PCE capability was not advertised) (see 504 Section 8.5) and it SHOULD terminate the PCEP session. 506 LSP delegation and LSP update operations defined in this document may 507 only be used if both PCEP Speakers set the LSP-UPDATE Flag in the 508 "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this 509 is not the case and LSP delegation or LSP update operations are 510 attempted, then a PCErr with error-type 19 (Invalid Operation) and 511 error-value 1 (Attempted LSP Update Request for a non-delegated LSP) 512 (see Section 8.5) MUST be generated. Note that even if the update 513 capability has not been advertised, a PCE can still accept LSP Status 514 Reports from a PCC and build and maintain an up to date view of the 515 state of the PCC's LSPs. 517 5.5. IGP Extensions for Stateful PCE Capabilities Advertisement 519 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 520 are either LSRs or servers also participating in the IGP, an 521 effective mechanism for PCE discovery within an IGP routing domain 522 consists of utilizing IGP advertisements. Extensions for the 523 advertisement of PCE Discovery Information are defined for OSPF and 524 for IS-IS in [RFC5088] and [RFC5089] respectively. 526 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 527 TLV used to advertise PCE capabilities. It MAY be present within the 528 PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] 529 provide the description and processing rules for this sub-TLV when 530 carried within OSPF and IS-IS, respectively. 532 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 533 reference: 535 Type: 5 537 Length: Multiple of 4. 539 Value: This contains an array of units of 32 bit flags with the most 540 significant bit as 0. Each bit represents one PCE capability. 542 PCE capability bits are defined in [RFC5088]. This document defines 543 new capability bits for the stateful PCE as follows: 545 Bit Capability 546 TBD Active Stateful PCE capability 547 TBD Passive Stateful PCE capability 549 Note that while active and passive stateful PCE capabilities may be 550 advertised during discovery, PCEP Speakers that wish to use stateful 551 PCEP MUST negotiate stateful PCEP capabilities during PCEP session 552 setup, as specified in the current document. A PCC MAY initiate 553 stateful PCEP capability negotiation at PCEP session setup even if it 554 did not receive any IGP PCE capability advertisements. 556 5.6. State Synchronization 558 The purpose of State Synchronization is to provide a checkpoint-in- 559 time state replica of a PCC's LSP state in a PCE. State 560 Synchronization is performed immediately after the Initialization 561 phase ([RFC5440]). 563 During State Synchronization, a PCC first takes a snapshot of the 564 state of its LSPs state, then sends the snapshot to a PCE in a 565 sequence of LSP State Reports. Each LSP State Report sent during 566 State Synchronization has the SYNC Flag in the LSP Object set to 1. 567 The set of LSPs for which state is synchronized with a PCE is 568 determined by advertised stateful PCEP capabilities and PCC's local 569 configuration (see more details in Section 9.1). 571 The end of synchronization marker is a PCRpt message with the SYNC 572 Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved 573 value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT 574 include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- 575 IDENTIFIERS TLV with the special value of all zeroes. The PCRpt 576 message MUST include an empty ERO as its intended path and SHOULD NOT 577 include the optional RRO object for its actual path. If the PCC has 578 no state to synchronize, it SHOULD only send the end of 579 synchronization marker. 581 A PCE SHOULD NOT send PCUpd messages to a PCC before State 582 Synchronization is complete. A PCC SHOULD NOT send PCReq messages to 583 a PCE before State Synchronization is complete. This is to allow the 584 PCE to get the best possible view of the network before it starts 585 computing new paths. 587 Either the PCE or the PCC MAY terminate the session using the PCEP 588 session termination procedures during the synchronization phase. If 589 the session is terminated, the PCE MUST clean up state it received 590 from this PCC. The session reestablishment MUST be re-attempted per 591 the procedures defined in [RFC5440], including use of a back-off 592 timer. 594 If the PCC encounters a problem which prevents it from completing the 595 state transfer, it MUST send a PCErr message with error-type 20 (LSP 596 State Synchronization Error) and error-value 5 (indicating an 597 internal PCC error) to the PCE and terminate the session. 599 The PCE does not send positive acknowledgements for properly received 600 synchronization messages. It MUST respond with a PCErr message with 601 error-type 20 (LSP State Synchronization Error) and error-value 1 602 (indicating an error in processing the PCRpt) (see Section 8.5) if it 603 encounters a problem with the LSP State Report it received from the 604 PCC and it MUST terminate the session. 606 A PCE implementing a limit on the resources a single PCC can occupy, 607 MUST send a PCNtf message with Notification Type to be allocated by 608 IANA (Stateful PCE resource limit exceeded) and Notification Value to 609 be allocated by IANA (Entering resource limit exceeded state) in 610 response to the PCRpt message triggering this condition in the 611 synchronization phase and MUST terminate the session. 613 The successful State Synchronization sequence is shown in Figure 1. 615 +-+-+ +-+-+ 616 |PCC| |PCE| 617 +-+-+ +-+-+ 618 | | 619 |-----PCRpt, SYNC=1----->| (Sync start) 620 | | 621 |-----PCRpt, SYNC=1----->| 622 | . | 623 | . | 624 | . | 625 |-----PCRpt, SYNC=1----->| 626 | . | 627 | . | 628 | . | 629 | | 630 |-----PCRpt, SYNC=0----->| (End of sync marker 631 | | LSP State Report 632 | | for PLSP-ID=0) 633 | | (Sync done) 635 Figure 1: Successful state synchronization 637 The sequence where the PCE fails during the State Synchronization 638 phase is shown in Figure 2. 640 +-+-+ +-+-+ 641 |PCC| |PCE| 642 +-+-+ +-+-+ 643 | | 644 |-----PCRpt, SYNC=1----->| 645 | | 646 |-----PCRpt, SYNC=1----->| 647 | . | 648 | . | 649 | . | 650 |-----PCRpt, SYNC=1----->| 651 | | 652 |-PCRpt, SYNC=1 | 653 | \ ,-PCErr | 654 | \ / | 655 | \/ | 656 | /\ | 657 | / `-------->| (Ignored) 658 |<--------` | 660 Figure 2: Failed state synchronization (PCE failure) 662 The sequence where the PCC fails during the State Synchronization 663 phase is shown in Figure 3. 665 +-+-+ +-+-+ 666 |PCC| |PCE| 667 +-+-+ +-+-+ 668 | | 669 |-----PCRpt, SYNC=1----->| 670 | | 671 |-----PCRpt, SYNC=1----->| 672 | . | 673 | . | 674 | . | 675 |-------- PCErr=? ------>| 676 | | 678 Figure 3: Failed state synchronization (PCC failure) 680 Optimizations to the synchronization procedures and alternate 681 mechanisms of providing the synchronization function are outside the 682 scope of this document and are discussed elsewhere (see 683 [I-D.ietf-pce-stateful-sync-optimizations]). 685 5.7. LSP Delegation 687 If during Capability advertisement both the PCE and the PCC have 688 indicated that they support LSP Update, then the PCC may choose to 689 grant the PCE a temporary right to update (a subset of) LSP 690 attributes on one or more LSPs. This is called "LSP Delegation", and 691 it MAY be performed at any time after the Initialization phase, 692 including during the State Synchronization phase. 694 A PCE MAY return an LSP delegation at any time if it no longer wishes 695 to update the LSP's state. A PCC MAY revoke an LSP delegation at any 696 time. Delegation, Revocation, and Return are done individually for 697 each LSP. 699 In the event of a delegation being rejected or returned by a PCE, the 700 PCC SHOULD react based on local policy. It can, for example, either 701 retry delegating to the same PCE using an exponentially increasing 702 timer or delegate to an alternate PCE. 704 5.7.1. Delegating an LSP 706 A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP 707 State Report to 1. If the PCE does not accept the LSP Delegation, it 708 MUST immediately respond with an empty LSP Update Request which has 709 the Delegate flag set to 0. If the PCE accepts the LSP Delegation, 710 it MUST set the Delegate flag to 1 when it sends an LSP Update 711 Request for the delegated LSP (note that this may occur at a later 712 time). The PCE MAY also immediately acknowledge a delegation by 713 sending an empty LSP Update Request which has the Delegate flag set 714 to 1. 716 The delegation sequence is shown in Figure 4. 718 +-+-+ +-+-+ 719 |PCC| |PCE| 720 +-+-+ +-+-+ 721 | | 722 |---PCRpt, Delegate=1--->| LSP Delegated 723 | | 724 |---PCRpt, Delegate=1--->| 725 | . | 726 | . | 727 | . | 728 |<--(PCUpd,Delegate=1)---| Delegation confirmed 729 | | 730 |---PCRpt, Delegate=1--->| 731 | | 733 Figure 4: Delegating an LSP 735 Note that for an LSP to remain delegated to a PCE, the PCC MUST set 736 the Delegate flag to 1 on each LSP Status Report sent to the PCE. 738 5.7.2. Revoking a Delegation 740 5.7.2.1. Explicit Revocation 742 When a PCC decides that a PCE is no longer permitted to modify an 743 LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke 744 an LSP delegation at any time during the LSP's life time. A PCC 745 revoking an LSP delegation MAY immediately clear the LSP state 746 provided by the PCE, but to avoid traffic loss, it SHOULD do so in a 747 make-before-break fashion. If the PCC has received but not yet acted 748 on PCUpd messages from the PCE for the LSP whose delegation is being 749 revoked, then it SHOULD ignore these PCUpd messages when processing 750 the message queue. All effects of all messages for which processing 751 started before the revocation took place MUST be allowed to complete 752 and the result MUST be given the same treatment as any LSP that had 753 been previously delegated to the PCE (e.g. the state MAY be 754 immediately cleared). Any further PCUpd messages from the PCE are 755 handled according to the PCUpd procedures described in this document. 757 If a PCEP session with the PCE to which the LSP is delegated exists 758 in the UP state during the revocation, the PCC MUST notify that PCE 759 by sending an LSP State Report with the Delegate flag set to 0, as 760 shown in Figure 5. 762 +-+-+ +-+-+ 763 |PCC| |PCE| 764 +-+-+ +-+-+ 765 | | 766 |---PCRpt, Delegate=1--->| 767 | | 768 |<--(PCUpd,Delegate=1)---| Delegation confirmed 769 | . | 770 | . | 771 | . | 772 |---PCRpt, Delegate=0--->| PCC revokes delegation 773 | | 775 Figure 5: Revoking a Delegation 777 After an LSP delegation has been revoked, a PCE can no longer update 778 LSP's parameters; an attempt to update parameters of a non-delegated 779 LSP will result in the PCC sending a PCErr message with error-type 19 780 (Invalid Operation), error-value 1 (attempted LSP Update Request for 781 a non-delegated LSP) (see Section 8.5). 783 5.7.2.2. Revocation on Redelegation Timeout 785 When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC 786 MUST wait the time interval specified in Redelegation Timeout 787 Interval before revoking LSP delegations to that PCE and attempting 788 to redelegate LSPs to an alternate PCE. If a PCEP session with the 789 original PCE can be reestablished before the Redelegation Timeout 790 Interval timer expires, LSP delegations to the PCE remain intact. 792 Likewise, when a PCC's PCEP session with a PCE terminates 793 unexpectedly, the PCC MUST wait for the State Timeout Interval before 794 flushing any LSP state associated with that PCE. Note that the State 795 Timeout Interval timer may expire before the PCC has redelegated the 796 LSPs to another PCE, for example if a PCC is not connected to any 797 active stateful PCE or if no connected active stateful PCE accepts 798 the delegation. In this case, the PCC MUST flush any LSP state set 799 by the PCE upon expiration of the State Timeout Interval and revert 800 to operator-defined default parameters or behaviors. This operation 801 SHOULD be done in a make-before-break fashion. 803 The State Timeout Interval MUST be greater than or equal to the 804 Redelegation Timeout Interval and MAY be set to infinity (meaning 805 that until the PCC specifically takes action to change the parameters 806 set by the PCE, they will remain intact). 808 5.7.3. Returning a Delegation 810 In order to keep a delegation, a PCE MUST set the Delegate flag to 1 811 on each LSP Update Request sent to the PCC. A PCE that no longer 812 wishes to update an LSP's parameters SHOULD return the LSP delegation 813 back to the PCC by sending an empty LSP Update Request which has the 814 Delegate flag set to 0. If a PCC receives a non-empty LSP Update 815 Request with the Delegate flag set to 0, it MUST treat this as a 816 delegation return. 818 +-+-+ +-+-+ 819 |PCC| |PCE| 820 +-+-+ +-+-+ 821 | | 822 |---PCRpt, Delegate=1--->| LSP delegated 823 | . | 824 | . | 825 | . | 826 |<--PCUpd, Delegate=0----| Delegation returned 827 | | 828 |---PCRpt, Delegate=0--->| No delegation for LSP 829 | | 831 Figure 6: Returning a Delegation 833 If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is 834 not connected to any active stateful PCE or if no connected active 835 stateful PCE accepts the delegation), the LSP delegation on the PCC 836 will time out within a configurable Redelegation Timeout Interval and 837 the PCC MUST flush any LSP state set by a PCE at the expiration of 838 the State Timeout Interval. 840 5.7.4. Redundant Stateful PCEs 842 In a redundant configuration where one PCE is backing up another PCE, 843 the backup PCE may have only a subset of the LSPs in the network 844 delegated to it. The backup PCE does not update any LSPs that are 845 not delegated to it. In order to allow the backup to operate in a 846 hot-standby mode and avoid the need for state synchronization in case 847 the primary fails, the backup receives all LSP State Reports from a 848 PCC. When the primary PCE for a given LSP set fails, after expiry of 849 the Redelegation Timeout Interval, the PCC SHOULD delegate to the 850 redundant PCE all LSPs that had been previously delegated to the 851 failed PCE. Assuming that the State Timeout Interval had been 852 configured to be greater than the Redelegation Timeout Interval (as 853 MANDATORY), and assuming that the primary and redundant PCEs take 854 similar decisions, this delegation change will not cause any changes 855 to the LSP parameters. 857 5.7.5. Redelegation on PCE Failure 859 On failure, the goal is to: 1) avoid any traffic loss on the LSPs 860 that were updated by the PCE that crashed 2) minimize the churn in 861 the network in terms of ownership of the LSPs, 3) not leave any 862 "orphan" (undelegated) LSPs and 4) be able to control when the state 863 that was set by the PCE can be changed or purged. The values chosen 864 for the Redelegation Timeout and State Timeout values affect the 865 ability to accomplish these goals. 867 This section summarizes the behaviour with regards to LSP delegation 868 and LSP state on a PCE failure. 870 If the PCE crashes but recovers within the Redelegation Timeout, both 871 the delegation state and the LSP state are kept intact. 873 If the PCE crashes but does not recover within the Redelegation 874 Timeout, the delegation state is returned to the PCC. If the PCC can 875 redelegate the LSPs to another PCE, and that PCE accepts the 876 delegations, there will be no change in LSP state. If the PCC cannot 877 redelegate the LSPs to another PCE, then upon expiration of the State 878 Timeout Interval, the state set by the PCE is flushed, which may 879 cause change in the LSP state. Note that an operator may choose to 880 use an infinite State Timeout Interval if he wishes to maintain the 881 PCE state indefinetely. Note also that flushing the state should be 882 implemented using make-before-break to avoid traffic loss. 884 If there is a standby PCE, the Redelegation Timeout may be set to 0 885 through policy on the PCC, causing the LSPs to be redelegated 886 immediately to the PCC, which can delegate them immediately to the 887 standby PCE. Assuming the State Timeout Interval is greater than the 888 Redelegation Timeout, and assuming the standby PCE takes similar 889 decisions as the failed PCE, the LSP state will be kept intact. 891 5.8. LSP Operations 893 5.8.1. Passive Stateful PCE Path Computation Request/Response 894 +-+-+ +-+-+ 895 |PCC| |PCE| 896 +-+-+ +-+-+ 897 | | 898 1) Path computation |----- PCReq message --->| 899 request sent to | |2) Path computation 900 PCE | | request received, 901 | | path computed 902 | | 903 |<---- PCRep message ----|3) Computed paths 904 | (Positive reply) | sent to the PCC 905 | (Negative reply) | 906 4) LSP Status change| | 907 event | | 908 | | 909 5) LSP Status Report|----- PCRpt message --->| 910 sent to all | . | 911 stateful PCEs | . | 912 | . | 913 6) Repeat for each |----- PCRpt message --->| 914 LSP status change| | 915 | | 917 Figure 7: Passive Stateful PCE Path Computation Request/Response 919 Once a PCC has successfully established a PCEP session with a passive 920 stateful PCE and the PCC's LSP state is synchronized with the PCE 921 (i.e. the PCE knows about all PCC's existing LSPs), if an event is 922 triggered that requires the computation of a set of paths, the PCC 923 sends a path computation request to the PCE ([RFC5440], 924 Section 4.2.3). The PCReq message MAY contain the LSP Object to 925 identify the LSP for which the path computation is requested. 927 Upon receiving a path computation request from a PCC, the PCE 928 triggers a path computation and returns either a positive or a 929 negative reply to the PCC ([RFC5440], Section 4.2.4). 931 Upon receiving a positive path computation reply, the PCC receives a 932 set of computed paths and starts to setup the LSPs. For each LSP, it 933 MAY send an LSP State Report carried on a PCRpt message to the PCE, 934 indicating that the LSP's status is "Going-up". 936 Once an LSP is up or active, the PCC MUST send an LSP State Report 937 carried on a PCRpt message to the PCE, indicating that the LSP's 938 status is 'Up' or 'Active' respectively. If the LSP could not be set 939 up, the PCC MUST send an LSP State Report indicating that the LSP is 940 "Down' and stating the cause of the failure. Note that due to timing 941 constraints, the LSP status may change from 'Going-up' to 'Up' (or 942 'Down') before the PCC has had a chance to send an LSP State Report 943 indicating that the status is 'Going-up'. In such cases, the PCC MAY 944 choose to only send the PCRpt indicating the latest status ('Active', 945 'Up' or 'Down'). 947 Upon receiving a negative reply from a PCE, a PCC MAY resend a 948 modified request or take any other appropriate action. For each 949 requested LSP, it SHOULD also send an LSP State Report carried on a 950 PCRpt message to the PCE, indicating that the LSP's status is 'Down'. 952 There is no direct correlation between PCRep and PCRpt messages. For 953 a given LSP, multiple LSP State Reports will follow a single PCRep 954 message, as a PCC notifies a PCE of the LSP's state changes. 956 A PCC MUST send each LSP State Report to each stateful PCE that is 957 connected to the PCC. 959 Note that a single PCRpt message MAY contain multiple LSP State 960 Reports. 962 The passive stateful PCE is the model for stateful PCEs is described 963 in [RFC4655], Section 6.8. 965 5.8.2. Switching from Passive Stateful to Active Stateful 967 This section deals with the scenario of an LSP transitioning from a 968 passive stateful to an active stateful mode of operation. When the 969 LSP has no working path, prior to delegating the LSP, the PCC MUST 970 first use the procedure defined in Section 5.8.1 to request the 971 initial path from the PCE. This is required because the action of 972 delegating the LSP to a PCE using a PCRpt message is not an explicit 973 request to the PCE to compute a path for the LSP. The only explicit 974 way for a PCC to request a path from PCE is to send a PCReq message. 975 The PCRpt message MUST NOT be used by the PCC to attempt to request a 976 path from the PCE. 978 When the LSP is delegated after its setup, it may be useful for the 979 PCC to communicate to the PCE the locally configured intended 980 configuration parameters, so that the PCE may reuse them in its 981 computations. Such parameters MAY be acquired through an out of band 982 channel, or MAY be communicated in the PCRpt message delegating the 983 LSPs, by including them as part of the intented-attribute-list as 984 explained in Section 6.1. An implementation MAY allow policies on 985 the PCC to determine the configuration parameters to be sent to the 986 PCE. 988 5.8.3. Active Stateful PCE LSP Update 990 +-+-+ +-+-+ 991 |PCC| |PCE| 992 +-+-+ +-+-+ 993 | | 994 1) LSP State |-- PCRpt, Delegate=1 -->| 995 Synchronization | . | 996 | . |2) PCE decides to 997 | . | update the LSP 998 | | 999 |<---- PCUpd message ----|3) PCUpd message sent 1000 | | to PCC 1001 | | 1002 | | 1003 4) LSP Status Report|---- PCRpt message ---->| 1004 sent(->Going-up) | . | 1005 | . | 1006 | . | 1007 5) LSP Status Report|---- PCRpt message ---->| 1008 sent (->Up|Down) | | 1009 | | 1011 Figure 8: Active Stateful PCE 1013 Once a PCC has successfully established a PCEP session with an active 1014 stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. 1015 the PCE knows about all PCC's existing LSPs). After LSPs have been 1016 delegated to the PCE, the PCE can modify LSP parameters of delegated 1017 LSPs. 1019 To update an LSP, a PCE MUST send the PCC an LSP Update Request using 1020 a PCUpd message. The LSP Update Request contains a variety of 1021 objects that specify the set of constraints and attributes for the 1022 LSP's path. Each LSP Update Request MUST have a unique identifier, 1023 the SRP-ID-number, carried in the SRP (Stateful PCE Request 1024 Parameters) Object described in Section 7.2. The SRP-ID-number is 1025 used to correlate errors and state reports to LSP Update Requests. A 1026 single PCUpd message MAY contain multiple LSP Update Requests. 1028 Upon receiving a PCUpd message the PCC starts to setup LSPs specified 1029 in LSP Update Requests carried in the message. For each LSP, it MAY 1030 send an LSP State Report carried on a PCRpt message to the PCE, 1031 indicating that the LSP's status is 'Going-up'. If the PCC decides 1032 that the LSP parameters proposed in the PCUpd message are 1033 unacceptable, it MUST report this error by including the LSP-ERROR- 1034 CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable 1035 parameters" in the LSP object in the PCRpt message to the PCE. Based 1036 on local policy, it MAY react further to this error by revoking the 1037 delegation. If the PCC receives a PCUpd message for an LSP object 1038 identified with a PLSP-ID that does not exist on the PCC, it MUST 1039 generate a PCErr with error-type 19 (Invalid Operation), error-value 1040 3, (Attempted LSP Update Request for an LSP identified by an unknown 1041 PSP-ID) (see Section 8.5). 1043 Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt 1044 message) to the PCE, indicating that the LSP's status is 'Up'. If 1045 the LSP could not be set up, the PCC MUST send an LSP State Report 1046 indicating that the LSP is 'Down' and stating the cause of the 1047 failure. A PCC MAY compress LSP State Reports to only reflect the 1048 most up to date state, as discussed in the previous section. 1050 A PCC MUST send each LSP State Report to each stateful PCE that is 1051 connected to the PCC. 1053 PCErr and PCRpt messages triggered as a result of a PCUpd message 1054 MUST include the SRP-ID-number from the PCUpd. This provides 1055 correlation of requests and errors and acknowledgement of state 1056 processing. The PCC MAY compress state when processing PCUpd. In 1057 this case, receipt of a higher SRP-ID-number implicitly acknowledges 1058 processing all the updates with lower SRP-ID-number for the specific 1059 LSP (as per Section 7.2). 1061 A PCC MUST NOT send to any PCE a Path Computation Request for a 1062 delegated LSP. Should the PCC decide it wants to issue a Path 1063 Computation Request on a delegated LSP, it MUST perform Delegation 1064 Revocation procedure first. 1066 5.9. LSP Protection 1068 LSP protection and interaction with stateful PCE, as well as the 1069 extensions necessary to implement this functionality will be 1070 discussed in a separate document. 1072 5.10. PCEP Sessions 1074 A permanent PCEP session MUST be established between a stateful PCE 1075 and the PCC. In the case of session failure, session reestablishment 1076 MUST be re-attempted per the procedures defined in [RFC5440]. 1078 6. PCEP Messages 1080 As defined in [RFC5440], a PCEP message consists of a common header 1081 followed by a variable-length body made of a set of objects. For 1082 each PCEP message type, a set of rules is defined that specify the 1083 set of objects that the message can carry. 1085 6.1. The PCRpt Message 1087 A Path Computation LSP State Report message (also referred to as 1088 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 1089 current state of an LSP. A PCRpt message can carry more than one LSP 1090 State Reports. A PCC can send an LSP State Report either in response 1091 to an LSP Update Request from a PCE, or asynchronously when the state 1092 of an LSP changes. The Message-Type field of the PCEP common header 1093 for the PCRpt message is to be assigned by IANA. 1095 The format of the PCRpt message is as follows: 1097 ::= 1098 1099 Where: 1101 ::= [] 1103 ::= [] 1104 1105 1106 Where: 1107 ::= 1108 [] 1109 1111 ::=[] 1112 [] 1114 Where: 1115 is represented by the ERO object defined in 1116 section 7.9 of [RFC5440]. 1117 consists of the actual computed and signaled values 1118 of the and objects defined in [RFC5440]. 1119 is represented by the RRO object defined in 1120 section 7.10 of [RFC5440]. 1121 is the attribute-list defined in 1122 section 6.5 of [RFC5440] and extended by PCEP extensions. 1124 The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message 1125 is not in response to a PCupd message, the SRP object MAY be omitted. 1126 When the PCC does not include the SRP object, the PCE MUST treat this 1127 as an SRP object with an SRP-ID-number equal to the reserved value 1128 0x00000000. The reserved value 0x00000000 indicates that the state 1129 reported is not as a result of processing a PCUpd message. 1131 If the PCRpt message is in response to a PCUpd message, the SRP 1132 object MUST be included and the value of the SRP-ID-number in the SRP 1133 Object MUST be the same as that sent in the PCUpd message that 1134 triggered the state that is reported. If the PCC compressed several 1135 PCUpd messages for the same LSP by only processing the one with the 1136 highest number, then it should use the SRP-ID-number of that request. 1137 No state compression is allowed for state reporting, e.g. PCRpt 1138 messages MUST NOT be pruned from the PCC's egress queue even if 1139 subsequent operations on the same LSP have been completed before the 1140 PCRpt message has been sent to the TCP stack. The PCC MUST 1141 explicitly report state changes (including removal) for paths it 1142 manages. 1144 The LSP object (see Section 7.3) is REQUIRED, and it MUST be included 1145 in each LSP State Report on the PCRpt message. If the LSP object is 1146 missing, the receiving PCE MUST send a PCErr message with Error- 1147 type=6 (Mandatory Object missing) and Error-value to be assigned by 1148 IANA (LSP object missing). 1150 If the LSP transitioned to non-operational state, the PCC SHOULD 1151 include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error 1152 Code to report the error to the PCE. 1154 The intended path, represented by the ERO object, is REQUIRED. If 1155 the ERO ojbect is missing, the receiving PCE MUST send a PCErr 1156 message with Error-type=6 (Mandatory Object missing) and Error-value 1157 to be assigned by IANA (ERO object missing). The ERO may be empty if 1158 the PCE does not have a path for a delegated LSP. 1160 The actual path, represented by the RRO object, SHOULD be included in 1161 PCRpt by the PCC when the path is up or active, but MAY be omitted if 1162 the path is down due to a signaling error or another failure. 1164 The intended_attribute_list maps to the attribute_list in Section 6.5 1165 of [RFC5440] and is used to convey the requested parameters of the 1166 LSP path. This is needed in order to support the switch from passive 1167 to active stateful PCE as described in Section 5.8.2. When included 1168 as part of the intended_attribute_list, the meaning of the BANDWIDTH 1169 object is the requested bandwidth as intended by the operator. In 1170 this case, the BANDWIDTH Object-Type of 1 SHOULD be used. Similarly, 1171 to indicate a limiting constraint, the METRIC object SHOULD be 1172 included as part of the intended_attribute_list with the B flag set 1173 and with a specific metric value. To indicate the optimization 1174 metric, the METRIC object SHOULD be included as part of the 1175 intended_attribute_list with the B flag unset and the metric value 1176 set to zero. Note that the intended_attribute_list is optional and 1177 thus may be omitted. In this case, the PCE MAY use the values in the 1178 actual_attribute_list as the requested parameters for the path. 1180 The actual_attribute_list consists of the actual computed and 1181 signaled values of the BANDWIDTH and METRIC objects defined in 1182 [RFC5440]. When included as part of the actual_attribute_list, 1183 Object-Type 2 ([RFC5440]) SHOULD be used for the BANDWIDTH object and 1184 the C flag SHOULD be set in the METRIC object ([RFC5440]). 1186 A PCE may choose to implement a limit on the resources a single PCC 1187 can occupy. If a PCRpt is received that causes the PCE to exceed 1188 this limit, the PCE MUST notify the PCC using a PCNtf message with 1189 Notification Type to be allocated by IANA (Stateful PCE resource 1190 limit exceeded) and Notification Value to be allocated by IANA 1191 (Entering resource limit exceeded state) and MAY terminate the 1192 session. 1194 6.2. The PCUpd Message 1196 A Path Computation LSP Update Request message (also referred to as 1197 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 1198 attributes of an LSP. A PCUpd message can carry more than one LSP 1199 Update Request. The Message-Type field of the PCEP common header for 1200 the PCUpd message is to be assigned by IANA. 1202 The format of a PCUpd message is as follows: 1204 ::= 1205 1206 Where: 1208 ::= [] 1210 ::= 1211 1212 1213 Where: 1214 ::= 1216 Where: 1217 is represented by the ERO object defined in 1218 section 7.9 of [RFC5440]. 1219 is defined in [RFC5440] and extended by 1220 PCEP extensions. 1222 There are three mandatory objects that MUST be included within each 1223 LSP Update Request in the PCUpd message: the SRP Object (see 1224 Section 7.2), the LSP object (see Section 7.3) and the ERO object (as 1225 defined in [RFC5440], which represents the intended path. If the SRP 1226 object is missing, the receiving PCC MUST send a PCErr message with 1227 Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP 1228 object missing). If the LSP object is missing, the receiving PCC 1229 MUST send a PCErr message with Error-type=6 (Mandatory Object 1230 missing) and Error-value=8 (LSP object missing). If the ERO object 1231 is missing, the receiving PCC MUST send a PCErr message with Error- 1232 type=6 (Mandatory Object missing) and Error-value=9 (ERO object 1233 missing). 1235 A PCC only acts on an LSP Update Request if permitted by the local 1236 policy configured by the network manager. Each LSP Update Request 1237 that the PCC acts on results in an LSP setup operation. An LSP 1238 Update Request MUST contain all LSP parameters that a PCE wishes to 1239 be set for the LSP. A PCC MAY set missing parameters from locally 1240 configured defaults. If the LSP specified in the Update Request is 1241 already up, it will be re-signaled. 1243 The PCC SHOULD minimize the traffic interruption, and MAY use the 1244 make-before-break procedures described in [RFC3209] in order to 1245 achieve this goal. If the make-before-break procedures are used, two 1246 paths will briefly co-exist. The PCC MUST send separate PCRpt 1247 messages for each, identified by the LSP-IDENTIFIERS TLV. When the 1248 old path is torn down after the head end switches over the traffic, 1249 this event MUST be reported by sending a PCRpt message with the LSP- 1250 IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number 1251 that the PCC associates with this PCRpt MUST be 0x00000000. Thus, a 1252 make-before-break operation will typically result in at least two 1253 PCRpt messages, one for the new path and one for the removal of the 1254 old path (more messages may be possible if intermediate states are 1255 reported). 1257 If the path setup fails due to an RSVP signaling error, the error is 1258 reported to the PCE. The PCC will not attempt to resignal the path 1259 until it is prompted again by the PCE with a subsequent PCUpd 1260 message. 1262 A PCC MUST respond with an LSP State Report to each LSP Update 1263 Request it processed to indicate the resulting state of the LSP in 1264 the network (even if this processing did not result in changing the 1265 state of the LSP). The SRP-ID-number included in the PCRpt MUST 1266 match that in the PCUpd. A PCC MAY respond with multiple LSP State 1267 Reports to report LSP setup progress of a single LSP. In that case, 1268 the SRP-ID-number MUST be included for the first message, for 1269 subsequent messages the reserved value 0x00000000 SHOULD be used. 1271 Note that a PCC MUST process all LSP Update Requests - for example, 1272 an LSP Update Request is sent when a PCE returns delegation or puts 1273 an LSP into non-operational state. The protocol relies on TCP for 1274 message-level flow control. 1276 If the rate of PCUpd messages sent to a PCC for the same target LSP 1277 exceeds the rate at which the PCC can signal LSPs into the network, 1278 the PCC MAY perform state compression on its ingress queue. The 1279 compression algorithm is based on the fact that each PCUpd request 1280 contains the complete LSP state the PCE wishes to be set and works as 1281 follows: when the PCC starts processing a PCUpd message at the head 1282 of its ingress queue, it may search the queue forward for more recent 1283 PCUpd messages pertaining that particular LSP, prune all but the 1284 latest one from the queue and process only the last one as that 1285 request contains the most up-to-date desired state for the LSP. The 1286 PCC MUST NOT send PCRpt nor PCErr messages for requests which were 1287 pruned from the queue in this way. This compression step may be 1288 performed only while the LSP is not being signaled, e.g. if two PCUpd 1289 arrive for the same LSP in quick succession and the PCC started the 1290 signaling of the changes relevant to the first PCUpd, then it MUST 1291 wait until the signaling finishes (and report the new state via a 1292 PCRpt) before attempting to apply the changes indicated in the second 1293 PCUpd. 1295 Note also that it is up to the PCE to handle inter-LSP dependencies; 1296 for example, if ordering of LSP set-ups is required, the PCE has to 1297 wait for an LSP State Report for a previous LSP before starting the 1298 update of the next LSP. 1300 If the PCUpd cannot be satisfied (for example due to unsupported 1301 object or TLV), the PCC MUST respond with a PCErr message indicating 1302 the failure (see Section 7.3.3). 1304 6.3. The PCErr Message 1306 If the stateful PCE capability has been advertised on the PCEP 1307 session, the PCErr message MAY include the SRP object. If the error 1308 reported is the result of an LSP update request, then the SRP-ID- 1309 number MUST be the one from the PCUpd that triggered the error. If 1310 the error is unsolicited, the SRP object MAY be omitted. This is 1311 equivalent to including an SRP object with SRP-ID-number equal to the 1312 reserved value 0x00000000. 1314 The format of a PCErr message from [RFC5440] is extended as follows: 1316 ::= 1317 ( [] ) | 1318 [] 1320 ::=[] 1322 ::=[ | ] 1323 1325 ::=[] 1327 ::=[] 1329 ::=[] 1331 6.4. The PCReq Message 1333 A PCC MAY include the LSP object in the PCReq message (see 1334 Section 7.3) if the stateful PCE capability has been negotiated on a 1335 PCEP session between the PCC and a PCE. 1337 The definition of the PCReq message from [RFC5440] is extended to 1338 optionally include the LSP object after the END-POINTS object. The 1339 encoding from [RFC5440] will become: 1341 ::= 1342 [] 1343 1345 Where: 1347 ::=[] 1348 ::=[] 1350 ::= 1351 1352 [] 1353 [] 1354 [] 1355 [] 1356 [[]] 1357 [] 1358 [] 1360 6.5. The PCRep Message 1362 A PCE MAY include the LSP object in the PCRep message (see 1363 (Section 7.3) if the stateful PCE capability has been negotiated on a 1364 PCEP session between the PCC and the PCE and the LSP object was 1365 included in the corresponding PCReq message from the PCC. 1367 The definition of the PCRep message from [RFC5440] is extended to 1368 optionally include the LSP object after the RP object. The encoding 1369 from [RFC5440] will become: 1371 ::= 1372 1374 Where: 1376 ::=[] 1378 ::= 1379 [] 1380 [] 1381 [] 1382 [] 1384 7. Object Formats 1386 The PCEP objects defined in this document are compliant with the PCEP 1387 object format defined in [RFC5440]. The P flag and the I flag of the 1388 PCEP objects defined in the current document MUST be set to 0 on 1389 transmission and SHOULD be ignored on receipt since the P and I flags 1390 are exclusively related to path computation requests. 1392 7.1. OPEN Object 1394 This document defines one new optional TLVs for use in the OPEN 1395 Object. 1397 7.1.1. Stateful PCE Capability TLV 1399 The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the 1400 OPEN Object for stateful PCE capability advertisement. Its format is 1401 shown in the following figure: 1403 0 1 2 3 1404 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 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Type=[TBD] | Length=4 | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | Flags |U| 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 Figure 9: STATEFUL-PCE-CAPABILITY TLV format 1413 The type (16 bits) of the TLV is to be assigned by IANA. The length 1414 field is 16 bit-long and has a fixed value of 4. 1416 The value comprises a single field - Flags (32 bits): 1418 U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag 1419 indicates that the PCC allows modification of LSP parameters; if 1420 set to 1 by a PCE, the U Flag indicates that the PCE is capable of 1421 updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be 1422 advertised by both a PCC and a PCE for PCUpd messages to be 1423 allowed on a PCEP session. 1425 Unassigned bits are considered reserved. They MUST be set to 0 on 1426 transmission and MUST be ignored on receipt. 1428 Advertisement of the stateful PCE capability implies support of LSPs 1429 that are signaled via RSVP, as well as the objects, TLVs and 1430 procedures defined in this document. 1432 7.2. SRP Object 1434 The SRP (Stateful PCE Request Parameters) object MUST be carried 1435 within PCUpd messages and MAY be carried within PCRpt and PCErr 1436 messages. The SRP object is used to correlate between update 1437 requests sent by the PCE and the error reports and state reports sent 1438 by the PCC. 1440 SRP Object-Class is to be assigned by IANA. 1442 SRP Object-Type is 1. 1444 The format of the SRP object body is shown in Figure 10: 1446 0 1 2 3 1447 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 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Flags | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | SRP-ID-number | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | | 1454 // Optional TLVs // 1455 | | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 Figure 10: The SRP Object format 1460 The SRP object body has a variable length and may contain additional 1461 TLVs. 1463 Flags (32 bits): None defined yet. 1465 SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the 1466 current PCEP session uniquely identify the operation that the PCE has 1467 requested the PCC to perform on a given LSP. The SRP-ID-number is 1468 incremented each time a new request is sent to the PCC, and may wrap 1469 around. 1471 The values 0x00000000 and 0xFFFFFFFF are reserved. 1473 Every request to update an LSP receives a new SRP-ID-number. This 1474 number is unique per PCEP session and is incremented each time an 1475 operation is requested from the PCE. Thus, for a given LSP there may 1476 be more than one SRP-ID-number unacknowledged at a given time. The 1477 value of the SRP-ID-number is echoed back by the PCC in PCErr and 1478 PCRpt messages to allow for correlation between requests made by the 1479 PCE and errors or state reports generated by the PCC. If the error 1480 or report were not as a result of a PCE operation (for example in the 1481 case of a link down event), the reserved value of 0x00000000 is used 1482 for the SRP-ID-number. The absence of the SRP object is equivalent 1483 to an SRP object with the reserved value of 0x00000000. An SRP-ID- 1484 number is considered unacknowledged and cannot be reused until a 1485 PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the 1486 same LSP. In case of SRP-ID-number wrapping the last SRP-ID-number 1487 before the wrapping MUST be explicitly acknowledged, to avoid a 1488 situation where SRP-ID-numbers remain unacknowledged after the wrap. 1489 This means that the PCC may need to issue two PCUpd messages on 1490 detecting a wrap. 1492 7.3. LSP Object 1494 The LSP object MUST be present within PCRpt and PCUpd messages. The 1495 LSP object MAY be carried within PCReq and PCRep messages if the 1496 stateful PCE capability has been negotiated on the session. The LSP 1497 object contains a set of fields used to specify the target LSP, the 1498 operation to be performed on the LSP, and LSP Delegation. It also 1499 contains a flag indicating to a PCE that the LSP state 1500 synchronization is in progress. This document focuses on LSPs that 1501 are signaled with RSVP, many of the TLVs used with the LSP object 1502 mirror RSVP state. 1504 LSP Object-Class is to be assigned by IANA. 1506 LSP Object-Type is 1. 1508 The format of the LSP object body is shown in Figure 11: 1510 0 1 2 3 1511 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 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | PLSP-ID | Flag | O|A|R|S|D| 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 // TLVs // 1516 | | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 Figure 11: The LSP Object format 1521 PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC 1522 creates a unique PLSP-ID for each LSP that is constant for the 1523 lifetime of a PCEP session. The PCC will advertise the same PLSP-ID 1524 on all PCEP sessions it maintains at a given times. The mapping of 1525 the Symbolic Path Name to PLSP-ID is communicated to the PCE by 1526 sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All 1527 subsequent PCEP messages then address the LSP by the PLSP-ID. The 1528 values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a 1529 value that is constant for the lifetime of the PCEP session, during 1530 which time for an RSVP-signaled LSP there might be a different RSVP 1531 identifiers (LSP-id, tunnel-id) allocated to it. 1533 Flags (12 bits), starting from the least significant bit: 1535 D (Delegate - 1 bit): On a PCRpt message, the D Flag set to 1 1536 indicates that the PCC is delegating the LSP to the PCE. On a 1537 PCUpd message, the D flag set to 1 indicates that the PCE is 1538 confirming the LSP Delegation. To keep an LSP delegated to the 1539 PCE, the PCC must set the D flag to 1 on each PCRpt message for 1540 the duration of the delegation - the first PCRpt with the D flag 1541 set to 0 revokes the delegation. To keep the delegation, the PCE 1542 must set the D flag to 1 on each PCUpd message for the duration of 1543 the delegation - the first PCUpd with the D flag set to 0 returns 1544 the delegation. 1546 S (SYNC - 1 bit): The S Flag MUST be set to 1 on each PCRpt sent 1547 from a PCC during State Synchronization. The S Flag MUST be set 1548 to 0 in other messages sent from the PCC. 1550 R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1551 LSP has been removed from the PCC and the PCE SHOULD remove all 1552 state from its database. Upon receiving an LSP State Report with 1553 the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD 1554 remove all state for the path identified by the LSP-IDENTIFIERS 1555 TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is 1556 used, the PCE SHOULD remove all state for the PLSP-ID from its 1557 database. 1559 A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates 1560 the PCC's target operational status for this LSP. On PCUpd 1561 messages, the A Flag indicates the LSP status that the PCE desires 1562 for this LSP. In both cases, a value of '1' means that the 1563 desired operational state is active, and a value of '0' means that 1564 the desired operational state is inactive. A PCC ignores the A 1565 flag on a PCUpd message unless the operator's policy allows the 1566 PCE to control the corresponding LSP's administrative state. 1568 O(Operational - 3 bits): On PCRpt messages, the O Field represents 1569 the operational status of the LSP. 1571 The following values are defined: 1573 0 - DOWN: not active. 1575 1 - UP: signalled. 1577 2 - ACTIVE: up and carrying traffic. 1579 3 - GOING-DOWN: LSP is being torn down, resources are being 1580 released. 1582 4 - GOING-UP: LSP is being signalled. 1584 5-7 - Reserved: these values are reserved for future use. 1586 Unassigned bits are considered reserved. They MUST be set to 0 on 1587 transmission and MUST be ignored on receipt. 1589 TLVs that may be included in the LSP Object are described in the 1590 following sections. 1592 7.3.1. LSP-IDENTIFIERS TLVs 1594 The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt 1595 messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will 1596 generate an error with error-type 6 (mandatory object missing) and 1597 error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. 1598 The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd 1599 messages for RSVP-signaled LSPs. The special value of all zeros for 1600 this TLV is used to refer to all paths pertaining to a particular 1601 PLSP-ID. There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one 1602 for IPv6. 1604 It is the responsibility of the PCC to send to the PCE the 1605 identifiers for each RSVP incarnation of the tunnel. For example, in 1606 a make-before-break scenario, the PCC MUST send a separate PCRpt for 1607 the old and for the reoptimized paths, and explicitly report removal 1608 of any of these paths using the R bit in the LSP object. 1610 The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 1611 figure: 1613 0 1 2 3 1614 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 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | Type=[TBD] | Length=16 | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | IPv4 Tunnel Sender Address | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | LSP ID | Tunnel ID | 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 | Extended Tunnel ID | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | IPv4 Tunnel Endpoint Address | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 Figure 12: IPV4-LSP-IDENTIFIERS TLV format 1629 The type (16 bits) of the TLV is to be assigned by IANA. The length 1630 field is 16 bit-long and has a fixed value of 16. The value contains 1631 the following fields: 1633 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 1634 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 1635 Sender Template Object. 1637 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1638 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 1639 Object. A value of 0 MUST be used if the LSP is not yet signaled. 1641 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1642 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 1644 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 1645 identifier defined in [RFC3209], Section 4.6.1.1 for the 1646 LSP_TUNNEL_IPv4 Session Object. 1648 IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 1649 address, as defined in [RFC3209], Section 4.6.1.1 for the 1650 LSP_TUNNEL_IPv4 Sender Template Object. 1652 The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following 1653 figure: 1655 0 1 2 3 1656 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 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Type=[TBD] | Length=52 | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | | 1661 + + 1662 | IPv6 tunnel sender address | 1663 + (16 octets) + 1664 | | 1665 + + 1666 | | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | LSP ID | Tunnel ID | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 | | 1671 + + 1672 | Extended Tunnel ID | 1673 + (16 octets) + 1674 | | 1675 + + 1676 | | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | | 1679 + + 1680 | IPv6 tunnel endpoint address | 1681 + (16 octets) + 1682 | | 1683 + + 1684 | | 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 Figure 13: IPV6-LSP-IDENTIFIERS TLV format 1689 The type (16 bits) of the TLV is to be assigned by IANA. The length 1690 field is 16 bit-long and has a fixed value of 52. The value contains 1691 the following fields: 1693 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 1694 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 1695 Sender Template Object. 1697 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1698 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 1699 Object. A value of 0 MUST be used if the LSP is not yet signaled. 1701 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1702 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 1704 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 1705 identifier defined in [RFC3209], Section 4.6.1.2 for the 1706 LSP_TUNNEL_IPv6 Session Object. 1708 IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 1709 address, as defined in [RFC3209], Section 4.6.1.2 for the 1710 LSP_TUNNEL_IPv6 Session Object. 1712 The Tunnel ID remains constant over the life time of a tunnel. 1714 7.3.2. Symbolic Path Name TLV 1716 Each LSP (path) MUST have a symbolic name that is unique in the PCC. 1717 This symbolic path name MUST remain constant throughout an LSP's 1718 lifetime, which may span across multiple consecutive PCEP sessions 1719 and/or PCC restarts. The symbolic path name MAY be specified by an 1720 operator in a PCC's configuration. If the operator does not specify 1721 a unique symbolic name for a path, the PCC MUST auto-generate one. 1723 The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the 1724 LSP State Report (PCRpt) message when during a given PCEP session an 1725 LSP is first reported to a PCE. A PCC sends to a PCE the first LSP 1726 State Report either during State Synchronization, or when a new LSP 1727 is configured at the PCC. The symbolic path name MAY be included in 1728 the LSP object in subsequent LSP State Reports for the LSP. 1730 The format of the SYMBOLIC-PATH-NAME TLV is shown in the following 1731 figure: 1733 0 1 2 3 1734 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 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Type=[TBD] | Length (variable) | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | | 1739 // Symbolic Path Name // 1740 | | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 Figure 14: SYMBOLIC-PATH-NAME TLV format 1745 Type (16 bits): to be assigned by IANA. 1747 Length (16 bits): indicates the total length of the TLV in octets and 1748 MUST be greater than 0. The TLV MUST be zero-padded so that the TLV 1749 is 4-octet aligned. 1751 Symbolic Path Name (variable): symbolic name for the LSP, unique in 1752 the PCC. 1754 7.3.3. LSP Error Code TLV 1756 The LSP Error code TLV is an optional TLV for use in the LSP object 1757 to convey error information. When an LSP Update Request fails, an 1758 LSP State Report MUST be sent to report the current state of the LSP, 1759 and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for 1760 the failure. Similarly, when a PCRpt is sent as a result of an LSP 1761 transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD 1762 be included to indicate the reason for the transition. 1764 The format of the LSP-ERROR-CODE TLV is shown in the following 1765 figure: 1767 0 1 2 3 1768 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 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Type=[TBD] | Length=4 | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 | LSP Error Code | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 Figure 15: LSP-ERROR-CODE TLV format 1777 The type (16 bits) of the TLV is to be assigned by IANA. The length 1778 field is 16 bit-long and has a fixed value of 4. The value contains 1779 an error code that indicates the cause of the failure. 1781 The following LSP Error Codes are currently defined: 1783 Value Meaning 1784 1 Unknown reason 1785 2 Limit reached for PCE-controlled LSPs 1786 3 Too many pending LSP update requests 1787 4 Unacceptable parameters 1788 5 Internal error 1789 6 LSP administratively brought down 1790 7 LSP preempted 1791 8 RSVP signaling error 1793 7.3.4. RSVP Error Spec TLV 1795 The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object 1796 to carry RSVP error information. It includes the RSVP ERROR_SPEC or 1797 USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned 1798 to the PCC from a downstream node. If the set up of an LSP fails at 1799 a downstream node which returned an ERROR_SPEC to the PCC, the PCC 1800 SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with 1801 LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV 1802 with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object. 1804 The format of the RSVP-ERROR-SPEC TLV is shown in the following 1805 figure: 1807 0 1 2 3 1808 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 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | Type=[TBD] | Length (variable) | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | | 1813 + RSVP ERROR_SPEC or USER_ERROR_SPEC Object + 1814 | | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 Figure 16: RSVP-ERROR-SPEC TLV format 1819 Type (16 bits):to be assigned by IANA. 1821 Length (16 bits): indicates the total length of the TLV in octets. 1822 The TLV MUST be zero-padded so that the TLV is 4-octet aligned. 1824 Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC 1825 Object: as specified in [RFC2205] and [RFC5284], including the object 1826 header. 1828 8. IANA Considerations 1830 This document requests IANA actions to allocate code points for the 1831 protocol elements defined in this document. Values shown here are 1832 suggested for use by IANA. 1834 8.1. PCE Capabilities in IGP Advertisements 1836 IANA is requested to allocate new bits in the OSPF Parameters "PCE 1837 Capability Flags" registry, as follows: 1839 Bit Meaning Reference 1840 11 Active Stateful PCE This document 1841 capability 1842 12 Passive Stateful PCE This document 1843 capability 1845 8.2. PCEP Messages 1847 IANA is requested to allocate new message types within the "PCEP 1848 Messages" sub-registry of the PCEP Numbers registry, as follows: 1850 Value Meaning Reference 1851 10 Report This document 1852 11 Update This document 1854 8.3. PCEP Objects 1856 IANA is requested to allocate new object-class values and object 1857 types within the "PCEP Objects" sub-registry of the PCEP Numbers 1858 registry, as follows. 1860 Object-Class Value Name Reference 1862 32 LSP This document 1863 Object-Type 1864 1 1865 33 SRP This document 1866 Object-Type 1867 1 1869 8.4. LSP Object 1871 This document requests that a new sub-registry, named "LSP Object 1872 Flag Field", is created within the "Path Computation Element Protocol 1873 (PCEP) Numbers" registry to manage the Flag field of the LSP 1874 object.New values are to be assigned by Standards Action [RFC5226]. 1875 Each bit should be tracked with the following qualities: 1877 o Bit number (counting from bit 0 as the most significant bit) 1879 o Capability description 1881 o Defining RFC 1883 The following values are defined in this document: 1885 Bit Description Reference 1887 0-4 Reserved This document 1888 5-7 Operational (3 bits) This document 1889 8 Administrative This document 1890 9 Remove This document 1891 10 SYNC This document 1892 11 Delegate This document 1894 8.5. PCEP-Error Object 1896 IANA is requested to allocate new Error Types and Error Values within 1897 the " PCEP-ERROR Object Error Types and Values" sub-registry of the 1898 PCEP Numbers registry, as follows: 1900 Error-Type Meaning 1901 6 Mandatory Object missing 1903 Error-value=8: LSP Object missing 1904 Error-value=9: ERO Object missing 1905 Error-value=10: SRP Object missing 1906 Error-value=11: LSP-IDENTIFIERS TLV missing 1907 19 Invalid Operation 1909 Error-value=1: Attempted LSP Update Request for a non- 1910 delegated LSP. The PCEP-ERROR Object 1911 is followed by the LSP Object that 1912 identifies the LSP. 1913 Error-value=2: Attempted LSP Update Request if the 1914 stateful PCE capability was not 1915 advertised. 1916 Error-value=3: Attempted LSP Update Request for an LSP 1917 identified by an unknown PLSP-ID. 1918 Error-value=5: Attempted LSP State Report if active 1919 stateful PCE capability was not 1920 advertised. 1921 20 LSP State synchronization error. 1923 Error-value=1: A PCE indicates to a PCC that it can 1924 not process (an otherwise valid) LSP 1925 State Report. The PCEP-ERROR Object is 1926 followed by the LSP Object that 1927 identifies the LSP. 1928 Error-value=5: A PCC indicates to a PCE that it can 1929 not complete the state synchronization, 1931 8.6. Notification Object 1933 IANA is requested to allocate new Notification Types and Notification 1934 Values within the "Notification Object" sub-registry of the PCEP 1935 Numbers registry, as follows: 1937 Notification-Type Meaning 1938 4 Stateful PCE resource limit exceeded 1939 Notification-value=1: Entering resource limit 1940 exceeded state 1941 Notification-value=2: Exiting resource limit exceeded 1942 state 1944 8.7. PCEP TLV Type Indicators 1946 IANA is requested to allocate new TLV Type Indicator values within 1947 the " PCEP TLV Type Indicators" sub-registry of the PCEP Numbers 1948 registry, as follows: 1950 Value Meaning Reference 1951 16 STATEFUL-PCE-CAPABILITY This document 1952 17 SYMBOLIC-PATH-NAME This document 1953 18 IPV4-LSP-IDENTIFIERS This document 1954 19 IPV6-LSP-IDENTIFIERS This document 1955 20 LSP-ERROR-CODE This document 1956 21 RSVP-ERROR-SPEC This document 1958 8.8. STATEFUL-PCE-CAPABILITY TLV 1960 This document requests that a new sub-registry, named "STATEFUL-PCE- 1961 CAPABILITY TLV Flag Field", is created within the "Path Computation 1962 Element Protocol (PCEP) Numbers" registry to manage the Flag field in 1963 the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = 1). 1964 New values are to be assigned by Standards Action [RFC5226]. Each 1965 bit should be tracked with the following qualities: 1967 o Bit number (counting from bit 0 as the most significant bit) 1969 o Capability description 1971 o Defining RFC 1973 The following values are defined in this document: 1975 Bit Description Reference 1977 31 LSP-UPDATE-CAPABILITY This document 1979 8.9. LSP-ERROR-CODE TLV 1981 This document requests that a new sub-registry, named "LSP-ERROR-CODE 1982 TLV Error Code Field", is created within the "Path Computation 1983 Element Protocol (PCEP) Numbers" registry to manage the LSP Error 1984 code field of the LSP-ERROR-CODE TLV. This field specifies the 1985 reason for failure to update the LSP. 1987 New values are to be assigned by Standards Action [RFC5226]. Each 1988 value should be tracked with the following qualities: value, 1989 description and defining RFC. The following values are defined in 1990 this document: 1992 Value Meaning 1993 1 Unknown reason 1994 2 Limit reached for PCE-controlled LSPs 1995 3 Too many pending LSP update requests 1996 4 Unacceptable parameters 1997 5 Internal error 1998 6 LSP administratively brought down 1999 7 LSP preempted 2000 8 RSVP signaling error 2002 9. Manageability Considerations 2004 All manageability requirements and considerations listed in [RFC5440] 2005 apply to PCEP extensions defined in this document. In addition, 2006 requirements and considerations listed in this section apply. 2008 9.1. Control Function and Policy 2010 In addition to configuring specific PCEP session parameters, as 2011 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 2012 allow configuring the stateful PCEP capability and the LSP Update 2013 capability. A PCC implementation SHOULD allow the operator to 2014 specify multiple candidate PCEs for and a delegation preference for 2015 each candidate PCE. A PCC SHOULD allow the operator to specify an 2016 LSP delegation policy where LSPs are delegated to the most-preferred 2017 online PCE. A PCC MAY allow the operator to specify different LSP 2018 delegation policies. 2020 A PCC implementation which allows concurrent connections to multiple 2021 PCEs SHOULD allow the operator to group the PCEs by administrative 2022 domains and it MUST NOT advertise LSP existence and state to a PCE if 2023 the LSP is delegated to a PCE in a different group. 2025 A PCC implementation SHOULD allow the operator to specify whether the 2026 PCC will advertise LSP existence and state for LSPs that are not 2027 controlled by any PCE (for example, LSPs that are statically 2028 configured at the PCC). 2030 A PCC implementation SHOULD allow the operator to specify both the 2031 Redelegation Timeout Interval and the State Timeout Interval. The 2032 default value of the Redelegation Timeout Interval SHOULD be set to 2033 30 seconds. An operator MAY also configure a policy that will 2034 dynamically adjust the Redelegation Timeout Interval, for example 2035 setting it to zero when the PCC has an established session to a 2036 backup PCE. The default value for the State Timeout Interval SHOULD 2037 be set to 60 seconds. 2039 After the expiration of the State Timeout Interval, the LSP reverts 2040 to operator-defined default parameters. A PCC implementation MUST 2041 allow the operator to specify the default LSP parameters. To achieve 2042 a behavior where the LSP retains the parameters set by the PCE until 2043 such time that the PCC makes a change to them, a State Timeout 2044 Interval of infinity SHOULD be used. Any changes to LSP parameters 2045 SHOULD be done in make-before-break fashion. 2047 LSP Delegation is controlled by operator-defined policies on a PCC. 2048 LSPs are delegated individually - different LSPs may be delegated to 2049 different PCEs. An LSP is delegated to at most one PCE at any given 2050 point in time. A PCC implementation SHOULD support the delegation 2051 policy, when all PCC's LSPs are delegated to a single PCE at any 2052 given time. Conversely, the policy revoking the delegation for all 2053 PCC's LSPs SHOULD also be supported. 2055 A PCC implementation SHOULD allow the operator to specify delegation 2056 priority for PCEs. This effectively defines the primary PCE and one 2057 or more backup PCEs to which primary PCE's LSPs can be delegated when 2058 the primary PCE fails. 2060 Policies defined for stateful PCEs and PCCs should eventually fit in 2061 the Policy-Enabled Path Computation Framework defined in [RFC5394], 2062 and the framework should be extended to support Stateful PCEs. 2064 9.2. Information and Data Models 2066 PCEP session configuration and information in the PCEP MIB module 2067 SHOULD be extended to include advertised stateful capabilities, 2068 synchronization status, and delegation status (at the PCC list PCEs 2069 with delegated LSPs). 2071 9.3. Liveness Detection and Monitoring 2073 PCEP extensions defined in this document do not require any new 2074 mechanisms beyond those already defined in [RFC5440], Section 8.3. 2076 9.4. Verifying Correct Operation 2078 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 2079 extensions defined in this document. In addition to monitoring 2080 parameters defined in [RFC5440], a stateful PCC-side PCEP 2081 implementation SHOULD provide the following parameters: 2083 o Total number of LSP updates 2085 o Number of successful LSP updates 2087 o Number of dropped LSP updates 2089 o Number of LSP updates where LSP setup failed 2091 A PCC implementation SHOULD provide a command to show for each LSP 2092 whether it is delegated, and if so, to which PCE. 2094 A PCC implementation SHOULD allow the operator to manually revoke LSP 2095 delegation. 2097 9.5. Requirements on Other Protocols and Functional Components 2099 PCEP extensions defined in this document do not put new requirements 2100 on other protocols. 2102 9.6. Impact on Network Operation 2104 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 2105 extensions defined in this document. 2107 Additionally, a PCEP implementation SHOULD allow a limit to be placed 2108 on the number of LSPs delegated to the PCE and on the rate of PCUpd 2109 and PCRpt messages sent by a PCEP speaker and processed from a peer. 2110 It SHOULD also allow sending a notification when a rate threshold is 2111 reached. 2113 A PCC implementation SHOULD allow a limit to be placed on the rate of 2114 LSP Updates to the same LSP to avoid signaling overload discussed in 2115 Section 10.3. 2117 10. Security Considerations 2119 10.1. Vulnerability 2121 This document defines extensions to PCEP to enable stateful PCEs. 2122 The nature of these extensions and the delegation of path control to 2123 PCEs results in more information being available for a hypothetical 2124 adversary and a number of additional attack surfaces which must be 2125 protected. 2127 The security provisions described in [RFC5440] remain applicable to 2128 these extensions. However, because the protocol modifications 2129 outlined in this document allow the PCE to control path computation 2130 timing and sequence, the PCE defense mechanisms described in 2131 [RFC5440] section 7.2 are also now applicable to PCC security. 2133 As a general precaution, it is RECOMMENDED that these PCEP extensions 2134 only be activated on authenticated and encrypted sessions across PCEs 2135 and PCCs belonging to the same administrative authority. 2137 The following sections identify specific security concerns that may 2138 result from the PCEP extensions outlined in this document along with 2139 recommended mechanisms to protect PCEP infrastructure against related 2140 attacks. 2142 10.2. LSP State Snooping 2144 The stateful nature of this extension explicitly requires LSP status 2145 updates to be sent from PCC to PCE. While this gives the PCE the 2146 ability to provide more optimal computations to the PCC, it also 2147 provides an adversary with the opportunity to eavesdrop on decisions 2148 made by network systems external to PCE. This is especially true if 2149 the PCC delegates LSPs to multiple PCEs simultaneously. 2151 Adversaries may gain access to this information by eavesdropping on 2152 unsecured PCEP sessions, and might then use this information in 2153 various ways to target or optimize attacks on network infrastructure. 2154 For example by flexibly countering anti-DDoS measures being taken to 2155 protect the network, or by determining choke points in the network 2156 where the greatest harm might be caused. 2158 PCC implementations which allow concurrent connections to multiple 2159 PCEs SHOULD allow the operator to group the PCEs by administrative 2160 domains and they MUST NOT advertise LSP existence and state to a PCE 2161 if the LSP is delegated to a PCE in a different group. 2163 10.3. Malicious PCE 2165 The LSP delegation mechanism described in this document allows a PCC 2166 to grant effective control of an LSP to the PCE for the duration of a 2167 PCEP session. While this enables PCE control of the timing and 2168 sequence of path computations within and across PCEP sessions, it 2169 also introduces a new attack vector: an attacker may flood the PCC 2170 with PCUpd messages at a rate which exceeds either the PCC's ability 2171 to process them or the network's ability to signal the changes, 2172 either by spoofing messages or by compromising the PCE itself. 2174 A PCC is free to revoke an LSP delegation at any time without needing 2175 any justification. A defending PCC can do this by enqueueing the 2176 appropriate PCRpt message. As soon as that message is enqueued in 2177 the session, the PCC is free to drop any incoming PCUpd messages 2178 without additional processing. 2180 10.4. Malicious PCC 2182 A stateful session also results in an increased attack surface by 2183 placing a requirement for the PCE to keep an LSP state replica for 2184 each PCC. It is RECOMMENDED that PCE implementations provide a limit 2185 on resources a single PCC can occupy. A PCE implementing such a 2186 limit MUST send a PCNtf message with notification-type to be assigned 2187 by IANA (Stateful PCE resource limit exceeded) and notification-value 2188 to be assigned by IANA (Entering resource limit exceeded state) upon 2189 receiving an LSP state report causing it to exceed this threshold. 2191 Delegation of LSPs can create further strain on PCE resources and a 2192 PCE implementation MAY preemptively give back delegations if it finds 2193 itself lacking the resources needed to effectively manage the 2194 delegation. Since the delegation state is ultimately controlled by 2195 the PCC, PCE implementations SHOULD provide throttling mechanisms to 2196 prevent strain created by flaps of either a PCEP session or an LSP 2197 delegation. 2199 11. Contributing Authors 2201 Xian Zhang 2202 Huawei Technology 2203 F3-5-B R&D Center 2204 Huawei Industrial Base, Bantian, Longgang District 2205 Shenzhen, Guangdong 518129 2206 P.R.China 2207 EMail: zhang.xian@huawei.com 2209 Dhruv Dhody 2210 Huawei Technology 2211 Leela Palace 2212 Bangalore, Karnataka 560008 2213 INDIA 2214 EMail: dhruv.dhody@huawei.com 2216 Siva Sivabalan 2217 Cisco Systems, Inc. 2218 2000 Innovation Drive 2219 Kanata, Ontario K2K 3E8 2220 Canada 2221 EMail: msiva@cisco.com 2223 12. Acknowledgements 2225 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 2226 Casellas for their contributions to this document. 2228 We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, 2229 Paul Schultz and Raveendra Torvi for their comments and suggestions. 2230 Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga, 2231 Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, 2232 Ambrose Kwong, Ashwin Sampath and Calvin Ying for helpful comments 2233 and discussions. 2235 13. References 2237 13.1. Normative References 2239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2240 Requirement Levels", BCP 14, RFC 2119, 2241 DOI 10.17487/RFC2119, March 1997, 2242 . 2244 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2245 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2246 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2247 September 1997, . 2249 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2250 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2251 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2252 . 2254 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 2255 Zhang, "OSPF Protocol Extensions for Path Computation 2256 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 2257 January 2008, . 2259 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 2260 Zhang, "IS-IS Protocol Extensions for Path Computation 2261 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 2262 January 2008, . 2264 [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", 2265 RFC 5284, DOI 10.17487/RFC5284, August 2008, 2266 . 2268 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 2269 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 2270 DOI 10.17487/RFC5440, March 2009, 2271 . 2273 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2274 Used to Form Encoding Rules in Various Routing Protocol 2275 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2276 2009, . 2278 13.2. Informative References 2280 [I-D.ietf-pce-gmpls-pcep-extensions] 2281 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 2282 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in 2283 progress), October 2015. 2285 [I-D.ietf-pce-stateful-pce-app] 2286 Zhang, X. and I. Minei, "Applicability of a Stateful Path 2287 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 2288 app-06 (work in progress), July 2016. 2290 [I-D.ietf-pce-stateful-sync-optimizations] 2291 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 2292 and D. Dhody, "Optimizations of Label Switched Path State 2293 Synchronization Procedures for a Stateful PCE", draft- 2294 ietf-pce-stateful-sync-optimizations-05 (work in 2295 progress), April 2016. 2297 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2298 LSP Path Computation using Preemption", Global 2299 Information Infrastructure Symposium, July 2007. 2301 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2302 programming algorithm for balancing the max-min fairness 2303 and throughput objectives in traffic engineering", 2304 INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012. 2306 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2307 McManus, "Requirements for Traffic Engineering Over MPLS", 2308 RFC 2702, DOI 10.17487/RFC2702, September 1999, 2309 . 2311 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2312 Label Switching Architecture", RFC 3031, 2313 DOI 10.17487/RFC3031, January 2001, 2314 . 2316 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2317 Christian, B., and W. Lai, "Applicability Statement for 2318 Traffic Engineering with MPLS", RFC 3346, 2319 DOI 10.17487/RFC3346, August 2002, 2320 . 2322 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2323 (TE) Extensions to OSPF Version 2", RFC 3630, 2324 DOI 10.17487/RFC3630, September 2003, 2325 . 2327 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2328 Element (PCE)-Based Architecture", RFC 4655, 2329 DOI 10.17487/RFC4655, August 2006, 2330 . 2332 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 2333 Element (PCE) Communication Protocol Generic 2334 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2335 2006, . 2337 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2338 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2339 DOI 10.17487/RFC5226, May 2008, 2340 . 2342 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2343 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2344 2008, . 2346 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2347 "Policy-Enabled Path Computation Framework", RFC 5394, 2348 DOI 10.17487/RFC5394, December 2008, 2349 . 2351 Authors' Addresses 2353 Edward Crabbe 2354 Oracle 2355 1501 4th Ave, suite 1800 2356 Seattle, WA 98101 2357 US 2359 Email: edward.crabbe@oracle.com 2360 Ina Minei 2361 Google, Inc. 2362 1600 Amphitheatre Parkway 2363 Mountain View, CA 94043 2364 US 2366 Email: inaminei@google.com 2368 Jan Medved 2369 Cisco Systems, Inc. 2370 170 West Tasman Dr. 2371 San Jose, CA 95134 2372 US 2374 Email: jmedved@cisco.com 2376 Robert Varga 2377 Pantheon Technologies SRO 2378 Mlynske Nivy 56 2379 Bratislava 821 05 2380 Slovakia 2382 Email: robert.varga@pantheon.tech