idnits 2.17.1 draft-ietf-pce-stateful-pce-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 1, 2015) is 3062 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) == Outdated reference: A later version (-16) exists of draft-ietf-pce-gmpls-pcep-extensions-11 == Outdated reference: A later version (-08) exists of draft-ietf-pce-stateful-pce-app-05 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-04 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group E. Crabbe 3 Internet-Draft Individual Contributor 4 Intended status: Standards Track I. Minei 5 Expires: June 3, 2016 Google, Inc. 6 J. Medved 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 December 1, 2015 12 PCEP Extensions for Stateful PCE 13 draft-ietf-pce-stateful-pce-13 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 June 3, 2016. 44 Copyright Notice 46 Copyright (c) 2015 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 . . . . . . . . . 6 65 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 10 74 5.3. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10 75 5.4. Capability Advertisement . . . . . . . . . . . . . . . . 10 76 5.5. IGP Extensions for Stateful PCE Capabilities 77 Advertisement . . . . . . . . . . . . . . . . . . . . . . 11 78 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12 79 5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15 80 5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 81 5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16 82 5.7.3. Returning a Delegation . . . . . . . . . . . . . . . 18 83 5.7.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18 84 5.7.5. Redelegation on PCE Failure . . . . . . . . . . . . . 19 85 5.8. LSP Operations . . . . . . . . . . . . . . . . . . . . . 19 86 5.8.1. Passive Stateful PCE Path Computation 87 Request/Response . . . . . . . . . . . . . . . . . . 19 88 5.8.2. Active Stateful PCE LSP Update . . . . . . . . . . . 21 89 5.9. LSP Protection . . . . . . . . . . . . . . . . . . . . . 23 90 5.10. PCEP Sessions . . . . . . . . . . . . . . . . . . . . . . 23 91 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 23 92 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23 93 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 25 94 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 27 95 6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 28 96 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 29 98 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 29 99 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 29 100 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 29 101 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 30 102 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 32 103 7.3.1. LSP-IDENTIFIERS TLVs . . . . . . . . . . . . . . . . 34 104 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 37 105 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 38 106 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 38 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 108 8.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 39 109 8.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 40 110 8.3. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 40 111 8.4. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 40 112 8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 41 113 8.6. Notification Object . . . . . . . . . . . . . . . . . . . 41 114 8.7. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 42 115 8.8. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 42 116 8.9. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 42 117 9. Manageability Considerations . . . . . . . . . . . . . . . . 43 118 9.1. Control Function and Policy . . . . . . . . . . . . . . . 43 119 9.2. Information and Data Models . . . . . . . . . . . . . . . 44 120 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 44 121 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 44 122 9.5. Requirements on Other Protocols and Functional Components 45 123 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 45 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 125 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 45 126 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 46 127 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 46 128 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 47 129 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 47 130 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 131 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 132 13.1. Normative References . . . . . . . . . . . . . . . . . . 48 133 13.2. Informative References . . . . . . . . . . . . . . . . . 49 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 136 1. Introduction 138 [RFC5440] describes the Path Computation Element Communication 139 Protocol (PCEP). PCEP defines the communication between a Path 140 Computation Client (PCC) and a Path Computation Element (PCE), or 141 between PCEs, enabling computation of Multiprotocol Label Switching 142 (MPLS) for Traffic Engineering Label Switched Path (TE LSP) 143 characteristics. Extensions for support of Generalized MPLS (GMPLS) 144 in PCEP are defined in [I-D.ietf-pce-gmpls-pcep-extensions] 145 This document specifies a set of extensions to PCEP to enable 146 stateful control of LSPs within and across PCEP sessions in 147 compliance with [RFC4657]. It includes mechanisms to effect Label 148 Switched Path (LSP) state synchronization between PCCs and PCEs, 149 delegation of control over LSPs to PCEs, and PCE control of timing 150 and sequence of path computations within and across PCEP sessions. 152 1.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 2. Terminology 160 This document uses the following terms defined in [RFC5440]: PCC, 161 PCE, PCEP Peer, PCEP Speaker. 163 This document uses the following terms defined in [RFC4655]: TED. 165 This document uses the following terms defined in [RFC3031]: LSP. 167 The following terms are defined in this document: 169 Stateful PCE: a PCE that has access to not only the network state, 170 but also to the set of active paths and their reserved resources 171 for its computations. A stateful PCE might also retain 172 information regarding LSPs under construction in order to reduce 173 churn and resource contention. The additional state allows the 174 PCE to compute constrained paths while considering individual LSPs 175 and their interactions. Note that this requires reliable state 176 synchronization mechanisms between the PCE and the network, PCE 177 and PCC, and between cooperating PCEs. 179 Passive Stateful PCE: a PCE that uses LSP state information learned 180 from PCCs to optimize path computations. It does not actively 181 update LSP state. A PCC maintains synchronization with the PCE. 183 Active Stateful PCE: a PCE that may issue recommendations to the 184 network.For example, an Active Stateful PCE may utilize the 185 Delegation mechanism to update LSP parameters in those PCCs that 186 delegated control over their LSPs to the PCE. 188 Delegation: an operation to grant a PCE temporary rights to modify a 189 subset of LSP parameters on one or more PCC's LSPs. LSPs are 190 delegated from a PCC to a PCE, and are referred to as delegated 191 LSPs. The PCC that owns the PCE state for the LSP has the right 192 to delegate it. An LSP is owned by a single PCC at any given 193 point in time. For intra-domain LSPs, this PCC should be the LSP 194 head end. 196 Revocation: an operation performed by a PCC on a previously 197 delegated LSP. Revocation revokes the rights granted to the PCE 198 in the delegation operation. 200 Redelegation Timeout Interval: the period of time a PCC waits for, 201 when a PCEP session is terminated, before revoking LSP delegation 202 to a PCE and attempting to redelegate LSPs associated with the 203 terminated PCEP session to an alternate PCE. The Redelegation 204 Timeout Interval is a PCC-local value that can be either operator- 205 configured or dynamically computed by the PCC based on local 206 policy. 208 State Timeout Interval: the period of time a PCE waits for, when a 209 PCEP session is terminated, before flushing LSP state associated 210 with that PCEP session and reverting to operator-defined default 211 parameters or behaviors. The State Timeout Interval is a PCC- 212 local value that can be either operator-configured or dynamically 213 computed by the PCC based on local policy. 215 LSP State Report: an operation to send LSP state (Operational / 216 Admin Status, LSP attributes configured at the PCC and set by a 217 PCE, etc.) from a PCC to a PCE. 219 LSP Update Request: an operation where an Active Stateful PCE 220 requests a PCC to update one or more attributes of an LSP and to 221 re-signal the LSP with updated attributes. 223 SRP-ID-number: a number used to correlate errors and LSP State 224 Reports to LSP Update Requests. It is carried in the SRP 225 (Stateful PCE Request Parameters) Object described in Section 7.2. 227 LSP State Database: information about all LSPs and their attributes. 229 Within this document, PCEP communications are described through PCC- 230 PCE relationship. The PCE architecture also supports the PCE-PCE 231 communication, by having the requesting PCE fill the role of a PCC, 232 as usual. 234 The message formats in this document are specified using Routing 235 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 237 3. Motivation and Objectives for Stateful PCE 239 3.1. Motivation 241 [I-D.ietf-pce-stateful-pce-app] presents several use cases, 242 demonstrating scenarios that benefit from the deployment of a 243 stateful PCE. The scenarios apply equally to MPLS-TE and GMPLS 244 deployments. 246 3.1.1. Background 248 Traffic engineering has been a goal of the MPLS architecture since 249 its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic 250 engineering system provided by [RFC3630], [RFC5305], and [RFC3209] 251 information about network resources utilization is only available as 252 total reserved capacity by traffic class on a per interface basis; 253 individual LSP state is available only locally on each LER for its 254 own LSPs. In most cases, this makes good sense, as distribution and 255 retention of total LSP state for all LERs within in the network would 256 be prohibitively costly. 258 Unfortunately, this visibility in terms of global LSP state may 259 result in a number of issues for some demand patterns, particularly 260 within a common setup and hold priority. This issue affects online 261 traffic engineering systems. 263 A sufficiently over-provisioned system will by definition have no 264 issues routing its demand on the shortest path. However, lowering 265 the degree to which network over-provisioning is required in order to 266 run a healthy, functioning network is a clear and explicit promise of 267 MPLS architecture. In particular, it has been a goal of MPLS to 268 provide mechanisms to alleviate congestion scenarios in which 269 "traffic streams are inefficiently mapped onto available resources; 270 causing subsets of network resources to become over-utilized while 271 others remain underutilized" ([RFC2702]). 273 3.1.2. Why a Stateful PCE? 275 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 276 "strict synchronization between the PCE and not only the network 277 states (in term of topology and resource information), but also the 278 set of computed paths and reserved resources in use in the network." 279 [RFC4655] also expressed a number of concerns with regard to a 280 stateful PCE, specifically: 282 o Any reliable synchronization mechanism would result in significant 283 control plane overhead 285 o Out-of-band TED synchronization would be complex and prone to race 286 conditions 288 o Path calculations incorporating total network state would be 289 highly complex 291 In general, stress on the control plane will be directly proportional 292 to the size of the system being controlled and the tightness of the 293 control loop, and indirectly proportional to the amount of over- 294 provisioning in terms of both network capacity and reservation 295 overhead. 297 Despite these concerns in terms of implementation complexity and 298 scalability, several TE algorithms exist today that have been 299 demonstrated to be extremely effective in large TE systems, providing 300 both rapid convergence and significant benefits in terms of 301 optimality of resource usage [MXMN-TE]. All of these systems share 302 at least two common characteristics: the requirement for both global 303 visibility of a flow (or in this case, a TE LSP) state and for 304 ordered control of path reservations across devices within the system 305 being controlled. While some approaches have been suggested in order 306 to remove the requirements for ordered control (See [MPLS-PC]), these 307 approaches are highly dependent on traffic distribution, and do not 308 allow for multiple simultaneous LSP priorities representing diffserv 309 classes. 311 The use cases described in [I-D.ietf-pce-stateful-pce-app] 312 demonstrate a need for visibility into global inter-PCC LSP state in 313 PCE path computations, and for PCE control of sequence and timing in 314 altering LSP path characteristics within and across PCEP sessions. 316 3.1.3. Protocol vs. Configuration 318 Note that existing configuration tools and protocols can be used to 319 set LSP state. However, this solution has several shortcomings: 321 o Scale & Performance: configuration operations often have 322 transactional semantics which are typically heavyweight and often 323 require processing of additional configuration portions beyond the 324 state being directly acted upon, with corresponding cost in CPU 325 cycles, negatively impacting both PCC stability LSP update rate 326 capacity. 328 o Security: when a PCC opens a configuration channel allowing a PCE 329 to send configuration, a malicious PCE may take advantage of this 330 ability to take over the PCC. In contrast, the PCEP extensions 331 described in this document only allow a PCE control over a very 332 limited set of LSP attributes. 334 o Interoperability: each vendor has a proprietary information model 335 for configuring LSP state, which limits interoperability of a 336 stateful PCE with PCCs from different vendors. The PCEP 337 extensions described in this document allow for a common 338 information model for LSP state for all vendors. 340 o Efficient State Synchronization: configuration channels may be 341 heavyweight and unidirectional, therefore efficient state 342 synchronization between a PCC and a PCE may be a problem. 344 3.2. Objectives 346 The objectives for the protocol extensions to support stateful PCE 347 described in this document are as follows: 349 o Allow a single PCC to interact with a mix of stateless and 350 stateful PCEs simultaneously using the same protocol, i.e. PCEP. 352 o Support efficient LSP state synchronization between the PCC and 353 one or more active or passive stateful PCEs. 355 o Allow a PCC to delegate control of its LSPs to an active stateful 356 PCE such that a given LSP is under the control of a single PCE at 357 any given time. A PCC may revoke this delegation at any time 358 during the lifetime of the LSP. If LSP delegation is revoked 359 while the PCEP session is up, the PCC MUST notify the PCE about 360 the revocation. A PCE may return an LSP delegation at any point 361 during the lifetime of the PCEP session. 363 o Allow a PCE to control computation timing and update timing across 364 all LSPs that have been delegated to it. 366 o Enable uninterrupted operation of PCC's LSPs in the event of a PCE 367 failure or while control of LSPs is being transferred between 368 PCEs. 370 4. New Functions to Support Stateful PCEs 372 Several new functions are required in PCEP to support stateful PCEs. 373 A function can be initiated either from a PCC towards a PCE (C-E) or 374 from a PCE towards a PCC (E-C). The new functions are: 376 Capability advertisement (E-C,C-E): both the PCC and the PCE must 377 announce during PCEP session establishment that they support PCEP 378 Stateful PCE extensions defined in this document. 380 LSP state synchronization (C-E): after the session between the PCC 381 and a stateful PCE is initialized, the PCE must learn the state of 382 a PCC's LSPs before it can perform path computations or update LSP 383 attributes in a PCC. 385 LSP Update Request (E-C): a PCE requests modification of attributes 386 on a PCC's LSP. 388 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 389 whenever the state of an LSP changes. 391 LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 392 update LSP attributes on one or more LSPs; the PCE becomes the 393 authoritative source of the LSP's attributes as long as the 394 delegation is in effect (See Section 5.7); the PCC may withdraw 395 the delegation or the PCE may give up the delegation at any time. 397 Similarly to [RFC5440], no assumption is made about the discovery 398 method used by a PCC to discover a set of PCEs (e.g., via static 399 configuration or dynamic discovery) and on the algorithm used to 400 select a PCE. 402 5. Overview of Protocol Extensions 404 5.1. LSP State Ownership 406 In PCEP (defined in [RFC5440]), LSP state and operation are under the 407 control of a PCC (a PCC may be an LSR or a management station). 408 Attributes received from a PCE are subject to PCC's local policy. 409 The PCEP extensions described in this document do not change this 410 behavior. 412 An active stateful PCE may have control of a PCC's LSPs that were 413 delegated to it, but the LSP state ownership is retained by the PCC. 414 In particular, in addition to specifying values for LSP's attributes, 415 an active stateful PCE also decides when to make LSP modifications. 417 Retaining LSP state ownership on the PCC allows for: 419 o a PCC to interact with both stateless and stateful PCEs at the 420 same time 422 o a stateful PCE to only modify a small subset of LSP parameters, 423 i.e. to set only a small subset of the overall LSP state; other 424 parameters may be set by the operator, for example through command 425 line interface (CLI) commands 427 o a PCC to revert delegated LSP to an operator-defined default or to 428 delegate the LSPs to a different PCE, if the PCC get disconnected 429 from a PCE with currently delegated LSPs 431 5.2. New Messages 433 In this document, we define the following new PCEP messages: 435 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 436 to a PCE to report the status of one or more LSPs. Each LSP 437 Status Report in a PCRpt message MAY contain the actual LSP's 438 path, bandwidth, operational and administrative status, etc. An 439 LSP Status Report carried on a PCRpt message is also used in 440 delegation or revocation of control of an LSP to/from a PCE. The 441 PCRpt message is described in Section 6.1. 443 Path Computation Update Request (PCUpd): a PCEP message sent by a 444 PCE to a PCC to update LSP parameters, on one or more LSPs. Each 445 LSP Update Request on a PCUpd message MUST contain all LSP 446 parameters that a PCE wishes to be set for a given LSP. An LSP 447 Update Request carried on a PCUpd message is also used to return 448 LSP delegations if at any point PCE no longer desires control of 449 an LSP. The PCUpd message is described in Section 6.2. 451 The new functions defined in Section 4 are mapped onto the new 452 messages as shown in the following table. 454 +----------------------------------------+--------------+ 455 | Function | Message | 456 +----------------------------------------+--------------+ 457 | Capability Advertisement (E-C,C-E) | Open | 458 | State Synchronization (C-E) | PCRpt | 459 | LSP State Report (C-E) | PCRpt | 460 | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | 461 | LSP Update Request (E-C) | PCUpd | 462 +----------------------------------------+--------------+ 464 Table 1: New Function to Message Mapping 466 5.3. Error Reporting 468 Error reporting is done using the procedures defined in [RFC5440], 469 and reusing the applicable error types and error values of [RFC5440] 470 wherever appropriate. The current document defines new error values 471 for several error types to cover failures specific to stateful PCE. 473 5.4. Capability Advertisement 475 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 476 advertise their support of stateful PCEP extensions. A PCEP Speaker 477 includes the "Stateful PCE Capability" TLV, described in 478 Section 7.1.1, in the OPEN Object to advertise its support for PCEP 479 stateful extensions. The Stateful Capability TLV includes the 'LSP 480 Update' Flag that indicates whether the PCEP Speaker supports LSP 481 parameter updates. 483 The presence of the Stateful PCE Capability TLV in PCC's OPEN Object 484 indicates that the PCC is willing to send LSP State Reports whenever 485 LSP parameters or operational status changes. 487 The presence of the Stateful PCE Capability TLV in PCE's OPEN message 488 indicates that the PCE is interested in receiving LSP State Reports 489 whenever LSP parameters or operational status changes. 491 The PCEP extensions for stateful PCEs MUST NOT be used if one or both 492 PCEP Speakers have not included the Stateful PCE Capability TLV in 493 their respective OPEN message. If the PCEP Speaker on the PCC 494 supports the extensions of this draft but did not advertise this 495 capability, then upon receipt of PCUpd message from the PCE, it MUST 496 generate a PCErr with error-type 19 (Invalid Operation), error-value 497 2 (Attempted LSP Update Request if the stateful PCE capability was 498 not advertised)(see Section 8.5) and it SHOULD terminate the PCEP 499 session. If the PCEP Speaker on the PCE supports the extensions of 500 this draft but did not advertise this capability, then upon receipt 501 of a PCRpt message from the PCC, it MUST generate a PCErr with error- 502 type 19 (Invalid Operation), error-value 5 (Attempted LSP State 503 Report if active stateful PCE capability was not advertised) (see 504 Section 8.5) and it SHOULD terminate the PCEP session. 506 LSP delegation and LSP update operations defined in this document may 507 only be used if both PCEP Speakers set the LSP-UPDATE Flag in the 508 "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this 509 is not the case and LSP delegation or LSP update operations are 510 attempted, then a PCErr with error-type 19 (Invalid Operation) and 511 error-value 1 (Attempted LSP Update Request for a non-delegated LSP) 512 (see Section 8.5) MUST be generated. Note that even if the update 513 capability has not been advertised, a PCE can still accept LSP Status 514 Reports from a PCC and build and maintain an up to date view of the 515 state of the PCC's LSPs. 517 5.5. IGP Extensions for Stateful PCE Capabilities Advertisement 519 When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs 520 are either LSRs or servers also participating in the IGP, an 521 effective mechanism for PCE discovery within an IGP routing domain 522 consists of utilizing IGP advertisements. Extensions for the 523 advertisement of PCE Discovery Information are defined for OSPF and 524 for IS-IS in [RFC5088] and [RFC5089] respectively. 526 The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- 527 TLV used to advertise PCE capabilities. It MAY be present within the 528 PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] 529 provide the description and processing rules for this sub-TLV when 530 carried within OSPF and IS-IS, respectively. 532 The format of the PCE-CAP-FLAGS sub-TLV is included below for easy 533 reference: 535 Type: 5 537 Length: Multiple of 4. 539 Value: This contains an array of units of 32 bit flags with the most 540 significant bit as 0. Each bit represents one PCE capability. 542 PCE capability bits are defined in [RFC5088]. This document defines 543 new capability bits for the stateful PCE as follows: 545 Bit Capability 546 TBD Active Stateful PCE capability 547 TBD Passive Stateful PCE capability 549 Note that while active and passive stateful PCE capabilities may be 550 advertised during discovery, PCEP Speakers that wish to use stateful 551 PCEP MUST negotiate stateful PCEP capabilities during PCEP session 552 setup, as specified in the current document. A PCC MAY initiate 553 stateful PCEP capability negotiation at PCEP session setup even if it 554 did not receive any IGP PCE capability advertisements. 556 5.6. State Synchronization 558 The purpose of State Synchronization is to provide a checkpoint-in- 559 time state replica of a PCC's LSP state in a PCE. State 560 Synchronization is performed immediately after the Initialization 561 phase ([RFC5440]). 563 During State Synchronization, a PCC first takes a snapshot of the 564 state of its LSPs state, then sends the snapshot to a PCE in a 565 sequence of LSP State Reports. Each LSP State Report sent during 566 State Synchronization has the SYNC Flag in the LSP Object set to 1. 567 The set of LSPs for which state is synchronized with a PCE is 568 determined by advertised stateful PCEP capabilities and PCC's local 569 configuration (see more details in Section 9.1). 571 The end of synchronization marker is a PCRpt message with the SYNC 572 Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved 573 value 0 (see Section 7.3). The LSP Object does not include the 574 SYMBOLIC-PATH-NAME TLV in this case, it will include an empty ERO as 575 its intended path and will not include the optional RRO object in the 576 path. If the PCC has no state to synchronize, it will only send the 577 end of synchronization marker. 579 A PCE SHOULD NOT send PCUpd messages to a PCC before State 580 Synchronization is complete. A PCC SHOULD NOT send PCReq messages to 581 a PCE before State Synchronization is complete. This is to allow the 582 PCE to get the best possible view of the network before it starts 583 computing new paths. 585 Either the PCE or the PCC MAY terminate the session using the PCEP 586 session termination procedures during the synchronization phase. If 587 the session is terminated, the PCE MUST clean up state it received 588 from this PCC. The session reestablishment MUST be re-attempted per 589 the procedures defined in [RFC5440], including use of a back-off 590 timer. 592 If the PCC encounters a problem which prevents it from completing the 593 state transfer, it MUST send a PCErr message with error-type 20 (LSP 594 State Synchronization Error) and error-value 5 (indicating an 595 internal PCC error) to the PCE and terminate the session. 597 The PCE does not send positive acknowledgements for properly received 598 synchronization messages. It MUST respond with a PCErr message with 599 error-type 20 (LSP State Synchronization Error) and error-value 1 600 (indicating an error in processing the PCRpt) (see Section 8.5) if it 601 encounters a problem with the LSP State Report it received from the 602 PCC and it MUST terminate the session. 604 A PCE implementing a limit on the resources a single PCC can occupy, 605 MUST send a PCNtf message with Notification Type to be allocated by 606 IANA (Stateful PCE resource limit exceeded) and Notification Value to 607 be allocated by IANA (Entering resource limit exceeded state) in 608 response to the PCRpt message triggering this condition in the 609 synchronization phase and MUST terminate the session. 611 The successful State Synchronization sequence is shown in Figure 1. 613 +-+-+ +-+-+ 614 |PCC| |PCE| 615 +-+-+ +-+-+ 616 | | 617 |-----PCRpt, SYNC=1----->| (Sync start) 618 | | 619 |-----PCRpt, SYNC=1----->| 620 | . | 621 | . | 622 | . | 623 |-----PCRpt, SYNC=1----->| 624 | . | 625 | . | 626 | . | 627 | | 628 |-----PCRpt, SYNC=0----->| (End of sync marker 629 | | LSP State Report 630 | | for PLSP-ID=0) 631 | | (Sync done) 633 Figure 1: Successful state synchronization 635 The sequence where the PCE fails during the State Synchronization 636 phase is shown in Figure 2. 638 +-+-+ +-+-+ 639 |PCC| |PCE| 640 +-+-+ +-+-+ 641 | | 642 |-----PCRpt, SYNC=1----->| 643 | | 644 |-----PCRpt, SYNC=1----->| 645 | . | 646 | . | 647 | . | 648 |-----PCRpt, SYNC=1----->| 649 | | 650 |-PCRpt, SYNC=1 | 651 | \ ,-PCErr | 652 | \ / | 653 | \/ | 654 | /\ | 655 | / `-------->| (Ignored) 656 |<--------` | 658 Figure 2: Failed state synchronization (PCE failure) 660 The sequence where the PCC fails during the State Synchronization 661 phase is shown in Figure 3. 663 +-+-+ +-+-+ 664 |PCC| |PCE| 665 +-+-+ +-+-+ 666 | | 667 |-----PCRpt, SYNC=1----->| 668 | | 669 |-----PCRpt, SYNC=1----->| 670 | . | 671 | . | 672 | . | 673 |-------- PCErr=? ------>| 674 | | 676 Figure 3: Failed state synchronization (PCC failure) 678 Optimizations to the synchronization procedures and alternate 679 mechanisms of providing the synchronization function are outside the 680 scope of this document and are discussed elsewhere (see 681 [I-D.ietf-pce-stateful-sync-optimizations]). 683 5.7. LSP Delegation 685 If during Capability advertisement both the PCE and the PCC have 686 indicated that they support LSP Update, then the PCC may choose to 687 grant the PCE a temporary right to update (a subset of) LSP 688 attributes on one or more LSPs. This is called "LSP Delegation", and 689 it MAY be performed at any time after the Initialization phase, 690 including during the State Synchronization phase. 692 A PCE MAY return an LSP delegation at any time if it no longer wishes 693 to update the LSP's state. A PCC MAY revoke an LSP delegation at any 694 time. Delegation, Revocation, and Return are done individually for 695 each LSP. 697 In the event of a delegation being rejected or returned by a PCE, the 698 PCC SHOULD react based on local policy. It can, for example, either 699 retry delegating to the same PCE using an exponentially increasing 700 timer or delegate to an alternate PCE. 702 5.7.1. Delegating an LSP 704 A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP 705 State Report to 1. If the PCE does not accept the LSP Delegation, it 706 MUST immediately respond with an empty LSP Update Request which has 707 the Delegate flag set to 0. If the PCE accepts the LSP Delegation, 708 it MUST set the Delegate flag to 1 when it sends an LSP Update 709 Request for the delegated LSP (note that this may occur at a later 710 time). The PCE MAY also immediately acknowledge a delegation by 711 sending an empty LSP Update Request which has the Delegate flag set 712 to 1. 714 The delegation sequence is shown in Figure 4. 716 +-+-+ +-+-+ 717 |PCC| |PCE| 718 +-+-+ +-+-+ 719 | | 720 |---PCRpt, Delegate=1--->| LSP Delegated 721 | | 722 |---PCRpt, Delegate=1--->| 723 | . | 724 | . | 725 | . | 726 |<--(PCUpd,Delegate=1)---| Delegation confirmed 727 | | 728 |---PCRpt, Delegate=1--->| 729 | | 731 Figure 4: Delegating an LSP 733 Note that for an LSP to remain delegated to a PCE, the PCC MUST set 734 the Delegate flag to 1 on each LSP Status Report sent to the PCE. 736 5.7.2. Revoking a Delegation 738 5.7.2.1. Explicit Revocation 740 When a PCC decides that a PCE is no longer permitted to modify an 741 LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke 742 an LSP delegation at any time during the LSP's life time. A PCC 743 revoking an LSP delegation MAY immediately clear the LSP state 744 provided by the PCE, but to avoid traffic loss, it SHOULD do so in a 745 make-before-break fashion. If the PCC has received but not yet acted 746 on PCUpd messages from the PCE for the LSP whose delegation is being 747 revoked, then it SHOULD ignore these PCUpd messages when processing 748 the message queue. All effects of all messages for which processing 749 started before the revocation took place MUST be allowed to complete 750 and the result MUST be given the same treatment as any LSP that had 751 been previously delegated to the PCE (e.g. the state MAY be 752 immediately cleared). Any further PCUpd messages from the PCE are 753 handled according to the PCUpd procedures described in this document. 755 If a PCEP session with the PCE to which the LSP is delegated exists 756 in the UP state during the revocation, the PCC MUST notify that PCE 757 by sending an LSP State Report with the Delegate flag set to 0, as 758 shown in Figure 5. 760 +-+-+ +-+-+ 761 |PCC| |PCE| 762 +-+-+ +-+-+ 763 | | 764 |---PCRpt, Delegate=1--->| 765 | | 766 |<--(PCUpd,Delegate=1)---| Delegation confirmed 767 | . | 768 | . | 769 | . | 770 |---PCRpt, Delegate=0--->| PCC revokes delegation 771 | | 773 Figure 5: Revoking a Delegation 775 After an LSP delegation has been revoked, a PCE can no longer update 776 LSP's parameters; an attempt to update parameters of a non-delegated 777 LSP will result in the PCC sending a PCErr message with error-type 19 778 (Invalid Operation), error-value 1 (attempted LSP Update Request for 779 a non-delegated LSP) (see Section 8.5). 781 5.7.2.2. Revocation on Redelegation Timeout 783 When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC 784 MUST wait the time interval specified in Redelegation Timeout 785 Interval before revoking LSP delegations to that PCE and attempting 786 to redelegate LSPs to an alternate PCE. If a PCEP session with the 787 original PCE can be reestablished before the Redelegation Timeout 788 Interval timer expires, LSP delegations to the PCE remain intact. 790 Likewise, when a PCC's PCEP session with a PCE terminates 791 unexpectedly, the PCC MUST wait for the State Timeout Interval before 792 flushing any LSP state associated with that PCE. Note that the State 793 Timeout Interval timer may expire before the PCC has redelegated the 794 LSPs to another PCE, for example if a PCC is not connected to any 795 active stateful PCE or if no connected active stateful PCE accepts 796 the delegation. In this case, the PCC MUST flush any LSP state set 797 by the PCE upon expiration of the State Timeout Interval and revert 798 to operator-defined default parameters or behaviors. This operation 799 SHOULD be done in a make-before-break fashion. 801 The State Timeout Interval MUST be greater than or equal to the 802 Redelegation Timeout Interval and MAY be set to infinity (meaning 803 that until the PCC specifically takes action to change the parameters 804 set by the PCE, they will remain intact). 806 5.7.3. Returning a Delegation 808 In order to keep a delegation, a PCE MUST set the Delegate flag to 1 809 on each LSP Update Request sent to the PCC. A PCE that no longer 810 wishes to update an LSP's parameters SHOULD return the LSP delegation 811 back to the PCC by sending an empty LSP Update Request which has the 812 Delegate flag set to 0. If a PCC receives a non-empty LSP Update 813 Request with the Delegate flag set to 0, it MUST treat this as a 814 delegation return. 816 +-+-+ +-+-+ 817 |PCC| |PCE| 818 +-+-+ +-+-+ 819 | | 820 |---PCRpt, Delegate=1--->| LSP delegated 821 | . | 822 | . | 823 | . | 824 |<--PCUpd, Delegate=0----| Delegation returned 825 | | 826 |---PCRpt, Delegate=0--->| No delegation for LSP 827 | | 829 Figure 6: Returning a Delegation 831 If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is 832 not connected to any active stateful PCE or if no connected active 833 stateful PCE accepts the delegation), the LSP delegation on the PCC 834 will time out within a configurable Redelegation Timeout Interval and 835 the PCC MUST flush any LSP state set by a PCE at the expiration of 836 the State Timeout Interval. 838 5.7.4. Redundant Stateful PCEs 840 In a redundant configuration where one PCE is backing up another PCE, 841 the backup PCE may have only a subset of the LSPs in the network 842 delegated to it. The backup PCE does not update any LSPs that are 843 not delegated to it. In order to allow the backup to operate in a 844 hot-standby mode and avoid the need for state synchronization in case 845 the primary fails, the backup receives all LSP State Reports from a 846 PCC. When the primary PCE for a given LSP set fails, after expiry of 847 the Redelegation Timeout Interval, the PCC SHOULD delegate to the 848 redundant PCE all LSPs that had been previously delegated to the 849 failed PCE. Assuming that the State Timeout Interval had been 850 configured to be greater than the Redelegation Timeout Interval (as 851 MANDATORY), and assuming that the primary and redundant PCEs take 852 similar decisions, this delegation change will not cause any changes 853 to the LSP parameters. 855 5.7.5. Redelegation on PCE Failure 857 On failure, the goal is to: 1) avoid any traffic loss on the LSPs 858 that were updated by the PCE that crashed 2) minimize the churn in 859 the network in terms of ownership of the LSPs, 3) not leave any 860 "orphan" (undelegated) LSPs and 4) be able to control when the state 861 that was set by the PCE can be changed or purged. The values chosen 862 for the Redelegation Timeout and State Timeout values affect the 863 ability to accomplish these goals. 865 This section summarizes the behaviour with regards to LSP delegation 866 and LSP state on a PCE failure. 868 If the PCE crashes but recovers within the Redelegation Timeout, both 869 the delegation state and the LSP state are kept intact. 871 If the PCE crashes but does not recover within the Redelegation 872 Timeout, the delegation state is returned to the PCC. If the PCC can 873 redelegate the LSPs to another PCE, and that PCE accepts the 874 delegations, there will be no change in LSP state. If the PCC cannot 875 redelegate the LSPs to another PCE, then upon expiration of the State 876 Timeout Interval, the state set by the PCE is flushed, which may 877 cause change in the LSP state. Note that an operator may choose to 878 use an infinite State Timeout Interval if he wishes to maintain the 879 PCE state indefinetely. Note also that flushing the state should be 880 implemented using make-before-break to avoid traffic loss. 882 If there is a standby PCE, the Redelegation Timeout may be set to 0 883 through policy on the PCC, causing the LSPs to be redelegated 884 immediately to the PCC, which can delegate them immediately to the 885 standby PCE. Assuming the State Timeout Interval is greater than the 886 Redelegation Timeout, and assuming the standby PCE takes similar 887 decisions as the failed PCE, the LSP state will be kept intact. 889 5.8. LSP Operations 891 5.8.1. Passive Stateful PCE Path Computation Request/Response 892 +-+-+ +-+-+ 893 |PCC| |PCE| 894 +-+-+ +-+-+ 895 | | 896 1) Path computation |----- PCReq message --->| 897 request sent to | |2) Path computation 898 PCE | | request received, 899 | | path computed 900 | | 901 |<---- PCRep message ----|3) Computed paths 902 | (Positive reply) | sent to the PCC 903 | (Negative reply) | 904 4) LSP Status change| | 905 event | | 906 | | 907 5) LSP Status Report|----- PCRpt message --->| 908 sent to all | . | 909 stateful PCEs | . | 910 | . | 911 6) Repeat for each |----- PCRpt message --->| 912 LSP status change| | 913 | | 915 Figure 7: Passive Stateful PCE Path Computation Request/Response 917 Once a PCC has successfully established a PCEP session with a passive 918 stateful PCE and the PCC's LSP state is synchronized with the PCE 919 (i.e. the PCE knows about all PCC's existing LSPs), if an event is 920 triggered that requires the computation of a set of paths, the PCC 921 sends a path computation request to the PCE ([RFC5440], 922 Section 4.2.3). The PCReq message MAY contain the LSP Object to 923 identify the LSP for which the path computation is requested. 925 Upon receiving a path computation request from a PCC, the PCE 926 triggers a path computation and returns either a positive or a 927 negative reply to the PCC ([RFC5440], Section 4.2.4). 929 Upon receiving a positive path computation reply, the PCC receives a 930 set of computed paths and starts to setup the LSPs. For each LSP, it 931 MAY send an LSP State Report carried on a PCRpt message to the PCE, 932 indicating that the LSP's status is "Going-up". 934 Once an LSP is up or active, the PCC MUST send an LSP State Report 935 carried on a PCRpt message to the PCE, indicating that the LSP's 936 status is 'Up' or 'Active' respectively. If the LSP could not be set 937 up, the PCC MUST send an LSP State Report indicating that the LSP is 938 "Down' and stating the cause of the failure. Note that due to timing 939 constraints, the LSP status may change from 'Going-up' to 'Up' (or 940 'Down') before the PCC has had a chance to send an LSP State Report 941 indicating that the status is 'Going-up'. In such cases, the PCC MAY 942 choose to only send the PCRpt indicating the latest status ('Active', 943 'Up' or 'Down'). 945 Upon receiving a negative reply from a PCE, a PCC MAY resend a 946 modified request or take any other appropriate action. For each 947 requested LSP, it SHOULD also send an LSP State Report carried on a 948 PCRpt message to the PCE, indicating that the LSP's status is 'Down'. 950 There is no direct correlation between PCRep and PCRpt messages. For 951 a given LSP, multiple LSP State Reports will follow a single PCRep 952 message, as a PCC notifies a PCE of the LSP's state changes. 954 A PCC MUST send each LSP State Report to each stateful PCE that is 955 connected to the PCC. 957 Note that a single PCRpt message MAY contain multiple LSP State 958 Reports. 960 The passive stateful PCE is the model for stateful PCEs is described 961 in [RFC4655], Section 6.8. 963 5.8.2. Active Stateful PCE LSP Update 965 +-+-+ +-+-+ 966 |PCC| |PCE| 967 +-+-+ +-+-+ 968 | | 969 1) LSP State |-- PCRpt, Delegate=1 -->| 970 Synchronization | . | 971 | . |2) PCE decides to 972 | . | update the LSP 973 | | 974 |<---- PCUpd message ----|3) PCUpd message sent 975 | | to PCC 976 | | 977 | | 978 4) LSP Status Report|---- PCRpt message ---->| 979 sent(->Going-up) | . | 980 | . | 981 | . | 982 5) LSP Status Report|---- PCRpt message ---->| 983 sent (->Up|Down) | | 984 | | 986 Figure 8: Active Stateful PCE 988 Once a PCC has successfully established a PCEP session with an active 989 stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. 990 the PCE knows about all PCC's existing LSPs). After LSPs have been 991 delegated to the PCE, the PCE can modify LSP parameters of delegated 992 LSPs. 994 To update an LSP, a PCE MUST send the PCC an LSP Update Request using 995 a PCUpd message. The LSP Update Request contains a variety of 996 objects that specify the set of constraints and attributes for the 997 LSP's path. Each LSP Update Request MUST have a unique identifier, 998 the SRP-ID-number, carried in the SRP (Stateful PCE Request 999 Parameters) Object described in Section 7.2. The SRP-ID-number is 1000 used to correlate errors and state reports to LSP Update Requests. A 1001 single PCUpd message MAY contain multiple LSP Update Requests. 1003 Upon receiving a PCUpd message the PCC starts to setup LSPs specified 1004 in LSP Update Requests carried in the message. For each LSP, it MAY 1005 send an LSP State Report carried on a PCRpt message to the PCE, 1006 indicating that the LSP's status is 'Going-up'. If the PCC decides 1007 that the LSP parameters proposed in the PCUpd message are 1008 unacceptable, it MUST report this error by including the LSP-ERROR- 1009 CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable 1010 parameters" in the LSP object in the PCRpt message to the PCE. Based 1011 on local policy, it MAY react further to this error by revoking the 1012 delegation. If the PCC receives a PCUpd message for an LSP object 1013 identified with a PLSP-ID that does not exist on the PCC, it MUST 1014 generate a PCErr with error-type 19 (Invalid Operation), error-value 1015 3, (Attempted LSP Update Request for an LSP identified by an unknown 1016 PSP-ID) (see Section 8.5). 1018 Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt 1019 message) to the PCE, indicating that the LSP's status is 'Up'. If 1020 the LSP could not be set up, the PCC MUST send an LSP State Report 1021 indicating that the LSP is 'Down' and stating the cause of the 1022 failure. A PCC MAY compress LSP State Reports to only reflect the 1023 most up to date state, as discussed in the previous section. 1025 A PCC MUST send each LSP State Report to each stateful PCE that is 1026 connected to the PCC. 1028 PCErr and PCRpt messages triggered as a result of a PCUpd message 1029 MUST include the SRP-ID-number from the PCUpd. This provides 1030 correlation of requests and errors and acknowledgement of state 1031 processing. The PCC MAY compress state when processing PCUpd. In 1032 this case, receipt of a higher SRP-ID-number implicitly acknowledges 1033 processing all the updates with lower SRP-ID-number for the specific 1034 LSP (as per Section 7.2). 1036 A PCC MUST NOT send to any PCE a Path Computation Request for a 1037 delegated LSP. Should the PCC decide it wants to issue a Path 1038 Computation Request on a delegated LSP, it MUST perform Delegation 1039 Revocation procedure first. 1041 5.9. LSP Protection 1043 LSP protection and interaction with stateful PCE, as well as the 1044 extensions necessary to implement this functionality will be 1045 discussed in a separate document. 1047 5.10. PCEP Sessions 1049 A permanent PCEP session MUST be established between a stateful PCE 1050 and the PCC. In the case of session failure, session reestablishment 1051 MUST be re-attempted per the procedures defined in [RFC5440]. 1053 6. PCEP Messages 1055 As defined in [RFC5440], a PCEP message consists of a common header 1056 followed by a variable-length body made of a set of objects. For 1057 each PCEP message type, a set of rules is defined that specify the 1058 set of objects that the message can carry. 1060 6.1. The PCRpt Message 1062 A Path Computation LSP State Report message (also referred to as 1063 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 1064 current state of an LSP. A PCRpt message can carry more than one LSP 1065 State Reports. A PCC can send an LSP State Report either in response 1066 to an LSP Update Request from a PCE, or asynchronously when the state 1067 of an LSP changes. The Message-Type field of the PCEP common header 1068 for the PCRpt message is to be assigned by IANA. 1070 The format of the PCRpt message is as follows: 1072 ::= 1073 1074 Where: 1076 ::= [] 1078 ::= [] 1079 1080 1081 Where: 1082 ::= [] 1084 Where: 1085 is represented by the ERO object defined in 1086 section 7.9 of [RFC5440]. 1087 is defined in [RFC5440] and extended by 1088 PCEP extensions. 1089 is represented by the RRO object defined in 1090 section 7.10 of [RFC5440]. 1092 The SRP object (see Section 7.2) is OPTIONAL. If the PCRpt message 1093 is not in response to a PCupd message, the SRP object MAY be omitted. 1094 When the PCC does not include the SRP object, the PCE MUST treat this 1095 as an SRP object with an SRP-ID-number equal to the reserved value 1096 0x00000000. The reserved value 0x00000000 indicates that the state 1097 reported is not as a result of processing a PCUpd message. 1099 If the PCRpt message is in response to a PCUpd message, the SRP 1100 object MUST be included and the value of the SRP-ID-number in the SRP 1101 Object MUST be the same as that sent in the PCUpd message that 1102 triggered the state that is reported. If the PCC compressed several 1103 PCUpd messages for the same LSP by only processing the one with the 1104 highest number, then it should use the SRP-ID-number of that request. 1105 No state compression is allowed for state reporting, e.g. PCRpt 1106 messages MUST NOT be pruned from the PCC's egress queue even if 1107 subsequent operations on the same LSP have been completed before the 1108 PCRpt message has been sent to the TCP stack. The PCC MUST 1109 explicitly report state changes (including removal) for paths it 1110 manages. 1112 The LSP object (see Section 7.3) is REQUIRED, and it MUST be included 1113 in each LSP State Report on the PCRpt message. If the LSP object is 1114 missing, the receiving PCE MUST send a PCErr message with Error- 1115 type=6 (Mandatory Object missing) and Error-value to be assigned by 1116 IANA (LSP object missing). 1118 If the LSP transitioned to non-operational state, the PCC SHOULD 1119 include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error 1120 Code to report the error to the PCE. 1122 The actual path, represented by the RRO object, SHOULD be included in 1123 PCRpt by the PCC when the path is up or active, but MAY be omitted if 1124 the path is down due to a signaling error or another failure. 1126 A PCE may choose to implement a limit on the resources a single PCC 1127 can occupy. If a PCRpt is received that causes the PCE to exceed 1128 this limit, the PCE MUST notify the PCC using a PCNtf message with 1129 Notification Type to be allocated by IANA (Stateful PCE resource 1130 limit exceeded) and Notification Value to be allocated by IANA 1131 (Entering resource limit exceeded state) and MAY terminate the 1132 session. 1134 6.2. The PCUpd Message 1136 A Path Computation LSP Update Request message (also referred to as 1137 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 1138 attributes of an LSP. A PCUpd message can carry more than one LSP 1139 Update Request. The Message-Type field of the PCEP common header for 1140 the PCUpd message is to be assigned by IANA. 1142 The format of a PCUpd message is as follows: 1144 ::= 1145 1146 Where: 1148 ::= [] 1150 ::= 1151 1152 1153 Where: 1154 ::= 1156 Where: 1157 is represented by the ERO object defined in 1158 section 7.9 of [RFC5440]. 1159 is defined in [RFC5440] and extended by 1160 PCEP extensions. 1162 There are three mandatory objects that MUST be included within each 1163 LSP Update Request in the PCUpd message: the SRP Object (see 1164 Section 7.2), the LSP object (see Section 7.3) and the ERO object (as 1165 defined in [RFC5440], which represents the intended path. If the SRP 1166 object is missing, the receiving PCC MUST send a PCErr message with 1167 Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP 1168 object missing). If the LSP object is missing, the receiving PCC 1169 MUST send a PCErr message with Error-type=6 (Mandatory Object 1170 missing) and Error-value=8 (LSP object missing). If the ERO object 1171 is missing, the receiving PCC MUST send a PCErr message with Error- 1172 type=6 (Mandatory Object missing) and Error-value=9 (ERO object 1173 missing). 1175 A PCC only acts on an LSP Update Request if permitted by the local 1176 policy configured by the network manager. Each LSP Update Request 1177 that the PCC acts on results in an LSP setup operation. An LSP 1178 Update Request MUST contain all LSP parameters that a PCE wishes to 1179 be set for the LSP. A PCC MAY set missing parameters from locally 1180 configured defaults. If the LSP specified in the Update Request is 1181 already up, it will be re-signaled. 1183 The PCC SHOULD minimize the traffic interruption, and MAY use the 1184 make-before-break procedures described in [RFC3209] in order to 1185 achieve this goal. If the make-before-break procedures are used, two 1186 paths will briefly co-exist. The PCC MUST send separate PCRpt 1187 messages for each, identified by the LSP-IDENTIFIERS TLV. When the 1188 old path is torn down after the head end switches over the traffic, 1189 this event MUST be reported by sending a PCRpt message with the LSP- 1190 IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number 1191 that the PCC associates with this PCRpt MUST be 0x00000000. Thus, a 1192 make-before-break operation will typically result in at least two 1193 PCRpt messages, one for the new path and one for the removal of the 1194 old path (more messages may be possible if intermediate states are 1195 reported). 1197 If the path setup fails due to an RSVP signaling error, the error is 1198 reported to the PCE. The PCC will not attempt to resignal the path 1199 until it is prompted again by the PCE with a subsequent PCUpd 1200 message. 1202 A PCC MUST respond with an LSP State Report to each LSP Update 1203 Request it processed to indicate the resulting state of the LSP in 1204 the network (even if this processing did not result in changing the 1205 state of the LSP). The SRP-ID-number included in the PCRpt MUST 1206 match that in the PCUpd. A PCC MAY respond with multiple LSP State 1207 Reports to report LSP setup progress of a single LSP. In that case, 1208 the SRP-ID-number MUST be included for the first message, for 1209 subsequent messages the reserved value 0x00000000 SHOULD be used. 1211 Note that a PCC MUST process all LSP Update Requests - for example, 1212 an LSP Update Request is sent when a PCE returns delegation or puts 1213 an LSP into non-operational state. The protocol relies on TCP for 1214 message-level flow control. 1216 If the rate of PCUpd messages sent to a PCC for the same target LSP 1217 exceeds the rate at which the PCC can signal LSPs into the network, 1218 the PCC MAY perform state compression on its ingress queue. The 1219 compression algorithm is based on the fact that each PCUpd request 1220 contains the complete LSP state the PCE wishes to be set and works as 1221 follows: when the PCC starts processing a PCUpd message at the head 1222 of its ingress queue, it may search the queue forward for more recent 1223 PCUpd messages pertaining that particular LSP, prune all but the 1224 latest one from the queue and process only the last one as that 1225 request contains the most up-to-date desired state for the LSP. The 1226 PCC MUST NOT send PCRpt nor PCErr messages for requests which were 1227 pruned from the queue in this way. This compression step may be 1228 performed only while the LSP is not being signaled, e.g. if two PCUpd 1229 arrive for the same LSP in quick succession and the PCC started the 1230 signaling of the changes relevant to the first PCUpd, then it MUST 1231 wait until the signaling finishes (and report the new state via a 1232 PCRpt) before attempting to apply the changes indicated in the second 1233 PCUpd. 1235 Note also that it is up to the PCE to handle inter-LSP dependencies; 1236 for example, if ordering of LSP set-ups is required, the PCE has to 1237 wait for an LSP State Report for a previous LSP before starting the 1238 update of the next LSP. 1240 If the PCUpd cannot be satisfied (for example due to unsupported 1241 object or TLV), the PCC MUST respond with a PCErr message indicating 1242 the failure (see Section 7.3.3). 1244 6.3. The PCErr Message 1246 If the stateful PCE capability has been advertised on the PCEP 1247 session, the PCErr message MAY include the SRP object. If the error 1248 reported is the result of an LSP update request, then the SRP-ID- 1249 number MUST be the one from the PCUpd that triggered the error. If 1250 the error is unsolicited, the SRP object MAY be omitted. This is 1251 equivalent to including an SRP object with SRP-ID-number equal to the 1252 reserved value 0x00000000. 1254 The format of a PCErr message from [RFC5440] is extended as follows: 1256 ::= 1257 ( [] ) | 1258 [] 1260 ::=[] 1262 ::=[ | ] 1263 1265 ::=[] 1267 ::=[] 1269 ::=[] 1271 6.4. The PCReq Message 1273 A PCC MAY include the LSP object in the PCReq message (see 1274 Section 7.3) if the stateful PCE capability has been negotiated on a 1275 PCEP session between the PCC and a PCE. 1277 The definition of the PCReq message from [RFC5440] is extended to 1278 optionally include the LSP object after the END-POINTS object. The 1279 encoding from [RFC5440] will become: 1281 ::= 1282 [] 1283 1285 Where: 1287 ::=[] 1288 ::=[] 1290 ::= 1291 1292 [] 1293 [] 1294 [] 1295 [] 1296 [[]] 1297 [] 1298 [] 1300 6.5. The PCRep Message 1302 A PCE MAY include the LSP object in the PCRep message (see 1303 (Section 7.3) if the stateful PCE capability has been negotiated on a 1304 PCEP session between the PCC and the PCE and the LSP object was 1305 included in the corresponding PCReq message from the PCC. 1307 The definition of the PCRep message from [RFC5440] is extended to 1308 optionally include the LSP object after the RP object. The encoding 1309 from [RFC5440] will become: 1311 ::= 1312 1314 Where: 1316 ::=[] 1318 ::= 1319 [] 1320 [] 1321 [] 1322 [] 1324 7. Object Formats 1326 The PCEP objects defined in this document are compliant with the PCEP 1327 object format defined in [RFC5440]. The P flag and the I flag of the 1328 PCEP objects defined in the current document MUST be set to 0 on 1329 transmission and SHOULD be ignored on receipt since the P and I flags 1330 are exclusively related to path computation requests. 1332 7.1. OPEN Object 1334 This document defines one new optional TLVs for use in the OPEN 1335 Object. 1337 7.1.1. Stateful PCE Capability TLV 1339 The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the 1340 OPEN Object for stateful PCE capability advertisement. Its format is 1341 shown in the following figure: 1343 0 1 2 3 1344 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 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | Type=[TBD] | Length=4 | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Flags |U| 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 Figure 9: STATEFUL-PCE-CAPABILITY TLV format 1353 The type (16 bits) of the TLV is to be assigned by IANA. The length 1354 field is 16 bit-long and has a fixed value of 4. 1356 The value comprises a single field - Flags (32 bits): 1358 U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag 1359 indicates that the PCC allows modification of LSP parameters; if 1360 set to 1 by a PCE, the U Flag indicates that the PCE is capable of 1361 updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be 1362 advertised by both a PCC and a PCE for PCUpd messages to be 1363 allowed on a PCEP session. 1365 Unassigned bits are considered reserved. They MUST be set to 0 on 1366 transmission and MUST be ignored on receipt. 1368 Advertisement of the stateful PCE capability implies support of LSPs 1369 that are signaled via RSVP, as well as the objects, TLVs and 1370 procedures defined in this document. 1372 7.2. SRP Object 1374 The SRP (Stateful PCE Request Parameters) object MUST be carried 1375 within PCUpd messages and MAY be carried within PCRpt and PCErr 1376 messages. The SRP object is used to correlate between update 1377 requests sent by the PCE and the error reports and state reports sent 1378 by the PCC. 1380 SRP Object-Class is to be assigned by IANA. 1382 SRP Object-Type is 1. 1384 The format of the SRP object body is shown in Figure 10: 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 | Flags | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | SRP-ID-number | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | | 1394 // Optional TLVs // 1395 | | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 Figure 10: The SRP Object format 1400 The SRP object body has a variable length and may contain additional 1401 TLVs. The SYMBOLIC-PATH-NAME TLV MAY be included as one of the 1402 optional TLVs. 1404 Flags (32 bits): None defined yet. 1406 SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the 1407 current PCEP session uniquely identify the operation that the PCE has 1408 requested the PCC to perform on a given LSP. The SRP-ID-number is 1409 incremented each time a new request is sent to the PCC, and may wrap 1410 around. 1412 The values 0x00000000 and 0xFFFFFFFF are reserved. 1414 Every request to update an LSP receives a new SRP-ID-number. This 1415 number is unique per PCEP session and is incremented each time an 1416 operation is requested from the PCE. Thus, for a given LSP there may 1417 be more than one SRP-ID-number unacknowledged at a given time. The 1418 value of the SRP-ID-number is echoed back by the PCC in PCErr and 1419 PCRpt messages to allow for correlation between requests made by the 1420 PCE and errors or state reports generated by the PCC. If the error 1421 or report were not as a result of a PCE operation (for example in the 1422 case of a link down event), the reserved value of 0x00000000 is used 1423 for the SRP-ID-number. The absence of the SRP object is equivalent 1424 to an SRP object with the reserved value of 0x00000000. An SRP-ID- 1425 number is considered unacknowledged and cannot be reused until a 1426 PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the 1427 same LSP. In case of SRP-ID-number wrapping the last SRP-ID-number 1428 before the wrapping MUST be explicitly acknowledged, to avoid a 1429 situation where SRP-ID-numbers remain unacknowledged after the wrap. 1430 This means that the PCC may need to issue two PCUpd messages on 1431 detecting a wrap. 1433 7.3. LSP Object 1435 The LSP object MUST be present within PCRpt and PCUpd messages. The 1436 LSP object MAY be carried within PCReq and PCRep messages if the 1437 stateful PCE capability has been negotiated on the session. The LSP 1438 object contains a set of fields used to specify the target LSP, the 1439 operation to be performed on the LSP, and LSP Delegation. It also 1440 contains a flag indicating to a PCE that the LSP state 1441 synchronization is in progress. This document focuses on LSPs that 1442 are signaled with RSVP, many of the TLVs used with the LSP object 1443 mirror RSVP state. 1445 LSP Object-Class is to be assigned by IANA. 1447 LSP Object-Type is 1. 1449 The format of the LSP object body is shown in Figure 11: 1451 0 1 2 3 1452 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 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | PLSP-ID | Flag | O|A|R|S|D| 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 // TLVs // 1457 | | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 Figure 11: The LSP Object format 1462 PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC 1463 creates a unique PLSP-ID for each LSP that is constant for the 1464 lifetime of a PCEP session. The PCC will advertise the same PLSP-ID 1465 on all PCEP sessions it maintains at a given times. The mapping of 1466 the Symbolic Path Name to PLSP-ID is communicated to the PCE by 1467 sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All 1468 subsequent PCEP messages then address the LSP by the PLSP-ID. The 1469 values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a 1470 value that is constant for the lifetime of the PCEP session, during 1471 which time for an RSVP-signaled LSP there might be a different RSVP 1472 identifiers (LSP-id, tunnel-id) allocated to it. 1474 Flags (12 bits), starting from the least significant bit: 1476 D (Delegate - 1 bit): On a PCRpt message, the D Flag set to 1 1477 indicates that the PCC is delegating the LSP to the PCE. On a 1478 PCUpd message, the D flag set to 1 indicates that the PCE is 1479 confirming the LSP Delegation. To keep an LSP delegated to the 1480 PCE, the PCC must set the D flag to 1 on each PCRpt message for 1481 the duration of the delegation - the first PCRpt with the D flag 1482 set to 0 revokes the delegation. To keep the delegation, the PCE 1483 must set the D flag to 1 on each PCUpd message for the duration of 1484 the delegation - the first PCUpd with the D flag set to 0 returns 1485 the delegation. 1487 S (SYNC - 1 bit): The S Flag MUST be set to 1 on each PCRpt sent 1488 from a PCC during State Synchronization. The S Flag MUST be set 1489 to 0 in other messages sent from the PCC. 1491 R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1492 LSP has been removed from the PCC and the PCE SHOULD remove all 1493 state from its database. Upon receiving an LSP State Report with 1494 the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD 1495 remove all state for the path identified by the LSP-IDENTIFIERS 1496 TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is 1497 used, the PCE SHOULD remove all state for the PLSP-ID from its 1498 database. 1500 A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates 1501 the PCC's target operational status for this LSP. On PCUpd 1502 messages, the A Flag indicates the LSP status that the PCE desires 1503 for this LSP. In both cases, a value of '1' means that the 1504 desired operational state is active, and a value of '0' means that 1505 the desired operational state is inactive. A PCC ignores the A 1506 flag on a PCUpd message unless the operator's policy allows the 1507 PCE to control the corresponding LSP's administrative state. 1509 O(Operational - 3 bits): On PCRpt messages, the O Field represents 1510 the operational status of the LSP. 1512 The following values are defined: 1514 0 - DOWN: not active. 1516 1 - UP: signalled. 1518 2 - ACTIVE: up and carrying traffic. 1520 3 - GOING-DOWN: LSP is being torn down, resources are being 1521 released. 1523 4 - GOING-UP: LSP is being signalled. 1525 5-7 - Reserved: these values are reserved for future use. 1527 Unassigned bits are considered reserved. They MUST be set to 0 on 1528 transmission and MUST be ignored on receipt. 1530 TLVs that may be included in the LSP Object are described in the 1531 following sections. 1533 7.3.1. LSP-IDENTIFIERS TLVs 1535 The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt 1536 messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will 1537 generate an error with error-type 6 (mandatory object missing) and 1538 error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. 1539 The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd 1540 messages for RSVP-signaled LSPs. The special value of all zeros for 1541 this TLV is used to refer to all paths pertaining to a particular 1542 PLSP-ID. There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one 1543 for IPv6. 1545 It is the responsibility of the PCC to send to the PCE the 1546 identifiers for each RSVP incarnation of the tunnel. For example, in 1547 a make-before-break scenario, the PCC MUST send a separate PCRpt for 1548 the old and for the reoptimized paths, and explicitly report removal 1549 of any of these paths using the R bit in the LSP object. 1551 The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 1552 figure: 1554 0 1 2 3 1555 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 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Type=[TBD] | Length=16 | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | IPv4 Tunnel Sender Address | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | LSP ID | Tunnel ID | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | Extended Tunnel ID | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | IPv4 Tunnel Endpoint Address | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 Figure 12: IPV4-LSP-IDENTIFIERS TLV format 1570 The type (16 bits) of the TLV is to be assigned by IANA. The length 1571 field is 16 bit-long and has a fixed value of 16. The value contains 1572 the following fields: 1574 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 1575 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 1576 Sender Template Object. 1578 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1579 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 1580 Object. A value of 0 MUST be used if the LSP is not yet signaled. 1582 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1583 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 1585 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 1586 identifier defined in [RFC3209], Section 4.6.1.1 for the 1587 LSP_TUNNEL_IPv4 Session Object. 1589 IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 1590 address, as defined in [RFC3209], Section 4.6.1.1 for the 1591 LSP_TUNNEL_IPv4 Sender Template Object. 1593 The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following 1594 figure: 1596 0 1 2 3 1597 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 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Type=[TBD] | Length=52 | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | | 1602 + + 1603 | IPv6 tunnel sender address | 1604 + (16 octets) + 1605 | | 1606 + + 1607 | | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | LSP ID | Tunnel ID | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | | 1612 + + 1613 | Extended Tunnel ID | 1614 + (16 octets) + 1615 | | 1616 + + 1617 | | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 | | 1620 + + 1621 | IPv6 tunnel endpoint address | 1622 + (16 octets) + 1623 | | 1624 + + 1625 | | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 Figure 13: IPV6-LSP-IDENTIFIERS TLV format 1630 The type (16 bits) of the TLV is to be assigned by IANA. The length 1631 field is 16 bit-long and has a fixed value of 52. The value contains 1632 the following fields: 1634 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 1635 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 1636 Sender Template Object. 1638 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1639 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 1640 Object. A value of 0 MUST be used if the LSP is not yet signaled. 1642 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1643 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 1645 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 1646 identifier defined in [RFC3209], Section 4.6.1.2 for the 1647 LSP_TUNNEL_IPv6 Session Object. 1649 IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 1650 address, as defined in [RFC3209], Section 4.6.1.2 for the 1651 LSP_TUNNEL_IPv6 Session Object. 1653 The Tunnel ID remains constant over the life time of a tunnel. 1655 7.3.2. Symbolic Path Name TLV 1657 Each LSP (path) MUST have a symbolic name that is unique in the PCC. 1658 This symbolic path name MUST remain constant throughout an LSP's 1659 lifetime, which may span across multiple consecutive PCEP sessions 1660 and/or PCC restarts. The symbolic path name MAY be specified by an 1661 operator in a PCC's configuration. If the operator does not specify 1662 a unique symbolic name for a path, the PCC MUST auto-generate one. 1664 The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the 1665 LSP State Report (PCRpt) message when during a given PCEP session an 1666 LSP is first reported to a PCE. A PCC sends to a PCE the first LSP 1667 State Report either during State Synchronization, or when a new LSP 1668 is configured at the PCC. The symbolic path name MAY be included in 1669 the LSP object in subsequent LSP State Reports for the LSP. 1671 The format of the SYMBOLIC-PATH-NAME TLV is shown in the following 1672 figure: 1674 0 1 2 3 1675 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 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Type=[TBD] | Length (variable) | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | | 1680 // Symbolic Path Name // 1681 | | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 Figure 14: SYMBOLIC-PATH-NAME TLV format 1686 Type (16 bits): to be assigned by IANA. 1688 Length (16 bits): indicates the total length of the TLV in octets and 1689 MUST be greater than 0. The TLV MUST be zero-padded so that the TLV 1690 is 4-octet aligned. 1692 Symbolic Path Name (variable): symbolic name for the LSP, unique in 1693 the PCC. 1695 7.3.3. LSP Error Code TLV 1697 The LSP Error code TLV is an optional TLV for use in the LSP object 1698 to convey error information. When an LSP Update Request fails, an 1699 LSP State Report MUST be sent to report the current state of the LSP, 1700 and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for 1701 the failure. Similarly, when a PCRpt is sent as a result of an LSP 1702 transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD 1703 be included to indicate the reason for the transition. 1705 The format of the LSP-ERROR-CODE TLV is shown in the following 1706 figure: 1708 0 1 2 3 1709 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 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Type=[TBD] | Length=4 | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | LSP Error Code | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 Figure 15: LSP-ERROR-CODE TLV format 1718 The type (16 bits) of the TLV is to be assigned by IANA. The length 1719 field is 16 bit-long and has a fixed value of 4. The value contains 1720 an error code that indicates the cause of the failure. 1722 The following LSP Error Codes are currently defined: 1724 Value Meaning 1725 1 Unknown reason 1726 2 Limit reached for PCE-controlled LSPs 1727 3 Too many pending LSP update requests 1728 4 Unacceptable parameters 1729 5 Internal error 1730 6 LSP administratively brought down 1731 7 LSP preempted 1732 8 RSVP signaling error 1734 7.3.4. RSVP Error Spec TLV 1736 The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object 1737 to carry RSVP error information. It includes the RSVP ERROR_SPEC or 1738 USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned 1739 to the PCC from a downstream node. If the set up of an LSP fails at 1740 a downstream node which returned an ERROR_SPEC to the PCC, the PCC 1741 SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with 1742 LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV 1743 with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object. 1745 The format of the RSVP-ERROR-SPEC TLV is shown in the following 1746 figure: 1748 0 1 2 3 1749 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 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | Type=[TBD] | Length (variable) | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | | 1754 + RSVP ERROR_SPEC or USER_ERROR_SPEC Object + 1755 | | 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 Figure 16: RSVP-ERROR-SPEC TLV format 1760 Type (16 bits):to be assigned by IANA. 1762 Length (16 bits): indicates the total length of the TLV in octets. 1763 The TLV MUST be zero-padded so that the TLV is 4-octet aligned. 1765 Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC 1766 Object: as specified in [RFC2205] and [RFC5284], including the object 1767 header. 1769 8. IANA Considerations 1771 This document requests IANA actions to allocate code points for the 1772 protocol elements defined in this document. Values shown here are 1773 suggested for use by IANA. 1775 8.1. PCE Capabilities in IGP Advertisements 1777 IANA is requested to allocate new bits in "PCE Capability Flags" 1778 registry for stateful PCE capability as follows: 1780 Bit Meaning Reference 1781 11 Active Stateful PCE This document 1782 capability 1783 12 Passive Stateful PCE This document 1784 capability 1786 8.2. PCEP Messages 1788 This document defines the following new PCEP messages: 1790 Value Meaning Reference 1791 10 Report This document 1792 11 Update This document 1794 8.3. PCEP Objects 1796 This document defines the following new PCEP Object-classes and 1797 Object-values: 1799 Object-Class Value Name Reference 1801 32 LSP This document 1802 Object-Type 1803 1 1804 33 SRP This document 1805 Object-Type 1806 1 1808 8.4. LSP Object 1810 This document requests that a new sub-registry, named "LSP Object 1811 Flag Field", is created within the "Path Computation Element Protocol 1812 (PCEP) Numbers" registry to manage the Flag field of the LSP 1813 object.New values are to be assigned by Standards Action [RFC5226]. 1814 Each bit should be tracked with the following qualities: 1816 o Bit number (counting from bit 0 as the most significant bit) 1818 o Capability description 1820 o Defining RFC 1822 The following values are defined in this document: 1824 Bit Description Reference 1826 0-4 Reserved This document 1827 5-7 Operational (3 bits) This document 1828 8 Administrative This document 1829 9 Remove This document 1830 10 SYNC This document 1831 11 Delegate This document 1833 8.5. PCEP-Error Object 1835 This document defines new Error-Type and Error-Value for the 1836 following new error conditions: 1838 Error-Type Meaning 1839 6 Mandatory Object missing 1841 Error-value=8: LSP Object missing 1842 Error-value=9: ERO Object missing 1843 Error-value=10: SRP Object missing 1844 Error-value=11: LSP-IDENTIFIERS TLV missing 1845 19 Invalid Operation 1847 Error-value=1: Attempted LSP Update Request for a non- 1848 delegated LSP. The PCEP-ERROR Object 1849 is followed by the LSP Object that 1850 identifies the LSP. 1851 Error-value=2: Attempted LSP Update Request if the 1852 stateful PCE capability was not 1853 advertised. 1854 Error-value=3: Attempted LSP Update Request for an LSP 1855 identified by an unknown PLSP-ID. 1856 Error-value=5: Attempted LSP State Report if active 1857 stateful PCE capability was not 1858 advertised. 1859 20 LSP State synchronization error. 1861 Error-value=1: A PCE indicates to a PCC that it can 1862 not process (an otherwise valid) LSP 1863 State Report. The PCEP-ERROR Object is 1864 followed by the LSP Object that 1865 identifies the LSP. 1866 Error-value=5: A PCC indicates to a PCE that it can 1867 not complete the state synchronization, 1869 8.6. Notification Object 1871 IANA is requested to allocate new Notification Types and Notification 1872 Values in the "PCEP Notification Object" registry as follows: 1874 Notification-Type Meaning 1875 4 Stateful PCE resource limit exceeded 1877 Notification-value=1: Entering resource limit 1878 exceeded state 1880 Notification-value=2: Exiting resource limit exceeded 1881 state 1883 8.7. PCEP TLV Type Indicators 1885 This document defines the following new PCEP TLVs: 1887 Value Meaning Reference 1888 16 STATEFUL-PCE-CAPABILITY This document 1889 17 SYMBOLIC-PATH-NAME This document 1890 18 IPV4-LSP-IDENTIFIERS This document 1891 19 IPV6-LSP-IDENTIFIERS This document 1892 20 LSP-ERROR-CODE This document 1893 21 RSVP-ERROR-SPEC This document 1895 8.8. STATEFUL-PCE-CAPABILITY TLV 1897 This document requests that a new sub-registry, named "STATEFUL-PCE- 1898 CAPABILITY TLV Flag Field", is created within the "Path Computation 1899 Element Protocol (PCEP) Numbers" registry to manage the Flag field in 1900 the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = 1). 1901 New values are to be assigned by Standards Action [RFC5226]. Each 1902 bit should be tracked with the following qualities: 1904 o Bit number (counting from bit 0 as the most significant bit) 1906 o Capability description 1908 o Defining RFC 1910 The following values are defined in this document: 1912 Bit Description Reference 1914 31 LSP-UPDATE-CAPABILITY This document 1916 8.9. LSP-ERROR-CODE TLV 1918 This document requests that a new sub-registry, named "LSP-ERROR-CODE 1919 TLV Error Code Field", is created within the "Path Computation 1920 Element Protocol (PCEP) Numbers" registry to manage the LSP Error 1921 code field of the LSP-ERROR-CODE TLV. This field specifies the 1922 reason for failure to update the LSP. 1924 Value Meaning 1925 1 Unknown reason 1926 2 Limit reached for PCE-controlled LSPs 1927 3 Too many pending LSP update requests 1928 4 Unacceptable parameters 1929 5 Internal error 1930 6 LSP administratively brought down 1931 7 LSP preempted 1932 8 RSVP signaling error 1934 9. Manageability Considerations 1936 All manageability requirements and considerations listed in [RFC5440] 1937 apply to PCEP extensions defined in this document. In addition, 1938 requirements and considerations listed in this section apply. 1940 9.1. Control Function and Policy 1942 In addition to configuring specific PCEP session parameters, as 1943 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 1944 allow configuring the stateful PCEP capability and the LSP Update 1945 capability. A PCC implementation SHOULD allow the operator to 1946 specify multiple candidate PCEs for and a delegation preference for 1947 each candidate PCE. A PCC SHOULD allow the operator to specify an 1948 LSP delegation policy where LSPs are delegated to the most-preferred 1949 online PCE. A PCC MAY allow the operator to specify different LSP 1950 delegation policies. 1952 A PCC implementation which allows concurrent connections to multiple 1953 PCEs SHOULD allow the operator to group the PCEs by administrative 1954 domains and it MUST NOT advertise LSP existence and state to a PCE if 1955 the LSP is delegated to a PCE in a different group. 1957 A PCC implementation SHOULD allow the operator to specify whether the 1958 PCC will advertise LSP existence and state for LSPs that are not 1959 controlled by any PCE (for example, LSPs that are statically 1960 configured at the PCC). 1962 A PCC implementation SHOULD allow the operator to specify both the 1963 Redelegation Timeout Interval and the State Timeout Interval. The 1964 default value of the Redelegation Timeout Interval SHOULD be set to 1965 30 seconds. An operator MAY also configure a policy that will 1966 dynamically adjust the Redelegation Timeout Interval, for example 1967 setting it to zero when the PCC has an established session to a 1968 backup PCE. The default value for the State Timeout Interval SHOULD 1969 be set to 60 seconds. 1971 After the expiration of the State Timeout Interval, the LSP reverts 1972 to operator-defined default parameters. A PCC implementation MUST 1973 allow the operator to specify the default LSP parameters. To achieve 1974 a behavior where the LSP retains the parameters set by the PCE until 1975 such time that the PCC makes a change to them, a State Timeout 1976 Interval of infinity SHOULD be used. Any changes to LSP parameters 1977 SHOULD be done in make-before-break fashion. 1979 LSP Delegation is controlled by operator-defined policies on a PCC. 1980 LSPs are delegated individually - different LSPs may be delegated to 1981 different PCEs. An LSP is delegated to at most one PCE at any given 1982 point in time. A PCC implementation SHOULD support the delegation 1983 policy, when all PCC's LSPs are delegated to a single PCE at any 1984 given time. Conversely, the policy revoking the delegation for all 1985 PCC's LSPs SHOULD also be supported. 1987 A PCC implementation SHOULD allow the operator to specify delegation 1988 priority for PCEs. This effectively defines the primary PCE and one 1989 or more backup PCEs to which primary PCE's LSPs can be delegated when 1990 the primary PCE fails. 1992 Policies defined for stateful PCEs and PCCs should eventually fit in 1993 the Policy-Enabled Path Computation Framework defined in [RFC5394], 1994 and the framework should be extended to support Stateful PCEs. 1996 9.2. Information and Data Models 1998 PCEP session configuration and information in the PCEP MIB module 1999 SHOULD be extended to include advertised stateful capabilities, 2000 synchronization status, and delegation status (at the PCC list PCEs 2001 with delegated LSPs). 2003 9.3. Liveness Detection and Monitoring 2005 PCEP extensions defined in this document do not require any new 2006 mechanisms beyond those already defined in [RFC5440], Section 8.3. 2008 9.4. Verifying Correct Operation 2010 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 2011 extensions defined in this document. In addition to monitoring 2012 parameters defined in [RFC5440], a stateful PCC-side PCEP 2013 implementation SHOULD provide the following parameters: 2015 o Total number of LSP updates 2017 o Number of successful LSP updates 2018 o Number of dropped LSP updates 2020 o Number of LSP updates where LSP setup failed 2022 A PCC implementation SHOULD provide a command to show for each LSP 2023 whether it is delegated, and if so, to which PCE. 2025 A PCC implementation SHOULD allow the operator to manually revoke LSP 2026 delegation. 2028 9.5. Requirements on Other Protocols and Functional Components 2030 PCEP extensions defined in this document do not put new requirements 2031 on other protocols. 2033 9.6. Impact on Network Operation 2035 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 2036 extensions defined in this document. 2038 Additionally, a PCEP implementation SHOULD allow a limit to be placed 2039 on the number of LSPs delegated to the PCE and on the rate of PCUpd 2040 and PCRpt messages sent by a PCEP speaker and processed from a peer. 2041 It SHOULD also allow sending a notification when a rate threshold is 2042 reached. 2044 A PCC implementation SHOULD allow a limit to be placed on the rate of 2045 LSP Updates to the same LSP to avoid signaling overload discussed in 2046 Section 10.3. 2048 10. Security Considerations 2050 10.1. Vulnerability 2052 This document defines extensions to PCEP to enable stateful PCEs. 2053 The nature of these extensions and the delegation of path control to 2054 PCEs results in more information being available for a hypothetical 2055 adversary and a number of additional attack surfaces which must be 2056 protected. 2058 The security provisions described in [RFC5440] remain applicable to 2059 these extensions. However, because the protocol modifications 2060 outlined in this document allow the PCE to control path computation 2061 timing and sequence, the PCE defense mechanisms described in 2062 [RFC5440] section 7.2 are also now applicable to PCC security. 2064 As a general precaution, it is RECOMMENDED that these PCEP extensions 2065 only be activated on authenticated and encrypted sessions across PCEs 2066 and PCCs belonging to the same administrative authority. 2068 The following sections identify specific security concerns that may 2069 result from the PCEP extensions outlined in this document along with 2070 recommended mechanisms to protect PCEP infrastructure against related 2071 attacks. 2073 10.2. LSP State Snooping 2075 The stateful nature of this extension explicitly requires LSP status 2076 updates to be sent from PCC to PCE. While this gives the PCE the 2077 ability to provide more optimal computations to the PCC, it also 2078 provides an adversary with the opportunity to eavesdrop on decisions 2079 made by network systems external to PCE. This is especially true if 2080 the PCC delegates LSPs to multiple PCEs simultaneously. 2082 Adversaries may gain access to this information by eavesdropping on 2083 unsecured PCEP sessions, and might then use this information in 2084 various ways to target or optimize attacks on network infrastructure. 2085 For example by flexibly countering anti-DDoS measures being taken to 2086 protect the network, or by determining choke points in the network 2087 where the greatest harm might be caused. 2089 PCC implementations which allow concurrent connections to multiple 2090 PCEs SHOULD allow the operator to group the PCEs by administrative 2091 domains and they MUST NOT advertise LSP existence and state to a PCE 2092 if the LSP is delegated to a PCE in a different group. 2094 10.3. Malicious PCE 2096 The LSP delegation mechanism described in this document allows a PCC 2097 to grant effective control of an LSP to the PCE for the duration of a 2098 PCEP session. While this enables PCE control of the timing and 2099 sequence of path computations within and across PCEP sessions, it 2100 also introduces a new attack vector: an attacker may flood the PCC 2101 with PCUpd messages at a rate which exceeds either the PCC's ability 2102 to process them or the network's ability to signal the changes, 2103 either by spoofing messages or by compromising the PCE itself. 2105 A PCC is free to revoke an LSP delegation at any time without needing 2106 any justification. A defending PCC can do this by enqueueing the 2107 appropriate PCRpt message. As soon as that message is enqueued in 2108 the session, the PCC is free to drop any incoming PCUpd messages 2109 without additional processing. 2111 10.4. Malicious PCC 2113 A stateful session also results in an increased attack surface by 2114 placing a requirement for the PCE to keep an LSP state replica for 2115 each PCC. It is RECOMMENDED that PCE implementations provide a limit 2116 on resources a single PCC can occupy. A PCE implementing such a 2117 limit MUST send a PCNtf message with notification-type to be assigned 2118 by IANA (Stateful PCE resource limit exceeded) and notification-value 2119 to be assigned by IANA (Entering resource limit exceeded state) upon 2120 receiving an LSP state report causing it to exceed this threshold. 2122 Delegation of LSPs can create further strain on PCE resources and a 2123 PCE implementation MAY preemptively give back delegations if it finds 2124 itself lacking the resources needed to effectively manage the 2125 delegation. Since the delegation state is ultimately controlled by 2126 the PCC, PCE implementations SHOULD provide throttling mechanisms to 2127 prevent strain created by flaps of either a PCEP session or an LSP 2128 delegation. 2130 11. Contributing Authors 2132 Xian Zhang 2133 Huawei Technology 2134 F3-5-B R&D Center 2135 Huawei Industrial Base, Bantian, Longgang District 2136 Shenzhen, Guangdong 518129 2137 P.R.China 2138 EMail: zhang.xian@huawei.com 2140 Dhruv Dhody 2141 Huawei Technology 2142 Leela Palace 2143 Bangalore, Karnataka 560008 2144 INDIA 2145 EMail: dhruv.dhody@huawei.com 2147 Siva Sivabalan 2148 Cisco Systems, Inc. 2149 2000 Innovation Drive 2150 Kanata, Ontario K2K 3E8 2151 Canada 2152 EMail: msiva@cisco.com 2154 12. Acknowledgements 2156 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 2157 Casellas for their contributions to this document. 2159 We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, 2160 Paul Schultz and Raveendra Torvi for their comments and suggestions. 2161 Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga, 2162 Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, 2163 Ambrose Kwong, Ashwin Sampath and Calvin Ying for helpful comments 2164 and discussions. 2166 13. References 2168 13.1. Normative References 2170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2171 Requirement Levels", BCP 14, RFC 2119, 2172 DOI 10.17487/RFC2119, March 1997, 2173 . 2175 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2176 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2177 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2178 September 1997, . 2180 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2181 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2182 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2183 . 2185 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 2186 Zhang, "OSPF Protocol Extensions for Path Computation 2187 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 2188 January 2008, . 2190 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 2191 Zhang, "IS-IS Protocol Extensions for Path Computation 2192 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 2193 January 2008, . 2195 [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", 2196 RFC 5284, DOI 10.17487/RFC5284, August 2008, 2197 . 2199 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 2200 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 2201 DOI 10.17487/RFC5440, March 2009, 2202 . 2204 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2205 Used to Form Encoding Rules in Various Routing Protocol 2206 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2207 2009, . 2209 13.2. Informative References 2211 [I-D.ietf-pce-gmpls-pcep-extensions] 2212 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 2213 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in 2214 progress), October 2015. 2216 [I-D.ietf-pce-stateful-pce-app] 2217 Zhang, X. and I. Minei, "Applicability of a Stateful Path 2218 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 2219 app-05 (work in progress), October 2015. 2221 [I-D.ietf-pce-stateful-sync-optimizations] 2222 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 2223 and D. Dhody, "Optimizations of Label Switched Path State 2224 Synchronization Procedures for a Stateful PCE", draft- 2225 ietf-pce-stateful-sync-optimizations-04 (work in 2226 progress), November 2015. 2228 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2229 LSP Path Computation using Preemption", Global 2230 Information Infrastructure Symposium, July 2007. 2232 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2233 programming algorithm for balancing the max-min fairness 2234 and throughput objectives in traffic engineering", 2235 INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012. 2237 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2238 McManus, "Requirements for Traffic Engineering Over MPLS", 2239 RFC 2702, DOI 10.17487/RFC2702, September 1999, 2240 . 2242 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2243 Label Switching Architecture", RFC 3031, 2244 DOI 10.17487/RFC3031, January 2001, 2245 . 2247 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2248 Christian, B., and W. Lai, "Applicability Statement for 2249 Traffic Engineering with MPLS", RFC 3346, 2250 DOI 10.17487/RFC3346, August 2002, 2251 . 2253 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2254 (TE) Extensions to OSPF Version 2", RFC 3630, 2255 DOI 10.17487/RFC3630, September 2003, 2256 . 2258 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2259 Element (PCE)-Based Architecture", RFC 4655, 2260 DOI 10.17487/RFC4655, August 2006, 2261 . 2263 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 2264 Element (PCE) Communication Protocol Generic 2265 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2266 2006, . 2268 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2269 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2270 DOI 10.17487/RFC5226, May 2008, 2271 . 2273 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2274 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2275 2008, . 2277 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2278 "Policy-Enabled Path Computation Framework", RFC 5394, 2279 DOI 10.17487/RFC5394, December 2008, 2280 . 2282 Authors' Addresses 2284 Edward Crabbe 2285 Individual Contributor 2287 Email: edward.crabbe@gmail.com 2289 Ina Minei 2290 Google, Inc. 2291 1600 Amphitheatre Parkway 2292 Mountain View, CA 94043 2293 US 2295 Email: inaminei@google.com 2296 Jan Medved 2297 Cisco Systems, Inc. 2298 170 West Tasman Dr. 2299 San Jose, CA 95134 2300 US 2302 Email: jmedved@cisco.com 2304 Robert Varga 2305 Pantheon Technologies SRO 2306 Mlynske Nivy 56 2307 Bratislava 821 05 2308 Slovakia 2310 Email: robert.varga@pantheon.sk