idnits 2.17.1 draft-ietf-pce-stateful-pce-06.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 3 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 (August 19, 2013) is 3875 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 1876, but not defined == Unused Reference: 'RFC3473' is defined on line 2287, but no explicit reference was found in the text == Unused Reference: 'NET-REC' is defined on line 2341, but no explicit reference was found in the text == Unused Reference: 'RFC5557' is defined on line 2375, 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-00 == Outdated reference: A later version (-03) exists of draft-sivabalan-pce-disco-stateful-02 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Crabbe 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track J. Medved 5 Expires: February 20, 2014 Cisco Systems, Inc. 6 I. Minei 7 Juniper Networks, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 August 19, 2013 12 PCEP Extensions for Stateful PCE 13 draft-ietf-pce-stateful-pce-06 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 February 20, 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 . . . . . . . . . . . . 10 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 Negotiation . . . . . . . . . . . . . . . . . . 12 80 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 12 81 5.4.1. State Synchronization Avoidance . . . . . . . . . . . 15 82 5.4.2. PCE-triggered State Synchronization . . . . . . . . . 19 83 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 19 84 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 20 85 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 21 86 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 22 87 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 23 88 5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 23 89 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 24 90 5.6.1. Passive Stateful PCE Path Computation 91 Request/Response . . . . . . . . . . . . . . . . . . . 24 92 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 26 93 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 27 94 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 27 95 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 27 96 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 28 97 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 29 98 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 31 99 6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 31 100 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 31 101 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 32 102 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 32 103 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 32 104 7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 33 105 7.1.3. PCE Redundancy Group Identifier TLV . . . . . . . . . 34 106 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 34 107 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 35 108 7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 38 109 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 40 110 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 41 111 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 42 112 7.3.5. LSP State Database Version TLV . . . . . . . . . . . . 42 113 7.3.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 43 114 7.4. Optional TLVs for the LSPA Object . . . . . . . . . . . . 43 115 7.4.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 43 116 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 117 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 43 118 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 44 119 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 44 120 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 44 121 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 45 122 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 46 123 8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 46 124 8.8. LSP-SIG-TYPE field in the LSP object . . . . . . . . . . . 46 125 9. Manageability Considerations . . . . . . . . . . . . . . . . . 47 126 9.1. Control Function and Policy . . . . . . . . . . . . . . . 47 127 9.2. Information and Data Models . . . . . . . . . . . . . . . 48 128 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 48 129 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 48 130 9.5. Requirements on Other Protocols and Functional 131 Components . . . . . . . . . . . . . . . . . . . . . . . . 49 132 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 49 133 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 134 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 49 135 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 50 136 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 50 137 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 50 138 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 139 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 140 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 141 12.2. Informative References . . . . . . . . . . . . . . . . . . 52 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 144 1. Introduction 146 [RFC5440] describes the Path Computation Element Protocol (PCEP). 147 PCEP defines the communication between a Path Computation Client 148 (PCC) and a Path Computation Element (PCE), or between PCEs, enabling 149 computation of Multiprotocol Label Switching (MPLS) for Traffic 150 Engineering Label Switched Path (TE LSP) characteristics. Extensions 151 for support of Generalized MPLS (GMPLS) in PCEP are defined in 152 [I-D.ietf-pce-gmpls-pcep-extensions] 154 This document specifies a set of extensions to PCEP to enable 155 stateful control of LSPs within and across PCEP sessions in 156 compliance with [RFC4657]. It includes mechanisms to effect LSP 157 state synchronization between PCCs and PCEs, delegation of control 158 over LSPs to PCEs, and PCE control of timing and sequence of path 159 computations within and across PCEP sessions. 161 2. Terminology 163 This document uses the following terms defined in [RFC5440]: PCC, 164 PCE, PCEP Peer, PCEP Speaker. 166 This document uses the following terms defined in [RFC4655]: TED. 168 This document uses the following terms defined in [RFC4090]: MPLS TE 169 Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup. 171 The following terms are defined in this document: 173 Stateful PCE: has access to not only the network state, but also to 174 the set of active paths and their reserved resources for its 175 computations. A stateful PCE might also retain information 176 regarding LSPs under construction in order to reduce churn and 177 resource contention. The additional state allows the PCE to 178 compute constrained paths while considering individual LSPs and 179 their interactions. Note that this requires reliable state 180 synchronization mechanisms between the PCE and the network, PCE 181 and PCC, and between cooperating PCEs. 183 Passive Stateful PCE: uses LSP state information learned from PCCs 184 to optimize path computations. It does not actively update LSP 185 state. A PCC maintains synchronization with the PCE. 187 Active Stateful PCE: is an extension of Passive Stateful PCE, in 188 which the PCE may issue recommendations to the network. For 189 example, an active stateful PCE may utilize the Delegation 190 mechanism to update LSP parameters in those PCCs that delegated 191 control over their LSPs to the PCE. 193 Delegation: An operation to grant a PCE temporary rights to modify a 194 subset of LSP parameters on one or more PCC's LSPs. LSPs are 195 delegated from a PCC to a PCE, and are referred to as delegated 196 LSPs. The PCC who owns the PCE state for the LSP has the right to 197 delegate it. An LSP is owned by a single PCC at any given point 198 in time. For intra-domain LSPs, this PCC SHOULD be the PCC of the 199 LSP head end. 201 Revocation: An operation performed by a PCC on a previously 202 delegated LSP. Revocation revokes the rights granted to the PCE 203 in the delegation operation. 205 Redelegation Timeout Interval: when a PCEP session is terminated, a 206 PCC waits for this time period before revoking LSP delegation to a 207 PCE and attempting to redelegate LSPs associated with the 208 terminated PCEP session to an alternate PCE. The Redelegation 209 Timeout Interval is a PCC-local value that can be either operator- 210 configured or dynamically computed by the PCC based on local 211 policy. 213 State Timeout Interval: when a PCEP session is terminated, a PCC 214 waits for this time period before flushing LSP state associated 215 with that PCEP session and reverting to operator-defined default 216 parameters. The State Timeout Interval is a PCC-local value that 217 can be either operator-configured or dynamically computed by the 218 PCC based on local policy. 220 LSP State Report: an operation to send LSP state (Operational / 221 Admin Status, LSP attributes configured and set by a PCE, etc.) 222 from a PCC to a PCE. 224 LSP Update Request: an operation where an Active Stateful PCE 225 requests a PCC to update one or more attributes of an LSP and to 226 re-signal the LSP with updated attributes. 228 LSP Priority: a specific pair of MPLS setup and hold priority values 229 as defined in [RFC3209]. 231 LSP State Database: information about all LSPs and their attributes. 233 Minimum Cut Set: the minimum set of links for a specific source 234 destination pair which, when removed from the network, result in a 235 specific source being completely isolated from specific 236 destination. The summed capacity of these links is equivalent to 237 the maximum capacity from the source to the destination by the 238 max-flow min-cut theorem. 240 Within this document, PCE-PCE communications are described by having 241 the requesting PCE fill the role of a PCC. This provides a saving in 242 documentation without loss of function. 244 The message formats in this document are specified using Routing 245 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 247 3. Motivation and Objectives for Stateful PCE 249 3.1. Motivation 251 [I-D.ietf-pce-stateful-pce-app] presents several use cases, 252 demonstrating scenarios that benefit from the deployment of a 253 stateful PCE. The scenarios apply equally to MPLS-TE and GMPLS 254 deployments. 256 3.1.1. Background 258 Traffic engineering has been a goal of the MPLS architecture since 259 its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic 260 engineering system provided by [RFC3630], [RFC5305], and [RFC3209] 261 information about network resources utilization is only available as 262 total reserved capacity by traffic class on a per interface basis; 263 individual LSP state is available only locally on each LER for its 264 own LSPs. In most cases, this makes good sense, as distribution and 265 retention of total LSP state for all LERs within in the network would 266 be prohibitively costly. 268 Unfortunately, this visibility in terms of global LSP state may 269 result in a number of issues for some demand patterns, particularly 270 within a common setup and hold priority. This issue affects online 271 traffic engineering systems. 273 A sufficiently over-provisioned system will by definition have no 274 issues routing its demand on the shortest path. However, lowering 275 the degree to which network over-provisioning is required in order to 276 run a healthy, functioning network is a clear and explicit promise of 277 MPLS architecture. In particular, it has been a goal of MPLS to 278 provide mechanisms to alleviate congestion scenarios in which 279 "traffic streams are inefficiently mapped onto available resources; 280 causing subsets of network resources to become over-utilized while 281 others remain underutilized" ([RFC2702]). 283 3.1.2. Why a Stateful PCE? 285 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 286 "strict synchronization between the PCE and not only the network 287 states (in term of topology and resource information), but also the 288 set of computed paths and reserved resources in use in the network." 289 [RFC4655] also expressed a number of concerns with regard to a 290 stateful PCE, specifically: 292 o Any reliable synchronization mechanism would result in significant 293 control plane overhead 295 o Out-of-band TED synchronization would be complex and prone to race 296 conditions 298 o Path calculations incorporating total network state would be 299 highly complex 301 In general, stress on the control plane will be directly proportional 302 to the size of the system being controlled and the tightness of the 303 control loop, and indirectly proportional to the amount of over- 304 provisioning in terms of both network capacity and reservation 305 overhead. 307 Despite these concerns in terms of implementation complexity and 308 scalability, several TE algorithms exist today that have been 309 demonstrated to be extremely effective in large TE systems, providing 310 both rapid convergence and significant benefits in terms of 311 optimality of resource usage [MXMN-TE]. All of these systems share 312 at least two common characteristics: the requirement for both global 313 visibility of a flow (or in this case, a TE LSP) state and for 314 ordered control of path reservations across devices within the system 315 being controlled. While some approaches have been suggested in order 316 to remove the requirements for ordered control (See [MPLS-PC]), these 317 approaches are highly dependent on traffic distribution, and do not 318 allow for multiple simultaneous LSP priorities representing diffserv 319 classes. 321 The use cases described in [I-D.ietf-pce-stateful-pce-app] 322 demonstrate a need for visibility into global inter-PCC LSP state in 323 PCE path computations, and for PCE control of sequence and timing in 324 altering LSP path characteristics within and across PCEP sessions. 326 3.1.3. Protocol vs. Configuration 328 Note that existing configuration tools and protocols can be used to 329 set LSP state. However, this solution has several shortcomings: 331 o Scale & Performance: configuration operations often require 332 processing of additional configuration portions beyond the state 333 being directly acted upon, with corresponding cost in CPU cycles, 334 negatively impacting both PCC stability LSP update rate capacity. 336 o Scale & Performance: configuration operations often have 337 transactional semantics which are typically heavyweight and 338 require additional CPU cycles, negatively impacting PCC update 339 rate capacity. 341 o Security: opening up a configuration channel to a PCE would allow 342 a malicious PCE to take over a PCC. The PCEP extensions described 343 in this document only allow a PCE control over a very limited set 344 of LSP attributes. 346 o Interoperability: each vendor has a proprietary information model 347 for configuring LSP state, which prevents interoperability of a 348 PCE with PCCs from different vendors. The PCEP extensions 349 described in this document allow for a common information model 350 for LSP state for all vendors. 352 o Efficient State Synchronization: configuration channels may be 353 heavyweight and unidirectional, therefore efficient state 354 synchronization between a PCE and a PCE may be a problem. 356 3.2. Objectives 358 The objectives for the protocol extensions to support stateful PCE 359 described in this document are as follows: 361 o Allow a single PCC to interact with a mix of stateless and 362 stateful PCEs simultaneously using the same PCEP. 364 o Support efficient LSP state synchronization between the PCC and 365 one or more active or passive stateful PCEs. 367 o Allow a PCC to delegate control of its LSPs to an active stateful 368 PCE such that a single LSP is under the control a single PCE at 369 any given time. A PCC may revoke this delegation at any time 370 during the lifetime of the LSP. If LSP delegation is revoked 371 while the PCEP session is up, the PCC MUST notify the PCE about 372 the revocation. A PCE may return an LSP delegation at any point 373 during the lifetime of the PCEP session. 375 o Allow a PCE to control computation timing and update timing across 376 all LSPs that have been delegated to it. 378 o Enable uninterrupted operation of PCC's LSPs in the event of a PCE 379 failure or while control of LSPs is being transferred between 380 PCEs. 382 4. New Functions to Support Stateful PCEs 384 Several new functions are required in PCEP to support stateful PCEs. 385 A function can be initiated either from a PCC towards a PCE (C-E) or 386 from a PCE towards a PCC (E-C). The new functions are: 388 Capability negotiation (E-C,C-E): both the PCC and the PCE must 389 announce during PCEP session establishment that they support PCEP 390 Stateful PCE extensions defined in this document. 392 LSP state synchronization (C-E): after the session between the PCC 393 and a stateful PCE is initialized, the PCE must learn the state of 394 a PCC's LSPs before it can perform path computations or update LSP 395 attributes in a PCC. 397 LSP Update Request (E-C): A PCE requests modification of attributes 398 on a PCC's LSP. 400 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 401 whenever the state of an LSP changes. 403 LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 404 update LSP attributes on one or more LSPs; the PCE becomes the 405 authoritative source of the LSP's attributes as long as the 406 delegation is in effect (See Section 5.5); the PCC may withdraw 407 the delegation or the PCE may give up the delegation at any time. 409 [I-D.sivabalan-pce-disco-stateful] defines the extensions needed to 410 support autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or 411 IS-IS ([RFC5089]) for PCE discovery. 413 5. Architectural Overview of Protocol Extensions 415 5.1. LSP State Ownership 417 In the PCEP protocol (defined in [RFC5440]), LSP state and operation 418 are under the control of a PCC (a PCC may be an LSR or a management 419 station). Attributes received from a PCE are subject to PCC's local 420 policy. The PCEP protocol extensions described in this document do 421 not change this behavior. 423 An active stateful PCE may have control of a PCC's LSPs be delegated 424 to it, but the LSP state ownership is retained by the PCC. In 425 particular, in addition to specifying values for LSP's attributes, an 426 active stateful PCE also decides when to make LSP modifications. 428 Retaining LSP state ownership on the PCC allows for: 430 o a PCC to interact with both stateless and stateful PCEs at the 431 same time 433 o a stateful PCE to only modify a small subset of LSP parameters, 434 i.e. to set only a small subset of the overall LSP state; other 435 parameters may be set by the operator through command line 436 interface (CLI) commands 438 o a PCC to revert delegated LSP to an operator-defined default or to 439 delegate the LSPs to a different PCE, if the PCC get disconnected 440 from a PCE with currently delegated LSPs 442 5.2. New Messages 444 In this document, we define the following new PCEP messages: 446 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 447 to a PCE to report the status of one or more LSPs. Each LSP 448 Status Report in a PCRpt message can contain the actual LSP's 449 path,bandwidth, operational and administrative status, etc. An 450 LSP Status Report carried on a PCRpt message is also used in 451 delegation or revocation of control of an LSP to/from a PCE. The 452 PCRpt message is described in Section 6.1. 454 Path Computation Update Request (PCUpd): a PCEP message sent by a 455 PCE to a PCC to update LSP parameters, on one or more LSPs. Each 456 LSP Update Request on a PCUpd message MUST contain all LSP 457 parameters that a PCE wishes to set for a given LSP. An LSP 458 Update Request carried on a PCUpd message is also used to return 459 LSP delegations if at any point PCE no longer desires control of 460 an LSP. The PCUpd message is described in Section 6.2. 462 The new functions defined in Section 4 are mapped onto the new 463 messages as shown in the following table. 465 +----------------------------------------+--------------------------+ 466 | Function | Message | 467 +----------------------------------------+--------------------------+ 468 | Capability Negotiation (E-C,C-E) | Open | 469 | State Synchronization (C-E) | PCRpt | 470 | LSP State Report (C-E) | PCRpt | 471 | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | 472 | LSP Update Request (E-C) | PCUpd | 473 | ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS | 474 | | sub-TLV | 475 | OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, | 476 | | PCE-CAP-FLAGS sub-TLV | 477 +----------------------------------------+--------------------------+ 478 Table 1: New Function to Message Mapping 480 5.3. Capability Negotiation 482 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 483 negotiate the use of stateful PCEP extensions. A PCEP Speaker 484 includes the "Stateful PCE Capability" TLV, described in 485 Section 7.1.1, in the OPEN Object to advertise its support for PCEP 486 stateful extensions. The Stateful Capability TLV includes the 'LSP 487 Update' Flag that indicates whether the PCEP Speaker supports LSP 488 parameter updates. 490 The presence of the Stateful PCE Capability TLV in PCC's OPEN Object 491 indicates that the PCC is willing to send LSP State Reports whenever 492 LSP parameters or operational status changes. 494 The presence of the Stateful PCE Capability TLV in PCE's OPEN message 495 indicates that the PCE is interested in receiving LSP State Reports 496 whenever LSP parameters or operational status changes. 498 The PCEP protocol extensions for stateful PCEs MUST NOT be used if 499 one or both PCEP Speakers have not included the Stateful PCE 500 Capability TLV in their respective OPEN message. If the PCEP 501 Speakers support the extensions of this draft but did not negotiate 502 this capability, then a PCErr with code "Stateful PCE capability not 503 negotiated" (see Section 8.4) will be generated and the PCEP session 504 will be terminated. 506 LSP delegation and LSP update operations defined in this document MAY 507 only be used if both PCEP Speakers set the LSP-UPDATE Flag in the 508 "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this 509 is not the case and LSP delegation or LSP update operations are 510 attempted, then a PCErr with code "Delegation not negotiated" (see 511 Section 8.4) SHOULD be generated. Note that even if the update 512 capability has not been negotiated, a PCE can still receive LSP 513 Status Reports from a PCC and build and maintain an up to date view 514 of the state of the PCC's LSPs. 516 5.4. State Synchronization 518 The purpose of State Synchronization is to provide a checkpoint-in- 519 time state replica of a PCC's LSP state in a PCE. State 520 Synchronization is performed immediately after the Initialization 521 phase ([RFC5440]). 523 During State Synchronization, a PCC first takes a snapshot of the 524 state of its LSPs state, then sends the snapshot to a PCE in a 525 sequence of LSP State Reports. Each LSP State Report sent during 526 State Synchronization has the SYNC Flag in the LSP Object set to 1. 527 The set of LSPs for which state is synchronized with a PCE is 528 determined by negotiated stateful PCEP capabilities and PCC's local 529 configuration (see more details in Section 9.1). 531 The end of synchronization marker is a PCRpt message with the SYNC 532 Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved 533 value 0. The LSP Object does not include the SYMBOLIC-PATH-NAME TLV 534 in this case. If both PCEP speakers had set the INCLUDE-DB-VERSION 535 Flag in the OPEN object's STATEFUL-PCE-CAPABILITY TLV, then the LSP- 536 DB-VERSION TLV MUST be included and contain the PCC's latest LSP 537 State Database version. If the PCC has no state to synchronize, it 538 will only send the end of synchronization marker. 540 A PCE SHOULD NOT send PCUpd messages to a PCC before State 541 Synchronization is complete. A PCC SHOULD NOT send PCReq messages to 542 a PCE before State Synchronization is complete. This is to allow the 543 PCE to get the best possible view of the network before it starts 544 computing new paths. 546 If the PCC encounters a problem which prevents it from completing the 547 state transfer, it MUST send a PCErr message to the PCE and terminate 548 the session using the PCEP session termination procedure. 550 In the event of a PCC resetting the session during synchronization, 551 the PCE MUST clean up state it received from this PCC. Session 552 reestablishment MUST be re-attempted per the procedures defined in 553 [RFC5440]. 555 The PCE does not send positive acknowledgements for properly received 556 synchronization messages. It MUST respond with a PCErr message 557 indicating "PCRpt error" (see Section 8.4) if it encounters a problem 558 with the LSP State Report it received from the PCC. Either the PCE 559 or the PCC MAY terminate the session if the PCE encounters a problem 560 during the synchronization. 562 The successful State Synchronization sequence is shown in Figure 1. 564 +-+-+ +-+-+ 565 |PCC| |PCE| 566 +-+-+ +-+-+ 567 | | 568 |-----PCRpt, SYNC=1----->| (Sync start) 569 | | 570 |-----PCRpt, SYNC=1----->| 571 | . | 572 | . | 573 | . | 574 |-----PCRpt, SYNC=1----->| 575 | . | 576 | . | 577 | . | 578 | | 579 |-----PCRpt, SYNC=0----->| (End of sync marker 580 | | LSP State Report 581 | | for PLSP-ID=0) 582 | | (Sync done) 584 Figure 1: Successful state synchronization 586 The sequence where the PCE fails during the State Synchronization 587 phase is shown in Figure 2. 589 +-+-+ +-+-+ 590 |PCC| |PCE| 591 +-+-+ +-+-+ 592 | | 593 |-----PCRpt, SYNC=1----->| 594 | | 595 |-----PCRpt, SYNC=1----->| 596 | . | 597 | . | 598 | . | 599 |-----PCRpt, SYNC=1----->| 600 | | 601 |-PCRpt, SYNC=1 | 602 | \ ,-PCErr=?-| 603 | \ / | 604 | \/ | 605 | /\ | 606 | / `-------->| (Ignored) 607 |<--------` | 609 Figure 2: Failed state synchronization (PCE failure) 611 The sequence where the PCC fails during the State Synchronization 612 phase is shown in Figure 3. 614 +-+-+ +-+-+ 615 |PCC| |PCE| 616 +-+-+ +-+-+ 617 | | 618 |-----PCRpt, SYNC=1----->| 619 | | 620 |-----PCRpt, SYNC=1----->| 621 | . | 622 | . | 623 | . | 624 |-------- PCErr=? ------>| 625 | | 627 Figure 3: Failed state synchronization (PCC failure) 629 5.4.1. State Synchronization Avoidance 631 State Synchronization MAY be skipped following a PCEP session restart 632 if the state of both PCEP peers did not change during the period 633 prior to session re-initialization. To be able to make this 634 determination, state must be exchanged and maintained by both PCE and 635 PCC during normal operation. This is accomplished by keeping track 636 of the changes to the LSP State Database, using a database version 637 called the LSP State Database Version. 639 The LSP State Database version is an unsigned 64-bit value that MUST 640 be incremented by 1 for each successive change in the LSP state 641 database. The LSP State Database version MUST start at 1 and may 642 wrap around. Values 0 and 0xFFFFFFFFFFFFFFFF are reserved. The PCC 643 is the owner of the LSP State Database version, which is incremented 644 each time a change is made to the PCC's local LSP State Database. 645 Operations that trigger a change to the local LSP State database 646 include a change in the LSP operational state, delegation of an LSP, 647 removal or addition of an LSP or change in any of the LSP attributes 648 that would trigger a report to the PCE. When State Synchronization 649 avoidance is enabled on a PCEP session, a PCC includes the LSP-DB- 650 VERSION TLV in the LSP Object on each LSP State Report. The LSP-DB- 651 VERSION TLV contains a PCC's LSP State Database version. 653 State Synchronization Avoidance is negotiated on a PCEP session 654 during session startup using the INCLUDE-DB-VERSION (IDB) bit in the 655 capabilities TLV. To ensure that a PCEP peer can recognize a 656 previously connected peer even if its IP address changed, each PCEP 657 peer includes the PREDUNDANCY-GROUP-ID TLV in the OPEN message. 659 If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN 660 object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the 661 LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the 662 PCC's latest LSP State Database version. 664 If a PCE's LSP State Database survived the restart of a PCEP session, 665 the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and 666 the TLV will contain the last LSP State Database version received on 667 an LSP State Report from the PCC in a previous PCEP session. If a 668 PCC's LSP State Database survived the restart of a PCEP session, the 669 PCC will include the LSP-DB-VERSION TLV in its OPEN object and the 670 TLV will contain the latest LSP State Database version sent on an LSP 671 State Report from the PCC in the previous PCEP session. If a PCEP 672 Speaker's LSP State Database did not survive the restart of a PCEP 673 session, the PCEP Speaker MUST NOT include the LSP-DB-VERSION TLV in 674 the OPEN Object. 676 If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN 677 Object and the TLV values match, the PCC MAY skip State 678 Synchronization. Otherwise, the PCC MUST perform State 679 Synchronization. If the PCC attempts to skip State Synchronization 680 (i.e. the SYNC Flag = 0 on the first LSP State Report from the PCC), 681 the PCE MUST send back a PCError with Error-type 20 Error-value 2 682 'LSP Database version mismatch', and close the PCEP session. 684 If state synchronization is required, then prior to completing the 685 Initialization phase, the PCE MUST mark any LSPs in the LSP database 686 that were previously reported by the PCC as stale. When the PCC 687 reports an LSP during state synchronization, if the LSP already 688 exists in the LSP database, the PCE MUST update the LSP database and 689 clear the stale marker from the LSP. When it has finished state 690 synchronization, the PCC MUST immediately send a PCRpt message 691 containing a state report with an LSP object containing an PLSP-ID of 692 0 and with the SYNC flag set to 0 (see Section 5.4). This state 693 report indicates to the PCE that state synchronization has completed. 694 On receiving this state report, the PCE MUST purge any LSPs from the 695 LSP database that are still marked as stale. 697 Note that a PCE/PCC MAY force State Synchronization by not including 698 the LSP-DB-VERSION TLV in its OPEN object. 700 Figure 4 shows an example sequence where State Synchronization is 701 skipped. 703 +-+-+ +-+-+ 704 |PCC| |PCE| 705 +-+-+ +-+-+ 706 | | 707 |--Open--, | 708 | DBv=42 \ ,---Open--| 709 | IDB=1 \ / DBv=42 | 710 | \/ IDB=1 | 711 | /\ | 712 | / `-------->| (OK to skip sync) 713 (Skip sync) |<--------` | 714 | . | 715 | . | 716 | . | 717 | | 718 |--PCRpt,DBv=43,SYNC=0-->| (Regular 719 | | LSP State Report) 720 |--PCRpt,DBv=44,SYNC=0-->| (Regular 721 | | LSP State Report) 722 |--PCRpt,DBv=45,SYNC=0-->| 723 | | 725 Figure 4: State Synchronization skipped 727 Figure 5 shows an example sequence where State Synchronization is 728 performed due to LSP State Database version mismatch during the PCEP 729 session setup. Note that the same State Synchronization sequence 730 would happen if either the PCC or the PCE would not include the LSP- 731 DB-VERSION TLV in their respective Open messages. 733 +-+-+ +-+-+ 734 |PCC| |PCE| 735 +-+-+ +-+-+ 736 | | 737 |--Open--, | 738 | DBv=46 \ ,---Open--| 739 | IDB=1 \ / DBv=42 | 740 | \/ IDB=1 | 741 | /\ | 742 | / `-------->| (Expect sync) 743 (Do sync) |<--------` | 744 | | 745 |--PCRpt,DBv=46,SYNC=1-->| (Sync start) 746 | . | 747 | . | 748 | . | 749 |--PCRpt,DBv=46,SYNC=1-->| (Sync done) 750 | . |(Purge LSP State) 751 | . | 752 | . | 753 |--PCRpt,DBv=47,SYNC=0-->| (Regular 754 | | LSP State Report) 755 |--PCRpt,DBv=48,SYNC=0-->| (Regular 756 | | LSP State Report) 757 |--PCRpt,DBv=49,SYNC=0-->| 758 | | 760 Figure 5: State Synchronization performed 762 Figure 6 shows an example sequence where State Synchronization is 763 skipped, but because one or both PCEP Speakers set the INCLUDE-DB- 764 VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the 765 PCE. If the current PCEP session restarts, the PCEP Speakers will 766 have to perform State Synchronization, since the PCE will not know 767 the PCC's latest LSP State Database version. 769 +-+-+ +-+-+ 770 |PCC| |PCE| 771 +-+-+ +-+-+ 772 | | 773 |--Open--, | 774 | DBv=42 \ ,---Open--| 775 | IDB=0 \ / DBv=42 | 776 | \/ IDB=0 | 777 | /\ | 778 | / `-------->| (OK to skip sync) 779 (Skip sync) |<--------` | 780 | . | 781 | . | 782 | . | 783 |------PCRpt,SYNC=0----->| (Regular 784 | | LSP State Report) 785 |------PCRpt,SYNC=0----->| (Regular 786 | | LSP State Report) 787 |------PCRpt,SYNC=0----->| 788 | | 790 Figure 6: State Synchronization skipped, no LSP-DB-VERSION TLVs sent 791 from PCC 793 5.4.2. PCE-triggered State Synchronization 795 Because the accuracy of the computations performed by the PCE is tied 796 to the accuracy of the view the PCE has on the state of the LSPs, it 797 can be beneficial to be able to resynchronize this state even after 798 the session has established. The PCE may use this approach to 799 continuously sanity check its state against the network, or to 800 recover from error conditions without having to tear down sessions. 802 To trigger a resynchronization with a PCC, the PCE MUST first mark 803 any LSPs in the LSP database that were previously reported by the PCC 804 as stale and then send a PCUpd for an LSP object containing a PLSP-ID 805 of 0 and with the SYNC flag set to 1. This PCUpd message is the 806 trigger for the PCC to enter the synchronization phase as described 807 in Section 5.4.1 and start sending PCRpt messages. After the receipt 808 of the end-of-synchronization marker, the PCE will purge LSPs which 809 were not refreshed. 811 5.5. LSP Delegation 813 If during Capability negotiation both the PCE and the PCC have 814 indicated that they support LSP Update, then the PCC may choose to 815 grant the PCE a temporary right to update (a subset of) LSP 816 attributes on one or more LSPs. This is called "LSP Delegation", and 817 it MAY be performed at any time after the Initialization phase, 818 including during the State Synchronization phase. 820 LSP Delegation is controlled by operator-defined policies on a PCC. 821 LSPs are delegated individually - different LSPs may be delegated to 822 different PCEs. An LSP is delegated to at most one PCE at any given 823 point in time. The delegation policy, when all PCC's LSPs are 824 delegated to a single PCE at any given time, SHOULD be supported by 825 all delegation-capable PCCs. Conversely, the policy revoking the 826 delegation for all PCC's LSPs SHOULD also be supported 828 A PCE may return LSP delegation at any time if it no longer wishes to 829 update the LSP's state. A PCC may revoke LSP delegation at any time. 830 Delegation, Revocation, and Return are done individually for each 831 LSP. 833 In the event of an delegation being rejected or returned by a PCE, 834 the PCC should react based on local policy. It can, for example, 835 either retry delegating to the same PCE using an exponentially 836 increasing timer or delegate to an alternate PCE. 838 5.5.1. Delegating an LSP 840 A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP 841 State Report to 1. If the PCE does not accept the LSP Delegation, it 842 MUST immediately respond with an empty LSP Update Request which has 843 the Delegate flag set to 0. If the PCE accepts the LSP Delegation, 844 it confirms this when it sends the first LSP Update Request for the 845 delegated LSP to the PCC by setting the Delegate flag to 1 (note that 846 this may occur at a later time). 848 The delegation sequence is shown in Figure 7. 850 +-+-+ +-+-+ 851 |PCC| |PCE| 852 +-+-+ +-+-+ 853 | | 854 |---PCRpt, Delegate=1--->| LSP Delegated 855 | | 856 |---PCRpt, Delegate=1--->| 857 | . | 858 | . | 859 | . | 860 |<--(PCUpd,Delegate=1)---| Delegation confirmed 861 | | 862 |---PCRpt, Delegate=1--->| 863 | | 864 Figure 7: Delegating an LSP 866 Note that for an LSP to remain delegated to a PCE, the PCC MUST set 867 the Delegate flag to 1 on each LSP Status Report sent to the PCE. 869 5.5.2. Revoking a Delegation 871 When a PCC decides that a PCE is no longer permitted to modify an 872 LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke 873 an LSP delegation at any time during the LSP's life time. A PCC 874 revoking an LSP delegation MAY immediately clear the LSP state 875 provided by the PCE, but to avoid traffic loss, it SHOULD do so in a 876 make-before-break fashion. If the PCC has received but not yet acted 877 on PCUpd messages from the PCE for the LSP whose delegation is being 878 revoked, then it SHOULD ignore these PCUpd messages when processing 879 the message queue. All effects of all messages for which processing 880 started before the revocation took place MUST be allowed to complete 881 and the result MUST be given the same treatment as any LSP that had 882 been previously delegated to the PCE (e.g. the state MAY be 883 immediately cleared). Any further PCUpd messages from the PCE are 884 handled according to the PCUpd procedures described in this document. 886 If a PCEP session with the PCE to which the LSP is delegated exists 887 in the UP state during the revocation, the PCC MUST notify that PCE 888 by sending an LSP State Report with the Delegate flag set to 0, as 889 shown in Figure 8. 891 +-+-+ +-+-+ 892 |PCC| |PCE| 893 +-+-+ +-+-+ 894 | | 895 |---PCRpt, Delegate=1--->| 896 | | 897 |<--(PCUpd,Delegate=1)---| Delegation confirmed 898 | . | 899 | . | 900 | . | 901 |---PCRpt, Delegate=0--->| PCC revokes delegation 902 | | 904 Figure 8: Revoking a Delegation 906 After an LSP delegation has been revoked, a PCE can no longer update 907 LSP's parameters; an attempt to update parameters of a non-delegated 908 LSP will result in the PCC sending a PCErr message indicating "LSP is 909 not delegated" (see Section 8.4). 911 When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC 912 MUST wait the time interval specified in Redelegation Timeout 913 Interval before revoking LSP delegations to that PCE and attempting 914 to redelegate LSPs to an alternate PCE. If a PCEP session with the 915 original PCE can be reestablished before the Redelegation Timeout 916 Interval timer expires, LSP delegations to the PCE remain intact. 918 Likewise, when a PCC's PCEP session with a PCE terminates 919 unexpectedly, the PCC MUST wait for the State Timeout Interval before 920 flushing any LSP state associated with that PCE. Note that the State 921 Timeout Interval timer may expire before the PCC has redelegated the 922 LSPs to another PCE, for example if a PCC is not connected to any 923 active stateful PCE or if no connected active stateful PCE accepts 924 the delegation. In this case, the PCC SHALL flush any LSP state set 925 by the PCE upon expiration of the State Timeout Interval and revert 926 to operator-defined default parameters. This operation SHOULD be 927 done in a make-before-break fashion. 929 The State Timeout Interval SHOULD be greater than or equal to the 930 Redelegation Timeout Interval and MAY be set to infinity (meaning 931 that until the PCC specifically takes action to change the parameters 932 set by the PCE, they will remain intact). 934 If State Synchronization Avoidance is enabled, a PCC MUST increment 935 its LSP State Database version when the 'Redelegation Timeout 936 Interval' timer expires. 938 5.5.3. Returning a Delegation 940 A PCE that no longer wishes to update an LSP's parameters SHOULD 941 return the LSP delegation back to the PCC by sending an empty LSP 942 Update Request which has the Delegate flag set to 0. Note that in 943 order to keep a delegation, the PCE MUST set the Delegate flag to 1 944 on each LSP Update Request sent to the PCC. 946 +-+-+ +-+-+ 947 |PCC| |PCE| 948 +-+-+ +-+-+ 949 | | 950 |---PCRpt, Delegate=1--->| LSP delegated 951 | . | 952 | . | 953 | . | 954 |<--PCUpd, Delegate=0----| Delegation returned 955 | | 956 |---PCRpt, Delegate=0--->| No delegation for LSP 957 | | 959 Figure 9: Returning a Delegation 961 If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is 962 not connected to any active stateful PCE or if no connected active 963 stateful PCE accepts the delegation), the LSP delegation on the PCC 964 will time out within a configurable Redelegation Timeout Interval and 965 the PCC MUST flush any LSP state set by a PCE at the expiration of 966 the State Timeout Interval. 968 5.5.4. Redundant Stateful PCEs 970 Note that a PCE may not have any delegated LSPs: in a redundant 971 configuration where one PCE is backing up another PCE, the backup PCE 972 may have a subset of the LSPs in the network delegated to it. The 973 backup PCE does not update any LSPs that are not delegated to it. In 974 order to allow the backup to operate in a hot-standby mode and avoid 975 the need for state synchronization in case the primary fails, the 976 backup receives all LSP State Reports from a PCC. When the primary 977 PCE for a given LSP set fails, after expiry of the Redelegation 978 Timeout Interval, the PCC SHOULD delegate to the redundant PCE all 979 LSPs that had been previously delegated to the failed PCE. Assuming 980 that the State Timeout Interval had been configured to be larger than 981 the Redelegation Timeout Interval (as recommended), this delegation 982 change will not cause any changes to the LSP parameters. 984 5.5.5. Redelegation on PCE Failure 986 On failure, the goal is to: 1) avoid any traffic loss on the LSPs 987 that were updated by the PCE that crashed 2) minimize the churn in 988 the network in terms of ownership of the LSPs, 3) not leave any 989 "orphan" (undelegated) LSPs and 4) be able to control when the state 990 that was set by the PCE can be changed or purged. The values chosen 991 for the Redelegation Timeout and State Timeout values affect the 992 ability to accomplish these goals. 994 This section summarizes the behaviour with regards to LSP delegation 995 and LSP state on a PCE failure. 997 If the PCE crashes but recovers within the Redelegation Timeout, both 998 the delegation state and the LSP state are kept intact. 1000 If the PCE crashes but does not recover within the Redelegation 1001 Timeout, the delegation state is returned to the PCC. If the PCC can 1002 redelegate the LSPs to another PCE, and that PCE accepts the 1003 delegations, there will be no change in LSP state. If the PCC cannot 1004 redelegate the LSPs to another PCE, then upon expiration of the State 1005 Timeout Interval, the state set by the PCE is flushed, which may 1006 cause change in the LSP state. Note that an operator may choose to 1007 use an infinite State Timeout Interval if he wishes to maintain the 1008 PCE state indefinetely. Note also that flushing the state should be 1009 implemented using make-before-break to avoid traffic loss. 1011 If there is a standby PCE, the Redelegation Timeout may be set to 0 1012 through policy on the PCC, causing the LSPs to be redelegated 1013 immediately to the PCC, which can delegate them immediately to the 1014 standby PCE. Assuming the State Timeout Interval is larger than the 1015 Redelegation Timeout, the LSP state will be kept intact. 1017 5.6. LSP Operations 1019 5.6.1. Passive Stateful PCE Path Computation Request/Response 1021 +-+-+ +-+-+ 1022 |PCC| |PCE| 1023 +-+-+ +-+-+ 1024 | | 1025 1) Path computation |----- PCReq message --->| 1026 request sent to | |2) Path computation 1027 PCE | | request received, 1028 | | path computed 1029 | | 1030 |<---- PCRep message ----|3) Computed paths 1031 | (Positive reply) | sent to the PCC 1032 | (Negative reply) | 1033 4) LSP Status change| | 1034 event | | 1035 | | 1036 5) LSP Status Report|----- PCRpt message --->| 1037 sent to all | . | 1038 stateful PCEs | . | 1039 | . | 1040 6) Repeat for each |----- PCRpt message --->| 1041 LSP status change| | 1042 | | 1044 Figure 10: Passive Stateful PCE Path Computation Request/Response 1046 Once a PCC has successfully established a PCEP session with a passive 1047 stateful PCE and the PCC's LSP state is synchronized with the PCE 1048 (i.e. the PCE knows about all PCC's existing LSPs), if an event is 1049 triggered that requires the computation of a set of paths, the PCC 1050 sends a path computation request to the PCE ([RFC5440], Section 1051 4.2.3). The PCReq message MAY contain the LSP Object to identify the 1052 LSP for which the path computation is requested. 1054 Upon receiving a path computation request from a PCC, the PCE 1055 triggers a path computation and returns either a positive or a 1056 negative reply to the PCC ([RFC5440], Section 4.2.4). 1058 Upon receiving a positive path computation reply, the PCC receives a 1059 set of computed paths and starts to setup the LSPs. For each LSP, it 1060 sends an LSP State Report carried on a PCRpt message to the PCE, 1061 indicating that the LSP's status is 'Pending'. 1063 Once an LSP is up, the PCC sends an LSP State Report carried on a 1064 PCRpt message to the PCE, indicating that the LSP's status is 'Up'. 1065 If the LSP could not be set up, the PCC sends an LSP State Report 1066 indicating that the LSP is "Down' and stating the cause of the 1067 failure. Note that due to timing constraints, the LSP status may 1068 change from 'Pending' to 'Up' (or 'Down') before the PCC has had a 1069 chance to send an LSP State Report indicating that the status is 1070 'Pending'. In such cases, the PCC may choose to only send the PCRpt 1071 indicating the latest status ('Up' or 'Down'). 1073 Upon receiving a negative reply from a PCE, a PCC may decide to 1074 resend a modified request or take any other appropriate action. For 1075 each requested LSP, it also sends an LSP State Report carried on a 1076 PCRpt message to the PCE, indicating that the LSP's status is 'Down'. 1078 There is no direct correlation between PCRep and PCRpt messages. For 1079 a given LSP, multiple LSP State Reports will follow a single PCRep 1080 message, as a PCC notifies a PCE of the LSP's state changes. 1082 A PCC sends each LSP State Report to each stateful PCE that is 1083 connected to the PCC. 1085 Note that a single PCRpt message MAY contain multiple LSP State 1086 Reports. 1088 The passive stateful PCE is the model for stateful PCEs is described 1089 in [RFC4655], Section 6.8. 1091 5.6.2. Active Stateful PCE LSP Update 1093 +-+-+ +-+-+ 1094 |PCC| |PCE| 1095 +-+-+ +-+-+ 1096 | | 1097 1) LSP State |-- PCRpt, Delegate=1 -->| 1098 Synchronization | . | 1099 or add new LSP | . |2) PCE decides to 1100 | . | update the LSP 1101 | | 1102 |<---- PCUpd message ----|3) PCUpd message sent 1103 | | to PCC 1104 | | 1105 | | 1106 4) LSP Status Report|---- PCRpt message ---->| 1107 sent(->Pending) | . | 1108 | . | 1109 | . | 1110 5) LSP Status Report|---- PCRpt message ---->| 1111 sent (->Up|Down) | | 1112 | | 1114 Figure 11: Active Stateful PCE 1116 Once a PCC has successfully established a PCEP session with an active 1117 stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. 1118 the PCE knows about all PCC's existing LSPs) and LSPs have been 1119 delegated to the PCE, the PCE can modify LSP parameters of delegated 1120 LSPs. 1122 A PCE sends an LSP Update Request carried on a PCUpd message to the 1123 PCC. The LSP Update Request contains a variety of objects that 1124 specify the set of constraints and attributes for the LSP's path. 1125 Each LSP Update Request has a unique identifier, the SRP-ID-number, 1126 carried in the SRP (Stateful PCE Request Parameters) Object described 1127 in Section 7.2. The SRP-ID-number is used to correlate errors and 1128 state reports to LSP Update Requests. A single PCUpd message MAY 1129 contain multiple LSP Update Requests. 1131 Upon receiving a PCUpd message the PCC starts to setup LSPs specified 1132 in LSP Update Requests carried in the message. For each LSP, it 1133 sends an LSP State Report carried on a PCRpt message to the PCE, 1134 indicating that the LSP's status is 'Pending'. If the PCC decides 1135 that the LSP parameters proposed in the PCUpd message are 1136 unacceptable, it MUST report this error by including the LSP-ERROR- 1137 CODE TLV (Section 7.3.3) with LSP error value="Unacceptable 1138 parameters" in the LSP object in the PCRpt message to the PCE. Based 1139 on local policy, it MAY react further to this error by revoking the 1140 delegation. If the PCC receives a PCUpd message for an LSP object 1141 identified with a PLSP-ID that does not exist on the PCC, it MUST 1142 generate a PCErr with error type 19, error value 3, "Unknown PLSP-ID" 1143 (see Section 8.4). 1145 Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) 1146 to the PCE, indicating that the LSP's status is 'Up'. If the LSP 1147 could not be set up, the PCC sends an LSP State Report indicating 1148 that the LSP is 'Down' and stating the cause of the failure. A PCC 1149 may choose to compress LSP State Reports to only reflect the most up 1150 to date state, as discussed in the previous section. 1152 A PCC sends each LSP State Report to each stateful PCE that is 1153 connected to the PCC. 1155 PCErr and PCRpt messages triggered as a result of a PCUpd message 1156 MUST include the SRP-ID-number from the PCUpd. This provides 1157 correlation of requests and errors and acknowledgement of state 1158 processing. The PCC may choose to compress state when processing 1159 PCUpd. In this case, receipt of a higher SRP-ID-number implicitly 1160 acknowledges processing all the earlier updates for the specific LSP. 1162 A PCC MUST NOT send to any PCE a Path Computation Request for a 1163 delegated LSP. Should the PCC decide it wants to issue a Path 1164 Computation Request on a delegated LSP, it MUST perform Delegation 1165 Revocation procedure first. 1167 5.7. LSP Protection 1169 LSP protection and interaction with stateful PCE, as well as the 1170 extensions necessary to implement this functionality will be 1171 discussed in a separate draft. 1173 5.8. Transport 1175 A permanent PCEP session MUST be established between a stateful PCE 1176 and the PCC. In the case of session failure, session reestablishment 1177 MUST be re-attempted per the procedures defined in [RFC5440]. 1179 6. PCEP Messages 1181 As defined in [RFC5440], a PCEP message consists of a common header 1182 followed by a variable-length body made of a set of objects that can 1183 be either mandatory or optional. An object is said to be mandatory 1184 in a PCEP message when the object must be included for the message to 1185 be considered valid. For each PCEP message type, a set of rules is 1186 defined that specify the set of objects that the message can carry. 1187 An implementation MUST form the PCEP messages using the object 1188 ordering specified in this document. 1190 6.1. The PCRpt Message 1192 A Path Computation LSP State Report message (also referred to as 1193 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 1194 current state of an LSP. A PCRpt message can carry more than one LSP 1195 State Reports. A PCC can send an LSP State Report either in response 1196 to an LSP Update Request from a PCE, or asynchronously when the state 1197 of an LSP changes. The Message-Type field of the PCEP common header 1198 for the PCRpt message is set to [TBD]. 1200 The format of the PCRpt message is as follows: 1202 ::= 1203 1204 Where: 1206 ::= [] 1208 ::= 1209 1210 1211 Where: 1212 ::= 1214 Where: 1215 is defined in [RFC5440] and extended by PCEP extensions. 1217 The SRP object (see Section 7.2) is mandatory, and it MUST be 1218 included for each LSP State Report in the PCRpt message. The value 1219 of the SRP-ID-number in the SRP Object MUST be the same as that sent 1220 in the PCUpd message that triggered the state that is reported, or 1221 the reserved value 0x00000000 if the state is not as a result of 1222 processing a PCUpd message. If the PCC compressed several PCUpd 1223 messages for the same LSP by only processing the latest one, then it 1224 should use the SRP-ID-number of that request. If the SRP object is 1225 missing, the receiving PCE MUST send a PCErr message with Error- 1226 type=6 (Mandatory Object missing) and Error-value=[TBD] (SRP object 1227 missing). No state compression is allowed for state reporting. The 1228 PCC MUST explicitly report state changes (including removal) for 1229 paths it manages. 1231 The LSP object (see Section 7.3) is mandatory, and it MUST be 1232 included in each LSP State Report on the PCRpt message. If the LSP 1233 object is missing, the receiving PCE MUST send a PCErr message with 1234 Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP 1235 object missing). 1237 If the LSP transitioned to non-operational state, the PCC SHOULD 1238 include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error 1239 Code to report the error to the PCE. 1241 6.2. The PCUpd Message 1243 A Path Computation LSP Update Request message (also referred to as 1244 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 1245 attributes of an LSP. A PCUpd message can carry more than one LSP 1246 Update Request. The Message-Type field of the PCEP common header for 1247 the PCUpd message is set to [TBD]. 1249 The format of a PCUpd message is as follows: 1251 ::= 1252 1253 Where: 1255 ::= [] 1257 ::= 1258 1259 1260 Where: 1261 ::= 1263 Where: 1264 is defined in [RFC5440] and extended by PCEP extensions. 1266 There are three mandatory objects that MUST be included within each 1267 LSP Update Request in the PCUpd message: the SRP Object (see 1268 Section 7.2), the LSP object (see Section 7.3) and the ERO object (as 1269 defined in [RFC5440]. If the SRP object is missing, the receiving 1270 PCC MUST send a PCErr message with Error-type=6 (Mandatory Object 1271 missing) and Error-value=[TBD] (SRP object missing). If the LSP 1272 object is missing, the receiving PCC MUST send a PCErr message with 1273 Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP 1274 object missing). If the ERO object is missing, the receiving PCC 1275 MUST send a PCErr message with Error-type=6 (Mandatory Object 1276 missing) and Error-value=[TBD] (ERO object missing). 1278 A PCC only acts on an LSP Update Request if permitted by the local 1279 policy configured by the network manager. Each LSP Update Request 1280 that the PCC acts on results in an LSP setup operation. An LSP 1281 Update Request MUST contain all LSP parameters that a PCE wishes to 1282 set for the LSP. A PCC MAY set missing parameters from locally 1283 configured defaults. If the LSP specified in the Update Request is 1284 already up, it will be re-signaled. 1286 The PCC SHOULD minimize the traffic interruption, and MAY use the 1287 make-before-break procedures described in [RFC3209] in order to 1288 achieve this goal. If the make-before-break procedures are used, two 1289 paths will briefly co-exist. The PCC MUST send separate PCRpt 1290 messages for each, identified by the LSP-IDENTIFIERS TLV. When the 1291 old path is torn down after the head end switches over the traffic, 1292 this event MUST be reported by sending a PCRpt message with the LSP- 1293 IDENTIFIERS-TLV of the old path, and the R bit set. In this case, 1294 the SRP object will have an SRP-id of 0. Thus, a make-before-break 1295 operation will typically result in at least two PCRpt messages, one 1296 for the new path and one for the removal of the old path (more 1297 messages may be possible if intermediate states are reported). 1299 A PCC MUST respond with an LSP State Report to each LSP Update 1300 Request it processed to indicate the resulting state of the LSP in 1301 the network (even if this processing did not result in changing the 1302 state of the LSP). The SRP-ID-number included in the PCRpt MUST 1303 match that in the PCUpd. A PCC MAY respond with multiple LSP State 1304 Reports to report LSP setup progress of a single LSP. In that case, 1305 the SRP-ID-number MUST be included for the first message, for 1306 subsequent messages the reserved value 0x00000000 SHOULD be used. 1308 Note that a PCC MUST process all LSP Update Requests - for example, 1309 an LSP Update Request is sent when a PCE returns delegation or puts 1310 an LSP into non-operational state. The protocol relies on TCP for 1311 message-level flow control. 1313 If the rate of PCUpd messages sent to a PCC for the same target LSP 1314 exceeds the rate at which the PCC can signal LSPs into the network, 1315 the PCC MAY perform state compression and only signal the last 1316 modification in its queue, as the last PCUpd contains the most up-to- 1317 date desired state for the LSP. If two PCUpd arrive for the same LSP 1318 in quick succession and the PCC started the signaling of the changes 1319 relevant to the first PCUpd, then it MUST wait until the signaling 1320 finishes (and report the new state via a PCRpt) before attempting to 1321 apply the changes indicated in the second PCUpd. 1323 Note also that it is up to the PCE to handle inter-LSP dependencies; 1324 for example, if ordering of LSP set-ups is required, the PCE has to 1325 wait for an LSP State Report for a previous LSP before starting the 1326 update of the next LSP. If the PCUpd cannot be satisfied (for 1327 example due to unsupported object or TLV), the PCC MUST respond with 1328 a PCErr message indicating the failure (see Section 7.3.3). 1330 6.3. The PCErr Message 1332 If the stateful PCE capability has been negotiated on the PCEP 1333 session, the PCErr message MUST include the SRP object. If the error 1334 reported is the result of an LSP update request, then the SRP-ID- 1335 number MUST be the one from the PCUpd that triggered the error. If 1336 it is unsolicited, the SRP-ID-number MUST be the reserved value 1337 0x00000000. 1339 6.4. The PCReq Message 1341 A PCC MAY include the LSP object in the PCReq message (see 1342 Section 7.3) if the stateful PCE capability has been negotiated on a 1343 PCEP session between the PCC and a PCE. 1345 The definition of the PCReq message from [RFC5440] is extended to 1346 optionally include the LSP object after the END-POINTS object. The 1347 encoding from [RFC5440] will become: 1349 ::= 1350 [] 1351 1353 Where: 1355 ::=[] 1356 ::=[] 1358 ::= 1359 1360 [] <--- New Object 1361 [] 1362 [] 1363 [] 1364 [[]] 1365 [] 1366 [] 1368 6.5. The PCRep Message 1370 A PCE MAY include the LSP object in the PCRep message (see 1371 (Section 7.3) if the stateful PCE capability has been negotiated on a 1372 PCEP session between the PCC and the PCE and the LSP object was 1373 included in the corresponding PCReq message from the PCC. 1375 The definition of the PCRep message from [RFC5440] is extended to 1376 optionally include the LSP object after the RP object. The encoding 1377 from [RFC5440] will become: 1379 ::= 1380 1382 Where: 1384 ::=[] 1386 ::= 1387 [] <--- New Object 1388 [] 1389 [] 1390 [] 1392 7. Object Formats 1394 The PCEP objects defined in this document are compliant with the PCEP 1395 object format defined in [RFC5440]. The P flag and the I flag of the 1396 PCEP objects defined in this document MUST always be set to 0 on 1397 transmission and MUST be ignored on receipt since these flags are 1398 exclusively related to path computation requests. 1400 7.1. OPEN Object 1402 This document defines two new optional TLVs for use in the OPEN 1403 Object. 1405 7.1.1. Stateful PCE Capability TLV 1407 The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the 1408 OPEN Object for stateful PCE capability negotiation. Its format is 1409 shown in the following figure: 1411 0 1 2 3 1412 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 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | Type=[TBD] | Length=4 | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Flags |S|U| 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 Figure 12: STATEFUL-PCE-CAPABILITY TLV format 1421 The type of the TLV is [TBD] and it has a fixed length of 4 octets. 1423 The value comprises a single field - Flags (32 bits): 1425 U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag 1426 indicates that the PCC allows modification of LSP parameters; if 1427 set to 1 by a PCE, the U Flag indicates that the PCE is capable of 1428 updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be 1429 advertised by both a PCC and a PCE for PCUpd messages to be 1430 allowed on a PCEP session. 1432 S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers, 1433 the PCC will include the LSP-DB-VERSION TLV in each LSP Object. 1435 Unassigned bits are considered reserved. They MUST be set to 0 on 1436 transmission and MUST be ignored on receipt. 1438 Negotiation of the stateful PCE capability implies support of LSPs 1439 that are signaled via RSVP, as well as the objects, TLVs and 1440 procedures defined in this document. 1442 7.1.2. LSP State Database Version TLV 1444 LSP-DB-VERSION is an optional TLV that MAY be included in the OPEN 1445 Object when a PCEP Speaker wishes to determine if State 1446 Synchronization can be skipped when a PCEP session is restarted. If 1447 sent from a PCE, the TLV contains the local LSP State Database 1448 version from the last valid LSP State Report received from a PCC. If 1449 sent from a PCC, the TLV contains the PCC's local LSP State Database 1450 version, which is incremented each time the LSP State Database is 1451 updated. 1453 The format of the LSP-DB-VERSION TLV is shown in the following 1454 figure: 1456 0 1 2 3 1457 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 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Type=[TBD] | Length=8 | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | LSP State DB Version | 1462 | | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 Figure 13: LSP-DB-VERSION TLV format 1467 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 1468 The value contains a 64-bit unsigned integer. 1470 7.1.3. PCE Redundancy Group Identifier TLV 1472 PREDUNDANCY-GROUP-ID is an optional TLV that MAY be included in the 1473 OPEN Object when a PCEP Speaker wishes to determine if State 1474 Synchronization can be skipped when a PCEP session is restarted. It 1475 contains a unique identifier for the node that does not change during 1476 the life time of the PCEP Speaker. It identifies the PCEP Speaker to 1477 its peers if the Speaker's IP address changed. 1479 The format of the PREDUNDANCY-GROUP-ID TLV is shown in the following 1480 figure: 1482 0 1 2 3 1483 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 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | Type=[TBD] | Length (variable) | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | | 1488 // PCE redundancy group Identifier // 1489 | | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 Figure 14: PREDUNDANCY-GROUP-ID TLV format 1494 The type of the TLV is [TBD] and it has a a variable length, which 1495 MUST be greater than 0. The value contains a node identifier that 1496 MUST be unique in the network. The node identifier MAY be configured 1497 by an operator. If the node identifier is not configured by the 1498 operator, it can be derived from a PCC's MAC address or serial 1499 number. 1501 7.2. SRP Object 1503 The SRP (Stateful PCE Request Parameters) object MUST be carried 1504 within each PCUpd and PCRpt message and MAY be carried within PCNtf 1505 and PCErr messages. The SRP object is used to correlate between 1506 update requests sent by the PCE and the error reports and state 1507 reports sent by the PCC. 1509 SRP Object-Class is [TBD]. 1511 SRP Object-Type is 1. 1513 The format of the SRP object body is shown in Figure 15: 1515 0 1 2 3 1516 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 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Flags | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | SRP-ID-number | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | | 1523 // Optional TLVs // 1524 | | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 Figure 15: The SRP Object format 1529 The SRP object body has a variable length and may contain additional 1530 TLVs. The SYMBOLIC-PATH-NAME TLV MAY be included as one of the 1531 optional TLVs. 1533 Flags (32 bits): None defined yet. 1535 SRP-ID-number (32 bits): The SRP-ID-number value combined with the 1536 source IP address of the PCC and the PCE uniquely identify the 1537 operation that the PCE has requested the PCC to perform on a given 1538 LSP. The SRP-ID-number is incremented each time a new request is 1539 sent to the PCC, and may wrap around. 1541 The values 0x00000000 and 0xFFFFFFFF are reserved. 1543 Every request to update an LSP receives a new SRP-ID-number. This 1544 number is unique per PCEP session and is incremented each time an 1545 operation is requested from the PCE. Thus, for a given LSP there may 1546 be more than one SRP-id-number unacknowledged at a given time. The 1547 value of the SRP-ID-number is echoed back by the PCC in PCErr and 1548 PCRpt messages to allow for correlation between requests made by the 1549 PCE and errors or state reports generated by the PCC. If the error 1550 or report were not as a result of a PCE operation (for example in the 1551 case of a link down event), then the reserved value of 0x00000000 is 1552 used instead. An SRP-ID-number is considered unacknowledged and 1553 cannot be reused until a PCErr or PCRpt arrives with an SRP-ID-number 1554 equal or higher for the same LSP. A PCRpt with state "Pending" is 1555 not considered as an acknowledgement. 1557 7.3. LSP Object 1559 The LSP object MUST be present within PCRpt and PCUpd messages. The 1560 LSP object MAY be carried within PCReq and PCRep messages if the 1561 stateful PCE capability has been negotiated on the session. The LSP 1562 object contains a set of fields used to specify the target LSP, the 1563 operation to be performed on the LSP, and LSP Delegation. It also 1564 contains a flag indicating to a PCE that the LSP state 1565 synchronization is in progress. This document focuses on LSPs that 1566 are signaled with RSVP, many of the TLVs used with the LSP object 1567 mirror RSVP state. 1569 LSP Object-Class is [TBD]. 1571 LSP Object-Type is 1. 1573 The format of the LSP object body is shown in Figure 16: 1575 0 1 2 3 1576 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 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | PLSP-ID | Flags | O|A|R|S|D| 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Reserved | LSP-sig-type | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 // TLVs // 1583 | | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 Figure 16: The LSP Object format 1588 PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC 1589 creates a unique PLSP-ID for each LSP that is constant for the life 1590 time of a PCEP session. The mapping of the Symbolic Path Name to 1591 PLSP-ID is communicated to the PCE by sending a PCRpt message 1592 containing the SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages 1593 then address the LSP by the PLSP-ID. The values of 0 and 0xFFFFF are 1594 reserved. Note that the PLSP-ID is a value that is constant for the 1595 life time of the PCEP session, during which time for an RSVP-signaled 1596 LSP there might be a different RSVP identifiers (LSP-id, tunnel-id) 1597 allocated it. 1599 Flags (12 bits): 1601 D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1 1602 indicates that the PCC is delegating the LSP to the PCE. On a 1603 PCUpd message, the D flag set to 1 indicates that the PCE is 1604 confirming the LSP Delegation. To keep an LSP delegated to the 1605 PCE, the PCC must set the D flag to 1 on each PCRpt message for 1606 the duration of the delegation - the first PCRpt with the D flag 1607 set to 0 revokes the delegation. To keep the delegation, the PCE 1608 must set the D flag to 1 on each PCUpd message for the duration of 1609 the delegation - the first PCUpd with the D flag set to 0 returns 1610 the delegation. 1612 S (SYNC - 1 bit): the S Flag MUST be set to 1 on each PCRpt sent 1613 from a PCC during State Synchronization. The S Flag MUST be set 1614 to 0 in other PCRpt messages sent from the PCC. The S flag MAY be 1615 set to 1 in a PCUpd sent by the PCE (see section Section 5.4.2). 1617 R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1618 LSP has been removed from the PCC and the PCE SHOULD remove all 1619 state from its database. Upon receiving an LSP State Report with 1620 the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD 1621 remove all state for the path identified by the LSP Identifiers 1622 TLV from its database. When the all-zeros LSP-IDENTIFIERS-TLV is 1623 used, the PCE SHOULD remove all state for the PLSP-ID from its 1624 database. 1626 A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates 1627 the PCC's target operational status for this LSP. On PCUpd 1628 messages, the A Flag indicates the LSP status that the PCE desires 1629 for this LSP. In both cases, a value of '1' means that the 1630 desired operational state is active, and a value of '0' means that 1631 the desired operational state is inactive. A PCC ignores the A 1632 flag on a PCUpd message unless the operator's policy allows the 1633 PCE to control the corresponding LSP's administrative state. 1635 O(Operational - 3 bits): On PCRpt messages, the O Field represents 1636 the operational status of the LSP. 1638 The following values are defined: 1640 0 - DOWN: not active. 1642 1 - UP: signalled. 1644 2 - ACTIVE: up and carrying traffic. 1646 3 - GOING-DOWN: LSP is being torn down, resources are being 1647 released. 1649 4 - GOING-UP: LSP is being signalled. 1651 5-7 - Reserved: these values are reserved for future use. 1653 Unassigned bits are considered reserved. They MUST be set to 0 on 1654 transmission and MUST be ignored on receipt. 1656 LSP-sig-type (8 bits) - identifies the method used for signaling the 1657 LSP. If a PCEP speaker receives an LSP object with LSP-sig-type that 1658 had not been previously negotiated, a PCErr with error type 19, error 1659 value 5, "Unsupported LSP signaling type", (see Section 8.4) MUST be 1660 sent. If there is a mismatch in the LSP signaling type for a 1661 particular LSP between the PCEP speakers, a PCErr with error type 19, 1662 error value 4, "Mismatched LSP signaling type" (see Section 8.4) MUST 1663 be sent by the party identifying the mismatch. 1665 Optional TLVs that may be included in the LSP Object are described in 1666 the following sections. 1668 7.3.1. LSP Identifiers TLVs 1670 The LSP Identifiers TLV MUST be included in the LSP object in PCRpt 1671 messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will 1672 generate an error with error-type 6 (mandatory object missing) and 1673 Error Value 11 (LSP-IDENTIFIERS TLV missing) and close the session. 1674 The LSP Identifiers TLV MAY be included in the LSP object in PCUpd 1675 messages for RSVP-signaled LSPs. The special value of all zeros for 1676 this TLV is used to refer to all paths pertaining to a particular 1677 PLSP-ID. There are two LSP Identifiers TLVs, one for IPv4 and one 1678 for IPv6. 1680 It is the responsibility of the PCC to send to the PCE the 1681 identifiers for each RSVP incarnation of the tunnel. For exmple, in 1682 a make-before-break scenario, the PCC MUST send a separate PCRpt for 1683 the old and for the reoptimized paths, and explicitly report removal 1684 of any of these paths using the R bit in the LSP object. 1686 The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 1687 figure: 1689 0 1 2 3 1690 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 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Type=[TBD] | Length=12 | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | IPv4 Tunnel Sender Address | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | LSP ID | Tunnel ID | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Extended Tunnel ID | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 Figure 17: IPV4-LSP-IDENTIFIERS TLV format 1703 The type of the TLV is [TBD] and it has a fixed length of 12 octets. 1704 The value contains the following fields: 1706 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 1707 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 1708 Sender Template Object. 1710 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1711 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 1712 Object. 1714 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1715 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 1716 Tunnel ID remains constant over the life time of a tunnel. 1718 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 1719 identifier defined in [RFC3209], Section 4.6.1.1 for the 1720 LSP_TUNNEL_IPv4 Session Object. 1722 The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l following 1723 figure: 1725 0 1 2 3 1726 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 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Type=[TBD] | Length=36 | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | | 1731 + + 1732 | IPv6 tunnel sender address | 1733 + (16 octets) + 1734 | | 1735 + + 1736 | | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | LSP ID | Tunnel ID | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | | 1741 + + 1742 | Extended Tunnel ID | 1743 + (16 octets) + 1744 | | 1745 + + 1746 | | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 Figure 18: IPV6-LSP-IDENTIFIERS TLV format 1751 The type of the TLV is [TBD] and it has a fixed length of 36 octets. 1752 The value contains the following fields: 1754 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 1755 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 1756 Sender Template Object. 1758 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1759 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 1760 Object. 1762 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1763 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 1764 Tunnel ID remains constant over the life time of a tunnel. 1765 However, when Global Path Protection or Global Default Restoration 1766 is used, both the primary and secondary LSPs have their own Tunnel 1767 IDs. A PCC will report a change in Tunnel ID when traffic 1768 switches over from primary LSP to secondary LSP (or vice versa). 1770 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 1771 identifier defined in [RFC3209], Section 4.6.1.2 for the 1772 LSP_TUNNEL_IPv6 Session Object. 1774 7.3.2. Symbolic Path Name TLV 1776 Each LSP (path) MUST have a symbolic name that is unique in the PCC. 1777 This symbolic path name MUST remain constant throughout a path's 1778 lifetime, which may span across multiple consecutive PCEP sessions 1779 and/or PCC restarts. The symbolic path name MAY be specified by an 1780 operator in a PCC's configuration. If the operator does not specify 1781 a unique symbolic name for a path, the PCC MUST auto-generate one. 1783 The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report 1784 when during a given PCEP session an LSP is first reported to a PCE. 1785 A PCC sends to a PCE the first LSP State Report either during State 1786 Synchronization, or when a new LSP is configured at the PCC. The 1787 symbolic path name MAY be included in subsequent LSP State Reports 1788 for the LSP. 1790 The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object 1791 and the LSPA Object. 1793 The format of the SYMBOLIC-PATH-NAME TLV is shown in the following 1794 figure: 1796 0 1 2 3 1797 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 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | Type=[TBD] | Length (variable) | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | | 1802 // Symbolic Path Name // 1803 | | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 Figure 19: SYMBOLIC-PATH-NAME TLV format 1808 The type of the TLV is [TBD] and it has a variable length, which MUST 1809 be greater than 0. 1811 7.3.3. LSP Error Code TLV 1813 The LSP Error code TLV is an optional TLV for use in the LSP object 1814 to convey error information. When an LSP Update Request fails, an 1815 LSP State Report MUST be sent to report the current state of the LSP, 1816 and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for 1817 the failure. Similarly, when a PCRpt is sent as a result of an LSP 1818 transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD 1819 be included to indicate the reason for the transition. 1821 The format of the LSP-ERROR-CODE TLV is shown in the following 1822 figure: 1824 0 1 2 3 1825 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 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | Type=[TBD] | Length=4 | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | LSP Error Code | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 Figure 20: LSP-ERROR-CODE TLV format 1834 The type of the TLV is [TBD] and it has a fixed length of 4 octets. 1835 The value contains an error code that indicates the cause of the 1836 failure. 1838 The following LSP Error Codes are defined: 1840 Value Meaning 1841 1 Unknown reason 1842 2 Limit reached for PCE-controlled LSPs 1843 3 Too many pending LSP update requests 1844 4 Unacceptable parameters 1845 5 Internal error 1846 6 LSP administratively brought down 1847 7 LSP preempted 1848 8 RSVP signaling error 1850 7.3.4. RSVP Error Spec TLV 1852 The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object 1853 to carry RSVP error information. It includes the RSVP ERROR_SPEC or 1854 USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned 1855 to the PCC from a downstream node. If the set up of an LSP fails at 1856 a downstream node which returned an ERROR_SPEC to the PCC, the PCC 1857 SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with 1858 LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV 1859 with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object. 1861 The format of the RSVP-ERROR-SPEC TLV is shown in the following 1862 figure: 1864 0 1 2 3 1865 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 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | Type=[TBD] | Length (variable) | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | | 1870 + RSVP ERROR_SPEC or USER_ERROR_SPEC Object + 1871 | | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 Figure 21: RSVP-ERROR-SPEC TLV format 1876 The type of the TLV is [TBD] and it has a variable length. The value 1877 contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the 1878 object header. 1880 7.3.5. LSP State Database Version TLV 1882 The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP 1883 object. The LSP-DB-VERSION TLV is discussed in Section 5.4.1 which 1884 covers state synchronization avoidance. The format of the TLV is 1885 described in Section 7.1.2, where the details of its use in the OPEN 1886 message are listed. 1888 If State Synchronization Avoidance has been enabled on a PCEP session 1889 (as described in Section 5.4.1), a PCC MUST include the LSP-DB- 1890 VERSION TLV in each LSP Object sent out on the session. If the TLV 1891 is missing, the PCE will generate an error with error-type 6 1892 (mandatory object missing) and Error Value 12 (LSP-DB-VERSION TLV 1893 missing) and close the session. If State Synchronization Avoidance 1894 has not been enabled on a PCEP session, the PCC SHOULD NOT include 1895 the LSP-DB-VERSION TLV in the LSP Object and the PCE SHOULD ignore it 1896 were it to receive one. 1898 Since a PCE does not make changes to the LSP State Database Version, 1899 a PCC should never encounter this TLV in a message from the PCE 1900 (other than the OPEN message). A PCC SHOULD ignore the LSP-DB- 1901 VERSION TLV, were it to receive one from a PCE. 1903 7.3.6. Delegation Parameters TLVs 1905 Multiple delegation parameters, such as sub-delegation permissions, 1906 authentication parameters, etc. need to be communicated from a PCC to 1907 a PCE during the delegation operation. Delegation parameters will be 1908 carried in multiple delegation parameter TLVs, which will be defined 1909 in future revisions of this document. 1911 7.4. Optional TLVs for the LSPA Object 1913 TLVs that may be included in the LSPA Object are described in the 1914 following sections and in separate technology-specific documents. 1916 7.4.1. Symbolic Path Name TLV 1918 See section Section 7.3.2. 1920 8. IANA Considerations 1922 This document requests IANA actions to allocate code points for the 1923 protocol elements defined in this document. Values shown here are 1924 suggested for use by IANA. 1926 8.1. PCEP Messages 1928 This document defines the following new PCEP messages: 1930 Value Meaning Reference 1931 10 Report This document 1932 11 Update This document 1934 8.2. PCEP Objects 1936 This document defines the following new PCEP Object-classes and 1937 Object-values: 1939 Object-Class Value Name Reference 1941 32 LSP This document 1942 Object-Type 1943 1 1944 33 SRP This document 1945 Object-Type 1946 1 1948 8.3. LSP Object 1950 This document requests that a registry is created to manage the Flags 1951 field of the LSP object. New values are to be assigned by Standards 1952 Action [RFC5226]. Each bit should be tracked with the following 1953 qualities: 1955 o Bit number (counting from bit 0 as the most significant bit) 1957 o Capability description 1959 o Defining RFC 1961 The following values are defined in this document: 1963 Bit Description Reference 1965 25-27 Operational (3 bits) This document 1966 28 Administrative This document 1967 29 Remove This document 1968 30 SYNC This document 1969 31 Delegate This document 1971 8.4. PCEP-Error Object 1973 This document defines new Error-Type and Error-Value for the 1974 following new error conditions: 1976 Error-Type Meaning 1977 6 Mandatory Object missing 1978 Error-value=8: LSP Object missing 1979 Error-value=9: ERO Object missing 1980 Error-value=10: SRP Object missing 1981 Error-value=11: LSP-IDENTIFIERS TLV missing 1982 Error-value=12: LSP-DB-VERSION TLV missing 1983 19 Invalid Operation 1984 Error-value=1: Attempted LSP Update Request for a non- 1985 delegated LSP. The PCEP-ERROR Object 1986 is followed by the LSP Object that 1987 identifies the LSP. 1988 Error-value=2: Attempted LSP Update Request if active 1989 stateful PCE capability was not 1990 negotiated active PCE. 1991 Error-value=3: Attempted LSP Update Request for an LSP 1992 identified by an unknown PLSP-ID. 1993 Error-value=4: Mismatched LSP signaling type. 1994 Error-value=5: Unsupported LSP signaling type. 1995 20 LSP State synchronization error. 1996 Error-value=1: A PCE indicates to a PCC that it can 1997 not process (an otherwise valid) LSP 1998 State Report. The PCEP-ERROR Object is 1999 followed by the LSP Object that 2000 identifies the LSP. 2001 Error-value=2: LSP Database version mismatch. 2002 Error-value=3: The LSP-DB-VERSION TLV Missing when 2003 State Synchronization Avoidance 2004 enabled. 2006 8.5. PCEP TLV Type Indicators 2008 This document defines the following new PCEP TLVs: 2010 Value Meaning Reference 2011 16 STATEFUL-PCE-CAPABILITY This document 2012 17 SYMBOLIC-PATH-NAME This document 2013 18 IPV4-LSP-IDENTIFIERS This document 2014 19 IPV6-LSP-IDENTIFIERS This document 2015 20 LSP-ERROR-CODE This document 2016 21 RSVP-ERROR-SPEC This document 2017 23 LSP-DB-VERSION This document 2018 24 PREDUNDANCY-GROUP-ID This document 2020 8.6. STATEFUL-PCE-CAPABILITY TLV 2022 This document requests that a registry is created to manage the Flags 2023 field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New 2024 values are to be assigned by Standards Action [RFC5226]. Each bit 2025 should be tracked with the following qualities: 2027 o Bit number (counting from bit 0 as the most significant bit) 2029 o Capability description 2031 o Defining RFC 2033 The following values are defined in this document: 2035 Bit Description Reference 2037 30 INCLUDE-DB-VERSION This document 2038 (IDB) 2039 31 LSP-UPDATE-CAPABILITY This document 2041 8.7. LSP-ERROR-CODE TLV 2043 This document requests that a registry is created to manage the value 2044 of the LSP error code field in this TLV. This field specifies the 2045 reason for failure to update the LSP. 2047 Value Meaning 2048 1 Unknown reason 2049 2 Limit reached for PCE-controlled LSPs 2050 3 Too many pending LSP update requests 2051 4 Unacceptable parameters 2052 5 Internal error 2053 6 LSP administratively brought down 2054 7 LSP preempted 2055 8 RSVP signaling error 2057 8.8. LSP-SIG-TYPE field in the LSP object 2059 This document requests that a registry is created to manage the value 2060 of the LSP type field in the LSP object, which defines the technology 2061 used for LSP setup. 2063 Value Meaning 2064 0 RSVP 2066 9. Manageability Considerations 2068 All manageability requirements and considerations listed in [RFC5440] 2069 apply to PCEP protocol extensions defined in this document. In 2070 addition, requirements and considerations listed in this section 2071 apply. 2073 9.1. Control Function and Policy 2075 In addition to configuring specific PCEP session parameters, as 2076 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 2077 allow configuring the stateful PCEP capability and the LSP Update 2078 capability. A PCC implementation SHOULD allow the operator to 2079 specify multiple candidate PCEs for and a delegation preference for 2080 each candidate PCE. A PCC SHOULD allow the operator to specify an 2081 LSP delegation policy where LSPs are delegated to the most-preferred 2082 online PCE. A PCC MAY allow the operator to specify different LSP 2083 delegation policies. 2085 A PCE or PCC implementation SHOULD allow the operator to configure a 2086 PREDUNDANCY-GROUP-ID (Section 7.1.3). 2088 A PCC implementation which allows concurrent connections to multiple 2089 PCEs SHOULD allow the operator to group the PCEs by administrative 2090 domains and it MUST NOT advertise LSP existence and state to a PCE if 2091 the LSP is delegated to a PCE in a different group. 2093 A PCC implementation SHOULD allow the operator to specify whether the 2094 PCC will advertise LSP existence and state for LSPs that are not 2095 controlled by any PCE (for example, LSPs that are statically 2096 configured at the PCC). 2098 A PCC implementation SHOULD allow the operator to specify both the 2099 Redelegation Timeout Interval and the State Timeout Interval. The 2100 default value of the Redelegation Timeout Interval SHOULD be set to 2101 30 seconds. An operator MAY also configure a policy that will 2102 dynamically adjust the Redelegation Timeout Interval, for example 2103 setting it to zero when the PCC has an established session to a 2104 backup PCE. The default value for the State Timeout Interval SHOULD 2105 be set to 60 seconds. 2107 After the expiration of the State Timeout Interval, the LSP reverts 2108 to operator-defined default parameters. A PCC implementation MUST 2109 allow the operator to specify the default LSP parameters. To achieve 2110 a behavior where the LSP retains the parameters set by the PCE until 2111 such time that the PCC makes a change to them, a State Timeout 2112 Interval of infinity SHOULD be used. Any changes to LSP parameters 2113 SHOULD be done in make-before-break fashion. 2115 A PCC implementation SHOULD allow the operator to specify delegation 2116 priority for PCEs. This effectively defines the primary PCE and one 2117 or more backup PCEs to which primary PCE's LSPs can be delegated when 2118 the primary PCE fails. 2120 Policies defined for stateful PCEs and PCCs should eventually fit in 2121 the Policy-Enabled Path Computation Framework defined in [RFC5394], 2122 and the framework should be extended to support Stateful PCEs. 2124 9.2. Information and Data Models 2126 PCEP session configuration and information in the PCEP MIB module 2127 SHOULD be extended to include negotiated stateful capabilities, 2128 synchronization status, and delegation status (at the PCC list PCEs 2129 with delegated LSPs). 2131 9.3. Liveness Detection and Monitoring 2133 PCEP protocol extensions defined in this document do not require any 2134 new mechanisms beyond those already defined in [RFC5440], Section 2135 8.3. 2137 9.4. Verifying Correct Operation 2139 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 2140 protocol extensions defined in this document. In addition to 2141 monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP 2142 implementation SHOULD provide the following parameters: 2144 o Total number of LSP updates 2146 o Number of successful LSP updates 2148 o Number of dropped LSP updates 2150 o Number of LSP updates where LSP setup failed 2152 A PCC implementation SHOULD provide a command to show for each LSP 2153 whether it is delegated, and if so, to which PCE. 2155 A PCC implementation SHOULD allow the operator to manually revoke LSP 2156 delegation. 2158 9.5. Requirements on Other Protocols and Functional Components 2160 PCEP protocol extensions defined in this document do not put new 2161 requirements on other protocols. 2163 9.6. Impact on Network Operation 2165 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 2166 protocol extensions defined in this document. 2168 Additionally, a PCEP implementation SHOULD allow a limit to be placed 2169 on the rate PCUpd and PCRpt messages sent by a PCEP speaker and 2170 processed from a peer. It SHOULD also allow sending a notification 2171 when a rate threshold is reached. 2173 A PCC implementation SHOULD allow a limit to be placed on the rate of 2174 LSP Updates to the same LSP to avoid signaling overload discussed in 2175 Section 10.3. 2177 10. Security Considerations 2179 10.1. Vulnerability 2181 This document defines extensions to PCEP to enable stateful PCEs. 2182 The nature of these extensions and the delegation of path control to 2183 PCEs results in more information being available for a hypothetical 2184 adversary and a number of additional attack surfaces which must be 2185 protected. 2187 The security provisions described in [RFC5440] remain applicable to 2188 these extensions. However, because the protocol modifications 2189 outlined in this document allow the PCE to control path computation 2190 timing and sequence, the PCE defense mechanisms described in 2191 [RFC5440] section 7.2 are also now applicable to PCC security. 2193 As a general precaution, it is RECOMMENDED that these PCEP extensions 2194 only be activated on authenticated and encrypted sessions across PCEs 2195 and PCCs belonging to the same administrative authority. 2197 The following sections identify specific security concerns that may 2198 result from the PCEP extensions outlined in this document along with 2199 recommended mechanisms to protect PCEP infrastructure against related 2200 attacks. 2202 10.2. LSP State Snooping 2204 The stateful nature of this extension explicitly requires LSP status 2205 updates to be sent from PCC to PCE. While this gives the PCE the 2206 ability to provide more optimal computations to the PCC, it also 2207 provides an adversary with the opportunity to eavesdrop on decisions 2208 made by network systems external to PCE. This is especially true if 2209 the PCC delegates LSPs to multiple PCEs simultaneously. 2211 Adversaries may gain access to this information by eavesdropping on 2212 unsecured PCEP sessions, and might then use this information in 2213 various ways to target or optimize attacks on network infrastructure. 2214 For example by flexibly countering anti-DDoS measures being taken to 2215 protect the network, or by determining choke points in the network 2216 where the greatest harm might be caused. 2218 PCC implementations which allow concurrent connections to multiple 2219 PCEs SHOULD allow the operator to group the PCEs by administrative 2220 domains and they MUST NOT advertise LSP existence and state to a PCE 2221 if the LSP is delegated to a PCE in a different group. 2223 10.3. Malicious PCE 2225 The LSP delegation mechanism described in this document allows a PCC 2226 to grant effective control of an LSP to the PCE for the duration of a 2227 PCEP session. While this enables PCE control of the timing and 2228 sequence of path computations within and across PCEP sessions, it 2229 also introduces a new attack vector: an attacker may flood the PCC 2230 with PCUpd messages at a rate which exceeds either the PCC's ability 2231 to process them or the network's ability to signal the changes, 2232 either by spoofing messages or by compromising the PCE itself. 2234 A PCC is free to revoke an LSP delegation at any time without needing 2235 any justification. A defending PCC can do this by enqueueing the 2236 appropriate PCRpt message. As soon as that message is enqueued in 2237 the session, the PCC is free to drop any incoming PCUpd messages 2238 without additional processing. 2240 10.4. Malicious PCC 2242 A stateful session also result in increased attack surface by placing 2243 a requirement for the PCE to keep an LSP state replica for each PCC. 2244 It is RECOMMENDED that PCE implementations provide a limit on 2245 resources a single PCC can occupy. 2247 Delegation of LSPs can create further strain on PCE resources and a 2248 PCE implementation MAY preemptively give back delegations if it finds 2249 itself lacking the resources needed to effectively manage the 2250 delegation. Since the delegation state is ultimately controlled by 2251 the PCC, PCE implementations SHOULD provide throttling mechanisms to 2252 prevent strain created by flaps of either a PCEP session or an LSP 2253 delegation. 2255 11. Acknowledgements 2257 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 2258 Casellas for their contributions to this document. 2260 We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, 2261 Paul Schultz and Raveendra Torvi for their comments and suggestions. 2262 Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Oscar 2263 Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej 2264 Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath, 2265 Calvin Ying and Xian Zhang for helpful comments and discussions. 2267 12. References 2269 12.1. Normative References 2271 [I-D.ietf-pce-gmpls-pcep-extensions] 2272 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 2273 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-08 (work in 2274 progress), July 2013. 2276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2277 Requirement Levels", BCP 14, RFC 2119, March 1997. 2279 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2280 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2281 Functional Specification", RFC 2205, September 1997. 2283 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2284 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2285 Tunnels", RFC 3209, December 2001. 2287 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2288 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2289 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2291 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 2292 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 2293 May 2005. 2295 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 2296 "OSPF Protocol Extensions for Path Computation Element 2297 (PCE) Discovery", RFC 5088, January 2008. 2299 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 2300 "IS-IS Protocol Extensions for Path Computation Element 2301 (PCE) Discovery", RFC 5089, January 2008. 2303 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2304 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2305 May 2008. 2307 [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", 2308 RFC 5284, August 2008. 2310 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 2311 (PCE) Communication Protocol (PCEP)", RFC 5440, 2312 March 2009. 2314 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2315 Used to Form Encoding Rules in Various Routing Protocol 2316 Specifications", RFC 5511, April 2009. 2318 12.2. Informative References 2320 [I-D.ietf-pce-stateful-pce-app] 2321 Zhang, X. and I. Minei, "Applicability of Stateful Path 2322 Computation Element (PCE)", 2323 draft-ietf-pce-stateful-pce-app-00 (work in progress), 2324 August 2013. 2326 [I-D.sivabalan-pce-disco-stateful] 2327 Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions 2328 for Stateful PCE Discovery", 2329 draft-sivabalan-pce-disco-stateful-02 (work in progress), 2330 July 2013. 2332 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2333 LSP Path Computation using Preemption", Global 2334 Information Infrastructure Symposium, July 2007. 2336 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2337 programming algorithm for balancing the max-min fairness 2338 and throughput objectives in traffic engineering", pre- 2339 print, 2011. 2341 [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network 2342 Recovery: Protection and Restoration of Optical, SONET- 2343 SDH, IP, and MPLS", The Morgan Kaufmann Series in 2344 Networking, June 2004. 2346 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2347 McManus, "Requirements for Traffic Engineering Over MPLS", 2348 RFC 2702, September 1999. 2350 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2351 Label Switching Architecture", RFC 3031, January 2001. 2353 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2354 Christian, B., and W. Lai, "Applicability Statement for 2355 Traffic Engineering with MPLS", RFC 3346, August 2002. 2357 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2358 (TE) Extensions to OSPF Version 2", RFC 3630, 2359 September 2003. 2361 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2362 Element (PCE)-Based Architecture", RFC 4655, August 2006. 2364 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 2365 Communication Protocol Generic Requirements", RFC 4657, 2366 September 2006. 2368 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2369 Engineering", RFC 5305, October 2008. 2371 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2372 "Policy-Enabled Path Computation Framework", RFC 5394, 2373 December 2008. 2375 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 2376 Computation Element Communication Protocol (PCEP) 2377 Requirements and Protocol Extensions in Support of Global 2378 Concurrent Optimization", RFC 5557, July 2009. 2380 Authors' Addresses 2382 Edward Crabbe 2383 Google, Inc. 2384 1600 Amphitheatre Parkway 2385 Mountain View, CA 94043 2386 US 2388 Email: edc@google.com 2389 Jan Medved 2390 Cisco Systems, Inc. 2391 170 West Tasman Dr. 2392 San Jose, CA 95134 2393 US 2395 Email: jmedved@cisco.com 2397 Ina Minei 2398 Juniper Networks, Inc. 2399 1194 N. Mathilda Ave. 2400 Sunnyvale, CA 94089 2401 US 2403 Email: ina@juniper.net 2405 Robert Varga 2406 Pantheon Technologies SRO 2407 Mlynske Nivy 56 2408 Bratislava 821 05 2409 Slovakia 2411 Email: robert.varga@pantheon.sk