idnits 2.17.1 draft-crabbe-pce-pce-initiated-lsp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (October 9, 2012) is 4218 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 262, but not defined == Unused Reference: 'RFC2205' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 477, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 481, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC5089' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC3346' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC5557' is defined on line 536, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-01 ** 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: April 12, 2013 Juniper Networks, Inc. 6 S. Sivabalan 7 Cisco Systems, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 October 9, 2012 12 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 13 draft-crabbe-pce-pce-initiated-lsp-00 15 Abstract 17 The Path Computation Element Communication Protocol (PCEP) provides 18 mechanisms for Path Computation Elements (PCEs) to perform path 19 computations in response to Path Computation Clients (PCCs) requests. 21 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 April 12, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 10 81 7.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 11 82 7.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 11 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 8.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 11 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 [RFC5440] describes the Path Computation Element Protocol PCEP. PCEP 94 defines the communication between a Path Computation Client (PCC) and 95 a Path Control Element (PCE), or between PCE and PCE, enabling 96 computation of Multiprotocol Label Switching (MPLS) for Traffic 97 Engineering Label Switched Path (TE LSP) characteristics. 99 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 100 extensions to PCEP to enable stateful control of TE LSPs between and 101 across PCEP sessions in compliance with [RFC4657]. It includes 102 mechanisms to effect LSP state synchronization between PCCs and PCEs, 103 delegation of control of LSPs to PCEs, and PCE control of timing and 104 sequence of path computations within and across PCEP sessions and 105 focuses on a model where LSPs are configured on the PCC and control 106 over them is delegated to the PCE. 108 This document describes the setup and teardown of PCE-initiated LSPs 109 under the stateful PCE model, without the need for local 110 configuration on the PCC, thus allowing for a dynamic network that is 111 centrally controlled and deployed. 113 2. Terminology 115 This document uses the following terms defined in [RFC5440]: PCC, 116 PCE, PCEP Peer. 118 This document uses the following terms defined in 119 [I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Delegation 120 Timeout Interval, LSP State Report, LSP Update Request. 122 The following terms are defined in this document: 124 PCE-initiated LSP: LSP that is instantiated as a result of a request 125 from the PCE. 127 LSP cleanup timer: PCE-defined timer for cleanup of PCE-initiated 128 LSPs that are no longer delegated to a PCE. 130 The message formats in this document are specified using Routing 131 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 133 3. Architectural Overview 134 3.1. Motivation 136 [I-D.ietf-pce-stateful-pce] provides stateful control over LSPs that 137 are locally configured on the PCC. This model relies on the LER 138 taking an active role in delegating locally configured LSPs to the 139 PCE, and is well suited in environments where the LSP placement is 140 fairly static. However, in environments where the LSP placement 141 needs to change in response to application demands, it is useful to 142 support dynamic creation and tear down of LSPs. The ability for a 143 PCE to trigger the creation of LSPs on demand can make possible agile 144 software-driven network operation, and can be seamlessly integrated 145 into a controller-based network architecture, where intelligence in 146 the controller can determine when and where to set up paths. 148 A possible use case is one of a software-driven network, where 149 applications request network resources and paths from the network 150 infrastructure. For example, an application can request a path with 151 certain constraints between two LSRs by contacting the PCE. The PCE 152 can compute a path satisfying the constraints, and instruct the head 153 end LSR to create and signal it. When the path is no longer required 154 by the application, the PCE can request its teardown. 156 Another use case is that of demand engineering, where a PCE with 157 visibility into both the network state and the demand matrix can 158 anticipate and optimize how traffic is distributed across the 159 infrastructure. Such optimizations may require creating new pahts 160 across the infrastructure. 162 3.2. Operation overview 164 A PCC indicates its ability to support PCE provisioned dynamic LSPs 165 during the PCEP Initialization Phase via a new flag in the STATEFUL- 166 PCE-CAPABILITY TLV (see details in Section 4.1). 168 The decision when to create a PCE-initiated LSP is out of the scope 169 of this document. To instantiate an LSP, the PCE sends a new 170 message, the LSP Create Request (PCCreate) message to the PCC. The 171 LSP Create Request MUST include the END-POINTS and LSPA objects, and 172 the LSPA object MUST include the SYMBOLIC-PATH-NAME TLV. The PCC 173 creates the LSP using the attributes communicated by the PCE, and 174 local values for the unspecified parameters. It assigns a unique 175 LSP-ID for the LSP and automatically delegates the LSP to the PCE. 176 It then generates an LSP State Report (PCRpt) for the LSP, carrying 177 the LSP-ID and the delegation bit. The PCE may update the attributes 178 of the LSP via subsequent PCUpd messages. 180 Subsequent LSP State Report and LSP Update Request for the LSP will 181 carry the PCC-assigned LSP-ID, which uniquely identifies the LSP. 183 The LSPA Object included in these messages MUST carry the SYMBOLIC- 184 PATH-NAME TLV which will be used to correlate between the PCC- 185 assigned LSP-ID and the LSP. See details in Section 5. 187 Removal of PCE-initiated LSPs is done by the PCE by setting the R 188 flag in the LSP Object in the PCUpd message. Upon receiving the 189 PCUpd message with the R Flag set, the PCC deletes the LSP. See 190 details in Section 5. 192 Once instantiated, a PCRpt is generated for the LSP, with the 193 delegation bit set. After this, the delegation procedures for PCE- 194 initiated LSPs are the same as for PCC initiated LSPs. Upon session 195 failure, PCE-initiated LSPs are not immediately removed, in order to 196 avoid LSP flap and service interruption. However, to allow for 197 network cleanup without manual intervention, such "orphan" PCE- 198 initiated LSPs must be either adopted by a different PCE or cleaned 199 up within a time interval. This time is negotiated between PCE and 200 PCC at session initialization time. See details in Section 6. 202 4. Support of PCE-initiated LSPs 204 A PCC indicates its ability to support PCE provisioned dynamic LSPs 205 during the PCEP Initialization Phase. The Open Object in the Open 206 message contains the "Stateful PCE Capability" TLV, defined in 207 [I-D.ietf-pce-stateful-pce]. 209 A new flag, the I (LSP-INSTANTIATION-CAPABILITY) flag is introduced 210 to indicate support for instantiation of PCE-initiated LSPs. A PCE 211 wishing to initiate LSPs, can do so only for PCCs that advertised 212 this capability and a PCC will follow the procedures described in 213 this document only on sessions where the PCE advertised the I flag. 214 A PCE or PCC that advertise support of LSP initiation MUST also 215 advertise a cleanup time for the removal of such LSPs. The cleanup 216 time is advertised via a new TLV in the Open Object, the LSP-CLEANUP 217 TLV, discussed in Section 6, and the value is negotiated to the lower 218 one advertised on a session. 220 4.1. Stateful PCE Capability TLV 222 The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the 223 following figure: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type=16 | Length=4 | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Flags |I|S|U| 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 233 Figure 1: STATEFUL-PCE-CAPABILITY TLV format 235 The type of the TLV is defined in [I-D.ietf-pce-stateful-pce] and it 236 has a fixed length of 4 octets. 238 The value comprises a single field - Flags (32 bits). The U and S 239 bits are defined in [I-D.ietf-pce-stateful-pce]. 241 If set to 1 by a PCC, the I Flag indicates that the PCC allows 242 instantiation of an LSP by a PCE. If set to 1 by a PCE, the I flag 243 indicates that the PCE will attempt to instantiate LSPs. The LSP- 244 INSTANTIATION-CAPABILITY flag must be set by both PCC and PCE in 245 order to support PCE-initiated LSP instantiation. 247 Unassigned bits are considered reserved. They MUST be set to 0 on 248 transmission and MUST be ignored on receipt. 250 5. PCE-initiated LSP creation 252 To create a PCE-initiated LSP, a PCE sends a PCCreate message to a 253 PCC, which include a set of objects and TLVs descriing the LSP to be 254 instantiated. The message format, the objects and TLVs are discussed 255 separately below. 257 5.1. The LSP Create Message 259 A Path Computation LSP Create message (also referred to as PCCreate 260 message) is a PCEP message sent by a PCE to a PCC to trigger an LSP 261 instantiation. The Message-Type field of the PCEP common header for 262 the PCCreate message is set to [TBD]. 264 The PCCreate message MUST include the END-POINTS and the LSPA 265 objects. In the LSPA object, it MUST include the SYMBOLIC-PATH-NAME 266 TLV for the LSP. The PCCreate message MAY include other attributes 267 for the LSP. If specified, the PCC MUST use them for the LSP 268 instantiation, otherwise it MUST use its locally configured values. 269 The error messages will be specified in a future version of this 270 document. 272 The format of a PCCreate message is as follows: 274 ::= 275 276 Where: 278 ::= [] 280 ::= 281 282 [] 283 [] 284 [] 286 Where: 288 ::=[] 290 The END-POINTS Object contains the source and destination addresses 291 for provisioning the PCE-initiated LSP. If the END-POINTS Object is 292 missing, the PCC MUST send a PCErr message with Error-type=6 293 (Mandatory Object missing) and Error-value=3 (END-POINTS Object 294 missing). 296 The LSPA Object MUST include the SYMBOLIC-PATH-NAME TLV, which will 297 be used to correlate between the PCC-assigned LSP-ID and the LSP. 298 The symbolic name used for provisioning PCE-initiated LSPs must not 299 have conflict with the LSP name of any existing LSP in the PCC. 300 (Existing LSPs may be either statically configured, or initiated by 301 another PCE). If there is conflict with the LSP name, the PCC MUST 302 send a PCErr message with Error-type=TBD (Invalid Parameter) and 303 Error-value=TBD (Bad Symbolic Path Name). The only exception to this 304 rule is for LSPs for which the LSP-cleanup timer is running (see 305 Section 6). 307 PCE-initiated removal of a PCE-initiated LSP is done by setting the R 308 (remove) flag in the LSP Object in the PCUpd request from the PCE. 309 The definition of the R bit is updated as follows: 311 R (Remove - 1 bit): On PCRpt messages the R Flag indicates that the 312 LSP has been removed from the PCC. Upon receiving a PCRpt message 313 with the R Flag set to 1, the PCE SHOULD remove all state related to 314 the LSP from its database. In PCUpd messages the R flag indicates 315 that the PCE wishes to disable the LSP. Upon receiving the PCUpd 316 message with the R Flag set for a PCE-initiated LSP, the PCC tears 317 down the LSP and removes its state. 319 A PCC SHOULD be able to place a limit on either the number of LSPs or 320 the percentage of resources that are allocated to honor PCE-initiated 321 LSP requests. As soon as that limit is reached, the PCC MUST send a 322 PCErr message of type 19 (Invalid Operation) and value TBD "PCE- 323 initiated limit reached" and is free to drop any incoming PCUpd 324 messages without additional processing. 326 A PCC SHOULD relay to the PCE errors it encounters in the setup of 327 PCE-initiated LSP. The error codes and error processing will be 328 detailed in a future version of this document. 330 6. LSP delegation and cleanup 332 6.1. LSP delegation procedures 334 PCE-initiated LSPs are automatically delegated by the PCC to the PCE 335 upon instantiation. The PCC MUST delegate the LSP to the PCE by 336 setting the delegation bit to 1 in the PCRpt that includes the 337 assigned LSP-Id. All subsequent messages from the PCC must have the 338 delegation bit set to 1. The PCC cannot revoke the delegation for 339 PCE-initiated LSPs for an active PCEP session. Sending a PCRpt 340 message with the delegation bit set to 0 results in a PCErr message 341 of type 19 (Invalid Operation) and value TBD "Delegation for PCE- 342 initiated LSP cannot be revoked". 344 A PCE MAY return a delegation to the PCC, to allow for LSP transfer 345 between PCEs. Doing so MUST trigger the LSP cleanup timer described 346 in Section 6.2. 348 Control over PCE-initiated LSPs reverts to the PCC at the expiration 349 of the delegation timeout. To obtain control of a PCE-initiated LSP, 350 a PCE (either the original or one of its backups) sends a PCCreate 351 message specifying the endpoints and symbolic name (the same process 352 used when initiating an LSP from the PCE). See more in the next 353 section. 355 6.2. LSP cleanup procedures 357 The LSP cleanup timer ensures that a PCE crash does not result in 358 automatic and immediate disruption for the services using PCE- 359 initiated LSPs. PCE-initiated LSPs are not be removed immediately 360 upon PCE failure. Instead, they are cleaned up on the expiration of 361 this timer. This allows for network cleanup without manual 362 intervention. The LSP cleanup timer is advertised in the session 363 open message via a mandatory TLV for sessions where PCE-initiated 364 LSPs are supported. The timer is started upon PCEP session failure 365 and is stopped when the LSP is delegated to a PCE. Both PCE and PCC 366 advertise a value for this timer, and the timer value is negotiated 367 to the lower value of the two. 369 6.2.1. LSP-CLEANUP TLV 371 The LSP-CLEANUP TLV is advertised in the Open Object and is mandatory 372 when the I flag is set in the STATEFUL-PCE-CAPABILITY TLV. The LSP- 373 CLEANUP TLV contains the time in seconds that the PCC has to wait 374 before cleaning up any PCE-initiated LSPs belonging to a particular 375 PCEP session when a PCEP session terminates. Both PCE and PCC 376 advertise a value for the cleanup time, and the cleanup timer is set 377 to the lower of the two. The timer is triggered on PCEP session 378 failure and reset when the LSP is delegated to a PCE. 380 Failure to include the mandatory LSP-CLEANUP TLV in the Open Object 381 when the I flag is set MUST trigger PCErr of type 6 (Mandatory Object 382 missing) and value TBD (LSP-CLEANUP TLV missing). 384 The format of the LSP-CLEANUP TLV is shown in the following figure: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type=TBD | Length=4 | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | LSP cleanup timeout value | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+ 394 Figure 2: LSP-CLEANUP TLV format 396 The type of the TLV is TBD and it has a fixed length of 4 octets. 398 The value comprises a single field, the LSP cleanup timeout value. 400 The time in seconds to wait before cleaning up PCE-initiated LSPs. 401 Zero means immediate removal. The value OXFFFFFFFF is reserved. 403 A PCE may take control of the dynamic LSPs for which the LSP cleanup 404 timer is running by sending an PCCreate request for the LSP. In this 405 case, the "Bad Symbolic Path Name" error MUST NOT be generated, the 406 LSP MUST be delegated and the cleanup timer MUST be stopped. 408 7. IANA considerations 409 7.1. PCEP-Error Object 411 This document defines new Error-Type and Error-Value for the 412 following new error conditions: 414 Error-Type Meaning 415 6 Mandatory Object missing 416 Error-value=8: LSP cleanup TLV missing 417 19 Invalid operation 418 Error-value=TBD: PCE-initiated LSP limit reached 419 Error-value=TBD: Delegation for PCE-initiated LSP 420 cannot be revoked 422 7.2. PCEP TLV Type Indicators 424 This document defines the following new PCEP TLVs: 426 Value Meaning Reference 427 ??? LSP cleanup This document 429 8. Security Considerations 431 The security considerations described in [I-D.ietf-pce-stateful-pce] 432 apply to the extensions described in this document. Additional 433 considerations related to a malicious PCE are introduced. 435 8.1. Malicious PCE 437 The LSP instantiation mechanism described in this document allows a 438 PCE to generate state on the PCC and throughout the network. As a 439 result, it introduces a new attack vector: an attacker may flood the 440 PCC with LSP instantiation requests and consume network and LSR 441 resources, either by spoofing messages or by compromising the PCE 442 itself. 444 A PCC can protect itself from such an attack by imposing a limit on 445 either the number of LSPs or the percentage of resources that are 446 allocated to honor PCE-initiated LSP requests. As soon as that limit 447 is reached, the PCC MUST send a PCErr message of type 19 (Invalid 448 Operation) and value TBD "PCE-initiated LSP limit reached" (XXX TBD 449 add to the IANA section) and is free to drop any incoming PCUpd 450 messages without additional processing. 452 Rapid flaps triggered by the PCE can also be an attack vector. This 453 will be discussed in a future version of this document. 455 9. Acknowledgements 457 We would like to thank Jan Medved, Ambrose Kwong and Raveendra Trovi 458 for their contributions to this document. 460 10. References 462 10.1. Normative References 464 [I-D.ietf-pce-stateful-pce] 465 Crabbe, E., Medved, J., Varga, R., and I. Minei, "PCEP 466 Extensions for Stateful PCE", 467 draft-ietf-pce-stateful-pce-01 (work in progress), 468 July 2012. 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 474 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 475 Functional Specification", RFC 2205, September 1997. 477 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 478 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 479 Tunnels", RFC 3209, December 2001. 481 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 482 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 483 May 2005. 485 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 486 "OSPF Protocol Extensions for Path Computation Element 487 (PCE) Discovery", RFC 5088, January 2008. 489 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 490 "IS-IS Protocol Extensions for Path Computation Element 491 (PCE) Discovery", RFC 5089, January 2008. 493 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 494 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 495 May 2008. 497 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 498 (PCE) Communication Protocol (PCEP)", RFC 5440, 499 March 2009. 501 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 502 Used to Form Encoding Rules in Various Routing Protocol 503 Specifications", RFC 5511, April 2009. 505 10.2. Informative References 507 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 508 McManus, "Requirements for Traffic Engineering Over MPLS", 509 RFC 2702, September 1999. 511 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 512 Label Switching Architecture", RFC 3031, January 2001. 514 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 515 Christian, B., and W. Lai, "Applicability Statement for 516 Traffic Engineering with MPLS", RFC 3346, August 2002. 518 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 519 (TE) Extensions to OSPF Version 2", RFC 3630, 520 September 2003. 522 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 523 Element (PCE)-Based Architecture", RFC 4655, August 2006. 525 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 526 Communication Protocol Generic Requirements", RFC 4657, 527 September 2006. 529 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 530 Engineering", RFC 5305, October 2008. 532 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 533 "Policy-Enabled Path Computation Framework", RFC 5394, 534 December 2008. 536 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 537 Computation Element Communication Protocol (PCEP) 538 Requirements and Protocol Extensions in Support of Global 539 Concurrent Optimization", RFC 5557, July 2009. 541 Authors' Addresses 543 Edward Crabbe 544 Google, Inc. 545 1600 Amphitheatre Parkway 546 Mountain View, CA 94043 547 US 549 Email: edc@google.com 551 Ina Minei 552 Juniper Networks, Inc. 553 1194 N. Mathilda Ave. 554 Sunnyvale, CA 94089 555 US 557 Email: ina@juniper.net 559 Siva Sivabalan 560 Cisco Systems, Inc. 561 170 West Tasman Dr. 562 San Jose, CA 95134 563 US 565 Email: msiva@cisco.com 567 Robert Varga 568 Pantheon Technologies SRO 569 Mlynske Nivy 56 570 Bratislava 821 05 571 Slovakia 573 Email: robert.varga@pantheon.sk