idnits 2.17.1 draft-ietf-pce-stateful-pce-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 17, 2017) is 2536 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) ** Downref: Normative reference to an Informational RFC: RFC 8051 == Outdated reference: A later version (-16) exists of draft-ietf-pce-gmpls-pcep-extensions-11 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-02 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-12 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group E. Crabbe 3 Internet-Draft Oracle 4 Intended status: Standards Track I. Minei 5 Expires: November 18, 2017 Google, Inc. 6 J. Medved 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 May 17, 2017 12 PCEP Extensions for Stateful PCE 13 draft-ietf-pce-stateful-pce-19 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 November 18, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Motivation and Objectives for Stateful PCE . . . . . . . . . 5 65 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 5 67 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6 68 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7 69 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8 71 5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 9 72 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 73 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 9 74 5.3. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10 75 5.4. Capability Advertisement . . . . . . . . . . . . . . . . 10 76 5.5. IGP Extensions for Stateful PCE Capabilities 77 Advertisement . . . . . . . . . . . . . . . . . . . . . . 11 78 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12 79 5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15 80 5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 81 5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16 82 5.7.3. Returning a Delegation . . . . . . . . . . . . . . . 18 83 5.7.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18 84 5.7.5. Redelegation on PCE Failure . . . . . . . . . . . . . 19 85 5.8. LSP Operations . . . . . . . . . . . . . . . . . . . . . 19 86 5.8.1. Passive Stateful PCE Path Computation 87 Request/Response . . . . . . . . . . . . . . . . . . 19 88 5.8.2. Switching from Passive Stateful to Active Stateful . 21 89 5.8.3. Active Stateful PCE LSP Update . . . . . . . . . . . 22 90 5.9. LSP Protection . . . . . . . . . . . . . . . . . . . . . 23 91 5.10. PCEP Sessions . . . . . . . . . . . . . . . . . . . . . . 23 92 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 23 93 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 24 94 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 26 95 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 28 96 6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 29 97 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 30 98 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 30 99 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 30 100 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 30 101 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 31 102 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 33 103 7.3.1. LSP-IDENTIFIERS TLVs . . . . . . . . . . . . . . . . 35 104 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 38 105 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 39 106 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 40 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 108 8.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 41 109 8.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 41 110 8.3. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 42 111 8.4. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 42 112 8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 43 113 8.6. Notification Object . . . . . . . . . . . . . . . . . . . 43 114 8.7. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 44 115 8.8. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 44 116 8.9. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 45 117 9. Manageability Considerations . . . . . . . . . . . . . . . . 45 118 9.1. Control Function and Policy . . . . . . . . . . . . . . . 45 119 9.2. Information and Data Models . . . . . . . . . . . . . . . 46 120 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 47 121 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 47 122 9.5. Requirements on Other Protocols and Functional Components 47 123 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 47 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 48 125 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 48 126 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 48 127 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 49 128 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 49 129 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 49 130 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 131 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 132 13.1. Normative References . . . . . . . . . . . . . . . . . . 50 133 13.2. Informative References . . . . . . . . . . . . . . . . . 51 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 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 The extensions that this document describes do not permit the PCE to 153 drive creation of an LSP. The companion document 154 [I-D.ietf-pce-pce-initiated-lsp] specifies PCE-initiated LSP 155 creation. 157 1.1. Requirements Language 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 2. Terminology 165 This document uses the following terms defined in [RFC5440]: PCC, 166 PCE, PCEP Peer, PCEP Speaker. 168 This document uses the following terms defined in [RFC4655]: TED. 170 This document uses the following terms defined in [RFC3031]: LSP. 172 This document uses the following terms defined in [RFC8051]: Stateful 173 PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, LSP State 174 Database. 176 The following terms are defined in this document: 178 Revocation: an operation performed by a PCC on a previously 179 delegated LSP. Revocation revokes the rights granted to the PCE 180 in the delegation operation. 182 Redelegation Timeout Interval: the period of time a PCC waits for, 183 when a PCEP session is terminated, before revoking LSP delegation 184 to a PCE and attempting to redelegate LSPs associated with the 185 terminated PCEP session to an alternate PCE. The Redelegation 186 Timeout Interval is a PCC-local value that can be either operator- 187 configured or dynamically computed by the PCC based on local 188 policy. 190 State Timeout Interval: the period of time a PCE waits for, when a 191 PCEP session is terminated, before flushing LSP state associated 192 with that PCEP session and reverting to operator-defined default 193 parameters or behaviors. The State Timeout Interval is a PCC- 194 local value that can be either operator-configured or dynamically 195 computed by the PCC based on local policy. 197 LSP State Report: an operation to send LSP state (Operational / 198 Admin Status, LSP attributes configured at the PCC and set by a 199 PCE, etc.) from a PCC to a PCE. 201 LSP Update Request: an operation where an Active Stateful PCE 202 requests a PCC to update one or more attributes of an LSP and to 203 re-signal the LSP with updated attributes. 205 SRP-ID-number: a number used to correlate errors and LSP State 206 Reports to LSP Update Requests. It is carried in the SRP 207 (Stateful PCE Request Parameters) Object described in Section 7.2. 209 Within this document, PCEP communications are described through PCC- 210 PCE relationship. The PCE architecture also supports the PCE-PCE 211 communication, by having the requesting PCE fill the role of a PCC, 212 as usual. 214 The message formats in this document are specified using Routing 215 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 217 3. Motivation and Objectives for Stateful PCE 219 3.1. Motivation 221 [RFC8051] presents several use cases, demonstrating scenarios that 222 benefit from the deployment of a stateful PCE. The scenarios apply 223 equally to MPLS-TE and GMPLS deployments. 225 3.1.1. Background 227 Traffic engineering has been a goal of the MPLS architecture since 228 its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic 229 engineering system provided by [RFC3630], [RFC5305], and [RFC3209] 230 information about network resources utilization is only available as 231 total reserved capacity by traffic class on a per interface basis; 232 individual LSP state is available only locally on each LER for its 233 own LSPs. In most cases, this makes good sense, as distribution and 234 retention of total LSP state for all LERs within in the network would 235 be prohibitively costly. 237 Unfortunately, this visibility in terms of global LSP state may 238 result in a number of issues for some demand patterns, particularly 239 within a common setup and hold priority. This issue affects online 240 traffic engineering systems. 242 A sufficiently over-provisioned system will by definition have no 243 issues routing its demand on the shortest path. However, lowering 244 the degree to which network over-provisioning is required in order to 245 run a healthy, functioning network is a clear and explicit promise of 246 MPLS architecture. In particular, it has been a goal of MPLS to 247 provide mechanisms to alleviate congestion scenarios in which 248 "traffic streams are inefficiently mapped onto available resources; 249 causing subsets of network resources to become over-utilized while 250 others remain underutilized" ([RFC2702]). 252 3.1.2. Why a Stateful PCE? 254 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 255 "strict synchronization between the PCE and not only the network 256 states (in term of topology and resource information), but also the 257 set of computed paths and reserved resources in use in the network." 258 [RFC4655] also expressed a number of concerns with regard to a 259 stateful PCE, specifically: 261 o Any reliable synchronization mechanism would result in significant 262 control plane overhead 264 o Out-of-band TED synchronization would be complex and prone to race 265 conditions 267 o Path calculations incorporating total network state would be 268 highly complex 270 In general, stress on the control plane will be directly proportional 271 to the size of the system being controlled and the tightness of the 272 control loop, and indirectly proportional to the amount of over- 273 provisioning in terms of both network capacity and reservation 274 overhead. 276 Despite these concerns in terms of implementation complexity and 277 scalability, several TE algorithms exist today that have been 278 demonstrated to be extremely effective in large TE systems, providing 279 both rapid convergence and significant benefits in terms of 280 optimality of resource usage [MXMN-TE]. All of these systems share 281 at least two common characteristics: the requirement for both global 282 visibility of a flow (or in this case, a TE LSP) state and for 283 ordered control of path reservations across devices within the system 284 being controlled. While some approaches have been suggested in order 285 to remove the requirements for ordered control (See [MPLS-PC]), these 286 approaches are highly dependent on traffic distribution, and do not 287 allow for multiple simultaneous LSP priorities representing diffserv 288 classes. 290 The use cases described in [RFC8051] demonstrate a need for 291 visibility into global inter-PCC LSP state in PCE path computations, 292 and for PCE control of sequence and timing in altering LSP path 293 characteristics within and across PCEP sessions. 295 3.1.3. Protocol vs. Configuration 297 Note that existing configuration tools and protocols can be used to 298 set LSP state, such as a Command Line Interface (CLI) tool. However, 299 this solution has several shortcomings: 301 o Scale & Performance: configuration operations often have 302 transactional semantics which are typically heavyweight and often 303 require processing of additional configuration portions beyond the 304 state being directly acted upon, with corresponding cost in CPU 305 cycles, negatively impacting both PCC stability LSP update rate 306 capacity. 308 o Security: when a PCC opens a configuration channel allowing a PCE 309 to send configuration, a malicious PCE may take advantage of this 310 ability to take over the PCC. In contrast, the PCEP extensions 311 described in this document only allow a PCE control over a very 312 limited set of LSP attributes. 314 o Interoperability: each vendor has a proprietary information model 315 for configuring LSP state, which limits interoperability of a 316 stateful PCE with PCCs from different vendors. The PCEP 317 extensions described in this document allow for a common 318 information model for LSP state for all vendors. 320 o Efficient State Synchronization: configuration channels may be 321 heavyweight and unidirectional, therefore efficient state 322 synchronization between a PCC and a PCE may be a problem. 324 3.2. Objectives 326 The objectives for the protocol extensions to support stateful PCE 327 described in this document are as follows: 329 o Allow a single PCC to interact with a mix of stateless and 330 stateful PCEs simultaneously using the same protocol, i.e. PCEP. 332 o Support efficient LSP state synchronization between the PCC and 333 one or more active or passive stateful PCEs. 335 o Allow a PCC to delegate control of its LSPs to an active stateful 336 PCE such that a given LSP is under the control of a single PCE at 337 any given time. 339 * A PCC may revoke this delegation at any time during the 340 lifetime of the LSP. If LSP delegation is revoked while the 341 PCEP session is up, the PCC MUST notify the PCE about the 342 revocation. 344 * A PCE may return an LSP delegation at any point during the 345 lifetime of the PCEP session. If LSP delegation is returned by 346 the PCE while the PCEP session is up, the PCE MUST notify the 347 PCC about the returned delegation. 349 o Allow a PCE to control computation timing and update timing across 350 all LSPs that have been delegated to it. 352 o Enable uninterrupted operation of PCC's LSPs in the event of a PCE 353 failure or while control of LSPs is being transferred between 354 PCEs. 356 4. New Functions to Support Stateful PCEs 358 Several new functions are required in PCEP to support stateful PCEs. 359 A function can be initiated either from a PCC towards a PCE (C-E) or 360 from a PCE towards a PCC (E-C). The new functions are: 362 Capability advertisement (E-C,C-E): both the PCC and the PCE must 363 announce during PCEP session establishment that they support PCEP 364 Stateful PCE extensions defined in this document. 366 LSP state synchronization (C-E): after the session between the PCC 367 and a stateful PCE is initialized, the PCE must learn the state of 368 a PCC's LSPs before it can perform path computations or update LSP 369 attributes in a PCC. 371 LSP Update Request (E-C): a PCE requests modification of attributes 372 on a PCC's LSP. 374 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 375 whenever the state of an LSP changes. 377 LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 378 update LSP attributes on one or more LSPs; the PCE becomes the 379 authoritative source of the LSP's attributes as long as the 380 delegation is in effect (See Section 5.7); the PCC may withdraw 381 the delegation or the PCE may give up the delegation at any time. 383 Similarly to [RFC5440], no assumption is made about the discovery 384 method used by a PCC to discover a set of PCEs (e.g., via static 385 configuration or dynamic discovery) and on the algorithm used to 386 select a PCE. 388 5. Overview of Protocol Extensions 390 5.1. LSP State Ownership 392 In PCEP (defined in [RFC5440]), LSP state and operation are under the 393 control of a PCC (a PCC may be an LSR or a management station). 394 Attributes received from a PCE are subject to PCC's local policy. 395 The PCEP extensions described in this document do not change this 396 behavior. 398 An active stateful PCE may have control of a PCC's LSPs that were 399 delegated to it, but the LSP state ownership is retained by the PCC. 400 In particular, in addition to specifying values for LSP's attributes, 401 an active stateful PCE also decides when to make LSP modifications. 403 Retaining LSP state ownership on the PCC allows for: 405 o a PCC to interact with both stateless and stateful PCEs at the 406 same time 408 o a stateful PCE to only modify a small subset of LSP parameters, 409 i.e. to set only a small subset of the overall LSP state; other 410 parameters may be set by the operator, for example through command 411 line interface (CLI) commands 413 o a PCC to revert delegated LSP to an operator-defined default or to 414 delegate the LSPs to a different PCE, if the PCC get disconnected 415 from a PCE with currently delegated LSPs 417 5.2. New Messages 419 In this document, we define the following new PCEP messages: 421 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 422 to a PCE to report the status of one or more LSPs. Each LSP State 423 Report in a PCRpt message MAY contain the actual LSP's path, 424 bandwidth, operational and administrative status, etc. An LSP 425 Status Report carried on a PCRpt message is also used in 426 delegation or revocation of control of an LSP to/from a PCE. The 427 PCRpt message is described in Section 6.1. 429 Path Computation Update Request (PCUpd): a PCEP message sent by a 430 PCE to a PCC to update LSP parameters, on one or more LSPs. Each 431 LSP Update Request on a PCUpd message MUST contain all LSP 432 parameters that a PCE wishes to be set for a given LSP. An LSP 433 Update Request carried on a PCUpd message is also used to return 434 LSP delegations if at any point PCE no longer desires control of 435 an LSP. The PCUpd message is described in Section 6.2. 437 The new functions defined in Section 4 are mapped onto the new 438 messages as shown in the following table. 440 +----------------------------------------+--------------+ 441 | Function | Message | 442 +----------------------------------------+--------------+ 443 | Capability Advertisement (E-C,C-E) | Open | 444 | State Synchronization (C-E) | PCRpt | 445 | LSP State Report (C-E) | PCRpt | 446 | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | 447 | LSP Update Request (E-C) | PCUpd | 448 +----------------------------------------+--------------+ 450 Table 1: New Function to Message Mapping 452 5.3. Error Reporting 454 Error reporting is done using the procedures defined in [RFC5440], 455 and reusing the applicable error types and error values of [RFC5440] 456 wherever appropriate. The current document defines new error values 457 for several error types to cover failures specific to stateful PCE. 459 5.4. Capability Advertisement 461 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 462 advertise their support of stateful PCEP extensions. A PCEP Speaker 463 includes the "Stateful PCE Capability" TLV, described in 464 Section 7.1.1, in the OPEN Object to advertise its support for PCEP 465 stateful extensions. The Stateful Capability TLV includes the 'LSP 466 Update' Flag that indicates whether the PCEP Speaker supports LSP 467 parameter updates. 469 The presence of the Stateful PCE Capability TLV in PCC's OPEN Object 470 indicates that the PCC is willing to send LSP State Reports whenever 471 LSP parameters or operational status changes. 473 The presence of the Stateful PCE Capability TLV in PCE's OPEN message 474 indicates that the PCE is interested in receiving LSP State Reports 475 whenever LSP parameters or operational status changes. 477 The PCEP extensions for stateful PCEs MUST NOT be used if one or both 478 PCEP Speakers have not included the Stateful PCE Capability TLV in 479 their respective OPEN message. If the PCEP Speaker on the PCC 480 supports the extensions of this draft but did not advertise this 481 capability, then upon receipt of PCUpd message from the PCE, it MUST 482 generate a PCErr with error-type 19 (Invalid Operation), error-value 483 2 (Attempted LSP Update Request if the stateful PCE capability was 484 not advertised)(see Section 8.5) and it SHOULD terminate the PCEP 485 session. If the PCEP Speaker on the PCE supports the extensions of 486 this draft but did not advertise this capability, then upon receipt 487 of a PCRpt message from the PCC, it MUST generate a PCErr with error- 488 type 19 (Invalid Operation), error-value 5 (Attempted LSP State 489 Report if stateful PCE capability was not advertised) (see 490 Section 8.5) and it SHOULD terminate the PCEP session. 492 LSP delegation and LSP update operations defined in this document may 493 only be used if both PCEP Speakers set the LSP-UPDATE-CAPABILITY Flag 494 in the "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. 495 If this is not the case and LSP delegation or LSP update operations 496 are attempted, then a PCErr with error-type 19 (Invalid Operation) 497 and error-value 1 (Attempted LSP Update Request for a non-delegated 498 LSP) (see Section 8.5) MUST be generated. Note that, even if one of 499 the PCEP speakers does not set the LSP-UPDATE-CAPABILITY flag in its 500 "Stateful Capability" TLV, a PCE can still operate as a passive 501 stateful PCE by accepting LSP State Reports from the PCC in order to 502 build and maintain an up to date view of the state of the PCC's LSPs. 504 5.5. IGP Extensions for Stateful PCE Capabilities Advertisement 506 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 507 are either LSRs or servers also participating in the IGP, an 508 effective mechanism for PCE discovery within an IGP routing domain 509 consists of utilizing IGP advertisements. Extensions for the 510 advertisement of PCE Discovery Information are defined for OSPF and 511 for IS-IS in [RFC5088] and [RFC5089] respectively. 513 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 514 TLV used to advertise PCE capabilities. It MAY be present within the 515 PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] 516 provide the description and processing rules for this sub-TLV when 517 carried within OSPF and IS-IS, respectively. 519 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 520 reference: 522 Type: 5 524 Length: Multiple of 4. 526 Value: This contains an array of units of 32 bit flags with the most 527 significant bit as 0. Each bit represents one PCE capability. 529 PCE capability bits are defined in [RFC5088]. This document defines 530 new capability bits for the stateful PCE as follows: 532 Bit Capability 533 11 Active Stateful PCE capability 534 12 Passive Stateful PCE capability 536 Note that while active and passive stateful PCE capabilities may be 537 advertised during discovery, PCEP Speakers that wish to use stateful 538 PCEP MUST negotiate stateful PCEP capabilities during PCEP session 539 setup, as specified in the current document. A PCC MAY initiate 540 stateful PCEP capability negotiation at PCEP session setup even if it 541 did not receive any IGP PCE capability advertisements. 543 5.6. State Synchronization 545 The purpose of State Synchronization is to provide a checkpoint-in- 546 time state replica of a PCC's LSP state in a PCE. State 547 Synchronization is performed immediately after the Initialization 548 phase ([RFC5440]). 550 During State Synchronization, a PCC first takes a snapshot of the 551 state of its LSPs state, then sends the snapshot to a PCE in a 552 sequence of LSP State Reports. Each LSP State Report sent during 553 State Synchronization has the SYNC Flag in the LSP Object set to 1. 554 The set of LSPs for which state is synchronized with a PCE is 555 determined by the PCC's local configuration (see more details in 556 Section 9.1) and MAY also be determined by stateful PCEP capabilities 557 defined in other documents, such as 558 [I-D.ietf-pce-stateful-sync-optimizations]. 560 The end of synchronization marker is a PCRpt message with the SYNC 561 Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved 562 value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT 563 include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- 564 IDENTIFIERS TLV with the special value of all zeroes. The PCRpt 565 message MUST include an empty ERO as its intended path and SHOULD NOT 566 include the optional RRO object for its actual path. If the PCC has 567 no state to synchronize, it SHOULD only send the end of 568 synchronization marker. 570 A PCE SHOULD NOT send PCUpd messages to a PCC before State 571 Synchronization is complete. A PCC SHOULD NOT send PCReq messages to 572 a PCE before State Synchronization is complete. This is to allow the 573 PCE to get the best possible view of the network before it starts 574 computing new paths. 576 Either the PCE or the PCC MAY terminate the session using the PCEP 577 session termination procedures during the synchronization phase. If 578 the session is terminated, the PCE MUST clean up state it received 579 from this PCC. The session reestablishment MUST be re-attempted per 580 the procedures defined in [RFC5440], including use of a back-off 581 timer. 583 If the PCC encounters a problem which prevents it from completing the 584 LSP state synchronization, it MUST send a PCErr message with error- 585 type 20 (LSP State Synchronization Error) and error-value 5 586 (indicating an internal PCC error) to the PCE and terminate the 587 session. 589 The PCE does not send positive acknowledgements for properly received 590 synchronization messages. It MUST respond with a PCErr message with 591 error-type 20 (LSP State Synchronization Error) and error-value 1 592 (indicating an error in processing the PCRpt) (see Section 8.5) if it 593 encounters a problem with the LSP State Report it received from the 594 PCC and it MUST terminate the session. 596 A PCE implementing a limit on the resources a single PCC can occupy, 597 MUST send a PCNtf message with Notification Type 4 (Stateful PCE 598 resource limit exceeded) and Notification Value 1 (Entering resource 599 limit exceeded state) in response to the PCRpt message triggering 600 this condition in the synchronization phase and MUST terminate the 601 session. 603 The successful State Synchronization sequence is shown in Figure 1. 605 +-+-+ +-+-+ 606 |PCC| |PCE| 607 +-+-+ +-+-+ 608 | | 609 |-----PCRpt, SYNC=1----->| (Sync start) 610 | | 611 |-----PCRpt, SYNC=1----->| 612 | . | 613 | . | 614 | . | 615 |-----PCRpt, SYNC=1----->| 616 | . | 617 | . | 618 | . | 619 | | 620 |-----PCRpt, SYNC=0----->| (End of sync marker 621 | | LSP State Report 622 | | for PLSP-ID=0) 623 | | (Sync done) 625 Figure 1: Successful state synchronization 627 The sequence where the PCE fails during the State Synchronization 628 phase is shown in Figure 2. 630 +-+-+ +-+-+ 631 |PCC| |PCE| 632 +-+-+ +-+-+ 633 | | 634 |-----PCRpt, SYNC=1----->| 635 | | 636 |-----PCRpt, SYNC=1----->| 637 | . | 638 | . | 639 | . | 640 |-----PCRpt, SYNC=1----->| 641 | | 642 |-PCRpt, SYNC=1 | 643 | \ ,-PCErr | 644 | \ / | 645 | \/ | 646 | /\ | 647 | / `-------->| (Ignored) 648 |<--------` | 650 Figure 2: Failed state synchronization (PCE failure) 652 The sequence where the PCC fails during the State Synchronization 653 phase is shown in Figure 3. 655 +-+-+ +-+-+ 656 |PCC| |PCE| 657 +-+-+ +-+-+ 658 | | 659 |-----PCRpt, SYNC=1----->| 660 | | 661 |-----PCRpt, SYNC=1----->| 662 | . | 663 | . | 664 | . | 665 |-------- PCErr=? ------>| 666 | | 668 Figure 3: Failed state synchronization (PCC failure) 670 Optimizations to the synchronization procedures and alternate 671 mechanisms of providing the synchronization function are outside the 672 scope of this document and are discussed elsewhere (see 673 [I-D.ietf-pce-stateful-sync-optimizations]). 675 5.7. LSP Delegation 677 If during Capability advertisement both the PCE and the PCC have 678 indicated that they support LSP Update, then the PCC may choose to 679 grant the PCE a temporary right to update (a subset of) LSP 680 attributes on one or more LSPs. This is called "LSP Delegation", and 681 it MAY be performed at any time after the Initialization phase, 682 including during the State Synchronization phase. 684 A PCE MAY return an LSP delegation at any time if it no longer wishes 685 to update the LSP's state. A PCC MAY revoke an LSP delegation at any 686 time. Delegation, Revocation, and Return are done individually for 687 each LSP. 689 In the event of a delegation being rejected or returned by a PCE, the 690 PCC SHOULD react based on local policy. It can, for example, either 691 retry delegating to the same PCE using an exponentially increasing 692 timer or delegate to an alternate PCE. 694 5.7.1. Delegating an LSP 696 A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP 697 State Report to 1. If the PCE does not accept the LSP Delegation, it 698 MUST immediately respond with an empty LSP Update Request which has 699 the Delegate flag set to 0. If the PCE accepts the LSP Delegation, 700 it MUST set the Delegate flag to 1 when it sends an LSP Update 701 Request for the delegated LSP (note that this may occur at a later 702 time). The PCE MAY also immediately acknowledge a delegation by 703 sending an empty LSP Update Request which has the Delegate flag set 704 to 1. 706 The delegation sequence is shown in Figure 4. 708 +-+-+ +-+-+ 709 |PCC| |PCE| 710 +-+-+ +-+-+ 711 | | 712 |---PCRpt, Delegate=1--->| LSP Delegated 713 | | 714 |---PCRpt, Delegate=1--->| 715 | . | 716 | . | 717 | . | 718 |<--(PCUpd,Delegate=1)---| Delegation confirmed 719 | | 720 |---PCRpt, Delegate=1--->| 721 | | 723 Figure 4: Delegating an LSP 725 Note that for an LSP to remain delegated to a PCE, the PCC MUST set 726 the Delegate flag to 1 on each LSP State Report sent to the PCE. 728 5.7.2. Revoking a Delegation 730 5.7.2.1. Explicit Revocation 732 When a PCC decides that a PCE is no longer permitted to modify an 733 LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke 734 an LSP delegation at any time during the LSP's life time. A PCC 735 revoking an LSP delegation MAY immediately remove the updated 736 parameters provided by the PCE and revert to the operator-defined 737 parameters, but to avoid traffic loss, it SHOULD do so in a make- 738 before-break fashion. If the PCC has received but not yet acted on 739 PCUpd messages from the PCE for the LSP whose delegation is being 740 revoked, then it SHOULD ignore these PCUpd messages when processing 741 the message queue. All effects of all messages for which processing 742 started before the revocation took place MUST be allowed to complete 743 and the result MUST be given the same treatment as any LSP that had 744 been previously delegated to the PCE (e.g. the state MAY immediately 745 revert to the operator-defined parameters). 747 If a PCEP session with the PCE to which the LSP is delegated exists 748 in the UP state during the revocation, the PCC MUST notify that PCE 749 by sending an LSP State Report with the Delegate flag set to 0, as 750 shown in Figure 5. 752 +-+-+ +-+-+ 753 |PCC| |PCE| 754 +-+-+ +-+-+ 755 | | 756 |---PCRpt, Delegate=1--->| 757 | | 758 |<--(PCUpd,Delegate=1)---| Delegation confirmed 759 | . | 760 | . | 761 | . | 762 |---PCRpt, Delegate=0--->| PCC revokes delegation 763 | | 765 Figure 5: Revoking a Delegation 767 After an LSP delegation has been revoked, a PCE can no longer update 768 LSP's parameters; an attempt to update parameters of a non-delegated 769 LSP will result in the PCC sending a PCErr message with error-type 19 770 (Invalid Operation), error-value 1 (attempted LSP Update Request for 771 a non-delegated LSP) (see Section 8.5). 773 5.7.2.2. Revocation on Redelegation Timeout 775 When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC 776 MUST wait the time interval specified in Redelegation Timeout 777 Interval before revoking LSP delegations to that PCE and attempting 778 to redelegate LSPs to an alternate PCE. If a PCEP session with the 779 original PCE can be reestablished before the Redelegation Timeout 780 Interval timer expires, LSP delegations to the PCE remain intact. 782 Likewise, when a PCC's PCEP session with a PCE terminates 783 unexpectedly, and the PCC does not succeed in redelegating its LSPs, 784 the PCC MUST wait for the State Timeout Interval before flushing any 785 LSP state associated with that PCE. Note that the State Timeout 786 Interval timer may expire before the PCC has redelegated the LSPs to 787 another PCE, for example if a PCC is not connected to any active 788 stateful PCE or if no connected active stateful PCE accepts the 789 delegation. In this case, the PCC MUST flush any LSP state set by 790 the PCE upon expiration of the State Timeout Interval and revert to 791 operator-defined default parameters or behaviors. This operation 792 SHOULD be done in a make-before-break fashion. 794 The State Timeout Interval MUST be greater than or equal to the 795 Redelegation Timeout Interval and MAY be set to infinity (meaning 796 that until the PCC specifically takes action to change the parameters 797 set by the PCE, they will remain intact). 799 5.7.3. Returning a Delegation 801 In order to keep a delegation, a PCE MUST set the Delegate flag to 1 802 on each LSP Update Request sent to the PCC. A PCE that no longer 803 wishes to update an LSP's parameters SHOULD return the LSP delegation 804 back to the PCC by sending an empty LSP Update Request which has the 805 Delegate flag set to 0. If a PCC receives an LSP Update Request with 806 the Delegate flag set to 0 (whether the LSP Update Request is empty 807 or not), it MUST treat this as a delegation return. 809 +-+-+ +-+-+ 810 |PCC| |PCE| 811 +-+-+ +-+-+ 812 | | 813 |---PCRpt, Delegate=1--->| LSP delegated 814 | . | 815 | . | 816 | . | 817 |<--PCUpd, Delegate=0----| Delegation returned 818 | | 819 |---PCRpt, Delegate=0--->| No delegation for LSP 820 | | 822 Figure 6: Returning a Delegation 824 If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is 825 not connected to any active stateful PCE or if no connected active 826 stateful PCE accepts the delegation), the LSP delegation on the PCC 827 will time out within a configurable Redelegation Timeout Interval and 828 the PCC MUST flush any LSP state set by a PCE at the expiration of 829 the State Timeout Interval and revert to operator-defined default 830 parameters or behaviors. 832 5.7.4. Redundant Stateful PCEs 834 In a redundant configuration where one PCE is backing up another PCE, 835 the backup PCE may have only a subset of the LSPs in the network 836 delegated to it. The backup PCE does not update any LSPs that are 837 not delegated to it. In order to allow the backup to operate in a 838 hot-standby mode and avoid the need for state synchronization in case 839 the primary fails, the backup receives all LSP State Reports from a 840 PCC. When the primary PCE for a given LSP set fails, after expiry of 841 the Redelegation Timeout Interval, the PCC SHOULD delegate to the 842 redundant PCE all LSPs that had been previously delegated to the 843 failed PCE. Assuming that the State Timeout Interval had been 844 configured to be greater than the Redelegation Timeout Interval (as 845 MANDATORY), and assuming that the primary and redundant PCEs take 846 similar decisions, this delegation change will not cause any changes 847 to the LSP parameters. 849 5.7.5. Redelegation on PCE Failure 851 On failure, the goal is to: 1) avoid any traffic loss on the LSPs 852 that were updated by the PCE that crashed 2) minimize the churn in 853 the network in terms of ownership of the LSPs, 3) not leave any 854 "orphan" (undelegated) LSPs and 4) be able to control when the state 855 that was set by the PCE can be changed or purged. The values chosen 856 for the Redelegation Timeout and State Timeout values affect the 857 ability to accomplish these goals. 859 This section summarizes the behaviour with regards to LSP delegation 860 and LSP state on a PCE failure. 862 If the PCE crashes but recovers within the Redelegation Timeout, both 863 the delegation state and the LSP state are kept intact. 865 If the PCE crashes but does not recover within the Redelegation 866 Timeout, the delegation state is returned to the PCC. If the PCC can 867 redelegate the LSPs to another PCE, and that PCE accepts the 868 delegations, there will be no change in LSP state. If the PCC cannot 869 redelegate the LSPs to another PCE, then upon expiration of the State 870 Timeout Interval, the state set by the PCE is removed and the LSP 871 reverts to operator-defined parameters, which may cause a change in 872 the LSP state. Note that an operator may choose to use an infinite 873 State Timeout Interval if he wishes to maintain the PCE state 874 indefinitely. Note also that flushing the state should be 875 implemented using make-before-break to avoid traffic loss. 877 If there is a standby PCE, the Redelegation Timeout may be set to 0 878 through policy on the PCC, causing the LSPs to be redelegated 879 immediately to the PCC, which can delegate them immediately to the 880 standby PCE. Assuming that the PCC can redelegate the LSP to the 881 standby PCE within the State Timeout Interval, and assuming the 882 standby PCE takes similar decisions as the failed PCE, the LSP state 883 will be kept intact. 885 5.8. LSP Operations 887 5.8.1. Passive Stateful PCE Path Computation Request/Response 888 +-+-+ +-+-+ 889 |PCC| |PCE| 890 +-+-+ +-+-+ 891 | | 892 1) Path computation |----- PCReq message --->| 893 request sent to | |2) Path computation 894 PCE | | request received, 895 | | path computed 896 | | 897 |<---- PCRep message ----|3) Computed paths 898 | (Positive reply) | sent to the PCC 899 | (Negative reply) | 900 4) LSP State change | | 901 event | | 902 | | 903 5) LSP State Report |----- PCRpt message --->| 904 sent to all | . | 905 stateful PCEs | . | 906 | . | 907 6) Repeat for each |----- PCRpt message --->| 908 LSP state change | | 909 | | 911 Figure 7: Passive Stateful PCE Path Computation Request/Response 913 Once a PCC has successfully established a PCEP session with a passive 914 stateful PCE and the PCC's LSP state is synchronized with the PCE 915 (i.e. the PCE knows about all PCC's existing LSPs), if an event is 916 triggered that requires the computation of a set of paths, the PCC 917 sends a path computation request to the PCE ([RFC5440], 918 Section 4.2.3). The PCReq message MAY contain the LSP Object to 919 identify the LSP for which the path computation is requested. 921 Upon receiving a path computation request from a PCC, the PCE 922 triggers a path computation and returns either a positive or a 923 negative reply to the PCC ([RFC5440], Section 4.2.4). 925 Upon receiving a positive path computation reply, the PCC receives a 926 set of computed paths and starts to setup the LSPs. For each LSP, it 927 MAY send an LSP State Report carried on a PCRpt message to the PCE, 928 indicating that the LSP's status is "Going-up". 930 Once an LSP is up or active, the PCC MUST send an LSP State Report 931 carried on a PCRpt message to the PCE, indicating that the LSP's 932 status is 'Up' or 'Active' respectively. If the LSP could not be set 933 up, the PCC MUST send an LSP State Report indicating that the LSP is 934 "Down' and stating the cause of the failure. Note that due to timing 935 constraints, the LSP status may change from 'Going-up' to 'Up' (or 936 'Down') before the PCC has had a chance to send an LSP State Report 937 indicating that the status is 'Going-up'. In such cases, the PCC MAY 938 choose to only send the PCRpt indicating the latest status ('Active', 939 'Up' or 'Down'). 941 Upon receiving a negative reply from a PCE, a PCC MAY resend a 942 modified request or take any other appropriate action. For each 943 requested LSP, it SHOULD also send an LSP State Report carried on a 944 PCRpt message to the PCE, indicating that the LSP's status is 'Down'. 946 There is no direct correlation between PCRep and PCRpt messages. For 947 a given LSP, multiple LSP State Reports will follow a single PCRep 948 message, as a PCC notifies a PCE of the LSP's state changes. 950 A PCC MUST send each LSP State Report to each stateful PCE that is 951 connected to the PCC. 953 Note that a single PCRpt message MAY contain multiple LSP State 954 Reports. 956 The passive stateful model for stateful PCEs is described in 957 [RFC4655], Section 6.8. 959 5.8.2. Switching from Passive Stateful to Active Stateful 961 This section deals with the scenario of an LSP transitioning from a 962 passive stateful to an active stateful mode of operation. When the 963 LSP has no working path, prior to delegating the LSP, the PCC MUST 964 first use the procedure defined in Section 5.8.1 to request the 965 initial path from the PCE. This is required because the action of 966 delegating the LSP to a PCE using a PCRpt message is not an explicit 967 request to the PCE to compute a path for the LSP. The only explicit 968 way for a PCC to request a path from PCE is to send a PCReq message. 969 The PCRpt message MUST NOT be used by the PCC to attempt to request a 970 path from the PCE. 972 When the LSP is delegated after its setup, it may be useful for the 973 PCC to communicate to the PCE the locally configured intended 974 configuration parameters, so that the PCE may reuse them in its 975 computations. Such parameters MAY be acquired through an out of band 976 channel, or MAY be communicated in the PCRpt message delegating the 977 LSPs, by including them as part of the intented-attribute-list as 978 explained in Section 6.1. An implementation MAY allow policies on 979 the PCC to determine the configuration parameters to be sent to the 980 PCE. 982 5.8.3. Active Stateful PCE LSP Update 984 +-+-+ +-+-+ 985 |PCC| |PCE| 986 +-+-+ +-+-+ 987 | | 988 1) LSP State |-- PCRpt, Delegate=1 -->| 989 Synchronization | . | 990 | . |2) PCE decides to 991 | . | update the LSP 992 | | 993 |<---- PCUpd message ----|3) PCUpd message sent 994 | | to PCC 995 | | 996 | | 997 4) LSP State Report |---- PCRpt message ---->| 998 sent(->Going-up) | . | 999 | . | 1000 | . | 1001 5) LSP State Report |---- PCRpt message ---->| 1002 sent (->Up|Down) | | 1003 | | 1005 Figure 8: Active Stateful PCE 1007 Once a PCC has successfully established a PCEP session with an active 1008 stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. 1009 the PCE knows about all PCC's existing LSPs). After LSPs have been 1010 delegated to the PCE, the PCE can modify LSP parameters of delegated 1011 LSPs. 1013 To update an LSP, a PCE MUST send the PCC an LSP Update Request using 1014 a PCUpd message. The LSP Update Request contains a variety of 1015 objects that specify the set of constraints and attributes for the 1016 LSP's path. Each LSP Update Request MUST have a unique identifier, 1017 the SRP-ID-number, carried in the SRP (Stateful PCE Request 1018 Parameters) Object described in Section 7.2. The SRP-ID-number is 1019 used to correlate errors and state reports to LSP Update Requests. A 1020 single PCUpd message MAY contain multiple LSP Update Requests. 1022 Upon receiving a PCUpd message the PCC starts to setup LSPs specified 1023 in LSP Update Requests carried in the message. For each LSP, it MAY 1024 send an LSP State Report carried on a PCRpt message to the PCE, 1025 indicating that the LSP's status is 'Going-up'. If the PCC decides 1026 that the LSP parameters proposed in the PCUpd message are 1027 unacceptable, it MUST report this error by including the LSP-ERROR- 1028 CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable 1029 parameters" in the LSP object in the PCRpt message to the PCE. Based 1030 on local policy, it MAY react further to this error by revoking the 1031 delegation. If the PCC receives a PCUpd message for an LSP object 1032 identified with a PLSP-ID that does not exist on the PCC, it MUST 1033 generate a PCErr with error-type 19 (Invalid Operation), error-value 1034 3, (Attempted LSP Update Request for an LSP identified by an unknown 1035 PSP-ID) (see Section 8.5). 1037 Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt 1038 message) to the PCE, indicating that the LSP's status is 'Up'. If 1039 the LSP could not be set up, the PCC MUST send an LSP State Report 1040 indicating that the LSP is 'Down' and stating the cause of the 1041 failure. A PCC MAY compress LSP State Reports to only reflect the 1042 most up to date state, as discussed in the previous section. 1044 A PCC MUST send each LSP State Report to each stateful PCE that is 1045 connected to the PCC. 1047 PCErr and PCRpt messages triggered as a result of a PCUpd message 1048 MUST include the SRP-ID-number from the PCUpd. This provides 1049 correlation of requests and errors and acknowledgement of state 1050 processing. The PCC MAY compress state when processing PCUpd. In 1051 this case, receipt of a higher SRP-ID-number implicitly acknowledges 1052 processing all the updates with lower SRP-ID-number for the specific 1053 LSP (as per Section 7.2). 1055 A PCC MUST NOT send to any PCE a Path Computation Request for a 1056 delegated LSP. Should the PCC decide it wants to issue a Path 1057 Computation Request on a delegated LSP, it MUST perform Delegation 1058 Revocation procedure first. 1060 5.9. LSP Protection 1062 LSP protection and interaction with stateful PCE, as well as the 1063 extensions necessary to implement this functionality will be 1064 discussed in a separate document. 1066 5.10. PCEP Sessions 1068 A permanent PCEP session MUST be established between a stateful PCE 1069 and the PCC. In the case of session failure, session reestablishment 1070 MUST be re-attempted per the procedures defined in [RFC5440]. 1072 6. PCEP Messages 1074 As defined in [RFC5440], a PCEP message consists of a common header 1075 followed by a variable-length body made of a set of objects. For 1076 each PCEP message type, a set of rules is defined that specify the 1077 set of objects that the message can carry. 1079 6.1. The PCRpt Message 1081 A Path Computation LSP State Report message (also referred to as 1082 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 1083 current state of an LSP. A PCRpt message can carry more than one LSP 1084 State Reports. A PCC can send an LSP State Report either in response 1085 to an LSP Update Request from a PCE, or asynchronously when the state 1086 of an LSP changes. The Message-Type field of the PCEP common header 1087 for the PCRpt message is 10. 1089 The format of the PCRpt message is as follows: 1091 ::= 1092 1093 Where: 1095 ::= [] 1097 ::= [] 1098 1099 1100 Where: 1101 ::= 1102 [] 1103 1105 ::=[] 1106 [] 1108 Where: 1109 is represented by the ERO object defined in 1110 section 7.9 of [RFC5440]. 1111 consists of the actual computed and 1112 signaled values of the and objects 1113 defined in [RFC5440]. 1114 is represented by the RRO object defined in 1115 section 7.10 of [RFC5440]. 1116 is the attribute-list defined in 1117 section 6.5 of [RFC5440] and extended by PCEP extensions. 1119 The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message 1120 is not in response to a PCupd message, the SRP object MAY be omitted. 1121 When the PCC does not include the SRP object, the PCE MUST treat this 1122 as an SRP object with an SRP-ID-number equal to the reserved value 1123 0x00000000. The reserved value 0x00000000 indicates that the state 1124 reported is not as a result of processing a PCUpd message. 1126 If the PCRpt message is in response to a PCUpd message, the SRP 1127 object MUST be included and the value of the SRP-ID-number in the SRP 1128 Object MUST be the same as that sent in the PCUpd message that 1129 triggered the state that is reported. If the PCC compressed several 1130 PCUpd messages for the same LSP by only processing the one with the 1131 highest number, then it should use the SRP-ID-number of that request. 1132 No state compression is allowed for state reporting, e.g. PCRpt 1133 messages MUST NOT be pruned from the PCC's egress queue even if 1134 subsequent operations on the same LSP have been completed before the 1135 PCRpt message has been sent to the TCP stack. The PCC MUST 1136 explicitly report state changes (including removal) for paths it 1137 manages. 1139 The LSP object (see Section 7.3) is REQUIRED, and it MUST be included 1140 in each LSP State Report on the PCRpt message. If the LSP object is 1141 missing, the receiving PCE MUST send a PCErr message with Error- 1142 type=6 (Mandatory Object missing) and Error-value 8 (LSP object 1143 missing). 1145 If the LSP transitioned to non-operational state, the PCC SHOULD 1146 include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error 1147 Code to report the error to the PCE. 1149 The intended path, represented by the ERO object, is REQUIRED. If 1150 the ERO object is missing, the receiving PCE MUST send a PCErr 1151 message with Error-type=6 (Mandatory Object missing) and Error-value 1152 9 (ERO object missing). The ERO may be empty if the PCE does not 1153 have a path for a delegated LSP. 1155 The actual path, represented by the RRO object, SHOULD be included in 1156 PCRpt by the PCC when the path is up or active, but MAY be omitted if 1157 the path is down due to a signaling error or another failure. 1159 The intended-attribute-list maps to the attribute-list in Section 6.5 1160 of [RFC5440] and is used to convey the requested parameters of the 1161 LSP path. This is needed in order to support the switch from passive 1162 to active stateful PCE as described in Section 5.8.2. When included 1163 as part of the intended-attribute-list, the meaning of the BANDWIDTH 1164 object is the requested bandwidth as intended by the operator. In 1165 this case, the BANDWIDTH Object-Type of 1 SHOULD be used. Similarly, 1166 to indicate a limiting constraint, the METRIC object SHOULD be 1167 included as part of the intended-attribute-list with the B flag set 1168 and with a specific metric value. To indicate the optimization 1169 metric, the METRIC object SHOULD be included as part of the intended- 1170 attribute-list with the B flag unset and the metric value set to 1171 zero. Note that the intended-attribute-list is optional and thus may 1172 be omitted. In this case, the PCE MAY use the values in the actual- 1173 attribute-list as the requested parameters for the path. 1175 The actual-attribute-list consists of the actual computed and 1176 signaled values of the BANDWIDTH and METRIC objects defined in 1177 [RFC5440]. When included as part of the actual-attribute-list, 1178 Object-Type 2 ([RFC5440]) SHOULD be used for the BANDWIDTH object and 1179 the C flag SHOULD be set in the METRIC object ([RFC5440]). 1181 A PCE may choose to implement a limit on the resources a single PCC 1182 can occupy. If a PCRpt is received that causes the PCE to exceed 1183 this limit, the PCE MUST notify the PCC using a PCNtf message with 1184 Notification Type 4 (Stateful PCE resource limit exceeded) and 1185 Notification Value 1 (Entering resource limit exceeded state) and 1186 MUST terminate the session. 1188 6.2. The PCUpd Message 1190 A Path Computation LSP Update Request message (also referred to as 1191 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 1192 attributes of an LSP. A PCUpd message can carry more than one LSP 1193 Update Request. The Message-Type field of the PCEP common header for 1194 the PCUpd message is 11. 1196 The format of a PCUpd message is as follows: 1198 ::= 1199 1200 Where: 1202 ::= [] 1204 ::= 1205 1206 1207 Where: 1208 ::= 1210 Where: 1211 is represented by the ERO object defined in 1212 section 7.9 of [RFC5440]. 1213 is the attribute-list defined in [RFC5440] 1214 and extended by PCEP extensions. 1216 There are three mandatory objects that MUST be included within each 1217 LSP Update Request in the PCUpd message: the SRP Object (see 1218 Section 7.2), the LSP object (see Section 7.3) and the ERO object (as 1219 defined in [RFC5440], which represents the intended path. If the SRP 1220 object is missing, the receiving PCC MUST send a PCErr message with 1221 Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP 1222 object missing). If the LSP object is missing, the receiving PCC 1223 MUST send a PCErr message with Error-type=6 (Mandatory Object 1224 missing) and Error-value=8 (LSP object missing). If the ERO object 1225 is missing, the receiving PCC MUST send a PCErr message with Error- 1226 type=6 (Mandatory Object missing) and Error-value=9 (ERO object 1227 missing). 1229 The ERO in the PCUpd may be empty if the PCE cannot find a valid path 1230 for a delegated LSP. One typical situation resulting in this empty 1231 ERO carried in the PCUpd message is that a PCE can no longer find a 1232 strict SRLG-disjoint path for a delegated LSP after a link failure. 1233 The PCC SHOULD implement a local policy to decide the appropriate 1234 action to be taken: either tear down the LSP, or revoke the 1235 delegation and use a locally computed path, or keep the existing LSP. 1237 A PCC only acts on an LSP Update Request if permitted by the local 1238 policy configured by the network manager. Each LSP Update Request 1239 that the PCC acts on results in an LSP setup operation. An LSP 1240 Update Request MUST contain all LSP parameters that a PCE wishes to 1241 be set for the LSP. A PCC MAY set missing parameters from locally 1242 configured defaults. If the LSP specified in the Update Request is 1243 already up, it will be re-signaled. 1245 The PCC SHOULD minimize the traffic interruption, and MAY use the 1246 make-before-break procedures described in [RFC3209] in order to 1247 achieve this goal. If the make-before-break procedures are used, two 1248 paths will briefly co-exist. The PCC MUST send separate PCRpt 1249 messages for each, identified by the LSP-IDENTIFIERS TLV. When the 1250 old path is torn down after the head end switches over the traffic, 1251 this event MUST be reported by sending a PCRpt message with the LSP- 1252 IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number 1253 that the PCC associates with this PCRpt MUST be 0x00000000. Thus, a 1254 make-before-break operation will typically result in at least two 1255 PCRpt messages, one for the new path and one for the removal of the 1256 old path (more messages may be possible if intermediate states are 1257 reported). 1259 If the path setup fails due to an RSVP signaling error, the error is 1260 reported to the PCE. The PCC will not attempt to resignal the path 1261 until it is prompted again by the PCE with a subsequent PCUpd 1262 message. 1264 A PCC MUST respond with an LSP State Report to each LSP Update 1265 Request it processed to indicate the resulting state of the LSP in 1266 the network (even if this processing did not result in changing the 1267 state of the LSP). The SRP-ID-number included in the PCRpt MUST 1268 match that in the PCUpd. A PCC MAY respond with multiple LSP State 1269 Reports to report LSP setup progress of a single LSP. In that case, 1270 the SRP-ID-number MUST be included for the first message, for 1271 subsequent messages the reserved value 0x00000000 SHOULD be used. 1273 Note that a PCC MUST process all LSP Update Requests - for example, 1274 an LSP Update Request is sent when a PCE returns delegation or puts 1275 an LSP into non-operational state. The protocol relies on TCP for 1276 message-level flow control. 1278 If the rate of PCUpd messages sent to a PCC for the same target LSP 1279 exceeds the rate at which the PCC can signal LSPs into the network, 1280 the PCC MAY perform state compression on its ingress queue. The 1281 compression algorithm is based on the fact that each PCUpd request 1282 contains the complete LSP state the PCE wishes to be set and works as 1283 follows: when the PCC starts processing a PCUpd message at the head 1284 of its ingress queue, it may search the queue forward for more recent 1285 PCUpd messages pertaining that particular LSP, prune all but the 1286 latest one from the queue and process only the last one as that 1287 request contains the most up-to-date desired state for the LSP. The 1288 PCC MUST NOT send PCRpt nor PCErr messages for requests which were 1289 pruned from the queue in this way. This compression step may be 1290 performed only while the LSP is not being signaled, e.g. if two PCUpd 1291 arrive for the same LSP in quick succession and the PCC started the 1292 signaling of the changes relevant to the first PCUpd, then it MUST 1293 wait until the signaling finishes (and report the new state via a 1294 PCRpt) before attempting to apply the changes indicated in the second 1295 PCUpd. 1297 Note also that it is up to the PCE to handle inter-LSP dependencies; 1298 for example, if ordering of LSP set-ups is required, the PCE has to 1299 wait for an LSP State Report for a previous LSP before starting the 1300 update of the next LSP. 1302 If the PCUpd cannot be satisfied (for example due to unsupported 1303 object or TLV), the PCC MUST respond with a PCErr message indicating 1304 the failure (see Section 7.3.3). 1306 6.3. The PCErr Message 1308 If the stateful PCE capability has been advertised on the PCEP 1309 session, the PCErr message MAY include the SRP object. If the error 1310 reported is the result of an LSP update request, then the SRP-ID- 1311 number MUST be the one from the PCUpd that triggered the error. If 1312 the error is unsolicited, the SRP object MAY be omitted. This is 1313 equivalent to including an SRP object with SRP-ID-number equal to the 1314 reserved value 0x00000000. 1316 The format of a PCErr message from [RFC5440] is extended as follows: 1318 ::= 1319 ( [] ) | 1320 [] 1322 ::=[] 1324 ::=[ | ] 1325 1327 ::=[] 1329 ::=[] 1331 ::=[] 1333 6.4. The PCReq Message 1335 A PCC MAY include the LSP object in the PCReq message (see 1336 Section 7.3) if the stateful PCE capability has been negotiated on a 1337 PCEP session between the PCC and a PCE. 1339 The definition of the PCReq message from [RFC5440] is extended to 1340 optionally include the LSP object after the END-POINTS object. The 1341 encoding from [RFC5440] will become: 1343 ::= 1344 [] 1345 1346 Where: 1348 ::=[] 1349 ::=[] 1351 ::= 1352 1353 [] 1354 [] 1355 [] 1356 [] 1357 [[]] 1358 [] 1359 [] 1361 6.5. The PCRep Message 1363 A PCE MAY include the LSP object in the PCRep message (see 1364 (Section 7.3) if the stateful PCE capability has been negotiated on a 1365 PCEP session between the PCC and the PCE and the LSP object was 1366 included in the corresponding PCReq message from the PCC. 1368 The definition of the PCRep message from [RFC5440] is extended to 1369 optionally include the LSP object after the RP object. The encoding 1370 from [RFC5440] will become: 1372 ::= 1373 1375 Where: 1377 ::=[] 1379 ::= 1380 [] 1381 [] 1382 [] 1383 [] 1385 7. Object Formats 1387 The PCEP objects defined in this document are compliant with the PCEP 1388 object format defined in [RFC5440]. The P flag and the I flag of the 1389 PCEP objects defined in the current document MUST be set to 0 on 1390 transmission and SHOULD be ignored on receipt since the P and I flags 1391 are exclusively related to path computation requests. 1393 7.1. OPEN Object 1395 This document defines one new optional TLV for use in the OPEN 1396 Object. 1398 7.1.1. Stateful PCE Capability TLV 1400 The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the 1401 OPEN Object for stateful PCE capability advertisement. Its format is 1402 shown in the following figure: 1404 0 1 2 3 1405 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 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Type=16 | Length=4 | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | Flags |U| 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 Figure 9: STATEFUL-PCE-CAPABILITY TLV format 1414 The type (16 bits) of the TLV is 16. The length field is 16 bit-long 1415 and has a fixed value of 4. 1417 The value comprises a single field - Flags (32 bits): 1419 U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag 1420 indicates that the PCC allows modification of LSP parameters; if 1421 set to 1 by a PCE, the U Flag indicates that the PCE is capable of 1422 updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be 1423 advertised by both a PCC and a PCE for PCUpd messages to be 1424 allowed on a PCEP session. 1426 Unassigned bits are considered reserved. They MUST be set to 0 on 1427 transmission and MUST be ignored on receipt. 1429 A PCEP speaker operating in passive stateful PCE mode advertises the 1430 stateful PCE capability with the U flag set to 0. A PCEP speaker 1431 operating in active stateful PCE mode advertises the stateful PCE 1432 capability with the U Flag set to 1. 1434 Advertisement of the stateful PCE capability implies support of LSPs 1435 that are signaled via RSVP, as well as the objects, TLVs and 1436 procedures defined in this document. 1438 7.2. SRP Object 1440 The SRP (Stateful PCE Request Parameters) object MUST be carried 1441 within PCUpd messages and MAY be carried within PCRpt and PCErr 1442 messages. The SRP object is used to correlate between update 1443 requests sent by the PCE and the error reports and state reports sent 1444 by the PCC. 1446 SRP Object-Class is 33. 1448 SRP Object-Type is 1. 1450 The format of the SRP object body is shown in Figure 10: 1452 0 1 2 3 1453 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 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Flags | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | SRP-ID-number | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | | 1460 // Optional TLVs // 1461 | | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 Figure 10: The SRP Object format 1466 The SRP object body has a variable length and may contain additional 1467 TLVs. 1469 Flags (32 bits): None defined yet. 1471 SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the 1472 current PCEP session uniquely identify the operation that the PCE has 1473 requested the PCC to perform on a given LSP. The SRP-ID-number is 1474 incremented each time a new request is sent to the PCC, and may wrap 1475 around. 1477 The values 0x00000000 and 0xFFFFFFFF are reserved. 1479 Optional TLVs MAY be included within the SRP object body. The 1480 specification of such TLVs is outside the scope of this document. 1482 Every request to update an LSP receives a new SRP-ID-number. This 1483 number is unique per PCEP session and is incremented each time an 1484 operation is requested from the PCE. Thus, for a given LSP there may 1485 be more than one SRP-ID-number unacknowledged at a given time. The 1486 value of the SRP-ID-number is echoed back by the PCC in PCErr and 1487 PCRpt messages to allow for correlation between requests made by the 1488 PCE and errors or state reports generated by the PCC. If the error 1489 or report were not as a result of a PCE operation (for example in the 1490 case of a link down event), the reserved value of 0x00000000 is used 1491 for the SRP-ID-number. The absence of the SRP object is equivalent 1492 to an SRP object with the reserved value of 0x00000000. An SRP-ID- 1493 number is considered unacknowledged and cannot be reused until a 1494 PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the 1495 same LSP. In case of SRP-ID-number wrapping the last SRP-ID-number 1496 before the wrapping MUST be explicitly acknowledged, to avoid a 1497 situation where SRP-ID-numbers remain unacknowledged after the wrap. 1499 This means that the PCC may need to issue two PCUpd messages on 1500 detecting a wrap. 1502 7.3. LSP Object 1504 The LSP object MUST be present within PCRpt and PCUpd messages. The 1505 LSP object MAY be carried within PCReq and PCRep messages if the 1506 stateful PCE capability has been negotiated on the session. The LSP 1507 object contains a set of fields used to specify the target LSP, the 1508 operation to be performed on the LSP, and LSP Delegation. It also 1509 contains a flag indicating to a PCE that the LSP state 1510 synchronization is in progress. This document focuses on LSPs that 1511 are signaled with RSVP, many of the TLVs used with the LSP object 1512 mirror RSVP state. 1514 LSP Object-Class is 32. 1516 LSP Object-Type is 1. 1518 The format of the LSP object body is shown in Figure 11: 1520 0 1 2 3 1521 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 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | PLSP-ID | Flag | O|A|R|S|D| 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 // TLVs // 1526 | | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 Figure 11: The LSP Object format 1531 PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC 1532 creates a unique PLSP-ID for each LSP that is constant for the 1533 lifetime of a PCEP session. The PCC will advertise the same PLSP-ID 1534 on all PCEP sessions it maintains at a given times. The mapping of 1535 the Symbolic Path Name to PLSP-ID is communicated to the PCE by 1536 sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All 1537 subsequent PCEP messages then address the LSP by the PLSP-ID. The 1538 values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a 1539 value that is constant for the lifetime of the PCEP session, during 1540 which time for an RSVP-signaled LSP there might be a different RSVP 1541 identifiers (LSP-id, tunnel-id) allocated to it. 1543 Flags (12 bits), starting from the least significant bit: 1545 D (Delegate - 1 bit): On a PCRpt message, the D Flag set to 1 1546 indicates that the PCC is delegating the LSP to the PCE. On a 1547 PCUpd message, the D flag set to 1 indicates that the PCE is 1548 confirming the LSP Delegation. To keep an LSP delegated to the 1549 PCE, the PCC must set the D flag to 1 on each PCRpt message for 1550 the duration of the delegation - the first PCRpt with the D flag 1551 set to 0 revokes the delegation. To keep the delegation, the PCE 1552 must set the D flag to 1 on each PCUpd message for the duration of 1553 the delegation - the first PCUpd with the D flag set to 0 returns 1554 the delegation. 1556 S (SYNC - 1 bit): The S Flag MUST be set to 1 on each PCRpt sent 1557 from a PCC during State Synchronization. The S Flag MUST be set 1558 to 0 in other messages sent from the PCC. When sending a PCUpd 1559 message, the PCE MUST set the S Flag to 0. 1561 R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1562 LSP has been removed from the PCC and the PCE SHOULD remove all 1563 state from its database. Upon receiving an LSP State Report with 1564 the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD 1565 remove all state for the path identified by the LSP-IDENTIFIERS 1566 TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is 1567 used, the PCE SHOULD remove all state for the PLSP-ID from its 1568 database. When sending a PCUpd message, the PCE MUST set the R 1569 Flag to 0. 1571 A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates 1572 the PCC's target operational status for this LSP. On PCUpd 1573 messages, the A Flag indicates the LSP status that the PCE desires 1574 for this LSP. In both cases, a value of '1' means that the 1575 desired operational state is active, and a value of '0' means that 1576 the desired operational state is inactive. A PCC ignores the A 1577 flag on a PCUpd message unless the operator's policy allows the 1578 PCE to control the corresponding LSP's administrative state. 1580 O(Operational - 3 bits): On PCRpt messages, the O Field represents 1581 the operational status of the LSP. 1583 The following values are defined: 1585 0 - DOWN: not active. 1587 1 - UP: signalled. 1589 2 - ACTIVE: up and carrying traffic. 1591 3 - GOING-DOWN: LSP is being torn down, resources are being 1592 released. 1594 4 - GOING-UP: LSP is being signalled. 1596 5-7 - Reserved: these values are reserved for future use. 1598 Unassigned bits are considered reserved. They MUST be set to 0 on 1599 transmission and MUST be ignored on receipt. When sending a PCUpd 1600 message, the PCE MUST set the O Field to 0. 1602 TLVs that may be included in the LSP Object are described in the 1603 following sections. Other optional TLVs, that are not defined in 1604 this document, MAY also be included within the LSP Object body. 1606 7.3.1. LSP-IDENTIFIERS TLVs 1608 The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt 1609 messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will 1610 generate an error with error-type 6 (mandatory object missing) and 1611 error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. 1612 The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd 1613 messages for RSVP-signaled LSPs. The special value of all zeros for 1614 this TLV is used to refer to all paths pertaining to a particular 1615 PLSP-ID. There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one 1616 for IPv6. 1618 It is the responsibility of the PCC to send to the PCE the 1619 identifiers for each RSVP incarnation of the tunnel. For example, in 1620 a make-before-break scenario, the PCC MUST send a separate PCRpt for 1621 the old and for the reoptimized paths, and explicitly report removal 1622 of any of these paths using the R bit in the LSP object. 1624 The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 1625 figure: 1627 0 1 2 3 1628 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 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Type=18 | Length=16 | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | IPv4 Tunnel Sender Address | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 | LSP ID | Tunnel ID | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Extended Tunnel ID | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | IPv4 Tunnel Endpoint Address | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 Figure 12: IPV4-LSP-IDENTIFIERS TLV format 1643 The type (16 bits) of the TLV is 18. The length field is 16 bit-long 1644 and has a fixed value of 16. The value contains the following 1645 fields: 1647 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 1648 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 1649 Sender Template Object. 1651 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1652 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 1653 Object. A value of 0 MUST be used if the LSP is not yet signaled. 1655 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1656 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 1658 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 1659 identifier defined in [RFC3209], Section 4.6.1.1 for the 1660 LSP_TUNNEL_IPv4 Session Object. 1662 IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 1663 address, as defined in [RFC3209], Section 4.6.1.1 for the 1664 LSP_TUNNEL_IPv4 Sender Template Object. 1666 The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following 1667 figure: 1669 0 1 2 3 1670 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 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | Type=19 | Length=52 | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | | 1675 + + 1676 | IPv6 tunnel sender address | 1677 + (16 octets) + 1678 | | 1679 + + 1680 | | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | LSP ID | Tunnel ID | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 | | 1685 + + 1686 | Extended Tunnel ID | 1687 + (16 octets) + 1688 | | 1689 + + 1690 | | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | | 1693 + + 1694 | IPv6 tunnel endpoint address | 1695 + (16 octets) + 1696 | | 1697 + + 1698 | | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 Figure 13: IPV6-LSP-IDENTIFIERS TLV format 1703 The type (16 bits) of the TLV is 19. The length field is 16 bit-long 1704 and has a fixed value of 52. The value contains the following 1705 fields: 1707 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 1708 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 1709 Sender Template Object. 1711 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1712 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 1713 Object. A value of 0 MUST be used if the LSP is not yet signaled. 1715 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1716 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 1718 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 1719 identifier defined in [RFC3209], Section 4.6.1.2 for the 1720 LSP_TUNNEL_IPv6 Session Object. 1722 IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 1723 address, as defined in [RFC3209], Section 4.6.1.2 for the 1724 LSP_TUNNEL_IPv6 Session Object. 1726 The Tunnel ID remains constant over the life time of a tunnel. 1728 7.3.2. Symbolic Path Name TLV 1730 Each LSP MUST have a symbolic path name that is unique in the PCC. 1731 The symbolic path name is a human-readable string that identifies an 1732 LSP in the network. The symbolic path name MUST remain constant 1733 throughout an LSP's lifetime, which may span across multiple 1734 consecutive PCEP sessions and/or PCC restarts. The symbolic path 1735 name MAY be specified by an operator in a PCC's configuration. If 1736 the operator does not specify a unique symbolic name for an LSP, then 1737 the PCC MUST auto-generate one. 1739 The PCE uses the symbolic path name as a stable identifier for the 1740 LSP. If the PCEP session restarts, or the PCC restarts, or the PCC 1741 re-delegates the LSP to a different PCE, the symbolic path name for 1742 the LSP remains constant and can be used to correlate across the PCEP 1743 session instances. 1745 The other protocol identifiers for the LSP cannot reliably be used to 1746 identify the LSP across multiple PCEP sessions, for the following 1747 reasons. 1749 o The PLSP-ID is unique only within the scope of a single PCEP 1750 session. 1752 o The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs 1753 that are signalled with RSVP-TE, and may change during the 1754 lifetime of the LSP. 1756 The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the 1757 LSP State Report (PCRpt) message when during a given PCEP session an 1758 LSP is first reported to a PCE. A PCC sends to a PCE the first LSP 1759 State Report either during State Synchronization, or when a new LSP 1760 is configured at the PCC. 1762 The initial PCRpt creates a binding between the symbolic path name 1763 and the PLSP-ID for the LSP which lasts for the duration of the PCEP 1764 session. The PCC MAY omit the symbolic path name from subsequent LSP 1765 State Reports for that LSP on that PCEP session, and just use the 1766 PLSP-ID. 1768 The format of the SYMBOLIC-PATH-NAME TLV is shown in the following 1769 figure: 1771 0 1 2 3 1772 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 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | Type=17 | Length (variable) | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | | 1777 // Symbolic Path Name // 1778 | | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 Figure 14: SYMBOLIC-PATH-NAME TLV format 1783 Type (16 bits): The type is 17. 1785 Length (16 bits): indicates the total length of the TLV in octets and 1786 MUST be greater than 0. The TLV MUST be zero-padded so that the TLV 1787 is 4-octet aligned. 1789 Symbolic Path Name (variable): symbolic name for the LSP, unique in 1790 the PCC. It SHOULD be a string of printable ASCII characters and 1791 SHOULD be NULL-terminated. The Symbolic Path Name (including its 1792 NULL terminator) MUST be padded to 4-bytes alignment; the padding 1793 itself MUST NOT be included in the Length field. 1795 7.3.3. LSP Error Code TLV 1797 The LSP Error code TLV is an optional TLV for use in the LSP object 1798 to convey error information. When an LSP Update Request fails, an 1799 LSP State Report MUST be sent to report the current state of the LSP, 1800 and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for 1801 the failure. Similarly, when a PCRpt is sent as a result of an LSP 1802 transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD 1803 be included to indicate the reason for the transition. 1805 The format of the LSP-ERROR-CODE TLV is shown in the following 1806 figure: 1808 0 1 2 3 1809 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 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | Type=20 | Length=4 | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | LSP Error Code | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 Figure 15: LSP-ERROR-CODE TLV format 1818 The type (16 bits) of the TLV is 20. The length field is 16 bit-long 1819 and has a fixed value of 4. The value contains an error code that 1820 indicates the cause of the failure. 1822 The following LSP Error Codes are currently defined: 1824 Value Meaning 1825 1 Unknown reason 1826 2 Limit reached for PCE-controlled LSPs 1827 3 Too many pending LSP update requests 1828 4 Unacceptable parameters 1829 5 Internal error 1830 6 LSP administratively brought down 1831 7 LSP preempted 1832 8 RSVP signaling error 1834 7.3.4. RSVP Error Spec TLV 1836 The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object 1837 to carry RSVP error information. It includes the RSVP ERROR_SPEC or 1838 USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned 1839 to the PCC from a downstream node. If the set up of an LSP fails at 1840 a downstream node which returned an ERROR_SPEC to the PCC, the PCC 1841 SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with 1842 LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV 1843 with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object. 1845 The format of the RSVP-ERROR-SPEC TLV is shown in the following 1846 figure: 1848 0 1 2 3 1849 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 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | Type=21 | Length (variable) | 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | | 1854 + RSVP ERROR_SPEC or USER_ERROR_SPEC Object + 1855 | | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 Figure 16: RSVP-ERROR-SPEC TLV format 1860 Type (16 bits): The type is 21. 1862 Length (16 bits): indicates the total length of the TLV in octets. 1863 The TLV MUST be zero-padded so that the TLV is 4-octet aligned. 1865 Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC 1866 Object: as specified in [RFC2205] and [RFC5284], including the object 1867 header. 1869 8. IANA Considerations 1871 This document requests IANA actions to allocate code points for the 1872 protocol elements defined in this document. 1874 8.1. PCE Capabilities in IGP Advertisements 1876 IANA is requested to confirm the early allocation of the following 1877 bits in the OSPF Parameters "PCE Capability Flags" registry, and to 1878 update the reference in the registry to point to this document, when 1879 it is an RFC: 1881 Bit Meaning Reference 1882 11 Active Stateful PCE This document 1883 capability 1884 12 Passive Stateful PCE This document 1885 capability 1887 8.2. PCEP Messages 1889 IANA is requested to confirm the early allocation of the following 1890 message types within the "PCEP Messages" sub-registry of the PCEP 1891 Numbers registry, and to update the reference in the registry to 1892 point to this document, when it is an RFC: 1894 Value Meaning Reference 1895 10 Report This document 1896 11 Update This document 1898 8.3. PCEP Objects 1900 IANA is requested to confirm the early allocation of the following 1901 object-class values and object types within the "PCEP Objects" sub- 1902 registry of the PCEP Numbers registry, and to update the reference in 1903 the registry to point to this document, when it is an RFC:. 1905 Object-Class Value Name Reference 1907 32 LSP This document 1908 Object-Type 1909 1 1910 33 SRP This document 1911 Object-Type 1912 1 1914 8.4. LSP Object 1916 This document requests that a new sub-registry, named "LSP Object 1917 Flag Field", is created within the "Path Computation Element Protocol 1918 (PCEP) Numbers" registry to manage the Flag field of the LSP object. 1919 New values are to be assigned by Standards Action [RFC5226]. Each 1920 bit should be tracked with the following qualities: 1922 o Bit number (counting from bit 0 as the most significant bit) 1924 o Capability description 1926 o Defining RFC 1928 The following values are defined in this document: 1930 Bit Description Reference 1932 0-4 Reserved This document 1933 5-7 Operational (3 bits) This document 1934 8 Administrative This document 1935 9 Remove This document 1936 10 SYNC This document 1937 11 Delegate This document 1939 8.5. PCEP-Error Object 1941 IANA is requested to confirm the early allocation of the following 1942 Error Types and Error Values within the "PCEP-ERROR Object Error 1943 Types and Values" sub-registry of the PCEP Numbers registry, and to 1944 update the reference in the registry to point to this document, when 1945 it is an RFC: 1947 Error-Type Meaning 1948 6 Mandatory Object missing 1950 Error-value=8: LSP Object missing 1951 Error-value=9: ERO Object missing 1952 Error-value=10: SRP Object missing 1953 Error-value=11: LSP-IDENTIFIERS TLV missing 1954 19 Invalid Operation 1956 Error-value=1: Attempted LSP Update Request for a non- 1957 delegated LSP. The PCEP-ERROR Object 1958 is followed by the LSP Object that 1959 identifies the LSP. 1960 Error-value=2: Attempted LSP Update Request if the 1961 stateful PCE capability was not 1962 advertised. 1963 Error-value=3: Attempted LSP Update Request for an LSP 1964 identified by an unknown PLSP-ID. 1965 Error-value=5: Attempted LSP State Report if stateful 1966 PCE capability was not advertised. 1967 20 LSP State synchronization error. 1969 Error-value=1: A PCE indicates to a PCC that it can 1970 not process (an otherwise valid) LSP 1971 State Report. The PCEP-ERROR Object is 1972 followed by the LSP Object that 1973 identifies the LSP. 1974 Error-value=5: A PCC indicates to a PCE that it can 1975 not complete the state synchronization, 1977 8.6. Notification Object 1979 IANA is requested to confirm the early allocation of the following 1980 Notification Types and Notification Values within the "Notification 1981 Object" sub-registry of the PCEP Numbers registry, and to update the 1982 reference in the registry to point to this document, when it is an 1983 RFC: 1985 Notification-Type Meaning 1986 4 Stateful PCE resource limit exceeded 1988 Notification-value=1: Entering resource limit 1989 exceeded state 1991 Note to IANA: the early allocation included an additional 1992 Notification value 2 for "Exiting resource limit exceeded state". 1993 This Notification value is no longer required. 1995 8.7. PCEP TLV Type Indicators 1997 IANA is requested to confirm the early allocation of the following 1998 TLV Type Indicator values within the "PCEP TLV Type Indicators" sub- 1999 registry of the PCEP Numbers registry, and to update the reference in 2000 the registry to point to this document, when it is an RFC: 2002 Value Meaning Reference 2003 16 STATEFUL-PCE-CAPABILITY This document 2004 17 SYMBOLIC-PATH-NAME This document 2005 18 IPV4-LSP-IDENTIFIERS This document 2006 19 IPV6-LSP-IDENTIFIERS This document 2007 20 LSP-ERROR-CODE This document 2008 21 RSVP-ERROR-SPEC This document 2010 8.8. STATEFUL-PCE-CAPABILITY TLV 2012 This document requests that a new sub-registry, named "STATEFUL-PCE- 2013 CAPABILITY TLV Flag Field", is created within the "Path Computation 2014 Element Protocol (PCEP) Numbers" registry to manage the Flag field in 2015 the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = 1). 2016 New values are to be assigned by Standards Action [RFC5226]. Each 2017 bit should be tracked with the following qualities: 2019 o Bit number (counting from bit 0 as the most significant bit) 2021 o Capability description 2023 o Defining RFC 2025 The following values are defined in this document: 2027 Bit Description Reference 2029 31 LSP-UPDATE-CAPABILITY This document 2031 8.9. LSP-ERROR-CODE TLV 2033 This document requests that a new sub-registry, named "LSP-ERROR-CODE 2034 TLV Error Code Field", is created within the "Path Computation 2035 Element Protocol (PCEP) Numbers" registry to manage the LSP Error 2036 code field of the LSP-ERROR-CODE TLV. This field specifies the 2037 reason for failure to update the LSP. 2039 New values are to be assigned by Standards Action [RFC5226]. Each 2040 value should be tracked with the following qualities: value, 2041 description and defining RFC. The following values are defined in 2042 this document: 2044 Value Meaning 2045 1 Unknown reason 2046 2 Limit reached for PCE-controlled LSPs 2047 3 Too many pending LSP update requests 2048 4 Unacceptable parameters 2049 5 Internal error 2050 6 LSP administratively brought down 2051 7 LSP preempted 2052 8 RSVP signaling error 2054 9. Manageability Considerations 2056 All manageability requirements and considerations listed in [RFC5440] 2057 apply to PCEP extensions defined in this document. In addition, 2058 requirements and considerations listed in this section apply. 2060 9.1. Control Function and Policy 2062 In addition to configuring specific PCEP session parameters, as 2063 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 2064 allow configuring the stateful PCEP capability and the LSP Update 2065 capability. A PCC implementation SHOULD allow the operator to 2066 specify multiple candidate PCEs for and a delegation preference for 2067 each candidate PCE. A PCC SHOULD allow the operator to specify an 2068 LSP delegation policy where LSPs are delegated to the most-preferred 2069 online PCE. A PCC MAY allow the operator to specify different LSP 2070 delegation policies. 2072 A PCC implementation which allows concurrent connections to multiple 2073 PCEs SHOULD allow the operator to group the PCEs by administrative 2074 domains and it MUST NOT advertise LSP existence and state to a PCE if 2075 the LSP is delegated to a PCE in a different group. 2077 A PCC implementation SHOULD allow the operator to specify whether the 2078 PCC will advertise LSP existence and state for LSPs that are not 2079 controlled by any PCE (for example, LSPs that are statically 2080 configured at the PCC). 2082 A PCC implementation SHOULD allow the operator to specify both the 2083 Redelegation Timeout Interval and the State Timeout Interval. The 2084 default value of the Redelegation Timeout Interval SHOULD be set to 2085 30 seconds. An operator MAY also configure a policy that will 2086 dynamically adjust the Redelegation Timeout Interval, for example 2087 setting it to zero when the PCC has an established session to a 2088 backup PCE. The default value for the State Timeout Interval SHOULD 2089 be set to 60 seconds. 2091 After the expiration of the State Timeout Interval, the LSP reverts 2092 to operator-defined default parameters. A PCC implementation MUST 2093 allow the operator to specify the default LSP parameters. To achieve 2094 a behavior where the LSP retains the parameters set by the PCE until 2095 such time that the PCC makes a change to them, a State Timeout 2096 Interval of infinity SHOULD be used. Any changes to LSP parameters 2097 SHOULD be done in make-before-break fashion. 2099 LSP Delegation is controlled by operator-defined policies on a PCC. 2100 LSPs are delegated individually - different LSPs may be delegated to 2101 different PCEs. An LSP is delegated to at most one PCE at any given 2102 point in time. A PCC implementation SHOULD support the delegation 2103 policy, when all PCC's LSPs are delegated to a single PCE at any 2104 given time. Conversely, the policy revoking the delegation for all 2105 PCC's LSPs SHOULD also be supported. 2107 A PCC implementation SHOULD allow the operator to specify delegation 2108 priority for PCEs. This effectively defines the primary PCE and one 2109 or more backup PCEs to which primary PCE's LSPs can be delegated when 2110 the primary PCE fails. 2112 Policies defined for stateful PCEs and PCCs should eventually fit in 2113 the Policy-Enabled Path Computation Framework defined in [RFC5394], 2114 and the framework should be extended to support Stateful PCEs. 2116 9.2. Information and Data Models 2118 The PCEP YANG module [I-D.ietf-pce-pcep-yang] should include 2120 o advertised stateful capabilities and synchronization status per 2121 PCEP session 2123 o the delegation status of each configured LSP. 2125 The PCEP MIB [RFC7420] could also be updated to include this 2126 information. 2128 9.3. Liveness Detection and Monitoring 2130 PCEP extensions defined in this document do not require any new 2131 mechanisms beyond those already defined in [RFC5440], Section 8.3. 2133 9.4. Verifying Correct Operation 2135 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 2136 extensions defined in this document. In addition to monitoring 2137 parameters defined in [RFC5440], a stateful PCC-side PCEP 2138 implementation SHOULD provide the following parameters: 2140 o Total number of LSP updates 2142 o Number of successful LSP updates 2144 o Number of dropped LSP updates 2146 o Number of LSP updates where LSP setup failed 2148 A PCC implementation SHOULD provide a command to show for each LSP 2149 whether it is delegated, and if so, to which PCE. 2151 A PCC implementation SHOULD allow the operator to manually revoke LSP 2152 delegation. 2154 9.5. Requirements on Other Protocols and Functional Components 2156 PCEP extensions defined in this document do not put new requirements 2157 on other protocols. 2159 9.6. Impact on Network Operation 2161 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 2162 extensions defined in this document. 2164 Additionally, a PCEP implementation SHOULD allow a limit to be placed 2165 on the number of LSPs delegated to the PCE and on the rate of PCUpd 2166 and PCRpt messages sent by a PCEP speaker and processed from a peer. 2167 It SHOULD also allow sending a notification when a rate threshold is 2168 reached. 2170 A PCC implementation SHOULD allow a limit to be placed on the rate of 2171 LSP Updates to the same LSP to avoid signaling overload discussed in 2172 Section 10.3. 2174 10. Security Considerations 2176 10.1. Vulnerability 2178 This document defines extensions to PCEP to enable stateful PCEs. 2179 The nature of these extensions and the delegation of path control to 2180 PCEs results in more information being available for a hypothetical 2181 adversary and a number of additional attack surfaces which must be 2182 protected. 2184 The security provisions described in [RFC5440] remain applicable to 2185 these extensions. However, because the protocol modifications 2186 outlined in this document allow the PCE to control path computation 2187 timing and sequence, the PCE defense mechanisms described in 2188 [RFC5440] section 7.2 are also now applicable to PCC security. 2190 As a general precaution, it is RECOMMENDED that these PCEP extensions 2191 only be activated on authenticated and encrypted sessions across PCEs 2192 and PCCs belonging to the same administrative authority, using 2193 Transport Layer Security (TLS) [I-D.ietf-pce-pceps], as per the 2194 recommendations and best current practices in [RFC7525]. 2196 The following sections identify specific security concerns that may 2197 result from the PCEP extensions outlined in this document along with 2198 recommended mechanisms to protect PCEP infrastructure against related 2199 attacks. 2201 10.2. LSP State Snooping 2203 The stateful nature of this extension explicitly requires LSP status 2204 updates to be sent from PCC to PCE. While this gives the PCE the 2205 ability to provide more optimal computations to the PCC, it also 2206 provides an adversary with the opportunity to eavesdrop on decisions 2207 made by network systems external to PCE. This is especially true if 2208 the PCC delegates LSPs to multiple PCEs simultaneously. 2210 Adversaries may gain access to this information by eavesdropping on 2211 unsecured PCEP sessions, and might then use this information in 2212 various ways to target or optimize attacks on network infrastructure. 2213 For example by flexibly countering anti-DDoS measures being taken to 2214 protect the network, or by determining choke points in the network 2215 where the greatest harm might be caused. 2217 PCC implementations which allow concurrent connections to multiple 2218 PCEs SHOULD allow the operator to group the PCEs by administrative 2219 domains and they MUST NOT advertise LSP existence and state to a PCE 2220 if the LSP is delegated to a PCE in a different group. 2222 10.3. Malicious PCE 2224 The LSP delegation mechanism described in this document allows a PCC 2225 to grant effective control of an LSP to the PCE for the duration of a 2226 PCEP session. While this enables PCE control of the timing and 2227 sequence of path computations within and across PCEP sessions, it 2228 also introduces a new attack vector: an attacker may flood the PCC 2229 with PCUpd messages at a rate which exceeds either the PCC's ability 2230 to process them or the network's ability to signal the changes, 2231 either by spoofing messages or by compromising the PCE itself. 2233 A PCC is free to revoke an LSP delegation at any time without needing 2234 any justification. A defending PCC can do this by enqueueing the 2235 appropriate PCRpt message. As soon as that message is enqueued in 2236 the session, the PCC is free to drop any incoming PCUpd messages 2237 without additional processing. 2239 10.4. Malicious PCC 2241 A stateful session also results in an increased attack surface by 2242 placing a requirement for the PCE to keep an LSP state replica for 2243 each PCC. It is RECOMMENDED that PCE implementations provide a limit 2244 on resources a single PCC can occupy. A PCE implementing such a 2245 limit MUST send a PCNtf message with notification-type 4 (Stateful 2246 PCE resource limit exceeded) and notification-value 1 (Entering 2247 resource limit exceeded state) upon receiving an LSP state report 2248 causing it to exceed this threshold. 2250 Delegation of LSPs can create further strain on PCE resources and a 2251 PCE implementation MAY preemptively give back delegations if it finds 2252 itself lacking the resources needed to effectively manage the 2253 delegation. Since the delegation state is ultimately controlled by 2254 the PCC, PCE implementations SHOULD provide throttling mechanisms to 2255 prevent strain created by flaps of either a PCEP session or an LSP 2256 delegation. 2258 11. Contributing Authors 2260 Xian Zhang 2261 Huawei Technology 2262 F3-5-B R&D Center 2263 Huawei Industrial Base, Bantian, Longgang District 2264 Shenzhen, Guangdong 518129 2265 P.R.China 2266 EMail: zhang.xian@huawei.com 2268 Dhruv Dhody 2269 Huawei Technology 2270 Leela Palace 2271 Bangalore, Karnataka 560008 2272 INDIA 2273 EMail: dhruv.dhody@huawei.com 2275 Siva Sivabalan 2276 Cisco Systems, Inc. 2277 2000 Innovation Drive 2278 Kanata, Ontario K2K 3E8 2279 Canada 2280 EMail: msiva@cisco.com 2282 12. Acknowledgements 2284 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 2285 Casellas for their contributions to this document. 2287 We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, 2288 Paul Schultz and Raveendra Torvi for their comments and suggestions. 2289 Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga, 2290 Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, 2291 Ambrose Kwong, Ashwin Sampath, Calvin Ying, Mustapha Aissaoui, 2292 Stephane Litkowski and Olivier Dugeon for helpful comments and 2293 discussions. 2295 13. References 2297 13.1. Normative References 2299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2300 Requirement Levels", BCP 14, RFC 2119, 2301 DOI 10.17487/RFC2119, March 1997, 2302 . 2304 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2305 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2306 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2307 September 1997, . 2309 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2310 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2311 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2312 . 2314 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 2315 Zhang, "OSPF Protocol Extensions for Path Computation 2316 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 2317 January 2008, . 2319 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 2320 Zhang, "IS-IS Protocol Extensions for Path Computation 2321 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 2322 January 2008, . 2324 [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", 2325 RFC 5284, DOI 10.17487/RFC5284, August 2008, 2326 . 2328 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 2329 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 2330 DOI 10.17487/RFC5440, March 2009, 2331 . 2333 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2334 Used to Form Encoding Rules in Various Routing Protocol 2335 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2336 2009, . 2338 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 2339 Stateful Path Computation Element (PCE)", RFC 8051, 2340 DOI 10.17487/RFC8051, January 2017, 2341 . 2343 13.2. Informative References 2345 [I-D.ietf-pce-gmpls-pcep-extensions] 2346 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 2347 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in 2348 progress), October 2015. 2350 [I-D.ietf-pce-pce-initiated-lsp] 2351 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 2352 Extensions for PCE-initiated LSP Setup in a Stateful PCE 2353 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 2354 progress), March 2017. 2356 [I-D.ietf-pce-pcep-yang] 2357 Dhody, D., Hardwick, J., Beeram, V., and j. 2358 jefftant@gmail.com, "A YANG Data Model for Path 2359 Computation Element Communications Protocol (PCEP)", 2360 draft-ietf-pce-pcep-yang-02 (work in progress), March 2361 2017. 2363 [I-D.ietf-pce-pceps] 2364 Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure 2365 Transport for PCEP", draft-ietf-pce-pceps-12 (work in 2366 progress), April 2017. 2368 [I-D.ietf-pce-stateful-sync-optimizations] 2369 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 2370 and D. Dhody, "Optimizations of Label Switched Path State 2371 Synchronization Procedures for a Stateful PCE", draft- 2372 ietf-pce-stateful-sync-optimizations-10 (work in 2373 progress), March 2017. 2375 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2376 LSP Path Computation using Preemption", Global 2377 Information Infrastructure Symposium, July 2007. 2379 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2380 programming algorithm for balancing the max-min fairness 2381 and throughput objectives in traffic engineering", 2382 INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012. 2384 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2385 McManus, "Requirements for Traffic Engineering Over MPLS", 2386 RFC 2702, DOI 10.17487/RFC2702, September 1999, 2387 . 2389 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2390 Label Switching Architecture", RFC 3031, 2391 DOI 10.17487/RFC3031, January 2001, 2392 . 2394 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2395 Christian, B., and W. Lai, "Applicability Statement for 2396 Traffic Engineering with MPLS", RFC 3346, 2397 DOI 10.17487/RFC3346, August 2002, 2398 . 2400 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2401 (TE) Extensions to OSPF Version 2", RFC 3630, 2402 DOI 10.17487/RFC3630, September 2003, 2403 . 2405 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2406 Element (PCE)-Based Architecture", RFC 4655, 2407 DOI 10.17487/RFC4655, August 2006, 2408 . 2410 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 2411 Element (PCE) Communication Protocol Generic 2412 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2413 2006, . 2415 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2416 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2417 DOI 10.17487/RFC5226, May 2008, 2418 . 2420 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2421 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2422 2008, . 2424 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2425 "Policy-Enabled Path Computation Framework", RFC 5394, 2426 DOI 10.17487/RFC5394, December 2008, 2427 . 2429 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 2430 Hardwick, "Path Computation Element Communication Protocol 2431 (PCEP) Management Information Base (MIB) Module", 2432 RFC 7420, DOI 10.17487/RFC7420, December 2014, 2433 . 2435 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2436 "Recommendations for Secure Use of Transport Layer 2437 Security (TLS) and Datagram Transport Layer Security 2438 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2439 2015, . 2441 Authors' Addresses 2443 Edward Crabbe 2444 Oracle 2445 1501 4th Ave, suite 1800 2446 Seattle, WA 98101 2447 US 2449 Email: edward.crabbe@oracle.com 2451 Ina Minei 2452 Google, Inc. 2453 1600 Amphitheatre Parkway 2454 Mountain View, CA 94043 2455 US 2457 Email: inaminei@google.com 2458 Jan Medved 2459 Cisco Systems, Inc. 2460 170 West Tasman Dr. 2461 San Jose, CA 95134 2462 US 2464 Email: jmedved@cisco.com 2466 Robert Varga 2467 Pantheon Technologies SRO 2468 Mlynske Nivy 56 2469 Bratislava 821 05 2470 Slovakia 2472 Email: robert.varga@pantheon.tech