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