idnits 2.17.1 draft-ietf-pce-stateful-pce-09.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 are 3 instances of too long lines in the document, the longest one being 4 characters 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 (June 22, 2014) is 3568 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 1690, but not defined == Unused Reference: 'RFC3473' is defined on line 2055, but no explicit reference was found in the text == Unused Reference: 'NET-REC' is defined on line 2110, but no explicit reference was found in the text == Unused Reference: 'RFC5557' is defined on line 2144, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-pce-gmpls-pcep-extensions-09 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-08) exists of draft-ietf-pce-stateful-pce-app-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group E. Crabbe 3 Internet-Draft I. Minei 4 Intended status: Standards Track Google, Inc. 5 Expires: December 24, 2014 J. Medved 6 Cisco Systems, Inc. 7 R. Varga 8 Pantheon Technologies SRO 9 June 22, 2014 11 PCEP Extensions for Stateful PCE 12 draft-ietf-pce-stateful-pce-09 14 Abstract 16 The Path Computation Element Communication Protocol (PCEP) provides 17 mechanisms for Path Computation Elements (PCEs) to perform path 18 computations in response to Path Computation Clients (PCCs) requests. 20 Although PCEP explicitly makes no assumptions regarding the 21 information available to the PCE, it also makes no provisions for PCE 22 control of timing and sequence of path computations within and across 23 PCEP sessions. This document describes a set of extensions to PCEP 24 to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 24, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Motivation and Objectives for Stateful PCE . . . . . . . . . 5 69 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 5 71 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6 72 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7 73 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 8 74 4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8 75 5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 9 76 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 77 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 9 78 5.3. Capability Advertisement . . . . . . . . . . . . . . . . 10 79 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11 80 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 14 81 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 82 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 15 83 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . 17 84 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 17 85 5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 18 86 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 18 87 5.6.1. Passive Stateful PCE Path Computation 88 Request/Response . . . . . . . . . . . . . . . . . . 18 89 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . 20 90 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . 22 91 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 22 92 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22 93 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 22 94 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24 95 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 26 96 6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 26 97 6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 27 98 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 28 99 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 28 100 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 28 101 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 29 102 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 30 103 7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . 32 104 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 35 105 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 36 106 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 36 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 108 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 37 109 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 37 110 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 38 111 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 38 112 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 39 113 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 39 114 8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 40 115 9. Manageability Considerations . . . . . . . . . . . . . . . . 40 116 9.1. Control Function and Policy . . . . . . . . . . . . . . . 40 117 9.2. Information and Data Models . . . . . . . . . . . . . . . 41 118 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 41 119 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 42 120 9.5. Requirements on Other Protocols and Functional Components 42 121 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 42 122 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 123 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 42 124 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 43 125 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 43 126 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 44 127 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 128 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 129 12.1. Normative References . . . . . . . . . . . . . . . . . . 44 130 12.2. Informative References . . . . . . . . . . . . . . . . . 45 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 133 1. Introduction 135 [RFC5440] describes the Path Computation Element Protocol (PCEP). 136 PCEP defines the communication between a Path Computation Client 137 (PCC) and a Path Computation Element (PCE), or between PCEs, enabling 138 computation of Multiprotocol Label Switching (MPLS) for Traffic 139 Engineering Label Switched Path (TE LSP) characteristics. Extensions 140 for support of Generalized MPLS (GMPLS) in PCEP are defined in 141 [I-D.ietf-pce-gmpls-pcep-extensions] 143 This document specifies a set of extensions to PCEP to enable 144 stateful control of LSPs within and across PCEP sessions in 145 compliance with [RFC4657]. It includes mechanisms to effect LSP 146 state synchronization between PCCs and PCEs, delegation of control 147 over LSPs to PCEs, and PCE control of timing and sequence of path 148 computations within and across PCEP sessions. 150 2. Terminology 152 This document uses the following terms defined in [RFC5440]: PCC, 153 PCE, PCEP Peer, PCEP Speaker. 155 This document uses the following terms defined in [RFC4655]: TED. 157 The following terms are defined in this document: 159 Stateful PCE: has access to not only the network state, but also to 160 the set of active paths and their reserved resources for its 161 computations. A stateful PCE might also retain information 162 regarding LSPs under construction in order to reduce churn and 163 resource contention. The additional state allows the PCE to 164 compute constrained paths while considering individual LSPs and 165 their interactions. Note that this requires reliable state 166 synchronization mechanisms between the PCE and the network, PCE 167 and PCC, and between cooperating PCEs. 169 Passive Stateful PCE: uses LSP state information learned from PCCs 170 to optimize path computations. It does not actively update LSP 171 state. A PCC maintains synchronization with the PCE. 173 Active Stateful PCE: is an extension of Passive Stateful PCE, in 174 which the PCE may issue recommendations to the network. For 175 example, an active stateful PCE may utilize the Delegation 176 mechanism to update LSP parameters in those PCCs that delegated 177 control over their LSPs to the PCE. 179 Delegation: An operation to grant a PCE temporary rights to modify a 180 subset of LSP parameters on one or more PCC's LSPs. LSPs are 181 delegated from a PCC to a PCE, and are referred to as delegated 182 LSPs. The PCC who owns the PCE state for the LSP has the right to 183 delegate it. An LSP is owned by a single PCC at any given point 184 in time. For intra-domain LSPs, this PCC SHOULD be the LSP head 185 end. 187 Revocation: An operation performed by a PCC on a previously 188 delegated LSP. Revocation revokes the rights granted to the PCE 189 in the delegation operation. 191 Redelegation Timeout Interval: when a PCEP session is terminated, a 192 PCC waits for this time period before revoking LSP delegation to a 193 PCE and attempting to redelegate LSPs associated with the 194 terminated PCEP session to an alternate PCE. The Redelegation 195 Timeout Interval is a PCC-local value that can be either operator- 196 configured or dynamically computed by the PCC based on local 197 policy. 199 State Timeout Interval: when a PCEP session is terminated, a PCC 200 waits for this time period before flushing LSP state associated 201 with that PCEP session and reverting to operator-defined default 202 parameters or behaviors. The State Timeout Interval is a PCC- 203 local value that can be either operator-configured or dynamically 204 computed by the PCC based on local policy. 206 LSP State Report: an operation to send LSP state (Operational / 207 Admin Status, LSP attributes configured at the PCC and set by a 208 PCE, etc.) from a PCC to a PCE. 210 LSP Update Request: an operation where an Active Stateful PCE 211 requests a PCC to update one or more attributes of an LSP and to 212 re-signal the LSP with updated attributes. 214 LSP State Database: information about all LSPs and their attributes. 216 Within this document, PCE-PCE communications are described by having 217 the requesting PCE fill the role of a PCC. This provides a saving in 218 documentation without loss of function. 220 The message formats in this document are specified using Routing 221 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 223 3. Motivation and Objectives for Stateful PCE 225 3.1. Motivation 227 [I-D.ietf-pce-stateful-pce-app] presents several use cases, 228 demonstrating scenarios that benefit from the deployment of a 229 stateful PCE. The scenarios apply equally to MPLS-TE and GMPLS 230 deployments. 232 3.1.1. Background 234 Traffic engineering has been a goal of the MPLS architecture since 235 its inception ([RFC3031], [RFC2702], [RFC3346]). In the traffic 236 engineering system provided by [RFC3630], [RFC5305], and [RFC3209] 237 information about network resources utilization is only available as 238 total reserved capacity by traffic class on a per interface basis; 239 individual LSP state is available only locally on each LER for its 240 own LSPs. In most cases, this makes good sense, as distribution and 241 retention of total LSP state for all LERs within in the network would 242 be prohibitively costly. 244 Unfortunately, this visibility in terms of global LSP state may 245 result in a number of issues for some demand patterns, particularly 246 within a common setup and hold priority. This issue affects online 247 traffic engineering systems. 249 A sufficiently over-provisioned system will by definition have no 250 issues routing its demand on the shortest path. However, lowering 251 the degree to which network over-provisioning is required in order to 252 run a healthy, functioning network is a clear and explicit promise of 253 MPLS architecture. In particular, it has been a goal of MPLS to 254 provide mechanisms to alleviate congestion scenarios in which 255 "traffic streams are inefficiently mapped onto available resources; 256 causing subsets of network resources to become over-utilized while 257 others remain underutilized" ([RFC2702]). 259 3.1.2. Why a Stateful PCE? 261 [RFC4655] defines a stateful PCE to be one in which the PCE maintains 262 "strict synchronization between the PCE and not only the network 263 states (in term of topology and resource information), but also the 264 set of computed paths and reserved resources in use in the network." 265 [RFC4655] also expressed a number of concerns with regard to a 266 stateful PCE, specifically: 268 o Any reliable synchronization mechanism would result in significant 269 control plane overhead 271 o Out-of-band TED synchronization would be complex and prone to race 272 conditions 274 o Path calculations incorporating total network state would be 275 highly complex 277 In general, stress on the control plane will be directly proportional 278 to the size of the system being controlled and the tightness of the 279 control loop, and indirectly proportional to the amount of over- 280 provisioning in terms of both network capacity and reservation 281 overhead. 283 Despite these concerns in terms of implementation complexity and 284 scalability, several TE algorithms exist today that have been 285 demonstrated to be extremely effective in large TE systems, providing 286 both rapid convergence and significant benefits in terms of 287 optimality of resource usage [MXMN-TE]. All of these systems share 288 at least two common characteristics: the requirement for both global 289 visibility of a flow (or in this case, a TE LSP) state and for 290 ordered control of path reservations across devices within the system 291 being controlled. While some approaches have been suggested in order 292 to remove the requirements for ordered control (See [MPLS-PC]), these 293 approaches are highly dependent on traffic distribution, and do not 294 allow for multiple simultaneous LSP priorities representing diffserv 295 classes. 297 The use cases described in [I-D.ietf-pce-stateful-pce-app] 298 demonstrate a need for visibility into global inter-PCC LSP state in 299 PCE path computations, and for PCE control of sequence and timing in 300 altering LSP path characteristics within and across PCEP sessions. 302 3.1.3. Protocol vs. Configuration 304 Note that existing configuration tools and protocols can be used to 305 set LSP state. However, this solution has several shortcomings: 307 o Scale & Performance: configuration operations often require 308 processing of additional configuration portions beyond the state 309 being directly acted upon, with corresponding cost in CPU cycles, 310 negatively impacting both PCC stability LSP update rate capacity. 312 o Scale & Performance: configuration operations often have 313 transactional semantics which are typically heavyweight and 314 require additional CPU cycles, negatively impacting PCC update 315 rate capacity. 317 o Security: when a PCC opens a configuration channel allowing a PCE 318 to send configuration, a malicious PCE may take advantage of this 319 ability to take over the PCC. In contrast, the PCEP extensions 320 described in this document only allow a PCE control over a very 321 limited set of LSP attributes. 323 o Interoperability: each vendor has a proprietary information model 324 for configuring LSP state, which prevents interoperability of a 325 PCE with PCCs from different vendors. The PCEP extensions 326 described in this document allow for a common information model 327 for LSP state for all vendors. 329 o Efficient State Synchronization: configuration channels may be 330 heavyweight and unidirectional, therefore efficient state 331 synchronization between a PCC and a PCE may be a problem. 333 3.2. Objectives 335 The objectives for the protocol extensions to support stateful PCE 336 described in this document are as follows: 338 o Allow a single PCC to interact with a mix of stateless and 339 stateful PCEs simultaneously using the same PCEP. 341 o Support efficient LSP state synchronization between the PCC and 342 one or more active or passive stateful PCEs. 344 o Allow a PCC to delegate control of its LSPs to an active stateful 345 PCE such that a single LSP is under the control a single PCE at 346 any given time. A PCC may revoke this delegation at any time 347 during the lifetime of the LSP. If LSP delegation is revoked 348 while the PCEP session is up, the PCC MUST notify the PCE about 349 the revocation. A PCE may return an LSP delegation at any point 350 during the lifetime of the PCEP session. 352 o Allow a PCE to control computation timing and update timing across 353 all LSPs that have been delegated to it. 355 o Enable uninterrupted operation of PCC's LSPs in the event of a PCE 356 failure or while control of LSPs is being transferred between 357 PCEs. 359 4. New Functions to Support Stateful PCEs 361 Several new functions are required in PCEP to support stateful PCEs. 362 A function can be initiated either from a PCC towards a PCE (C-E) or 363 from a PCE towards a PCC (E-C). The new functions are: 365 Capability advertisement (E-C,C-E): both the PCC and the PCE must 366 announce during PCEP session establishment that they support PCEP 367 Stateful PCE extensions defined in this document. 369 LSP state synchronization (C-E): after the session between the PCC 370 and a stateful PCE is initialized, the PCE must learn the state of 371 a PCC's LSPs before it can perform path computations or update LSP 372 attributes in a PCC. 374 LSP Update Request (E-C): A PCE requests modification of attributes 375 on a PCC's LSP. 377 LSP State Report (C-E): a PCC sends an LSP state report to a PCE 378 whenever the state of an LSP changes. 380 LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 381 update LSP attributes on one or more LSPs; the PCE becomes the 382 authoritative source of the LSP's attributes as long as the 383 delegation is in effect (See Section 5.5); the PCC may withdraw 384 the delegation or the PCE may give up the delegation at any time. 386 [I-D.sivabalan-pce-disco-stateful] defines the extensions needed to 387 support autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or 388 IS-IS ([RFC5089]) for PCE discovery. 390 5. Overview of Protocol Extensions 392 5.1. LSP State Ownership 394 In the PCEP protocol (defined in [RFC5440]), LSP state and operation 395 are under the control of a PCC (a PCC may be an LSR or a management 396 station). Attributes received from a PCE are subject to PCC's local 397 policy. The PCEP protocol extensions described in this document do 398 not change this behavior. 400 An active stateful PCE may have control of a PCC's LSPs that were 401 delegated to it, but the LSP state ownership is retained by the PCC. 402 In particular, in addition to specifying values for LSP's attributes, 403 an active stateful PCE also decides when to make LSP modifications. 405 Retaining LSP state ownership on the PCC allows for: 407 o a PCC to interact with both stateless and stateful PCEs at the 408 same time 410 o a stateful PCE to only modify a small subset of LSP parameters, 411 i.e. to set only a small subset of the overall LSP state; other 412 parameters may be set by the operator through command line 413 interface (CLI) commands 415 o a PCC to revert delegated LSP to an operator-defined default or to 416 delegate the LSPs to a different PCE, if the PCC get disconnected 417 from a PCE with currently delegated LSPs 419 5.2. New Messages 421 In this document, we define the following new PCEP messages: 423 Path Computation State Report (PCRpt): a PCEP message sent by a PCC 424 to a PCE to report the status of one or more LSPs. Each LSP 425 Status Report in a PCRpt message can contain the actual LSP's 426 path, bandwidth, operational and administrative status, etc. An 427 LSP Status Report carried on a PCRpt message is also used in 428 delegation or revocation of control of an LSP to/from a PCE. The 429 PCRpt message is described in Section 6.1. 431 Path Computation Update Request (PCUpd): a PCEP message sent by a 432 PCE to a PCC to update LSP parameters, on one or more LSPs. Each 433 LSP Update Request on a PCUpd message MUST contain all LSP 434 parameters that a PCE wishes to be set for a given LSP. An LSP 435 Update Request carried on a PCUpd message is also used to return 436 LSP delegations if at any point PCE no longer desires control of 437 an LSP. The PCUpd message is described in Section 6.2. 439 The new functions defined in Section 4 are mapped onto the new 440 messages as shown in the following table. 442 +----------------------------------------+--------------------------+ 443 | Function | Message | 444 +----------------------------------------+--------------------------+ 445 | Capability Advertisement (E-C,C-E) | Open | 446 | State Synchronization (C-E) | PCRpt | 447 | LSP State Report (C-E) | PCRpt | 448 | LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd | 449 | LSP Update Request (E-C) | PCUpd | 450 | ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS sub- | 451 | | TLV | 452 | OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, | 453 | | PCE-CAP-FLAGS sub-TLV | 454 +----------------------------------------+--------------------------+ 456 Table 1: New Function to Message Mapping 458 5.3. Capability Advertisement 460 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 461 advertise their support of stateful PCEP extensions. A PCEP Speaker 462 includes the "Stateful PCE Capability" TLV, described in 463 Section 7.1.1, in the OPEN Object to advertise its support for PCEP 464 stateful extensions. The Stateful Capability TLV includes the 'LSP 465 Update' Flag that indicates whether the PCEP Speaker supports LSP 466 parameter updates. 468 The presence of the Stateful PCE Capability TLV in PCC's OPEN Object 469 indicates that the PCC is willing to send LSP State Reports whenever 470 LSP parameters or operational status changes. 472 The presence of the Stateful PCE Capability TLV in PCE's OPEN message 473 indicates that the PCE is interested in receiving LSP State Reports 474 whenever LSP parameters or operational status changes. 476 The PCEP protocol extensions for stateful PCEs MUST NOT be used if 477 one or both PCEP Speakers have not included the Stateful PCE 478 Capability TLV in their respective OPEN message. If the PCEP Speaker 479 on the PCC supports the extensions of this draft but did not 480 advertise this capability, then upon receipt of PCUpd message from 481 the PCE, it SHOULD generate a PCErr with error-type 19 (Invalid 482 Operation), error-value 2 (Attempted LSP Update Request if active 483 stateful PCE capability was not advertised)(see Section 8.4) and it 484 will terminate the PCEP session. If the PCEP Speaker on the PCE 485 supports the extensions of this draft but did not advertise this 486 capability, then upon receipt of a PCRpt message from the PCC, it 487 SHOULD generate a PCErr with error-type 19 (Invalid Operation), 488 error-value 5 (Attempted LSP State Report if active stateful PCE 489 capability was not advertised) (see Section 8.4) and it will 490 terminate the PCEP session. 492 LSP delegation and LSP update operations defined in this document MAY 493 only be used if both PCEP Speakers set the LSP-UPDATE Flag in the 494 "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this 495 is not the case and LSP delegation or LSP update operations are 496 attempted, then a PCErr with error-type 19 (Invalid Operation) and 497 error-value 1 (Attempted LSP Update Request for a non-delegated 498 LSP).(see Section 8.4) SHOULD be generated. Note that even if the 499 update capability has not been advertised, a PCE can still receive 500 LSP Status Reports from a PCC and build and maintain an up to date 501 view of the state of the PCC's LSPs. 503 5.4. State Synchronization 505 The purpose of State Synchronization is to provide a checkpoint-in- 506 time state replica of a PCC's LSP state in a PCE. State 507 Synchronization is performed immediately after the Initialization 508 phase ([RFC5440]). 510 During State Synchronization, a PCC first takes a snapshot of the 511 state of its LSPs state, then sends the snapshot to a PCE in a 512 sequence of LSP State Reports. Each LSP State Report sent during 513 State Synchronization has the SYNC Flag in the LSP Object set to 1. 514 The set of LSPs for which state is synchronized with a PCE is 515 determined by advertised stateful PCEP capabilities and PCC's local 516 configuration (see more details in Section 9.1). 518 The end of synchronization marker is a PCRpt message with the SYNC 519 Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved 520 value 0. The LSP Object does not include the SYMBOLIC-PATH-NAME TLV 521 in this case, and it will include an empty ERO in its path. If the 522 PCC has no state to synchronize, it will only send the end of 523 synchronization marker. 525 A PCE SHOULD NOT send PCUpd messages to a PCC before State 526 Synchronization is complete. A PCC SHOULD NOT send PCReq messages to 527 a PCE before State Synchronization is complete. This is to allow the 528 PCE to get the best possible view of the network before it starts 529 computing new paths. 531 Either the PCE or the PCC MAY terminate the session using the PCEP 532 session termination procedures during the synchronization phase. If 533 the session is terminated, the PCE MUST clean up state it received 534 from this PCC. The session reestablishment MUST be re-attempted per 535 the procedures defined in [RFC5440], including use of a back-off 536 timer. 538 If the PCC encounters a problem which prevents it from completing the 539 state transfer, it MUST send a PCErr message with error-type 20 (LSP 540 State Synchronization Error) and error-value 5 (indicating an 541 internal PCC error) to the PCE and terminate the session. 543 The PCE does not send positive acknowledgements for properly received 544 synchronization messages. It MUST respond with a PCErr message with 545 error-type 20 (LSP State Synchronization Error) and error-value 1 546 (indicating an error in processing the PCRpt) (see Section 8.4) if it 547 encounters a problem with the LSP State Report it received from the 548 PCC and it MUST terminate the session. 550 A PCE implementing a limit on the resources a single PCC can occupy, 551 MUST send a PCErr message with error-type 19 (invalid operation) and 552 error-value 4 (indicating resource limit exceeded) in response to the 553 PCRpt message triggering this condition in the synchronization phase 554 and MUST terminate the session. 556 The successful State Synchronization sequence is shown in Figure 1. 558 +-+-+ +-+-+ 559 |PCC| |PCE| 560 +-+-+ +-+-+ 561 | | 562 |-----PCRpt, SYNC=1----->| (Sync start) 563 | | 564 |-----PCRpt, SYNC=1----->| 565 | . | 566 | . | 567 | . | 568 |-----PCRpt, SYNC=1----->| 569 | . | 570 | . | 571 | . | 572 | | 573 |-----PCRpt, SYNC=0----->| (End of sync marker 574 | | LSP State Report 575 | | for PLSP-ID=0) 576 | | (Sync done) 578 Figure 1: Successful state synchronization 580 The sequence where the PCE fails during the State Synchronization 581 phase is shown in Figure 2. 583 +-+-+ +-+-+ 584 |PCC| |PCE| 585 +-+-+ +-+-+ 586 | | 587 |-----PCRpt, SYNC=1----->| 588 | | 589 |-----PCRpt, SYNC=1----->| 590 | . | 591 | . | 592 | . | 593 |-----PCRpt, SYNC=1----->| 594 | | 595 |-PCRpt, SYNC=1 | 596 | \ ,-PCErr=?-| 597 | \ / | 598 | \/ | 599 | /\ | 600 | / `-------->| (Ignored) 601 |<--------` | 603 Figure 2: Failed state synchronization (PCE failure) 605 The sequence where the PCC fails during the State Synchronization 606 phase is shown in Figure 3. 608 +-+-+ +-+-+ 609 |PCC| |PCE| 610 +-+-+ +-+-+ 611 | | 612 |-----PCRpt, SYNC=1----->| 613 | | 614 |-----PCRpt, SYNC=1----->| 615 | . | 616 | . | 617 | . | 618 |-------- PCErr=? ------>| 619 | | 621 Figure 3: Failed state synchronization (PCC failure) 623 Optimizations to the synchronization procedures and alternate 624 mechanisms of providing the synchronization function are outside the 625 scope of this document and are discussed elsewhere (see 626 [I-D.minei-pce-stateful-sync-optimizations]). 628 5.5. LSP Delegation 630 If during Capability advertisement both the PCE and the PCC have 631 indicated that they support LSP Update, then the PCC may choose to 632 grant the PCE a temporary right to update (a subset of) LSP 633 attributes on one or more LSPs. This is called "LSP Delegation", and 634 it MAY be performed at any time after the Initialization phase, 635 including during the State Synchronization phase. 637 LSP Delegation is controlled by operator-defined policies on a PCC. 638 LSPs are delegated individually - different LSPs may be delegated to 639 different PCEs. An LSP is delegated to at most one PCE at any given 640 point in time. The delegation policy, when all PCC's LSPs are 641 delegated to a single PCE at any given time, SHOULD be supported by 642 all delegation-capable PCCs. Conversely, the policy revoking the 643 delegation for all PCC's LSPs SHOULD also be supported. 645 A PCE may return LSP delegation at any time if it no longer wishes to 646 update the LSP's state. A PCC may revoke LSP delegation at any time. 647 Delegation, Revocation, and Return are done individually for each 648 LSP. 650 In the event of an delegation being rejected or returned by a PCE, 651 the PCC should react based on local policy. It can, for example, 652 either retry delegating to the same PCE using an exponentially 653 increasing timer or delegate to an alternate PCE. 655 5.5.1. Delegating an LSP 657 A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP 658 State Report to 1. If the PCE does not accept the LSP Delegation, it 659 MUST immediately respond with an empty LSP Update Request which has 660 the Delegate flag set to 0. If the PCE accepts the LSP Delegation, 661 it confirms this when it sends the first LSP Update Request for the 662 delegated LSP to the PCC by setting the Delegate flag to 1 (note that 663 this may occur at a later time). 665 The delegation sequence is shown in Figure 4. 667 +-+-+ +-+-+ 668 |PCC| |PCE| 669 +-+-+ +-+-+ 670 | | 671 |---PCRpt, Delegate=1--->| LSP Delegated 672 | | 673 |---PCRpt, Delegate=1--->| 674 | . | 675 | . | 676 | . | 677 |<--(PCUpd,Delegate=1)---| Delegation confirmed 678 | | 679 |---PCRpt, Delegate=1--->| 680 | | 682 Figure 4: Delegating an LSP 684 Note that for an LSP to remain delegated to a PCE, the PCC MUST set 685 the Delegate flag to 1 on each LSP Status Report sent to the PCE. 687 5.5.2. Revoking a Delegation 689 When a PCC decides that a PCE is no longer permitted to modify an 690 LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke 691 an LSP delegation at any time during the LSP's life time. A PCC 692 revoking an LSP delegation MAY immediately clear the LSP state 693 provided by the PCE, but to avoid traffic loss, it SHOULD do so in a 694 make-before-break fashion. If the PCC has received but not yet acted 695 on PCUpd messages from the PCE for the LSP whose delegation is being 696 revoked, then it SHOULD ignore these PCUpd messages when processing 697 the message queue. All effects of all messages for which processing 698 started before the revocation took place MUST be allowed to complete 699 and the result MUST be given the same treatment as any LSP that had 700 been previously delegated to the PCE (e.g. the state MAY be 701 immediately cleared). Any further PCUpd messages from the PCE are 702 handled according to the PCUpd procedures described in this document. 704 If a PCEP session with the PCE to which the LSP is delegated exists 705 in the UP state during the revocation, the PCC MUST notify that PCE 706 by sending an LSP State Report with the Delegate flag set to 0, as 707 shown in Figure 5. 709 +-+-+ +-+-+ 710 |PCC| |PCE| 711 +-+-+ +-+-+ 712 | | 713 |---PCRpt, Delegate=1--->| 714 | | 715 |<--(PCUpd,Delegate=1)---| Delegation confirmed 716 | . | 717 | . | 718 | . | 719 |---PCRpt, Delegate=0--->| PCC revokes delegation 720 | | 722 Figure 5: Revoking a Delegation 724 After an LSP delegation has been revoked, a PCE can no longer update 725 LSP's parameters; an attempt to update parameters of a non-delegated 726 LSP will result in the PCC sending a PCErr message with error-type 19 727 (Invalid Operation), error-value 1 (attempted LSP Update Request for 728 a non-delegated LSP) (see Section 8.4). 730 When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC 731 MUST wait the time interval specified in Redelegation Timeout 732 Interval before revoking LSP delegations to that PCE and attempting 733 to redelegate LSPs to an alternate PCE. If a PCEP session with the 734 original PCE can be reestablished before the Redelegation Timeout 735 Interval timer expires, LSP delegations to the PCE remain intact. 737 Likewise, when a PCC's PCEP session with a PCE terminates 738 unexpectedly, the PCC MUST wait for the State Timeout Interval before 739 flushing any LSP state associated with that PCE. Note that the State 740 Timeout Interval timer may expire before the PCC has redelegated the 741 LSPs to another PCE, for example if a PCC is not connected to any 742 active stateful PCE or if no connected active stateful PCE accepts 743 the delegation. In this case, the PCC SHALL flush any LSP state set 744 by the PCE upon expiration of the State Timeout Interval and revert 745 to operator-defined default parameters or behaviors. This operation 746 SHOULD be done in a make-before-break fashion. 748 The State Timeout Interval SHOULD be greater than or equal to the 749 Redelegation Timeout Interval and MAY be set to infinity (meaning 750 that until the PCC specifically takes action to change the parameters 751 set by the PCE, they will remain intact). 753 5.5.3. Returning a Delegation 755 A PCE that no longer wishes to update an LSP's parameters SHOULD 756 return the LSP delegation back to the PCC by sending an empty LSP 757 Update Request which has the Delegate flag set to 0. Note that in 758 order to keep a delegation, the PCE MUST set the Delegate flag to 1 759 on each LSP Update Request sent to the PCC. 761 +-+-+ +-+-+ 762 |PCC| |PCE| 763 +-+-+ +-+-+ 764 | | 765 |---PCRpt, Delegate=1--->| LSP delegated 766 | . | 767 | . | 768 | . | 769 |<--PCUpd, Delegate=0----| Delegation returned 770 | | 771 |---PCRpt, Delegate=0--->| No delegation for LSP 772 | | 774 Figure 6: Returning a Delegation 776 If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is 777 not connected to any active stateful PCE or if no connected active 778 stateful PCE accepts the delegation), the LSP delegation on the PCC 779 will time out within a configurable Redelegation Timeout Interval and 780 the PCC MUST flush any LSP state set by a PCE at the expiration of 781 the State Timeout Interval. 783 5.5.4. Redundant Stateful PCEs 785 In a redundant configuration where one PCE is backing up another PCE, 786 the backup PCE may have only a subset of the LSPs in the network 787 delegated to it. The backup PCE does not update any LSPs that are 788 not delegated to it. In order to allow the backup to operate in a 789 hot-standby mode and avoid the need for state synchronization in case 790 the primary fails, the backup receives all LSP State Reports from a 791 PCC. When the primary PCE for a given LSP set fails, after expiry of 792 the Redelegation Timeout Interval, the PCC SHOULD delegate to the 793 redundant PCE all LSPs that had been previously delegated to the 794 failed PCE. Assuming that the State Timeout Interval had been 795 configured to be larger than the Redelegation Timeout Interval (as 796 recommended), this delegation change will not cause any changes to 797 the LSP parameters. 799 5.5.5. Redelegation on PCE Failure 801 On failure, the goal is to: 1) avoid any traffic loss on the LSPs 802 that were updated by the PCE that crashed 2) minimize the churn in 803 the network in terms of ownership of the LSPs, 3) not leave any 804 "orphan" (undelegated) LSPs and 4) be able to control when the state 805 that was set by the PCE can be changed or purged. The values chosen 806 for the Redelegation Timeout and State Timeout values affect the 807 ability to accomplish these goals. 809 This section summarizes the behaviour with regards to LSP delegation 810 and LSP state on a PCE failure. 812 If the PCE crashes but recovers within the Redelegation Timeout, both 813 the delegation state and the LSP state are kept intact. 815 If the PCE crashes but does not recover within the Redelegation 816 Timeout, the delegation state is returned to the PCC. If the PCC can 817 redelegate the LSPs to another PCE, and that PCE accepts the 818 delegations, there will be no change in LSP state. If the PCC cannot 819 redelegate the LSPs to another PCE, then upon expiration of the State 820 Timeout Interval, the state set by the PCE is flushed, which may 821 cause change in the LSP state. Note that an operator may choose to 822 use an infinite State Timeout Interval if he wishes to maintain the 823 PCE state indefinetely. Note also that flushing the state should be 824 implemented using make-before-break to avoid traffic loss. 826 If there is a standby PCE, the Redelegation Timeout may be set to 0 827 through policy on the PCC, causing the LSPs to be redelegated 828 immediately to the PCC, which can delegate them immediately to the 829 standby PCE. Assuming the State Timeout Interval is larger than the 830 Redelegation Timeout, the LSP state will be kept intact. 832 5.6. LSP Operations 834 5.6.1. Passive Stateful PCE Path Computation Request/Response 835 +-+-+ +-+-+ 836 |PCC| |PCE| 837 +-+-+ +-+-+ 838 | | 839 1) Path computation |----- PCReq message --->| 840 request sent to | |2) Path computation 841 PCE | | request received, 842 | | path computed 843 | | 844 |<---- PCRep message ----|3) Computed paths 845 | (Positive reply) | sent to the PCC 846 | (Negative reply) | 847 4) LSP Status change| | 848 event | | 849 | | 850 5) LSP Status Report|----- PCRpt message --->| 851 sent to all | . | 852 stateful PCEs | . | 853 | . | 854 6) Repeat for each |----- PCRpt message --->| 855 LSP status change| | 856 | | 858 Figure 7: Passive Stateful PCE Path Computation Request/Response 860 Once a PCC has successfully established a PCEP session with a passive 861 stateful PCE and the PCC's LSP state is synchronized with the PCE 862 (i.e. the PCE knows about all PCC's existing LSPs), if an event is 863 triggered that requires the computation of a set of paths, the PCC 864 sends a path computation request to the PCE ([RFC5440], 865 Section 4.2.3). The PCReq message MAY contain the LSP Object to 866 identify the LSP for which the path computation is requested. 868 Upon receiving a path computation request from a PCC, the PCE 869 triggers a path computation and returns either a positive or a 870 negative reply to the PCC ([RFC5440], Section 4.2.4). 872 Upon receiving a positive path computation reply, the PCC receives a 873 set of computed paths and starts to setup the LSPs. For each LSP, it 874 sends an LSP State Report carried on a PCRpt message to the PCE, 875 indicating that the LSP's status is "Going-up". 877 Once an LSP is up, the PCC sends an LSP State Report carried on a 878 PCRpt message to the PCE, indicating that the LSP's status is 'Up'. 879 If the LSP could not be set up, the PCC sends an LSP State Report 880 indicating that the LSP is "Down' and stating the cause of the 881 failure. Note that due to timing constraints, the LSP status may 882 change from 'Going-up' to 'Up' (or 'Down') before the PCC has had a 883 chance to send an LSP State Report indicating that the status is 884 'Going-up'. In such cases, the PCC may choose to only send the PCRpt 885 indicating the latest status ('Up' or 'Down'). 887 Upon receiving a negative reply from a PCE, a PCC may decide to 888 resend a modified request or take any other appropriate action. For 889 each requested LSP, it also sends an LSP State Report carried on a 890 PCRpt message to the PCE, indicating that the LSP's status is 'Down'. 892 There is no direct correlation between PCRep and PCRpt messages. For 893 a given LSP, multiple LSP State Reports will follow a single PCRep 894 message, as a PCC notifies a PCE of the LSP's state changes. 896 A PCC sends each LSP State Report to each stateful PCE that is 897 connected to the PCC. 899 Note that a single PCRpt message MAY contain multiple LSP State 900 Reports. 902 The passive stateful PCE is the model for stateful PCEs is described 903 in [RFC4655], Section 6.8. 905 5.6.2. Active Stateful PCE LSP Update 907 +-+-+ +-+-+ 908 |PCC| |PCE| 909 +-+-+ +-+-+ 910 | | 911 1) LSP State |-- PCRpt, Delegate=1 -->| 912 Synchronization | . | 913 or add new LSP | . |2) PCE decides to 914 | . | update the LSP 915 | | 916 |<---- PCUpd message ----|3) PCUpd message sent 917 | | to PCC 918 | | 919 | | 920 4) LSP Status Report|---- PCRpt message ---->| 921 sent(->Going-up) | . | 922 | . | 923 | . | 924 5) LSP Status Report|---- PCRpt message ---->| 925 sent (->Up|Down) | | 926 | | 928 Figure 8: Active Stateful PCE 930 Once a PCC has successfully established a PCEP session with an active 931 stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e. 932 the PCE knows about all PCC's existing LSPs) and LSPs have been 933 delegated to the PCE, the PCE can modify LSP parameters of delegated 934 LSPs. 936 A PCE sends an LSP Update Request carried on a PCUpd message to the 937 PCC. The LSP Update Request contains a variety of objects that 938 specify the set of constraints and attributes for the LSP's path. 939 Each LSP Update Request has a unique identifier, the SRP-ID-number, 940 carried in the SRP (Stateful PCE Request Parameters) Object described 941 in Section 7.2. The SRP-ID-number is used to correlate errors and 942 state reports to LSP Update Requests. A single PCUpd message MAY 943 contain multiple LSP Update Requests. 945 Upon receiving a PCUpd message the PCC starts to setup LSPs specified 946 in LSP Update Requests carried in the message. For each LSP, it 947 sends an LSP State Report carried on a PCRpt message to the PCE, 948 indicating that the LSP's status is 'Going-up'. If the PCC decides 949 that the LSP parameters proposed in the PCUpd message are 950 unacceptable, it MUST report this error by including the LSP-ERROR- 951 CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable 952 parameters" in the LSP object in the PCRpt message to the PCE. Based 953 on local policy, it MAY react further to this error by revoking the 954 delegation. If the PCC receives a PCUpd message for an LSP object 955 identified with a PLSP-ID that does not exist on the PCC, it MUST 956 generate a PCErr with error-type 19 (Invalid Operation), error-value 957 3, (Attempted LSP Update Request for an LSP identified by an unknown 958 PSP-ID) (see Section 8.4). 960 Once an LSP is up, the PCC sends an LSP State Report (PCRpt message) 961 to the PCE, indicating that the LSP's status is 'Up'. If the LSP 962 could not be set up, the PCC sends an LSP State Report indicating 963 that the LSP is 'Down' and stating the cause of the failure. A PCC 964 may choose to compress LSP State Reports to only reflect the most up 965 to date state, as discussed in the previous section. 967 A PCC sends each LSP State Report to each stateful PCE that is 968 connected to the PCC. 970 PCErr and PCRpt messages triggered as a result of a PCUpd message 971 MUST include the SRP-ID-number from the PCUpd. This provides 972 correlation of requests and errors and acknowledgement of state 973 processing. The PCC may choose to compress state when processing 974 PCUpd. In this case, receipt of a higher SRP-ID-number implicitly 975 acknowledges processing all the earlier updates for the specific LSP. 977 A PCC MUST NOT send to any PCE a Path Computation Request for a 978 delegated LSP. Should the PCC decide it wants to issue a Path 979 Computation Request on a delegated LSP, it MUST perform Delegation 980 Revocation procedure first. 982 5.7. LSP Protection 984 LSP protection and interaction with stateful PCE, as well as the 985 extensions necessary to implement this functionality will be 986 discussed in a separate draft. 988 5.8. Transport 990 A permanent PCEP session MUST be established between a stateful PCE 991 and the PCC. In the case of session failure, session reestablishment 992 MUST be re-attempted per the procedures defined in [RFC5440]. 994 6. PCEP Messages 996 As defined in [RFC5440], a PCEP message consists of a common header 997 followed by a variable-length body made of a set of objects that can 998 be either mandatory or optional. An object is said to be mandatory 999 in a PCEP message when the object must be included for the message to 1000 be considered valid. For each PCEP message type, a set of rules is 1001 defined that specify the set of objects that the message can carry. 1002 An implementation MUST form the PCEP messages using the object 1003 ordering specified in this document. 1005 6.1. The PCRpt Message 1007 A Path Computation LSP State Report message (also referred to as 1008 PCRpt message) is a PCEP message sent by a PCC to a PCE to report the 1009 current state of an LSP. A PCRpt message can carry more than one LSP 1010 State Reports. A PCC can send an LSP State Report either in response 1011 to an LSP Update Request from a PCE, or asynchronously when the state 1012 of an LSP changes. The Message-Type field of the PCEP common header 1013 for the PCRpt message is set to [TBD]. 1015 The format of the PCRpt message is as follows: 1017 ::= 1018 1019 Where: 1021 ::= [] 1023 ::= [] 1024 1025 1026 Where: 1027 ::= [] 1029 Where: 1030 is defined in [RFC5440] and extended by PCEP extensions. 1032 The SRP object (see Section 7.2) is optional. If the PCRpt message 1033 is not in response to a PCupd message, the SRP object MAY be omitted. 1034 When the PCC does not include the SRP object, the PCE treats this as 1035 an SRP object with an SRP-ID-number equal to the reserved value 1036 0x00000000. The reserved value 0x00000000 indicates that the state 1037 reported is not as a result of processing a PCUpd message. 1039 If the PCRpt message is in response to a PCUpd message, the SRP 1040 object MUST be included and the value of the SRP-ID-number in the SRP 1041 Object MUST be the same as that sent in the PCUpd message that 1042 triggered the state that is reported. If the PCC compressed several 1043 PCUpd messages for the same LSP by only processing the latest one, 1044 then it should use the SRP-ID-number of that request. No state 1045 compression is allowed for state reporting, e.g. PCRpt messages MUST 1046 NOT be pruned from the PCC's egress queue even if subsequent 1047 operations on the same LSP have been completed before the PCRpt 1048 message has been sent to the TCP stack. The PCC MUST explicitly 1049 report state changes (including removal) for paths it manages. 1051 The LSP object (see Section 7.3) is mandatory, and it MUST be 1052 included in each LSP State Report on the PCRpt message. If the LSP 1053 object is missing, the receiving PCE MUST send a PCErr message with 1054 Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP 1055 object missing). 1057 If the LSP transitioned to non-operational state, the PCC SHOULD 1058 include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error 1059 Code to report the error to the PCE. 1061 The RRO SHOULD be included by the PCC when the path is up, but MAY be 1062 omitted if the path is down due to a signaling error or another 1063 failure. 1065 A PCE may choose to implement a limit on the resources a single PCC 1066 can occupy. If a PCRpt is received that causes the PCE to exceed 1067 this limit, it MUST send a PCErr message with error-type 19 (invalid 1068 operation) and error-value 4 (indicating resource limit exceeded) in 1069 response to the PCRpt message triggering this condition and MAY 1070 terminate the session. 1072 6.2. The PCUpd Message 1074 A Path Computation LSP Update Request message (also referred to as 1075 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 1076 attributes of an LSP. A PCUpd message can carry more than one LSP 1077 Update Request. The Message-Type field of the PCEP common header for 1078 the PCUpd message is set to [TBD]. 1080 The format of a PCUpd message is as follows: 1082 ::= 1083 1084 Where: 1086 ::= [] 1088 ::= 1089 1090 1091 Where: 1092 ::= 1094 Where: 1095 is defined in [RFC5440] and extended by PCEP extensions. 1097 There are three mandatory objects that MUST be included within each 1098 LSP Update Request in the PCUpd message: the SRP Object (see 1099 Section 7.2), the LSP object (see Section 7.3) and the ERO object (as 1100 defined in [RFC5440]. If the SRP object is missing, the receiving 1101 PCC MUST send a PCErr message with Error-type=6 (Mandatory Object 1102 missing) and Error-value=10 (SRP object missing). If the LSP object 1103 is missing, the receiving PCC MUST send a PCErr message with Error- 1104 type=6 (Mandatory Object missing) and Error-value=8 (LSP object 1105 missing). If the ERO object is missing, the receiving PCC MUST send 1106 a PCErr message with Error-type=6 (Mandatory Object missing) and 1107 Error-value=9(ERO object missing). 1109 A PCC only acts on an LSP Update Request if permitted by the local 1110 policy configured by the network manager. Each LSP Update Request 1111 that the PCC acts on results in an LSP setup operation. An LSP 1112 Update Request MUST contain all LSP parameters that a PCE wishes to 1113 be set for the LSP. A PCC MAY set missing parameters from locally 1114 configured defaults. If the LSP specified in the Update Request is 1115 already up, it will be re-signaled. 1117 The PCC SHOULD minimize the traffic interruption, and MAY use the 1118 make-before-break procedures described in [RFC3209] in order to 1119 achieve this goal. If the make-before-break procedures are used, two 1120 paths will briefly co-exist. The PCC MUST send separate PCRpt 1121 messages for each, identified by the LSP-IDENTIFIERS TLV. When the 1122 old path is torn down after the head end switches over the traffic, 1123 this event MUST be reported by sending a PCRpt message with the LSP- 1124 IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number 1125 that the PCE associates with this PCRpt MUST be 0x00000000. Thus, a 1126 make-before-break operation will typically result in at least two 1127 PCRpt messages, one for the new path and one for the removal of the 1128 old path (more messages may be possible if intermediate states are 1129 reported). 1131 If the path setup fails due to an RSVP signaling error, the error is 1132 reported to the PCE. The PCC will not attempt to resignal the path 1133 until it is prompted again by the PCE with a subsequent PCUpd 1134 message. 1136 A PCC MUST respond with an LSP State Report to each LSP Update 1137 Request it processed to indicate the resulting state of the LSP in 1138 the network (even if this processing did not result in changing the 1139 state of the LSP). The SRP-ID-number included in the PCRpt MUST 1140 match that in the PCUpd. A PCC MAY respond with multiple LSP State 1141 Reports to report LSP setup progress of a single LSP. In that case, 1142 the SRP-ID-number MUST be included for the first message, for 1143 subsequent messages the reserved value 0x00000000 SHOULD be used. 1145 Note that a PCC MUST process all LSP Update Requests - for example, 1146 an LSP Update Request is sent when a PCE returns delegation or puts 1147 an LSP into non-operational state. The protocol relies on TCP for 1148 message-level flow control. 1150 If the rate of PCUpd messages sent to a PCC for the same target LSP 1151 exceeds the rate at which the PCC can signal LSPs into the network, 1152 the PCC MAY perform state compression on its ingress queue. The 1153 compression algorithm is based on the fact that each PCUpd request 1154 contains the complete LSP state the PCE wishes to be set and works as 1155 follows: when the PCC starts processing a PCUpd message at the head 1156 of its ingress queue, it may search the queue forward for more recent 1157 PCUpd messages pertaining that particular LSP, prune all but the 1158 latest one from the queue and process only the last one as that 1159 request contains the most up-to-date desired state for the LSP. The 1160 PCC MUST NOT send PCRpt nor PCErr messages for requests which were 1161 pruned from the queue in this way. This compression step may be 1162 performed only while the LSP is not being signaled, e.g. if two PCUpd 1163 arrive for the same LSP in quick succession and the PCC started the 1164 signaling of the changes relevant to the first PCUpd, then it MUST 1165 wait until the signaling finishes (and report the new state via a 1166 PCRpt) before attempting to apply the changes indicated in the second 1167 PCUpd. 1169 Note also that it is up to the PCE to handle inter-LSP dependencies; 1170 for example, if ordering of LSP set-ups is required, the PCE has to 1171 wait for an LSP State Report for a previous LSP before starting the 1172 update of the next LSP. If the PCUpd cannot be satisfied (for 1173 example due to unsupported object or TLV), the PCC MUST respond with 1174 a PCErr message indicating the failure (see Section 7.3.3). 1176 6.3. The PCErr Message 1178 If the stateful PCE capability has been advertised on the PCEP 1179 session, the PCErr message MAY include the SRP object. If the error 1180 reported is the result of an LSP update request, then the SRP-ID- 1181 number MUST be the one from the PCUpd that triggered the error. If 1182 the error is unsolicited, the SRP object MAY be omitted. This is 1183 equivalent to including an SRP object with SRP-ID-number equal to the 1184 reserved value 0x00000000. 1186 The format of a PCErr message from [RFC5440] is extended as follows: 1188 ::= 1189 ( [] ) | 1190 [] 1192 ::=[] 1194 ::=[ | ] <<<< new 1195 1197 ::=[] 1199 ::=[] <<< new 1201 ::=[] 1203 6.4. The PCReq Message 1205 A PCC MAY include the LSP object in the PCReq message (see 1206 Section 7.3) if the stateful PCE capability has been negotiated on a 1207 PCEP session between the PCC and a PCE. 1209 The definition of the PCReq message from [RFC5440] is extended to 1210 optionally include the LSP object after the END-POINTS object. The 1211 encoding from [RFC5440] will become: 1213 ::= 1214 [] 1215 1217 Where: 1219 ::=[] 1220 ::=[] 1222 ::= 1223 1224 [] <--- New Object 1225 [] 1226 [] 1227 [] 1228 [[]] 1229 [] 1230 [] 1232 6.5. The PCRep Message 1234 A PCE MAY include the LSP object in the PCRep message (see 1235 (Section 7.3) if the stateful PCE capability has been negotiated on a 1236 PCEP session between the PCC and the PCE and the LSP object was 1237 included in the corresponding PCReq message from the PCC. 1239 The definition of the PCRep message from [RFC5440] is extended to 1240 optionally include the LSP object after the RP object. The encoding 1241 from [RFC5440] will become: 1243 ::= 1244 1246 Where: 1248 ::=[] 1250 ::= 1251 [] <--- New Object 1252 [] 1253 [] 1254 [] 1256 7. Object Formats 1258 The PCEP objects defined in this document are compliant with the PCEP 1259 object format defined in [RFC5440]. The P flag and the I flag of the 1260 PCEP objects defined in this document MUST always be set to 0 on 1261 transmission and MUST be ignored on receipt since these flags are 1262 exclusively related to path computation requests. 1264 7.1. OPEN Object 1266 This document defines two new optional TLVs for use in the OPEN 1267 Object. 1269 7.1.1. Stateful PCE Capability TLV 1271 The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the 1272 OPEN Object for stateful PCE capability advertisement. Its format is 1273 shown in the following figure: 1275 0 1 2 3 1276 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 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Type=[TBD] | Length=4 | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Flags |U| 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 Figure 9: STATEFUL-PCE-CAPABILITY TLV format 1285 The type of the TLV is [TBD] and it has a fixed length of 4 octets. 1287 The value comprises a single field - Flags (32 bits): 1289 U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag 1290 indicates that the PCC allows modification of LSP parameters; if 1291 set to 1 by a PCE, the U Flag indicates that the PCE is capable of 1292 updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be 1293 advertised by both a PCC and a PCE for PCUpd messages to be 1294 allowed on a PCEP session. 1296 Unassigned bits are considered reserved. They MUST be set to 0 on 1297 transmission and MUST be ignored on receipt. 1299 Advertisement of the stateful PCE capability implies support of LSPs 1300 that are signaled via RSVP, as well as the objects, TLVs and 1301 procedures defined in this document. 1303 7.2. SRP Object 1305 The SRP (Stateful PCE Request Parameters) object MUST be carried 1306 within PCUpd messages and MAY be carried within PCRpt and PCErr 1307 messages. The SRP object is used to correlate between update 1308 requests sent by the PCE and the error reports and state reports sent 1309 by the PCC. 1311 SRP Object-Class is [TBD]. 1313 SRP Object-Type is 1. 1315 The format of the SRP object body is shown in Figure 10: 1317 0 1 2 3 1318 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 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Flags | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | SRP-ID-number | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | | 1325 // Optional TLVs // 1326 | | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 Figure 10: The SRP Object format 1331 The SRP object body has a variable length and may contain additional 1332 TLVs. The SYMBOLIC-PATH-NAME TLV MAY be included as one of the 1333 optional TLVs. 1335 Flags (32 bits): None defined yet. 1337 SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the 1338 current PCEP session uniquely identify the operation that the PCE has 1339 requested the PCC to perform on a given LSP. The SRP-ID-number is 1340 incremented each time a new request is sent to the PCC, and may wrap 1341 around. 1343 The values 0x00000000 and 0xFFFFFFFF are reserved. 1345 Every request to update an LSP receives a new SRP-ID-number. This 1346 number is unique per PCEP session and is incremented each time an 1347 operation is requested from the PCE. Thus, for a given LSP there may 1348 be more than one SRP-id-number unacknowledged at a given time. The 1349 value of the SRP-ID-number is echoed back by the PCC in PCErr and 1350 PCRpt messages to allow for correlation between requests made by the 1351 PCE and errors or state reports generated by the PCC. If the error 1352 or report were not as a result of a PCE operation (for example in the 1353 case of a link down event), the reserved value of 0x00000000 is used 1354 for the SRP-ID-number. The absence of the SRP object is equivalent 1355 to an SRP object with the reserved value of 0x00000000. An SRP-ID- 1356 number is considered unacknowledged and cannot be reused until a 1357 PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the 1358 same LSP. In case of SRP-ID wrapping the last SRP-ID before the 1359 wrapping MUST be explicitly acknowledged, to avoid a situation where 1360 SRP-IDs remain unacknowledged after the wrap. This means that the 1361 PCC may need to issue two PCUpd messages on detecting a wrap. 1363 7.3. LSP Object 1365 The LSP object MUST be present within PCRpt and PCUpd messages. The 1366 LSP object MAY be carried within PCReq and PCRep messages if the 1367 stateful PCE capability has been negotiated on the session. The LSP 1368 object contains a set of fields used to specify the target LSP, the 1369 operation to be performed on the LSP, and LSP Delegation. It also 1370 contains a flag indicating to a PCE that the LSP state 1371 synchronization is in progress. This document focuses on LSPs that 1372 are signaled with RSVP, many of the TLVs used with the LSP object 1373 mirror RSVP state. 1375 LSP Object-Class is [TBD]. 1377 LSP Object-Type is 1. 1379 The format of the LSP object body is shown in Figure 11: 1381 0 1 2 3 1382 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 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | PLSP-ID | Flag | O|A|R|S|D| 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 // TLVs // 1387 | | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 Figure 11: The LSP Object format 1392 PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC 1393 creates a unique PLSP-ID for each LSP that is constant for the 1394 lifetime of a PCEP session. The PCC will advertise the same PLSP-ID 1395 on all PCEP sessions it maintains at a given times. The mapping of 1396 the Symbolic Path Name to PLSP-ID is communicated to the PCE by 1397 sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All 1398 subsequent PCEP messages then address the LSP by the PLSP-ID. The 1399 values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a 1400 value that is constant for the lifetime of the PCEP session, during 1401 which time for an RSVP-signaled LSP there might be a different RSVP 1402 identifiers (LSP-id, tunnel-id) allocated it. 1404 Flags (12 bits): 1406 D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1 1407 indicates that the PCC is delegating the LSP to the PCE. On a 1408 PCUpd message, the D flag set to 1 indicates that the PCE is 1409 confirming the LSP Delegation. To keep an LSP delegated to the 1410 PCE, the PCC must set the D flag to 1 on each PCRpt message for 1411 the duration of the delegation - the first PCRpt with the D flag 1412 set to 0 revokes the delegation. To keep the delegation, the PCE 1413 must set the D flag to 1 on each PCUpd message for the duration of 1414 the delegation - the first PCUpd with the D flag set to 0 returns 1415 the delegation. 1417 S (SYNC - 1 bit): the S Flag MUST be set to 1 on each PCRpt sent 1418 from a PCC during State Synchronization. The S Flag MUST be set 1419 to 0 in other PCRpt messages sent from the PCC. 1421 R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the 1422 LSP has been removed from the PCC and the PCE SHOULD remove all 1423 state from its database. Upon receiving an LSP State Report with 1424 the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD 1425 remove all state for the path identified by the LSP Identifiers 1426 TLV from its database. When the all-zeros LSP-IDENTIFIERS-TLV is 1427 used, the PCE SHOULD remove all state for the PLSP-ID from its 1428 database. 1430 A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates 1431 the PCC's target operational status for this LSP. On PCUpd 1432 messages, the A Flag indicates the LSP status that the PCE desires 1433 for this LSP. In both cases, a value of '1' means that the 1434 desired operational state is active, and a value of '0' means that 1435 the desired operational state is inactive. A PCC ignores the A 1436 flag on a PCUpd message unless the operator's policy allows the 1437 PCE to control the corresponding LSP's administrative state. 1439 O(Operational - 3 bits): On PCRpt messages, the O Field represents 1440 the operational status of the LSP. 1442 The following values are defined: 1444 0 - DOWN: not active. 1446 1 - UP: signalled. 1448 2 - ACTIVE: up and carrying traffic. 1450 3 - GOING-DOWN: LSP is being torn down, resources are being 1451 released. 1453 4 - GOING-UP: LSP is being signalled. 1455 5-7 - Reserved: these values are reserved for future use. 1457 Unassigned bits are considered reserved. They MUST be set to 0 on 1458 transmission and MUST be ignored on receipt. 1460 TLVs that may be included in the LSP Object are described in the 1461 following sections. 1463 7.3.1. LSP Identifiers TLVs 1465 The LSP Identifiers TLV MUST be included in the LSP object in PCRpt 1466 messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will 1467 generate an error with error-type 6 (mandatory object missing) and 1468 error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session. 1469 The LSP Identifiers TLV MAY be included in the LSP object in PCUpd 1470 messages for RSVP-signaled LSPs. The special value of all zeros for 1471 this TLV is used to refer to all paths pertaining to a particular 1472 PLSP-ID. There are two LSP Identifiers TLVs, one for IPv4 and one 1473 for IPv6. 1475 It is the responsibility of the PCC to send to the PCE the 1476 identifiers for each RSVP incarnation of the tunnel. For exmple, in 1477 a make-before-break scenario, the PCC MUST send a separate PCRpt for 1478 the old and for the reoptimized paths, and explicitly report removal 1479 of any of these paths using the R bit in the LSP object. 1481 The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following 1482 figure: 1484 0 1 2 3 1485 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Type=[TBD] | Length=16 | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | IPv4 Tunnel Sender Address | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | LSP ID | Tunnel ID | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Extended Tunnel ID | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | IPv4 Tunnel Endpoint Address | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 Figure 12: IPV4-LSP-IDENTIFIERS TLV format 1500 The type of the TLV is [TBD] and it has a fixed length of 12 octets. 1501 The value contains the following fields: 1503 IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, 1504 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 1505 Sender Template Object. 1507 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1508 [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template 1509 Object. 1511 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1512 [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. 1513 Tunnel ID remains constant over the life time of a tunnel. 1515 Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' 1516 identifier defined in [RFC3209], Section 4.6.1.1 for the 1517 LSP_TUNNEL_IPv4 Session Object. 1519 IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 1520 address, as defined in [RFC3209], Section 4.6.1.1 for the 1521 LSP_TUNNEL_IPv4 Sender Template Object. 1523 The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l following 1524 figure: 1526 0 1 2 3 1527 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Type=[TBD] | Length=52 | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | | 1532 + + 1533 | IPv6 tunnel sender address | 1534 + (16 octets) + 1535 | | 1536 + + 1537 | | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | LSP ID | Tunnel ID | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | | 1542 + + 1543 | Extended Tunnel ID | 1544 + (16 octets) + 1545 | | 1546 + + 1547 | | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | | 1550 + + 1551 | IPv6 tunnel endpoint address | 1552 + (16 octets) + 1553 | | 1554 + + 1555 | | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 Figure 13: IPV6-LSP-IDENTIFIERS TLV format 1560 The type of the TLV is [TBD] and it has a fixed length of 36 octets. 1561 The value contains the following fields: 1563 IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, 1564 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 1565 Sender Template Object. 1567 LSP ID: contains the 16-bit 'LSP ID' identifier defined in 1568 [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template 1569 Object. 1571 Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in 1572 [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. 1573 Tunnel ID remains constant over the life time of a tunnel. 1575 However, when Global Path Protection or Global Default Restoration 1576 is used, both the primary and secondary LSPs have their own Tunnel 1577 IDs. A PCC will report a change in Tunnel ID when traffic 1578 switches over from primary LSP to secondary LSP (or vice versa). 1580 Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID' 1581 identifier defined in [RFC3209], Section 4.6.1.2 for the 1582 LSP_TUNNEL_IPv6 Session Object. 1584 IPv6 Tunnel Endpoint Address: contains the egress node's IPv6 1585 address, as defined in [RFC3209], Section 4.6.1.2 for the 1586 LSP_TUNNEL_IPv6 Session Object. 1588 7.3.2. Symbolic Path Name TLV 1590 Each LSP (path) MUST have a symbolic name that is unique in the PCC. 1591 This symbolic path name MUST remain constant throughout a path's 1592 lifetime, which may span across multiple consecutive PCEP sessions 1593 and/or PCC restarts. The symbolic path name MAY be specified by an 1594 operator in a PCC's configuration. If the operator does not specify 1595 a unique symbolic name for a path, the PCC MUST auto-generate one. 1597 The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report 1598 when during a given PCEP session an LSP is first reported to a PCE. 1599 A PCC sends to a PCE the first LSP State Report either during State 1600 Synchronization, or when a new LSP is configured at the PCC. The 1601 symbolic path name MAY be included in subsequent LSP State Reports 1602 for the LSP. 1604 The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object 1605 and the SRP Object. 1607 The format of the SYMBOLIC-PATH-NAME TLV is shown in the following 1608 figure: 1610 0 1 2 3 1611 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 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Type=[TBD] | Length (variable) | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | | 1616 // Symbolic Path Name // 1617 | | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 Figure 14: SYMBOLIC-PATH-NAME TLV format 1622 The type of the TLV is [TBD] and it has a variable length, which MUST 1623 be greater than 0. 1625 7.3.3. LSP Error Code TLV 1627 The LSP Error code TLV is an optional TLV for use in the LSP object 1628 to convey error information. When an LSP Update Request fails, an 1629 LSP State Report MUST be sent to report the current state of the LSP, 1630 and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for 1631 the failure. Similarly, when a PCRpt is sent as a result of an LSP 1632 transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD 1633 be included to indicate the reason for the transition. 1635 The format of the LSP-ERROR-CODE TLV is shown in the following 1636 figure: 1638 0 1 2 3 1639 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 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Type=[TBD] | Length=4 | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | LSP Error Code | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 Figure 15: LSP-ERROR-CODE TLV format 1648 The type of the TLV is [TBD] and it has a fixed length of 4 octets. 1649 The value contains an error code that indicates the cause of the 1650 failure. 1652 The following LSP Error Codes are defined: 1654 Value Meaning 1655 1 Unknown reason 1656 2 Limit reached for PCE-controlled LSPs 1657 3 Too many pending LSP update requests 1658 4 Unacceptable parameters 1659 5 Internal error 1660 6 LSP administratively brought down 1661 7 LSP preempted 1662 8 RSVP signaling error 1664 7.3.4. RSVP Error Spec TLV 1666 The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object 1667 to carry RSVP error information. It includes the RSVP ERROR_SPEC or 1668 USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned 1669 to the PCC from a downstream node. If the set up of an LSP fails at 1670 a downstream node which returned an ERROR_SPEC to the PCC, the PCC 1671 SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with 1672 LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV 1673 with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC Object. 1675 The format of the RSVP-ERROR-SPEC TLV is shown in the following 1676 figure: 1678 0 1 2 3 1679 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 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | Type=[TBD] | Length (variable) | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | | 1684 + RSVP ERROR_SPEC or USER_ERROR_SPEC Object + 1685 | | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 Figure 16: RSVP-ERROR-SPEC TLV format 1690 The type of the TLV is [TBD] and it has a variable length. The value 1691 contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the 1692 object header. 1694 8. IANA Considerations 1696 This document requests IANA actions to allocate code points for the 1697 protocol elements defined in this document. Values shown here are 1698 suggested for use by IANA. 1700 8.1. PCEP Messages 1702 This document defines the following new PCEP messages: 1704 Value Meaning Reference 1705 10 Report This document 1706 11 Update This document 1708 8.2. PCEP Objects 1710 This document defines the following new PCEP Object-classes and 1711 Object-values: 1713 Object-Class Value Name Reference 1715 32 LSP This document 1716 Object-Type 1717 1 1718 33 SRP This document 1719 Object-Type 1720 1 1722 8.3. LSP Object 1724 This document requests that a registry is created to manage the Flags 1725 field of the LSP object. New values are to be assigned by Standards 1726 Action [RFC5226]. Each bit should be tracked with the following 1727 qualities: 1729 o Bit number (counting from bit 0 as the most significant bit) 1731 o Capability description 1733 o Defining RFC 1735 The following values are defined in this document: 1737 Bit Description Reference 1739 0-4 Reserved This document 1740 5-7 Operational (3 bits) This document 1741 8 Administrative This document 1742 9 Remove This document 1743 10 SYNC This document 1744 11 Delegate This document 1746 8.4. PCEP-Error Object 1748 This document defines new Error-Type and Error-Value for the 1749 following new error conditions: 1751 Error-Type Meaning 1752 6 Mandatory Object missing 1754 Error-value=8: LSP Object missing 1755 Error-value=9: ERO Object missing 1756 Error-value=10: SRP Object missing 1757 Error-value=11: LSP-IDENTIFIERS TLV missing 1758 19 Invalid Operation 1759 Error-value=1: Attempted LSP Update Request for a non- 1760 delegated LSP. The PCEP-ERROR Object 1761 is followed by the LSP Object that 1762 identifies the LSP. 1763 Error-value=2: Attempted LSP Update Request if active 1764 stateful PCE capability was not 1765 advertised. 1766 Error-value=3: Attempted LSP Update Request for an LSP 1767 identified by an unknown PLSP-ID. 1768 Error-value=4: A PCE indicates to a PCC that it has 1769 exceeded the resource limit allocated 1770 for its state, and thus it cannot 1771 accept and process its LSP State Report 1772 message. 1773 Error-value=5: Attempted LSP State Report if active 1774 stateful PCE capability was not 1775 advertised. 1776 20 LSP State synchronization error. 1778 Error-value=1: A PCE indicates to a PCC that it can 1779 not process (an otherwise valid) LSP 1780 State Report. The PCEP-ERROR Object is 1781 followed by the LSP Object that 1782 identifies the LSP. 1783 Error-value=5: A PCC indicates to a PCE that it can 1784 not complete the state synchronization, 1786 8.5. PCEP TLV Type Indicators 1788 This document defines the following new PCEP TLVs: 1790 Value Meaning Reference 1791 16 STATEFUL-PCE-CAPABILITY This document 1792 17 SYMBOLIC-PATH-NAME This document 1793 18 IPV4-LSP-IDENTIFIERS This document 1794 19 IPV6-LSP-IDENTIFIERS This document 1795 20 LSP-ERROR-CODE This document 1796 21 RSVP-ERROR-SPEC This document 1798 8.6. STATEFUL-PCE-CAPABILITY TLV 1800 This document requests that a registry is created to manage the Flags 1801 field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New 1802 values are to be assigned by Standards Action [RFC5226]. Each bit 1803 should be tracked with the following qualities: 1805 o Bit number (counting from bit 0 as the most significant bit) 1806 o Capability description 1808 o Defining RFC 1810 The following values are defined in this document: 1812 Bit Description Reference 1814 31 LSP-UPDATE-CAPABILITY This document 1816 8.7. LSP-ERROR-CODE TLV 1818 This document requests that a registry is created to manage the value 1819 of the LSP error code field in this TLV. This field specifies the 1820 reason for failure to update the LSP. 1822 Value Meaning 1823 1 Unknown reason 1824 2 Limit reached for PCE-controlled LSPs 1825 3 Too many pending LSP update requests 1826 4 Unacceptable parameters 1827 5 Internal error 1828 6 LSP administratively brought down 1829 7 LSP preempted 1830 8 RSVP signaling error 1832 9. Manageability Considerations 1834 All manageability requirements and considerations listed in [RFC5440] 1835 apply to PCEP protocol extensions defined in this document. In 1836 addition, requirements and considerations listed in this section 1837 apply. 1839 9.1. Control Function and Policy 1841 In addition to configuring specific PCEP session parameters, as 1842 specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST 1843 allow configuring the stateful PCEP capability and the LSP Update 1844 capability. A PCC implementation SHOULD allow the operator to 1845 specify multiple candidate PCEs for and a delegation preference for 1846 each candidate PCE. A PCC SHOULD allow the operator to specify an 1847 LSP delegation policy where LSPs are delegated to the most-preferred 1848 online PCE. A PCC MAY allow the operator to specify different LSP 1849 delegation policies. 1851 A PCC implementation which allows concurrent connections to multiple 1852 PCEs SHOULD allow the operator to group the PCEs by administrative 1853 domains and it MUST NOT advertise LSP existence and state to a PCE if 1854 the LSP is delegated to a PCE in a different group. 1856 A PCC implementation SHOULD allow the operator to specify whether the 1857 PCC will advertise LSP existence and state for LSPs that are not 1858 controlled by any PCE (for example, LSPs that are statically 1859 configured at the PCC). 1861 A PCC implementation SHOULD allow the operator to specify both the 1862 Redelegation Timeout Interval and the State Timeout Interval. The 1863 default value of the Redelegation Timeout Interval SHOULD be set to 1864 30 seconds. An operator MAY also configure a policy that will 1865 dynamically adjust the Redelegation Timeout Interval, for example 1866 setting it to zero when the PCC has an established session to a 1867 backup PCE. The default value for the State Timeout Interval SHOULD 1868 be set to 60 seconds. 1870 After the expiration of the State Timeout Interval, the LSP reverts 1871 to operator-defined default parameters. A PCC implementation MUST 1872 allow the operator to specify the default LSP parameters. To achieve 1873 a behavior where the LSP retains the parameters set by the PCE until 1874 such time that the PCC makes a change to them, a State Timeout 1875 Interval of infinity SHOULD be used. Any changes to LSP parameters 1876 SHOULD be done in make-before-break fashion. 1878 A PCC implementation SHOULD allow the operator to specify delegation 1879 priority for PCEs. This effectively defines the primary PCE and one 1880 or more backup PCEs to which primary PCE's LSPs can be delegated when 1881 the primary PCE fails. 1883 Policies defined for stateful PCEs and PCCs should eventually fit in 1884 the Policy-Enabled Path Computation Framework defined in [RFC5394], 1885 and the framework should be extended to support Stateful PCEs. 1887 9.2. Information and Data Models 1889 PCEP session configuration and information in the PCEP MIB module 1890 SHOULD be extended to include advertised stateful capabilities, 1891 synchronization status, and delegation status (at the PCC list PCEs 1892 with delegated LSPs). 1894 9.3. Liveness Detection and Monitoring 1896 PCEP protocol extensions defined in this document do not require any 1897 new mechanisms beyond those already defined in [RFC5440], 1898 Section 8.3. 1900 9.4. Verifying Correct Operation 1902 Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP 1903 protocol extensions defined in this document. In addition to 1904 monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP 1905 implementation SHOULD provide the following parameters: 1907 o Total number of LSP updates 1909 o Number of successful LSP updates 1911 o Number of dropped LSP updates 1913 o Number of LSP updates where LSP setup failed 1915 A PCC implementation SHOULD provide a command to show for each LSP 1916 whether it is delegated, and if so, to which PCE. 1918 A PCC implementation SHOULD allow the operator to manually revoke LSP 1919 delegation. 1921 9.5. Requirements on Other Protocols and Functional Components 1923 PCEP protocol extensions defined in this document do not put new 1924 requirements on other protocols. 1926 9.6. Impact on Network Operation 1928 Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP 1929 protocol extensions defined in this document. 1931 Additionally, a PCEP implementation SHOULD allow a limit to be placed 1932 on the number of LSPs delegated to the PcE and on the rate of PCUpd 1933 and PCRpt messages sent by a PCEP speaker and processed from a peer. 1934 It SHOULD also allow sending a notification when a rate threshold is 1935 reached. 1937 A PCC implementation SHOULD allow a limit to be placed on the rate of 1938 LSP Updates to the same LSP to avoid signaling overload discussed in 1939 Section 10.3. 1941 10. Security Considerations 1943 10.1. Vulnerability 1945 This document defines extensions to PCEP to enable stateful PCEs. 1946 The nature of these extensions and the delegation of path control to 1947 PCEs results in more information being available for a hypothetical 1948 adversary and a number of additional attack surfaces which must be 1949 protected. 1951 The security provisions described in [RFC5440] remain applicable to 1952 these extensions. However, because the protocol modifications 1953 outlined in this document allow the PCE to control path computation 1954 timing and sequence, the PCE defense mechanisms described in 1955 [RFC5440] section 7.2 are also now applicable to PCC security. 1957 As a general precaution, it is RECOMMENDED that these PCEP extensions 1958 only be activated on authenticated and encrypted sessions across PCEs 1959 and PCCs belonging to the same administrative authority. 1961 The following sections identify specific security concerns that may 1962 result from the PCEP extensions outlined in this document along with 1963 recommended mechanisms to protect PCEP infrastructure against related 1964 attacks. 1966 10.2. LSP State Snooping 1968 The stateful nature of this extension explicitly requires LSP status 1969 updates to be sent from PCC to PCE. While this gives the PCE the 1970 ability to provide more optimal computations to the PCC, it also 1971 provides an adversary with the opportunity to eavesdrop on decisions 1972 made by network systems external to PCE. This is especially true if 1973 the PCC delegates LSPs to multiple PCEs simultaneously. 1975 Adversaries may gain access to this information by eavesdropping on 1976 unsecured PCEP sessions, and might then use this information in 1977 various ways to target or optimize attacks on network infrastructure. 1978 For example by flexibly countering anti-DDoS measures being taken to 1979 protect the network, or by determining choke points in the network 1980 where the greatest harm might be caused. 1982 PCC implementations which allow concurrent connections to multiple 1983 PCEs SHOULD allow the operator to group the PCEs by administrative 1984 domains and they MUST NOT advertise LSP existence and state to a PCE 1985 if the LSP is delegated to a PCE in a different group. 1987 10.3. Malicious PCE 1989 The LSP delegation mechanism described in this document allows a PCC 1990 to grant effective control of an LSP to the PCE for the duration of a 1991 PCEP session. While this enables PCE control of the timing and 1992 sequence of path computations within and across PCEP sessions, it 1993 also introduces a new attack vector: an attacker may flood the PCC 1994 with PCUpd messages at a rate which exceeds either the PCC's ability 1995 to process them or the network's ability to signal the changes, 1996 either by spoofing messages or by compromising the PCE itself. 1998 A PCC is free to revoke an LSP delegation at any time without needing 1999 any justification. A defending PCC can do this by enqueueing the 2000 appropriate PCRpt message. As soon as that message is enqueued in 2001 the session, the PCC is free to drop any incoming PCUpd messages 2002 without additional processing. 2004 10.4. Malicious PCC 2006 A stateful session also result in increased attack surface by placing 2007 a requirement for the PCE to keep an LSP state replica for each PCC. 2008 It is RECOMMENDED that PCE implementations provide a limit on 2009 resources a single PCC can occupy. A PCE implementing such a limit 2010 MUST send a PCErr message with error-type 19 (invalid operation) and 2011 error-value 4 (indicating resource limit exceeded) upon receiving an 2012 LSP state report causing it to exceed this threshold. 2014 Delegation of LSPs can create further strain on PCE resources and a 2015 PCE implementation MAY preemptively give back delegations if it finds 2016 itself lacking the resources needed to effectively manage the 2017 delegation. Since the delegation state is ultimately controlled by 2018 the PCC, PCE implementations SHOULD provide throttling mechanisms to 2019 prevent strain created by flaps of either a PCEP session or an LSP 2020 delegation. 2022 11. Acknowledgements 2024 We would like to thank Adrian Farrel, Cyril Margaria and Ramon 2025 Casellas for their contributions to this document. 2027 We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, 2028 Paul Schultz and Raveendra Torvi for their comments and suggestions. 2029 Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Ramon 2030 Casellas, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin 2031 Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin 2032 Sampath, Calvin Ying and Xian Zhang for helpful comments and 2033 discussions. 2035 12. References 2037 12.1. Normative References 2039 [I-D.ietf-pce-gmpls-pcep-extensions] 2040 Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for 2041 GMPLS", draft-ietf-pce-gmpls-pcep-extensions-09 (work in 2042 progress), February 2014. 2044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2045 Requirement Levels", BCP 14, RFC 2119, March 1997. 2047 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2048 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2049 Functional Specification", RFC 2205, September 1997. 2051 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2052 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2053 Tunnels", RFC 3209, December 2001. 2055 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2056 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2057 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2059 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 2060 "OSPF Protocol Extensions for Path Computation Element 2061 (PCE) Discovery", RFC 5088, January 2008. 2063 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 2064 "IS-IS Protocol Extensions for Path Computation Element 2065 (PCE) Discovery", RFC 5089, January 2008. 2067 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2068 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2069 May 2008. 2071 [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", 2072 RFC 5284, August 2008. 2074 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 2075 (PCE) Communication Protocol (PCEP)", RFC 5440, March 2076 2009. 2078 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 2079 Used to Form Encoding Rules in Various Routing Protocol 2080 Specifications", RFC 5511, April 2009. 2082 12.2. Informative References 2084 [I-D.ietf-pce-stateful-pce-app] 2085 Zhang, X. and I. Minei, "Applicability of a Stateful Path 2086 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 2087 app-02 (work in progress), June 2014. 2089 [I-D.minei-pce-stateful-sync-optimizations] 2090 Crabbe, E., Medved, J., Minei, I., Varga, R., Zhang, X., 2091 and D. Dhody, "Optimizations of Label Switched Path State 2092 Synchronization Procedures for a Stateful PCE", draft- 2093 minei-pce-stateful-sync-optimizations-02 (work in 2094 progress), March 2014. 2096 [I-D.sivabalan-pce-disco-stateful] 2097 Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions 2098 for Stateful PCE Discovery", draft-sivabalan-pce-disco- 2099 stateful-03 (work in progress), January 2014. 2101 [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE 2102 LSP Path Computation using Preemption", Global Information 2103 Infrastructure Symposium, July 2007. 2105 [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear 2106 programming algorithm for balancing the max-min fairness 2107 and throughput objectives in traffic engineering", 2108 INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012. 2110 [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network 2111 Recovery: Protection and Restoration of Optical, SONET- 2112 SDH, IP, and MPLS", The Morgan Kaufmann Series in 2113 Networking, June 2004. 2115 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 2116 McManus, "Requirements for Traffic Engineering Over MPLS", 2117 RFC 2702, September 1999. 2119 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2120 Label Switching Architecture", RFC 3031, January 2001. 2122 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 2123 Christian, B., and W. Lai, "Applicability Statement for 2124 Traffic Engineering with MPLS", RFC 3346, August 2002. 2126 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 2127 (TE) Extensions to OSPF Version 2", RFC 3630, September 2128 2003. 2130 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2131 Element (PCE)-Based Architecture", RFC 4655, August 2006. 2133 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 2134 Communication Protocol Generic Requirements", RFC 4657, 2135 September 2006. 2137 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 2138 Engineering", RFC 5305, October 2008. 2140 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 2141 "Policy-Enabled Path Computation Framework", RFC 5394, 2142 December 2008. 2144 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 2145 Computation Element Communication Protocol (PCEP) 2146 Requirements and Protocol Extensions in Support of Global 2147 Concurrent Optimization", RFC 5557, July 2009. 2149 Authors' Addresses 2151 Edward Crabbe 2152 Google, Inc. 2153 1600 Amphitheatre Parkway 2154 Mountain View, CA 94043 2155 US 2157 Email: edc@google.com 2159 Ina Minei 2160 Google, Inc. 2161 1600 Amphitheatre Parkway 2162 Mountain View, CA 94043 2163 US 2165 Email: inaminei@google.com 2167 Jan Medved 2168 Cisco Systems, Inc. 2169 170 West Tasman Dr. 2170 San Jose, CA 95134 2171 US 2173 Email: jmedved@cisco.com 2175 Robert Varga 2176 Pantheon Technologies SRO 2177 Mlynske Nivy 56 2178 Bratislava 821 05 2179 Slovakia 2181 Email: robert.varga@pantheon.sk