idnits 2.17.1 draft-ietf-pce-stateful-pce-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2012) is 4210 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 1702, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-16) exists of draft-ietf-pce-gmpls-pcep-extensions-06 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: April 18, 2013 Cisco Systems, Inc. 6 I. Minei 7 Juniper Networks, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 October 15, 2012 12 PCEP Extensions for Stateful PCE 13 draft-ietf-pce-stateful-pce-02 15 Abstract 17 The Path Computation Element Communication Protocol (PCEP) provides 18 mechanisms for Path Computation Elements (PCEs) to perform path 19 computations in response to Path Computation Clients (PCCs) requests. 21 Although PCEP explicitly makes no assumptions regarding the 22 information available to the PCE, it also makes no provisions for 23 synchronization or PCE control of timing and sequence of path 24 computations within and across PCEP sessions. This document 25 describes a set of extensions to PCEP to enable stateful control of 26 MPLS-TE and GMPLS tunnels via PCEP. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 18, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Motivation and Objectives for Stateful PCE in an MPLS TE 70 deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7 74 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . 17 79 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 17 80 5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 18 81 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 19 82 5.4.1. State Synchronization Avoidance . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . 33 98 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 33 99 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 34 100 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 34 101 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 34 102 7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 35 103 7.1.3. Node Identifier TLV . . . . . . . . . . . . . . . . . 35 104 7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 36 105 7.2.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 38 106 7.2.2. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 38 107 7.2.3. LSP State Database Version TLV . . . . . . . . . . . . 39 108 7.2.4. Delegation Parameters TLVs . . . . . . . . . . . . . . 40 109 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 110 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 40 111 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 40 112 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 41 113 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 41 114 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 42 115 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 42 116 9. Manageability Considerations . . . . . . . . . . . . . . . . . 42 117 9.1. Control Function and Policy . . . . . . . . . . . . . . . 42 118 9.2. Information and Data Models . . . . . . . . . . . . . . . 43 119 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 44 120 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 44 121 9.5. Requirements on Other Protocols and Functional 122 Components . . . . . . . . . . . . . . . . . . . . . . . . 44 123 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 44 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 125 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 45 126 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 45 127 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 46 128 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 46 129 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 131 12.1. Normative References . . . . . . . . . . . . . . . . . . . 47 132 12.2. Informative References . . . . . . . . . . . . . . . . . . 47 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 135 1. Introduction 137 [RFC5440] describes the Path Computation Element Protocol (PCEP. 138 PCEP defines the communication between a Path Computation Client 139 (PCC) and a Path Control Element (PCE), or between PCE and PCE, 140 enabling computation of Multiprotocol Label Switching (MPLS) for 141 Traffic Engineering Label Switched Path (TE LSP) characteristics. 142 Extensions for support of GMPLS in PCEP are defined in 143 [I-D.ietf-pce-gmpls-pcep-extensions] 145 This document specifies a set of extensions to PCEP to enable 146 stateful control of tunnels between and across PCEP sessions in 147 compliance with [RFC4657]. It includes mechanisms to effect tunnel 148 state synchronization between PCCs and PCEs, delegation of control 149 over tunnels to PCEs, and PCE control of timing and sequence of path 150 computations within and across PCEP sessions. 152 2. Terminology 154 This document uses the following terms defined in [RFC5440]: PCC, 155 PCE, PCEP Peer. 157 This document uses the following terms defined in [RFC4090]: MPLS TE 158 Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup. 160 The following terms are defined in this document: 162 Passive Stateful PCE: uses LSP state information learned from PCCs 163 to optimize path computations. It does not actively update tunnel 164 state. A PCC maintains synchronization with the PCE. 166 Active Stateful PCE: uses tunnel state information learned from PCCs 167 to optimize path computations. Additionally, it actively updates 168 tunnel parameters in those PCCs that delegated control over their 169 tunnels to the PCE. 171 Delegation: An operation to grant a PCE temporary rights to modify a 172 subset of tunnel parameters on one or more PCC's tunnels. Tunnels 173 are delegated from a PCC to a PCE. 175 Delegation Timeout Interval: when a PCEP session is terminated, a 176 PCC waits for this time period before revoking tunnel delegation 177 to a PCE. 179 LSP State Report: an operation to send LSP state (Operational / 180 Admin Status, LSP attributes configured and set by a PCE, etc.) 181 from a PCC to a PCE. 183 LSP Update Request: an operation where a PCE requests a PCC to 184 update one or more attributes of an LSP and to re-signal the LSP 185 with updated attributes. 187 LSP Priority: a specific pair of MPLS setup and hold priority 188 values. 190 LSP State Database: information about and attributes of all LSPs 191 that are being reported to one or more PCEs via LSP State Reports. 193 Minimum Cut Set: the minimum set of links for a specific source 194 destination pair which, when removed from the network, result in a 195 specific source being completely isolated from specific 196 destination. The summed capacity of these links is equivalent to 197 the maximum capacity from the source to the destination by the 198 max-flow min-cut theorem. 200 MPLS TE Global Default Restoration: once an LSP failure is detected 201 by some downstream mode, the head-end LSP is notified by means of 202 RSVP. Upon receiving the notification, the headend Label 203 Switching Router (LSR) recomputes the path and signals the LSP 204 along an alternate path. [NET-REC] 206 MPLS TE Global Path Protection: once an LSP failure is detected by 207 some downstream mode, the head-end LSP is notified by means of 208 RSVP. Upon receiving the notification, the headend LSR reroutes 209 traffic using a pre-signaled backup (secondary) LSP. [NET-REC]. 211 Revocation: an operation performed by a PCC on a previously 212 delegated LSP. Revocation clears the LSP's PCE specific state on 213 the PCC and, if a PCEP session with the PCE the LSP was delegated 214 to exists in the UP state, also generates a revocation message to 215 the PCE. 217 Within this document, when describing PCE-PCE communications, the 218 requesting PCE fills the role of a PCC. This provides a saving in 219 documentation without loss of function. 221 The message formats in this document are specified using Routing 222 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 224 3. Motivation and Objectives for Stateful PCE in an MPLS TE deployment 226 3.1. Motivation 228 In the following sections, several use cases are described, 229 showcasing scenarios that benefit from the deployment of a stateful 230 PCE. The scenarios are specific to MPLS TE deployments, but the 231 extensions described in this document apply to GMPLS tunnels as well. 233 3.1.1. Background 235 Traffic engineering has been a goal of the MPLS architecture since 236 its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic 237 engineering system provided by [RFC3630], [RFC5305], and [RFC3209] 238 information about network resources utilization is only available as 239 total reserved capacity by traffic class on a per interface basis; 240 individual LSP state is available only locally on each LER for it's 241 own LSPs. In most cases, this makes good sense, as distribution and 242 retention of total LSP state for all LERs within in the network would 243 be prohibitively costly. 245 Unfortunately, this visibility in terms of global LSP state may 246 result in a number of issues for some demand patterns, particularly 247 within a common setup and hold priority. This issue affects online 248 traffic engineering systems, and in particular, the widely 249 implemented but seldom deployed auto-bandwidth system. 251 A sufficiently over-provisioned system will by definition have no 252 issues routing its demand on the shortest path. However, lowering 253 the degree to which network over-provisioning is required in order to 254 run a healthy, functioning network is a clear and explicit promise of 255 MPLS architecture. In particular, it has been a goal of MPLS to 256 provide mechanisms to alleviate congestion scenarios in which 257 "traffic streams are inefficiently mapped onto available resources; 258 causing subsets of network resources to become over-utilized while 259 others remain underutilized" ([RFC2702]). 261 3.1.2. Why a Stateful PCE? 263 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 264 "strict synchronization between the PCE and not only the network 265 states (in term of topology and resource information), but also the 266 set of computed paths and reserved resources in use in the network." 267 [RFC4655] also expressed a number of concerns with regard to a 268 stateful PCE, specifically: 270 o Any reliable synchronization mechanism would result in significant 271 control plane overhead 273 o Out-of-band ted synchronization would be complex and prone to race 274 conditions 276 o Path calculations incorporating total network state would be 277 highly complex 279 In general, stress on the MPLS TE control plane will be directly 280 proportional to the size of the system being controlled and the 281 tightness of the control loop, and indirectly proportional to the 282 amount of over-provisioning in terms of both network capacity and 283 reservation overhead. 285 Despite these concerns in terms of implementation complexity and 286 scalability, several TE algorithms exist today that have been 287 demonstrated to be extremely effective in large TE systems, providing 288 both rapid convergence and significant benefits in terms of 289 optimality of resource usage [MXMN-TE]. All of these systems share 290 at least two common characteristics: the requirement for both global 291 visibility of a flow (or in this case, a TE LSP) state and for 292 ordered control of path reservations across devices within the system 293 being controlled. While some approaches have been suggested in order 294 to remove the requirements for ordered control (See [MPLS-PC]), these 295 approaches are highly dependent on traffic distribution, and do not 296 allow for multiple simultaneous LSP priorities representing diffserv 297 classes. 299 The following use cases demonstrate a need for visibility into global 300 inter-PCC LSP state in PCE path computations, and for a PCE control 301 of sequence and timing in altering LSP path characteristics within 302 and across PCEP sessions. Reference topologies for the use cases 303 described later in this section are shown in Figures 1 and 2. 305 Unless otherwise cited, use cases assume that all LSPs listed exist 306 at the same LSP priority. 308 +-------+ 309 | A | 310 | | 311 +-------+ 312 \ 313 +-------+ +-------+ 314 | C |-------------------------| E | 315 | | | | 316 +-------+ +-------+ +-------+ 317 / \ | D | / 318 +-------+ ------| |------ 319 | B | +-------+ 320 | | 321 +-------+ 323 Figure 1: Reference topology 1 325 +-------+ +-------+ +-------+ 326 | A | | B | | C | 327 | | | | | | 328 +---+---+ +---+---+ +---+---+ 329 | | | 330 | | | 331 +---+---+ +---+---+ +---+---+ 332 | E | | F | | G | 333 | +--------+ +--------+ | 334 +-------+ +-------+ +-------+ 336 Figure 2: Reference topology 2 338 3.1.2.1. Throughput Maximization and Bin Packing 340 Because LSP attribute changes in [RFC5440] are driven by PCReq 341 messages under control of a PCC's local timers, the sequence of RSVP 342 reservation arrivals occurring in the network will be randomized. 343 This, coupled with a lack of global LSP state visibility on the part 344 of a stateless PCE may result in suboptimal throughput in a given 345 network topology. 347 Reference topology 2 in Figure 2 and Tables 1 and 2 show an example 348 in which throughput is at 50% of optimal as a result of lack of 349 visibility and synchronized control across PCC's. In this scenario, 350 the decision must be made as to whether to route any portion of the 351 E-G demand, as any demand routed for this source and destination will 352 decrease system throughput. 354 +------+--------+----------+ 355 | Link | Metric | Capacity | 356 +------+--------+----------+ 357 | A-E | 1 | 10 | 358 | B-F | 1 | 10 | 359 | C-G | 1 | 10 | 360 | E-F | 1 | 10 | 361 | F-G | 1 | 10 | 362 +------+--------+----------+ 364 Table 1: Link parameters for Throughput use case 366 +------+-----+-----+-----+--------+----------+-------+ 367 | Time | LSP | Src | Dst | Demand | Routable | Path | 368 +------+-----+-----+-----+--------+----------+-------+ 369 | 1 | 1 | E | G | 10 | Yes | E-F-G | 370 | 2 | 2 | A | B | 10 | No | --- | 371 | 3 | 1 | F | C | 10 | No | --- | 372 +------+-----+-----+-----+--------+----------+-------+ 374 Table 2: Throughput use case demand time series 376 In many cases throughput maximization becomes a bin packing problem. 377 While bin packing itself is an NP-hard problem, a number of common 378 heuristics which run in polynomial time can provide significant 379 improvements in throughput over random reservation event 380 distribution, especially when traversing links which are members of 381 the minimum cut set for a large subset of source destination pairs. 383 Tables 3 and 4 show a simple use case using Reference Topology 1 in 384 Figure 1, where LSP state visibility and control of reservation order 385 across PCCs would result in significant improvement in total 386 throughput. 388 +------+--------+----------+ 389 | Link | Metric | Capacity | 390 +------+--------+----------+ 391 | A-C | 1 | 10 | 392 | B-C | 1 | 10 | 393 | C-E | 10 | 5 | 394 | C-D | 1 | 10 | 395 | D-E | 1 | 10 | 396 +------+--------+----------+ 398 Table 3: Link parameters for Bin Packing use case 400 +------+-----+-----+-----+--------+----------+---------+ 401 | Time | LSP | Src | Dst | Demand | Routable | Path | 402 +------+-----+-----+-----+--------+----------+---------+ 403 | 1 | 1 | A | E | 5 | Yes | A-C-D-E | 404 | 2 | 2 | B | E | 10 | No | --- | 405 +------+-----+-----+-----+--------+----------+---------+ 407 Table 4: Bin Packing use case demand time series 409 3.1.2.2. Deadlock 411 Most existing RSVP-TE implementations will not tear down established 412 LSPs in the event of the failure of the bandwidth increase procedure 413 detailed in [RFC3209]. This behavior is directly implied to be 414 correct in [RFC3209] and is often desirable from an operator's 415 perspective, because either a) the destination prefixes are not 416 reachable via any means other than MPLS or b) this would result in 417 significant packet loss as demand is shifted to other LSPs in the 418 overlay mesh. 420 In addition, there are currently few implementations offering ingress 421 admission control at the LSP level. Again, having ingress admission 422 control on a per LSP basis is not necessarily desirable from an 423 operational perspective, as a) one must over-provision tunnels 424 significantly in order to avoid deleterious effects resulting from 425 stacked transport and flow control systems and b) there is currently 426 no efficient commonly available northbound interface for dynamic 427 configuration of per LSP ingress admission control (such an interface 428 could easily be defined using the extensions present in this spec, 429 but it beyond the scope of the current document). 431 Lack of ingress admission control coupled with the behavior in 432 [RFC3209] effectively results in mis-signaled LSPs during periods of 433 contention for network capacity between LSPs in a given LSP priority. 434 This in turn causes information loss in the TED with regard to actual 435 network state, resulting in LSPs sharing common network interfaces 436 with mis-signaled LSPs operating in a degraded state for significant 437 periods of time, even when unused network capacity may potentially be 438 available. 440 Reference Topology 1 in Figure 1 and Tables 5 and 6 show a use case 441 that demonstrates this behavior. Two LSPs, LSP 1 and LSP 2 are 442 signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E 443 respectively. At a later time, the demand of LSP 1 increases to 20. 444 Under such a demand, the LSP cannot be resignaled. However, the 445 existing LSP will not be torn down. In the absence of ingress 446 policing, traffic on LSP 1 will cause degradation for traffic of LSP 447 2 (due to oversubscription on the links C-D and D-E), as well as 448 information loss in the TED with regard to the actual network state. 450 The problem could be easily ameliorated by global visibility of LSP 451 state coupled with PCC- external demand measurements and placement of 452 two LSPs on disjoint links. Note that while the demand of 20 for LSP 453 1 could never be satisfied in the given topology, what could be 454 achieved would be isolation from the ill-effects of the 455 (unsatisfiable) increased demand. 457 +------+--------+----------+ 458 | Link | Metric | Capacity | 459 +------+--------+----------+ 460 | A-C | 1 | 10 | 461 | B-C | 1 | 10 | 462 | C-E | 10 | 5 | 463 | C-D | 1 | 10 | 464 | D-E | 1 | 10 | 465 +------+--------+----------+ 467 Table 5: Link parameters for the 'Deadlock' example 469 +------+-----+-----+-----+--------+----------+---------+ 470 | Time | LSP | Src | Dst | Demand | Routable | Path | 471 +------+-----+-----+-----+--------+----------+---------+ 472 | 1 | 1 | A | E | 2 | Yes | A-C-D-E | 473 | 2 | 2 | B | E | 2 | Yes | B-C-D-E | 474 | 3 | 1 | A | E | 20 | No | --- | 475 +------+-----+-----+-----+--------+----------+---------+ 477 Table 6: Deadlock LSP and demand time series 479 3.1.2.3. Minimum Perturbation 481 As a result of both the lack of visibility into global LSP state and 482 the lack of control over event ordering across PCE sessions, 483 unnecessary perturbations may be introduced into the network by a 484 stateless PCE. Tables 7 and 8 show an example of an unnecessary 485 network perturbation using Reference Topology 1 in Figure 1. In this 486 case an unimportant (high LSP priority value) LSP (LSP1) is first set 487 up along the shortest path. At time 2, which is assumed to be 488 relatively close to time 1, a second more important (lower LSP- 489 priority value) LSP is established, preempting LSP 1 and shifting it 490 to the longer A-C-E path. 492 +------+--------+----------+ 493 | Link | Metric | Capacity | 494 +------+--------+----------+ 495 | A-C | 1 | 10 | 496 | B-C | 1 | 10 | 497 | C-E | 10 | 10 | 498 | C-D | 1 | 10 | 499 | D-E | 1 | 10 | 500 +------+--------+----------+ 502 Table 7: Link parameters for the 'Minimum-Perturbation' example 504 +------+-----+-----+-----+--------+----------+----------+---------+ 505 | Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path | 506 +------+-----+-----+-----+--------+----------+----------+---------+ 507 | 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E | 508 | 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E | 509 | 3 | 1 | A | E | 7 | 7 | Yes | A-C-E | 510 +------+-----+-----+-----+--------+----------+----------+---------+ 512 Table 8: Minimum-Perturbation LSP and demand time series 514 3.1.2.4. Predictability 516 Randomization of reservation events caused by lack of control over 517 event ordering across PCE sessions results in poor predictability in 518 LSP routing. An offline system applying a consistent optimization 519 method will produce predictable results to within either the boundary 520 of forecast error when reservations are over-provisioned by 521 reasonable margins or to the variability of the signal and the 522 forecast error when applying some hysteresis in order to minimize 523 churn. 525 Reference Topology 1 and Tables 9, 10 and 11 show the impact of event 526 ordering and predictability of LSP routing. 528 +------+--------+----------+ 529 | Link | Metric | Capacity | 530 +------+--------+----------+ 531 | A-C | 1 | 10 | 532 | B-C | 1 | 10 | 533 | C-E | 1 | 10 | 534 | C-D | 1 | 10 | 535 | D-E | 1 | 10 | 536 +------+--------+----------+ 538 Table 9: Link parameters for the 'Predictability' example 539 +------+-----+-----+-----+--------+----------+---------+ 540 | Time | LSP | Src | Dst | Demand | Routable | Path | 541 +------+-----+-----+-----+--------+----------+---------+ 542 | 1 | 1 | A | E | 7 | Yes | A-C-E | 543 | 2 | 2 | B | E | 7 | Yes | B-C-D-E | 544 +------+-----+-----+-----+--------+----------+---------+ 546 Table 10: Predictability LSP and demand time series 1 548 +------+-----+-----+-----+--------+----------+---------+ 549 | Time | LSP | Src | Dst | Demand | Routable | Path | 550 +------+-----+-----+-----+--------+----------+---------+ 551 | 1 | 2 | B | E | 7 | Yes | B-C-E | 552 | 2 | 1 | A | E | 7 | Yes | A-C-D-E | 553 +------+-----+-----+-----+--------+----------+---------+ 555 Table 11: Predictability LSP and demand time series 2 557 3.1.2.5. Global Concurrent Optimization 559 Global Concurrent Optimization (GCO) defined in [RFC5557] is a 560 network optimization mechanism that is able to simultaneously 561 consider the entire topology of the network and the complete set of 562 existing TE LSPs and their existing constraints, and look to optimize 563 or reoptimize the entire network to satisfy all constraints for all 564 TE LSPs. It allows for bulk path computations in order to avoid 565 blocking problems and to achieve more optimal network-wide solutions. 567 Global control of LSP operation sequence in [RFC5557] is predicated 568 on the use of what is effectively a stateful (or semi-stateful) NMS. 569 The NMS can be either not local to the switch, in which case another 570 northbound interface is required for LSP attribute changes, or local/ 571 collocated, in which case there are significant issues with 572 efficiency in resource usage. Stateful PCE adds a few features that: 574 o Roll the NMS visibility into the PCE and remove the requirement 575 for an additional northbound interface 577 o Allow the PCE to determine when re-optimization is needed 579 o Allow the PCE to determine which LSPs should be re-optimized 581 o Allow a PCE to control the sequence of events across multiple 582 PCCs, allowing for bulk (and truly global) optimization, LSP 583 shuffling etc. 585 3.1.3. Protocol vs. Configuration 587 Note that existing configuration tools and protocols can be used to 588 set LSP state. However, this solution has several shortcomings: 590 o Scale & Performance: configuration operations often require 591 processing of additional configuration portions beyond the state 592 being directly acted upon, with corresponding cost in CPU cycles, 593 negatively impacting both PCC stability LSP update rate capacity. 595 o Scale & Performance: configuration operations often have 596 transactional semantics which are typically heavyweight and 597 require additional CPU cycles, negatively impacting PCC update 598 rate capacity. 600 o Security: opening up a configuration channel to a PCE would allow 601 a malicious PCE to take over a PCC. The PCEP extensions described 602 in this document only allow a PCE control over a very limited set 603 of LSP attributes. 605 o Interoperability: each vendor has a proprietary information model 606 for configuring LSP state, which prevents interoperability of a 607 PCE with PCCs from different vendors. The PCEP extensions 608 described in this document allow for a common information model 609 for LSP state for all vendors. 611 o Efficient State Synchronization: configuration channels may be 612 heavyweight and unidirectional, therefore efficient state 613 synchronization between a PCE and a PCE may be a problem. 615 3.2. Objectives 617 The objectives for the protocol extensions to support stateful PCE 618 described in this document are as follows: 620 o Allow a single PCC to interact with a mix of stateless and 621 stateful PCEs simultaneously using the same PCEP. 623 o Support efficient LSP state synchronization between the PCC and 624 one or more active or passive stateful PCEs. 626 o Allow a PCC to delegate control of its LSPs to an active stateful 627 PCE such that a single LSP is under the control a single PCE at 628 any given time. A PCC may revoke this delegation at any time 629 during the lifetime of the LSP. If LSP delegation is revoked 630 while the PCEP session is up, the PCC MUST notify the PCE about 631 the revocation. A PCE may return an LSP delegation at any point 632 during the lifetime of the PCEP session. 634 o Allow a PCE to control computation timing and update timing across 635 all LSPs that have been delegated to it. 637 o Allow a PCE to specify protection / restoration settings for all 638 LSPs that have been delegated to it. 640 o Enable uninterrupted operation of PCC's LSPs in the event PCE 641 failure or while control of LSPs is being transferred between 642 PCEs. 644 4. New Functions to Support Stateful PCEs 646 Several new functions will be required in PCEP to support stateful 647 PCEs. A function can be initiated either from a PCC towards a PCE 648 (C-E) or from a PCE towards a PCC (E-C). The new functions are: 650 Capability negotiation (E-C,C-E): both the PCC and the PCE must 651 announce during PCEP session establishment that they support PCEP 652 Stateful PCE extensions defined in this document. 654 LSP state synchronization (C-E): after the session between the PCC 655 and a stateful PCE is initialized, the PCE must learn the state of 656 a PCC's LSPs before it can perform path computations or update LSP 657 attributes in a PCC. 659 LSP Update Request (E-C): A PCE requests modification of attributes 660 on a PCC's LSP. 662 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 663 whenever the state of an LSP changes. 665 LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 666 update LSP attributes on one or more LSPs; the PCE becomes the 667 authoritative source of the LSP's attributes as long as the 668 delegation is in effect (See Section 5.5); the PCC may withdraw 669 the delegation or the PCE may give up the delegation 671 In addition to new PCEP functions, stateful capabilities discovery 672 will be required in OSPF ([RFC5088]) and IS-IS ([RFC5089]). Stateful 673 capabilities discovery is not in scope of this document. 675 5. Architectural Overview of Protocol Extensions 676 5.1. LSP State Ownership 678 In the PCEP protocol (defined in [RFC5440]), LSP state and operation 679 are under the control of a PCC (a PCC may be an LSR or a management 680 station). Attributes received from a PCE are subject to PCC's local 681 policy. The PCEP protocol extensions described in this document do 682 not change this behavior. 684 An active stateful PCE may have control of a PCC's LSPs be delegated 685 to it, but the LSP state ownership is retained by the PCC. In 686 particular, in addition to specifying values for LSP's attributes, an 687 active stateful PCE also decides when to make LSP modifications. 689 Retaining LSP state ownership on the PCC allows for: 691 o a PCC to interact with both stateless and stateful PCEs at the 692 same time 694 o a stateful PCE to only modify a small subset of LSP parameters, 695 i.e. to set only a small subset of the overall LSP state; other 696 parameters may be set by the operator through CLI commands 698 o a PCC to revert delegated LSP to an operator-defined default or to 699 delegate the LSPs to a different PCE, if the PCC get disconnected 700 from a PCE with currently delegated LSPs 702 5.2. New Messages 704 In this document, we define the following new PCEP messages: 706 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 707 to a PCE to report the status of one or more LSPs. Each LSP 708 Status Report in a PCRpt message can contain the actual LSP's 709 path,bandwidth, operational and administrative status, etc. An 710 LSP Status Report carried on a PCRpt message is also used in 711 delegation or revocation of control of an LSP to/from a PCE. The 712 PCRpt message is described in Section 6.1. 714 Path Computation Update Request (PCUpd): a PCEP message sent by a 715 PCE to a PCC to update LSP parameters, on one or more LSPs. Each 716 LSP Update Request on a PCUpd message MUST contain all LSP 717 parameters that a PCE wishes to set for a given LSP. An LSP 718 Update Request carried on a PCUpd message is also used to return 719 LSP delegations if at any point PCE no longer desires control of 720 an LSP. The PCUpd message is described in Section 6.2. 722 The new functions defined in Section 4 are mapped onto the new 723 messages as shown in the following table. 725 +----------------------------------------+--------------------------+ 726 | Function | Message | 727 +----------------------------------------+--------------------------+ 728 | Capability Negotiation (E-C,C-E) | Open | 729 | State Synchronization (C-E) | PCRpt | 730 | LSP State Report (C-E) | PCRpt | 731 | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | 732 | LSP Update Request (E-C) | PCUpd | 733 | ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS | 734 | | sub-TLV | 735 | OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, | 736 | | PCE-CAP-FLAGS sub-TLV | 737 +----------------------------------------+--------------------------+ 739 Table 12: New Function to Message Mapping 741 5.3. Capability Negotiation 743 During PCEP Initialization Phase, PCEP Speakers (PCE pr PCC) 744 negotiate the use of stateful PCEP extensions. A PCEP Speaker 745 includes the "Stateful PCE Capability" TLV, described in 746 Section 7.1.1, in the OPEN Object to advertise its support for PCEP 747 stateful extensions. The Stateful Capability TLV includes the 'LSP 748 Update' Flag that indicates whether the PCEP Speaker supports LSP 749 parameter updates. 751 The presence of the Stateful PCE Capability TLV in PCC's OPEN Object 752 indicates that the PCC is willing to send LSP State Reports whenever 753 LSP parameters or operational status changes. 755 The presence of the Stateful PCE Capability TLV in PCE's OPEN message 756 indicates that the PCE is interested in receiving LSP State Reports 757 whenever LSP parameters or operational status changes. 759 The PCEP protocol extensions for stateful PCEs MUST NOT be used if 760 one or both PCEP Speakers have not included the Stateful PCE 761 Capability TLV in their respective OPEN message, otherwise a PCErr 762 with code "Stateful PCE capability not negotiated" (see Section 8.4) 763 will be generated and the PCEP session will be terminated. 765 LSP delegation and LSP update operations defined in this document MAY 766 only be used if both PCEP Speakers set the LSP-UPDATE Flag in the 767 "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)', 768 otherwise a PCErr with code "Delegation not negotiated" (see 769 Section 8.4) will be generated. Note that even if the update 770 capability has not been negotiated, a PCE can still receive LSP 771 Status Reports from a PCC and build and maintain an up to date view 772 of the state of the PCC's LSPs. 774 5.4. State Synchronization 776 The purpose of State Synchronization is to provide a checkpoint-in- 777 time state replica of a PCC's LSP state in a PCE. State 778 Synchronization is performed immediately after the Initialization 779 phase ([RFC5440]). 781 During State Synchronization, a PCC first takes a snapshot of the 782 state of its LSPs state, then sends the snapshot to a PCE in a 783 sequence of LSP State Reports. Each LSP State Report sent during 784 State Synchronization has the SYNC Flag in the LSP Object set to 1. 785 The set of LSPs for which state is synchronized with a PCE is 786 determined by negotiated stateful PCEP capabilities and PCC's local 787 configuration (see more details in Section 9.1). 789 A PCE SHOULD NOT send PCUpd messages to a PCC before State 790 Synchronization is complete. A PCC SHOULD NOT send PCReq messages to 791 a PCE before State Synchronization is complete. This is to allow the 792 PCE to get the best possible view of the network before it starts 793 computing new paths. 795 If the PCC encounters a problem which prevents it from completing the 796 state transfer, it MUST send a PCErr message to the PCE and terminate 797 the session using the PCEP session termination procedure. 799 The PCE does not send positive acknowledgements for properly received 800 synchronization messages. It MUST respond with a PCErr message 801 indicating "PCRpt error" (see Section 8.4) if it encounters a problem 802 with the LSP State Report it received from the PCC. Either the PCE 803 or the PCC MAY terminate the session if the PCE encounters a problem 804 during the synchronization. 806 The successful State Synchronization sequence is shown in Figure 3. 808 +-+-+ +-+-+ 809 |PCC| |PCE| 810 +-+-+ +-+-+ 811 | | 812 |-----PCRpt, SYNC=1----->| (Sync start) 813 | | 814 |-----PCRpt, SYNC=1----->| 815 | . | 816 | . | 817 | . | 818 |-----PCRpt, SYNC=1----->| (Sync done) 819 | . | 820 | . | 821 | . | 822 | | 823 |-----PCRpt, SYNC=0----->| (Regular 824 | | LSP State Report) 826 Figure 3: Successful state synchronization 828 The sequence where the PCE fails during the State Synchronization 829 phase is shown in Figure 4. 831 +-+-+ +-+-+ 832 |PCC| |PCE| 833 +-+-+ +-+-+ 834 | | 835 |-----PCRpt, SYNC=1----->| 836 | | 837 |-----PCRpt, SYNC=1----->| 838 | . | 839 | . | 840 | . | 841 |-----PCRpt, SYNC=1----->| 842 | | 843 |-PCRpt, SYNC=1 | 844 | \ ,-PCErr=?-| 845 | \ / | 846 | \/ | 847 | /\ | 848 | / `-------->| (Ignored) 849 |<--------` | 851 Figure 4: Failed state synchronization (PCE failure) 853 The sequence where the PCC fails during the State Synchronization 854 phase is shown in Figure 5. 856 +-+-+ +-+-+ 857 |PCC| |PCE| 858 +-+-+ +-+-+ 859 | | 860 |-----PCRpt, SYNC=1----->| 861 | | 862 |-----PCRpt, SYNC=1----->| 863 | . | 864 | . | 865 | . | 866 |-------- PCErr=? ------>| 867 | | 869 Figure 5: Failed state synchronization (PCC failure) 871 5.4.1. State Synchronization Avoidance 873 State Synchronization MAY be skipped following a PCEP session restart 874 if the state of both PCEP peers did not change during the period 875 prior to session re-initialization. To be able to make this 876 determination, state must be exchanged and maintained by both PCE and 877 PCC during normal operation. This is accomplished by keeping track 878 of the changes to the LSP State Database. When State Synchronization 879 avoidance is enabled on a PCEP session, a PCC includes the LSP-DB- 880 VERSION TLV as an optional TLV in the LSP Object on each LSP State 881 Report. The LSP-DB-VERSION TLV contains a PCC's LSP State Database 882 version, which is incremented each time a change is made to the PCC's 883 local LSP State Database. The LSP State Database version is an 884 unsigned 64-bit value that MUST be incremented by 1 for each 885 successive change in the LSP state database. The LSP State Database 886 version MUST start at 1 and may wrap around. Values 0 and 887 0xFFFFFFFFFFFFFFFF are reserved. 889 State Synchronization Avoidance is negotiated on a PCEP session 890 during session startup. To make sure that a PCEP peer can recognize 891 a previously connected peer even if its IP address changed, each PCEP 892 peer includes the NODE_IDENTIFIER TLV in the OPEN message. 894 If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN 895 object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the 896 LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the 897 PCC's latest LSP State Database version. 899 If a PCE's LSP State Database survived the restart of a PCEP session, 900 the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and 901 the TLV will contain the last LSP State Database version received on 902 an LSP State Report from the PCC in a previous PCEP session. If a 903 PCC's LSP State Database survived the restart, the PCC will include 904 the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain 905 the last LSP State Database version sent on an LSP State Update from 906 the PCC in the previous PCEP session. If a PCEP Speaker's LSP State 907 Database did not survive the restart of a PCEP session, the PCEP 908 Speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN Object. 910 If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN 911 Object and the TLV values match, the PCC MAY skip State 912 Synchronization. Otherwise, the PCE MUST purge any remaining LSP 913 state and expect the PCC to perform State Synchronization; if the PCC 914 attempts to skip State Synchronization (i.e. the SYNC Flag = 0 on the 915 first LSP State Report from the PCC), the PCE MUST send back a 916 PCError with Error-type 20 Error-value 2 'LSP Database version 917 mismatch', and close the PCEP session. 919 Note that a PCE MAY force State Synchronization by not including the 920 LSP-DB-VERSION TLV in its OPEN object. 922 Figure 6 shows an example sequence where State Synchronization is 923 skipped. 925 +-+-+ +-+-+ 926 |PCC| |PCE| 927 +-+-+ +-+-+ 928 | | 929 |--Open--, | 930 | DBv=42 \ ,---Open--| 931 | IDB=1 \ / DBv=42 | 932 | \/ IDB=1 | 933 | /\ | 934 | / `-------->| (OK to skip sync) 935 (Skip sync) |<--------` | 936 | . | 937 | . | 938 | . | 939 | | 940 |--PCRpt,DBv=43,SYNC=0-->| (Regular 941 | | LSP State Report) 942 |--PCRpt,DBv=44,SYNC=0-->| (Regular 943 | | LSP State Report) 944 |--PCRpt,DBv=45,SYNC=0-->| 945 | | 947 Figure 6: State Synchronization skipped 949 Figure 7 shows an example sequence where State Synchronization is 950 performed due to LSP State Database version mismatch during the PCEP 951 session setup. Note that the same State Synchronization sequence 952 would happen if either the PCE or the PCE would not include the LSP- 953 DB-VERSION TLV in their respective Open messages. 955 +-+-+ +-+-+ 956 |PCC| |PCE| 957 +-+-+ +-+-+ 958 | | 959 |--Open--, | 960 | DBv=46 \ ,---Open--| 961 | IDB=1 \ / DBv=42 | 962 | \/ IDB=1 | 963 | /\ | 964 | / `-------->| (Expect sync) 965 (Do sync) |<--------` | (Purge LSP State) 966 | | 967 |--PCRpt,DBv=46,SYNC=1-->| (Sync start) 968 | . | 969 | . | 970 | . | 971 |--PCRpt,DBv=46,SYNC=1-->| (Sync done) 972 | . | 973 | . | 974 | . | 975 |--PCRpt,DBv=47,SYNC=0-->| (Regular 976 | | LSP State Report) 977 |--PCRpt,DBv=48,SYNC=0-->| (Regular 978 | | LSP State Report) 979 |--PCRpt,DBv=49,SYNC=0-->| 980 | | 982 Figure 7: State Synchronization performed 984 Figure 8 shows an example sequence where State Synchronization is 985 skipped, but because one or both PCEP Speakers set the INCLUDE-DB- 986 VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the 987 PCE. If the current PCEP session restarts, the PCEP Speakers will 988 have to perform State Synchronization, since the PCE will not know 989 the PCC's latest LSP State Database version. 991 +-+-+ +-+-+ 992 |PCC| |PCE| 993 +-+-+ +-+-+ 994 | | 995 |--Open--, | 996 | DBv=42 \ ,---Open--| 997 | IDB=0 \ / DBv=42 | 998 | \/ IDB=0 | 999 | /\ | 1000 | / `-------->| (OK to skip sync) 1001 (Skip sync) |<--------` | 1002 | . | 1003 | . | 1004 | . | 1005 |------PCRpt,SYNC=0----->| (Regular 1006 | | LSP State Report) 1007 |------PCRpt,SYNC=0----->| (Regular 1008 | | LSP State Update) 1009 |------PCRpt,SYNC=0----->| 1010 | | 1012 Figure 8: State Synchronization skipped, no LSP-DB-VERSION TLVs sent 1013 from PCC 1015 5.5. LSP Delegation 1017 If during Capability negotiation both the PCE and the PCC have 1018 indicated that they support LSP Update, then the PCC may choose to 1019 grant the PCE a temporary right to update (a subset of) LSP 1020 attributes on one or more LSPs. This is called "LSP Delegation", and 1021 it MAY be performed at any time after the Initialization phase. 1023 LSP Delegation is controlled by operator-defined policies on a PCC. 1024 LSPs are delegated individually - different LSPs may be delegated to 1025 different PCEs, and an LSP may be delegated to one or more PCEs. The 1026 delegation policy, when all PCC's LSPs are delegated to a single PCE 1027 at any given time, SHOULD be supported by all delegation-capable 1028 PCCs. Conversely, the policy revoking the delegation for all PCC's 1029 LSPs SHOULD also be supported 1031 A PCE may return LSP delegation at any time if it no longer wishes to 1032 update the LSP's state. A PCC may revoke LSP delegation at any time. 1033 Delegation, Revocation, and Return are done individually for each 1034 LSP. 1036 5.5.1. Delegating an LSP 1038 A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP 1039 State Report to 1. A PCE confirms the delegation when it sends the 1040 first LSP Update Request for the delegated LSP to the PCC by setting 1041 the Delegate flag to 1. Note that a PCE does not immediately confirm 1042 to the PCC the acceptance of LSP Delegation; Delegation acceptance is 1043 confirmed when the PCC wishes to update the LSP via the LSP Update 1044 Request. If a PCE does not accept the LSP Delegation, it MUST 1045 immediately respond with an empty LSP Update Request which has the 1046 Delegate flag set to 0. 1048 The delegation sequence is shown in Figure 9. 1050 +-+-+ +-+-+ 1051 |PCC| |PCE| 1052 +-+-+ +-+-+ 1053 | | 1054 |---PCRpt, Delegate=1--->| LSP Delegated 1055 | | 1056 |---PCRpt, Delegate=1--->| 1057 | . | 1058 | . | 1059 | . | 1060 |<--(PCUpd,Delegate=1)---| Delegation confirmed 1061 | | 1062 |---PCRpt, Delegate=1--->| 1063 | | 1065 Figure 9: Delegating an LSP 1067 Note that for an LSP to remain delegated to a PCE, the PCC MUST set 1068 the Delegate flag to 1 on each LSP Status Report sent to the PCE. 1070 5.5.2. Revoking a Delegation 1072 When a PCC decides that a PCE is no longer permitted to modify an 1073 LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke 1074 an LSP delegation at any time during the LSP's life time. A PCC 1075 revoking a LSP MAY immediately clear the LSP state provided by the 1076 PCE, and MUST ignore any further PCUpd messages received regarding 1077 the revoked LSP from the previous PCE delegate. 1079 If a PCEP session with the PCE to which the LSP is delegated exists 1080 in the UP state during the revocation, the PCC MUST notify that PCE 1081 by sending an LSP State Report with the Delegate flag set to 0, as 1082 shown in Figure 10. 1084 +-+-+ +-+-+ 1085 |PCC| |PCE| 1086 +-+-+ +-+-+ 1087 | | 1088 |---PCRpt, Delegate=1--->| 1089 | | 1090 |<--(PCUpd,Delegate=1)---| Delegation confirmed 1091 | . | 1092 | . | 1093 | . | 1094 |---PCRpt, Delegate=0--->| PCC revokes delegation 1095 | | 1097 Figure 10: Revoking a Delegation 1099 After an LSP delegation has been revoked, a PCE can no longer update 1100 LSP's parameters; an attempt to update parameters of a non-delegated 1101 LSP will result in the PCC sending a PCErr message indicating "LSP is 1102 not delegated" (see Section 8.4). 1104 When a PCC's PCEP session with a PCE terminates, the PCC SHALL wait a 1105 time interval specified in 'Delegation Timeout Interval' before 1106 revoking LSP delegations to the PCE. If a new PCEP session with the 1107 PCE can be established before the 'Delegation Timeout' timer expires, 1108 LSP delegations to the PCE remain intact. If, after expiry of the 1109 'Delegation Timeout' timer, a PCC can not delegate an LSP to another 1110 PCE (for example, if a PCC is not connected to any active stateful 1111 PCE or if no connected active stateful PCE accepts the delegation), 1112 the PCC SHALL flush any LSP state set by the PCE. 1114 If State Synchronization Avoidance is enabled, a PCC MUST increment 1115 its LSP State Database version when the 'Delegation Timeout' timer 1116 expires. 1118 5.5.3. Returning a Delegation 1120 A PCE that no longer wishes to update an LSP's parameters SHOULD 1121 return the LSP delegation back to the PCC by sending an empty LSP 1122 Update Request which has the Delegate flag set to 0. Note that in 1123 order to keep a delegation, the PCE MUST set the Delegate flag to 1 1124 on each LSP Update Request sent to the PCC. 1126 +-+-+ +-+-+ 1127 |PCC| |PCE| 1128 +-+-+ +-+-+ 1129 | | 1130 |---PCRpt, Delegate=1--->| LSP delegated 1131 | . | 1132 | . | 1133 | . | 1134 |<--PCUpd, Delegate=0----| Delegation returned 1135 | | 1136 |---PCRpt, Delegate=0--->| No delegation for LSP 1137 | | 1139 Figure 11: Returning a Delegation 1141 If a PCC can not delegate an LSP to a PCE (for example, if a PCC is 1142 not connected to any active stateful PCE or if no connected active 1143 stateful PCE accepts the delegation), the LSP delegation on the PCC 1144 will time out within a configurable Delegation Timeout Interval and 1145 the PCC MUST flush any LSP state set by a PCE. 1147 5.5.4. Redundant Stateful PCEs 1149 Note that a PCE may not have any delegated LSPs: in a redundant 1150 configuration where one PCE is backing up another PCE, the backup PCE 1151 will not have any delegated LSPs. The backup PCE does not update any 1152 LSPs, but it receives all LSP State Reports from a PCC. When the 1153 primary PCE fails, a PCC will delegate to the secondary PCE all LSPs 1154 that had been previously delegated to the failed PCE. 1156 5.6. LSP Operations 1157 5.6.1. Passive Stateful PCE Path Computation Request/Response 1159 +-+-+ +-+-+ 1160 |PCC| |PCE| 1161 +-+-+ +-+-+ 1162 | | 1163 1) Path computation |----- PCReq message --->| 1164 request sent to | |2) Path computation 1165 PCE | | request received, 1166 | | path computed 1167 | | 1168 |<---- PCRep message ----|3) Computed paths 1169 | (Positive reply) | sent to the PCC 1170 | (Negative reply) | 1171 4) LSP Status change| | 1172 event | | 1173 | | 1174 5) LSP Status Report|----- PCRpt message --->| 1175 sent to all | . | 1176 stateful PCEs | . | 1177 | . | 1178 6) Repeat for each |----- PCRpt message --->| 1179 LSP status change| | 1180 | | 1182 Figure 12: Passive Stateful PCE Path Computation Request/Response 1184 Once a PCC has successfully established a PCEP session with a passive 1185 stateful PCE and the PCC's LSP state is synchronized with the PCE 1186 (i.e. the PCE knows about all PCC's existing LSPs), if an event is 1187 triggered that requires the computation of a set of paths, the PCC 1188 sends a path computation request to the PCE ([RFC5440], Section 1189 4.2.3). The PCReq message MAY contain the LSP Object to identify the 1190 LSP for which the path computation is requested. 1192 Upon receiving a path computation request from a PCC, the PCE 1193 triggers a path computation and returns either a positive or a 1194 negative reply to the PCC ([RFC5440], Section 4.2.4). 1196 Upon receiving a positive path computation reply, the PCC receives a 1197 set of computed paths and starts to setup the LSPs. For each LSP, it 1198 sends an LSP State Report carried on a PCRpt message to the PCE, 1199 indicating that the LSP's status is 'Pending'. 1201 Once an LSP is up, the PCC sends an LSP State Report carried on a 1202 PCRpt message to the PCE, indicating that the LSP's status is 'Up'. 1203 If the LSP could not be set up, the PCC sends an LSP State Report 1204 indicating that the LSP is "Down' and stating the cause of the 1205 failure. Note that due to timing constraints, the LSP status may 1206 change from 'Pending' to 'Up' (or 'Down') before the PCC has had a 1207 chance to send an LSP State Report indicating that the status is 1208 'Pending'. In such cases, the PCC may choose to only send the PCRpt 1209 indicating the latest status ('Up' or 'Down'). 1211 Upon receiving a negative reply from a PCE, a PCC may decide to 1212 resend a modified request or take any other appropriate action. For 1213 each requested LSP, it also sends an LSP State Report carried on a 1214 PCRpt message to the PCE, indicating that the LSP's status is 'Down'. 1216 There is no direct correlation between PCRep and PCRpt messages. For 1217 a given LSP, multiple LSP State Reports will follow a single PC 1218 Reply, as a PCC notifies a PCE of the LSP's state changes. 1220 A PCC sends each LSP State Report to each stateful PCE that is 1221 connected to the PCC. 1223 Note that a single PCRpt message MAY contain multiple LSP State 1224 Reports. 1226 The passive stateful PCE is the model for stateful PCEs is described 1227 in [RFC4655], Section 6.8. 1229 5.6.2. Active Stateful PCE LSP Update 1231 +-+-+ +-+-+ 1232 |PCC| |PCE| 1233 +-+-+ +-+-+ 1234 | | 1235 1) LSP State |-- PCRpt, Delegate=1 -->| 1236 Synchronization | . | 1237 or add new LSP | . |2) PCE decides to 1238 | . | update the LSP 1239 | | 1240 |<---- PCUpd message ----|3) PCUpd message sent 1241 | | to PCC 1242 | | 1243 | | 1244 4) LSP Status Report|---- PCRpt message ---->| 1245 sent(->Pending) | . | 1246 | . | 1247 | . | 1248 5) LSP Status Report|---- PCRpt message ---->| 1249 sent (->Up|Down) | | 1250 | | 1252 Figure 13: Active Stateful PCE 1254 Once a PCC has successfully established a PCEP session with an active 1255 stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. 1256 the PCE knows about all PCC's existing LSPs) and LSPs have been 1257 delegated to the PCE, the PCE can modify LSP parameters of delegated 1258 LSPs. 1260 A PCE sends an LSP Update Request carried on a PCUpd message to the 1261 PCC. The LSP Update Request contains a variety of objects that 1262 specify the set of constraints and attributes for the LSP's path. 1263 Additionally, the PCC may specify the urgency of such request by 1264 assigning a request priority. A single PCUpd message MAY contain 1265 multiple LSP Update Requests. 1267 Upon receiving a PCUpd message the PCC starts to setup LSPs specified 1268 in LSP Update Requests carried in the message. For each LSP, it 1269 sends an LSP State Report carried on a PCRpt message to the PCE, 1270 indicating that the LSP's status is 'Pending'. 1272 Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) 1273 to the PCE, indicating that the LSP's status is 'Up'. If the LSP 1274 could not be set up, the PCC sends an LSP State Report indicating 1275 that the LSP is 'Down' and stating the cause of the failure. A PCC 1276 may choose to compress LSP State Updates to only reflect the most up 1277 to date state, as discussed in the previous section. 1279 A PCC sends each LSP State Report to each stateful PCE that is 1280 connected to the PCC. 1282 A PCC MUST NOT send to any PCE a Path Computation Request for a 1283 delegated LSP. 1285 5.7. LSP Protection 1287 With a stateless PCE or a passive stateful PCE, LSP protection and 1288 restoration settings may be operator-configured locally at a PCC. A 1289 PCE may be merely asked to compute the protected (primary) and backup 1290 (secondary) paths for the LSP. 1292 An active stateful PCE controls the LSPs that are delegated to it, 1293 and must therefore be able to set via PCEP the desired protection / 1294 restoration mechanism for each delegated LSP. PCEP extensions for 1295 stateful PCEs SHOULD support, at a minimum, the following protection 1296 mechanisms for MPLS-TE LSPs: 1298 o MPLS TE Global Default Restoration 1300 o MPLS TE Global Path Protection 1301 o FRR One-to-One Backup 1303 o FRR Facility Backup - link protection, node protection, or both 1305 The necessary extensions for support of protection are described in 1306 technology-specific documents. 1308 5.8. Transport 1310 A Permanent PCEP session MUST be established between a stateful PCE 1311 and the PCC. 1313 State cleanup after session termination, as well as session setup 1314 failures will be described in a later version of this document. 1316 6. PCEP Messages 1318 As defined in [RFC5440], a PCEP message consists of a common header 1319 followed by a variable-length body made of a set of objects that can 1320 be either mandatory or optional. An object is said to be mandatory 1321 in a PCEP message when the object must be included for the message to 1322 be considered valid. For each PCEP message type, a set of rules is 1323 defined that specify the set of objects that the message can carry. 1324 An implementation MUST form the PCEP messages using the object 1325 ordering specified in this document. 1327 6.1. The PCRpt Message 1329 A Path Computation LSP State Report message (also referred to as 1330 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 1331 current state of an LSP. A PCRpt message can carry more than one LSP 1332 State Reports. A PCC can send an LSP State Report either in response 1333 to an LSP Update Request from a PCE, or asynchronously when the state 1334 of an LSP changes. The Message-Type field of the PCEP common header 1335 for the PCRpt message is set to [TBD]. 1337 The format of the PCRpt message is as follows: 1339 ::= 1340 1341 Where: 1343 ::= [] 1345 ::= 1346 [] 1348 Where: 1350 ::=[] 1352 Where: 1353 is defined in technology-specific documents per LSP type. 1355 The LSP object (see Section 7.2) is mandatory, and it MUST be 1356 included in each LSP State Report on the PCRpt message. If the LSP 1357 object is missing, the receiving PCE MUST send a PCErr message with 1358 Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP 1359 object missing). 1361 The path descriptor is described in separate technology-specific 1362 documents according to the LSP type. 1364 6.2. The PCUpd Message 1366 A Path Computation LSP Update Request message (also referred to as 1367 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 1368 attributes of an LSP. A PCUpd message can carry more than one LSP 1369 Update Request. The Message-Type field of the PCEP common header for 1370 the PCRpt message is set to [TBD]. 1372 The format of a PCUpd message is as follows: 1374 ::= 1375 1376 Where: 1378 ::= [] 1380 ::= 1381 [] 1383 Where: 1385 ::=[] 1386 Where: 1388 is defined in technology-specific documents per LSP type 1390 There is one mandatory object that MUST be included within each LSP 1391 Update Request in the PCUpd message: the LSP object (see 1392 Section 7.2). If the LSP object is missing, the receiving PCE MUST 1393 send a PCErr message with Error-type=6 (Mandatory Object missing) and 1394 Error-value=[TBD] (LSP object missing). 1396 Each LSP Update Request results in a separate LSP setup operation at 1397 a PCC. An LSP Update Request MUST contain all LSP parameters that a 1398 PCC wishes to set for the LSP. A PCC MAY set missing parameters from 1399 locally configured defaults. If the LSP specified the Update Request 1400 is already up, it will be re-signaled. The PCC will use make-before- 1401 break whenever possible in the re-signaling operation. 1403 A PCC MUST respond with an LSP State Report to each LSP Update 1404 Request to indicate the resulting state of the LSP in the network. A 1405 PCC MAY respond with multiple LSP State Reports to report LSP setup 1406 progress of a single LSP. 1408 If the rate of PCUpd messages sent to a PCC for the same target LSP 1409 exceeds the rate at which the PCC can signal LSPs into the network, 1410 the PCC MAY perform state compression and only re-signal the last 1411 modification in its queue. 1413 Note that a PCC MUST process all LSP Update Requests - for example, 1414 an LSP Update Request is sent when a PCE returns delegation or puts 1415 an LSP into non-operational state. The protocol relies on TCP for 1416 message-level flow control. 1418 Note also that it's up to the PCE to handle inter-LSP dependencies; 1419 for example, if ordering of LSP set-ups is required, the PCE has to 1420 wait for an LSP State Report for a previous LSP before triggering the 1421 LSP setup of a next LSP. 1423 6.3. The PCReq Message 1425 A PCC MAY include the LSP object in the PCReq message (see 1426 Section 7.2) if stateful PCE capability has been negotiated on a PCEP 1427 session between the PCC and a PCE. The extensions to the PCReq 1428 message are described in technology-specific documents for MPLS and 1429 GMPLS. 1431 6.4. The PCRep Message 1433 A PCE MAY include the LSP object in the PCRep message (see 1434 (Section 7.2) if stateful PCE capability has been negotiated on a 1435 PCEP session between the PCC and the PCE and the LSP object was 1436 included in the corresponding PCReq message from the PCC. The 1437 extensions to the PCRep message are described in technology-specific 1438 documents for MPLS and GMPLS. 1440 7. Object Formats 1442 The PCEP objects defined in this document are compliant with the PCEP 1443 object format defined in [RFC5440]. The P flag and the I flag of the 1444 PCEP objects defined in this document MUST always be set to 0 on 1445 transmission and MUST be ignored on receipt since these flags are 1446 exclusively related to path computation requests. 1448 7.1. OPEN Object 1450 This document defines a new optional TLV for the OPEN Object to 1451 support stateful PCE capability negotiation. 1453 7.1.1. Stateful PCE Capability TLV 1455 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 1456 following figure: 1458 0 1 2 3 1459 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 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Type=[TBD] | Length=4 | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Flags |S|U| 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 Figure 14: STATEFUL-PCE-CAPABILITY TLV format 1468 The type of the TLV is [TBD] and it has a fixed length of 4 octets. 1470 The value comprises a single field - Flags (32 bits): 1472 U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag 1473 indicates that the PCC allows modification of LSP parameters; if 1474 set to 1 by a PCE, the U Flag indicates that the PCE wishes to 1475 update LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be 1476 advertised by both a PCC and a PCE for PCUpd messages to be 1477 allowed on a PCEP session. 1479 S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers, 1480 the PCC will include the LSP-DB-VERSION TLV in each LSP Object. 1482 Unassigned bits are considered reserved. They MUST be set to 0 on 1483 transmission and MUST be ignored on receipt. 1485 7.1.2. LSP State Database Version TLV 1487 LSP-DB-VERSION is an optional TLV that MAY be included in the OPEN 1488 Object when a PCEP Speaker wishes to determine if State 1489 Synchronization can be skipped when a PCEP session is restarted. If 1490 sent from a PCE, the TLV contains the local LSP State Database 1491 version from the last valid LSP State Report received from a PCC. If 1492 sent from a PCC, the TLV contains the PCC's local LSP State Database 1493 version, which is incremented each time the LSP State Database is 1494 updated. 1496 The format of the LSP-DB-VERSION TLV is shown in the following 1497 figure: 1499 0 1 2 3 1500 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 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | Type=[TBD] | Length=8 | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | LSP State DB Version | 1505 | | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 Figure 15: LSP-DB-VERSION TLV format 1510 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 1511 The value contains a 64-bit unsigned integer. 1513 7.1.3. Node Identifier TLV 1515 NODE-IDENTIFIER is an optional TLV that MAY be included in the OPEN 1516 Object when a PCEP Speaker wishes to determine if State 1517 Synchronization can be skipped when a PCEP session is restarted. It 1518 contains a unique identifier for the node that does not change during 1519 the life time of the PCEP Speaker. It identifies the PCEP Speaker to 1520 its peers if the Speaker's IP address changed. 1522 The format of the NODE-IDENTIFIER TLV is shown in the following 1523 figure: 1525 0 1 2 3 1526 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 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Type=[TBD] | Length (variable) | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | | 1531 // PCEP Speaker Node Identifier // 1532 | | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 Figure 16: NODE-IDENTIFIER TLV format 1537 The type of the TLV is [TBD] and it has a a variable length, which 1538 MUST be greater than 0. The value contains a node identifier that 1539 MUST be unique in the network. The node identifier MAY be configured 1540 by an operator. If the node identifier is not configured by the 1541 operator, it can be derived from a PCC's MAC address or serial 1542 number. 1544 7.2. LSP Object 1546 The LSP object MUST be present within PCRpt and PCUpd messages. The 1547 LSP object MAY be carried within PCReq and PCRep messages if the 1548 stateful PCE capability has been negotiated on the session. The LSP 1549 object contains a set of fields used to specify the target LSP, the 1550 operation to be performed on the LSP, and LSP Delegation. It also 1551 contains a flag indicating to a PCE that the LSP state 1552 synchronization is in progress. 1554 LSP Object-Class is [TBD]. 1556 LSP Object-Type is 1. 1558 The format of the LSP object body is shown in Figure 17: 1560 0 1 2 3 1561 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 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | LSP-ID | Flags |R|O|S|D| 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | | 1566 // Optional TLVs // 1567 | | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 Figure 17: The LSP Object format 1572 The LSP object body has a variable length and may contain additional 1573 TLVs. 1575 LSP-ID (20 bits): An identifier for the LSP. A PCC creates a unique 1576 LSP-ID for each LSP that is constant for the life time of a PCEP 1577 session. The mapping of the Symbolic Path Name to LSP-ID is 1578 communicated to the PCE by sending a PCRpt message containing the 1579 'Symbolic Path Name' TLV. All subsequent PCEP messages then address 1580 the LSP by the LSP-ID. 1582 Flags (12 bits): 1584 D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1 1585 indicates that the PCC is delegating the LSP to the PCE. On a 1586 PCUpd message, the D flag set to 1 indicates that the PCE is 1587 confirming the LSP Delegation. To keep an LSP delegated to the 1588 PCE, the PCC must set the D flag to 1 on each PCRpt message for 1589 the duration of the delegation - the first PCRpt with the D flag 1590 set to 0 revokes the delegation. To keep the delegation, the PCE 1591 must set the D flag to 1 on each PCUpd message for the duration of 1592 the delegation - the first PCUpd with the D flag set to 0 returns 1593 the delegation. 1595 S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSP State 1596 Report sent from a PCC during State Synchronization. The S Flag 1597 MUST be set to 0 otherwise. 1599 O (Operational - 1 bit): On PCRpt messages the O Flag indicates the 1600 LSP status. Value of '1' means that the LSP is operational, i.e. 1601 it is either being signaled or it is active. Value of '0' means 1602 that the LSP is not operational, i.e it is de-routed and the PCC 1603 is not attempting to set it up. On PCUpd messages the flag 1604 indicates the desired status for the LSP. Value of '1' means that 1605 the desired LSP state is operational, value of '0' means that the 1606 target LSP should be non-operational. Setting the LSP status from 1607 the PCE SHALL NOT override the operator: if a pce-controlled LSP 1608 has been configured to be non-operational, setting the LSP's 1609 status to '1' from an PCE will not make it operational. 1611 R (Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1612 LSP has been removed from the PCC. Upon receiving an LSP State 1613 Report with the R Flag set to 1, the PCE SHOULD remove all state 1614 related to the LSP from its database. 1616 Unassigned bits are considered reserved. They MUST be set to 0 on 1617 transmission and MUST be ignored on receipt. 1619 TLVs that may be included in the LSP Object are described in the 1620 following sections and in separate technology-specific documents. 1622 7.2.1. Symbolic Path Name TLV 1624 Each LSP (path) MUST have a symbolic name that is unique in the PCC. 1625 This symbolic path name MUST remain constant throughout a path's 1626 lifetime, which may span across multiple consecutive PCEP sessions 1627 and/or PCC restarts. The symbolic path name MAY be specified by an 1628 operator in a PCC's CLI configuration. If the operator does not 1629 specify a symbolic name for a path, the PCC MUST auto-generate one. 1631 The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report 1632 when during a given PCEP session an LSP is first reported to a PCE. 1633 A PCC sends to a PCE the first LSP State Report either during State 1634 Synchronization, or when a new LSP is configured at the PCC. The 1635 symbolic path name MAY be included in subsequent LSP State Reports 1636 for the LSP. 1638 The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object 1639 and the LSPA Object. 1641 The format of the SYMBOLIC-PATH-NAME TLV is shown in the following 1642 figure: 1644 0 1 2 3 1645 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 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Type=[TBD] | Length (variable) | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | | 1650 // Symbolic Path Name // 1651 | | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 Figure 18: SYMBOLIC-PATH-NAME TLV format 1656 The type of the TLV is [TBD] and it has a variable length, which MUST 1657 be greater than 0. 1659 7.2.2. RSVP ERROR_SPEC TLVs 1661 If the set up of an LSP failed at a downstream node which returned an 1662 ERROR_SPEC to the PCC, the ERROR_SPEC MUST be included in the LSP 1663 State Report. Depending on whether RSVP signaling was performed over 1664 IPv4 or IPv6, the LSP Object will contain an IPV4-ERROR_SPEC TLV or 1665 an IPV6-ERROR_SPEC TLV. 1667 The format of the IPV4-RSVP-ERROR-SPEC TLV is shown in the following 1668 figure: 1670 0 1 2 3 1671 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 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | Type=[TBD] | Length=8 | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | | 1676 + IPv4 ERROR_SPEC object (rfc2205) + 1677 | | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 Figure 19: IPV4-RSVP-ERROR-SPEC TLV format 1682 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 1683 The value contains the RSVP IPv4 ERROR_SPEC object defined in 1684 [RFC2205]. Error codes allowed in the ERROR_SPEC object are defined 1685 in [RFC2205], [RFC3209] and [RFC3473].. 1687 The format of the IPV6-RSVP-ERROR-SPEC TLV is shown in the following 1688 figure: 1690 0 1 2 3 1691 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 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 | Type=[TBD] | Length=20 | 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 | | 1696 // IPv6 ERROR_SPEC object (rfc2205) // 1697 | | 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 Figure 20: IPV6-RSVP-ERROR-SPEC TLV format 1702 The type of the TLV is [TBD] and it has a fixed length of 20 octets. 1703 The value contains the RSVP IPv6 ERROR_SPEC object defined in 1704 [RFC2205]. Error codes allowed in the ERROR_SPEC object are defined 1705 in [RFC2205], [RFC3209] and [RFC3473]. 1707 7.2.3. LSP State Database Version TLV 1709 The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP 1710 object. The LSP-DB-VERSION TLV is discussed in Section 5.4.1 which 1711 covers state synchronization avoidance. The format of the TLV is 1712 described in Section 7.1.2, where the details of its use in the OPEN 1713 message are listed. 1715 If State Synchronization Avoidance has been enabled on a PCEP session 1716 (as described in Section 5.4.1) , a PCC MUST include the LSP-DB- 1717 VERSION TLV in each LSP Object sent out on the session. If the TLV 1718 is missing, the PCE will generate an error with error-type 6 1719 (mandatory object missing) and Error Value 12 (LSP-DB-VERSION TLV 1720 missing) and close the session. If State Synchronization Avoidance 1721 has not been enabled on a PCEP session, the PCC SHOULD NOT include 1722 the LSP-DB-VERSION TLV in the LSP Object and the PCE SHOULD ignore it 1723 were it to receive one. 1725 Since a PCE does not send LSP updates to a PCC, a PCC should never 1726 encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were 1727 it to receive one from a PCE. 1729 7.2.4. Delegation Parameters TLVs 1731 Multiple delegation parameters, such as sub-delegation permissions, 1732 authentication parameters, etc. need to be communicated from a PCC to 1733 a PCE during the delegation operation. Delegation parameters will be 1734 carried in multiple delegation parameter TLVs, which will be defined 1735 in future revisions of this document. 1737 8. IANA Considerations 1739 This document requests IANA actions to allocate code points for the 1740 protocol elements defined in this document. Values shown here are 1741 suggested for use by IANA. 1743 8.1. PCEP Messages 1745 This document defines the following new PCEP messages: 1747 Value Meaning Reference 1748 10 Report This document 1749 11 Update This document 1751 8.2. PCEP Objects 1753 This document defines the following new PCEP Object-classes and 1754 Object-values: 1756 Object-Class Value Name Reference 1758 32 LSP This document 1759 Object-Type 1760 1 1762 8.3. LSP Object 1764 This document requests that a registry is created to manage the Flags 1765 field of the LSP object. New values are to be assigned by Standards 1766 Action [RFC5226]. Each bit should be tracked with the following 1767 qualities: 1769 o Bit number (counting from bit 0 as the most significant bit) 1771 o Capability description 1773 o Defining RFC 1775 The following values are defined in this document: 1777 Bit Description Reference 1779 28 Remove This document 1780 29 Operational This document 1781 30 SYNC This document 1782 31 Delegate This document 1784 8.4. PCEP-Error Object 1786 This document defines new Error-Type and Error-Value for the 1787 following new error conditions: 1789 Error-Type Meaning 1790 6 Mandatory Object missing 1791 Error-value=8: LSP Object missing 1792 Error-value=12: LSP-DB-VERSION TLV missing 1793 19 Invalid Operation 1794 Error-value=1: Attempted LSP Update Request for a non- 1795 delegated LSP. The PCEP-ERROR Object 1796 is followed by the LSP Object that 1797 identifies the LSP. 1798 Error-value=2: Attempted LSP Update Request if active 1799 stateful PCE capability was not 1800 negotiated active PCE. 1801 20 LSP State synchronization error. 1802 Error-value=1: A PCE indicates to a PCC that it can 1803 not process (an otherwise valid) LSP 1804 State Report. The PCEP-ERROR Object is 1805 followed by the LSP Object that 1806 identifies the LSP. 1808 Error-value=2: LSP Database version mismatch. 1809 Error-value=3: The LSP-DB-VERSION TLV Missing when 1810 State Synchronization Avoidance 1811 enabled. 1813 8.5. PCEP TLV Type Indicators 1815 This document defines the following new PCEP TLVs: 1817 Value Meaning Reference 1818 16 STATEFUL-PCE-CAPABILITY This document 1819 17 SYMBOLIC-PATH-NAME This document 1820 21 IPV4-RSVP-ERROR-SPEC This document 1821 22 IPV6-RSVP-ERROR-SPEC This document 1822 23 LSP-DB-VERSION This document 1824 8.6. STATEFUL-PCE-CAPABILITY TLV 1826 This document requests that a registry is created to manage the Flags 1827 field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New 1828 values are to be assigned by Standards Action [RFC5226]. Each bit 1829 should be tracked with the following qualities: 1831 o Bit number (counting from bit 0 as the most significant bit) 1833 o Capability description 1835 o Defining RFC 1837 The following values are defined in this document: 1839 Bit Description Reference 1841 30 INCLUDE-DB-VERSION This document 1842 31 LSP-UPDATE-CAPABILITY This document 1844 9. Manageability Considerations 1846 All manageability requirements and considerations listed in [RFC5440] 1847 apply to PCEP protocol extensions defined in this document. In 1848 addition, requirements and considerations listed in this section 1849 apply. 1851 9.1. Control Function and Policy 1853 In addition to configuring specific PCEP session parameters, as 1854 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 1855 allow configuring the stateful PCEP capability and the LSP Update 1856 capability. A PCC implementation SHOULD allow the operator to 1857 specify multiple candidate PCEs for and a delegation preference for 1858 each candidate PCE. A PCC SHOULD allow the operator to specify an 1859 LSP delegation policy where LSPs are delegated to the most-preferred 1860 online PCE. A PCC MAY allow the operator to specify different LSP 1861 delegation policies. 1863 A PCE or PCC implementation SHOULD allow the operator to configure a 1864 Node Identifier (Section 7.1.3). 1866 A PCC implementation which allows concurrent connections to multiple 1867 PCEs SHOULD allow the operator to group the PCEs by administrative 1868 domains and it MUST NOT advertise LSP existence and state to a PCE if 1869 the LSP is delegated to a PCE in a different group. 1871 A PCC implementation SHOULD allow the operator to specify whether the 1872 PCC will advertise LSP existence and state for LSPs that are not 1873 controlled by any PCE (for example, LSPs that are statically 1874 configured at the PCC). 1876 A PCC implementation SHOULD allow the operator to specify the 1877 Delegation Timeout Interval. The default value of the Delegation 1878 Timeout Interval SHOULD be set to 30 seconds. 1880 When an LSP can no longer be delegated to a PCE, after the expiration 1881 of the Delegation Timeout Interval, the LSP MAY either: 1) retain its 1882 current parameters or 2) revert to operator-defined default LSP 1883 parameters. This behavior SHOULD be configurable and in the case 1884 when (2) is supported, a PCC implementation MUST allow the operator 1885 to specify the default LSP parameters. 1887 A PCC implementation SHOULD allow the operator to specify delegation 1888 priority for PCEs. This effectively defines the primary PCE and one 1889 or more backup PCEs to which primary PCE's LSPs can be delegated when 1890 the primary PCE fails. 1892 Policies defined for stateful PCEs and PCCs should eventually fit in 1893 the Policy-Enabled Path Computation Framework defined in [RFC5394], 1894 and the framework should be extended to support Stateful PCEs. 1896 9.2. Information and Data Models 1898 PCEP session configuration and information in the PCEP MIB module 1899 SHOULD be extended to include negotiated stateful capabilities, 1900 synchronization status, and delegation status (at the PCC list PCEs 1901 with delegated LSPs). 1903 9.3. Liveness Detection and Monitoring 1905 PCEP protocol extensions defined in this document do not require any 1906 new mechanisms beyond those already defined in [RFC5440], Section 1907 8.3. 1909 9.4. Verifying Correct Operation 1911 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 1912 protocol extensions defined in this document. In addition to 1913 monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP 1914 implementation SHOULD provide the following parameters: 1916 o Total number of LSP updates 1918 o Number of successful LSP updates 1920 o Number of dropped LSP updates 1922 o Number of LSP updates where LSP setup failed 1924 A PCC implementation SHOULD provide a command to show to which PCEs 1925 LSPs are delegated. 1927 A PCC implementation SHOULD allow the operator to manually revoke LSP 1928 delegation. 1930 9.5. Requirements on Other Protocols and Functional Components 1932 PCEP protocol extensions defined in this document do not put new 1933 requirements on other protocols. 1935 9.6. Impact on Network Operation 1937 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 1938 protocol extensions defined in this document. 1940 Additionally, a PCEP implementation SHOULD allow a limit to be placed 1941 on the rate PCUpd and PCRpt messages sent by a PCEP speaker and 1942 processed from a peer. It SHOULD also allow sending a notification 1943 when a rate threshold is reached. 1945 A PCC implementation SHOULD allow a limit to be placed on the rate of 1946 LSP Updates to the same LSP to avoid signaling overload discussed in 1947 Section 10.3. 1949 10. Security Considerations 1951 10.1. Vulnerability 1953 This document defines extensions to PCEP to enable stateful PCEs. 1954 The nature of these extensions and the delegation of path control to 1955 PCEs results in more information being available for a hypothetical 1956 adversary and a number of additional attack surfaces which must be 1957 protected. 1959 The security provisions described in [RFC5440] remain applicable to 1960 these extensions. However, because the protocol modifications 1961 outlined in this document allow the PCE to control path computation 1962 timing and sequence, the PCE defense mechanisms described in 1963 [RFC5440] section 7.2 are also now applicable to PCC security. 1965 As a general precaution, it is RECOMMENDED that these PCEP extensions 1966 only be activated on authenticated and encrypted sessions across PCEs 1967 and PCCs belonging to the same administrative authority. 1969 The following sections identify specific security concerns that may 1970 result from the PCEP extensions outlined in this document along with 1971 recommended mechanisms to protect PCEP infrastructure against related 1972 attacks. 1974 10.2. LSP State Snooping 1976 The stateful nature of this extension explicitly requires LSP status 1977 updates to be sent from PCC to PCE. While this gives the PCE the 1978 ability to provide more optimal computations to the PCC, it also 1979 provides an adversary with the opportunity to eavesdrop on decisions 1980 made by network systems external to PCE. This is especially true if 1981 the PCC delegates LSPs to multiple PCEs simultaneously. 1983 Adversaries may gain access to this information by eavesdropping on 1984 unsecured PCEP sessions, and might then use this information in 1985 various ways to target or optimize attacks on network infrastructure. 1986 For example by flexibly countering anti-DDoS measures being taken to 1987 protect the network, or by determining choke points in the network 1988 where the greatest harm might be caused. 1990 PCC implementations which allow concurrent connections to multiple 1991 PCEs SHOULD allow the operator to group the PCEs by administrative 1992 domains and they MUST NOT advertise LSP existence and state to a PCE 1993 if the LSP is delegated to a PCE in a different group. 1995 10.3. Malicious PCE 1997 The LSP delegation mechanism described in this document allows a PCC 1998 to grant effective control of an LSP to the PCE for the duration of a 1999 PCEP session. While this enables PCE control of the timing and 2000 sequence of path computations within and across PCEP sessions, it 2001 also introduces a new attack vector: an attacker may flood the PCC 2002 with PCUpd messages at a rate which exceeds either the PCC's ability 2003 to process them or the network's ability to signal the changes, 2004 either by spoofing messages or by compromising the PCE itself. 2006 A PCC is free to revoke an LSP delegation at any time without needing 2007 any justification. A defending PCC can do this by enqueueing the 2008 appropriate PCRpt message. As soon as that message is enqueued in 2009 the session, the PCC is free to drop any incoming PCUpd messages 2010 without additional processing. 2012 10.4. Malicious PCC 2014 A stateful session also result in increased attack surface by placing 2015 a requirement for the PCE to keep an LSP state replica for each PCC. 2016 It is RECOMMENDED that PCE implementations provide a limit on 2017 resources a single PCC can occupy. 2019 Delegation of LSPs can create further strain on PCE resources and a 2020 PCE implementation MAY preemptively give back delegations if it finds 2021 itself lacking the resources needed to effectively manage the 2022 delegation. Since the delegation state is ultimately controlled by 2023 the PCC, PCE implementations SHOULD provide throttling mechanisms to 2024 prevent strain created by flaps of either a PCEP session or an LSP 2025 delegation. 2027 11. Acknowledgements 2029 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 2030 Casellas for their contributions to this document. 2032 We would like to thank Shane Amante,Julien Meuric, Kohei Shiomoto, 2033 Paul Schultz and Raveendra Torvi for their comments and suggestions. 2034 Thanks also to Dhruv Dhoddy, Oscar Gonzales de Dios, Tomas Janciga, 2035 Stefan Kobza and Kexin Tang for helpful discussions. 2037 12. References 2038 12.1. Normative References 2040 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2041 Requirement Levels", BCP 14, RFC 2119, March 1997. 2043 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2044 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2045 Functional Specification", RFC 2205, September 1997. 2047 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2048 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2049 Tunnels", RFC 3209, December 2001. 2051 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2052 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2053 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2055 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 2056 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 2057 May 2005. 2059 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 2060 "OSPF Protocol Extensions for Path Computation Element 2061 (PCE) Discovery", RFC 5088, January 2008. 2063 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 2064 "IS-IS Protocol Extensions for Path Computation Element 2065 (PCE) Discovery", RFC 5089, January 2008. 2067 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2068 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2069 May 2008. 2071 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 2072 (PCE) Communication Protocol (PCEP)", RFC 5440, 2073 March 2009. 2075 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2076 Used to Form Encoding Rules in Various Routing Protocol 2077 Specifications", RFC 5511, April 2009. 2079 12.2. Informative References 2081 [I-D.ietf-pce-gmpls-pcep-extensions] 2082 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 2083 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-06 (work in 2084 progress), July 2012. 2086 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2087 LSP Path Computation using Preemption", Global 2088 Information Infrastructure Symposium, July 2007. 2090 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2091 programming algorithm for balancing the max-min fairness 2092 and throughput objectives in traffic engineering", pre- 2093 print, 2011. 2095 [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network 2096 Recovery: Protection and Restoration of Optical, SONET- 2097 SDH, IP, and MPLS", The Morgan Kaufmann Series in 2098 Networking, June 2004. 2100 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2101 McManus, "Requirements for Traffic Engineering Over MPLS", 2102 RFC 2702, September 1999. 2104 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2105 Label Switching Architecture", RFC 3031, January 2001. 2107 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2108 Christian, B., and W. Lai, "Applicability Statement for 2109 Traffic Engineering with MPLS", RFC 3346, August 2002. 2111 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2112 (TE) Extensions to OSPF Version 2", RFC 3630, 2113 September 2003. 2115 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2116 Element (PCE)-Based Architecture", RFC 4655, August 2006. 2118 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 2119 Communication Protocol Generic Requirements", RFC 4657, 2120 September 2006. 2122 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2123 Engineering", RFC 5305, October 2008. 2125 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2126 "Policy-Enabled Path Computation Framework", RFC 5394, 2127 December 2008. 2129 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 2130 Computation Element Communication Protocol (PCEP) 2131 Requirements and Protocol Extensions in Support of Global 2132 Concurrent Optimization", RFC 5557, July 2009. 2134 Authors' Addresses 2136 Edward Crabbe 2137 Google, Inc. 2138 1600 Amphitheatre Parkway 2139 Mountain View, CA 94043 2140 US 2142 Email: edc@google.com 2144 Jan Medved 2145 Cisco Systems, Inc. 2146 170 West Tasman Dr. 2147 San Jose, CA 95134 2148 US 2150 Email: jmedved@cisco.com 2152 Ina Minei 2153 Juniper Networks, Inc. 2154 1194 N. Mathilda Ave. 2155 Sunnyvale, CA 94089 2156 US 2158 Email: ina@juniper.net 2160 Robert Varga 2161 Pantheon Technologies SRO 2162 Mlynske Nivy 56 2163 Bratislava 821 05 2164 Slovakia 2166 Email: robert.varga@pantheon.sk