idnits 2.17.1 draft-ietf-pce-stateful-pce-01.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The PCEP protocol extensions for stateful PCEs MUST not be used if one or both PCEP Speakers have not included the Stateful PCE Capability TLV in their respective OPEN message, otherwise a PCErr with code "Stateful PCE capability not negotiated" (see Section 8.4) will be generated and the PCEP session will be terminated. -- The document date (July 15, 2012) is 4301 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 1891, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Crabbe 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track J. Medved 5 Expires: January 16, 2013 Cisco Systems, Inc. 6 R. Varga 7 Pantheon Technologies SRO 8 I. Minei 9 Juniper Networks, Inc. 10 July 15, 2012 12 PCEP Extensions for Stateful PCE 13 draft-ietf-pce-stateful-pce-01 15 Abstract 17 The Path Computation Element Communication Protocol (PCEP) provides 18 mechanisms for Path Computation Elements (PCEs) to perform path 19 computations in response to Path Computation Clients (PCCs) requests. 21 Although PCEP explicitly makes no assumptions regarding the 22 information available to the PCE, it also makes no provisions for 23 synchronization or PCE control of timing and sequence of path 24 computations within and across PCEP sessions. This document 25 describes a set of extensions to PCEP to enable this functionality, 26 providing stateful control of Multiprotocol Label Switching (MPLS) 27 Traffic Engineering Label Switched Paths (TE LSP) via PCEP. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 16, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Motivation and Objectives . . . . . . . . . . . . . . . . . . 6 71 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7 74 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 14 75 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 15 76 4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 16 77 5. Architectural Overview of Protocol Extensions . . . . . . . . 16 78 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 16 79 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 17 80 5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 18 81 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 18 82 5.4.1. State Synchronization Avoidance . . . . . . . . . . . 20 83 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 24 84 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 25 85 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 25 86 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 26 87 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 27 88 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 27 89 5.6.1. Passive Stateful PCE Path Computation 90 Request/Response . . . . . . . . . . . . . . . . . . . 28 91 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 29 92 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 30 93 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31 94 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 31 95 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 31 96 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 32 97 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 34 98 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 35 99 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 35 100 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 35 101 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 36 102 7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 36 103 7.1.3. Node Identifier TLV . . . . . . . . . . . . . . . . . 37 104 7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 38 105 7.2.1. The LSP Symbolic Name TLV . . . . . . . . . . . . . . 39 106 7.2.2. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 40 107 7.2.3. LSP Update Error Code TLV . . . . . . . . . . . . . . 42 108 7.2.4. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 42 109 7.2.5. LSP State Database Version TLV . . . . . . . . . . . . 43 110 7.2.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 44 111 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 112 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 44 113 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 44 114 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 45 115 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 45 116 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 46 117 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 46 118 8.7. LSP-UPDATE-ERROR-CODE TLV . . . . . . . . . . . . . . . . 47 119 9. Manageability Considerations . . . . . . . . . . . . . . . . . 47 120 9.1. Control Function and Policy . . . . . . . . . . . . . . . 47 121 9.2. Information and Data Models . . . . . . . . . . . . . . . 48 122 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 48 123 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 48 124 9.5. Requirements on Other Protocols and Functional 125 Components . . . . . . . . . . . . . . . . . . . . . . . . 49 126 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 49 127 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 128 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 49 129 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 50 130 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 50 131 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 51 132 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 133 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 134 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51 135 12.2. Informative References . . . . . . . . . . . . . . . . . . 52 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 138 1. Introduction 140 [RFC5440] describes the Path Computation Element Protocol (PCEP. 141 PCEP defines the communication between a Path Computation Client 142 (PCC) and a Path Control Element (PCE), or between PCE and PCE, 143 enabling computation of Multiprotocol Label Switching (MPLS) for 144 Traffic Engineering Label Switched Path (TE LSP) characteristics 146 This document specifies a set of extensions to PCEP to enable 147 stateful control of TE LSPs between and across PCEP sessions in 148 compliance with [RFC4657]. It includes mechanisms to effect LSP 149 state synchronization between PCCs and PCEs, delegation of control of 150 LSPs to PCEs, and PCE control of timing and sequence of path 151 computations within and across PCEP sessions. 153 2. Terminology 155 This document uses the following terms defined in [RFC5440]: PCC, 156 PCE, PCEP Peer. 158 This document uses the following terms defined in [RFC4090]: MPLS TE 159 Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup. 161 The following terms are defined in this document: 163 Passive Stateful PCE: uses LSP state information learned from PCCs 164 to optimize path computations. It does not actively update LSP 165 state. A PCC maintains synchronization with the PCE. 167 Active Stateful PCE: uses LSP state information learned from PCCs to 168 optimize path computations. Additionally, it actively updates LSP 169 parameters in those PCCs that delegated control over their LSPs to 170 the PCE. 172 Delegation: An operation to grant a PCE temporary rights to modify a 173 subset of LSPs parameters on one or more PCC's LSPs. LSPs are 174 delegated from a PCC to a PCE. 176 Delegation Timeout Interval: when a PCEP session is terminated, a 177 PCC waits for this time period before revoking LSP delegation to a 178 PCE. 180 LSP State Report: an operation to send LSP state (Operational / 181 Admin Status, LSP attributes configured and set by a PCE, etc.) 182 from a PCC to a PCE. 184 LSP Update Request: an operation where a PCE requests a PCC to 185 update one or more attributes of an LSP and to re-signal the LSP 186 with updated attributes. 188 LSP Priority: a specific pair of MPLS setup and hold priority 189 values. 191 LSP State Database: information about and attributes of all LSPs 192 that are being reported to one or more PCEs via LSP State Reports. 194 Minimum Cut Set: the minimum set of links for a specific source 195 destination pair which, when removed from the network, result in a 196 specific source being completely isolated from specific 197 destination. The summed capacity of these links is equivalent to 198 the maximum capacity from the source to the destination by the 199 max-flow min-cut theorem. 201 MPLS TE Global Default Restoration: once an LSP failure is detected 202 by some downstream mode, the head-end LSP is notified by means of 203 RSVP. Upon receiving the notification, the headend Label 204 Switching Router (LSR) recomputes the path and signals the LSP 205 along an alternate path. [NET-REC] 207 MPLS TE Global Path Protection: once an LSP failure is detected by 208 some downstream mode, the head-end LSP is notified by means of 209 RSVP. Upon receiving the notification, the headend LSR reroutes 210 traffic using a pre-signaled backup (secondary) LSP. [NET-REC]. 212 Revocation: an operation performed by a PCC on a previously 213 delegated LSP. Revocation clears the LSP's PCE specific state on 214 the PCC and, if a PCEP session with the PCE the LSP was delegated 215 to exists in the UP state, also generates a revocation message to 216 the PCE. 218 Within this document, when describing PCE-PCE communications, the 219 requesting PCE fills the role of a PCC. This provides a saving in 220 documentation without loss of function. 222 The message formats in this document are specified using Routing 223 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 225 3. Motivation and Objectives 227 3.1. Motivation 228 3.1.1. Background 230 Traffic engineering has been a goal of the MPLS architecture since 231 its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic 232 engineering system provided by [RFC3630], [RFC5305], and [RFC3209] 233 information about network resources utilization is only available as 234 total reserved capacity by traffic class on a per interface basis; 235 individual LSP state is available only locally on each LER for it's 236 own LSPs. In most cases, this makes good sense, as distribution and 237 retention of total LSP state for all LERs within in the network would 238 be prohibitively costly. 240 Unfortunately, this visibility in terms of global LSP state may 241 result in a number of issues for some demand patterns, particularly 242 within a common setup and hold priority. This issue affects online 243 traffic engineering systems, and in particular, the widely 244 implemented but seldom deployed auto-bandwidth system. 246 A sufficiently over-provisioned system will by definition have no 247 issues routing its demand on the shortest path. However, lowering 248 the degree to which network over-provisioning is required in order to 249 run a healthy, functioning network is a clear and explicit promise of 250 MPLS architecture. In particular, it has been a goal of MPLS to 251 provide mechanisms to alleviate congestion scenarios in which 252 "traffic streams are inefficiently mapped onto available resources; 253 causing subsets of network resources to become over-utilized while 254 others remain underutilized" ([RFC2702]). 256 3.1.2. Why a Stateful PCE? 258 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 259 "strict synchronization between the PCE and not only the network 260 states (in term of topology and resource information), but also the 261 set of computed paths and reserved resources in use in the network." 262 [RFC4655] also expressed a number of concerns with regard to a 263 stateful PCE, specifically: 265 o Any reliable synchronization mechanism would result in significant 266 control plane overhead 268 o Out-of-band ted synchronization would be complex and prone to race 269 conditions 271 o Path calculations incorporating total network state would be 272 highly complex 274 In general, stress on the MPLS TE control plane will be directly 275 proportional to the size of the system being controlled and the 276 tightness of the control loop, and indirectly proportional to the 277 amount of over-provisioning in terms of both network capacity and 278 reservation overhead. 280 Despite these concerns in terms of implementation complexity and 281 scalability, several TE algorithms exist today that have been 282 demonstrated to be extremely effective in large TE systems, providing 283 both rapid convergence and significant benefits in terms of 284 optimality of resource usage [MXMN-TE]. All of these systems share 285 at least two common characteristics: the requirement for both global 286 visibility of a flow (or in this case, a TE LSP) state and for 287 ordered control of path reservations across devices within the system 288 being controlled. While some approaches have been suggested in order 289 to remove the requirements for ordered control (See [MPLS-PC]), these 290 approaches are highly dependent on traffic distribution, and do not 291 allow for multiple simultaneous LSP priorities representing diffserv 292 classes. 294 The following use cases demonstrate a need for visibility into global 295 inter-PCC LSP state in PCE path computations, and for a PCE control 296 of sequence and timing in altering LSP path characteristics within 297 and across PCEP sessions. Reference topologies for the use cases 298 described later in this section are shown in Figures 1 and 2. 300 Unless otherwise cited, use cases assume that all LSPs listed exist 301 at the same LSP priority. 303 +-------+ 304 | A | 305 | | 306 +-------+ 307 \ 308 +-------+ +-------+ 309 | C |-------------------------| E | 310 | | | | 311 +-------+ +-------+ +-------+ 312 / \ | D | / 313 +-------+ ------| |------ 314 | B | +-------+ 315 | | 316 +-------+ 318 Figure 1: Reference topology 1 320 +-------+ +-------+ +-------+ 321 | A | | B | | C | 322 | | | | | | 323 +---+---+ +---+---+ +---+---+ 324 | | | 325 | | | 326 +---+---+ +---+---+ +---+---+ 327 | E | | F | | G | 328 | +--------+ +--------+ | 329 +-------+ +-------+ +-------+ 331 Figure 2: Reference topology 2 333 3.1.2.1. Throughput Maximization and Bin Packing 335 Because LSP attribute changes in [RFC5440] are driven by PCReq 336 messages under control of a PCC's local timers, the sequence of RSVP 337 reservation arrivals occurring in the network will be randomized. 338 This, coupled with a lack of global LSP state visibility on the part 339 of a stateless PCE may result in suboptimal throughput in a given 340 network topology. 342 Reference topology 2 in Figure 2 and Tables 1 and 2 show an example 343 in which throughput is at 50% of optimal as a result of lack of 344 visibility and synchronized control across PCC's. In this scenario, 345 the decision must be made as to whether to route any portion of the 346 E-G demand, as any demand routed for this source and destination will 347 decrease system throughput. 349 +------+--------+----------+ 350 | Link | Metric | Capacity | 351 +------+--------+----------+ 352 | A-E | 1 | 10 | 353 | B-F | 1 | 10 | 354 | C-G | 1 | 10 | 355 | E-F | 1 | 10 | 356 | F-G | 1 | 10 | 357 +------+--------+----------+ 359 Table 1: Link parameters for Throughput use case 361 +------+-----+-----+-----+--------+----------+-------+ 362 | Time | LSP | Src | Dst | Demand | Routable | Path | 363 +------+-----+-----+-----+--------+----------+-------+ 364 | 1 | 1 | E | G | 10 | Yes | E-F-G | 365 | 2 | 2 | A | B | 10 | No | --- | 366 | 3 | 1 | F | C | 10 | No | --- | 367 +------+-----+-----+-----+--------+----------+-------+ 369 Table 2: Throughput use case demand time series 371 In many cases throughput maximization becomes a bin packing problem. 372 While bin packing itself is an NP-hard problem, a number of common 373 heuristics which run in polynomial time can provide significant 374 improvements in throughput over random reservation event 375 distribution, especially when traversing links which are members of 376 the minimum cut set for a large subset of source destination pairs. 378 Tables 3 and 4 show a simple use case using Reference Topology 1 in 379 Figure 1, where LSP state visibility and control of reservation order 380 across PCCs would result in significant improvement in total 381 throughput. 383 +------+--------+----------+ 384 | Link | Metric | Capacity | 385 +------+--------+----------+ 386 | A-C | 1 | 10 | 387 | B-C | 1 | 10 | 388 | C-E | 10 | 5 | 389 | C-D | 1 | 10 | 390 | D-E | 1 | 10 | 391 +------+--------+----------+ 393 Table 3: Link parameters for Bin Packing use case 395 +------+-----+-----+-----+--------+----------+---------+ 396 | Time | LSP | Src | Dst | Demand | Routable | Path | 397 +------+-----+-----+-----+--------+----------+---------+ 398 | 1 | 1 | A | E | 5 | Yes | A-C-D-E | 399 | 2 | 2 | B | E | 10 | No | --- | 400 +------+-----+-----+-----+--------+----------+---------+ 402 Table 4: Bin Packing use case demand time series 404 3.1.2.2. Deadlock 406 Most existing RSVP-TE implementations will not tear down established 407 LSPs in the event of the failure of the bandwidth increase procedure 408 detailed in [RFC3209]. This behavior is directly implied to be 409 correct in [RFC3209] and is often desirable from an operator's 410 perspective, because either a) the destination prefixes are not 411 reachable via any means other than MPLS or b) this would result in 412 significant packet loss as demand is shifted to other LSPs in the 413 overlay mesh. 415 In addition, there are currently few implementations offering ingress 416 admission control at the LSP level. Again, having ingress admission 417 control on a per LSP basis is not necessarily desirable from an 418 operational perspective, as a) one must over-provision tunnels 419 significantly in order to avoid deleterious effects resulting from 420 stacked transport and flow control systems and b) there is currently 421 no efficient commonly available northbound interface for dynamic 422 configuration of per LSP ingress admission control (such an interface 423 could easily be defined using the extensions present in this spec, 424 but it beyond the scope of the current document). 426 Lack of ingress admission control coupled with the behavior in 427 [RFC3209] effectively results in mis-signaled LSPs during periods of 428 contention for network capacity between LSPs in a given LSP priority. 429 This in turn causes information loss in the TED with regard to actual 430 network state, resulting in LSPs sharing common network interfaces 431 with mis-signaled LSPs operating in a degraded state for significant 432 periods of time, even when unused network capacity may potentially be 433 available. 435 Reference Topology 1 in Figure 1 and Tables 5 and 6 show a use case 436 that demonstrates this behavior. Two LSPs, LSP 1 and LSP 2 are 437 signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E 438 respectively. At a later time, the demand of LSP 1 increases to 20. 439 Under such a demand, the LSP cannot be resignaled. However, the 440 existing LSP will not be torn down. In the absence of ingress 441 policing, traffic on LSP 1 will cause degradation for traffic of LSP 442 2 (due to oversubscription on the links C-D and D-E), as well as 443 information loss in the TED with regard to the actual network state. 445 The problem could be easily ameliorated by global visibility of LSP 446 state coupled with PCC- external demand measurements and placement of 447 two LSPs on disjoint links. Note that while the demand of 20 for LSP 448 1 could never be satisfied in the given topology, what could be 449 achieved would be isolation from the ill-effects of the 450 (unsatisfiable) increased demand. 452 +------+--------+----------+ 453 | Link | Metric | Capacity | 454 +------+--------+----------+ 455 | A-C | 1 | 10 | 456 | B-C | 1 | 10 | 457 | C-E | 10 | 5 | 458 | C-D | 1 | 10 | 459 | D-E | 1 | 10 | 460 +------+--------+----------+ 462 Table 5: Link parameters for the 'Deadlock' example 464 +------+-----+-----+-----+--------+----------+---------+ 465 | Time | LSP | Src | Dst | Demand | Routable | Path | 466 +------+-----+-----+-----+--------+----------+---------+ 467 | 1 | 1 | A | E | 2 | Yes | A-C-D-E | 468 | 2 | 2 | B | E | 2 | Yes | B-C-D-E | 469 | 3 | 1 | A | E | 20 | No | --- | 470 +------+-----+-----+-----+--------+----------+---------+ 472 Table 6: Deadlock LSP and demand time series 474 3.1.2.3. Minimum Perturbation 476 As a result of both the lack of visibility into global LSP state and 477 the lack of control over event ordering across PCE sessions, 478 unnecessary perturbations may be introduced into the network by a 479 stateless PCE. Tables 7 and 8 show an example of an unnecessary 480 network perturbation using Reference Topology 1 in Figure 1. In this 481 case an unimportant (high LSP priority value) LSP (LSP1) is first set 482 up along the shortest path. At time 2, which is assumed to be 483 relatively close to time 1, a second more important (lower LSP- 484 priority value) LSP is established, preempting LSP 1 and shifting it 485 to the longer A-C-E path. 487 +------+--------+----------+ 488 | Link | Metric | Capacity | 489 +------+--------+----------+ 490 | A-C | 1 | 10 | 491 | B-C | 1 | 10 | 492 | C-E | 10 | 10 | 493 | C-D | 1 | 10 | 494 | D-E | 1 | 10 | 495 +------+--------+----------+ 497 Table 7: Link parameters for the 'Minimum-Perturbation' example 499 +------+-----+-----+-----+--------+----------+----------+---------+ 500 | Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path | 501 +------+-----+-----+-----+--------+----------+----------+---------+ 502 | 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E | 503 | 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E | 504 | 3 | 1 | A | E | 7 | 7 | Yes | A-C-E | 505 +------+-----+-----+-----+--------+----------+----------+---------+ 507 Table 8: Minimum-Perturbation LSP and demand time series 509 3.1.2.4. Predictability 511 Randomization of reservation events caused by lack of control over 512 event ordering across PCE sessions results in poor predictability in 513 LSP routing. An offline system applying a consistent optimization 514 method will produce predictable results to within either the boundary 515 of forecast error when reservations are over-provisioned by 516 reasonable margins or to the variability of the signal and the 517 forecast error when applying some hysteresis in order to minimize 518 churn. 520 Reference Topology 1 and Tables 9, 10 and 11 show the impact of event 521 ordering and predictability of LSP routing. 523 +------+--------+----------+ 524 | Link | Metric | Capacity | 525 +------+--------+----------+ 526 | A-C | 1 | 10 | 527 | B-C | 1 | 10 | 528 | C-E | 1 | 10 | 529 | C-D | 1 | 10 | 530 | D-E | 1 | 10 | 531 +------+--------+----------+ 533 Table 9: Link parameters for the 'Predictability' example 535 +------+-----+-----+-----+--------+----------+---------+ 536 | Time | LSP | Src | Dst | Demand | Routable | Path | 537 +------+-----+-----+-----+--------+----------+---------+ 538 | 1 | 1 | A | E | 7 | Yes | A-C-E | 539 | 2 | 2 | B | E | 7 | Yes | B-C-D-E | 540 +------+-----+-----+-----+--------+----------+---------+ 542 Table 10: Predictability LSP and demand time series 1 544 +------+-----+-----+-----+--------+----------+---------+ 545 | Time | LSP | Src | Dst | Demand | Routable | Path | 546 +------+-----+-----+-----+--------+----------+---------+ 547 | 1 | 2 | B | E | 7 | Yes | B-C-E | 548 | 2 | 1 | A | E | 7 | Yes | A-C-D-E | 549 +------+-----+-----+-----+--------+----------+---------+ 551 Table 11: Predictability LSP and demand time series 2 553 3.1.2.5. Global Concurrent Optimization 555 Global Concurrent Optimization (GCO) defined in [RFC5557] is a 556 network optimization mechanism that is able to simultaneously 557 consider the entire topology of the network and the complete set of 558 existing TE LSPs and their existing constraints, and look to optimize 559 or reoptimize the entire network to satisfy all constraints for all 560 TE LSPs. It allows for bulk path computations in order to avoid 561 blocking problems and to achieve more optimal network-wide solutions. 563 Global control of LSP operation sequence in [RFC5557] is predicated 564 on the use of what is effectively a stateful (or semi-stateful) NMS. 565 The NMS can be either not local to the switch, in which case another 566 northbound interface is required for LSP attribute changes, or local/ 567 collocated, in which case there are significant issues with 568 efficiency in resource usage. Stateful PCE adds a few features that: 570 o Roll the NMS visibility into the PCE and remove the requirement 571 for an additional northbound interface 573 o Allow the PCE to determine when re-optimization is needed 575 o Allow the PCE to determine which LSPs should be re-optimized 577 o Allow a PCE to control the sequence of events across multiple 578 PCCs, allowing for bulk (and truly global) optimization, LSP 579 shuffling etc. 581 3.1.3. Protocol vs. Configuration 583 Note that existing configuration tools and protocols can be used to 584 set LSP state. However, this solution has several shortcomings: 586 o Scale & Performance: configuration operations often require 587 processing of additional configuration portions beyond the state 588 being directly acted upon, with corresponding cost in CPU cycles, 589 negatively impacting both PCC stability LSP update rate capacity. 591 o Scale & Performance: configuration operations often have 592 transactional semantics which are typically heavyweight and 593 require additional CPU cycles, negatively impacting PCC update 594 rate capacity. 596 o Security: opening up a configuration channel to a PCE would allow 597 a malicious PCE to take over a PCC. The PCEP extensions described 598 in this document only allow a PCE control over a very limited set 599 of LSP attributes. 601 o Interoperability: each vendor has a proprietary information model 602 for configuring LSP state, which prevents interoperability of a 603 PCE with PCCs from different vendors. The PCEP extensions 604 described in this document allow for a common information model 605 for LSP state for all vendors. 607 o Efficient State Synchronization: configuration channels may be 608 heavyweight and unidirectional, therefore efficient state 609 synchronization between a PCE and a PCE may be a problem. 611 3.2. Objectives 613 The objectives for the protocol extensions to support stateful PCE 614 described in this document are as follows: 616 o Allow a single PCC to interact with a mix of stateless and 617 stateful PCEs simultaneously using the same PCEP. 619 o Support efficient LSP state synchronization between the PCC and 620 one or more active or passive stateful PCEs. 622 o Allow a PCC to delegate control of its LSPs to an active stateful 623 PCE such that a single LSP is under the control a single PCE at 624 any given time. A PCC may revoke this delegation at any time 625 during the lifetime of the LSP. If LSP delegation is revoked 626 while the PCEP session is up, the PCC MUST notify the PCE about 627 the revocation. A PCE may return an LSP delegation at any point 628 during the lifetime of the PCEP session. 630 o Allow a PCE to control computation timing and update timing across 631 all LSPs that have been delegated to it. 633 o Allow a PCE to specify protection / restoration settings for all 634 LSPs that have been delegated to it. 636 o Enable uninterrupted operation of PCC's LSPs in the event PCE 637 failure or while control of LSPs is being transferred between 638 PCEs. 640 4. New Functions to Support Stateful PCEs 642 Several new functions will be required in PCEP to support stateful 643 PCEs. A function can be initiated either from a PCC towards a PCE 644 (C-E) or from a PCE towards a PCC (E-C). The new functions are: 646 Capability negotiation (E-C,C-E): both the PCC and the PCE must 647 announce during PCEP session establishment that they support PCEP 648 Stateful PCE extensions defined in this document. 650 LSP state synchronization (C-E): after the session between the PCC 651 and a stateful PCE is initialized, the PCE must learn the state of 652 a PCC's LSPs before it can perform path computations or update LSP 653 attributes in a PCC. 655 LSP Update Request (E-C): A PCE requests modification of attributes 656 on a PCC's LSP. 658 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 659 whenever the state of an LSP changes. 661 LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 662 update LSP attributes on one or more LSPs; the PCE becomes the 663 authoritative source of the LSP's attributes as long as the 664 delegation is in effect (See Section 5.5); the PCC may withdraw 665 the delegation or the PCE may give up the delegation 667 In addition to new PCEP functions, stateful capabilities discovery 668 will be required in OSPF ([RFC5088]) and IS-IS ([RFC5089]). Stateful 669 capabilities discovery is not in scope of this document. 671 5. Architectural Overview of Protocol Extensions 673 5.1. LSP State Ownership 675 In the PCEP protocol (defined in [RFC5440]), LSP state and operation 676 are under the control of a PCC (a PCC may be an LSR or a management 677 station). Attributes received from a PCE are subject to PCC's local 678 policy. The PCEP protocol extensions described in this document do 679 not change this behavior. 681 An active stateful PCE may have control of a PCC's LSPs be delegated 682 to it, but the LSP state ownership is retained by the PCC. In 683 particular, in addition to specifying values for LSP's attributes, an 684 active stateful PCE also decides when to make LSP modifications. 686 Retaining LSP state ownership on the PCC allows for: 688 o a PCC to interact with both stateless and stateful PCEs at the 689 same time 691 o a stateful PCE to only modify a small subset of LSP parameters, 692 i.e. to set only a small subset of the overall LSP state; other 693 parameters may be set by the operator through CLI commands 695 o a PCC to revert delegated LSP to an operator-defined default or to 696 delegate the LSPs to a different PCE, if the PCC get disconnected 697 from a PCE with currently delegated LSPs 699 5.2. New Messages 701 In this document, we define the following new PCEP messages: 703 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 704 to a PCE to report the status of one or more LSPs. Each LSP 705 Status Report in a PCRpt message can contain the actual LSP's 706 path,bandwidth, operational and administrative status, etc. An 707 LSP Status Report carried on a PCRpt message is also used in 708 delegation or revocation of control of an LSP to/from a PCE. The 709 PCRpt message is described in Section 6.1. 711 Path Computation Update Request (PCUpd): a PCEP message sent by a 712 PCE to a PCC to update LSP parameters, on one or more LSPs. Each 713 LSP Update Request on a PCUpd message MUST contain all LSP 714 parameters that a PCE wishes to set for a given LSP. An LSP 715 Update Request carried on a PCUpd message is also used to return 716 LSP delegations if at any point PCE no longer desires control of 717 an LSP. The PCUpd message is described in Section 6.2. 719 The new functions defined in Section 4 are mapped onto the new 720 messages as shown in the following table. 722 +----------------------------------------+--------------------------+ 723 | Function | Message | 724 +----------------------------------------+--------------------------+ 725 | Capability Negotiation (E-C,C-E) | Open | 726 | State Synchronization (C-E) | PCRpt | 727 | LSP State Report (C-E) | PCRpt | 728 | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | 729 | LSP Update Request (E-C) | PCUpd | 730 | ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS | 731 | | sub-TLV | 732 | OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, | 733 | | PCE-CAP-FLAGS sub-TLV | 734 +----------------------------------------+--------------------------+ 735 Table 12: New Function to Message Mapping 737 5.3. Capability Negotiation 739 During PCEP Initialization Phase, PCEP Speakers (PCE pr PCC) 740 negotiate the use of stateful PCEP extensions. A PCEP Speaker 741 includes the "Stateful PCE Capability" TLV, described in 742 Section 7.1.1, in the OPEN Object to advertise its support for PCEP 743 stateful extensions. The Stateful Capability TLV includes the 'LSP 744 Update' Flag that indicates whether the PCEP Speaker supports LSP 745 parameter updates. 747 The presence of the Stateful PCE Capability TLV in PCC's OPEN Object 748 indicates that the PCC is willing to send LSP State Reports whenever 749 LSP parameters or operational status changes. 751 The presence of the Stateful PCE Capability TLV in PCE's OPEN message 752 indicates that the PCE is interested in receiving LSP State Reports 753 whenever LSP parameters or operational status changes. 755 The PCEP protocol extensions for stateful PCEs MUST not be used if 756 one or both PCEP Speakers have not included the Stateful PCE 757 Capability TLV in their respective OPEN message, otherwise a PCErr 758 with code "Stateful PCE capability not negotiated" (see Section 8.4) 759 will be generated and the PCEP session will be terminated. 761 LSP delegation and LSP update operations defined in this document MAY 762 only be used if both PCEP Speakers set the LSP-UPDATE Flag in the 763 "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)', 764 otherwise a PCErr with code "Delegation not negotiated" (see 765 Section 8.4) will be generated. Note that even if the update 766 capability has not been negotiated, a PCE can still receive LSP 767 Status Reports from a PCC and build and maintain an up to date view 768 of the state of the PCC's LSPs. 770 5.4. State Synchronization 772 The purpose of State Synchronization is to provide a checkpoint-in- 773 time state replica of a PCC's LSP state in a PCE. State 774 Synchronization is performed immediately after the Initialization 775 phase ([RFC5440]). 777 During State Synchronization, a PCC first takes a snapshot of the 778 state of its LSPs state, then sends the snapshot to a PCE in a 779 sequence of LSP State Reports. Each LSP State Report sent during 780 State Synchronization has the SYNC Flag in the LSP Object set to 1. 781 The set of LSPs for which state is synchronized with a PCE is 782 determined by negotiated stateful PCEP capabilities and PCC's local 783 configuration (see more details in Section 9.1). 785 A PCE SHOULD NOT send PCUpd messages to a PCC before State 786 Synchronization is complete. A PCC SHOULD NOT send PCReq messages to 787 a PCE before State Synchronization is complete. This is to allow the 788 PCE to get the best possible view of the network before it starts 789 computing new paths. 791 If the PCC encounters a problem which prevents it from completing the 792 state transfer, it MUST send a PCErr message to the PCE and terminate 793 the session using the PCEP session termination procedure. 795 The PCE does not send positive acknowledgements for properly received 796 synchronization messages. It MUST respond with a PCErr message 797 indicating "PCRpt error" (see Section 8.4) if it encounters a problem 798 with the LSP State Report it received from the PCC. Either the PCE 799 or the PCC MAY terminate the session if the PCE encounters a problem 800 during the synchronization. 802 The successful State Synchronization sequence is shown in Figure 3. 804 +-+-+ +-+-+ 805 |PCC| |PCE| 806 +-+-+ +-+-+ 807 | | 808 |-----PCRpt, SYNC=1----->| (Sync start) 809 | | 810 |-----PCRpt, SYNC=1----->| 811 | . | 812 | . | 813 | . | 814 |-----PCRpt, SYNC=1----->| (Sync done) 815 | . | 816 | . | 817 | . | 818 | | 819 |-----PCRpt, SYNC=0----->| (Regular 820 | | LSP State Report) 822 Figure 3: Successful state synchronization 824 The sequence where the PCE fails during the State Synchronization 825 phase is shown in Figure 4. 827 +-+-+ +-+-+ 828 |PCC| |PCE| 829 +-+-+ +-+-+ 830 | | 831 |-----PCRpt, SYNC=1----->| 832 | | 833 |-----PCRpt, SYNC=1----->| 834 | . | 835 | . | 836 | . | 837 |-----PCRpt, SYNC=1----->| 838 | | 839 |-PCRpt, SYNC=1 | 840 | \ ,-PCErr=?-| 841 | \ / | 842 | \/ | 843 | /\ | 844 | / `-------->| (Ignored) 845 |<--------` | 847 Figure 4: Failed state synchronization (PCE failure) 849 The sequence where the PCC fails during the State Synchronization 850 phase is shown in Figure 5. 852 +-+-+ +-+-+ 853 |PCC| |PCE| 854 +-+-+ +-+-+ 855 | | 856 |-----PCRpt, SYNC=1----->| 857 | | 858 |-----PCRpt, SYNC=1----->| 859 | . | 860 | . | 861 | . | 862 |-------- PCErr=? ------>| 863 | | 865 Figure 5: Failed state synchronization (PCC failure) 867 5.4.1. State Synchronization Avoidance 869 State Synchronization MAY be skipped following a PCEP session restart 870 if the state of both PCEP peers did not change during the period 871 prior to session re-initialization. To be able to make this 872 determination, state must be exchanged and maintained by both PCE and 873 PCC during normal operation. This is accomplished by keeping track 874 of the changes to the LSP State Database. When State Synchronization 875 avoidance is enabled on a PCEP session, a PCC includes the LSP-DB- 876 VERSION TLV as an optional TLV in the LSP Object on each LSP State 877 Report. The LSP-DB-VERSION TLV contains a PCC's LSP State Database 878 version, which is incremented each time a change is made to the PCC's 879 local LSP State Database. The LSP State Database version is an 880 unsigned 64-bit value that MUST be incremented by 1 for each 881 successive change in the LSP state database. The LSP State Database 882 version MUST start at 1 and may wrap around. Values 0 and 883 0xFFFFFFFFFFFFFFF are reserved. 885 State Synchronization Avoidance is negotiated on a PCEP session 886 during session startup. To make sure that a PCEP peer can recognize 887 a previously connected peer even if its IP address changed, each PCEP 888 peer includes the NODE_IDENTIFIER TLV in the OPEN message. 890 If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN 891 object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the 892 LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the 893 PCC's latest LSP State Database version. 895 If a PCE's LSP State Database survived the restart of a PCEP session, 896 the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and 897 the TLV will contain the last LSP State Database version received on 898 an LSP State Update from the PCC in a previous PCEP session. If a 899 PCC's LSP State Database survived the restart, the PCC will include 900 the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain 901 the last LSP State Database version sent on an LSP State Update from 902 the PCC in the previous PCEP session. If a PCEP Speaker's LSP State 903 Database did not survive the restart of a PCEP session, the PCEP 904 Speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN Object. 906 If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN 907 Object and the TLV values match, the PCC MAY skip State 908 Synchronization. Otherwise, the PCE MUST purge any remaining LSP 909 state and expect the PCC to perform State Synchronization; if the PCC 910 attempts to skip State Synchronization (i.e. the SYNC Flag = 0 on the 911 first LSP State Report from the PCC), the PCE MUST send back a 912 PCError with Error-type 20 Error-value 2 'LSP Database version 913 mismatch', and close the PCEP session. 915 Note that a PCE MAY force State Synchronization by not including the 916 LSP-DB-VERSION TLV in its OPEN object. 918 Figure 6 shows an example sequence where State Synchronization is 919 skipped. 921 +-+-+ +-+-+ 922 |PCC| |PCE| 923 +-+-+ +-+-+ 924 | | 925 |--Open--, | 926 | DBv=42 \ ,---Open--| 927 | IDB=1 \ / DBv=42 | 928 | \/ IDB=1 | 929 | /\ | 930 | / `-------->| (OK to skip sync) 931 (Skip sync) |<--------` | 932 | . | 933 | . | 934 | . | 935 | | 936 |--PCRpt,DBv=43,SYNC=0-->| (Regular 937 | | LSP State Update) 938 |--PCRpt,DBv=44,SYNC=0-->| (Regular 939 | | LSP State Update) 940 |--PCRpt,DBv=45,SYNC=0-->| 941 | | 943 Figure 6: State Synchronization skipped 945 Figure 7 shows an example sequence where State Synchronization is 946 performed due to LSP State Database version mismatch during the PCEP 947 session setup. Note that the same State Synchronization sequence 948 would happen if either the PCE or the PCE would not include the LSP- 949 DB-VERSION TLV in their respective Open messages. 951 +-+-+ +-+-+ 952 |PCC| |PCE| 953 +-+-+ +-+-+ 954 | | 955 |--Open--, | 956 | DBv=46 \ ,---Open--| 957 | IDB=1 \ / DBv=42 | 958 | \/ IDB=1 | 959 | /\ | 960 | / `-------->| (Expect sync) 961 (Do sync) |<--------` | (Purge LSP State) 962 | | 963 |--PCRpt,DBv=46,SYNC=1-->| (Sync start) 964 | . | 965 | . | 966 | . | 967 |--PCRpt,DBv=46,SYNC=1-->| (Sync done) 968 | . | 969 | . | 970 | . | 971 |--PCRpt,DBv=47,SYNC=0-->| (Regular 972 | | LSP State Update) 973 |--PCRpt,DBv=48,SYNC=0-->| (Regular 974 | | LSP State Update) 975 |--PCRpt,DBv=49,SYNC=0-->| 976 | | 978 Figure 7: State Synchronization performed 980 Figure 8 shows an example sequence where State Synchronization is 981 skipped, but because one or both PCEP Speakers set the INCLUDE-DB- 982 VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the 983 PCE. If the current PCEP session restarts, the PCEP Speakers will 984 have to perform State Synchronization, since the PCE will not know 985 the PCC's latest LSP State Database version. 987 +-+-+ +-+-+ 988 |PCC| |PCE| 989 +-+-+ +-+-+ 990 | | 991 |--Open--, | 992 | DBv=42 \ ,---Open--| 993 | IDB=0 \ / DBv=42 | 994 | \/ IDB=0 | 995 | /\ | 996 | / `-------->| (OK to skip sync) 997 (Skip sync) |<--------` | 998 | . | 999 | . | 1000 | . | 1001 |------PCRpt,SYNC=0----->| (Regular 1002 | | LSP State Update) 1003 |------PCRpt,SYNC=0----->| (Regular 1004 | | LSP State Update) 1005 |------PCRpt,SYNC=0----->| 1006 | | 1008 Figure 8: State Synchronization skipped, no LSP-DB-VERSION TLVs sent 1009 from PCC 1011 5.5. LSP Delegation 1013 If during Capability negotiation both the PCE and the PCC have 1014 indicated that they support LSP Update, then the PCC may choose to 1015 grant the PCE a temporary right to update (a subset of) LSP 1016 attributes on one or more LSPs. This is called "LSP Delegation", and 1017 it MAY be performed at any time after the Initialization phase. 1019 LSP Delegation is controlled by operator-defined policies on a PCC. 1020 LSPs are delegated individually - different LSPs may be delegated to 1021 different PCEs, and an LSP may be delegated to one or more PCEs. The 1022 delegation policy, when all PCC's LSPs are delegated to a single PCE 1023 at any given time, SHOULD be supported by all delegation-capable 1024 PCCs. Conversely, the policy revoking the delegation for all PCC's 1025 LSPs SHOULD also be supported 1027 A PCE may return LSP delegation at any time if it no longer wishes to 1028 update the LSP's state. A PCC may revoke LSP delegation at any time. 1029 Delegation, Revocation, and Return are done individually for each 1030 LSP. 1032 5.5.1. Delegating an LSP 1034 A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP 1035 State Report to 1. A PCE confirms the delegation when it sends the 1036 first LSP Update Request for the delegated LSP to the PCC by setting 1037 the Delegate flag to 1. Note that a PCE does not immediately confirm 1038 to the PCC the acceptance of LSP Delegation; Delegation acceptance is 1039 confirmed when the PCC wishes to update the LSP via the LSP Update 1040 Request. If a PCE does not accept the LSP Delegation, it MUST 1041 immediately respond with an empty LSP Update Request which has the 1042 Delegate flag set to 0. 1044 The delegation sequence is shown in Figure 9. 1046 +-+-+ +-+-+ 1047 |PCC| |PCE| 1048 +-+-+ +-+-+ 1049 | | 1050 |---PCRpt, Delegate=1--->| LSP Delegated 1051 | | 1052 |---PCRpt, Delegate=1--->| 1053 | . | 1054 | . | 1055 | . | 1056 |<--(PCUpd,Delegate=1)---| Delegation confirmed 1057 | | 1058 |---PCRpt, Delegate=1--->| 1059 | | 1061 Figure 9: Delegating an LSP 1063 Note that for an LSP to remain delegated to a PCE, the PCC MUST set 1064 the Delegate flag to 1 on each LSP Status Report sent to the PCE. 1066 5.5.2. Revoking a Delegation 1068 When a PCC decides that a PCE is no longer permitted to modify an 1069 LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke 1070 an LSP delegation at any time during the LSP's life time. A PCC 1071 revoking a LSP MAY immediately clear the LSP state provided by the 1072 PCE, and MUST ignore any further PCUpd messages received regarding 1073 the revoked LSP from the previous PCE delegate. 1075 If a PCEP session with the PCE to which the LSP is delegated exists 1076 in the UP state during the revocation, the PCC MUST notify that PCE 1077 by sending an LSP State Report with the Delegate flag set to 0, as 1078 shown in Figure 10. 1080 +-+-+ +-+-+ 1081 |PCC| |PCE| 1082 +-+-+ +-+-+ 1083 | | 1084 |---PCRpt, Delegate=1--->| 1085 | | 1086 |<--(PCUpd,Delegate=1)---| Delegation confirmed 1087 | . | 1088 | . | 1089 | . | 1090 |---PCRpt, Delegate=0--->| PCC revokes delegation 1091 | | 1093 Figure 10: Revoking a Delegation 1095 After an LSP delegation has been revoked, a PCE can no longer update 1096 LSP's parameters; an attempt to update parameters of a non-delegated 1097 LSP will result in the PCC sending a PCErr message indicating "LSP is 1098 not delegated" (see Section 8.4). 1100 When a PCC's PCEP session with a PCE terminates, the PCC SHALL wait a 1101 time interval specified in 'Delegation Timeout Interval' before 1102 revoking LSP delegations to the PCE. If a new PCEP session with the 1103 PCE can be established before the 'Delegation Timeout' timer expires, 1104 LSP delegations to the PCE remain intact. If, after expiry of the 1105 'Delegation Timeout' timer, a PCC can not delegate an LSP to another 1106 PCE (for example, if a PCC is not connected to any active stateful 1107 PCE or if no connected active stateful PCE accepts the delegation), 1108 the PCC SHALL flush any LSP state set by the PCE. 1110 If State Synchronization Avoidance is enabled, a PCC MUST increment 1111 its LSP State Database version when the 'Delegation Timeout' timer 1112 expires. 1114 5.5.3. Returning a Delegation 1116 A PCE that no longer wishes to update an LSP's parameters SHOULD 1117 return the LSP delegation back to the PCC by sending an empty LSP 1118 Update Request which has the Delegate flag set to 0. Note that in 1119 order to keep a delegation, the PCE MUST set the Delegate flag to 1 1120 on each LSP Update Request sent to the PCC. 1122 +-+-+ +-+-+ 1123 |PCC| |PCE| 1124 +-+-+ +-+-+ 1125 | | 1126 |---PCRpt, Delegate=1--->| LSP delegated 1127 | . | 1128 | . | 1129 | . | 1130 |<--PCUpd, Delegate=0----| Delegation returned 1131 | | 1132 |---PCRpt, Delegate=0--->| No delegation for LSP 1133 | | 1135 Figure 11: Returning a Delegation 1137 If a PCC can not delegate an LSP to a PCE (for example, if a PCC is 1138 not connected to any active stateful PCE or if no connected active 1139 stateful PCE accepts the delegation), the LSP delegation on the PCC 1140 will time out within a configurable Delegation Timeout Interval and 1141 the PCC MUST flush any LSP state set by a PCE. 1143 5.5.4. Redundant Stateful PCEs 1145 Note that a PCE may not have any delegated LSPs: in a redundant 1146 configuration where one PCE is backing up another PCE, the backup PCE 1147 will not have any delegated LSPs. The backup PCE does not update any 1148 LSPs, but it receives all LSP State Reports from a PCC. When the 1149 primary PCE fails, a PCC will delegate to the secondary PCE all LSPs 1150 that had been previously delegated to the failed PCE. 1152 5.6. LSP Operations 1153 5.6.1. Passive Stateful PCE Path Computation Request/Response 1155 +-+-+ +-+-+ 1156 |PCC| |PCE| 1157 +-+-+ +-+-+ 1158 | | 1159 1) Path computation |----- PCReq message --->| 1160 request sent to | |2) Path computation 1161 PCE | | request received, 1162 | | path computed 1163 | | 1164 |<---- PCRep message ----|3) Computed paths 1165 | (Positive reply) | sent to the PCC 1166 | (Negative reply) | 1167 4) LSP Status change| | 1168 event | | 1169 | | 1170 5) LSP Status Report|----- PCRpt message --->| 1171 sent to all | . | 1172 stateful PCEs | . | 1173 | . | 1174 6) Repeat for each |----- PCRpt message --->| 1175 LSP status change| | 1176 | | 1178 Figure 12: Passive Stateful PCE Path Computation Request/Response 1180 Once a PCC has successfully established a PCEP session with a passive 1181 stateful PCE and the PCC's LSP state is synchronized with the PCE 1182 (i.e. the PCE knows about all PCC's existing LSPs), if an event is 1183 triggered that requires the computation of a set of paths, the PCC 1184 sends a path computation request to the PCE ([RFC5440], Section 1185 4.2.3). The PCReq message MAY contain the LSP Object to identify the 1186 LSP for which the path computation is requested. 1188 Upon receiving a path computation request from a PCC, the PCE 1189 triggers a path computation and returns either a positive or a 1190 negative reply to the PCC ([RFC5440], Section 4.2.4). 1192 Upon receiving a positive path computation reply, the PCC receives a 1193 set of computed paths and starts to setup the LSPs. For each LSP, it 1194 sends an LSP State Report carried on a PCRpt message to the PCE, 1195 indicating that the LSP's status is 'Pending'. 1197 Once an LSP is up, the PCC sends an LSP State Report carried on a 1198 PCRpt message to the PCE, indicating that the LSP's status is 'Up'. 1199 If the LSP could not be set up, the PCC sends an LSP State Report 1200 indicating that the LSP is "Down' and stating the cause of the 1201 failure. Note that due to timing constraints, the LSP status may 1202 change from 'Pending' to 'Up' (or 'Down') before the PCC has had a 1203 chance to send an LSP State Report indicating that the status is 1204 'Pending'. In such cases, the PCC may choose to only send the PCRpt 1205 indicating the latest status ('Up' or 'Down'). 1207 Upon receiving a negative reply from a PCE, a PCC may decide to 1208 resend a modified request or take any other appropriate action. For 1209 each requested LSP, it also sends an LSP State Report carried on a 1210 PCRpt message to the PCE, indicating that the LSP's status is 'Down'. 1212 There is no direct correlation between PCRep and PCRpt messages. For 1213 a given LSP, multiple LSP State Reports will follow a single PC 1214 Reply, as a PCC notifies a PCE of the LSP's state changes. 1216 A PCC sends each LSP State Report to each stateful PCE that is 1217 connected to the PCC. 1219 Note that a single PCRpt message MAY contain multiple LSP State 1220 Reports. 1222 The passive stateful PCE is the model for stateful PCEs is described 1223 in [RFC4655], Section 6.8. 1225 5.6.2. Active Stateful PCE LSP Update 1227 +-+-+ +-+-+ 1228 |PCC| |PCE| 1229 +-+-+ +-+-+ 1230 | | 1231 1) LSP State |-- PCRpt, Delegate=1 -->| 1232 Synchronization | . | 1233 or add new LSP | . |2) PCE decides to 1234 | . | update the LSP 1235 | | 1236 |<---- PCUpd message ----|3) PCUpd message sent 1237 | | to PCC 1238 | | 1239 | | 1240 4) LSP Status Report|---- PCRpt message ---->| 1241 sent(->Pending) | . | 1242 | . | 1243 | . | 1244 5) LSP Status Report|---- PCRpt message ---->| 1245 sent (->Up|Down) | | 1246 | | 1248 Figure 13: Active Stateful PCE 1250 Once a PCC has successfully established a PCEP session with an active 1251 stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. 1252 the PCE knows about all PCC's existing LSPs) and LSPs have been 1253 delegated to the PCE, the PCE can modify LSP parameters of delegated 1254 LSPs. 1256 A PCE sends an LSP Update Request carried on a PCUpd message to the 1257 PCC. The LSP Update Request contains a variety of objects that 1258 specify the set of constraints and attributes for the LSP's path. 1259 Additionally, the PCC may specify the urgency of such request by 1260 assigning a request priority. A single PCUpd message MAY contain 1261 multiple LSP Update Requests. 1263 Upon receiving a PCUpd message the PCC starts to setup LSPs specified 1264 in LSP Update Requests carried in the message. For each LSP, it 1265 sends an LSP State Report carried on a PCRpt message to the PCE, 1266 indicating that the LSP's status is 'Pending'. 1268 Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) 1269 to the PCE, indicating that the LSP's status is 'Up'. If the LSP 1270 could not be set up, the PCC sends an LSP State Report indicating 1271 that the LSP is 'Down' and stating the cause of the failure. A PCC 1272 may choose to compress LSP State Updates to only reflect the most up 1273 to date state, as discussed in the previous section. 1275 A PCC sends each LSP State Report to each stateful PCE that is 1276 connected to the PCC. 1278 A PCC MUST NOT send to any PCE a Path Computation Request for a 1279 delegated LSP. 1281 5.7. LSP Protection 1283 With a stateless PCE or a passive stateful PCE, LSP protection and 1284 restoration settings may be operator-configured locally at a PCC. A 1285 PCE may be merely asked to compute the protected (primary) and backup 1286 (secondary) paths for the LSP. 1288 An active stateful PCE controls the LSPs that are delegated to it, 1289 and must therefore be able to set via PCEP the desired protection / 1290 restoration mechanism for each delegated LSP. PCEP extensions for 1291 stateful PCEs SHOULD support, at a minimum, the following protection 1292 mechanisms: 1294 o MPLS TE Global Default Restoration 1296 o MPLS TE Global Path Protection 1297 o FRR One-to-One Backup 1299 o FRR Facility Backup - link protection, node protection, or both 1301 5.8. Transport 1303 A Permanent PCEP session MUST be established between a stateful PCEs 1304 and the PCC. 1306 State cleanup after session termination, as well as session setup 1307 failures will be described in a later version of this document. 1309 6. PCEP Messages 1311 As defined in [RFC5440], a PCEP message consists of a common header 1312 followed by a variable-length body made of a set of objects that can 1313 be either mandatory or optional. An object is said to be mandatory 1314 in a PCEP message when the object must be included for the message to 1315 be considered valid. For each PCEP message type, a set of rules is 1316 defined that specify the set of objects that the message can carry. 1317 An implementation MUST form the PCEP messages using the object 1318 ordering specified in this document. 1320 6.1. The PCRpt Message 1322 A Path Computation LSP State Report message (also referred to as 1323 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 1324 current state of an LSP. A PCRpt message can carry more than one LSP 1325 State Reports. A PCC can send an LSP State Report either in response 1326 to an LSP Update Request from a PCE, or asynchronously when the state 1327 of an LSP changes. The Message-Type field of the PCEP common header 1328 for the PCRpt message is set to [TBD]. 1330 The format of the PCRpt message is as follows: 1332 ::= 1333 1334 Where: 1336 ::= [] 1338 ::= 1339 [] 1341 Where: 1343 ::=[] 1345 ::= 1347 Where: 1349 ::= [] 1350 [] 1351 [] 1352 [] 1354 ::= [] 1356 The LSP object (see Section 7.2) is mandatory, and it MUST be 1357 included in each LSP State Report on the PCRpt message. If the LSP 1358 object is missing, the receiving PCE MUST send a PCErr message with 1359 Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP 1360 object missing). 1362 The LSP State Report MAY contain a path descriptor for the primary 1363 path and one or more path descriptors for backup paths. A path 1364 descriptor MUST contain an ERO object as it was specified by a PCE or 1365 an operator. A path descriptor MUST contain the RRO object if a 1366 primary or secondary LSP is set up along the path in the network. A 1367 path descriptor MAY contain the LSPA, BANDWIDTH, and METRIC objects. 1368 The ERO,LSPA, BANDWIDTH, METRIC, and RRO objects are defined 1369 in[RFC5440]. 1371 6.2. The PCUpd Message 1373 A Path Computation LSP Update Request message (also referred to as 1374 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 1375 attributes of an LSP. A PCUpd message can carry more than one LSP 1376 Update Request. The Message-Type field of the PCEP common header for 1377 the PCRpt message is set to [TBD]. 1379 The format of a PCUpd message is as follows: 1381 ::= 1382 1383 Where: 1385 ::= [] 1387 ::= 1388 [] 1390 Where: 1392 ::=[] 1394 ::= 1396 Where: 1398 ::= [] 1399 [] 1400 [] 1402 ::= [] 1404 There is one mandatory object that MUST be included within each LSP 1405 Update Request in the PCUpd message: the LSP object (see 1406 Section 7.2). If the LSP object is missing, the receiving PCE MUST 1407 send a PCErr message with Error-type=6 (Mandatory Object missing) and 1408 Error-value=[TBD] (LSP object missing). 1410 The LSP Update Request MUST contain a path descriptor for the primary 1411 path, and MAY contain one or more path descriptors for backup paths. 1412 A path descriptor MUST contain an ERO object. A path descriptor MAY 1413 further contain the BANDWIDTH, IRO, and METRIC objects. The ERO, 1414 LSPA, BANDWIDTH, METRIC, and IRO objects are defined in [RFC5440]. 1416 Each LSP Update Request results in a separate LSP setup operation at 1417 a PCC. An LSP Update Request MUST contain all LSP parameters that a 1418 PCC wishes to set for the LSP. A PCC MAY set missing parameters from 1419 locally configured defaults. If the LSP specified the Update Request 1420 is already up, it will be re-signaled. The PCC will use make-before- 1421 break whenever possible in the re-signaling operation. 1423 A PCC MUST respond with an LSP State Report to each LSP Update 1424 Request to indicate the resulting state of the LSP in the network. A 1425 PCC MAY respond with multiple LSP State Reports to report LSP setup 1426 progress of a single LSP. 1428 If the rate of PCUpd messages sent to a PCC for the same target LSP 1429 exceeds the rate at which the PCC can signal LSPs into the network, 1430 the PCC MAY perform state compression and only re-signal the last 1431 modification in its queue. 1433 Note that a PCC MUST process all LSP Update Requests - for example, 1434 an LSP Update Request is sent when a PCE returns delegation or puts 1435 an LSP into non-operational state. The protocol relies on TCP for 1436 message-level flow control. 1438 Note also that it's up to the PCE to handle inter-LSP dependencies; 1439 for example, if ordering of LSP set-ups is required, the PCE has to 1440 wait for an LSP State Report for a previous LSP before triggering the 1441 LSP setup of a next LSP. 1443 6.3. The PCReq Message 1445 A PCC MAY include the LSP object in the PCReq message (see 1446 Section 7.2) if stateful PCE capability has been negotiated on a PCEP 1447 session between the PCC and a PCE. The definition of the PCReq 1448 message (see [RFC5440], Section 6.4) is then extended as follows: 1450 ::= 1451 [] 1452 1454 Where: 1456 ::=[] 1457 ::=[] 1459 ::= 1460 1461 [] <--- New Object 1462 [] 1463 [] 1464 [] 1465 [[]] 1466 [] 1467 [] 1469 Where: 1471 ::=[] 1473 6.4. The PCRep Message 1475 A PCE MAY include the LSP object in the PCRep message (see 1476 (Section 7.2) if stateful PCE capability has been negotiated on a 1477 PCEP session between the PCC and the PCE and the LSP object was 1478 included in the corresponding PCReq message from the PCC. The 1479 definition of the PCRep message (see [RFC5440], Section 6.5) is then 1480 extended as follows 1482 ::= 1483 1485 Where: 1487 ::=[] 1489 ::= 1490 [] <--- New Object 1491 [] 1492 [] 1493 [] 1495 ::=[] 1497 ::= 1499 Where: 1501 ::=[] 1502 [] 1503 [] 1504 [] 1506 ::=[] 1508 7. Object Formats 1510 The PCEP objects defined in this document are compliant with the PCEP 1511 object format defined in [RFC5440]. The P flag and the I flag of the 1512 PCEP objects defined in this document MUST always be set to 0 on 1513 transmission and MUST be ignored on receipt since these flags are 1514 exclusively related to path computation requests. 1516 7.1. OPEN Object 1518 This document defines a new optional TLV for the OPEN Object to 1519 support stateful PCE capability negotiation. 1521 7.1.1. Stateful PCE Capability TLV 1523 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 1524 following figure: 1526 0 1 2 3 1527 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 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Type=[TBD] | Length=4 | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | Flags |S|U| 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 Figure 14: STATEFUL-PCE-CAPABILITY TLV format 1536 The type of the TLV is [TBD] and it has a fixed length of 4 octets. 1538 The value comprises a single field - Flags (16 bits): 1540 U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag 1541 indicates that the PCC allows modification of LSP parameters; if 1542 set to 1 by a PCE, the U Flag indicates that the PCE wishes to 1543 update LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be 1544 advertised by both a PCC and a PCE for PCUpd messages to be 1545 allowed on a PCEP session. 1547 S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers, 1548 the PCC will include the LSP-DB-VERSION TLV in each LSP Object. 1550 Unassigned bits are considered reserved. They MUST be set to 0 on 1551 transmission and MUST be ignored on receipt. 1553 7.1.2. LSP State Database Version TLV 1555 LSP-DB-VERSION is an optional TLV that MAY be included in the OPEN 1556 Object when a PCEP Speaker wishes to determine if State 1557 Synchronization can be skipped when a PCEP session is restarted. If 1558 sent from a PCE, the TLV contains the local LSP State Database 1559 version from the last valid LSP State Report received from a PCC. If 1560 sent from a PCC, the TLV contains the PCC's local LSP State Database 1561 version, which is incremented each time the LSP State Database is 1562 updated. 1564 The format of the LSP-DB-VERSION TLV is shown in the following 1565 figure: 1567 0 1 2 3 1568 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 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Type=[TBD] | Length=8 | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | LSP State DB Version | 1573 | | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 Figure 15: LSP-DB-VERSION TLV format 1578 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 1579 The value contains a 64-bit unsigned integer. 1581 7.1.3. Node Identifier TLV 1583 NODE-IDENTIFIER is an optional TLV that MAY be included in the OPEN 1584 Object when a PCEP Speaker wishes to determine if State 1585 Synchronization can be skipped when a PCEP session is restarted. It 1586 contains a unique identifier for the node that does not change during 1587 the life time of the PCEP Speaker. It identifies the PCEP Speaker to 1588 its peers if the Speaker's IP address changed. 1590 The format of the NODE-IDENTIFIER TLV is shown in the following 1591 figure: 1593 0 1 2 3 1594 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 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | Type=[TBD] | Length (variable) | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | | 1599 // PCEP Speaker Node Identifier // 1600 | | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 Figure 16: NODE-IDENTIFIER TLV format 1605 The type of the TLV is [TBD] and it has a a variable length, which 1606 MUST be greater than 0. The value contains a node identifier that 1607 MUST be unique in the network. The node identifier MAY be configured 1608 by an operator. If the node identifier is not configured by the 1609 operator, it can be derived from a PCC's MAC address or serial 1610 number. 1612 7.2. LSP Object 1614 The LSP object MUST be present within PCRpt and PCUpd messages. The 1615 LSP object MAY be carried within PCReq and PCRep messages if the 1616 stateful PCE capability has been negotiated on the session. The LSP 1617 object contains a set of fields used to specify the target LSP, the 1618 operation to be performed on the LSP, and LSP Delegation. It also 1619 contains a flag indicating to a PCE that the LSP state 1620 synchronization is in progress. 1622 LSP Object-Class is [TBD]. 1624 LSP Object-Type is 1. 1626 The format of the LSP object body is shown in Figure 17: 1628 0 1 2 3 1629 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 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | LSP-ID | Flags |R|O|S|D| 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | | 1634 // Optional TLVs // 1635 | | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 Figure 17: The LSP Object format 1640 The LSP object body has a variable length and may contain additional 1641 TLVs. 1643 LSP-ID (20 bits): An identifier for the LSP. A PCC creates a unique 1644 LSP-ID for each LSP that is constant for the life time of a PCEP 1645 session. The mapping of the LSP Symbolic Name to LSP-ID is 1646 communicated to the PCE by sending a PCRpt message containing the 1647 'LSP Symbolic Name' TLV. All subsequent PCEP messages then address 1648 the LSP by the LSP-ID. 1650 Flags (12 bits): 1652 D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1 1653 indicates that the PCC is delegating the LSP to the PCE. On a 1654 PCUpd message, the D flag set to 1 indicates that the PCE is 1655 confirming the LSP Delegation. To keep an LSP delegated to the 1656 PCE, the PCC must set the D flag to 1 on each PCRpt message for 1657 the duration of the delegation - the first PCRpt with the D flag 1658 set to 0 revokes the delegation. To keep the delegation, the PCE 1659 must set the D flag to 1 on each PCUpd message for the duration of 1660 the delegation - the first PCUpd with the D flag set to 0 returns 1661 the delegation. 1663 S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSP State 1664 Report sent from a PCC during State Synchronization. The S Flag 1665 MUST be set to 0 otherwise. 1667 O (Operational - 1 bit): On PCRpt messages the O Flag indicates the 1668 LSP status. Value of '1' means that the LSP is operational, i.e. 1669 it is either being signaled or it is active. Value of '0' means 1670 that the LSP is not operational, i.e it is de-routed and the PCC 1671 is not attempting to set it up. On PCUpd messages the flag 1672 indicates the desired status for the LSP. Value of '1' means that 1673 the desired LSP state is operational, value of '0' means that the 1674 target LSP should be non-operational. Setting the LSP status from 1675 the PCE SHALL NOT override the operator: if a pce-controlled LSP 1676 has been configured to be non-operational, setting the LSP's 1677 status to '1' from an PCE will not make it operational. 1679 R (Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1680 LSP has been removed from the PCC. Upon receiving an LSP State 1681 Update with the R Flag set to 1, the PCE SHOULD remove all state 1682 related to the LSP from its database. 1684 Unassigned bits are considered reserved. They MUST be set to 0 on 1685 transmission and MUST be ignored on receipt. 1687 TLVs that are currently defined for the LSP Object are described in 1688 the following sections. 1690 7.2.1. The LSP Symbolic Name TLV 1692 Each LSP MUST have a symbolic name that is unique in the PCC. The 1693 LSP Symbolic Name MUST remain constant throughout an LSP's lifetime, 1694 which may span across multiple consecutive PCEP sessions and/or PCC 1695 restarts. The LSP Symbolic Name MAY be specified by an operator in a 1696 PCC's CLI configuration. If the operator does not specify a Symbolic 1697 Name for an LSP, the PCC MUST auto-generate one. 1699 The LSP-SYMBOLIC-NAME TLV MUST be included in the LSP State Report 1700 when during a given PCEP session an LSP is first reported to a PCE. 1701 A PCC sends to a PCE the first LSP State Report either during State 1702 Synchronization, or when a new LSP is configured at the PCC. LSP 1703 State Report MAY be included in subsequent LSP State Reports for the 1704 LSP. 1706 The format of the LSP-SYMBOLIC-NAME TLV is shown in the following 1707 figure: 1709 0 1 2 3 1710 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 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | Type=[TBD] | Length (variable) | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | | 1715 // Symbolic LSP Name // 1716 | | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 Figure 18: LSP-SYMBOLIC-NAME TLV format 1721 The type of the TLV is [TBD] and it has a variable length, which MUST 1722 be greater than 0. 1724 7.2.2. LSP Identifiers TLVs 1726 Whenever the value of an LSP identifier changes, a PCC MUST send out 1727 an LSP State Report, where the LSP Object carries the LSP Identifiers 1728 TLV that contains the new value. The LSP Identifiers TLV MUST also 1729 be included in the LSP object during state synchronization. There 1730 are two LSP Identifiers TLVs, one for IPv4 and one for IPv6. 1732 The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 1733 figure: 1735 0 1 2 3 1736 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 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | Type=[TBD] | Length=12 | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | IPv4 Tunnel Sender Address | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | LSP ID | Tunnel ID | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | Extended Tunnel ID | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 Figure 19: IPV4-LSP-IDENTIFIERS TLV format 1749 The type of the TLV is [TBD] and it has a fixed length of 12 octets. 1750 The value contains the following fields: 1752 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 1753 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 1754 Sender Template Object. 1756 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1757 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 1758 Object. 1760 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1761 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 1762 Tunnel ID remains constant over the life time of a tunnel. 1763 However, when Global Path Protection or Global Default Restoration 1764 is used, both the primary and secondary LSPs have their own Tunnel 1765 IDs. A PCC will report a change in Tunnel ID when traffic 1766 switches over from primary LSP to secondary LSP (or vice versa). 1768 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 1769 identifier defined in [RFC3209], Section 4.6.1.1 for the 1770 LSP_TUNNEL_IPv4 Session Object. 1772 The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following 1773 figure: 1775 0 1 2 3 1776 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 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | Type=[TBD] | Length=36 | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | | 1781 + + 1782 | IPv6 tunnel sender address | 1783 + (16 octets) + 1784 | | 1785 + + 1786 | | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | LSP ID | Tunnel ID | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | | 1791 + + 1792 | Extended Tunnel ID | 1793 + (16 octets) + 1794 | | 1795 + + 1796 | | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 Figure 20: IPV6-LSP-IDENTIFIERS TLV format 1801 The type of the TLV is [TBD] and it has a fixed length of 36 octets. 1802 The value contains the following fields: 1804 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 1805 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 1806 Sender Template Object. 1808 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1809 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 1810 Object. 1812 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1813 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 1814 Tunnel ID remains constant over the life time of a tunnel. 1815 However, when Global Path Protection or Global Default Restoration 1816 is used, both the primary and secondary LSPs have their own Tunnel 1817 IDs. A PCC will report a change in Tunnel ID when traffic 1818 switches over from primary LSP to secondary LSP (or vice versa). 1820 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 1821 identifier defined in [RFC3209], Section 4.6.1.2 for the 1822 LSP_TUNNEL_IPv6 Session Object. 1824 7.2.3. LSP Update Error Code TLV 1826 If an LSP Update Request failed, an LSP State Report MUST be sent to 1827 all connected stateful PCEs. LSP State Report MUST contain the LSP 1828 Update Error Code TLV, indicating the cause of the failure. 1830 The format of the LSP-UPDATE-ERROR-CODE TLV is shown in the following 1831 figure: 1833 0 1 2 3 1834 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 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | Type=[TBD] | Length=4 | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | Error Code | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 Figure 21: LSP-UPDATE-ERROR-CODE TLV format 1843 The type of the TLV is [TBD] and it has a fixed length of 4 octets. 1844 The value contains the error code that indicates the cause of the LSP 1845 setup failure. Error codes will be defined in a later revision of 1846 this document. 1848 7.2.4. RSVP ERROR_SPEC TLVs 1850 If the set up of an LSP failed at a downstream node which returned an 1851 ERROR_SPEC to the PCC, the ERROR_SPEC MUST be included in the LSP 1852 State Report. Depending on whether RSVP signaling was performed over 1853 IPv4 or IPv6, the LSP Object will contain an IPV4-ERROR_SPEC TLV or 1854 an IPV6-ERROR_SPEC TLV. 1856 The format of the IPV4-RSVP-ERROR-SPEC TLV is shown in the following 1857 figure: 1859 0 1 2 3 1860 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 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Type=[TBD] | Length=8 | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | | 1865 + IPv4 ERROR_SPEC object (rfc2205) + 1866 | | 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 Figure 22: IPV4-RSVP-ERROR-SPEC TLV format 1871 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 1872 The value contains the RSVP IPv4 ERROR_SPEC object defined in 1873 [RFC2205]. Error codes allowed in the ERROR_SPEC object are defined 1874 in [RFC2205] and [RFC3209]. 1876 The format of the IPV6-RSVP-ERROR-SPEC TLV is shown in the following 1877 figure: 1879 0 1 2 3 1880 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 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | Type=[TBD] | Length=20 | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | | 1885 // IPv6 ERROR_SPEC object (rfc2205) // 1886 | | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 Figure 23: IPV6-RSVP-ERROR-SPEC TLV format 1891 The type of the TLV is [TBD] and it has a fixed length of 20 octets. 1892 The value contains the RSVP IPv6 ERROR_SPEC object defined in 1893 [RFC2205]. Error codes allowed in the ERROR_SPEC object are defined 1894 in [RFC2205] and [RFC3209]. 1896 7.2.5. LSP State Database Version TLV 1898 The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP 1899 object. The LSP-DB-VERSION TLV is discussed in Section 5.4.1 which 1900 covers state synchronization avoidance. The format of the TLV is 1901 described in Section 7.1.2, where the details of its use in the OPEN 1902 message are listed. 1904 If State Synchronization Avoidance has been enabled on a PCEP session 1905 (as described in Section 5.4.1) , a PCC MUST include the LSP-DB- 1906 VERSION TLV in each LSP Object sent out on the session. If the TLV 1907 is missing, the PCE will generate an error with error-type 6 1908 (mandatory object missing) and Error Value 12 (LSP-DB-VERSION TLV 1909 missing) and close the session. If State Synchronization Avoidance 1910 has not been enabled on a PCEP session, the PCC SHOULD NOT include 1911 the LSP-DB-VERSION TLV in the LSP Object and the PCE SHOULD ignore it 1912 were it to receive one. 1914 Since a PCE does not send LSP updates to a PCC, a PCC should never 1915 encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were 1916 it to receive one from a PCE. 1918 7.2.6. Delegation Parameters TLVs 1920 Multiple delegation parameters, such as sub-delegation permissions, 1921 authentication parameters, etc. need to be communicated from a PCC to 1922 a PCE during the delegation operation. Delegation parameters will be 1923 carried in multiple delegation parameter TLVs, which will be defined 1924 in future revisions of this document. 1926 8. IANA Considerations 1928 This document requests IANA actions to allocate code points for the 1929 protocol elements defined in this document. Values shown here are 1930 suggested for use by IANA. 1932 8.1. PCEP Messages 1934 This document defines the following new PCEP messages: 1936 Value Meaning Reference 1937 10 Report This document 1938 11 Update This document 1940 8.2. PCEP Objects 1942 This document defines the following new PCEP Object-classes and 1943 Object-values: 1945 Object-Class Value Name Reference 1947 32 LSP This document 1948 Object-Type 1949 1 1951 8.3. LSP Object 1953 This document requests that a registry is created to manage the Flags 1954 field of the LSP object. New values are to be assigned by Standards 1955 Action [RFC5226]. Each bit should be tracked with the following 1956 qualities: 1958 o Bit number (counting from bit 0 as the most significant bit) 1960 o Capability description 1962 o Defining RFC 1964 The following values are defined in this document: 1966 Bit Description Reference 1968 28 Remove This document 1969 29 Operational This document 1970 30 SYNC This document 1971 31 Delegate This document 1973 8.4. PCEP-Error Object 1975 This document defines new Error-Type and Error-Value for the 1976 following new error conditions: 1978 Error-Type Meaning 1979 6 Mandatory Object missing 1980 Error-value=8: LSP Object missing 1981 Error-value=9: ERO Object missing for a path in an LSP 1982 Update Request where TE-LSP setup is 1983 requested 1984 Error-value=10: BANDWIDTH Object missing for a path in 1985 an LSP Update Request where TE-LSP 1986 setup is requested 1987 Error-value=11: LSPA Object missing for a path in an 1988 LSP Update Request where TE-LSP setup 1989 is requested 1991 Error-value=12: LSP-DB-VERSION TLV missing 1992 19 Invalid Operation 1993 Error-value=1: Attempted LSP Update Request for a non- 1994 delegated LSP. The PCEP-ERROR Object 1995 is followed by the LSP Object that 1996 identifies the LSP. 1997 Error-value=2: Attempted LSP Update Request if active 1998 stateful PCE capability was not 1999 negotiated active PCE. 2000 20 LSP State synchronization error. 2001 Error-value=1: A PCE indicates to a PCC that it can 2002 not process (an otherwise valid) LSP 2003 State Report. The PCEP-ERROR Object is 2004 followed by the LSP Object that 2005 identifies the LSP. 2006 Error-value=2: LSP Database version mismatch. 2007 Error-value=3: The LSP-DB-VERSION TLV Missing when 2008 State Synchronization Avoidance 2009 enabled. 2011 8.5. PCEP TLV Type Indicators 2013 This document defines the following new PCEP TLVs: 2015 Value Meaning Reference 2016 16 STATEFUL-PCE-CAPABILITY This document 2017 17 LSP-SYMBOLIC-NAME This document 2018 18 IPV4-LSP-IDENTIFIERS This document 2019 19 IPV6-LSP-IDENTIFIERS This document 2020 20 LSP-UPDATE-ERROR-CODE This document 2021 21 IPV4-RSVP-ERROR-SPEC This document 2022 22 IPV6-RSVP-ERROR-SPEC This document 2023 23 LSP-DB-VERSION This document 2025 8.6. STATEFUL-PCE-CAPABILITY TLV 2027 This document requests that a registry is created to manage the Flags 2028 field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New 2029 values are to be assigned by Standards Action [RFC5226]. Each bit 2030 should be tracked with the following qualities: 2032 o Bit number (counting from bit 0 as the most significant bit) 2034 o Capability description 2036 o Defining RFC 2038 The following values are defined in this document: 2040 Bit Description Reference 2042 30 INCLUDE-DB-VERSION This document 2043 31 LSP-UPDATE-CAPABILITY This document 2045 8.7. LSP-UPDATE-ERROR-CODE TLV 2047 This document requests that a registry is created to manage the Error 2048 Codes in the LSP-UPDATE-ERROR-CODE TLV. New values are to be 2049 assigned by Standards Action [RFC5226]. 2051 The following Error Codes are defined in this document: 2053 Value Meaning Reference 2055 1 LSP Setup failed outside of the node. Must This document 2056 be followed by the RSVP-ERROR-SPEC TLV, 2057 which indicates the failure cause. 2059 2 LSP not operational This document 2061 9. Manageability Considerations 2063 All manageability requirements and considerations listed in [RFC5440] 2064 apply to PCEP protocol extensions defined in this document. In 2065 addition, requirements and considerations listed in this section 2066 apply. 2068 9.1. Control Function and Policy 2070 In addition to configuring specific PCEP session parameters, as 2071 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 2072 allow configuring the stateful PCEP capability and the LSP Update 2073 capability. A PCC implementation SHOULD allow the operator to 2074 specify multiple candidate PCEs for and a delegation preference for 2075 each candidate PCE. A PCC SHOULD allow the operator to specify an 2076 LSP delegation policy where LSPs are delegated to the most-preferred 2077 online PCE. A PCC MAY allow the operator to specify different LSP 2078 delegation policies. 2080 A PCE or PCC implementation SHOULD allow the operator to configure a 2081 Node Identifier (Section 7.1.3). 2083 A PCC implementation which allows concurrent connections to multiple 2084 PCEs SHOULD allow the operator to group the PCEs by administrative 2085 domains and it MUST NOT advertise LSP existence and state to a PCE if 2086 the LSP is delegated to a PCE in a different group. 2088 A PCC implementation SHOULD allow the operator to specify whether the 2089 PCC will advertise LSP existence and state for LSPs that are not 2090 controlled by any PCE (for example, LSPs that are statically 2091 configured at the PCC). 2093 A PCC implementation SHOULD allow the operator to specify the 2094 Delegation Timeout Interval. The default value of the Delegation 2095 Timeout Interval SHOULD be set to 30 seconds. 2097 When an LSP can no longer be delegated to a PCE, after the expiration 2098 of the Delegation Timeout Interval, the LSP MAY either: 1) retain its 2099 current parameters or 2) revert to operator-defined default LSP 2100 parameters. This behavior SHOULD be configurable and in the case 2101 when (2) is supported, a PCC implementation MUST allow the operator 2102 to specify the default LSP parameters. 2104 A PCC implementation SHOULD allow the operator to specify delegation 2105 priority for PCEs. This effectively defines the primary PCE and one 2106 or more backup PCEs to which primary PCE's LSPs can be delegated when 2107 the primary PCE fails. 2109 Policies defined for stateful PCEs and PCCs should eventually fit in 2110 the Policy-Enabled Path Computation Framework defined in [RFC5394], 2111 and the framework should be extended to support Stateful PCEs. 2113 9.2. Information and Data Models 2115 PCEP session configuration and information in the PCEP MIB module 2116 SHOULD be extended to include negotiated stateful capabilities, 2117 synchronization status, and delegation status (at the PCC list PCEs 2118 with delegated LSPs). 2120 9.3. Liveness Detection and Monitoring 2122 PCEP protocol extensions defined in this document do not require any 2123 new mechanisms beyond those already defined in [RFC5440], Section 2124 8.3. 2126 9.4. Verifying Correct Operation 2128 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 2129 protocol extensions defined in this document. In addition to 2130 monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP 2131 implementation SHOULD provide the following parameters: 2133 o Total number of LSP updates 2134 o Number of successful LSP updates 2136 o Number of dropped LSP updates 2138 o Number of LSP updates where LSP setup failed 2140 A PCC implementation SHOULD provide a command to show to which PCEs 2141 LSPs are delegated. 2143 A PCC implementation SHOULD allow the operator to manually revoke LSP 2144 delegation. 2146 9.5. Requirements on Other Protocols and Functional Components 2148 PCEP protocol extensions defined in this document do not put new 2149 requirements on other protocols. 2151 9.6. Impact on Network Operation 2153 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 2154 protocol extensions defined in this document. 2156 Additionally, a PCEP implementation SHOULD allow a limit to be placed 2157 on the rate PCUpd and PCRpt messages sent by a PCEP speaker and 2158 processed from a peer. It SHOULD also allow sending a notification 2159 when a rate threshold is reached. 2161 A PCC implementation SHOULD allow a limit to be placed on the rate of 2162 LSP Updates to the same LSP to avoid signaling overload discussed in 2163 Section 10.3. 2165 10. Security Considerations 2167 10.1. Vulnerability 2169 This document defines extensions to PCEP to enable stateful PCEs. 2170 The nature of these extensions and the delegation of path control to 2171 PCEs results in more information being available for a hypothetical 2172 adversary and a number of additional attack surfaces which must be 2173 protected. 2175 The security provisions described in [RFC5440] remain applicable to 2176 these extensions. However, because the protocol modifications 2177 outlined in this document allow the PCE to control path computation 2178 timing and sequence, the PCE defense mechanisms described in 2179 [RFC5440] section 7.2 are also now applicable to PCC security. 2181 As a general precaution, it is RECOMMENDED that these PCEP extensions 2182 only be activated on authenticated and encrypted sessions across PCEs 2183 and PCCs belonging to the same administrative authority. 2185 The following sections identify specific security concerns that may 2186 result from the PCEP extensions outlined in this document along with 2187 recommended mechanisms to protect PCEP infrastructure against related 2188 attacks. 2190 10.2. LSP State Snooping 2192 The stateful nature of this extension explicitly requires LSP status 2193 updates to be sent from PCC to PCE. While this gives the PCE the 2194 ability to provide more optimal computations to the PCC, it also 2195 provides an adversary with the opportunity to eavesdrop on decisions 2196 made by network systems external to PCE. This is especially true if 2197 the PCC delegates LSPs to multiple PCEs simultaneously. 2199 Adversaries may gain access to this information by eavesdropping on 2200 unsecured PCEP sessions, and might then use this information in 2201 various ways to target or optimize attacks on network infrastructure. 2202 For example by flexibly countering anti-DDoS measures being taken to 2203 protect the network, or by determining choke points in the network 2204 where the greatest harm might be caused. 2206 PCC implementations which allow concurrent connections to multiple 2207 PCEs SHOULD allow the operator to group the PCEs by administrative 2208 domains and they MUST NOT advertise LSP existence and state to a PCE 2209 if the LSP is delegated to a PCE in a different group. 2211 10.3. Malicious PCE 2213 The LSP delegation mechanism described in this document allows a PCC 2214 to grant effective control of an LSP to the PCE for the duration of a 2215 PCEP session. While this enables PCE control of the timing and 2216 sequence of path computations within and across PCEP sessions, it 2217 also introduces a new attack vector: an attacker may flood the PCC 2218 with PCUpd messages at a rate which exceeds either the PCC's ability 2219 to process them or the network's ability to signal the changes, 2220 either by spoofing messages or by compromising the PCE itself. 2222 A PCC is free to revoke an LSP delegation at any time without needing 2223 any justification. A defending PCC can do this by enqueueing the 2224 appropriate PCRpt message. As soon as that message is enqueued in 2225 the session, the PCC is free to drop any incoming PCUpd messages 2226 without additional processing. 2228 10.4. Malicious PCC 2230 A stateful session also result in increased attack surface by placing 2231 a requirement for the PCE to keep an LSP state replica for each PCC. 2232 It is RECOMMENDED that PCE implementations provide a limit on 2233 resources a single PCC can occupy. 2235 Delegation of LSPs can create further strain on PCE resources and a 2236 PCE implementation MAY preemptively give back delegations if it finds 2237 itself lacking the resources needed to effectively manage the 2238 delegation. Since the delegation state is ultimately controlled by 2239 the PCC, PCE implementations SHOULD provide throttling mechanisms to 2240 prevent strain created by flaps of either a PCEP session or an LSP 2241 delegation. 2243 11. Acknowledgements 2245 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 2246 Casellas for their contributions to this document. 2248 We would like to thank Shane Amante,Julien Meuric, Kohei Shiomoto, 2249 Paul Schultz and Raveendra Torvi for their comments and suggestions. 2250 Thanks also to Dhruv Dhoddy, Oscar Gonzales de Dios, Tomas Janciga, 2251 Stefan Kobza and Kexin Tang for helpful discussions. 2253 12. References 2255 12.1. Normative References 2257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2258 Requirement Levels", BCP 14, RFC 2119, March 1997. 2260 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2261 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2262 Functional Specification", RFC 2205, September 1997. 2264 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2265 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2266 Tunnels", RFC 3209, December 2001. 2268 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 2269 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 2270 May 2005. 2272 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 2273 "OSPF Protocol Extensions for Path Computation Element 2274 (PCE) Discovery", RFC 5088, January 2008. 2276 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 2277 "IS-IS Protocol Extensions for Path Computation Element 2278 (PCE) Discovery", RFC 5089, January 2008. 2280 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2281 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2282 May 2008. 2284 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 2285 (PCE) Communication Protocol (PCEP)", RFC 5440, 2286 March 2009. 2288 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2289 Used to Form Encoding Rules in Various Routing Protocol 2290 Specifications", RFC 5511, April 2009. 2292 12.2. Informative References 2294 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2295 LSP Path Computation using Preemption", Global 2296 Information Infrastructure Symposium, July 2007. 2298 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2299 programming algorithm for balancing the max-min fairness 2300 and throughput objectives in traffic engineering", pre- 2301 print, 2011. 2303 [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network 2304 Recovery: Protection and Restoration of Optical, SONET- 2305 SDH, IP, and MPLS", The Morgan Kaufmann Series in 2306 Networking, June 2004. 2308 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2309 McManus, "Requirements for Traffic Engineering Over MPLS", 2310 RFC 2702, September 1999. 2312 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2313 Label Switching Architecture", RFC 3031, January 2001. 2315 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2316 Christian, B., and W. Lai, "Applicability Statement for 2317 Traffic Engineering with MPLS", RFC 3346, August 2002. 2319 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2320 (TE) Extensions to OSPF Version 2", RFC 3630, 2321 September 2003. 2323 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2324 Element (PCE)-Based Architecture", RFC 4655, August 2006. 2326 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 2327 Communication Protocol Generic Requirements", RFC 4657, 2328 September 2006. 2330 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2331 Engineering", RFC 5305, October 2008. 2333 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2334 "Policy-Enabled Path Computation Framework", RFC 5394, 2335 December 2008. 2337 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 2338 Computation Element Communication Protocol (PCEP) 2339 Requirements and Protocol Extensions in Support of Global 2340 Concurrent Optimization", RFC 5557, July 2009. 2342 Authors' Addresses 2344 Edward Crabbe 2345 Google, Inc. 2346 1600 Amphitheatre Parkway 2347 Mountain View, CA 94043 2348 US 2350 Email: edc@google.com 2352 Jan Medved 2353 Cisco Systems, Inc. 2354 170 West Tasman Dr. 2355 San Jose, CA 95134 2356 US 2358 Email: jmedved@cisco.com 2360 Robert Varga 2361 Pantheon Technologies SRO 2362 Mlynske Nivy 56 2363 Bratislava 821 05 2364 Slovakia 2366 Email: robert.varga@pantheon.sk 2367 Ina Minei 2368 Juniper Networks, Inc. 2369 1194 N. Mathilda Ave. 2370 Sunnyvale, CA 94089 2371 US 2373 Email: ina@juniper.net