idnits 2.17.1 draft-ietf-pce-stateful-pce-00.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 (February 28, 2012) is 4439 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 1777, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 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: August 31, 2012 Cisco Systems, Inc. 6 R. Varga 7 Pantheon Technologies LLC 8 I. Minei 9 Juniper Networks, Inc. 10 February 28, 2012 12 PCEP Extensions for Stateful PCE 13 draft-ietf-pce-stateful-pce-00 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 August 31, 2012. 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 . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7 74 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 14 75 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 14 76 4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 15 77 5. Architectural Overview of Protocol Extensions . . . . . . . . 16 78 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 16 79 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 16 80 5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 17 81 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 18 82 5.4.1. State Synchronization Avoidance . . . . . . . . . . . 20 83 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 23 84 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 24 85 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 24 86 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 25 87 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 26 88 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 26 89 5.6.1. Passive Stateful PCE Path Computation 90 Request/Response . . . . . . . . . . . . . . . . . . . 26 91 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 28 92 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 29 93 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 29 94 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 29 95 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 30 96 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 31 97 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 32 98 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 32 99 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 32 100 7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 33 101 7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 34 102 7.2.1. The LSP Symbolic Name TLV . . . . . . . . . . . . . . 35 103 7.2.2. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 36 104 7.2.3. LSP Update Error Code TLV . . . . . . . . . . . . . . 39 105 7.2.4. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 39 106 7.2.5. LSP State Database Version TLV . . . . . . . . . . . . 40 107 7.2.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 41 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 109 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 41 110 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 41 111 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 42 112 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 42 113 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 43 114 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 43 115 8.7. LSP-UPDATE-ERROR-CODE TLV . . . . . . . . . . . . . . . . 44 116 9. Manageability Considerations . . . . . . . . . . . . . . . . . 44 117 9.1. Control Function and Policy . . . . . . . . . . . . . . . 44 118 9.2. Information and Data Models . . . . . . . . . . . . . . . 45 119 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 45 120 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 45 121 9.5. Requirements on Other Protocols and Functional 122 Components . . . . . . . . . . . . . . . . . . . . . . . . 46 123 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 46 124 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 125 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 46 126 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 47 127 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 47 128 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 48 129 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 131 12.1. Normative References . . . . . . . . . . . . . . . . . . . 48 132 12.2. Informative References . . . . . . . . . . . . . . . . . . 49 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 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 143 This document specifies a set of extensions to PCEP to enable 144 stateful control of TE LSPs between and across PCEP sessions in 145 compliance with [RFC4657]. It includes mechanisms to effect LSP 146 state synchronization between PCCs and PCEs, delegation of control of 147 LSPs to PCEs, and PCE control of timing and sequence of path 148 computations within and across PCEP sessions. 150 2. Terminology 152 This document uses the following terms defined in [RFC5440]: PCC, 153 PCE, PCEP Peer. 155 This document uses the following terms defined in [RFC4090]: MPLS TE 156 Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup. 158 The following terms are defined in this document: 160 Passive Stateful PCE: uses LSP state information learned from PCCs 161 to optimize path computations. It does not actively update LSP 162 state. A PCC maintains synchronization with the PCE. 164 Active Stateful PCE: uses LSP state information learned from PCCs to 165 optimize path computations. Additionally, it actively updates LSP 166 parameters in those PCCs that delegated control over their LSPs to 167 the PCE. 169 Delegation: An operation to grant a PCE temporary rights to modify a 170 subset of LSPs parameters on one or more PCC's LSPs. LSPs are 171 delegated from a PCC to a PCE. 173 Delegation Timeout Interval: when a PCEP session is terminated, a 174 PCC waits for this time period before revoking LSP delegation to a 175 PCE. 177 LSP State Report: an operation to send LSP state (Operational / 178 Admin Status, LSP attributes configured and set by a PCE, etc.) 179 from a PCC to a PCE. 181 LSP Update Request: an operation where a PCE requests a PCC to 182 update one or more attributes of an LSP and to re-signal the LSP 183 with updated attributes. 185 LSP Priority: a specific pair of MPLS setup and hold priority 186 values. 188 LSP State Database: information about and attributes of all LSPs 189 that are being reported to one or more PCEs via LSP State Reports. 191 Minimum Cut Set: the minimum set of links for a specific source 192 destination pair which, when removed from the network, result in a 193 specific source being completely isolated from specific 194 destination. The summed capacity of these links is equivalent to 195 the maximum capacity from the source to the destination by the 196 max-flow min-cut theorem. 198 MPLS TE Global Default Restoration: once an LSP failure is detected 199 by some downstream mode, the head-end LSP is notified by means of 200 RSVP. Upon receiving the notification, the headend Label 201 Switching Router (LSR) recomputes the path and signals the LSP 202 along an alternate path. [NET-REC] 204 MPLS TE Global Path Protection: once an LSP failure is detected by 205 some downstream mode, the head-end LSP is notified by means of 206 RSVP. Upon receiving the notification, the headend LSR reroutes 207 traffic using a pre-signaled backup (secondary) LSP. [NET-REC]. 209 Within this document, when describing PCE-PCE communications, the 210 requesting PCE fills the role of a PCC. This provides a saving in 211 documentation without loss of function. 213 The message formats in this document are specified using Routing 214 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 216 3. Motivation and Objectives 218 3.1. Motivation 220 3.1.1. Background 222 Traffic engineering has been a goal of the MPLS architecture since 223 its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic 224 engineering system provided by [RFC3630], [RFC5305], and [RFC3209] 225 information about network resources utilization is only available as 226 total reserved capacity by traffic class on a per interface basis; 227 individual LSP state is available only locally on each LER for it's 228 own LSPs. In most cases, this makes good sense, as distribution and 229 retention of total LSP state for all LERs within in the network would 230 be prohibitively costly. 232 Unfortunately, this visibility in terms of global LSP state may 233 result in a number of issues for some demand patterns, particularly 234 within a common setup and hold priority. This issue affects online 235 traffic engineering systems, and in particular, the widely 236 implemented but seldom deployed auto-bandwidth system. 238 A sufficiently over-provisioned system will by definition have no 239 issues routing its demand on the shortest path. However, lowering 240 the degree to which network over-provisioning is required in order to 241 run a healthy, functioning network is a clear and explicit promise of 242 MPLS architecture. In particular, it has been a goal of MPLS to 243 provide mechanisms to alleviate congestion scenarios in which 244 "traffic streams are inefficiently mapped onto available resources; 245 causing subsets of network resources to become over-utilized while 246 others remain underutilized" ([RFC2702]). 248 3.1.2. Why a Stateful PCE? 250 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 251 "strict synchronization between the PCE and not only the network 252 states (in term of topology and resource information), but also the 253 set of computed paths and reserved resources in use in the network." 254 [RFC4655] also expressed a number of concerns with regard to a 255 stateful PCE, specifically: 257 o Any reliable synchronization mechanism would result in significant 258 control plane overhead 260 o Out-of-band ted synchronization would be complex and prone to race 261 conditions 263 o Path calculations incorporating total network state would be 264 highly complex 266 In general, stress on the MPLS TE control plane will be directly 267 proportional to the size of the system being controlled and the and 268 the tightness of the control loop, and indirectly proportional to the 269 amount of over-provisioning in terms of both network capacity and 270 reservation overhead. 272 Despite these concerns in terms of implementation complexity and 273 scalability, several TE algorithms exist today that have been 274 demonstrated to be extremely effective in large TE systems, providing 275 both rapid convergence and significant benefits in terms of 276 optimality of resource usage [MXMN-TE]. All of these systems share 277 at least two common characteristics: the requirement for both global 278 visibility of a flow (or in this case, a TE LSP) state and for 279 ordered control of path reservations across devices within the system 280 being controlled. While some approaches have been suggested in order 281 to remove the requirements for ordered control (See [MPLS-PC]), these 282 approaches are highly dependent on traffic distribution, and do not 283 allow for multiple simultaneous LSP priorities representing diffserv 284 classes. 286 The following use cases demonstrate a need for visibility into global 287 inter-PCC LSP state in PCE path computations, and for a PCE control 288 of sequence and timing in altering LSP path characteristics within 289 and across PCEP sessions. Reference topologies for the use cases 290 described later in this section are shown in Figures 1 and 2. 292 Unless otherwise cited, use cases assume that all LSPs listed exist 293 at the same LSP priority. 295 +-------+ 296 | A | 297 | | 298 +-------+ 299 \ 300 +-------+ +-------+ 301 | C |-------------------------| E | 302 | | | | 303 +-------+ +-------+ +-------+ 304 / \ | D | / 305 +-------+ ------| |------ 306 | B | +-------+ 307 | | 308 +-------+ 310 Figure 1: Reference topology 1 312 +-------+ +-------+ +-------+ 313 | A | | B | | C | 314 | | | | | | 315 +---+---+ +---+---+ +---+---+ 316 | | | 317 | | | 318 +---+---+ +---+---+ +---+---+ 319 | E | | F | | G | 320 | +--------+ +--------+ | 321 +-------+ +-------+ +-------+ 322 Figure 2: Reference topology 2 324 3.1.2.1. Throughput Maximization and Bin Packing 326 Because LSP attribute changes in [RFC5440] are driven by PCReq 327 messages under control of a PCC's local timers, the sequence of RSVP 328 reservation arrivals occurring in the network will be randomized. 329 This, coupled with a lack of global LSP state visibility on the part 330 of a stateless PCE may result in suboptimal throughput in a given 331 network topology. 333 Reference topology 2 in Figure 2 and Tables 1 and 2 show an example 334 in which throughput is at 50% of optimal as a result of lack of 335 visibility and synchronized control across PCC's. In this scenario, 336 the decision must be made as to whether to route any portion of the 337 E-G demand, as any demand routed for this source and destination will 338 decrease system throughput. 340 +------+--------+----------+ 341 | Link | Metric | Capacity | 342 +------+--------+----------+ 343 | A-E | 1 | 10 | 344 | B-F | 1 | 10 | 345 | C-G | 1 | 10 | 346 | E-F | 1 | 10 | 347 | F-G | 1 | 10 | 348 +------+--------+----------+ 350 Table 1: Link parameters for Throughput use case 352 +------+-----+-----+-----+--------+----------+-------+ 353 | Time | LSP | Src | Dst | Demand | Routable | Path | 354 +------+-----+-----+-----+--------+----------+-------+ 355 | 1 | 1 | E | G | 10 | Yes | E-F-G | 356 | 2 | 2 | A | B | 10 | No | --- | 357 | 3 | 1 | F | C | 10 | No | --- | 358 +------+-----+-----+-----+--------+----------+-------+ 360 Table 2: Throughput use case demand time series 362 In many cases throughput maximization becomes a bin packing problem. 363 While bin packing itself is an NP-hard problem, a number of common 364 heuristics which run in polynomial time can provide significant 365 improvements in throughput over random reservation event 366 distribution, especially when traversing links which are members of 367 the minimum cut set for a large subset of source destination pairs. 369 Tables 3 and 4 show a simple use case using Reference Topology 1 in 370 Figure 1, where LSP state visibility and control of reservation order 371 across PCCs would result in significant improvement in total 372 throughput. 374 +------+--------+----------+ 375 | Link | Metric | Capacity | 376 +------+--------+----------+ 377 | A-C | 1 | 10 | 378 | B-C | 1 | 10 | 379 | C-E | 10 | 5 | 380 | C-D | 1 | 10 | 381 | D-E | 1 | 10 | 382 +------+--------+----------+ 384 Table 3: Link parameters for Bin Packing use case 386 +------+-----+-----+-----+--------+----------+---------+ 387 | Time | LSP | Src | Dst | Demand | Routable | Path | 388 +------+-----+-----+-----+--------+----------+---------+ 389 | 1 | 1 | A | E | 5 | Yes | A-C-D-E | 390 | 2 | 2 | B | E | 10 | No | --- | 391 +------+-----+-----+-----+--------+----------+---------+ 393 Table 4: Bin Packing use case demand time series 395 3.1.2.2. Deadlock 397 Most existing RSVP-TE implementations will not tear down established 398 LSPs in the event of the failure of the bandwidth increase procedure 399 detailed in [RFC3209]. This behavior is directly implied to be 400 correct in [RFC3209] and is often desirable from an operator's 401 perspective, because either a) the destination prefixes are not 402 reachable via any means other than MPLS or b) this would result in 403 significant packet loss as demand is shifted to other LSPs in the 404 overlay mesh. 406 In addition, there are currently few implementations offering ingress 407 admission control at the LSP level. Again, having ingress admission 408 control on a per LSP basis is not necessarily desirable from an 409 operational perspective, as a) one must over-provision tunnels 410 significantly in order to avoid deleterious effects resulting from 411 stacked transport and flow control systems and b) there is currently 412 no efficient commonly available northbound interface for dynamic 413 configuration of per LSP ingress admission control (such an interface 414 could easily be defined using the extensions present in this spec, 415 but it beyond the scope of the current document). 417 Lack of ingress admission control coupled with the behavior in 419 [RFC3209] effectively results in mis-signaled LSPs during periods of 420 contention for network capacity between LSPs in a given LSP priority. 421 This in turn causes information loss in the TED with regard to actual 422 network state, resulting in LSPs sharing common network interfaces 423 with mis-signaled LSPs operating in a degraded state for significant 424 periods of time, even when unused network capacity may potentially be 425 available. 427 Reference Topology 1 in Figure 1 and Tables 5 and 6 show a use case 428 that demonstrates this behavior. Two LSPs, LSP 1 and LSP 2 are 429 signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E 430 respectively. At a later time, the demand of LSP 1 increases to 20. 431 Under such a demand, the LSP cannot be resignaled. However, the 432 existing LSP will not be torn down. In the absence of ingress 433 policing, traffic on LSP 1 will cause degradation for traffic of LSP 434 2 (due to oversubscription on the links C-D and D-E), as well as 435 information loss in the TED with regard to the actual network state. 437 The problem could be easily ameliorated by global visibility of LSP 438 state coupled with PCC- external demand measurements and placement of 439 two LSPs on disjoint links. Note that while the demand of 20 for LSP 440 1 could never be satisfied in the given topology, what could be 441 achieved would be isolation from the ill-effects of the 442 (unsatisfiable) increased demand. 444 +------+--------+----------+ 445 | Link | Metric | Capacity | 446 +------+--------+----------+ 447 | A-C | 1 | 10 | 448 | B-C | 1 | 10 | 449 | C-E | 10 | 5 | 450 | C-D | 1 | 10 | 451 | D-E | 1 | 10 | 452 +------+--------+----------+ 454 Table 5: Link parameters for the 'Deadlock' example 456 +------+-----+-----+-----+--------+----------+---------+ 457 | Time | LSP | Src | Dst | Demand | Routable | Path | 458 +------+-----+-----+-----+--------+----------+---------+ 459 | 1 | 1 | A | E | 2 | Yes | A-C-D-E | 460 | 2 | 2 | B | E | 2 | Yes | B-C-D-E | 461 | 3 | 1 | A | E | 20 | No | --- | 462 +------+-----+-----+-----+--------+----------+---------+ 464 Table 6: Deadlock LSP and demand time series 466 3.1.2.3. Minimum Perturbation 468 As a result of both the lack of visibility into global LSP state and 469 the lack of control over event ordering across PCE sessions, 470 unnecessary perturbations may be introduced into the network by a 471 stateless PCE. Tables 7 and 8 show an example of an unnecessary 472 network perturbation using Reference Topology 1 in Figure 1. In this 473 case an unimportant (high LSP priority value) LSP (LSP1) is first set 474 up along the shortest path. At time 2, which is assumed to be 475 relatively close to time 1, a second more important (lower LSP- 476 priority value) LSP is established, preempting LSP 1 and shifting it 477 to the longer A-C-E path. 479 +------+--------+----------+ 480 | Link | Metric | Capacity | 481 +------+--------+----------+ 482 | A-C | 1 | 10 | 483 | B-C | 1 | 10 | 484 | C-E | 10 | 10 | 485 | C-D | 1 | 10 | 486 | D-E | 1 | 10 | 487 +------+--------+----------+ 489 Table 7: Link parameters for the 'Minimum-Perturbation' example 491 +------+-----+-----+-----+--------+----------+----------+---------+ 492 | Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path | 493 +------+-----+-----+-----+--------+----------+----------+---------+ 494 | 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E | 495 | 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E | 496 | 3 | 1 | A | E | 7 | 7 | Yes | A-C-E | 497 +------+-----+-----+-----+--------+----------+----------+---------+ 499 Table 8: Minimum-Perturbation LSP and demand time series 501 3.1.2.4. Predictability 503 Randomization of reservation events caused by lack of control over 504 event ordering across PCE sessions results in poor predictability in 505 LSP routing. An offline system applying a consistent optimization 506 method will produce predictable results to within either the boundary 507 of forecast error when reservations are over-provisioned by 508 reasonable margins or to the variability of the signal and the 509 forecast error when applying some hysteresis in order to minimize 510 churn. 512 Reference Topology 1 and Tables 9, 10 and 11 show the impact of event 513 ordering and predictability of LSP routing. 515 +------+--------+----------+ 516 | Link | Metric | Capacity | 517 +------+--------+----------+ 518 | A-C | 1 | 10 | 519 | B-C | 1 | 10 | 520 | C-E | 1 | 10 | 521 | C-D | 1 | 10 | 522 | D-E | 1 | 10 | 523 +------+--------+----------+ 525 Table 9: Link parameters for the 'Predictability' example 527 +------+-----+-----+-----+--------+----------+---------+ 528 | Time | LSP | Src | Dst | Demand | Routable | Path | 529 +------+-----+-----+-----+--------+----------+---------+ 530 | 1 | 1 | A | E | 7 | Yes | A-C-E | 531 | 2 | 2 | B | E | 7 | Yes | B-C-D-E | 532 +------+-----+-----+-----+--------+----------+---------+ 534 Table 10: Predictability LSP and demand time series 1 536 +------+-----+-----+-----+--------+----------+---------+ 537 | Time | LSP | Src | Dst | Demand | Routable | Path | 538 +------+-----+-----+-----+--------+----------+---------+ 539 | 1 | 2 | B | E | 7 | Yes | B-C-E | 540 | 2 | 1 | A | E | 7 | Yes | A-C-D-E | 541 +------+-----+-----+-----+--------+----------+---------+ 543 Table 11: Predictability LSP and demand time series 2 545 3.1.2.5. Global Concurrent Optimization 547 Global Concurrent Optimization (GCO) defined in [RFC5557] is a 548 network optimization mechanism that is able to simultaneously 549 consider the entire topology of the network and the complete set of 550 existing TE LSPs and their existing constraints, and look to optimize 551 or reoptimize the entire network to satisfy all constraints for all 552 TE LSPs. It allows for bulk path computations in order to avoid 553 blocking problems and to achieve more optimal network-wide solutions. 555 Global control of LSP operation sequence in [RFC5557] is predicated 556 on the use of what is effectively a stateful (or semi-stateful) NMS. 557 The NMS can be either not local to the switch, in which case another 558 northbound interface is required for LSP attribute changes, or local/ 559 collocated, in which case there are significant issues with 560 efficiency in resource usage. Stateful PCE adds a few features that: 562 o Roll the NMS visibility into the PCE and remove the requirement 563 for an additional northbound interface 565 o Allow the PCE to determine when re-optimization is needed 567 o Allow the PCE to determine which LSPs should be re-optimized 569 o Allow a PCE to control the sequence of events across multiple 570 PCCs, allowing for bulk (and truly global) optimization, LSP 571 shuffling etc. 573 3.1.3. Protocol vs. Configuration 575 Note that existing configuration tools and protocols can be used to 576 set LSP state. However, this solution has several shortcomings: 578 o Scale & Performance: configuration operations often require 579 processing of additional configuration portions beyond the state 580 being directly acted upon, with corresponding cost in CPU cycles, 581 negatively impacting both PCC stability LSP update rate capacity. 583 o Scale & Performance: configuration operations often have 584 transactional semantics which are typically heavyweight and 585 require additional CPU cycles, negatively impacting PCC update 586 rate capacity. 588 o Security: opening up a configuration channel to a PCE would allow 589 a malicious PCE to take over a PCC. The PCEP extensions described 590 in this document only allow a PCE control over a very limited set 591 of LSP attributes. 593 o Interoperability: each vendor has a proprietary information model 594 for configuring LSP state, which prevents interoperability of a 595 PCE with PCCs from different vendors. The PCEP extensions 596 described in this document allow for a common information model 597 for LSP state for all vendors. 599 o Efficient State Synchronization: configuration channels may be 600 heavyweight and unidirectional, therefore efficient state 601 synchronization between a PCE and a PCE may be a problem. 603 3.2. Objectives 605 The objectives for the protocol extensions to support stateful PCE 606 described in this document are as follows: 608 o Allow a single PCC to interact with a mix of stateless and 609 stateful PCEs simultaneously using the same PCEP. 611 o Support efficient LSP state synchronization between the PCC and 612 one or more active or passive stateful PCEs. 614 o Allow a PCC to delegate control of its LSPs to an active stateful 615 PCE such that a single LSP is under the control a single PCE at 616 any given time. A PCC may revoke this delegation at any point 617 during the lifetime of the PCEP session. A PCE may return this 618 delegation at any point during the lifetime of the PCEP session. 620 o Allow a PCE to control computation timing and update timing across 621 all LSPs that have been delegated to it. 623 o Allow a PCE to specify protection / restoration settings for all 624 LSPs that have been delegated to it. 626 o Enable uninterrupted operation of PCC's LSPs in the event PCE 627 failure or while control of LSPs is being transferred between 628 PCEs. 630 4. New Functions to Support Stateful PCEs 632 Several new functions will be required in PCEP to support stateful 633 PCEs. A function can be initiated either from a PCC towards a PCE 634 (C-E) or from a PCE towards a PCC (E-C). The new functions are: 636 Capability negotiation (E-C,C-E): both the PCC and the PCE must 637 announce during PCEP session establishment that they support PCEP 638 Stateful PCE extensions defined in this document. 640 LSP state synchronization (C-E): after the session between the PCC 641 and a stateful PCE is initialized, the PCE must learn the state of 642 a PCC's LSPs before it can perform path computations or update LSP 643 attributes in a PCC. 645 LSP Update Request (E-C): A PCE requests modification of attributes 646 on a PCC's LSP. 648 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 649 whenever the state of an LSP changes. 651 LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 652 update LSP attributes on one or more LSPs; the PCE becomes the 653 authoritative source of the LSP's attributes as long as the 654 delegation is in effect (See Section 5.5); the PCC may withdraw 655 the delegation or the PCE may give up the delegation 657 In addition to new PCEP functions, stateful capabilities discovery 658 will be required in OSPF ([RFC5088]) and IS-IS ([RFC5089]). Stateful 659 capabilities discovery is not in scope of this document. 661 5. Architectural Overview of Protocol Extensions 663 5.1. LSP State Ownership 665 In the PCEP protocol (defined in [RFC5440]), LSP state and operation 666 are under the control of a PCC (a PCC may be an LSR or a management 667 station). Attributes received from a PCE are subject to PCC's local 668 policy. The PCEP protocol extensions described in this document do 669 not change this behavior. 671 An active stateful PCE may have control of a PCC's LSPs be delegated 672 to it, but the LSP state ownership is retained by the PCC. In 673 particular, in addition to specifying values for LSP's attributes, an 674 active stateful PCE also decides when to make LSP modifications. 676 Retaining LSP state ownership on the PCC allows for: 678 o a PCC to interact with both stateless and stateful PCEs at the 679 same time 681 o a stateful PCE to only modify a small subset of LSP parameters, 682 i.e. to set only a small subset of the overall LSP state; other 683 parameters may be set by the operator through CLI commands 685 o a PCC to revert delegated LSP to an operator-defined default or to 686 delegate the LSPs to a different PCE, if the PCC get disconnected 687 from a PCE with currently delegated LSPs 689 5.2. New Messages 691 In this document, we define the following new PCEP messages: 693 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 694 to a PCE to report the status of one or more LSPs. Each LSP 695 Status Report in a PCRpt message can contain the actual LSP's 696 path,bandwidth, operational and administrative status, etc. An 697 LSP Status Report carried on a PCRpt message is also used in 698 delegation or revocation of control of an LSP to/from a PCE. The 699 PCRep message is described in Section 6.1. 701 Path Computation Update Request (PCUpd): a PCEP message sent by a 702 PCE to a PCC to update LSP parameters, on one or more LSPs. Each 703 LSP Update Request on a PCUpd message MUST contain all LSP 704 parameters that a PCE wishes to set for a given LSP. An LSP 705 Update Request carried on a PCUpd message is also used to return 706 LSP delegations if at any point PCE no longer desires control of 707 an LSP. The PCUpd message is described in Section 6.2. 709 The new functions defined in Section 4 are mapped onto the new 710 messages as shown in the following table. 712 +----------------------------------------+--------------------------+ 713 | Function | Message | 714 +----------------------------------------+--------------------------+ 715 | Capability Negotiation (E-C,C-E) | Open | 716 | State Synchronization (C-E) | PCRpt | 717 | LSP State Report (C-E) | PCRpt | 718 | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | 719 | LSP Update Request (E-C) | PCUpd | 720 | ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS | 721 | | sub-TLV | 722 | OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, | 723 | | PCE-CAP-FLAGS sub-TLV | 724 +----------------------------------------+--------------------------+ 726 Table 12: New Function to Message Mapping 728 5.3. Capability Negotiation 730 During PCEP Initialization Phase, PCEP Speakers (PCE pr PCC) 731 negotiate the use of stateful PCEP extensions. A PCEP Speaker 732 includes the "Stateful PCE Capability" TLV, described in 733 Section 7.1.1, in the OPEN Object to advertise its support for PCEP 734 stateful extensions. The Stateful Capability TLV includes the 'LSP 735 Update' Flag that indicates whether the PCEP Speaker supports LSP 736 parameter updates. 738 The presence of the Stateful PCE Capability TLV in PCC's OPEN Object 739 indicates that the PCC is willing to send LSP State Reports whenever 740 LSP parameters or operational status changes. 742 The presence of the Stateful PCE Capability TLV in PCE's OPEN message 743 indicates that the PCE is interested in receiving LSP State Reports 744 whenever LSP parameters or operational status changes. 746 The PCEP protocol extensions for stateful PCEs MAY only be used if 747 both sides have included the Stateful PCE Capability TLV in their 748 respective OPEN messages, otherwise a PCErr with code "Stateful PCE 749 capability not negotiated" (see Section 8.4) will be generated and 750 the PCEP session will be terminated. 752 LSP delegation and LSP update operations defined in this document MAY 753 only be used if both PCEP Speakers set the LSP-UPDATE Flag in the 754 "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)', 755 otherwise a PCErr with code "Delegation not negotiated" (see 756 Section 8.4) will be generated. Note that even if the update 757 capability has not been negotiated, a PCE can still receive LSP 758 Status Reports from a PCC and build and maintain an up to date view 759 of the state of the PCC's LSPs. 761 5.4. State Synchronization 763 The purpose of State Synchronization is to provide a checkpoint-in- 764 time state replica of a PCC's LSP state in a PCE. State 765 Synchronization is performed immediately after the Initialization 766 phase ([RFC5440]). 768 During State Synchronization, a PCC first takes a snapshot of the 769 state of its LSPs state, then sends the snapshot to a PCE in a 770 sequence of LSP State Reports. Each LSP State Report sent during 771 State Synchronization has the SYNC Flag in the LSP Object set to 1. 772 The set of LSPs for which state is synchronized with a PCE is 773 determined by negotiated stateful PCEP capabilities and PCC's local 774 configuration (see more details in Section 9.1). 776 A PCE SHOULD NOT send PCUpd messages to a PCC before State 777 Synchronization is complete. A PCC SHOULD NOT send PCReq messages to 778 a PCE before State Synchronization is complete. This is to allow the 779 PCE to get the best possible view of the network before it starts 780 computing new paths. 782 If the PCC encounters a problem which prevents it from completing the 783 state transfer, it MUST send a PCErr message to the PCE and terminate 784 the session using the PCEP session termination procedure. 786 The PCE does not send positive acknowledgements for properly received 787 synchronization messages. It MUST respond with a PCErr message 788 indicating "PCRpt error" (see ) if it encounters a problem with the 789 LSP State Report it received from the PCC. Either the PCE or the PCC 790 MAY terminate the session if the PCE encounters a problem during the 791 synchronization. 793 The successful State Synchronization sequence is shown in Figure 3. 795 +-+-+ +-+-+ 796 |PCC| |PCE| 797 +-+-+ +-+-+ 798 | | 799 |-----PCRpt, SYNC=1----->| (Sync start) 800 | | 801 |-----PCRpt, SYNC=1----->| 802 | . | 803 | . | 804 | . | 805 |-----PCRpt, SYNC=1----->| (Sync done) 806 | . | 807 | . | 808 | . | 809 | | 810 |-----PCRpt, SYNC=0----->| (Regular 811 | | LSP State Report) 813 Figure 3: Successful state synchronization 815 The sequence where the PCE fails during the State Synchronization 816 phase is shown in Figure 4. 818 +-+-+ +-+-+ 819 |PCC| |PCE| 820 +-+-+ +-+-+ 821 | | 822 |-----PCRpt, SYNC=1----->| 823 | | 824 |-----PCRpt, SYNC=1----->| 825 | . | 826 | . | 827 | . | 828 |-----PCRpt, SYNC=1----->| 829 | | 830 |-PCRpt, SYNC=1 | 831 | \ ,-PCErr=?-| 832 | \ / | 833 | \/ | 834 | /\ | 835 | / `-------->| (Ignored) 836 |<--------` | 838 Figure 4: Failed state synchronization (PCE failure) 840 The sequence where the PCC fails during the State Synchronization 841 phase is shown in Figure 5. 843 +-+-+ +-+-+ 844 |PCC| |PCE| 845 +-+-+ +-+-+ 846 | | 847 |-----PCRpt, SYNC=1----->| 848 | | 849 |-----PCRpt, SYNC=1----->| 850 | . | 851 | . | 852 | . | 853 |-------- PCErr=? ------>| 854 | | 856 Figure 5: Failed state synchronization (PCC failure) 858 5.4.1. State Synchronization Avoidance 860 State Synchronization MAY be skipped following a PCEP session restart 861 if the state of both PCEP peers did not change during the period 862 prior to session re-initialization. To be able to make this 863 determination, state must be exchanged and maintained by both PCE and 864 PCC during normal operation. This is accomplished by keeping track 865 of the changes to the LSP State Database. When State Synchronization 866 avoidance is enabled on a PCEP session, a PCC includes the LSP-DB- 867 VERSION TLV as an optional TLV in the LSP Object on each LSP State 868 Report. The LSP-DB-VERSION TLV contains a PCC's LSP State Database 869 version, which is incremented each time a change is made to the PCC's 870 local LSP State Database. The LSP State Database version is an 871 unsigned 64-bit value that MUST be incremented by 1 for each 872 successive change in the LSP state database. The LSP State Database 873 version MUST start at 1 and may wrap around. Values 0 and 874 0xFFFFFFFFFFFFFFF are reserved. 876 State Synchronization Avoidance is negotiated on a PCEP session 877 during session startup. 879 If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN 880 object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the 881 LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the 882 PCC's latest LSP State Database version. 884 If a PCE's LSP State Database survived the restart of a PCEP session, 885 the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and 886 the TLV will contain the last LSP State Database version received on 887 an LSP State Update from the PCC in a previous PCEP session. If a 888 PCC's LSP State Database survived the restart, the PCC will include 889 the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain 890 the last LSP State Database version sent on an LSP State Update from 891 the PCC in the previous PCEP session. If a PCEP Speaker's LSP State 892 Database did not survive the restart of a PCEP session, the PCEP 893 Speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN Object. 895 If both PCEP Speakers include the LSP-DB-VERSION TLV in the OPEN 896 Object and the TLV values match, the PCC MAY skip State 897 Synchronization. Otherwise, the PCE MUST purge any remaining LSP 898 state and expect the PCC to perform State Synchronization; if the PCC 899 attempts to skip State Synchronization (i.e. the SYNC Flag = 0 on the 900 first LSP State Report from the PCC), the PCE MUST send back a 901 PCError with Error-type 20 Error-value 2 'LSP Database version 902 mismatch', and close the PCEP session. 904 Note that a PCE MAY force State Synchronization by not including the 905 LSP-DB-VERSION TLV in its OPEN object. 907 Figure 6 shows an example sequence where State Synchronization is 908 skipped. 910 +-+-+ +-+-+ 911 |PCC| |PCE| 912 +-+-+ +-+-+ 913 | | 914 |-PCOpen-, | 915 | DBv=42 \ ,--PCOpen-| 916 | IDB=1 \ / DBv=42 | 917 | \/ IDB=1 | 918 | /\ | 919 | / `-------->| (OK to skip sync) 920 (Skip sync) |<--------` | 921 | . | 922 | . | 923 | . | 924 | | 925 |--PCRpt,DBv=43,SYNC=0-->| (Regular 926 | | LSP State Update) 927 |--PCRpt,DBv=44,SYNC=0-->| (Regular 928 | | LSP State Update) 929 |--PCRpt,DBv=45,SYNC=0-->| 930 | | 932 Figure 6: State Synchronization skipped 934 Figure 7 shows an example sequence where State Synchronization is 935 performed due to LSP State Database version mismatch during the PCEP 936 session setup. Note that the same State Synchronization sequence 937 would happen if either the PCE or the PCE would not include the LSP- 938 DB-VERSION TLV in their respective Open messages. 940 +-+-+ +-+-+ 941 |PCC| |PCE| 942 +-+-+ +-+-+ 943 | | 944 |-PCOpen-, | 945 | DBv=46 \ ,--PCOpen-| 946 | IDB=1 \ / DBv=42 | 947 | \/ IDB=1 | 948 | /\ | 949 | / `-------->| (Expect sync) 950 (Do sync) |<--------` | (Purge LSP State) 951 | | 952 |--PCRpt,DBv=46,SYNC=1-->| (Sync start) 953 | . | 954 | . | 955 | . | 956 |--PCRpt,DBv=46,SYNC=1-->| (Sync done) 957 | . | 958 | . | 959 | . | 960 |--PCRpt,DBv=47,SYNC=0-->| (Regular 961 | | LSP State Update) 962 |--PCRpt,DBv=48,SYNC=0-->| (Regular 963 | | LSP State Update) 964 |--PCRpt,DBv=49,SYNC=0-->| 965 | | 967 Figure 7: State Synchronization performed 969 Figure 8 shows an example sequence where State Synchronization is 970 skipped, but because one or both PCEP Speakers set the INCLUDE-DB- 971 VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the 972 PCE. If the current PCEP session restarts, the PCEP Speakers will 973 have to perform State Synchronization, since the PCE will not know 974 the PCC's latest LSP State Database version. 976 +-+-+ +-+-+ 977 |PCC| |PCE| 978 +-+-+ +-+-+ 979 | | 980 |-PCOpen-, | 981 | DBv=42 \ ,--PCOpen-| 982 | IDB=0 \ / DBv=42 | 983 | \/ IDB=0 | 984 | /\ | 985 | / `-------->| (OK to skip sync) 986 (Skip sync) |<--------` | 987 | . | 988 | . | 989 | . | 990 |------PCRpt,SYNC=0----->| (Regular 991 | | LSP State Update) 992 |------PCRpt,SYNC=0----->| (Regular 993 | | LSP State Update) 994 |------PCRpt,SYNC=0----->| 995 | | 997 Figure 8: State Synchronization skipped, no LSP-DB-VERSION TLVs sent 998 from PCC 1000 5.5. LSP Delegation 1002 If during Capability negotiation both the PCE and the PCC have 1003 indicated that they support LSP Update, then the PCC may choose to 1004 grant the PCE a temporary right to update (a subset of) LSP 1005 attributes on one or more LSPs. This is called "LSP Delegation", and 1006 it MAY be performed at any time after the Initialization phase. 1008 LSP Delegation is controlled by operator-defined policies on a PCC. 1009 LSPs are delegated individually - different LSPs may be delegated to 1010 different PCEs, and an LSP may be delegated to one or more PCEs. The 1011 delegation policy, when all PCC's LSPs are delegated to a single PCE 1012 at any given time, SHOULD be supported by all delegation-capable 1013 PCCs. Conversely, the policy revoking the delegation for all PCC's 1014 LSPs SHOULD also be supported 1016 A PCE may return LSP delegation at any time if it no longer wishes to 1017 update the LSP's state. A PCC may revoke LSP delegation at any time. 1018 Delegation, Revocation, and Return are done individually for each 1019 LSP. 1021 5.5.1. Delegating an LSP 1023 A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP 1024 State Report to 1. A PCE confirms the delegation when it sends the 1025 first LSP Update Request for the delegated LSP to the PCC by setting 1026 the Delegate flag to 1. Note that a PCE does not immediately confirm 1027 to the PCC the acceptance of LSP Delegation; Delegation acceptance is 1028 confirmed when the PCC wishes to update the LSP via the LSP Update 1029 Request. If a PCE does not accept the LSP Delegation, it MUST 1030 immediately respond with an empty LSP Update Request which has the 1031 Delegate flag set to 0. 1033 The delegation sequence is shown in Figure 9. 1035 +-+-+ +-+-+ 1036 |PCC| |PCE| 1037 +-+-+ +-+-+ 1038 | | 1039 |---PCRpt, Delegate=1--->| LSP Delegated 1040 | | 1041 |---PCRpt, Delegate=1--->| 1042 | . | 1043 | . | 1044 | . | 1045 |<--(PCUpd,Delegate=1)---| Delegation confirmed 1046 | | 1047 |---PCRpt, Delegate=1--->| 1048 | | 1050 Figure 9: Delegating an LSP 1052 Note that for an LSP to remain delegated to a PCE, the PCC MUST set 1053 the Delegate flag to 1 on each LSP Status Report sent to the PCE. 1055 5.5.2. Revoking a Delegation 1057 A PCC revokes an LSP delegation by sending an LSP State Report with 1058 the Delegate flag set to 0. A PCC MAY revoke an LSP delegation at 1059 any time during the PCEP session life time. When a PCC's PCEP 1060 session with the PCE terminates, the PCC SHALL wait a time interval 1061 specified in 'Delegation Timeout Interval' and then revoke all LSP 1062 delegations to the PCE . 1064 After an LSP delegation has been revoked, a PCE can no longer update 1065 LSP's parameters; an attempt to update parameters of a non-delegated 1066 LSP will result in the PCC sending a PCErr message indicating "LSP is 1067 not delegated" (see Section 8.4). 1069 The revocation sequence is shown in Figure 10. 1071 +-+-+ +-+-+ 1072 |PCC| |PCE| 1073 +-+-+ +-+-+ 1074 | | 1075 |---PCRpt, Delegate=1--->| 1076 | | 1077 |<--(PCUpd,Delegate=1)---| Delegation confirmed 1078 | . | 1079 | . | 1080 | . | 1081 |---PCRpt, Delegate=0--->| Delegation revoked 1082 | | 1084 Figure 10: Revoking a Delegation 1086 If a PCC can not delegate an LSP to a PCE (for example, if a PCC is 1087 not connected to any active stateful PCE or if no connected active 1088 stateful PCE accepts the delegation), the LSP delegation on the PCC 1089 will time out within a configurable Delegation Timeout Interval and 1090 the PCC SHALL flush any LSP state set by a PCE. 1092 5.5.3. Returning a Delegation 1094 A PCE that no longer wishes to update an LSP's parameters SHOULD 1095 return the LSP delegation back to the PCC by sending an empty LSP 1096 Update Request which has the Delegate flag set to 0. Note that in 1097 order to keep a delegation, the PCE MUST set the Delegate flag to 1 1098 on each LSP Update Request sent to the PCC. 1100 +-+-+ +-+-+ 1101 |PCC| |PCE| 1102 +-+-+ +-+-+ 1103 | | 1104 |---PCRpt, Delegate=1--->| LSP delegated 1105 | . | 1106 | . | 1107 | . | 1108 |<--PCUpd, Delegate=0----| Delegation returned 1109 | | 1110 |---PCRpt, Delegate=0--->| No delegation for LSP 1111 | | 1113 Figure 11: Returning a Delegation 1115 If a PCC can not delegate an LSP to a PCE (for example, if a PCC is 1116 not connected to any active stateful PCE or if no connected active 1117 stateful PCE accepts the delegation), the LSP delegation on the PCC 1118 will time out within a configurable Delegation Timeout Interval and 1119 the PCC MUST flush any LSP state set by a PCE. 1121 5.5.4. Redundant Stateful PCEs 1123 Note that a PCE may not have any delegated LSPs: in a redundant 1124 configuration where one PCE is backing up another PCE, the backup PCE 1125 will not have any delegated LSPs. The backup PCE does not update any 1126 LSPs, but it receives all LSP State Reports from a PCC. When the 1127 primary PCE fails, a PCC will delegate to the secondary PCE all LSPs 1128 that had been previously delegated to the failed PCE. 1130 5.6. LSP Operations 1132 5.6.1. Passive Stateful PCE Path Computation Request/Response 1134 +-+-+ +-+-+ 1135 |PCC| |PCE| 1136 +-+-+ +-+-+ 1137 | | 1138 1) Path computation |----- PCReq message --->| 1139 request sent to | |2) Path computation 1140 PCE | | request received, 1141 | | path computed 1142 | | 1143 |<---- PCRep message ----|3) Computed paths 1144 | (Positive reply) | sent to the PCC 1145 | (Negative reply) | 1146 4) LSP Status change| | 1147 event | | 1148 | | 1149 5) LSP Status Report|----- PCRpt message --->| 1150 sent to all | . | 1151 stateful PCEs | . | 1152 | . | 1153 6) Repeat for each |----- PCRpt message --->| 1154 LSP status change| | 1155 | | 1157 Figure 12: Passive Stateful PCE Path Computation Request/Response 1159 Once a PCC has successfully established a PCEP session with a passive 1160 stateful PCE and the PCC's LSP state is synchronized with the PCE 1161 (i.e. the PCE knows about all PCC's existing LSPs), if an event is 1162 triggered that requires the computation of a set of paths, the PCC 1163 sends a path computation request to the PCE ([RFC5440], Section 1164 4.2.3). The PCReq message MAY contain the LSP Object to identify the 1165 LSP for which the path computation is requested. 1167 Upon receiving a path computation request from a PCC, the PCE 1168 triggers a path computation and returns either a positive or a 1169 negative reply to the PCC ([RFC5440], Section 4.2.4). 1171 Upon receiving a positive path computation reply, the PCC receives a 1172 set of computed paths and starts to setup the LSPs. For each LSP, it 1173 sends an LSP State Report carried on a PCRpt message to the PCE, 1174 indicating that the LSP's status is 'Pending'. 1176 Once an LSP is up, the PCC sends an LSP State Report carried on a 1177 PCRpt message to the PCE, indicating that the LSP's status is 'Up'. 1178 If the LSP could not be set up, the PCC sends an LSP State Report 1179 indicating that the LSP is "Down' and stating the cause of the 1180 failure. Note that due to timing constraints, the LSP status may 1181 change from 'Pending' to 'Up' (or 'Down') before the PCC has had a 1182 chance to send an LSP State Report indicating that the status is 1183 'Pending'. In such cases, the PCC may choose to only send the PCRpt 1184 indicating the latest status ('Up' or 'Down'). 1186 Upon receiving a negative reply from a PCE, a PCC may decide to 1187 resend a modified request or take any other appropriate action. For 1188 each requested LSP, it also sends an LSP State Report carried on a 1189 PCRpt message to the PCE, indicating that the LSP's status is 'Down'. 1191 There is no direct correlation between PCRep and PCRpt messages. For 1192 a given LSP, multiple LSP State Reports will follow a single PC 1193 Reply, as a PCC notifies a PCE of the LSP's state changes. 1195 A PCC sends each LSP State Report to each stateful PCE that is 1196 connected to the PCC. 1198 Note that a single PCRpt message MAY contain multiple LSP State 1199 Reports. 1201 The passive stateful PCE is the model for stateful PCEs is described 1202 in [RFC4655], Section 6.8. 1204 5.6.2. Active Stateful PCE LSP Update 1206 +-+-+ +-+-+ 1207 |PCC| |PCE| 1208 +-+-+ +-+-+ 1209 | | 1210 1) LSP State |-- PCRpt, Delegate=1 -->| 1211 Synchronization | . | 1212 or add new LSP | . |2) PCE decides to 1213 | . | update the LSP 1214 | | 1215 |<---- PCUpd message ----|3) PCUpd message sent 1216 | | to PCC 1217 | | 1218 | | 1219 4) LSP Status Report|---- PCRpt message ---->| 1220 sent(->Pending) | . | 1221 | . | 1222 | . | 1223 5) LSP Status Report|---- PCRpt message ---->| 1224 sent (->Up|Down) | | 1225 | | 1227 Figure 13: Active Stateful PCE 1229 Once a PCC has successfully established a PCEP session with an active 1230 stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. 1231 the PCE knows about all PCC's existing LSPs) and LSPs have been 1232 delegated to the PCE, the PCE can modify LSP parameters of delegated 1233 LSPs. 1235 A PCE sends an LSP Update Request carried on a PCUpd message to the 1236 PCC. The LSP Update Request contains a variety of objects that 1237 specify the set of constraints and attributes for the LSP's path. 1238 Additionally, the PCC may specify the urgency of such request by 1239 assigning a request priority. A single PCUpd message MAY contain 1240 multiple LSP Update Requests. 1242 Upon receiving a PCUpd message the PCC starts to setup LSPs specified 1243 in LSP Update Requests carried in the message. For each LSP, it 1244 sends an LSP State Report carried on a PCRpt message to the PCE, 1245 indicating that the LSP's status is 'Pending'. 1247 Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) 1248 to the PCE, indicating that the LSP's status is 'Up'. If the LSP 1249 could not be set up, the PCC sends an LSP State Report indicating 1250 that the LSP is 'Down' and stating the cause of the failure. A PCC 1251 may choose to compress LSP State Updates to only reflect the most up 1252 to date state, as discussed in the previous section. 1254 A PCC sends each LSP State Report to each stateful PCE that is 1255 connected to the PCC. 1257 A PCC MUST NOT send to any PCE a Path Computation Request for a 1258 delegated LSP. 1260 5.7. LSP Protection 1262 With a stateless PCE or a passive stateful PCE, LSP protection and 1263 restoration settings may be operator-configured locally at a PCC. A 1264 PCE may be merely asked to compute the protected (primary) and backup 1265 (secondary) paths for the LSP. 1267 An active stateful PCE controls the LSPs that are delegated to it, 1268 and must therefore be able to set via PCEP the desired protection / 1269 restoration mechanism for each delegated LSP. PCEP extensions for 1270 stateful PCEs SHOULD support, at a minimum, the following protection 1271 mechanisms: 1273 o MPLS TE Global Default Restoration 1275 o MPLS TE Global Path Protection 1277 o FRR One-to-One Backup 1279 o FRR Facility Backup - link protection, node protection, or both 1281 5.8. Transport 1283 A Permanent PCEP session MUST be established between a stateful PCEs 1284 and the PCC. 1286 State cleanup after session termination, as well as session setup 1287 failures will be described in a later version of this document. 1289 6. PCEP Messages 1291 As defined in [RFC5440], a PCEP message consists of a common header 1292 followed by a variable-length body made of a set of objects that can 1293 be either mandatory or optional. An object is said to be mandatory 1294 in a PCEP message when the object must be included for the message to 1295 be considered valid. For each PCEP message type, a set of rules is 1296 defined that specify the set of objects that the message can carry. 1297 An implementation MUST form the PCEP messages using the object 1298 ordering specified in this document. 1300 6.1. The PCRpt Message 1302 A Path Computation LSP State Report message (also referred to as 1303 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 1304 current state of an LSP. A PCRpt message can carry more than one LSP 1305 State Reports. A PCC can send an LSP State Report either in response 1306 to an LSP Update Request from a PCE, or asynchronously when the state 1307 of an LSP changes. The Message-Type field of the PCEP common header 1308 for the PCRpt message is set to [TBD]. 1310 The format of the PCRpt message is as follows: 1312 ::= 1313 1314 Where: 1316 ::= [] 1318 ::= 1319 [] 1321 Where: 1323 ::=[] 1325 ::= 1327 Where: 1329 ::= [] 1330 [] 1331 [] 1332 [] 1334 ::= [] 1336 The LSP object (see Section 7.2) is mandatory, and it MUST be 1337 included in each LSP State Report on the PCRpt message. If the LSP 1338 object is missing, the receiving PCE MUST send a PCErr message with 1339 Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP 1340 object missing). 1342 The LSP State Report MAY contain a path descriptor for the primary 1343 path and one or more path descriptors for backup paths. A path 1344 descriptor MUST contain an ERO object as it was specified by a PCE or 1345 an operator. A path descriptor MUST contain the RRO object if a 1346 primary or secondary LSP is set up along the path in the network. A 1347 path descriptor MAY contain the LSPA, BANDWIDTH, and METRIC objects. 1349 The ERO,LSPA, BANDWIDTH, METRIC, and RRO objects are defined 1350 in[RFC5440]. 1352 6.2. The PCUpd Message 1354 A Path Computation LSP Update Request message (also referred to as 1355 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 1356 attributes of an LSP. A PCUpd message can carry more than one LSP 1357 Update Request. The Message-Type field of the PCEP common header for 1358 the PCRpt message is set to [TBD]. 1360 The format of a PCUpd message is as follows: 1362 ::= 1363 1364 Where: 1366 ::= [] 1368 ::= 1369 [] 1371 Where: 1373 ::=[] 1375 ::= 1377 Where: 1379 ::= [] 1380 [] 1381 [] 1382 [] 1384 ::= [] 1386 There is one mandatory object that MUST be included within each LSP 1387 Update Request in the PCUpd message: the LSP object (see 1388 Section 7.2). If the LSP object is missing, the receiving PCE MUST 1389 send a PCErr message with Error-type=6 (Mandatory Object missing) and 1390 Error-value=[TBD] (LSP object missing). 1392 The LSP Update Request MUST contain a path descriptor for the primary 1393 path, and MAY contain one or more path descriptors for backup paths. 1394 A path descriptor MUST contain an ERO object. A path descriptor MAY 1395 further contain the BANDWIDTH, IRO, and METRIC objects. The ERO, 1396 LSPA, BANDWIDTH, METRIC, and IRO objects are defined in [RFC5440]. 1398 Each LSP Update Request results in a separate LSP setup operation at 1399 a PCC. An LSP Update Request MUST contain all LSP parameters that a 1400 PCC wishes to set for the LSP. A PCC MAY set missing parameters from 1401 locally configured defaults. If the LSP specified the Update Request 1402 is already up, it will be re-signaled. The PCC will use make-before- 1403 break whenever possible in the re-signaling operation. 1405 A PCC MUST respond with an LSP State Report to each LSP Update 1406 Request to indicate the resulting state of the LSP in the network. A 1407 PCC MAY respond with multiple LSP State Reports to report LSP setup 1408 progress of a single LSP. 1410 If the rate of PCUpd messages sent to a PCC for the same target LSP 1411 exceeds the rate at which the PCC can signal LSPs into the network, 1412 the PCC MAY perform state compression and only re-signal the last 1413 modification in its queue. 1415 Note that a PCC MUST process all LSP Update Requests - for example, 1416 an LSP Update Request is sent when a PCE returns delegation or puts 1417 an LSP into non-operational state. The protocol relies on TCP for 1418 message-level flow control. 1420 Note also that it's up to the PCE to handle inter-LSP dependencies; 1421 for example, if ordering of LSP set-ups is required, the PCE has to 1422 wait for an LSP State Report for a previous LSP before triggering the 1423 LSP setup of a next LSP. 1425 7. Object Formats 1427 The PCEP objects defined in this document are compliant with the PCEP 1428 object format defined in [RFC5440]. The P flag and the I flag of the 1429 PCEP objects defined in this document MUST always be set to 0 on 1430 transmission and MUST be ignored on receipt since these flags are 1431 exclusively related to path computation requests. 1433 7.1. OPEN Object 1435 This document defines a new optional TLV for the OPEN Object to 1436 support stateful PCE capability negotiation. 1438 7.1.1. Stateful PCE Capability TLV 1440 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 1441 following figure: 1443 0 1 2 3 1444 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 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Type=[TBD] | Length=2 | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Flags |S|U| 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 Figure 14: STATEFUL-PCE-CAPABILITY TLV format 1453 The type of the TLV is [TBD] and it has a fixed length of 2 octets. 1455 The value comprises a single field - Flags (16 bits): 1457 U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag 1458 indicates that the PCC allows modification of LSP parameters; if 1459 set to 1 by a PCE, the U Flag indicates that the PCE wishes to 1460 update LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be 1461 advertised by both a PCC and a PCE for PCUpd messages to be 1462 allowed on a PCEP session. 1464 S (INCLUDE-DB-VERSION - 1 bit): if set to 1 by both PCEP Speakers, 1465 the PCC will include the LSP-DB-VERSION TLV in each LSP Object. 1467 Unassigned bits are considered reserved. They MUST be set to 0 on 1468 transmission and MUST be ignored on receipt. 1470 7.1.2. LSP State Database Version TLV 1472 LSP-DB-VERSION is an optional TLV that MAY be included in the OPEN 1473 Object when a PCEP Speaker wishes to determine if State 1474 Synchronization can be skipped when a PCEP session is restarted. If 1475 sent from a PCE, the TLV contains the local LSP State Database 1476 version from the last valid LSP State Report received from a PCC. If 1477 sent from a PCC, the TLV contains the PCC's local LSP State Database 1478 version, which is incremented each time the LSP State Database is 1479 updated. 1481 The format of the LSP-DB-VERSION TLV is shown in the following 1482 figure: 1484 0 1 2 3 1485 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 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Type=[TBD] | Length=8 | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | LSP State DB Version | 1490 | | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 Figure 15: LSP-DB-VERSION TLV format 1495 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 1496 The value contains a 64-bit unsigned integer. 1498 7.2. LSP Object 1500 The LSP object MUST be present within PCRpt and PCUpd messages. The 1501 LSP object MAY be carried within PCReq and PCRep messages if the 1502 stateful PCE capability has been negotiated on the session. The LSP 1503 object contains a set of fields used to specify the target LSP, the 1504 operation to be performed on the LSP, and LSP Delegation. It is also 1505 contains a flag to indicate to a PCE that the initial LSP state 1506 synchronization has been done. 1508 LSP Object-Class is [TBD]. 1510 LSP Object-Type is 1. 1512 The format of the LSP object body is shown in Figure 16: 1514 0 1 2 3 1515 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 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Session-internal LSP-ID | Flags |R|O|S|D| 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | | 1520 // Optional TLVs // 1521 | | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 Figure 16: The LSP Object format 1526 The LSP object body has a variable length and may contain additional 1527 TLVs. 1529 Session-internal LSP-ID (20 bits): Per-PCEP session identifier for an 1530 LSP. In each PCEP session the PCC creates a unique LSP-ID for each 1531 LSP that will remain constant for the duration of the session. The 1532 mapping of the LSP Symbolic Name to LSP-ID is communicated to the PCE 1533 by sending a PCRpt message containing the 'LSP Symbolic Name' TLV. 1534 All subsequent PCEP messages then address the LSP by its Session- 1535 internal LSP-ID. 1537 Flags (12 bits): 1539 D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1 1540 indicates that the PCC is delegating the LSP the PCE. On a PCUpd 1541 message, the D flag set to 1 indicates that the PCE is confirming 1542 the LSP Delegation. To keep an LSP delegated to the PCE, the PCC 1543 must set the D flag to 1 on each PCRpt message for the duration of 1544 the delegation - the first PCRpt with the D flag set to 0 revokes 1545 the delegation. To keep the delegation, the PCE must set the D 1546 flag to 1 on each PCUpd message for the duration of the delegation 1547 - the first PCUpd with the D flag set to 0 returns the delegation. 1549 S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSP State 1550 Report sent from a PCC during State Synchronization. The S Flag 1551 MUST be set to 0 otherwise. 1553 O (Operational - 1 bit): On PCRpt messages the O Flag indicates the 1554 LSP status. Value of '1' means that the LSP is operational, i.e. 1555 it is either being signaled or it is active. Value of '0' means 1556 that the LSP is not operational, i.e it is de-routed and the PCC 1557 is not attempting to set it up. On PCUpd messages the flag 1558 indicates the desired status for the LSP. Value of '1' means that 1559 the desired LSP state is operational, value of '0' means that the 1560 target LSP should be non-operational. Setting the LSP status from 1561 the PCE SHALL NOT override the operator: if a pce-controlled LSP 1562 has been configured to be non-operational, setting the LSP's 1563 status to '1' from an PCE will not make it operational. 1565 R (Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1566 LSP has been removed from the PCC. Upon receiving an LSP State 1567 Update with the R Flag set to 1, the PCE SHOULD remove all state 1568 related to the LSP from its database. 1570 Unassigned bits are considered reserved. They MUST be set to 0 on 1571 transmission and MUST be ignored on receipt. 1573 TLVs that are currently defined for the LSP Object are described in 1574 the following sections. 1576 7.2.1. The LSP Symbolic Name TLV 1578 Each LSP MUST have a symbolic name that is unique in the PCC. The 1579 LSP Symbolic Name MUST remain constant throughout an LSP's lifetime, 1580 which may span across multiple consecutive PCEP sessions and/or PCC 1581 restarts. The LSP Symbolic Name MAY be specified by an operator in a 1582 PCC's CLI configuration. If the operator does not specify a Symbolic 1583 Name for an LSP, the PCC MUST auto-generate one. 1585 The LSP-SYMBOLIC-NAME TLV MUST be included in the LSP State Report 1586 when during a given PCEP session an LSP is first reported to a PCE. 1587 A PCC sends to a PCE the first LSP State Report either during State 1588 Synchronization, or when a new LSP is configured at the PCC. LSP 1589 State Report MAY be included in subsequent LSP State Reports for the 1590 LSP. 1592 The format of the LSP-SYMBOLIC-NAME TLV is shown in the following 1593 figure: 1595 0 1 2 3 1596 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Type=[TBD] | Length (variable) | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | | 1601 // Symbolic LSP Name // 1602 | | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 Figure 17: LSP-SYMBOLIC-NAME TLV format 1607 The type of the TLV is [TBD] and it has a variable length, which MUST 1608 be greater than 0. 1610 7.2.2. LSP Identifiers TLVs 1612 Whenever the value of an LSP identifier changes, a PCC MUST send out 1613 an LSP State Report, where the LSP Object carries the LSP Identifiers 1614 TLV that contains the new value. The LSP Identifiers TLV MUST also 1615 be included in the LSP object during state synchronization. There 1616 are two LSP Identifiers TLVs, one for IPv4 and one for IPv6. 1618 The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 1619 figure: 1621 0 1 2 3 1622 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 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | Type=[TBD] | Length=12 | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | IPv4 Tunnel Sender Address | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | LSP ID | Tunnel ID | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Extended Tunnel ID | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 Figure 18: IPV4-LSP-IDENTIFIERS TLV format 1635 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 1636 The value contains two fields: 1638 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 1639 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 1640 Sender Template Object. 1642 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1643 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 1644 Object. 1646 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1647 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 1648 Tunnel ID remains constant over the life time of a tunnel. 1649 However, when Global Path Protection or Global Default Restoration 1650 is used, both the primary and secondary LSPs have their own Tunnel 1651 IDs. A PCC will report a change in Tunnel ID when traffic 1652 switches over from primary LSP to secondary LSP (or vice versa). 1654 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 1655 identifier defined in [RFC3209], Section 4.6.1.1 for the 1656 LSP_TUNNEL_IPv4 Session Object. 1658 The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following 1659 figure: 1661 0 1 2 3 1662 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 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | Type=[TBD] | Length=36 | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 | | 1667 + + 1668 | IPv6 tunnel sender address | 1669 + (16 octets) + 1670 | | 1671 + + 1672 | | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | LSP ID | Tunnel ID | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | | 1677 + + 1678 | Extended Tunnel ID | 1679 + (16 octets) + 1680 | | 1681 + + 1682 | | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 Figure 19: IPV6-LSP-IDENTIFIERS TLV format 1687 The type of the TLV is [TBD] and it has a fixed length of 20 octets. 1688 The value contains two fields: 1690 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 1691 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 1692 Sender Template Object. 1694 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1695 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 1696 Object. 1698 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1699 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 1700 Tunnel ID remains constant over the life time of a tunnel. 1701 However, when Global Path Protection or Global Default Restoration 1702 is used, both the primary and secondary LSPs have their own Tunnel 1703 IDs. A PCC will report a change in Tunnel ID when traffic 1704 switches over from primary LSP to secondary LSP (or vice versa). 1706 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 1707 identifier defined in [RFC3209], Section 4.6.1.2 for the 1708 LSP_TUNNEL_IPv6 Session Object. 1710 7.2.3. LSP Update Error Code TLV 1712 If an LSP Update Request failed, an LSP State Report MUST be sent to 1713 all connected stateful PCEs. LSP State Report MUST contain the LSP 1714 Update Error Code TLV, indicating the cause of the failure. 1716 The format of the LSP-UPDATE-ERROR-CODE TLV is shown in the following 1717 figure: 1719 0 1 2 3 1720 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 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | Type=[TBD] | Length=4 | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | Error Code | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 Figure 20: LSP-UPDATE-ERROR-CODE TLV format 1729 The type of the TLV is [TBD] and it has a fixed length of 4 octets. 1730 The value contains the error code that indicates the cause of the LSP 1731 setup failure. Error codes will be defined in a later revision of 1732 this document. 1734 7.2.4. RSVP ERROR_SPEC TLVs 1736 If the set up of an LSP failed at a downstream node which returned an 1737 ERROR_SPEC to the PCC, the ERROR_SPEC MUST be included in the LSP 1738 State Report. Depending on whether RSVP signaling was performed over 1739 IPv4 or IPv6, the LSP Object will contain an IPV4-ERROR_SPEC TLV or 1740 an IPV6-ERROR_SPEC TLV. 1742 The format of the IPV4-RSVP-ERROR-SPEC TLV is shown in the following 1743 figure: 1745 0 1 2 3 1746 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 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | Type=[TBD] | Length=8 | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1750 | | 1751 + IPv4 ERROR_SPEC object (rfc2205) + 1752 | | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 Figure 21: IPV4-RSVP-ERROR-SPEC TLV format 1757 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 1758 The value contains the RSVP IPv4 ERROR_SPEC object defined in 1759 [RFC2205]. Error codes allowed in the ERROR_SPEC object are defined 1760 in [RFC2205] and [RFC3209]. 1762 The format of the IPV6-RSVP-ERROR-SPEC TLV is shown in the following 1763 figure: 1765 0 1 2 3 1766 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 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | Type=[TBD] | Length=20 | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | | 1771 // IPv6 ERROR_SPEC object (rfc2205) // 1772 | | 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 Figure 22: IPV6-RSVP-ERROR-SPEC TLV format 1777 The type of the TLV is [TBD] and it has a fixed length of 20 octets. 1778 The value contains the RSVP IPv6 ERROR_SPEC object defined in 1779 [RFC2205]. Error codes allowed in the ERROR_SPEC object are defined 1780 in [RFC2205] and [RFC3209]. 1782 7.2.5. LSP State Database Version TLV 1784 The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP 1785 object. The LSP-DB-VERSION TLV is discussed in Section 5.4.1 which 1786 covers state synchronization avoidance. The format of the TLV is 1787 described in Section 7.1.2, where the details of its use in the OPEN 1788 message are listed. 1790 If State Synchronization Avoidance has been enabled on a PCEP session 1791 (as described in Section 5.4.1) , a PCC MUST include the LSP-DB- 1792 VERSION TLV in each LSP Object sent out on the session. If the TLV 1793 is missing, the PCE will generate an error with error-type 6 1794 (mandatory object missing) and Error Value 12 (LSP-DB-VERSION TLV 1795 missing) and close the session. If State Synchronization Avoidance 1796 has not been enabled on a PCEP session, the PCC SHOULD NOT include 1797 the LSP-DB-VERSION TLV in the LSP Object and the PCE SHOULD ignore it 1798 were it to receive one. 1800 Since a PCE does not send LSP updates to a PCC, a PCC should never 1801 encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were 1802 it to receive one from a PCE. 1804 7.2.6. Delegation Parameters TLVs 1806 Multiple delegation parameters, such as sub-delegation permissions, 1807 authentication parameters, etc. need to be communicated from a PCC to 1808 a PCE during the delegation operation. Delegation parameters will be 1809 carried in multiple delegation parameter TLVs, which will be defined 1810 in future revisions of this document. 1812 8. IANA Considerations 1814 This document requests IANA actions to allocate code points for the 1815 protocol elements defined in this document. Values shown here are 1816 suggested for use by IANA. 1818 8.1. PCEP Messages 1820 This document defines the following new PCEP messages: 1822 Value Meaning Reference 1823 10 Report This document 1824 11 Update This document 1826 8.2. PCEP Objects 1828 This document defines the following new PCEP Object-classes and 1829 Object-values: 1831 Object-Class Value Name Reference 1833 32 LSP This document 1834 Object-Type 1835 1 1837 8.3. LSP Object 1839 This document requests that a registry is created to manage the Flags 1840 field of the LSP object. New values are to be assigned by Standards 1841 Action [RFC5226]. Each bit should be tracked with the following 1842 qualities: 1844 o Bit number (counting from bit 0 as the most significant bit) 1846 o Capability description 1848 o Defining RFC 1850 The following values are defined in this document: 1852 Bit Description Reference 1854 28 Remove This document 1855 29 Operational This document 1856 30 SYNC This document 1857 31 Delegate This document 1859 8.4. PCEP-Error Object 1861 This document defines new Error-Type and Error-Value for the 1862 following new error conditions: 1864 Error-Type Meaning 1865 6 Mandatory Object missing 1866 Error-value=8: LSP Object missing 1867 Error-value=9: ERO Object missing for a path in an LSP 1868 Update Request where TE-LSP setup is 1869 requested 1870 Error-value=10: BANDWIDTH Object missing for a path in 1871 an LSP Update Request where TE-LSP 1872 setup is requested 1873 Error-value=11: LSPA Object missing for a path in an 1874 LSP Update Request where TE-LSP setup 1875 is requested 1876 Error-value=12: LSP-DB-VERSION TLV missing 1877 19 Invalid Operation 1878 Error-value=1: Attempted LSP Update Request for a non- 1879 delegated LSP. The PCEP-ERROR Object 1880 is followed by the LSP Object that 1881 identifies the LSP. 1883 Error-value=2: Attempted LSP Update Request if active 1884 stateful PCE capability was not 1885 negotiated active PCE. 1886 20 LSP State synchronization error. 1887 Error-value=1: A PCE indicates to a PCC that it can 1888 not process (an otherwise valid) LSP 1889 State Report. The PCEP-ERROR Object is 1890 followed by the LSP Object that 1891 identifies the LSP. 1892 Error-value=2: LSP Database version mismatch. 1893 Error-value=3: The LSP-DB-VERSION TLV Missing when 1894 State Synchronization Avoidance 1895 enabled. 1897 8.5. PCEP TLV Type Indicators 1899 This document defines the following new PCEP TLVs: 1901 Value Meaning Reference 1902 16 STATEFUL-PCE-CAPABILITY This document 1903 17 LSP-SYMBOLIC-NAME This document 1904 18 IPV4-LSP-IDENTIFIERS This document 1905 19 IPV6-LSP-IDENTIFIERS This document 1906 20 LSP-UPDATE-ERROR-CODE This document 1907 21 IPV4-RSVP-ERROR-SPEC This document 1908 22 IPV6-RSVP-ERROR-SPEC This document 1909 23 LSP-DB-VERSION This document 1911 8.6. STATEFUL-PCE-CAPABILITY TLV 1913 This document requests that a registry is created to manage the Flags 1914 field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New 1915 values are to be assigned by Standards Action [RFC5226]. Each bit 1916 should be tracked with the following qualities: 1918 o Bit number (counting from bit 0 as the most significant bit) 1920 o Capability description 1922 o Defining RFC 1924 The following values are defined in this document: 1926 Bit Description Reference 1928 30 INCLUDE-DB-VERSION This document 1929 31 LSP-UPDATE-CAPABILITY This document 1931 8.7. LSP-UPDATE-ERROR-CODE TLV 1933 This document requests that a registry is created to manage the Error 1934 Codes in the LSP-UPDATE-ERROR-CODE TLV. New values are to be 1935 assigned by Standards Action [RFC5226]. 1937 The following Error Codes are defined in this document: 1939 Value Meaning Reference 1941 1 LSP Setup failed outside of the node. Must This document 1942 be followed by the RSVP-ERROR-SPEC TLV, 1943 which indicates the failure cause. 1945 2 LSP not operational This document 1947 9. Manageability Considerations 1949 All manageability requirements and considerations listed in [RFC5440] 1950 apply to PCEP protocol extensions defined in this document. In 1951 addition, requirements and considerations listed in this section 1952 apply. 1954 9.1. Control Function and Policy 1956 In addition to configuring specific PCEP session parameters, as 1957 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 1958 allow configuring the stateful PCEP capability and the LSP Update 1959 capability. A PCC implementation SHOULD allow the operator to 1960 specify multiple candidate PCEs for and a delegation preference for 1961 each candidate PCE. A PCC SHOULD allow the operator to specify an 1962 LSP delegation policy where LSPs are delegated to the most-preferred 1963 online PCE. A PCC MAY allow the operator to specify different LSP 1964 delegation policies. 1966 A PCC implementation which allows concurrent connections to multiple 1967 PCEs SHOULD allow the operator to group the PCEs by administrative 1968 domains and it MUST NOT advertise LSP existence and state to a PCE if 1969 the LSP is delegated to a PCE in a different group. 1971 A PCC implementation SHOULD allow the operator to specify whether the 1972 PCC will advertise LSP existence and state for LSPs that are not 1973 controlled by any PCE (for example, LSPs that are statically 1974 configured at the PCC). 1976 A PCC implementation SHOULD allow the operator to specify the 1977 Delegation Timeout Interval. The default value of the Delegation 1978 Timeout Interval SHOULD be set to 30 seconds. 1980 When an LSP can no longer be delegated to a PCE, after the expiration 1981 of the Delegation Timeout Interval, the LSP MAY either: 1) retain its 1982 current parameters or 2) revert to operator-defined default LSP 1983 parameters. This behavior SHOULD be configurable and in the case 1984 when (2) is supported, a PCC implementation MUST allow the operator 1985 to specify the default LSP parameters. 1987 A PCC implementation SHOULD allow the operator to specify delegation 1988 priority for PCEs. This effectively defines the primary PCE and one 1989 or more backup PCEs to which primary PCE's LSPs can be delegated when 1990 the primary PCE fails. 1992 Policies defined for stateful PCEs and PCCs should eventually fit in 1993 the Policy-Enabled Path Computation Framework defined in [RFC5394], 1994 and the framework should be extended to support Stateful PCEs. 1996 9.2. Information and Data Models 1998 PCEP session configuration and information in the PCEP MIB module 1999 SHOULD be extended to include negotiated stateful capabilities, 2000 synchronization status, and delegation status (at the PCC list PCEs 2001 with delegated LSPs). 2003 9.3. Liveness Detection and Monitoring 2005 PCEP protocol extensions defined in this document do not require any 2006 new mechanisms beyond those already defined in [RFC5440], Section 2007 8.3. 2009 9.4. Verifying Correct Operation 2011 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 2012 protocol extensions defined in this document. In addition to 2013 monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP 2014 implementation SHOULD provide the following parameters: 2016 o Total number of LSP updates 2018 o Number of successful LSP updates 2019 o Number of dropped LSP updates 2021 o Number of LSP updates where LSP setup failed 2023 A PCC implementation SHOULD provide a command to show to which PCEs 2024 LSPs are delegated. 2026 A PCC implementation SHOULD allow the operator to manually revoke LSP 2027 delegation. 2029 9.5. Requirements on Other Protocols and Functional Components 2031 PCEP protocol extensions defined in this document do not put new 2032 requirements on other protocols. 2034 9.6. Impact on Network Operation 2036 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 2037 protocol extensions defined in this document. 2039 Additionally, a PCEP implementation SHOULD allow a limit to be placed 2040 on the rate PCUpd and PCRpt messages sent by a PCEP speaker and 2041 processed from a peer. It SHOULD also allow sending a notification 2042 when a rate threshold is reached. 2044 A PCC implementation SHOULD allow a limit to be placed on the rate of 2045 LSP Updates to the same LSP to avoid signaling overload discussed in 2046 Section 10.3. 2048 10. Security Considerations 2050 10.1. Vulnerability 2052 This document defines extensions to PCEP to enable stateful PCEs. 2053 The nature of these extensions and the delegation of path control to 2054 PCEs results in more information being available for a hypothetical 2055 adversary and a number of additional attack surfaces which must be 2056 protected. 2058 The security provisions described in [RFC5440] remain applicable to 2059 these extensions. However, because the protocol modifications 2060 outlined in this document allow the PCE to control path computation 2061 timing and sequence, the PCE defense mechanisms described in 2062 [RFC5440] section 7.2 are also now applicable to PCC security. 2064 As a general precaution, it is RECOMMENDED that these PCEP extensions 2065 only be activated on authenticated and encrypted sessions across PCEs 2066 and PCCs belonging to the same administrative authority. 2068 The following sections identify specific security concerns that may 2069 result from the PCEP extensions outlined in this document along with 2070 recommended mechanisms to protect PCEP infrastructure against related 2071 attacks. 2073 10.2. LSP State Snooping 2075 The stateful nature of this extension explicitly requires LSP status 2076 updates to be sent from PCC to PCE. While this gives the PCE the 2077 ability to provide more optimal computations to the PCC, it also 2078 provides an adversary with the opportunity to eavesdrop on decisions 2079 made by network systems external to PCE. This is especially true if 2080 the PCC delegates LSPs to multiple PCEs simultaneously. 2082 Adversaries may gain access to this information by eavesdropping on 2083 unsecured PCEP sessions, and might then use this information in 2084 various ways to target or optimize attacks on network infrastructure. 2085 For example by flexibly countering anti-DDoS measures being taken to 2086 protect the network, or by determining choke points in the network 2087 where the greatest harm might be caused. 2089 PCC implementations which allow concurrent connections to multiple 2090 PCEs SHOULD allow the operator to group the PCEs by administrative 2091 domains and they MUST NOT advertise LSP existence and state to a PCE 2092 if the LSP is delegated to a PCE in a different group. 2094 10.3. Malicious PCE 2096 The LSP delegation mechanism described in this document allows a PCC 2097 to grant effective control of an LSP to the PCE for the duration of a 2098 PCEP session. While this enables PCE control of the timing and 2099 sequence of path computations within and across PCEP sessions, it 2100 also introduces a new attack vector: an attacker may flood the PCC 2101 with PCUpd messages at a rate which exceeds either the PCC's ability 2102 to process them or the network's ability to signal the changes, 2103 either by spoofing messages or by compromising the PCE itself. 2105 A PCC is free to revoke an LSP delegation at any time without needing 2106 any justification. A defending PCC can do this by enqueueing the 2107 appropriate PCRpt message. As soon as that message is enqueued in 2108 the session, the PCC is free to drop any incoming PCUpd messages 2109 without additional processing. 2111 10.4. Malicious PCC 2113 A stateful session also result in increased attack surface by placing 2114 a requirement for the PCE to keep an LSP state replica for each PCC. 2115 It is RECOMMENDED that PCE implementations provide a limit on 2116 resources a single PCC can occupy. 2118 Delegation of LSPs can create further strain on PCE resources and a 2119 PCE implementation MAY preemptively give back delegations if it finds 2120 itself lacking the resources needed to effectively manage the 2121 delegation. Since the delegation state is ultimately controlled by 2122 the PCC, PCE implementations SHOULD provide throttling mechanisms to 2123 prevent strain created by flaps of either a PCEP session or an LSP 2124 delegation. 2126 11. Acknowledgements 2128 We would like to thank Adrian Farrel and Cyril Margaria for their 2129 contributions to this document. 2131 We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, 2132 Paul Schultz and Raveendra Torvi for their comments and suggestions. 2133 Thanks also to Dhruv Dhoddy, Oscar Gonzales de Dios, Tomas Janciga, 2134 Stefan Kobza and Kexin Tang for helpful discussions. 2136 12. References 2138 12.1. Normative References 2140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2141 Requirement Levels", BCP 14, RFC 2119, March 1997. 2143 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2144 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2145 Functional Specification", RFC 2205, September 1997. 2147 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2148 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2149 Tunnels", RFC 3209, December 2001. 2151 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 2152 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 2153 May 2005. 2155 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 2156 "OSPF Protocol Extensions for Path Computation Element 2157 (PCE) Discovery", RFC 5088, January 2008. 2159 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 2160 "IS-IS Protocol Extensions for Path Computation Element 2161 (PCE) Discovery", RFC 5089, January 2008. 2163 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2164 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2165 May 2008. 2167 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 2168 (PCE) Communication Protocol (PCEP)", RFC 5440, 2169 March 2009. 2171 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2172 Used to Form Encoding Rules in Various Routing Protocol 2173 Specifications", RFC 5511, April 2009. 2175 12.2. Informative References 2177 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2178 LSP Path Computation using Preemption", Global 2179 Information Infrastructure Symposium, July 2007. 2181 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2182 programming algorithm for balancing the max-min fairness 2183 and throughput objectives in traffic engineering", pre- 2184 print, 2011. 2186 [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network 2187 Recovery: Protection and Restoration of Optical, SONET- 2188 SDH, IP, and MPLS", The Morgan Kaufmann Series in 2189 Networking, June 2004. 2191 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2192 McManus, "Requirements for Traffic Engineering Over MPLS", 2193 RFC 2702, September 1999. 2195 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2196 Label Switching Architecture", RFC 3031, January 2001. 2198 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2199 Christian, B., and W. Lai, "Applicability Statement for 2200 Traffic Engineering with MPLS", RFC 3346, August 2002. 2202 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2203 (TE) Extensions to OSPF Version 2", RFC 3630, 2204 September 2003. 2206 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2207 Element (PCE)-Based Architecture", RFC 4655, August 2006. 2209 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 2210 Communication Protocol Generic Requirements", RFC 4657, 2211 September 2006. 2213 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2214 Engineering", RFC 5305, October 2008. 2216 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2217 "Policy-Enabled Path Computation Framework", RFC 5394, 2218 December 2008. 2220 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 2221 Computation Element Communication Protocol (PCEP) 2222 Requirements and Protocol Extensions in Support of Global 2223 Concurrent Optimization", RFC 5557, July 2009. 2225 Authors' Addresses 2227 Edward Crabbe 2228 Google, Inc. 2229 1600 Amphitheatre Parkway 2230 Mountain View, CA 94043 2231 US 2233 Email: edc@google.com 2235 Jan Medved 2236 Cisco Systems, Inc. 2237 170 West Tasman Dr. 2238 San Jose, CA 95134 2239 US 2241 Email: jmedved@cisco.com 2243 Robert Varga 2244 Pantheon Technologies LLC 2245 Mlynske Nivy 56 2246 Bratislava 821 05 2247 Slovakia 2249 Email: robert.varga@pantheon.sk 2250 Ina Minei 2251 Juniper Networks, Inc. 2252 1194 N. Mathilda Ave. 2253 Sunnyvale, CA 94089 2254 US 2256 Email: ina@juniper.net