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