idnits 2.17.1 draft-ietf-pce-stateful-pce-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2014) is 3719 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) == Missing Reference: 'TBD' is mentioned on line 1623, but not defined == Unused Reference: 'RFC3473' is defined on line 1985, but no explicit reference was found in the text == Unused Reference: 'NET-REC' is defined on line 2042, but no explicit reference was found in the text == Unused Reference: 'RFC5557' is defined on line 2076, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-pce-gmpls-pcep-extensions-09 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-08) exists of draft-ietf-pce-stateful-pce-app-01 == Outdated reference: A later version (-02) exists of draft-minei-pce-stateful-sync-optimizations-01 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group E. Crabbe 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track J. Medved 5 Expires: August 16, 2014 Cisco Systems, Inc. 6 I. Minei 7 Google, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 February 12, 2014 12 PCEP Extensions for Stateful PCE 13 draft-ietf-pce-stateful-pce-08 15 Abstract 17 The Path Computation Element Communication Protocol (PCEP) provides 18 mechanisms for Path Computation Elements (PCEs) to perform path 19 computations in response to Path Computation Clients (PCCs) requests. 21 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 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 16, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 5 70 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6 73 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 7 74 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 8 76 5. Architectural Overview of Protocol Extensions . . . . . . . . 9 77 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 78 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.3. Capability Advertisement . . . . . . . . . . . . . . . . . 10 80 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11 81 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 14 82 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 83 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 15 84 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 17 85 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 17 86 5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 18 87 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 18 88 5.6.1. Passive Stateful PCE Path Computation 89 Request/Response . . . . . . . . . . . . . . . . . . . 19 90 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 20 91 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 22 92 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 22 93 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22 94 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 22 95 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24 96 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 26 98 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 26 99 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 27 100 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 27 101 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 27 102 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 29 103 7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 31 104 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 34 105 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 35 106 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 35 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 108 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 36 109 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 36 110 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37 111 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 37 112 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 38 113 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 38 114 8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 39 115 9. Manageability Considerations . . . . . . . . . . . . . . . . . 39 116 9.1. Control Function and Policy . . . . . . . . . . . . . . . 39 117 9.2. Information and Data Models . . . . . . . . . . . . . . . 40 118 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 40 119 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 41 120 9.5. Requirements on Other Protocols and Functional 121 Components . . . . . . . . . . . . . . . . . . . . . . . . 41 122 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 41 123 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 124 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 41 125 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 42 126 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 42 127 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 43 128 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 129 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 130 12.1. Normative References . . . . . . . . . . . . . . . . . . . 43 131 12.2. Informative References . . . . . . . . . . . . . . . . . . 44 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 134 1. Introduction 136 [RFC5440] describes the Path Computation Element Protocol (PCEP). 137 PCEP defines the communication between a Path Computation Client 138 (PCC) and a Path Computation Element (PCE), or between PCEs, enabling 139 computation of Multiprotocol Label Switching (MPLS) for Traffic 140 Engineering Label Switched Path (TE LSP) characteristics. Extensions 141 for support of Generalized MPLS (GMPLS) in PCEP are defined in 142 [I-D.ietf-pce-gmpls-pcep-extensions] 144 This document specifies a set of extensions to PCEP to enable 145 stateful control of LSPs within and across PCEP sessions in 146 compliance with [RFC4657]. It includes mechanisms to effect LSP 147 state synchronization between PCCs and PCEs, delegation of control 148 over LSPs to PCEs, and PCE control of timing and sequence of path 149 computations within and across PCEP sessions. 151 2. Terminology 153 This document uses the following terms defined in [RFC5440]: PCC, 154 PCE, PCEP Peer, PCEP Speaker. 156 This document uses the following terms defined in [RFC4655]: TED. 158 The following terms are defined in this document: 160 Stateful PCE: has access to not only the network state, but also to 161 the set of active paths and their reserved resources for its 162 computations. A stateful PCE might also retain information 163 regarding LSPs under construction in order to reduce churn and 164 resource contention. The additional state allows the PCE to 165 compute constrained paths while considering individual LSPs and 166 their interactions. Note that this requires reliable state 167 synchronization mechanisms between the PCE and the network, PCE 168 and PCC, and between cooperating PCEs. 170 Passive Stateful PCE: uses LSP state information learned from PCCs 171 to optimize path computations. It does not actively update LSP 172 state. A PCC maintains synchronization with the PCE. 174 Active Stateful PCE: is an extension of Passive Stateful PCE, in 175 which the PCE may issue recommendations to the network. For 176 example, an active stateful PCE may utilize the Delegation 177 mechanism to update LSP parameters in those PCCs that delegated 178 control over their LSPs to the PCE. 180 Delegation: An operation to grant a PCE temporary rights to modify a 181 subset of LSP parameters on one or more PCC's LSPs. LSPs are 182 delegated from a PCC to a PCE, and are referred to as delegated 183 LSPs. The PCC who owns the PCE state for the LSP has the right to 184 delegate it. An LSP is owned by a single PCC at any given point 185 in time. For intra-domain LSPs, this PCC SHOULD be the LSP head 186 end. 188 Revocation: An operation performed by a PCC on a previously 189 delegated LSP. Revocation revokes the rights granted to the PCE 190 in the delegation operation. 192 Redelegation Timeout Interval: when a PCEP session is terminated, a 193 PCC waits for this time period before revoking LSP delegation to a 194 PCE and attempting to redelegate LSPs associated with the 195 terminated PCEP session to an alternate PCE. The Redelegation 196 Timeout Interval is a PCC-local value that can be either operator- 197 configured or dynamically computed by the PCC based on local 198 policy. 200 State Timeout Interval: when a PCEP session is terminated, a PCC 201 waits for this time period before flushing LSP state associated 202 with that PCEP session and reverting to operator-defined default 203 parameters or behaviors. The State Timeout Interval is a PCC- 204 local value that can be either operator-configured or dynamically 205 computed by the PCC based on local policy. 207 LSP State Report: an operation to send LSP state (Operational / 208 Admin Status, LSP attributes configured at the PCC and set by a 209 PCE, etc.) from a PCC to a PCE. 211 LSP Update Request: an operation where an Active Stateful PCE 212 requests a PCC to update one or more attributes of an LSP and to 213 re-signal the LSP with updated attributes. 215 LSP State Database: information about all LSPs and their attributes. 217 Within this document, PCE-PCE communications are described by having 218 the requesting PCE fill the role of a PCC. This provides a saving in 219 documentation without loss of function. 221 The message formats in this document are specified using Routing 222 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 224 3. Motivation and Objectives for Stateful PCE 225 3.1. Motivation 227 [I-D.ietf-pce-stateful-pce-app] presents several use cases, 228 demonstrating scenarios that benefit from the deployment of a 229 stateful PCE. The scenarios apply equally to MPLS-TE and GMPLS 230 deployments. 232 3.1.1. Background 234 Traffic engineering has been a goal of the MPLS architecture since 235 its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic 236 engineering system provided by [RFC3630], [RFC5305], and [RFC3209] 237 information about network resources utilization is only available as 238 total reserved capacity by traffic class on a per interface basis; 239 individual LSP state is available only locally on each LER for its 240 own LSPs. In most cases, this makes good sense, as distribution and 241 retention of total LSP state for all LERs within in the network would 242 be prohibitively costly. 244 Unfortunately, this visibility in terms of global LSP state may 245 result in a number of issues for some demand patterns, particularly 246 within a common setup and hold priority. This issue affects online 247 traffic engineering systems. 249 A sufficiently over-provisioned system will by definition have no 250 issues routing its demand on the shortest path. However, lowering 251 the degree to which network over-provisioning is required in order to 252 run a healthy, functioning network is a clear and explicit promise of 253 MPLS architecture. In particular, it has been a goal of MPLS to 254 provide mechanisms to alleviate congestion scenarios in which 255 "traffic streams are inefficiently mapped onto available resources; 256 causing subsets of network resources to become over-utilized while 257 others remain underutilized" ([RFC2702]). 259 3.1.2. Why a Stateful PCE? 261 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 262 "strict synchronization between the PCE and not only the network 263 states (in term of topology and resource information), but also the 264 set of computed paths and reserved resources in use in the network." 265 [RFC4655] also expressed a number of concerns with regard to a 266 stateful PCE, specifically: 268 o Any reliable synchronization mechanism would result in significant 269 control plane overhead 271 o Out-of-band TED synchronization would be complex and prone to race 272 conditions 274 o Path calculations incorporating total network state would be 275 highly complex 277 In general, stress on the control plane will be directly proportional 278 to the size of the system being controlled and the tightness of the 279 control loop, and indirectly proportional to the amount of over- 280 provisioning in terms of both network capacity and reservation 281 overhead. 283 Despite these concerns in terms of implementation complexity and 284 scalability, several TE algorithms exist today that have been 285 demonstrated to be extremely effective in large TE systems, providing 286 both rapid convergence and significant benefits in terms of 287 optimality of resource usage [MXMN-TE]. All of these systems share 288 at least two common characteristics: the requirement for both global 289 visibility of a flow (or in this case, a TE LSP) state and for 290 ordered control of path reservations across devices within the system 291 being controlled. While some approaches have been suggested in order 292 to remove the requirements for ordered control (See [MPLS-PC]), these 293 approaches are highly dependent on traffic distribution, and do not 294 allow for multiple simultaneous LSP priorities representing diffserv 295 classes. 297 The use cases described in [I-D.ietf-pce-stateful-pce-app] 298 demonstrate a need for visibility into global inter-PCC LSP state in 299 PCE path computations, and for PCE control of sequence and timing in 300 altering LSP path characteristics within and across PCEP sessions. 302 3.1.3. Protocol vs. Configuration 304 Note that existing configuration tools and protocols can be used to 305 set LSP state. However, this solution has several shortcomings: 307 o Scale & Performance: configuration operations often require 308 processing of additional configuration portions beyond the state 309 being directly acted upon, with corresponding cost in CPU cycles, 310 negatively impacting both PCC stability LSP update rate capacity. 312 o Scale & Performance: configuration operations often have 313 transactional semantics which are typically heavyweight and 314 require additional CPU cycles, negatively impacting PCC update 315 rate capacity. 317 o Security: when a PCC opens a configuration channel allowing a PCE 318 to send configuration, a malicious PCE may take advantage of this 319 ability to take over the PCC. In contrast, the PCEP extensions 320 described in this document only allow a PCE control over a very 321 limited set of LSP attributes. 323 o Interoperability: each vendor has a proprietary information model 324 for configuring LSP state, which prevents interoperability of a 325 PCE with PCCs from different vendors. The PCEP extensions 326 described in this document allow for a common information model 327 for LSP state for all vendors. 329 o Efficient State Synchronization: configuration channels may be 330 heavyweight and unidirectional, therefore efficient state 331 synchronization between a PCC and a PCE may be a problem. 333 3.2. Objectives 335 The objectives for the protocol extensions to support stateful PCE 336 described in this document are as follows: 338 o Allow a single PCC to interact with a mix of stateless and 339 stateful PCEs simultaneously using the same PCEP. 341 o Support efficient LSP state synchronization between the PCC and 342 one or more active or passive stateful PCEs. 344 o Allow a PCC to delegate control of its LSPs to an active stateful 345 PCE such that a single LSP is under the control a single PCE at 346 any given time. A PCC may revoke this delegation at any time 347 during the lifetime of the LSP. If LSP delegation is revoked 348 while the PCEP session is up, the PCC MUST notify the PCE about 349 the revocation. A PCE may return an LSP delegation at any point 350 during the lifetime of the PCEP session. 352 o Allow a PCE to control computation timing and update timing across 353 all LSPs that have been delegated to it. 355 o Enable uninterrupted operation of PCC's LSPs in the event of a PCE 356 failure or while control of LSPs is being transferred between 357 PCEs. 359 4. New Functions to Support Stateful PCEs 361 Several new functions are required in PCEP to support stateful PCEs. 362 A function can be initiated either from a PCC towards a PCE (C-E) or 363 from a PCE towards a PCC (E-C). The new functions are: 365 Capability advertisement (E-C,C-E): both the PCC and the PCE must 366 announce during PCEP session establishment that they support PCEP 367 Stateful PCE extensions defined in this document. 369 LSP state synchronization (C-E): after the session between the PCC 370 and a stateful PCE is initialized, the PCE must learn the state of 371 a PCC's LSPs before it can perform path computations or update LSP 372 attributes in a PCC. 374 LSP Update Request (E-C): A PCE requests modification of attributes 375 on a PCC's LSP. 377 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 378 whenever the state of an LSP changes. 380 LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 381 update LSP attributes on one or more LSPs; the PCE becomes the 382 authoritative source of the LSP's attributes as long as the 383 delegation is in effect (See Section 5.5); the PCC may withdraw 384 the delegation or the PCE may give up the delegation at any time. 386 [I-D.sivabalan-pce-disco-stateful] defines the extensions needed to 387 support autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or 388 IS-IS ([RFC5089]) for PCE discovery. 390 5. Architectural Overview of Protocol Extensions 392 5.1. LSP State Ownership 394 In the PCEP protocol (defined in [RFC5440]), LSP state and operation 395 are under the control of a PCC (a PCC may be an LSR or a management 396 station). Attributes received from a PCE are subject to PCC's local 397 policy. The PCEP protocol extensions described in this document do 398 not change this behavior. 400 An active stateful PCE may have control of a PCC's LSPs that were 401 delegated to it, but the LSP state ownership is retained by the PCC. 402 In particular, in addition to specifying values for LSP's attributes, 403 an active stateful PCE also decides when to make LSP modifications. 405 Retaining LSP state ownership on the PCC allows for: 407 o a PCC to interact with both stateless and stateful PCEs at the 408 same time 410 o a stateful PCE to only modify a small subset of LSP parameters, 411 i.e. to set only a small subset of the overall LSP state; other 412 parameters may be set by the operator through command line 413 interface (CLI) commands 415 o a PCC to revert delegated LSP to an operator-defined default or to 416 delegate the LSPs to a different PCE, if the PCC get disconnected 417 from a PCE with currently delegated LSPs 419 5.2. New Messages 421 In this document, we define the following new PCEP messages: 423 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 424 to a PCE to report the status of one or more LSPs. Each LSP 425 Status Report in a PCRpt message can contain the actual LSP's 426 path, bandwidth, operational and administrative status, etc. An 427 LSP Status Report carried on a PCRpt message is also used in 428 delegation or revocation of control of an LSP to/from a PCE. The 429 PCRpt message is described in Section 6.1. 431 Path Computation Update Request (PCUpd): a PCEP message sent by a 432 PCE to a PCC to update LSP parameters, on one or more LSPs. Each 433 LSP Update Request on a PCUpd message MUST contain all LSP 434 parameters that a PCE wishes to be set for a given LSP. An LSP 435 Update Request carried on a PCUpd message is also used to return 436 LSP delegations if at any point PCE no longer desires control of 437 an LSP. The PCUpd message is described in Section 6.2. 439 The new functions defined in Section 4 are mapped onto the new 440 messages as shown in the following table. 442 +----------------------------------------+--------------------------+ 443 | Function | Message | 444 +----------------------------------------+--------------------------+ 445 | Capability Advertisement (E-C,C-E) | Open | 446 | State Synchronization (C-E) | PCRpt | 447 | LSP State Report (C-E) | PCRpt | 448 | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | 449 | LSP Update Request (E-C) | PCUpd | 450 | ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS | 451 | | sub-TLV | 452 | OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, | 453 | | PCE-CAP-FLAGS sub-TLV | 454 +----------------------------------------+--------------------------+ 456 Table 1: New Function to Message Mapping 458 5.3. Capability Advertisement 460 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 461 advertise their support of stateful PCEP extensions. A PCEP Speaker 462 includes the "Stateful PCE Capability" TLV, described in 463 Section 7.1.1, in the OPEN Object to advertise its support for PCEP 464 stateful extensions. The Stateful Capability TLV includes the 'LSP 465 Update' Flag that indicates whether the PCEP Speaker supports LSP 466 parameter updates. 468 The presence of the Stateful PCE Capability TLV in PCC's OPEN Object 469 indicates that the PCC is willing to send LSP State Reports whenever 470 LSP parameters or operational status changes. 472 The presence of the Stateful PCE Capability TLV in PCE's OPEN message 473 indicates that the PCE is interested in receiving LSP State Reports 474 whenever LSP parameters or operational status changes. 476 The PCEP protocol extensions for stateful PCEs MUST NOT be used if 477 one or both PCEP Speakers have not included the Stateful PCE 478 Capability TLV in their respective OPEN message. If the PCEP Speaker 479 on the PCC supports the extensions of this draft but did not 480 advertise this capability, then upon receipt of PCUpd message from 481 the PCE, it SHOULD generate a PCErr with error-type 19 (Invalid 482 Operation), error-value 2 (Attempted LSP Update Request if active 483 stateful PCE capability was not advertised)(see Section 8.4) and it 484 will terminate the PCEP session. If the PCEP Speaker on the PCE 485 supports the extensions of this draft but did not advertise this 486 capability, then upon receipt of a PCRpt message from the PCC, it 487 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 488 error-value 5 (Attempted LSP State Report if active stateful PCE 489 capability was not advertised) (see Section 8.4) and it will 490 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 Flag in the 494 "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this 495 is not the case and LSP delegation or LSP update operations are 496 attempted, then a PCErr with error-type 19 (Invalid Operation) and 497 error-value 1 (Attempted LSP Update Request for a non-delegated 498 LSP).(see Section 8.4) SHOULD be generated. Note that even if the 499 update capability has not been advertised, a PCE can still receive 500 LSP Status Reports from a PCC and build and maintain an up to date 501 view of the state of the PCC's LSPs. 503 5.4. State Synchronization 505 The purpose of State Synchronization is to provide a checkpoint-in- 506 time state replica of a PCC's LSP state in a PCE. State 507 Synchronization is performed immediately after the Initialization 508 phase ([RFC5440]). 510 During State Synchronization, a PCC first takes a snapshot of the 511 state of its LSPs state, then sends the snapshot to a PCE in a 512 sequence of LSP State Reports. Each LSP State Report sent during 513 State Synchronization has the SYNC Flag in the LSP Object set to 1. 514 The set of LSPs for which state is synchronized with a PCE is 515 determined by advertised stateful PCEP capabilities and PCC's local 516 configuration (see more details in Section 9.1). 518 The end of synchronization marker is a PCRpt message with the SYNC 519 Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved 520 value 0. The LSP Object does not include the SYMBOLIC-PATH-NAME TLV 521 in this case. If the PCC has no state to synchronize, it will only 522 send the end of synchronization marker. 524 A PCE SHOULD NOT send PCUpd messages to a PCC before State 525 Synchronization is complete. A PCC SHOULD NOT send PCReq messages to 526 a PCE before State Synchronization is complete. This is to allow the 527 PCE to get the best possible view of the network before it starts 528 computing new paths. 530 Either the PCE or the PCC MAY terminate the session using the PCEP 531 session termination procedures during the synchronization phase. If 532 the session is terminated, the PCE MUST clean up state it received 533 from this PCC. The session reestablishment MUST be re-attempted per 534 the procedures defined in [RFC5440], including use of a back-off 535 timer. 537 If the PCC encounters a problem which prevents it from completing the 538 state transfer, it MUST send a PCErr message with error-type 20 (LSP 539 State Synchronization Error) and error-value 5 (indicating an 540 internal PCC error) to the PCE and terminate the session. 542 The PCE does not send positive acknowledgements for properly received 543 synchronization messages. It MUST respond with a PCErr message with 544 error-type 20 (LSP State Synchronization Error) and error-value 1 545 (indicating an error in processing the PCRpt) (see Section 8.4) if it 546 encounters a problem with the LSP State Report it received from the 547 PCC and it MUST terminate the session. 549 A PCE implementing a limit on the resources a single PCC can occupy, 550 MUST send a PCErr message with error-type 19 (invalid operation) and 551 error-value 4 (indicating resource limit exceeded) in response to the 552 PCRpt message triggering this condition in the synchronization phase 553 and MUST terminate the session. 555 The successful State Synchronization sequence is shown in Figure 1. 557 +-+-+ +-+-+ 558 |PCC| |PCE| 559 +-+-+ +-+-+ 560 | | 561 |-----PCRpt, SYNC=1----->| (Sync start) 562 | | 563 |-----PCRpt, SYNC=1----->| 564 | . | 565 | . | 566 | . | 567 |-----PCRpt, SYNC=1----->| 568 | . | 569 | . | 570 | . | 571 | | 572 |-----PCRpt, SYNC=0----->| (End of sync marker 573 | | LSP State Report 574 | | for PLSP-ID=0) 575 | | (Sync done) 577 Figure 1: Successful state synchronization 579 The sequence where the PCE fails during the State Synchronization 580 phase is shown in Figure 2. 582 +-+-+ +-+-+ 583 |PCC| |PCE| 584 +-+-+ +-+-+ 585 | | 586 |-----PCRpt, SYNC=1----->| 587 | | 588 |-----PCRpt, SYNC=1----->| 589 | . | 590 | . | 591 | . | 592 |-----PCRpt, SYNC=1----->| 593 | | 594 |-PCRpt, SYNC=1 | 595 | \ ,-PCErr=?-| 596 | \ / | 597 | \/ | 598 | /\ | 599 | / `-------->| (Ignored) 600 |<--------` | 602 Figure 2: Failed state synchronization (PCE failure) 604 The sequence where the PCC fails during the State Synchronization 605 phase is shown in Figure 3. 607 +-+-+ +-+-+ 608 |PCC| |PCE| 609 +-+-+ +-+-+ 610 | | 611 |-----PCRpt, SYNC=1----->| 612 | | 613 |-----PCRpt, SYNC=1----->| 614 | . | 615 | . | 616 | . | 617 |-------- PCErr=? ------>| 618 | | 620 Figure 3: Failed state synchronization (PCC failure) 622 Optimizations to the synchronization procedures and alternate 623 mechanisms of providing the synchronization function are outside the 624 scope of this document and are discussed elsewhere (see 625 [I-D.minei-pce-stateful-sync-optimizations]). 627 5.5. LSP Delegation 629 If during Capability advertisement both the PCE and the PCC have 630 indicated that they support LSP Update, then the PCC may choose to 631 grant the PCE a temporary right to update (a subset of) LSP 632 attributes on one or more LSPs. This is called "LSP Delegation", and 633 it MAY be performed at any time after the Initialization phase, 634 including during the State Synchronization phase. 636 LSP Delegation is controlled by operator-defined policies on a PCC. 637 LSPs are delegated individually - different LSPs may be delegated to 638 different PCEs. An LSP is delegated to at most one PCE at any given 639 point in time. The delegation policy, when all PCC's LSPs are 640 delegated to a single PCE at any given time, SHOULD be supported by 641 all delegation-capable PCCs. Conversely, the policy revoking the 642 delegation for all PCC's LSPs SHOULD also be supported. 644 A PCE may return LSP delegation at any time if it no longer wishes to 645 update the LSP's state. A PCC may revoke LSP delegation at any time. 646 Delegation, Revocation, and Return are done individually for each 647 LSP. 649 In the event of an delegation being rejected or returned by a PCE, 650 the PCC should react based on local policy. It can, for example, 651 either retry delegating to the same PCE using an exponentially 652 increasing timer or delegate to an alternate PCE. 654 5.5.1. Delegating an LSP 656 A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP 657 State Report to 1. If the PCE does not accept the LSP Delegation, it 658 MUST immediately respond with an empty LSP Update Request which has 659 the Delegate flag set to 0. If the PCE accepts the LSP Delegation, 660 it confirms this when it sends the first LSP Update Request for the 661 delegated LSP to the PCC by setting the Delegate flag to 1 (note that 662 this may occur at a later time). 664 The delegation sequence is shown in Figure 4. 666 +-+-+ +-+-+ 667 |PCC| |PCE| 668 +-+-+ +-+-+ 669 | | 670 |---PCRpt, Delegate=1--->| LSP Delegated 671 | | 672 |---PCRpt, Delegate=1--->| 673 | . | 674 | . | 675 | . | 676 |<--(PCUpd,Delegate=1)---| Delegation confirmed 677 | | 678 |---PCRpt, Delegate=1--->| 679 | | 681 Figure 4: Delegating an LSP 683 Note that for an LSP to remain delegated to a PCE, the PCC MUST set 684 the Delegate flag to 1 on each LSP Status Report sent to the PCE. 686 5.5.2. Revoking a Delegation 688 When a PCC decides that a PCE is no longer permitted to modify an 689 LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke 690 an LSP delegation at any time during the LSP's life time. A PCC 691 revoking an LSP delegation MAY immediately clear the LSP state 692 provided by the PCE, but to avoid traffic loss, it SHOULD do so in a 693 make-before-break fashion. If the PCC has received but not yet acted 694 on PCUpd messages from the PCE for the LSP whose delegation is being 695 revoked, then it SHOULD ignore these PCUpd messages when processing 696 the message queue. All effects of all messages for which processing 697 started before the revocation took place MUST be allowed to complete 698 and the result MUST be given the same treatment as any LSP that had 699 been previously delegated to the PCE (e.g. the state MAY be 700 immediately cleared). Any further PCUpd messages from the PCE are 701 handled according to the PCUpd procedures described in this document. 703 If a PCEP session with the PCE to which the LSP is delegated exists 704 in the UP state during the revocation, the PCC MUST notify that PCE 705 by sending an LSP State Report with the Delegate flag set to 0, as 706 shown in Figure 5. 708 +-+-+ +-+-+ 709 |PCC| |PCE| 710 +-+-+ +-+-+ 711 | | 712 |---PCRpt, Delegate=1--->| 713 | | 714 |<--(PCUpd,Delegate=1)---| Delegation confirmed 715 | . | 716 | . | 717 | . | 718 |---PCRpt, Delegate=0--->| PCC revokes delegation 719 | | 721 Figure 5: Revoking a Delegation 723 After an LSP delegation has been revoked, a PCE can no longer update 724 LSP's parameters; an attempt to update parameters of a non-delegated 725 LSP will result in the PCC sending a PCErr message with error-type 19 726 (Invalid Operation), error-value 1 (attempted LSP Update Request for 727 a non-delegated LSP) (see Section 8.4). 729 When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC 730 MUST wait the time interval specified in Redelegation Timeout 731 Interval before revoking LSP delegations to that PCE and attempting 732 to redelegate LSPs to an alternate PCE. If a PCEP session with the 733 original PCE can be reestablished before the Redelegation Timeout 734 Interval timer expires, LSP delegations to the PCE remain intact. 736 Likewise, when a PCC's PCEP session with a PCE terminates 737 unexpectedly, the PCC MUST wait for the State Timeout Interval before 738 flushing any LSP state associated with that PCE. Note that the State 739 Timeout Interval timer may expire before the PCC has redelegated the 740 LSPs to another PCE, for example if a PCC is not connected to any 741 active stateful PCE or if no connected active stateful PCE accepts 742 the delegation. In this case, the PCC SHALL flush any LSP state set 743 by the PCE upon expiration of the State Timeout Interval and revert 744 to operator-defined default parameters or behaviors. This operation 745 SHOULD be done in a make-before-break fashion. 747 The State Timeout Interval SHOULD be greater than or equal to the 748 Redelegation Timeout Interval and MAY be set to infinity (meaning 749 that until the PCC specifically takes action to change the parameters 750 set by the PCE, they will remain intact). 752 5.5.3. Returning a Delegation 754 A PCE that no longer wishes to update an LSP's parameters SHOULD 755 return the LSP delegation back to the PCC by sending an empty LSP 756 Update Request which has the Delegate flag set to 0. Note that in 757 order to keep a delegation, the PCE MUST set the Delegate flag to 1 758 on each LSP Update Request sent to the PCC. 760 +-+-+ +-+-+ 761 |PCC| |PCE| 762 +-+-+ +-+-+ 763 | | 764 |---PCRpt, Delegate=1--->| LSP delegated 765 | . | 766 | . | 767 | . | 768 |<--PCUpd, Delegate=0----| Delegation returned 769 | | 770 |---PCRpt, Delegate=0--->| No delegation for LSP 771 | | 773 Figure 6: Returning a Delegation 775 If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is 776 not connected to any active stateful PCE or if no connected active 777 stateful PCE accepts the delegation), the LSP delegation on the PCC 778 will time out within a configurable Redelegation Timeout Interval and 779 the PCC MUST flush any LSP state set by a PCE at the expiration of 780 the State Timeout Interval. 782 5.5.4. Redundant Stateful PCEs 784 In a redundant configuration where one PCE is backing up another PCE, 785 the backup PCE may have only a subset of the LSPs in the network 786 delegated to it. The backup PCE does not update any LSPs that are 787 not delegated to it. In order to allow the backup to operate in a 788 hot-standby mode and avoid the need for state synchronization in case 789 the primary fails, the backup receives all LSP State Reports from a 790 PCC. When the primary PCE for a given LSP set fails, after expiry of 791 the Redelegation Timeout Interval, the PCC SHOULD delegate to the 792 redundant PCE all LSPs that had been previously delegated to the 793 failed PCE. Assuming that the State Timeout Interval had been 794 configured to be larger than the Redelegation Timeout Interval (as 795 recommended), this delegation change will not cause any changes to 796 the LSP parameters. 798 5.5.5. Redelegation on PCE Failure 800 On failure, the goal is to: 1) avoid any traffic loss on the LSPs 801 that were updated by the PCE that crashed 2) minimize the churn in 802 the network in terms of ownership of the LSPs, 3) not leave any 803 "orphan" (undelegated) LSPs and 4) be able to control when the state 804 that was set by the PCE can be changed or purged. The values chosen 805 for the Redelegation Timeout and State Timeout values affect the 806 ability to accomplish these goals. 808 This section summarizes the behaviour with regards to LSP delegation 809 and LSP state on a PCE failure. 811 If the PCE crashes but recovers within the Redelegation Timeout, both 812 the delegation state and the LSP state are kept intact. 814 If the PCE crashes but does not recover within the Redelegation 815 Timeout, the delegation state is returned to the PCC. If the PCC can 816 redelegate the LSPs to another PCE, and that PCE accepts the 817 delegations, there will be no change in LSP state. If the PCC cannot 818 redelegate the LSPs to another PCE, then upon expiration of the State 819 Timeout Interval, the state set by the PCE is flushed, which may 820 cause change in the LSP state. Note that an operator may choose to 821 use an infinite State Timeout Interval if he wishes to maintain the 822 PCE state indefinetely. Note also that flushing the state should be 823 implemented using make-before-break to avoid traffic loss. 825 If there is a standby PCE, the Redelegation Timeout may be set to 0 826 through policy on the PCC, causing the LSPs to be redelegated 827 immediately to the PCC, which can delegate them immediately to the 828 standby PCE. Assuming the State Timeout Interval is larger than the 829 Redelegation Timeout, the LSP state will be kept intact. 831 5.6. LSP Operations 832 5.6.1. Passive Stateful PCE Path Computation Request/Response 834 +-+-+ +-+-+ 835 |PCC| |PCE| 836 +-+-+ +-+-+ 837 | | 838 1) Path computation |----- PCReq message --->| 839 request sent to | |2) Path computation 840 PCE | | request received, 841 | | path computed 842 | | 843 |<---- PCRep message ----|3) Computed paths 844 | (Positive reply) | sent to the PCC 845 | (Negative reply) | 846 4) LSP Status change| | 847 event | | 848 | | 849 5) LSP Status Report|----- PCRpt message --->| 850 sent to all | . | 851 stateful PCEs | . | 852 | . | 853 6) Repeat for each |----- PCRpt message --->| 854 LSP status change| | 855 | | 857 Figure 7: Passive Stateful PCE Path Computation Request/Response 859 Once a PCC has successfully established a PCEP session with a passive 860 stateful PCE and the PCC's LSP state is synchronized with the PCE 861 (i.e. the PCE knows about all PCC's existing LSPs), if an event is 862 triggered that requires the computation of a set of paths, the PCC 863 sends a path computation request to the PCE ([RFC5440], Section 864 4.2.3). 866 Upon receiving a path computation request from a PCC, the PCE 867 triggers a path computation and returns either a positive or a 868 negative reply to the PCC ([RFC5440], Section 4.2.4). 870 Upon receiving a positive path computation reply, the PCC receives a 871 set of computed paths and starts to setup the LSPs. For each LSP, it 872 sends an LSP State Report carried on a PCRpt message to the PCE, 873 indicating that the LSP's status is 'Pending'. 875 Once an LSP is up, the PCC sends an LSP State Report carried on a 876 PCRpt message to the PCE, indicating that the LSP's status is 'Up'. 877 If the LSP could not be set up, the PCC sends an LSP State Report 878 indicating that the LSP is "Down' and stating the cause of the 879 failure. Note that due to timing constraints, the LSP status may 880 change from 'Pending' to 'Up' (or 'Down') before the PCC has had a 881 chance to send an LSP State Report indicating that the status is 882 'Pending'. In such cases, the PCC may choose to only send the PCRpt 883 indicating the latest status ('Up' or 'Down'). 885 Upon receiving a negative reply from a PCE, a PCC may decide to 886 resend a modified request or take any other appropriate action. For 887 each requested LSP, it also sends an LSP State Report carried on a 888 PCRpt message to the PCE, indicating that the LSP's status is 'Down'. 890 There is no direct correlation between PCRep and PCRpt messages. For 891 a given LSP, multiple LSP State Reports will follow a single PCRep 892 message, as a PCC notifies a PCE of the LSP's state changes. 894 A PCC sends each LSP State Report to each stateful PCE that is 895 connected to the PCC. 897 Note that a single PCRpt message MAY contain multiple LSP State 898 Reports. 900 The passive stateful PCE is the model for stateful PCEs is described 901 in [RFC4655], Section 6.8. 903 5.6.2. Active Stateful PCE LSP Update 905 +-+-+ +-+-+ 906 |PCC| |PCE| 907 +-+-+ +-+-+ 908 | | 909 1) LSP State |-- PCRpt, Delegate=1 -->| 910 Synchronization | . | 911 or add new LSP | . |2) PCE decides to 912 | . | update the LSP 913 | | 914 |<---- PCUpd message ----|3) PCUpd message sent 915 | | to PCC 916 | | 917 | | 918 4) LSP Status Report|---- PCRpt message ---->| 919 sent(->Pending) | . | 920 | . | 921 | . | 922 5) LSP Status Report|---- PCRpt message ---->| 923 sent (->Up|Down) | | 924 | | 926 Figure 8: Active Stateful PCE 928 Once a PCC has successfully established a PCEP session with an active 929 stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. 930 the PCE knows about all PCC's existing LSPs) and LSPs have been 931 delegated to the PCE, the PCE can modify LSP parameters of delegated 932 LSPs. 934 A PCE sends an LSP Update Request carried on a PCUpd message to the 935 PCC. The LSP Update Request contains a variety of objects that 936 specify the set of constraints and attributes for the LSP's path. 937 Each LSP Update Request has a unique identifier, the SRP-ID-number, 938 carried in the SRP (Stateful PCE Request Parameters) Object described 939 in Section 7.2. The SRP-ID-number is used to correlate errors and 940 state reports to LSP Update Requests. A single PCUpd message MAY 941 contain multiple LSP Update Requests. 943 Upon receiving a PCUpd message the PCC starts to setup LSPs specified 944 in LSP Update Requests carried in the message. For each LSP, it 945 sends an LSP State Report carried on a PCRpt message to the PCE, 946 indicating that the LSP's status is 'Pending'. If the PCC decides 947 that the LSP parameters proposed in the PCUpd message are 948 unacceptable, it MUST report this error by including the LSP-ERROR- 949 CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable 950 parameters" in the LSP object in the PCRpt message to the PCE. Based 951 on local policy, it MAY react further to this error by revoking the 952 delegation. If the PCC receives a PCUpd message for an LSP object 953 identified with a PLSP-ID that does not exist on the PCC, it MUST 954 generate a PCErr with error-type 19 (Invalid Operation), error-value 955 3, (Attempted LSP Update Request for an LSP identified by an unknown 956 PSP-ID) (see Section 8.4). 958 Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) 959 to the PCE, indicating that the LSP's status is 'Up'. If the LSP 960 could not be set up, the PCC sends an LSP State Report indicating 961 that the LSP is 'Down' and stating the cause of the failure. A PCC 962 may choose to compress LSP State Reports to only reflect the most up 963 to date state, as discussed in the previous section. 965 A PCC sends each LSP State Report to each stateful PCE that is 966 connected to the PCC. 968 PCErr and PCRpt messages triggered as a result of a PCUpd message 969 MUST include the SRP-ID-number from the PCUpd. This provides 970 correlation of requests and errors and acknowledgement of state 971 processing. The PCC may choose to compress state when processing 972 PCUpd. In this case, receipt of a higher SRP-ID-number implicitly 973 acknowledges processing all the earlier updates for the specific LSP. 975 A PCC MUST NOT send to any PCE a Path Computation Request for a 976 delegated LSP. Should the PCC decide it wants to issue a Path 977 Computation Request on a delegated LSP, it MUST perform Delegation 978 Revocation procedure first. 980 5.7. LSP Protection 982 LSP protection and interaction with stateful PCE, as well as the 983 extensions necessary to implement this functionality will be 984 discussed in a separate draft. 986 5.8. Transport 988 A permanent PCEP session MUST be established between a stateful PCE 989 and the PCC. In the case of session failure, session reestablishment 990 MUST be re-attempted per the procedures defined in [RFC5440]. 992 6. PCEP Messages 994 As defined in [RFC5440], a PCEP message consists of a common header 995 followed by a variable-length body made of a set of objects that can 996 be either mandatory or optional. An object is said to be mandatory 997 in a PCEP message when the object must be included for the message to 998 be considered valid. For each PCEP message type, a set of rules is 999 defined that specify the set of objects that the message can carry. 1000 An implementation MUST form the PCEP messages using the object 1001 ordering specified in this document. 1003 6.1. The PCRpt Message 1005 A Path Computation LSP State Report message (also referred to as 1006 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 1007 current state of an LSP. A PCRpt message can carry more than one LSP 1008 State Reports. A PCC can send an LSP State Report either in response 1009 to an LSP Update Request from a PCE, or asynchronously when the state 1010 of an LSP changes. The Message-Type field of the PCEP common header 1011 for the PCRpt message is set to [TBD]. 1013 The format of the PCRpt message is as follows: 1015 ::= 1016 1017 Where: 1019 ::= [] 1021 ::= [] 1022 1023 1024 Where: 1025 ::= [] 1027 Where: 1028 is defined in [RFC5440] and extended by PCEP extensions. 1030 The SRP object (see Section 7.2) is optional. If the PCRpt message 1031 is not in response to a PCupd message, the SRP object MAY be omitted. 1032 When the PCC does not include the SRP object, the PCE treats this as 1033 an SRP object with an SRP-ID-number equal to the reserved value 1034 0x00000000. The reserved value 0x00000000 indicates that the state 1035 reported is not as a result of processing a PCUpd message. 1037 If the PCRpt message is in response to a PCUpd message, the SRP 1038 object SHOULD be included and the value of the SRP-ID-number in the 1039 SRP Object MUST be the same as that sent in the PCUpd message that 1040 triggered the state that is reported. If the PCC compressed several 1041 PCUpd messages for the same LSP by only processing the latest one, 1042 then it should use the SRP-ID-number of that request. No state 1043 compression is allowed for state reporting, e.g. PCRpt messages MUST 1044 NOT be pruned from the PCC's egress queue even if subsequent 1045 operations on the same LSP have been completed before the PCRpt 1046 message has been sent to the TCP stack. The PCC MUST explicitly 1047 report state changes (including removal) for paths it manages. 1049 The LSP object (see Section 7.3) is mandatory, and it MUST be 1050 included in each LSP State Report on the PCRpt message. If the LSP 1051 object is missing, the receiving PCE MUST send a PCErr message with 1052 Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP 1053 object missing). 1055 If the LSP transitioned to non-operational state, the PCC SHOULD 1056 include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error 1057 Code to report the error to the PCE. 1059 The RRO SHOULD be included by the PCC when the path is up, but MAY be 1060 omitted if the path is down due to a signaling error or another 1061 failure. 1063 A PCE may choose to implement a limit on the resources a single PCC 1064 can occupy. If a PCRpt is received that causes the PCE to exceed 1065 this limit, it MUST send a PCErr message with error-type 19 (invalid 1066 operation) and error-value 4 (indicating resource limit exceeded) in 1067 response to the PCRpt message triggering this condition and MAY 1068 terminate the session. 1070 6.2. The PCUpd Message 1072 A Path Computation LSP Update Request message (also referred to as 1073 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 1074 attributes of an LSP. A PCUpd message can carry more than one LSP 1075 Update Request. The Message-Type field of the PCEP common header for 1076 the PCUpd message is set to [TBD]. 1078 The format of a PCUpd message is as follows: 1080 ::= 1081 1082 Where: 1084 ::= [] 1086 ::= 1087 1088 1089 Where: 1090 ::= 1092 Where: 1093 is defined in [RFC5440] and extended by PCEP extensions. 1095 There are three mandatory objects that MUST be included within each 1096 LSP Update Request in the PCUpd message: the SRP Object (see 1097 Section 7.2), the LSP object (see Section 7.3) and the ERO object (as 1098 defined in [RFC5440]. If the SRP object is missing, the receiving 1099 PCC MUST send a PCErr message with Error-type=6 (Mandatory Object 1100 missing) and Error-value=10 (SRP object missing). If the LSP object 1101 is missing, the receiving PCC MUST send a PCErr message with Error- 1102 type=6 (Mandatory Object missing) and Error-value=8 (LSP object 1103 missing). If the ERO object is missing, the receiving PCC MUST send 1104 a PCErr message with Error-type=6 (Mandatory Object missing) and 1105 Error-value=9(ERO object missing). 1107 A PCC only acts on an LSP Update Request if permitted by the local 1108 policy configured by the network manager. Each LSP Update Request 1109 that the PCC acts on results in an LSP setup operation. An LSP 1110 Update Request MUST contain all LSP parameters that a PCE wishes to 1111 be set for the LSP. A PCC MAY set missing parameters from locally 1112 configured defaults. If the LSP specified in the Update Request is 1113 already up, it will be re-signaled. 1115 The PCC SHOULD minimize the traffic interruption, and MAY use the 1116 make-before-break procedures described in [RFC3209] in order to 1117 achieve this goal. If the make-before-break procedures are used, two 1118 paths will briefly co-exist. The PCC MUST send separate PCRpt 1119 messages for each, identified by the LSP-IDENTIFIERS TLV. When the 1120 old path is torn down after the head end switches over the traffic, 1121 this event MUST be reported by sending a PCRpt message with the LSP- 1122 IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number 1123 that the PCE associates with this PCRpt MUST be 0x00000000. Thus, a 1124 make-before-break operation will typically result in at least two 1125 PCRpt messages, one for the new path and one for the removal of the 1126 old path (more messages may be possible if intermediate states are 1127 reported). 1129 A PCC MUST respond with an LSP State Report to each LSP Update 1130 Request it processed to indicate the resulting state of the LSP in 1131 the network (even if this processing did not result in changing the 1132 state of the LSP). The SRP-ID-number included in the PCRpt MUST 1133 match that in the PCUpd. A PCC MAY respond with multiple LSP State 1134 Reports to report LSP setup progress of a single LSP. In that case, 1135 the SRP-ID-number MUST be included for the first message, for 1136 subsequent messages the reserved value 0x00000000 SHOULD be used. 1138 Note that a PCC MUST process all LSP Update Requests - for example, 1139 an LSP Update Request is sent when a PCE returns delegation or puts 1140 an LSP into non-operational state. The protocol relies on TCP for 1141 message-level flow control. 1143 If the rate of PCUpd messages sent to a PCC for the same target LSP 1144 exceeds the rate at which the PCC can signal LSPs into the network, 1145 the PCC MAY perform state compression on its ingress queue. The 1146 compression algorithm is based on the fact that each PCUpd request 1147 contains the complete LSP state the PCE wishes to be set and works as 1148 follows: when the PCC starts processing a PCUpd message at the head 1149 of its ingress queue, it may search the queue forward for more recent 1150 PCUpd messages pertaining that particular LSP, prune all but the 1151 latest one from the queue and process only the last one as that 1152 request contains the most up-to-date desired state for the LSP. The 1153 PCC MUST NOT send PCRpt nor PCErr messages for requests which were 1154 pruned from the queue in this way. This compression step may be 1155 performed only while the LSP is not being signaled, e.g. if two PCUpd 1156 arrive for the same LSP in quick succession and the PCC started the 1157 signaling of the changes relevant to the first PCUpd, then it MUST 1158 wait until the signaling finishes (and report the new state via a 1159 PCRpt) before attempting to apply the changes indicated in the second 1160 PCUpd. 1162 Note also that it is up to the PCE to handle inter-LSP dependencies; 1163 for example, if ordering of LSP set-ups is required, the PCE has to 1164 wait for an LSP State Report for a previous LSP before starting the 1165 update of the next LSP. If the PCUpd cannot be satisfied (for 1166 example due to unsupported object or TLV), the PCC MUST respond with 1167 a PCErr message indicating the failure (see Section 7.3.3). 1169 6.3. The PCErr Message 1171 If the stateful PCE capability has been advertised on the PCEP 1172 session, the PCErr message MAY include the SRP object. If the error 1173 reported is the result of an LSP update request, then the SRP-ID- 1174 number MUST be the one from the PCUpd that triggered the error. If 1175 the error is unsolicited, the SRP object MAY be omitted. This is 1176 equivalent to including an SRP object with SRP-ID-number equal to the 1177 reserved value 0x00000000. 1179 The format of a PCErr message from [RFC5440] is extended as follows: 1181 ::= 1182 ( [] ) | 1183 [] 1185 ::=[] 1187 ::=[ | ] <<<< new 1188 1190 ::=[] 1192 ::=[] <<< new 1194 ::=[] 1196 7. Object Formats 1198 The PCEP objects defined in this document are compliant with the PCEP 1199 object format defined in [RFC5440]. The P flag and the I flag of the 1200 PCEP objects defined in this document MUST always be set to 0 on 1201 transmission and MUST be ignored on receipt since these flags are 1202 exclusively related to path computation requests. 1204 7.1. OPEN Object 1206 This document defines two new optional TLVs for use in the OPEN 1207 Object. 1209 7.1.1. Stateful PCE Capability TLV 1211 The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the 1212 OPEN Object for stateful PCE capability advertisement. Its format is 1213 shown in the following figure: 1215 0 1 2 3 1216 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 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | Type=[TBD] | Length=4 | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | Flags |U| 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 Figure 9: STATEFUL-PCE-CAPABILITY TLV format 1225 The type of the TLV is [TBD] and it has a fixed length of 4 octets. 1227 The value comprises a single field - Flags (32 bits): 1229 U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag 1230 indicates that the PCC allows modification of LSP parameters; if 1231 set to 1 by a PCE, the U Flag indicates that the PCE is capable of 1232 updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be 1233 advertised by both a PCC and a PCE for PCUpd messages to be 1234 allowed on a PCEP session. 1236 Unassigned bits are considered reserved. They MUST be set to 0 on 1237 transmission and MUST be ignored on receipt. 1239 Advertisement of the stateful PCE capability implies support of LSPs 1240 that are signaled via RSVP, as well as the objects, TLVs and 1241 procedures defined in this document. 1243 7.2. SRP Object 1245 The SRP (Stateful PCE Request Parameters) object MUST be carried 1246 within PCUpd messages and MAY be carried within PCRpt and PCErr 1247 messages. The SRP object is used to correlate between update 1248 requests sent by the PCE and the error reports and state reports sent 1249 by the PCC. 1251 SRP Object-Class is [TBD]. 1253 SRP Object-Type is 1. 1255 The format of the SRP object body is shown in Figure 10: 1257 0 1 2 3 1258 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Flags | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | SRP-ID-number | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | | 1265 // Optional TLVs // 1266 | | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 Figure 10: The SRP Object format 1271 The SRP object body has a variable length and may contain additional 1272 TLVs. 1274 Flags (32 bits): None defined yet. 1276 SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the 1277 current PCEP session uniquely identify the operation that the PCE has 1278 requested the PCC to perform on a given LSP. The SRP-ID-number is 1279 incremented each time a new request is sent to the PCC, and may wrap 1280 around. 1282 The values 0x00000000 and 0xFFFFFFFF are reserved. 1284 Every request to update an LSP receives a new SRP-ID-number. This 1285 number is unique per PCEP session and is incremented each time an 1286 operation is requested from the PCE. Thus, for a given LSP there may 1287 be more than one SRP-id-number unacknowledged at a given time. The 1288 value of the SRP-ID-number is echoed back by the PCC in PCErr and 1289 PCRpt messages to allow for correlation between requests made by the 1290 PCE and errors or state reports generated by the PCC. If the error 1291 or report were not as a result of a PCE operation (for example in the 1292 case of a link down event), the reserved value of 0x00000000 is used 1293 for the SRP-ID-number. The absence of the SRP object is equivalent 1294 to an SRP object with the reserved value of 0x00000000. An SRP-ID- 1295 number is considered unacknowledged and cannot be reused until a 1296 PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the 1297 same LSP. A PCRpt with state "Pending" is not considered as an 1298 acknowledgement. 1300 7.3. LSP Object 1302 The LSP object MUST be present within PCRpt and PCUpd messages. The 1303 LSP object contains a set of fields used to specify the target LSP, 1304 the operation to be performed on the LSP, and LSP Delegation. It 1305 also contains a flag indicating to a PCE that the LSP state 1306 synchronization is in progress. This document focuses on LSPs that 1307 are signaled with RSVP, many of the TLVs used with the LSP object 1308 mirror RSVP state. 1310 LSP Object-Class is [TBD]. 1312 LSP Object-Type is 1. 1314 The format of the LSP object body is shown in Figure 11: 1316 0 1 2 3 1317 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 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | PLSP-ID | Flag | O|A|R|S|D| 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 // TLVs // 1322 | | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 Figure 11: The LSP Object format 1327 PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC 1328 creates a unique PLSP-ID for each LSP that is constant for the 1329 lifetime of a PCEP session. The PCC will advertise the same PLSP-ID 1330 on all PCEP sessions it maintains at a given times. The mapping of 1331 the Symbolic Path Name to PLSP-ID is communicated to the PCE by 1332 sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All 1333 subsequent PCEP messages then address the LSP by the PLSP-ID. The 1334 values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a 1335 value that is constant for the lifetime of the PCEP session, during 1336 which time for an RSVP-signaled LSP there might be a different RSVP 1337 identifiers (LSP-id, tunnel-id) allocated it. 1339 Flags (12 bits): 1341 D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1 1342 indicates that the PCC is delegating the LSP to the PCE. On a 1343 PCUpd message, the D flag set to 1 indicates that the PCE is 1344 confirming the LSP Delegation. To keep an LSP delegated to the 1345 PCE, the PCC must set the D flag to 1 on each PCRpt message for 1346 the duration of the delegation - the first PCRpt with the D flag 1347 set to 0 revokes the delegation. To keep the delegation, the PCE 1348 must set the D flag to 1 on each PCUpd message for the duration of 1349 the delegation - the first PCUpd with the D flag set to 0 returns 1350 the delegation. 1352 S (SYNC - 1 bit): the S Flag MUST be set to 1 on each PCRpt sent 1353 from a PCC during State Synchronization. The S Flag MUST be set 1354 to 0 in other PCRpt messages sent from the PCC. 1356 R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1357 LSP has been removed from the PCC and the PCE SHOULD remove all 1358 state from its database. Upon receiving an LSP State Report with 1359 the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD 1360 remove all state for the path identified by the LSP Identifiers 1361 TLV from its database. When the all-zeros LSP-IDENTIFIERS-TLV is 1362 used, the PCE SHOULD remove all state for the PLSP-ID from its 1363 database. 1365 A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates 1366 the PCC's target operational status for this LSP. On PCUpd 1367 messages, the A Flag indicates the LSP status that the PCE desires 1368 for this LSP. In both cases, a value of '1' means that the 1369 desired operational state is active, and a value of '0' means that 1370 the desired operational state is inactive. A PCC ignores the A 1371 flag on a PCUpd message unless the operator's policy allows the 1372 PCE to control the corresponding LSP's administrative state. 1374 O(Operational - 3 bits): On PCRpt messages, the O Field represents 1375 the operational status of the LSP. 1377 The following values are defined: 1379 0 - DOWN: not active. 1381 1 - UP: signalled. 1383 2 - ACTIVE: up and carrying traffic. 1385 3 - GOING-DOWN: LSP is being torn down, resources are being 1386 released. 1388 4 - GOING-UP: LSP is being signalled. 1390 5-7 - Reserved: these values are reserved for future use. 1392 Unassigned bits are considered reserved. They MUST be set to 0 on 1393 transmission and MUST be ignored on receipt. 1395 TLVs that may be included in the LSP Object are described in the 1396 following sections. 1398 7.3.1. LSP Identifiers TLVs 1400 The LSP Identifiers TLV MUST be included in the LSP object in PCRpt 1401 messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will 1402 generate an error with error-type 6 (mandatory object missing) and 1403 error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. 1404 The LSP Identifiers TLV MAY be included in the LSP object in PCUpd 1405 messages for RSVP-signaled LSPs. The special value of all zeros for 1406 this TLV is used to refer to all paths pertaining to a particular 1407 PLSP-ID. There are two LSP Identifiers TLVs, one for IPv4 and one 1408 for IPv6. 1410 It is the responsibility of the PCC to send to the PCE the 1411 identifiers for each RSVP incarnation of the tunnel. For exmple, in 1412 a make-before-break scenario, the PCC MUST send a separate PCRpt for 1413 the old and for the reoptimized paths, and explicitly report removal 1414 of any of these paths using the R bit in the LSP object. 1416 The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 1417 figure: 1419 0 1 2 3 1420 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 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | Type=[TBD] | Length=12 | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | IPv4 Tunnel Sender Address | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | LSP ID | Tunnel ID | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | Extended Tunnel ID | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | IPv4 Tunnel Endpoint Address | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 Figure 12: IPV4-LSP-IDENTIFIERS TLV format 1435 The type of the TLV is [TBD] and it has a fixed length of 12 octets. 1436 The value contains the following fields: 1438 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 1439 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 1440 Sender Template Object. 1442 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1443 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 1444 Object. 1446 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1447 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 1448 Tunnel ID remains constant over the life time of a tunnel. 1450 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 1451 identifier defined in [RFC3209], Section 4.6.1.1 for the 1452 LSP_TUNNEL_IPv4 Session Object. 1454 IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 1455 address, as defined in [RFC3209], Section 4.6.1.1 for the 1456 LSP_TUNNEL_IPv4 Sender Template Object. 1458 The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l following 1459 figure: 1461 0 1 2 3 1462 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 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | Type=[TBD] | Length=36 | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | | 1467 + + 1468 | IPv6 tunnel sender address | 1469 + (16 octets) + 1470 | | 1471 + + 1472 | | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | LSP ID | Tunnel ID | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | | 1477 + + 1478 | Extended Tunnel ID | 1479 + (16 octets) + 1480 | | 1481 + + 1482 | | 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | | 1485 + + 1486 | IPv6 tunnel endpoint address | 1487 + (16 octets) + 1488 | | 1489 + + 1490 | | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 Figure 13: IPV6-LSP-IDENTIFIERS TLV format 1495 The type of the TLV is [TBD] and it has a fixed length of 36 octets. 1496 The value contains the following fields: 1498 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 1499 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 1500 Sender Template Object. 1502 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1503 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 1504 Object. 1506 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1507 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 1508 Tunnel ID remains constant over the life time of a tunnel. 1509 However, when Global Path Protection or Global Default Restoration 1510 is used, both the primary and secondary LSPs have their own Tunnel 1511 IDs. A PCC will report a change in Tunnel ID when traffic 1512 switches over from primary LSP to secondary LSP (or vice versa). 1514 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 1515 identifier defined in [RFC3209], Section 4.6.1.2 for the 1516 LSP_TUNNEL_IPv6 Session Object. 1518 IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 1519 address, as defined in [RFC3209], Section 4.6.1.2 for the 1520 LSP_TUNNEL_IPv6 Session Object. 1522 7.3.2. Symbolic Path Name TLV 1524 Each LSP (path) MUST have a symbolic name that is unique in the PCC. 1525 This symbolic path name MUST remain constant throughout a path's 1526 lifetime, which may span across multiple consecutive PCEP sessions 1527 and/or PCC restarts. The symbolic path name MAY be specified by an 1528 operator in a PCC's configuration. If the operator does not specify 1529 a unique symbolic name for a path, the PCC MUST auto-generate one. 1531 The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report 1532 when during a given PCEP session an LSP is first reported to a PCE. 1533 A PCC sends to a PCE the first LSP State Report either during State 1534 Synchronization, or when a new LSP is configured at the PCC. The 1535 symbolic path name MAY be included in subsequent LSP State Reports 1536 for the LSP. 1538 The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in the LSP Object 1540 The format of the SYMBOLIC-PATH-NAME TLV is shown in the following 1541 figure: 1543 0 1 2 3 1544 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 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Type=[TBD] | Length (variable) | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | | 1549 // Symbolic Path Name // 1550 | | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 Figure 14: SYMBOLIC-PATH-NAME TLV format 1555 The type of the TLV is [TBD] and it has a variable length, which MUST 1556 be greater than 0. 1558 7.3.3. LSP Error Code TLV 1560 The LSP Error code TLV is an optional TLV for use in the LSP object 1561 to convey error information. When an LSP Update Request fails, an 1562 LSP State Report MUST be sent to report the current state of the LSP, 1563 and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for 1564 the failure. Similarly, when a PCRpt is sent as a result of an LSP 1565 transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD 1566 be included to indicate the reason for the transition. 1568 The format of the LSP-ERROR-CODE TLV is shown in the following 1569 figure: 1571 0 1 2 3 1572 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 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Type=[TBD] | Length=4 | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | LSP Error Code | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 Figure 15: LSP-ERROR-CODE TLV format 1581 The type of the TLV is [TBD] and it has a fixed length of 4 octets. 1582 The value contains an error code that indicates the cause of the 1583 failure. 1585 The following LSP Error Codes are defined: 1587 Value Meaning 1588 1 Unknown reason 1589 2 Limit reached for PCE-controlled LSPs 1590 3 Too many pending LSP update requests 1591 4 Unacceptable parameters 1592 5 Internal error 1593 6 LSP administratively brought down 1594 7 LSP preempted 1595 8 RSVP signaling error 1597 7.3.4. RSVP Error Spec TLV 1599 The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object 1600 to carry RSVP error information. It includes the RSVP ERROR_SPEC or 1601 USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned 1602 to the PCC from a downstream node. If the set up of an LSP fails at 1603 a downstream node which returned an ERROR_SPEC to the PCC, the PCC 1604 SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with 1605 LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV 1606 with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object. 1608 The format of the RSVP-ERROR-SPEC TLV is shown in the following 1609 figure: 1611 0 1 2 3 1612 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 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Type=[TBD] | Length (variable) | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | | 1617 + RSVP ERROR_SPEC or USER_ERROR_SPEC Object + 1618 | | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 Figure 16: RSVP-ERROR-SPEC TLV format 1623 The type of the TLV is [TBD] and it has a variable length. The value 1624 contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the 1625 object header. 1627 8. IANA Considerations 1629 This document requests IANA actions to allocate code points for the 1630 protocol elements defined in this document. Values shown here are 1631 suggested for use by IANA. 1633 8.1. PCEP Messages 1635 This document defines the following new PCEP messages: 1637 Value Meaning Reference 1638 10 Report This document 1639 11 Update This document 1641 8.2. PCEP Objects 1643 This document defines the following new PCEP Object-classes and 1644 Object-values: 1646 Object-Class Value Name Reference 1648 32 LSP This document 1649 Object-Type 1650 1 1651 33 SRP This document 1652 Object-Type 1653 1 1655 8.3. LSP Object 1657 This document requests that a registry is created to manage the Flags 1658 field of the LSP object. New values are to be assigned by Standards 1659 Action [RFC5226]. Each bit should be tracked with the following 1660 qualities: 1662 o Bit number (counting from bit 0 as the most significant bit) 1664 o Capability description 1666 o Defining RFC 1668 The following values are defined in this document: 1670 Bit Description Reference 1672 25-27 Operational (3 bits) This document 1673 28 Administrative This document 1674 29 Remove This document 1675 30 SYNC This document 1676 31 Delegate This document 1678 8.4. PCEP-Error Object 1680 This document defines new Error-Type and Error-Value for the 1681 following new error conditions: 1683 Error-Type Meaning 1684 6 Mandatory Object missing 1685 Error-value=8: LSP Object missing 1686 Error-value=9: ERO Object missing 1687 Error-value=10: SRP Object missing 1688 Error-value=11: LSP-IDENTIFIERS TLV missing 1689 19 Invalid Operation 1690 Error-value=1: Attempted LSP Update Request for a non- 1691 delegated LSP. The PCEP-ERROR Object 1692 is followed by the LSP Object that 1693 identifies the LSP. 1694 Error-value=2: Attempted LSP Update Request if active 1695 stateful PCE capability was not 1696 advertised. 1697 Error-value=3: Attempted LSP Update Request for an LSP 1698 identified by an unknown PLSP-ID. 1699 Error-value=4: A PCE indicates to a PCC that it has 1700 exceeded the resource limit allocated 1701 for its state, and thus it cannot 1702 accept and process its LSP State Report 1703 message. 1704 Error-value=5: Attempted LSP State Report if active 1705 stateful PCE capability was not 1706 advertised. 1707 20 LSP State synchronization error. 1708 Error-value=1: A PCE indicates to a PCC that it can 1709 not process (an otherwise valid) LSP 1710 State Report. The PCEP-ERROR Object is 1711 followed by the LSP Object that 1712 identifies the LSP. 1713 Error-value=5: A PCC indicates to a PCE that it can 1714 not complete the state synchronization, 1716 8.5. PCEP TLV Type Indicators 1718 This document defines the following new PCEP TLVs: 1720 Value Meaning Reference 1721 16 STATEFUL-PCE-CAPABILITY This document 1722 17 SYMBOLIC-PATH-NAME This document 1723 18 IPV4-LSP-IDENTIFIERS This document 1724 19 IPV6-LSP-IDENTIFIERS This document 1725 20 LSP-ERROR-CODE This document 1726 21 RSVP-ERROR-SPEC This document 1728 8.6. STATEFUL-PCE-CAPABILITY TLV 1730 This document requests that a registry is created to manage the Flags 1731 field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New 1732 values are to be assigned by Standards Action [RFC5226]. Each bit 1733 should be tracked with the following qualities: 1735 o Bit number (counting from bit 0 as the most significant bit) 1736 o Capability description 1738 o Defining RFC 1740 The following values are defined in this document: 1742 Bit Description Reference 1744 31 LSP-UPDATE-CAPABILITY This document 1746 8.7. LSP-ERROR-CODE TLV 1748 This document requests that a registry is created to manage the value 1749 of the LSP error code field in this TLV. This field specifies the 1750 reason for failure to update the LSP. 1752 Value Meaning 1753 1 Unknown reason 1754 2 Limit reached for PCE-controlled LSPs 1755 3 Too many pending LSP update requests 1756 4 Unacceptable parameters 1757 5 Internal error 1758 6 LSP administratively brought down 1759 7 LSP preempted 1760 8 RSVP signaling error 1762 9. Manageability Considerations 1764 All manageability requirements and considerations listed in [RFC5440] 1765 apply to PCEP protocol extensions defined in this document. In 1766 addition, requirements and considerations listed in this section 1767 apply. 1769 9.1. Control Function and Policy 1771 In addition to configuring specific PCEP session parameters, as 1772 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 1773 allow configuring the stateful PCEP capability and the LSP Update 1774 capability. A PCC implementation SHOULD allow the operator to 1775 specify multiple candidate PCEs for and a delegation preference for 1776 each candidate PCE. A PCC SHOULD allow the operator to specify an 1777 LSP delegation policy where LSPs are delegated to the most-preferred 1778 online PCE. A PCC MAY allow the operator to specify different LSP 1779 delegation policies. 1781 A PCC implementation which allows concurrent connections to multiple 1782 PCEs SHOULD allow the operator to group the PCEs by administrative 1783 domains and it MUST NOT advertise LSP existence and state to a PCE if 1784 the LSP is delegated to a PCE in a different group. 1786 A PCC implementation SHOULD allow the operator to specify whether the 1787 PCC will advertise LSP existence and state for LSPs that are not 1788 controlled by any PCE (for example, LSPs that are statically 1789 configured at the PCC). 1791 A PCC implementation SHOULD allow the operator to specify both the 1792 Redelegation Timeout Interval and the State Timeout Interval. The 1793 default value of the Redelegation Timeout Interval SHOULD be set to 1794 30 seconds. An operator MAY also configure a policy that will 1795 dynamically adjust the Redelegation Timeout Interval, for example 1796 setting it to zero when the PCC has an established session to a 1797 backup PCE. The default value for the State Timeout Interval SHOULD 1798 be set to 60 seconds. 1800 After the expiration of the State Timeout Interval, the LSP reverts 1801 to operator-defined default parameters. A PCC implementation MUST 1802 allow the operator to specify the default LSP parameters. To achieve 1803 a behavior where the LSP retains the parameters set by the PCE until 1804 such time that the PCC makes a change to them, a State Timeout 1805 Interval of infinity SHOULD be used. Any changes to LSP parameters 1806 SHOULD be done in make-before-break fashion. 1808 A PCC implementation SHOULD allow the operator to specify delegation 1809 priority for PCEs. This effectively defines the primary PCE and one 1810 or more backup PCEs to which primary PCE's LSPs can be delegated when 1811 the primary PCE fails. 1813 Policies defined for stateful PCEs and PCCs should eventually fit in 1814 the Policy-Enabled Path Computation Framework defined in [RFC5394], 1815 and the framework should be extended to support Stateful PCEs. 1817 9.2. Information and Data Models 1819 PCEP session configuration and information in the PCEP MIB module 1820 SHOULD be extended to include advertised stateful capabilities, 1821 synchronization status, and delegation status (at the PCC list PCEs 1822 with delegated LSPs). 1824 9.3. Liveness Detection and Monitoring 1826 PCEP protocol extensions defined in this document do not require any 1827 new mechanisms beyond those already defined in [RFC5440], Section 1828 8.3. 1830 9.4. Verifying Correct Operation 1832 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 1833 protocol extensions defined in this document. In addition to 1834 monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP 1835 implementation SHOULD provide the following parameters: 1837 o Total number of LSP updates 1839 o Number of successful LSP updates 1841 o Number of dropped LSP updates 1843 o Number of LSP updates where LSP setup failed 1845 A PCC implementation SHOULD provide a command to show for each LSP 1846 whether it is delegated, and if so, to which PCE. 1848 A PCC implementation SHOULD allow the operator to manually revoke LSP 1849 delegation. 1851 9.5. Requirements on Other Protocols and Functional Components 1853 PCEP protocol extensions defined in this document do not put new 1854 requirements on other protocols. 1856 9.6. Impact on Network Operation 1858 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 1859 protocol extensions defined in this document. 1861 Additionally, a PCEP implementation SHOULD allow a limit to be placed 1862 on the number of LSPs delegated to the PcE and on the rate of PCUpd 1863 and PCRpt messages sent by a PCEP speaker and processed from a peer. 1864 It SHOULD also allow sending a notification when a rate threshold is 1865 reached. 1867 A PCC implementation SHOULD allow a limit to be placed on the rate of 1868 LSP Updates to the same LSP to avoid signaling overload discussed in 1869 Section 10.3. 1871 10. Security Considerations 1873 10.1. Vulnerability 1875 This document defines extensions to PCEP to enable stateful PCEs. 1876 The nature of these extensions and the delegation of path control to 1877 PCEs results in more information being available for a hypothetical 1878 adversary and a number of additional attack surfaces which must be 1879 protected. 1881 The security provisions described in [RFC5440] remain applicable to 1882 these extensions. However, because the protocol modifications 1883 outlined in this document allow the PCE to control path computation 1884 timing and sequence, the PCE defense mechanisms described in 1885 [RFC5440] section 7.2 are also now applicable to PCC security. 1887 As a general precaution, it is RECOMMENDED that these PCEP extensions 1888 only be activated on authenticated and encrypted sessions across PCEs 1889 and PCCs belonging to the same administrative authority. 1891 The following sections identify specific security concerns that may 1892 result from the PCEP extensions outlined in this document along with 1893 recommended mechanisms to protect PCEP infrastructure against related 1894 attacks. 1896 10.2. LSP State Snooping 1898 The stateful nature of this extension explicitly requires LSP status 1899 updates to be sent from PCC to PCE. While this gives the PCE the 1900 ability to provide more optimal computations to the PCC, it also 1901 provides an adversary with the opportunity to eavesdrop on decisions 1902 made by network systems external to PCE. This is especially true if 1903 the PCC delegates LSPs to multiple PCEs simultaneously. 1905 Adversaries may gain access to this information by eavesdropping on 1906 unsecured PCEP sessions, and might then use this information in 1907 various ways to target or optimize attacks on network infrastructure. 1908 For example by flexibly countering anti-DDoS measures being taken to 1909 protect the network, or by determining choke points in the network 1910 where the greatest harm might be caused. 1912 PCC implementations which allow concurrent connections to multiple 1913 PCEs SHOULD allow the operator to group the PCEs by administrative 1914 domains and they MUST NOT advertise LSP existence and state to a PCE 1915 if the LSP is delegated to a PCE in a different group. 1917 10.3. Malicious PCE 1919 The LSP delegation mechanism described in this document allows a PCC 1920 to grant effective control of an LSP to the PCE for the duration of a 1921 PCEP session. While this enables PCE control of the timing and 1922 sequence of path computations within and across PCEP sessions, it 1923 also introduces a new attack vector: an attacker may flood the PCC 1924 with PCUpd messages at a rate which exceeds either the PCC's ability 1925 to process them or the network's ability to signal the changes, 1926 either by spoofing messages or by compromising the PCE itself. 1928 A PCC is free to revoke an LSP delegation at any time without needing 1929 any justification. A defending PCC can do this by enqueueing the 1930 appropriate PCRpt message. As soon as that message is enqueued in 1931 the session, the PCC is free to drop any incoming PCUpd messages 1932 without additional processing. 1934 10.4. Malicious PCC 1936 A stateful session also result in increased attack surface by placing 1937 a requirement for the PCE to keep an LSP state replica for each PCC. 1938 It is RECOMMENDED that PCE implementations provide a limit on 1939 resources a single PCC can occupy. A PCE implementing such a limit 1940 MUST send a PCErr message with error-type 19 (invalid operation) and 1941 error-value 4 (indicating resource limit exceeded) upon receiving an 1942 LSP state report causing it to exceed this threshold. 1944 Delegation of LSPs can create further strain on PCE resources and a 1945 PCE implementation MAY preemptively give back delegations if it finds 1946 itself lacking the resources needed to effectively manage the 1947 delegation. Since the delegation state is ultimately controlled by 1948 the PCC, PCE implementations SHOULD provide throttling mechanisms to 1949 prevent strain created by flaps of either a PCEP session or an LSP 1950 delegation. 1952 11. Acknowledgements 1954 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 1955 Casellas for their contributions to this document. 1957 We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, 1958 Paul Schultz and Raveendra Torvi for their comments and suggestions. 1959 Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Ramon 1960 Casellas, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin 1961 Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin 1962 Sampath, Calvin Ying and Xian Zhang for helpful comments and 1963 discussions. 1965 12. References 1967 12.1. Normative References 1969 [I-D.ietf-pce-gmpls-pcep-extensions] 1970 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 1971 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-09 (work in 1972 progress), February 2014. 1974 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1975 Requirement Levels", BCP 14, RFC 2119, March 1997. 1977 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1978 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1979 Functional Specification", RFC 2205, September 1997. 1981 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1982 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1983 Tunnels", RFC 3209, December 2001. 1985 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1986 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1987 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1989 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1990 "OSPF Protocol Extensions for Path Computation Element 1991 (PCE) Discovery", RFC 5088, January 2008. 1993 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1994 "IS-IS Protocol Extensions for Path Computation Element 1995 (PCE) Discovery", RFC 5089, January 2008. 1997 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1998 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1999 May 2008. 2001 [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", 2002 RFC 5284, August 2008. 2004 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 2005 (PCE) Communication Protocol (PCEP)", RFC 5440, 2006 March 2009. 2008 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2009 Used to Form Encoding Rules in Various Routing Protocol 2010 Specifications", RFC 5511, April 2009. 2012 12.2. Informative References 2014 [I-D.ietf-pce-stateful-pce-app] 2015 Zhang, X. and I. Minei, "Applicability of Stateful Path 2016 Computation Element (PCE)", 2017 draft-ietf-pce-stateful-pce-app-01 (work in progress), 2018 September 2013. 2020 [I-D.minei-pce-stateful-sync-optimizations] 2021 Crabbe, E., Medved, J., Minei, I., Varga, R., Zhang, X., 2022 and D. Dhody, "Optimizations of Label Switched Path State 2023 Synchronization Procedures for a Stateful PCE", 2024 draft-minei-pce-stateful-sync-optimizations-01 (work in 2025 progress), December 2013. 2027 [I-D.sivabalan-pce-disco-stateful] 2028 Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions 2029 for Stateful PCE Discovery", 2030 draft-sivabalan-pce-disco-stateful-03 (work in progress), 2031 January 2014. 2033 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2034 LSP Path Computation using Preemption", Global 2035 Information Infrastructure Symposium, July 2007. 2037 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2038 programming algorithm for balancing the max-min fairness 2039 and throughput objectives in traffic engineering", 2040 INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012. 2042 [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network 2043 Recovery: Protection and Restoration of Optical, SONET- 2044 SDH, IP, and MPLS", The Morgan Kaufmann Series in 2045 Networking, June 2004. 2047 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2048 McManus, "Requirements for Traffic Engineering Over MPLS", 2049 RFC 2702, September 1999. 2051 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2052 Label Switching Architecture", RFC 3031, January 2001. 2054 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2055 Christian, B., and W. Lai, "Applicability Statement for 2056 Traffic Engineering with MPLS", RFC 3346, August 2002. 2058 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2059 (TE) Extensions to OSPF Version 2", RFC 3630, 2060 September 2003. 2062 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2063 Element (PCE)-Based Architecture", RFC 4655, August 2006. 2065 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 2066 Communication Protocol Generic Requirements", RFC 4657, 2067 September 2006. 2069 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2070 Engineering", RFC 5305, October 2008. 2072 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2073 "Policy-Enabled Path Computation Framework", RFC 5394, 2074 December 2008. 2076 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 2077 Computation Element Communication Protocol (PCEP) 2078 Requirements and Protocol Extensions in Support of Global 2079 Concurrent Optimization", RFC 5557, July 2009. 2081 Authors' Addresses 2083 Edward Crabbe 2084 Google, Inc. 2085 1600 Amphitheatre Parkway 2086 Mountain View, CA 94043 2087 US 2089 Email: edc@google.com 2091 Jan Medved 2092 Cisco Systems, Inc. 2093 170 West Tasman Dr. 2094 San Jose, CA 95134 2095 US 2097 Email: jmedved@cisco.com 2099 Ina Minei 2100 Google, Inc. 2101 1600 Amphitheatre Parkway 2102 Mountain View, CA 94043 2103 US 2105 Email: inaminei@google.com 2106 Robert Varga 2107 Pantheon Technologies SRO 2108 Mlynske Nivy 56 2109 Bratislava 821 05 2110 Slovakia 2112 Email: robert.varga@pantheon.sk