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