idnits 2.17.1 draft-crabbe-pce-pce-initiated-lsp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-pce-stateful-pce]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 10, 2013) is 4024 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 263, but not defined == Unused Reference: 'RFC2205' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC5089' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC3346' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC5557' is defined on line 549, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-03 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Crabbe 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track I. Minei 5 Expires: October 12, 2013 Juniper Networks, Inc. 6 S. Sivabalan 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 April 10, 2013 12 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 13 draft-crabbe-pce-pce-initiated-lsp-01 15 Abstract 17 The Path Computation Element Communication Protocol (PCEP) provides 18 mechanisms for Path Computation Elements (PCEs) to perform path 19 computations in response to Path Computation Clients (PCCs) requests. 21 The extensions described in [I-D.ietf-pce-stateful-pce] provide 22 stateful control of Multiprotocol Label Switching (MPLS) Traffic 23 Engineering Label Switched Paths (TE LSP) via PCEP, for a model where 24 the PCC delegates control over one or more locally configured LSPs to 25 the PCE. This document describes the creation and deletion of PCE- 26 initiated LSPs under the stateful PCE model. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 12, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Operation overview . . . . . . . . . . . . . . . . . . . . 5 72 4. Support of PCE-initiated LSPs . . . . . . . . . . . . . . . . 6 73 4.1. Stateful PCE Capability TLV . . . . . . . . . . . . . . . 6 74 5. PCE-initiated LSP creation . . . . . . . . . . . . . . . . . . 7 75 5.1. The LSP Create Message . . . . . . . . . . . . . . . . . . 7 76 6. LSP delegation and cleanup . . . . . . . . . . . . . . . . . . 9 77 6.1. LSP delegation procedures . . . . . . . . . . . . . . . . 9 78 6.2. LSP cleanup procedures . . . . . . . . . . . . . . . . . . 9 79 6.2.1. LSP-CLEANUP TLV . . . . . . . . . . . . . . . . . . . 10 80 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 11 82 7.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 11 83 7.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 11 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 8.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 11 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 [RFC5440] describes the Path Computation Element Protocol PCEP. PCEP 95 defines the communication between a Path Computation Client (PCC) and 96 a Path Control Element (PCE), or between PCE and PCE, enabling 97 computation of Multiprotocol Label Switching (MPLS) for Traffic 98 Engineering Label Switched Path (TE LSP) characteristics. 100 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 101 extensions to PCEP to enable stateful control of TE LSPs between and 102 across PCEP sessions in compliance with [RFC4657]. It includes 103 mechanisms to effect LSP state synchronization between PCCs and PCEs, 104 delegation of control of LSPs to PCEs, and PCE control of timing and 105 sequence of path computations within and across PCEP sessions and 106 focuses on a model where LSPs are configured on the PCC and control 107 over them is delegated to the PCE. 109 This document describes the setup and teardown of PCE-initiated LSPs 110 under the stateful PCE model, without the need for local 111 configuration on the PCC, thus allowing for a dynamic network that is 112 centrally controlled and deployed. 114 2. Terminology 116 This document uses the following terms defined in [RFC5440]: PCC, 117 PCE, PCEP Peer. 119 This document uses the following terms defined in 120 [I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Delegation 121 Timeout Interval, LSP State Report, LSP Update Request. 123 The following terms are defined in this document: 125 PCE-initiated LSP: LSP that is instantiated as a result of a request 126 from the PCE. 128 LSP cleanup timer: PCE-defined timer for cleanup of PCE-initiated 129 LSPs that are no longer delegated to a PCE. 131 The message formats in this document are specified using Routing 132 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 134 3. Architectural Overview 135 3.1. Motivation 137 [I-D.ietf-pce-stateful-pce] provides stateful control over LSPs that 138 are locally configured on the PCC. This model relies on the LER 139 taking an active role in delegating locally configured LSPs to the 140 PCE, and is well suited in environments where the LSP placement is 141 fairly static. However, in environments where the LSP placement 142 needs to change in response to application demands, it is useful to 143 support dynamic creation and tear down of LSPs. The ability for a 144 PCE to trigger the creation of LSPs on demand can make possible agile 145 software-driven network operation, and can be seamlessly integrated 146 into a controller-based network architecture, where intelligence in 147 the controller can determine when and where to set up paths. 149 A possible use case is one of a software-driven network, where 150 applications request network resources and paths from the network 151 infrastructure. For example, an application can request a path with 152 certain constraints between two LSRs by contacting the PCE. The PCE 153 can compute a path satisfying the constraints, and instruct the head 154 end LSR to create and signal it. When the path is no longer required 155 by the application, the PCE can request its teardown. 157 Another use case is that of demand engineering, where a PCE with 158 visibility into both the network state and the demand matrix can 159 anticipate and optimize how traffic is distributed across the 160 infrastructure. Such optimizations may require creating new paths 161 across the infrastructure. 163 3.2. Operation overview 165 A PCC indicates its ability to support PCE provisioned dynamic LSPs 166 during the PCEP Initialization Phase via a new flag in the STATEFUL- 167 PCE-CAPABILITY TLV (see details in Section 4.1). 169 The decision when to create a PCE-initiated LSP is out of the scope 170 of this document. To instantiate an LSP, the PCE sends a new 171 message, the LSP Create Request (PCCreate) message to the PCC. The 172 LSP Create Request MUST include the END-POINTS and LSPA objects, and 173 the LSPA object MUST include the SYMBOLIC-PATH-NAME TLV. The PCC 174 creates the LSP using the attributes communicated by the PCE, and 175 local values for the unspecified parameters. It assigns a unique 176 LSP-ID for the LSP and automatically delegates the LSP to the PCE. 177 It then generates an LSP State Report (PCRpt) for the LSP, carrying 178 the LSP-ID and the delegation bit. The PCE may update the attributes 179 of the LSP via subsequent PCUpd messages. 181 Subsequent LSP State Report and LSP Update Request for the LSP will 182 carry the PCC-assigned LSP-ID, which uniquely identifies the LSP. 184 The LSPA Object included in these messages MUST carry the SYMBOLIC- 185 PATH-NAME TLV which will be used to correlate between the PCC- 186 assigned LSP-ID and the LSP. See details in Section 5. 188 Removal of PCE-initiated LSPs is done by the PCE by setting the R 189 flag in the LSP Object in the PCUpd message. Upon receiving the 190 PCUpd message with the R Flag set, the PCC deletes the LSP. See 191 details in Section 5. 193 Once instantiated, a PCRpt is generated for the LSP, with the 194 delegation bit set. After this, the delegation procedures for PCE- 195 initiated LSPs are the same as for PCC initiated LSPs. Upon session 196 failure, PCE-initiated LSPs are not immediately removed, in order to 197 avoid LSP flap and service interruption. However, to allow for 198 network cleanup without manual intervention, such "orphan" PCE- 199 initiated LSPs must be either adopted by a different PCE or cleaned 200 up within a time interval. This time is negotiated between PCE and 201 PCC at session initialization time. See details in Section 6. 203 4. Support of PCE-initiated LSPs 205 A PCC indicates its ability to support PCE provisioned dynamic LSPs 206 during the PCEP Initialization Phase. The Open Object in the Open 207 message contains the "Stateful PCE Capability" TLV, defined in 208 [I-D.ietf-pce-stateful-pce]. 210 A new flag, the I (LSP-INSTANTIATION-CAPABILITY) flag is introduced 211 to indicate support for instantiation of PCE-initiated LSPs. A PCE 212 wishing to initiate LSPs, can do so only for PCCs that advertised 213 this capability and a PCC will follow the procedures described in 214 this document only on sessions where the PCE advertised the I flag. 215 A PCE or PCC that advertise support of LSP initiation MUST also 216 advertise a cleanup time for the removal of such LSPs. The cleanup 217 time is advertised via a new TLV in the Open Object, the LSP-CLEANUP 218 TLV, discussed in Section 6, and the value is negotiated to the lower 219 one advertised on a session. 221 4.1. Stateful PCE Capability TLV 223 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 224 following figure: 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type=16 | Length=4 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Flags |I|S|U| 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 234 Figure 1: STATEFUL-PCE-CAPABILITY TLV format 236 The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it 237 has a fixed length of 4 octets. 239 The value comprises a single field - Flags (32 bits). The U and S 240 bits are defined in [I-D.ietf-pce-stateful-pce]. 242 If set to 1 by a PCC, the I Flag indicates that the PCC allows 243 instantiation of an LSP by a PCE. If set to 1 by a PCE, the I flag 244 indicates that the PCE will attempt to instantiate LSPs. The LSP- 245 INSTANTIATION-CAPABILITY flag must be set by both PCC and PCE in 246 order to support PCE-initiated LSP instantiation. 248 Unassigned bits are considered reserved. They MUST be set to 0 on 249 transmission and MUST be ignored on receipt. 251 5. PCE-initiated LSP creation 253 To create a PCE-initiated LSP, a PCE sends a PCCreate message to a 254 PCC, which include a set of objects and TLVs describing the LSP to be 255 instantiated. The message format, the objects and TLVs are discussed 256 separately below. 258 5.1. The LSP Create Message 260 A Path Computation LSP Create message (also referred to as PCCreate 261 message) is a PCEP message sent by a PCE to a PCC to trigger an LSP 262 instantiation. The Message-Type field of the PCEP common header for 263 the PCCreate message is set to [TBD]. 265 The PCCreate message MUST include the END-POINTS and the LSPA 266 objects. In the LSPA object, it MUST include the SYMBOLIC-PATH-NAME 267 TLV for the LSP. The PCCreate message MAY include other attributes 268 for the LSP. If specified, the PCC MUST use them for the LSP 269 instantiation, otherwise it MUST use its locally configured values. 270 The error messages will be specified in a future version of this 271 document. 273 The format of a PCCreate message is as follows: 275 ::= 276 277 Where: 279 ::= [] 281 ::= 282 283 [] 284 [] 285 [] 287 Where: 289 ::=[] 291 The END-POINTS Object contains the source and destination addresses 292 for provisioning the PCE-initiated LSP. If the END-POINTS Object is 293 missing, the PCC MUST send a PCErr message with Error-type=6 294 (Mandatory Object missing) and Error-value=3 (END-POINTS Object 295 missing). 297 The LSPA Object MUST include the SYMBOLIC-PATH-NAME TLV, which will 298 be used to correlate between the PCC-assigned LSP-ID and the LSP. If 299 the TLV is missing, the PCC MUST send a PCErr message with Error- 300 type=6(Mandatory object missing) and Error-value=14 (SYMBOLIC-PATH- 301 NAME TLV missing). The symbolic name used for provisioning PCE- 302 initiated LSPs must not have conflict with the LSP name of any 303 existing LSP in the PCC. (Existing LSPs may be either statically 304 configured, or initiated by another PCE). If there is conflict with 305 the LSP name, the PCC MUST send a PCErr message with Error-type=23 306 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). 307 The only exception to this rule is for LSPs for which the LSP-cleanup 308 timer is running (see Section 6). 310 PCE-initiated removal of a PCE-initiated LSP is done by setting the R 311 (remove) flag in the LSP Object in the PCUpd request from the PCE. 312 The definition of the R bit is updated as follows: 314 R (Remove - 1 bit): On PCRpt messages the R Flag indicates that the 315 LSP has been removed from the PCC. Upon receiving a PCRpt message 316 with the R Flag set to 1, the PCE SHOULD remove all state related to 317 the LSP from its database. In PCUpd messages the R flag indicates 318 that the PCE wishes to disable the LSP. Upon receiving the PCUpd 319 message with the R Flag set for a PCE-initiated LSP, the PCC tears 320 down the LSP and removes its state. 322 A PCC SHOULD be able to place a limit on either the number of LSPs or 323 the percentage of resources that are allocated to honor PCE-initiated 324 LSP requests. As soon as that limit is reached, the PCC MUST send a 325 PCErr message of type 19 (Invalid Operation) and value TBD "PCE- 326 initiated limit reached" and is free to drop any incoming PCCreate 327 messages without additional processing. 329 A PCC SHOULD relay to the PCE errors it encounters in the setup of 330 PCE-initiated LSP. The error codes and error processing will be 331 detailed in a future version of this document. 333 6. LSP delegation and cleanup 335 6.1. LSP delegation procedures 337 PCE-initiated LSPs are automatically delegated by the PCC to the PCE 338 upon instantiation. The PCC MUST delegate the LSP to the PCE by 339 setting the delegation bit to 1 in the PCRpt that includes the 340 assigned LSP-Id. All subsequent messages from the PCC must have the 341 delegation bit set to 1. The PCC cannot revoke the delegation for 342 PCE-initiated LSPs for an active PCEP session. Sending a PCRpt 343 message with the delegation bit set to 0 results in a PCErr message 344 of type 19 (Invalid Operation) and value TBD "Delegation for PCE- 345 initiated LSP cannot be revoked". 347 A PCE MAY return a delegation to the PCC, to allow for LSP transfer 348 between PCEs. Doing so MUST trigger the LSP cleanup timer described 349 in Section 6.2. 351 Control over PCE-initiated LSPs reverts to the PCC at the expiration 352 of the delegation timeout. To obtain control of a PCE-initiated LSP, 353 a PCE (either the original or one of its backups) sends a PCCreate 354 message specifying the endpoints and symbolic name (the same process 355 used when initiating an LSP from the PCE). See more in the next 356 section. 358 6.2. LSP cleanup procedures 360 The LSP cleanup timer ensures that a PCE crash does not result in 361 automatic and immediate disruption for the services using PCE- 362 initiated LSPs. PCE-initiated LSPs are not be removed immediately 363 upon PCE failure. Instead, they are cleaned up on the expiration of 364 this timer. This allows for network cleanup without manual 365 intervention. The LSP cleanup timer is advertised in the session 366 open message via a mandatory TLV for sessions where PCE-initiated 367 LSPs are supported. The timer is started upon PCEP session failure 368 and is stopped when the LSP is delegated to a PCE. Both PCE and PCC 369 advertise a value for this timer, and the timer value is negotiated 370 to the lower value of the two. 372 6.2.1. LSP-CLEANUP TLV 374 The LSP-CLEANUP TLV is advertised in the Open Object and is mandatory 375 when the I flag is set in the STATEFUL-PCE-CAPABILITY TLV. The LSP- 376 CLEANUP TLV contains the time in seconds that the PCC has to wait 377 before cleaning up any PCE-initiated LSPs belonging to a particular 378 PCEP session when a PCEP session terminates. Both PCE and PCC 379 advertise a value for the cleanup time, and the cleanup timer is set 380 to the lower of the two. The timer is triggered on PCEP session 381 failure and reset when the LSP is delegated to a PCE. 383 Failure to include the mandatory LSP-CLEANUP TLV in the Open Object 384 when the I flag is set MUST trigger PCErr of type 6 (Mandatory Object 385 missing) and value 13 (LSP-CLEANUP TLV missing). 387 The format of the LSP-CLEANUP TLV is shown in the following figure: 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type=TBD | Length=4 | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | LSP cleanup timeout value | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 397 Figure 2: LSP-CLEANUP TLV format 399 The type of the TLV is TBD and it has a fixed length of 4 octets. 401 The value comprises a single field, the LSP cleanup timeout value. 403 The time in seconds to wait before cleaning up PCE-initiated LSPs. 404 Zero means immediate removal. The value OXFFFFFFFF is reserved. 406 A PCE may take control of the dynamic LSPs for which the LSP cleanup 407 timer is running by sending an PCCreate request for the LSP. In this 408 case, the "Bad Symbolic Path Name" error MUST NOT be generated, the 409 LSP MUST be delegated and the cleanup timer MUST be stopped. 411 7. IANA considerations 413 7.1. PCEP Messages 415 This document defines the following new PCEP messages: 417 Value Meaning Reference 418 12 Create This document 420 7.2. PCEP-Error Object 422 This document defines new Error-Type and Error-Value for the 423 following new error conditions: 425 Error-Type Meaning 426 6 Mandatory Object missing 427 Error-value=13: LSP cleanup TLV missing 428 Error-value=14: SYMBOLIC-PATH-NAME TLV missing 429 19 Invalid operation 430 Error-value=3: PCE-initiated LSP limit reached 431 Error-value=4: Delegation for PCE-initiated LSP cannot 432 be revoked 433 23 Bad parameter value 434 Error-value=1: SYMBOLIC-PATH-NAME in use 436 7.3. PCEP TLV Type Indicators 438 This document defines the following new PCEP TLVs: 440 Value Meaning Reference 441 26 LSP cleanup This document 443 8. Security Considerations 445 The security considerations described in [I-D.ietf-pce-stateful-pce] 446 apply to the extensions described in this document. Additional 447 considerations related to a malicious PCE are introduced. 449 8.1. Malicious PCE 451 The LSP instantiation mechanism described in this document allows a 452 PCE to generate state on the PCC and throughout the network. As a 453 result, it introduces a new attack vector: an attacker may flood the 454 PCC with LSP instantiation requests and consume network and LSR 455 resources, either by spoofing messages or by compromising the PCE 456 itself. 458 A PCC can protect itself from such an attack by imposing a limit on 459 either the number of LSPs or the percentage of resources that are 460 allocated to honor PCE-initiated LSP requests. As soon as that limit 461 is reached, the PCC MUST send a PCErr message of type 19 (Invalid 462 Operation) and value 3 "PCE-initiated LSP limit reached" and is free 463 to drop any incoming PCCreate messages without additional processing. 465 Rapid flaps triggered by the PCE can also be an attack vector. This 466 will be discussed in a future version of this document. 468 9. Acknowledgements 470 We would like to thank Jan Medved, Ambrose Kwong and Raveendra Trovi 471 for their contributions to this document. 473 10. References 475 10.1. Normative References 477 [I-D.ietf-pce-stateful-pce] 478 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 479 Extensions for Stateful PCE", 480 draft-ietf-pce-stateful-pce-03 (work in progress), 481 March 2013. 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 487 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 488 Functional Specification", RFC 2205, September 1997. 490 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 491 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 492 Tunnels", RFC 3209, December 2001. 494 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 495 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 496 May 2005. 498 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 499 "OSPF Protocol Extensions for Path Computation Element 500 (PCE) Discovery", RFC 5088, January 2008. 502 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 503 "IS-IS Protocol Extensions for Path Computation Element 504 (PCE) Discovery", RFC 5089, January 2008. 506 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 507 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 508 May 2008. 510 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 511 (PCE) Communication Protocol (PCEP)", RFC 5440, 512 March 2009. 514 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 515 Used to Form Encoding Rules in Various Routing Protocol 516 Specifications", RFC 5511, April 2009. 518 10.2. Informative References 520 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 521 McManus, "Requirements for Traffic Engineering Over MPLS", 522 RFC 2702, September 1999. 524 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 525 Label Switching Architecture", RFC 3031, January 2001. 527 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 528 Christian, B., and W. Lai, "Applicability Statement for 529 Traffic Engineering with MPLS", RFC 3346, August 2002. 531 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 532 (TE) Extensions to OSPF Version 2", RFC 3630, 533 September 2003. 535 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 536 Element (PCE)-Based Architecture", RFC 4655, August 2006. 538 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 539 Communication Protocol Generic Requirements", RFC 4657, 540 September 2006. 542 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 543 Engineering", RFC 5305, October 2008. 545 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 546 "Policy-Enabled Path Computation Framework", RFC 5394, 547 December 2008. 549 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 550 Computation Element Communication Protocol (PCEP) 551 Requirements and Protocol Extensions in Support of Global 552 Concurrent Optimization", RFC 5557, July 2009. 554 Authors' Addresses 556 Edward Crabbe 557 Google, Inc. 558 1600 Amphitheatre Parkway 559 Mountain View, CA 94043 560 US 562 Email: edc@google.com 564 Ina Minei 565 Juniper Networks, Inc. 566 1194 N. Mathilda Ave. 567 Sunnyvale, CA 94089 568 US 570 Email: ina@juniper.net 572 Siva Sivabalan 573 Cisco Systems, Inc. 574 170 West Tasman Dr. 575 San Jose, CA 95134 576 US 578 Email: msiva@cisco.com 580 Robert Varga 581 Pantheon Technologies SRO 582 Mlynske Nivy 56 583 Bratislava 821 05 584 Slovakia 586 Email: robert.varga@pantheon.sk