idnits 2.17.1 draft-ietf-pce-stateful-pce-15.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 (July 18, 2016) is 2838 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-06 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-05 -- 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: January 19, 2017 Google, Inc. 6 J. Medved 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 July 18, 2016 12 PCEP Extensions for Stateful PCE 13 draft-ietf-pce-stateful-pce-15 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 January 19, 2017. 44 Copyright Notice 46 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . 48 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. 1403 Flags (32 bits): None defined yet. 1405 SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the 1406 current PCEP session uniquely identify the operation that the PCE has 1407 requested the PCC to perform on a given LSP. The SRP-ID-number is 1408 incremented each time a new request is sent to the PCC, and may wrap 1409 around. 1411 The values 0x00000000 and 0xFFFFFFFF are reserved. 1413 Every request to update an LSP receives a new SRP-ID-number. This 1414 number is unique per PCEP session and is incremented each time an 1415 operation is requested from the PCE. Thus, for a given LSP there may 1416 be more than one SRP-ID-number unacknowledged at a given time. The 1417 value of the SRP-ID-number is echoed back by the PCC in PCErr and 1418 PCRpt messages to allow for correlation between requests made by the 1419 PCE and errors or state reports generated by the PCC. If the error 1420 or report were not as a result of a PCE operation (for example in the 1421 case of a link down event), the reserved value of 0x00000000 is used 1422 for the SRP-ID-number. The absence of the SRP object is equivalent 1423 to an SRP object with the reserved value of 0x00000000. An SRP-ID- 1424 number is considered unacknowledged and cannot be reused until a 1425 PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the 1426 same LSP. In case of SRP-ID-number wrapping the last SRP-ID-number 1427 before the wrapping MUST be explicitly acknowledged, to avoid a 1428 situation where SRP-ID-numbers remain unacknowledged after the wrap. 1429 This means that the PCC may need to issue two PCUpd messages on 1430 detecting a wrap. 1432 7.3. LSP Object 1434 The LSP object MUST be present within PCRpt and PCUpd messages. The 1435 LSP object MAY be carried within PCReq and PCRep messages if the 1436 stateful PCE capability has been negotiated on the session. The LSP 1437 object contains a set of fields used to specify the target LSP, the 1438 operation to be performed on the LSP, and LSP Delegation. It also 1439 contains a flag indicating to a PCE that the LSP state 1440 synchronization is in progress. This document focuses on LSPs that 1441 are signaled with RSVP, many of the TLVs used with the LSP object 1442 mirror RSVP state. 1444 LSP Object-Class is to be assigned by IANA. 1446 LSP Object-Type is 1. 1448 The format of the LSP object body is shown in Figure 11: 1450 0 1 2 3 1451 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 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | PLSP-ID | Flag | O|A|R|S|D| 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 // TLVs // 1456 | | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 Figure 11: The LSP Object format 1461 PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC 1462 creates a unique PLSP-ID for each LSP that is constant for the 1463 lifetime of a PCEP session. The PCC will advertise the same PLSP-ID 1464 on all PCEP sessions it maintains at a given times. The mapping of 1465 the Symbolic Path Name to PLSP-ID is communicated to the PCE by 1466 sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All 1467 subsequent PCEP messages then address the LSP by the PLSP-ID. The 1468 values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a 1469 value that is constant for the lifetime of the PCEP session, during 1470 which time for an RSVP-signaled LSP there might be a different RSVP 1471 identifiers (LSP-id, tunnel-id) allocated to it. 1473 Flags (12 bits), starting from the least significant bit: 1475 D (Delegate - 1 bit): On a PCRpt message, the D Flag set to 1 1476 indicates that the PCC is delegating the LSP to the PCE. On a 1477 PCUpd message, the D flag set to 1 indicates that the PCE is 1478 confirming the LSP Delegation. To keep an LSP delegated to the 1479 PCE, the PCC must set the D flag to 1 on each PCRpt message for 1480 the duration of the delegation - the first PCRpt with the D flag 1481 set to 0 revokes the delegation. To keep the delegation, the PCE 1482 must set the D flag to 1 on each PCUpd message for the duration of 1483 the delegation - the first PCUpd with the D flag set to 0 returns 1484 the delegation. 1486 S (SYNC - 1 bit): The S Flag MUST be set to 1 on each PCRpt sent 1487 from a PCC during State Synchronization. The S Flag MUST be set 1488 to 0 in other messages sent from the PCC. 1490 R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1491 LSP has been removed from the PCC and the PCE SHOULD remove all 1492 state from its database. Upon receiving an LSP State Report with 1493 the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD 1494 remove all state for the path identified by the LSP-IDENTIFIERS 1495 TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is 1496 used, the PCE SHOULD remove all state for the PLSP-ID from its 1497 database. 1499 A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates 1500 the PCC's target operational status for this LSP. On PCUpd 1501 messages, the A Flag indicates the LSP status that the PCE desires 1502 for this LSP. In both cases, a value of '1' means that the 1503 desired operational state is active, and a value of '0' means that 1504 the desired operational state is inactive. A PCC ignores the A 1505 flag on a PCUpd message unless the operator's policy allows the 1506 PCE to control the corresponding LSP's administrative state. 1508 O(Operational - 3 bits): On PCRpt messages, the O Field represents 1509 the operational status of the LSP. 1511 The following values are defined: 1513 0 - DOWN: not active. 1515 1 - UP: signalled. 1517 2 - ACTIVE: up and carrying traffic. 1519 3 - GOING-DOWN: LSP is being torn down, resources are being 1520 released. 1522 4 - GOING-UP: LSP is being signalled. 1524 5-7 - Reserved: these values are reserved for future use. 1526 Unassigned bits are considered reserved. They MUST be set to 0 on 1527 transmission and MUST be ignored on receipt. 1529 TLVs that may be included in the LSP Object are described in the 1530 following sections. 1532 7.3.1. LSP-IDENTIFIERS TLVs 1534 The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt 1535 messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will 1536 generate an error with error-type 6 (mandatory object missing) and 1537 error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. 1538 The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd 1539 messages for RSVP-signaled LSPs. The special value of all zeros for 1540 this TLV is used to refer to all paths pertaining to a particular 1541 PLSP-ID. There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one 1542 for IPv6. 1544 It is the responsibility of the PCC to send to the PCE the 1545 identifiers for each RSVP incarnation of the tunnel. For example, in 1546 a make-before-break scenario, the PCC MUST send a separate PCRpt for 1547 the old and for the reoptimized paths, and explicitly report removal 1548 of any of these paths using the R bit in the LSP object. 1550 The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 1551 figure: 1553 0 1 2 3 1554 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 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | Type=[TBD] | Length=16 | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | IPv4 Tunnel Sender Address | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | LSP ID | Tunnel ID | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Extended Tunnel ID | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | IPv4 Tunnel Endpoint Address | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 Figure 12: IPV4-LSP-IDENTIFIERS TLV format 1569 The type (16 bits) of the TLV is to be assigned by IANA. The length 1570 field is 16 bit-long and has a fixed value of 16. The value contains 1571 the following fields: 1573 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 1574 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 1575 Sender Template Object. 1577 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1578 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 1579 Object. A value of 0 MUST be used if the LSP is not yet signaled. 1581 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1582 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 1584 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 1585 identifier defined in [RFC3209], Section 4.6.1.1 for the 1586 LSP_TUNNEL_IPv4 Session Object. 1588 IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 1589 address, as defined in [RFC3209], Section 4.6.1.1 for the 1590 LSP_TUNNEL_IPv4 Sender Template Object. 1592 The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following 1593 figure: 1595 0 1 2 3 1596 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 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Type=[TBD] | Length=52 | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | | 1601 + + 1602 | IPv6 tunnel sender address | 1603 + (16 octets) + 1604 | | 1605 + + 1606 | | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | LSP ID | Tunnel ID | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1610 | | 1611 + + 1612 | Extended Tunnel ID | 1613 + (16 octets) + 1614 | | 1615 + + 1616 | | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | | 1619 + + 1620 | IPv6 tunnel endpoint address | 1621 + (16 octets) + 1622 | | 1623 + + 1624 | | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 Figure 13: IPV6-LSP-IDENTIFIERS TLV format 1629 The type (16 bits) of the TLV is to be assigned by IANA. The length 1630 field is 16 bit-long and has a fixed value of 52. The value contains 1631 the following fields: 1633 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 1634 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 1635 Sender Template Object. 1637 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1638 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 1639 Object. A value of 0 MUST be used if the LSP is not yet signaled. 1641 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1642 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 1644 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 1645 identifier defined in [RFC3209], Section 4.6.1.2 for the 1646 LSP_TUNNEL_IPv6 Session Object. 1648 IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 1649 address, as defined in [RFC3209], Section 4.6.1.2 for the 1650 LSP_TUNNEL_IPv6 Session Object. 1652 The Tunnel ID remains constant over the life time of a tunnel. 1654 7.3.2. Symbolic Path Name TLV 1656 Each LSP (path) MUST have a symbolic name that is unique in the PCC. 1657 This symbolic path name MUST remain constant throughout an LSP's 1658 lifetime, which may span across multiple consecutive PCEP sessions 1659 and/or PCC restarts. The symbolic path name MAY be specified by an 1660 operator in a PCC's configuration. If the operator does not specify 1661 a unique symbolic name for a path, the PCC MUST auto-generate one. 1663 The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the 1664 LSP State Report (PCRpt) message when during a given PCEP session an 1665 LSP is first reported to a PCE. A PCC sends to a PCE the first LSP 1666 State Report either during State Synchronization, or when a new LSP 1667 is configured at the PCC. The symbolic path name MAY be included in 1668 the LSP object in subsequent LSP State Reports for the LSP. 1670 The format of the SYMBOLIC-PATH-NAME TLV is shown in the following 1671 figure: 1673 0 1 2 3 1674 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 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | Type=[TBD] | Length (variable) | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | | 1679 // Symbolic Path Name // 1680 | | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 Figure 14: SYMBOLIC-PATH-NAME TLV format 1685 Type (16 bits): to be assigned by IANA. 1687 Length (16 bits): indicates the total length of the TLV in octets and 1688 MUST be greater than 0. The TLV MUST be zero-padded so that the TLV 1689 is 4-octet aligned. 1691 Symbolic Path Name (variable): symbolic name for the LSP, unique in 1692 the PCC. 1694 7.3.3. LSP Error Code TLV 1696 The LSP Error code TLV is an optional TLV for use in the LSP object 1697 to convey error information. When an LSP Update Request fails, an 1698 LSP State Report MUST be sent to report the current state of the LSP, 1699 and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for 1700 the failure. Similarly, when a PCRpt is sent as a result of an LSP 1701 transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD 1702 be included to indicate the reason for the transition. 1704 The format of the LSP-ERROR-CODE TLV is shown in the following 1705 figure: 1707 0 1 2 3 1708 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 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Type=[TBD] | Length=4 | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | LSP Error Code | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 Figure 15: LSP-ERROR-CODE TLV format 1717 The type (16 bits) of the TLV is to be assigned by IANA. The length 1718 field is 16 bit-long and has a fixed value of 4. The value contains 1719 an error code that indicates the cause of the failure. 1721 The following LSP Error Codes are currently defined: 1723 Value Meaning 1724 1 Unknown reason 1725 2 Limit reached for PCE-controlled LSPs 1726 3 Too many pending LSP update requests 1727 4 Unacceptable parameters 1728 5 Internal error 1729 6 LSP administratively brought down 1730 7 LSP preempted 1731 8 RSVP signaling error 1733 7.3.4. RSVP Error Spec TLV 1735 The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object 1736 to carry RSVP error information. It includes the RSVP ERROR_SPEC or 1737 USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned 1738 to the PCC from a downstream node. If the set up of an LSP fails at 1739 a downstream node which returned an ERROR_SPEC to the PCC, the PCC 1740 SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with 1741 LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV 1742 with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object. 1744 The format of the RSVP-ERROR-SPEC TLV is shown in the following 1745 figure: 1747 0 1 2 3 1748 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 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | Type=[TBD] | Length (variable) | 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | | 1753 + RSVP ERROR_SPEC or USER_ERROR_SPEC Object + 1754 | | 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 Figure 16: RSVP-ERROR-SPEC TLV format 1759 Type (16 bits):to be assigned by IANA. 1761 Length (16 bits): indicates the total length of the TLV in octets. 1762 The TLV MUST be zero-padded so that the TLV is 4-octet aligned. 1764 Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC 1765 Object: as specified in [RFC2205] and [RFC5284], including the object 1766 header. 1768 8. IANA Considerations 1770 This document requests IANA actions to allocate code points for the 1771 protocol elements defined in this document. Values shown here are 1772 suggested for use by IANA. 1774 8.1. PCE Capabilities in IGP Advertisements 1776 IANA is requested to allocate new bits in the OSPF Parameters "PCE 1777 Capability Flags" registry, as follows: 1779 Bit Meaning Reference 1780 11 Active Stateful PCE This document 1781 capability 1782 12 Passive Stateful PCE This document 1783 capability 1785 8.2. PCEP Messages 1787 IANA is requested to allocate new message types within the "PCEP 1788 Messages" sub-registry of the PCEP Numbers registry, as follows: 1790 Value Meaning Reference 1791 10 Report This document 1792 11 Update This document 1794 8.3. PCEP Objects 1796 IANA is requested to allocate new object-class values and object 1797 types within the "PCEP Objects" sub-registry of the PCEP Numbers 1798 registry, as follows. 1800 Object-Class Value Name Reference 1802 32 LSP This document 1803 Object-Type 1804 1 1805 33 SRP This document 1806 Object-Type 1807 1 1809 8.4. LSP Object 1811 This document requests that a new sub-registry, named "LSP Object 1812 Flag Field", is created within the "Path Computation Element Protocol 1813 (PCEP) Numbers" registry to manage the Flag field of the LSP 1814 object.New values are to be assigned by Standards Action [RFC5226]. 1815 Each bit should be tracked with the following qualities: 1817 o Bit number (counting from bit 0 as the most significant bit) 1819 o Capability description 1821 o Defining RFC 1823 The following values are defined in this document: 1825 Bit Description Reference 1827 0-4 Reserved This document 1828 5-7 Operational (3 bits) This document 1829 8 Administrative This document 1830 9 Remove This document 1831 10 SYNC This document 1832 11 Delegate This document 1834 8.5. PCEP-Error Object 1836 IANA is requested to allocate new Error Types and Error Values within 1837 the " PCEP-ERROR Object Error Types and Values" sub-registry of the 1838 PCEP Numbers registry, as follows: 1840 Error-Type Meaning 1841 6 Mandatory Object missing 1843 Error-value=8: LSP Object missing 1844 Error-value=9: ERO Object missing 1845 Error-value=10: SRP Object missing 1846 Error-value=11: LSP-IDENTIFIERS TLV missing 1847 19 Invalid Operation 1849 Error-value=1: Attempted LSP Update Request for a non- 1850 delegated LSP. The PCEP-ERROR Object 1851 is followed by the LSP Object that 1852 identifies the LSP. 1853 Error-value=2: Attempted LSP Update Request if the 1854 stateful PCE capability was not 1855 advertised. 1856 Error-value=3: Attempted LSP Update Request for an LSP 1857 identified by an unknown PLSP-ID. 1858 Error-value=5: Attempted LSP State Report if active 1859 stateful PCE capability was not 1860 advertised. 1861 20 LSP State synchronization error. 1863 Error-value=1: A PCE indicates to a PCC that it can 1864 not process (an otherwise valid) LSP 1865 State Report. The PCEP-ERROR Object is 1866 followed by the LSP Object that 1867 identifies the LSP. 1868 Error-value=5: A PCC indicates to a PCE that it can 1869 not complete the state synchronization, 1871 8.6. Notification Object 1873 IANA is requested to allocate new Notification Types and Notification 1874 Values within the "Notification Object" sub-registry of the PCEP 1875 Numbers registry, as follows: 1877 Notification-Type Meaning 1878 4 Stateful PCE resource limit exceeded 1879 Notification-value=1: Entering resource limit 1880 exceeded state 1881 Notification-value=2: Exiting resource limit exceeded 1882 state 1884 8.7. PCEP TLV Type Indicators 1886 IANA is requested to allocate new TLV Type Indicator values within 1887 the " PCEP TLV Type Indicators" sub-registry of the PCEP Numbers 1888 registry, as follows: 1890 Value Meaning Reference 1891 16 STATEFUL-PCE-CAPABILITY This document 1892 17 SYMBOLIC-PATH-NAME This document 1893 18 IPV4-LSP-IDENTIFIERS This document 1894 19 IPV6-LSP-IDENTIFIERS This document 1895 20 LSP-ERROR-CODE This document 1896 21 RSVP-ERROR-SPEC This document 1898 8.8. STATEFUL-PCE-CAPABILITY TLV 1900 This document requests that a new sub-registry, named "STATEFUL-PCE- 1901 CAPABILITY TLV Flag Field", is created within the "Path Computation 1902 Element Protocol (PCEP) Numbers" registry to manage the Flag field in 1903 the STATEFUL-PCE-CAPABILITY TLV of the PCEP OPEN object (class = 1). 1904 New values are to be assigned by Standards Action [RFC5226]. Each 1905 bit should be tracked with the following qualities: 1907 o Bit number (counting from bit 0 as the most significant bit) 1909 o Capability description 1911 o Defining RFC 1913 The following values are defined in this document: 1915 Bit Description Reference 1917 31 LSP-UPDATE-CAPABILITY This document 1919 8.9. LSP-ERROR-CODE TLV 1921 This document requests that a new sub-registry, named "LSP-ERROR-CODE 1922 TLV Error Code Field", is created within the "Path Computation 1923 Element Protocol (PCEP) Numbers" registry to manage the LSP Error 1924 code field of the LSP-ERROR-CODE TLV. This field specifies the 1925 reason for failure to update the LSP. 1927 New values are to be assigned by Standards Action [RFC5226]. Each 1928 value should be tracked with the following qualities: value, 1929 description and defining RFC. The following values are defined in 1930 this document: 1932 Value Meaning 1933 1 Unknown reason 1934 2 Limit reached for PCE-controlled LSPs 1935 3 Too many pending LSP update requests 1936 4 Unacceptable parameters 1937 5 Internal error 1938 6 LSP administratively brought down 1939 7 LSP preempted 1940 8 RSVP signaling error 1942 9. Manageability Considerations 1944 All manageability requirements and considerations listed in [RFC5440] 1945 apply to PCEP extensions defined in this document. In addition, 1946 requirements and considerations listed in this section apply. 1948 9.1. Control Function and Policy 1950 In addition to configuring specific PCEP session parameters, as 1951 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 1952 allow configuring the stateful PCEP capability and the LSP Update 1953 capability. A PCC implementation SHOULD allow the operator to 1954 specify multiple candidate PCEs for and a delegation preference for 1955 each candidate PCE. A PCC SHOULD allow the operator to specify an 1956 LSP delegation policy where LSPs are delegated to the most-preferred 1957 online PCE. A PCC MAY allow the operator to specify different LSP 1958 delegation policies. 1960 A PCC implementation which allows concurrent connections to multiple 1961 PCEs SHOULD allow the operator to group the PCEs by administrative 1962 domains and it MUST NOT advertise LSP existence and state to a PCE if 1963 the LSP is delegated to a PCE in a different group. 1965 A PCC implementation SHOULD allow the operator to specify whether the 1966 PCC will advertise LSP existence and state for LSPs that are not 1967 controlled by any PCE (for example, LSPs that are statically 1968 configured at the PCC). 1970 A PCC implementation SHOULD allow the operator to specify both the 1971 Redelegation Timeout Interval and the State Timeout Interval. The 1972 default value of the Redelegation Timeout Interval SHOULD be set to 1973 30 seconds. An operator MAY also configure a policy that will 1974 dynamically adjust the Redelegation Timeout Interval, for example 1975 setting it to zero when the PCC has an established session to a 1976 backup PCE. The default value for the State Timeout Interval SHOULD 1977 be set to 60 seconds. 1979 After the expiration of the State Timeout Interval, the LSP reverts 1980 to operator-defined default parameters. A PCC implementation MUST 1981 allow the operator to specify the default LSP parameters. To achieve 1982 a behavior where the LSP retains the parameters set by the PCE until 1983 such time that the PCC makes a change to them, a State Timeout 1984 Interval of infinity SHOULD be used. Any changes to LSP parameters 1985 SHOULD be done in make-before-break fashion. 1987 LSP Delegation is controlled by operator-defined policies on a PCC. 1988 LSPs are delegated individually - different LSPs may be delegated to 1989 different PCEs. An LSP is delegated to at most one PCE at any given 1990 point in time. A PCC implementation SHOULD support the delegation 1991 policy, when all PCC's LSPs are delegated to a single PCE at any 1992 given time. Conversely, the policy revoking the delegation for all 1993 PCC's LSPs SHOULD also be supported. 1995 A PCC implementation SHOULD allow the operator to specify delegation 1996 priority for PCEs. This effectively defines the primary PCE and one 1997 or more backup PCEs to which primary PCE's LSPs can be delegated when 1998 the primary PCE fails. 2000 Policies defined for stateful PCEs and PCCs should eventually fit in 2001 the Policy-Enabled Path Computation Framework defined in [RFC5394], 2002 and the framework should be extended to support Stateful PCEs. 2004 9.2. Information and Data Models 2006 PCEP session configuration and information in the PCEP MIB module 2007 SHOULD be extended to include advertised stateful capabilities, 2008 synchronization status, and delegation status (at the PCC list PCEs 2009 with delegated LSPs). 2011 9.3. Liveness Detection and Monitoring 2013 PCEP extensions defined in this document do not require any new 2014 mechanisms beyond those already defined in [RFC5440], Section 8.3. 2016 9.4. Verifying Correct Operation 2018 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 2019 extensions defined in this document. In addition to monitoring 2020 parameters defined in [RFC5440], a stateful PCC-side PCEP 2021 implementation SHOULD provide the following parameters: 2023 o Total number of LSP updates 2025 o Number of successful LSP updates 2027 o Number of dropped LSP updates 2029 o Number of LSP updates where LSP setup failed 2031 A PCC implementation SHOULD provide a command to show for each LSP 2032 whether it is delegated, and if so, to which PCE. 2034 A PCC implementation SHOULD allow the operator to manually revoke LSP 2035 delegation. 2037 9.5. Requirements on Other Protocols and Functional Components 2039 PCEP extensions defined in this document do not put new requirements 2040 on other protocols. 2042 9.6. Impact on Network Operation 2044 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 2045 extensions defined in this document. 2047 Additionally, a PCEP implementation SHOULD allow a limit to be placed 2048 on the number of LSPs delegated to the PCE and on the rate of PCUpd 2049 and PCRpt messages sent by a PCEP speaker and processed from a peer. 2050 It SHOULD also allow sending a notification when a rate threshold is 2051 reached. 2053 A PCC implementation SHOULD allow a limit to be placed on the rate of 2054 LSP Updates to the same LSP to avoid signaling overload discussed in 2055 Section 10.3. 2057 10. Security Considerations 2059 10.1. Vulnerability 2061 This document defines extensions to PCEP to enable stateful PCEs. 2062 The nature of these extensions and the delegation of path control to 2063 PCEs results in more information being available for a hypothetical 2064 adversary and a number of additional attack surfaces which must be 2065 protected. 2067 The security provisions described in [RFC5440] remain applicable to 2068 these extensions. However, because the protocol modifications 2069 outlined in this document allow the PCE to control path computation 2070 timing and sequence, the PCE defense mechanisms described in 2071 [RFC5440] section 7.2 are also now applicable to PCC security. 2073 As a general precaution, it is RECOMMENDED that these PCEP extensions 2074 only be activated on authenticated and encrypted sessions across PCEs 2075 and PCCs belonging to the same administrative authority. 2077 The following sections identify specific security concerns that may 2078 result from the PCEP extensions outlined in this document along with 2079 recommended mechanisms to protect PCEP infrastructure against related 2080 attacks. 2082 10.2. LSP State Snooping 2084 The stateful nature of this extension explicitly requires LSP status 2085 updates to be sent from PCC to PCE. While this gives the PCE the 2086 ability to provide more optimal computations to the PCC, it also 2087 provides an adversary with the opportunity to eavesdrop on decisions 2088 made by network systems external to PCE. This is especially true if 2089 the PCC delegates LSPs to multiple PCEs simultaneously. 2091 Adversaries may gain access to this information by eavesdropping on 2092 unsecured PCEP sessions, and might then use this information in 2093 various ways to target or optimize attacks on network infrastructure. 2094 For example by flexibly countering anti-DDoS measures being taken to 2095 protect the network, or by determining choke points in the network 2096 where the greatest harm might be caused. 2098 PCC implementations which allow concurrent connections to multiple 2099 PCEs SHOULD allow the operator to group the PCEs by administrative 2100 domains and they MUST NOT advertise LSP existence and state to a PCE 2101 if the LSP is delegated to a PCE in a different group. 2103 10.3. Malicious PCE 2105 The LSP delegation mechanism described in this document allows a PCC 2106 to grant effective control of an LSP to the PCE for the duration of a 2107 PCEP session. While this enables PCE control of the timing and 2108 sequence of path computations within and across PCEP sessions, it 2109 also introduces a new attack vector: an attacker may flood the PCC 2110 with PCUpd messages at a rate which exceeds either the PCC's ability 2111 to process them or the network's ability to signal the changes, 2112 either by spoofing messages or by compromising the PCE itself. 2114 A PCC is free to revoke an LSP delegation at any time without needing 2115 any justification. A defending PCC can do this by enqueueing the 2116 appropriate PCRpt message. As soon as that message is enqueued in 2117 the session, the PCC is free to drop any incoming PCUpd messages 2118 without additional processing. 2120 10.4. Malicious PCC 2122 A stateful session also results in an increased attack surface by 2123 placing a requirement for the PCE to keep an LSP state replica for 2124 each PCC. It is RECOMMENDED that PCE implementations provide a limit 2125 on resources a single PCC can occupy. A PCE implementing such a 2126 limit MUST send a PCNtf message with notification-type to be assigned 2127 by IANA (Stateful PCE resource limit exceeded) and notification-value 2128 to be assigned by IANA (Entering resource limit exceeded state) upon 2129 receiving an LSP state report causing it to exceed this threshold. 2131 Delegation of LSPs can create further strain on PCE resources and a 2132 PCE implementation MAY preemptively give back delegations if it finds 2133 itself lacking the resources needed to effectively manage the 2134 delegation. Since the delegation state is ultimately controlled by 2135 the PCC, PCE implementations SHOULD provide throttling mechanisms to 2136 prevent strain created by flaps of either a PCEP session or an LSP 2137 delegation. 2139 11. Contributing Authors 2141 Xian Zhang 2142 Huawei Technology 2143 F3-5-B R&D Center 2144 Huawei Industrial Base, Bantian, Longgang District 2145 Shenzhen, Guangdong 518129 2146 P.R.China 2147 EMail: zhang.xian@huawei.com 2149 Dhruv Dhody 2150 Huawei Technology 2151 Leela Palace 2152 Bangalore, Karnataka 560008 2153 INDIA 2154 EMail: dhruv.dhody@huawei.com 2156 Siva Sivabalan 2157 Cisco Systems, Inc. 2158 2000 Innovation Drive 2159 Kanata, Ontario K2K 3E8 2160 Canada 2161 EMail: msiva@cisco.com 2163 12. Acknowledgements 2165 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 2166 Casellas for their contributions to this document. 2168 We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, 2169 Paul Schultz and Raveendra Torvi for their comments and suggestions. 2170 Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga, 2171 Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, 2172 Ambrose Kwong, Ashwin Sampath and Calvin Ying for helpful comments 2173 and discussions. 2175 13. References 2177 13.1. Normative References 2179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2180 Requirement Levels", BCP 14, RFC 2119, 2181 DOI 10.17487/RFC2119, March 1997, 2182 . 2184 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 2185 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2186 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 2187 September 1997, . 2189 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2190 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2191 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2192 . 2194 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 2195 Zhang, "OSPF Protocol Extensions for Path Computation 2196 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 2197 January 2008, . 2199 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 2200 Zhang, "IS-IS Protocol Extensions for Path Computation 2201 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 2202 January 2008, . 2204 [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", 2205 RFC 5284, DOI 10.17487/RFC5284, August 2008, 2206 . 2208 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 2209 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 2210 DOI 10.17487/RFC5440, March 2009, 2211 . 2213 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2214 Used to Form Encoding Rules in Various Routing Protocol 2215 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2216 2009, . 2218 13.2. Informative References 2220 [I-D.ietf-pce-gmpls-pcep-extensions] 2221 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 2222 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in 2223 progress), October 2015. 2225 [I-D.ietf-pce-stateful-pce-app] 2226 Zhang, X. and I. Minei, "Applicability of a Stateful Path 2227 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 2228 app-06 (work in progress), July 2016. 2230 [I-D.ietf-pce-stateful-sync-optimizations] 2231 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 2232 and D. Dhody, "Optimizations of Label Switched Path State 2233 Synchronization Procedures for a Stateful PCE", draft- 2234 ietf-pce-stateful-sync-optimizations-05 (work in 2235 progress), April 2016. 2237 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2238 LSP Path Computation using Preemption", Global 2239 Information Infrastructure Symposium, July 2007. 2241 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2242 programming algorithm for balancing the max-min fairness 2243 and throughput objectives in traffic engineering", 2244 INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012. 2246 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2247 McManus, "Requirements for Traffic Engineering Over MPLS", 2248 RFC 2702, DOI 10.17487/RFC2702, September 1999, 2249 . 2251 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2252 Label Switching Architecture", RFC 3031, 2253 DOI 10.17487/RFC3031, January 2001, 2254 . 2256 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2257 Christian, B., and W. Lai, "Applicability Statement for 2258 Traffic Engineering with MPLS", RFC 3346, 2259 DOI 10.17487/RFC3346, August 2002, 2260 . 2262 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2263 (TE) Extensions to OSPF Version 2", RFC 3630, 2264 DOI 10.17487/RFC3630, September 2003, 2265 . 2267 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2268 Element (PCE)-Based Architecture", RFC 4655, 2269 DOI 10.17487/RFC4655, August 2006, 2270 . 2272 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 2273 Element (PCE) Communication Protocol Generic 2274 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2275 2006, . 2277 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2278 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2279 DOI 10.17487/RFC5226, May 2008, 2280 . 2282 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2283 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2284 2008, . 2286 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2287 "Policy-Enabled Path Computation Framework", RFC 5394, 2288 DOI 10.17487/RFC5394, December 2008, 2289 . 2291 Authors' Addresses 2293 Edward Crabbe 2294 Individual Contributor 2296 Email: edward.crabbe@gmail.com 2297 Ina Minei 2298 Google, Inc. 2299 1600 Amphitheatre Parkway 2300 Mountain View, CA 94043 2301 US 2303 Email: inaminei@google.com 2305 Jan Medved 2306 Cisco Systems, Inc. 2307 170 West Tasman Dr. 2308 San Jose, CA 95134 2309 US 2311 Email: jmedved@cisco.com 2313 Robert Varga 2314 Pantheon Technologies SRO 2315 Mlynske Nivy 56 2316 Bratislava 821 05 2317 Slovakia 2319 Email: robert.varga@pantheon.tech