idnits 2.17.1 draft-ietf-pce-pcep-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2895. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2908. 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 23 instances of too long lines in the document, the longest one being 57 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 2007) is 6281 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) == Unused Reference: 'RFC2205' is defined on line 2711, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-inter-domain-rsvp-te' is defined on line 2743, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4657 ** Downref: Normative reference to an Informational RFC: RFC 4674 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-04 == Outdated reference: A later version (-08) exists of draft-ietf-pce-disco-proto-isis-01 == Outdated reference: A later version (-08) exists of draft-ietf-pce-disco-proto-ospf-01 == Outdated reference: A later version (-15) exists of draft-ietf-pce-inter-layer-req-03 == Outdated reference: A later version (-06) exists of draft-ietf-pce-interas-pcecp-reqs-01 == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-06 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 4420 (Obsoleted by RFC 5420) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems, Inc 3 Intended status: Standards Track JL. Le Roux, Ed. 4 Expires: August 17, 2007 France Telecom 5 February 13, 2007 7 Path Computation Element (PCE) communication Protocol (PCEP) 8 draft-ietf-pce-pcep-06.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 17, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies the Path Computation Element communication 42 Protocol (PCEP) for communications between a Path Computation Client 43 (PCC) and a Path Computation Element (PCE), or between two PCEs. 44 Such interactions include path computation requests and path 45 computation replies as well as notifications of specific states 46 related to the use of a PCE in the context of Multiprotocol Label 47 Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. The 48 PCEP protocol is designed to be flexible and extensible so as to 49 easily allow for the addition of further messages and objects, should 50 further requirements be expressed in the future. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Architectural Protocol Overview (Model) . . . . . . . . . . . 5 64 4.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Architectural Protocol Overview . . . . . . . . . . . . . 6 66 4.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 7 67 4.2.2. Path computation request sent by a PCC to a PCE . . . 8 68 4.2.3. Path computation reply sent by the PCE to a PCC . . . 9 69 4.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 11 70 4.2.5. Error . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2.6. Termination of the PCEP Session . . . . . . . . . . . 13 72 5. Transport protocol . . . . . . . . . . . . . . . . . . . . . . 13 73 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 14 75 6.2. Open message . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.3. Keepalive message . . . . . . . . . . . . . . . . . . . . 16 77 6.4. Path Computation Request (PCReq) message . . . . . . . . . 17 78 6.5. Path Computation Reply (PCRep) message . . . . . . . . . . 18 79 6.6. Notification (PCNtf) message . . . . . . . . . . . . . . . 19 80 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 20 81 6.8. Close message . . . . . . . . . . . . . . . . . . . . . . 20 82 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 21 83 7.1. Common object header . . . . . . . . . . . . . . . . . . . 21 84 7.2. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 22 85 7.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 24 86 7.3.1. Object definition . . . . . . . . . . . . . . . . . . 24 87 7.3.2. Handling of the RP object . . . . . . . . . . . . . . 26 88 7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 26 89 7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 29 90 7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 30 91 7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 31 92 7.8. Explicit Route Object . . . . . . . . . . . . . . . . . . 34 93 7.9. Route Record Object . . . . . . . . . . . . . . . . . . . 34 94 7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 35 95 7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 36 96 7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 37 97 7.12.1. Notion of Dependent and Synchronized path 98 computation requests . . . . . . . . . . . . . . . . . 37 99 7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 38 100 7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 40 101 7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 40 102 7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 43 103 7.15. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 47 104 7.16. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 48 105 8. Manageability Considerations . . . . . . . . . . . . . . . . . 49 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 107 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 49 108 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 50 109 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 50 110 9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 51 111 9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 52 112 9.6. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 53 113 10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 54 114 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 115 11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 60 116 11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 60 117 11.3. Protection against Denial of Service attacks . . . . . . . 60 118 11.4. Request input shaping/policing . . . . . . . . . . . . . . 61 119 12. Authors' addresses . . . . . . . . . . . . . . . . . . . . . . 61 120 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 121 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 122 14.1. Normative References . . . . . . . . . . . . . . . . . . . 63 123 14.2. Informative References . . . . . . . . . . . . . . . . . . 63 124 Appendix A. Compliance with the PCECP Requirement Document . . . 65 125 Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 65 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 127 Intellectual Property and Copyright Statements . . . . . . . . . . 67 129 1. Terminology 131 Terminology used in this document 133 Explicit path: full explicit path from start to destination made of a 134 list of strict hops where a hop may be an abstract node such as an 135 AS. 137 IGP area: OSPF area or IS-IS level. 139 Inter-domain TE LSP: A TE LSP whose path transits across at least two 140 different domains where a domain can either be an IGP area, an 141 Autonomous System or a sub-AS (BGP confederations). 143 PCC: Path Computation Client: any client application requesting a 144 path computation to be performed by a Path Computation Element. 146 PCE: Path Computation Element: an entity (component, application or 147 network node) that is capable of computing a network path or route 148 based on a network graph and applying computational constraints. 150 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the 151 PCE). 153 TED: Traffic Engineering Database that contains the topology and 154 resource information of the domain. The TED may be fed by IGP 155 extensions or potentially by other means. 157 TE LSP: Traffic Engineering Label Switched Path. 159 Strict/loose path: mix of strict and loose hops comprising of at 160 least one loose hop representing the destination where a hop may be 161 an abstract node such as an AS. 163 Within this document, when describing PCE-PCE communications, the 164 requesting PCE fills the role of a PCC. This provides a saving in 165 documentation without loss of function. 167 2. Introduction 169 [RFC4655]describes the motivations and architecture for a PCE-based 170 model for the computation of MPLS and GMPLS TE LSPs. The model 171 allows for the separation of PCE from PCC, and allows for the 172 cooperation between PCEs. This necessitates a communication protocol 173 between PCC and PCE, and between PCEs. [RFC4657] states the generic 174 requirements for such protocol including the requirement for using 175 the same protocol between PCC and PCE, and between PCEs. Additional 176 application-specific requirements (for scenarios such as inter-area, 177 inter-AS, etc.) are not included in [RFC4657], but there is a 178 requirement that any solution protocol must be easily extensible to 179 handle other requirements as they are introduced in application- 180 specific requirements documents. Examples of such application- 181 specific requirements are [I-D.ietf-pce-pcecp-interarea-reqs], 182 [I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req]. 184 This document specifies the Path Computation Element communication 185 Protocol (PCEP) for communications between a Path Computation Client 186 (PCC) and a Path Computation Element (PCE), or between two PCEs, in 187 compliance with [RFC4657]. Such interactions include path 188 computation requests and path computation replies as well as 189 notifications of specific states related to the use of a PCE in the 190 context of MPLS and GMPLS Traffic Engineering. 192 PCEP is designed to be flexible and extensible so as to easily allow 193 for the addition of further messages and objects, should further 194 requirements be expressed in the future. 196 3. Assumptions 198 [RFC4655] describes various types of PCE. PCEP does not make any 199 assumption and thus does not impose any constraint on the nature of 200 the PCE. 202 Moreover, it is assumed that the PCE gets the required information so 203 as to perform the computation of TE LSP that usually requires network 204 topology and resource information. Such information can be gathered 205 by routing protocols or by some other means, the gathering of which 206 is out of the scope of this document. 208 Similarly, no assumption is made on the discovery method used by a 209 PCC to discover a set of PCEs (e.g. via static configuration or 210 dynamic discovery) and on the algorithm used to select a PCE. For 211 the sake of reference [RFC4674] defines a list of requirements for 212 dynamic PCE discovery and IGP-based solution for such PCE discovery 213 are specified in [I-D.ietf-pce-disco-proto-ospf] and 214 [I-D.ietf-pce-disco-proto-isis]. 216 4. Architectural Protocol Overview (Model) 218 The aim of this section is to describe the PCEP model in the spirit 219 of [RFC4101]. An architecture protocol overview (the big picture of 220 the protocol) is provided in this section. Protocol details can be 221 found in further sections. 223 4.1. Problem 225 The PCE-based architecture used for the computation of MPLS and GMPLS 226 TE LSP is described in [RFC4655]. When the PCC and the PCE are not 227 collocated, a communication protocol between the PCC and the PCE is 228 needed. PCEP is such a protocol designed specifically for 229 communications between a PCC and a PCE or between two PCEs in 230 compliance with [RFC4657]: a PCC may use PCEP to send a path 231 computation request for one or more TE LSP(s) to a PCE and the PCE 232 may reply with a set of computed path(s) if one or more path(s) that 233 satisfy the set of constraints can be found. 235 4.2. Architectural Protocol Overview 237 PCEP operates over TCP, which fulfils the requirements for reliable 238 messaging and flow control without further protocol work. 240 Several PCEP messages are defined: 242 - Open and Keepalive messages are used to initiate and maintain a 243 PCEP session respectively. 245 - PCReq: a PCEP message sent by a PCC to a PCE to request a path 246 computation. 248 - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path 249 computation request. A PCRep message can either contain a set of 250 computed path(s) if the request can be satisfied or a negative reply 251 otherwise. 253 - PCNtf: a PCEP notification message either sent by a PCC to a PCE or 254 a PCE to a PCC to notify of a specific event. 256 - PCErr: a PCEP message sent upon the occurrence of a protocol error 257 condition. 259 - Close message: a message used to close a PCEP session. 261 The set of available PCE(s) may be either statically configured on a 262 PCC or dynamically discovered. The mechanisms used to discover one 263 or more PCE(s) and to select a PCE are out of the scope of this 264 document. 266 A PCC may have PCEP sessions with more than one PCE and similarly a 267 PCE may have PCEP sessions with multiple PCCs. 269 The establishment of a PCEP session is always initiated by the PCC. 271 4.2.1. Initialization Phase 273 The initialization phase consists of two successive steps (described 274 in a schematic form in Figure 1): 276 1) Establishment of a TCP connection (3-way handshake) between the 277 PCC and the PCE. 279 2) Establishment of a PCEP session over the TCP connection. 281 Once the TCP connection is established, the PCC and the PCE (also 282 referred to as "PCEP peers") initiate a PCEP session establishment 283 during which various session parameters are negotiated. These 284 parameters are carried within Open messages and include the Keepalive 285 timer, the Deadtimer and potentially other detailed capabilities and 286 policy rules that specify the conditions under which path computation 287 requests may be sent to the PCE. If the PCEP session establishment 288 phase fails because the PCEP peers disagree on the session parameters 289 or one of the PCEP peers does not answer after the expiration of the 290 establishment timer, the TCP connection is immediately closed. 291 Successive retries are permitted but an implementation SHOULD make 292 use of an exponential back-off session establishment retry procedure. 294 Keepalive messages are used to acknowledge Open messages and once the 295 PCEP session has been successfully established, Keepalive messages 296 are exchanged between PCEP peers to ensure the liveness of the PCEP 297 session. 299 A single PCEP session can exist between a pair a PCEP peers. 301 Details about the Open message and the Keepalive messages can be 302 found in . (Section 6.2) and Section 6.3 respectively. 304 +-+-+ +-+-+ 305 |PCC| |PCE| 306 +-+-+ +-+-+ 307 | | 308 |---- Open message --->| 309 | | 310 |<--- Open message ----| 311 | | 312 | | 313 | | 314 |<--- Keepalive -------| 315 | | 316 |---- Keepalive ------>| 318 Figure 1: PCEP Initialization phase without parameter 319 negotiation(initiated by a PCC) 321 4.2.2. Path computation request sent by a PCC to a PCE 323 +-+-+ +-+-+ 324 |PCC| |PCE| 325 +-+-+ +-+-+ 326 1)Path computation | | 327 event | | 328 2)PCE Selection | | 329 3)Path computation |---- PCReq message--->| 330 request sent to | | 331 the selected PCE | | 333 Figure 2: Path computation request 335 Once a PCC has successfully established a PCEP session with one or 336 more PCEs, if an event is triggered that requires the computation of 337 a set of path(s), the PCC first selects one or more PCE(s) to send 338 the request to. Note that the PCE selection decision process may 339 have taken place prior to the PCEP session establishment. 341 Once the PCC has selected a PCE, it sends a path computation request 342 to the PCE (PCReq message) that contains a variety of objects that 343 specify the set of constraints and attributes for the path to be 344 computed. For example "Compute a TE LSP path with source IP 345 address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B 346 Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may 347 desire to specify the urgency of such request by assigning a request 348 priority. Each request is uniquely identified by a request-id number 349 and the PCC-PCE address pair. The process is shown in a schematic 350 form in figure 2. 352 Details about the PCReq message can be found in Section 6.4 354 4.2.3. Path computation reply sent by the PCE to a PCC 355 +-+-+ +-+-+ 356 |PCC| |PCE| 357 +-+-+ +-+-+ 358 | | 359 |---- PCReq message--->| 360 | |1) Path computation 361 | |request received 362 | | 363 | |2)Path successfully 364 | |computed 365 | | 366 | |3) Computed path(s) sent 367 | |to the PCC 368 |<--- PCRep message ---| 369 | (Positive reply) | 371 Figure 3a: Path computation request with successful path computation 373 +-+-+ +-+-+ 374 |PCC| |PCE| 375 +-+-+ +-+-+ 376 | | 377 | | 378 |---- PCReq message--->| 379 | |1) Path computation 380 | |request received 381 | | 382 | |2) No Path found that 383 | |satisfies the request 384 | | 385 | |3) Negative reply sent to 386 | |the PCC (optionally with 387 | |various additional 388 | |information) 389 |<--- PCRep message ---| 390 | (Negative reply) | 392 Figure 3b: Path computation request with unsuccessful path computation 393 Upon receiving a path computation request from a PCC, the PCE 394 triggers a path computation, the result of which can either be: 396 - Positive (Figure 3-a): the PCE manages to compute a path that 397 satisfies the set of required constraints, in which case the PCE 398 returns the set of computed path(s) to the requesting PCC. Note that 399 PCEP supports the capability to send a single request which requires 400 the computation of more than one path (e.g. computation of a set of 401 link-diverse paths). 403 - Negative (Figure 3-b): no path could be found that satisfies the 404 set of constraints. In this case, a PCE may provide the set of 405 constraints that led to the path computation failure. Upon receiving 406 a negative reply, a PCC may decide to resend a modified request or 407 take any other appropriate action. 409 Details about the PCRep message can be found in Section 6.5. 411 4.2.4. Notification 413 There are several circumstances whereby a PCE may want to notify a 414 PCC of a specific event. For example, suppose that the PCE suddenly 415 experiences some congestion that would lead to unacceptable response 416 times. The PCE may want to notify one or more PCCs that some of 417 their requests (listed in the notification) will not be satisfied or 418 may experience unacceptable delays. Upon receiving such 419 notification, the PCC may decide to redirect it(s) path computation 420 request(s) to another PCE should an alternate PCE be available. 421 Similarly, a PCC may desire to notify a PCE of a particular event 422 such as the cancellation of pending request(s). 424 +-+-+ +-+-+ 425 |PCC| |PCE| 426 +-+-+ +-+-+ 427 1)Path computation | | 428 event | | 429 2)PCE Selection | | 430 3)Path computation |---- PCReq message--->| 431 request X sent to | |4) Path computation 432 the selected PCE | |triggered 433 | | 434 | | 435 5) Path computation| | 436 request X cancelled| | 437 |---- PCNtf message -->| 438 | |6) Path computation 439 | |request X cancelled 441 Figure 4: Example of PCC notification (cancellation notification) sent to a PCE 443 +-+-+ +-+-+ 444 |PCC| |PCE| 445 +-+-+ +-+-+ 446 1)Path computation | | 447 event | | 448 2)PCE Selection | | 449 3)Path computation |---- PCReq message--->| 450 request X sent to | |4) Path computation 451 the selected PCE | |triggered 452 | | 453 | | 454 | |5) PCE experiencing 455 | |congestion 456 | | 457 | |6) Path computation 458 | |request X cancelled 459 | | 460 |<--- PCNtf message----| 462 Figure 5: Example of PCE notification (cancellation notification) sent to a PCC 464 Details about the PCNtf message can be found in Section 6.6. 466 4.2.5. Error 468 PCEP Error messages are sent when a protocol error condition is met 469 (e.g. unknown object, non supported object, policy violation, ...). 471 +-+-+ +-+-+ 472 |PCC| |PCE| 473 +-+-+ +-+-+ 474 1)Path computation | | 475 event | | 476 2)PCE Selection | | 477 3)Path computation |---- PCReq message--->| 478 request X sent to | |4) Path computation 479 the selected PCE | |triggered => Policy 480 | |violation ! 481 | |5) Request discarded 482 | | 483 |<-- PCErr message ---| 484 | | 486 Figure 6: Example of Error message (policy violation) sent by a PCE 488 Details about the PCErr message can be found in Section 6.7. 490 4.2.6. Termination of the PCEP Session 492 When one of the PCEP peers desires to terminate a PCEP session it 493 first sends a PCEP Close message and then close the TCP connection. 494 If the PCEP session is terminated by the PCE, the PCC clears all the 495 states related to pending requests previously sent to the PCE. 496 Similarly, if the PCC terminates a PCEP session the PCE clears all 497 pending path computation requests sent by the PCC in question as well 498 as the related states. A Close message can only be sent to terminate 499 a PCEP session if the PCEP session has previously been established. 501 In case of TCP connection failure, the PCEP session is immediatly 502 terminated. 504 Details about the Close message can be found in Section 6.8. 506 5. Transport protocol 508 PCEP operates over TCP using a well-known TCP port (to be assigned by 509 IANA). This allows the requirements of reliable messaging and flow 510 control to be met without further protocol work. 512 An implementation may decide to keep the TCP session alive for an 513 unlimited time (this may for instance be appropriate when path 514 computation requests are sent on a frequent basis so as to avoid to 515 open a TCP session each time a path computation request is needed, 516 which would incur additional processing delays). Conversely, in some 517 other circumstances, it may be desirable to systematically open and 518 close the TCP connection for each PCEP request (for instance when 519 sending a path computation request is a rare event). 521 6. PCEP Messages 523 A PCEP message consists of a common header followed by a variable 524 length body made of a set of objects that can either be mandatory or 525 optional. In the context of this document, an object is said to be 526 mandatory in a PCEP message when the object MUST be included for the 527 message to be considered as valid. A PCEP message with a missing 528 mandatory object MUST trigger an Error message (see Section 7.14). 529 Conversely, if an object is optional, the object may or may not be 530 present. 532 A flag referred to as the P flag is defined in the common header of 533 each PCEP object (see Section 7.1) that can be set by a PCEP peer to 534 enforce a PCE to take into account the related information during the 535 path computation. For example, the METRIC object defined in 536 Section 7.7allows a PCC to specify a bounded acceptable path cost. 537 The METRIC object is optional but a PCC may set a flag to ensure that 538 such constraint is taken into account. Similarly to the previous 539 case, if such constraint cannot be taken into account by the PCE, 540 this should trigger an Error message. 542 For each PCEP message type, rules are defined that specify the set of 543 objects that the message can carry. We use the Backus-Naur Form 544 (BNF) to specify such rules. Square brackets refer to optional sub- 545 sequences. An implementation MUST form the PCEP messages using the 546 object ordering specified in this document. 548 6.1. Common header 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Ver | Flags | Message-Type | Message-Lenght | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Figure 7: PCEP message common header 557 Ver (Version - 3 bits): PCEP version number. Current version is 558 version 1. 560 Flags (5 bits): no flags are currently defined. Unassigned bits are 561 considered as reserved and MUST be set to zero on transmission. 563 Message-Type (8 bits): 565 The following message types are currently defined (to be confirmed by 566 IANA). 567 Value Meaning 568 1 Open 569 2 Keepalive 570 3 Path Computation Request 571 4 Path Computation Reply 572 5 Notification 573 6 Error 574 7 Close 575 Reserved: This field MUST be set to zero on transmission and MUST be 576 ignored on receipt. 578 Message Length (32 bits): total length of the PCEP message expressed 579 in bytes including the common header. 581 6.2. Open message 583 The Open message is a PCEP message sent by a PCC to a PCE and a PCE 584 to a PCC in order to establish a PCEP session. The Message-Type 585 field of the PCEP common header for the Open message is set to 1 (To 586 be confirmed by IANA). 588 Once the TCP connection has been successfully established, the first 589 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 590 an Open message. Any message received prior to an Open message 591 (other than a Keepalive message) MUST trigger a protocol error 592 condition and the PCEP session MUST be terminated. The Open message 593 is used to establish a PCEP session between the PCEP peers. During 594 the establishment phase the PCEP peers exchange several session 595 characteristics. If both parties agree on such characteristics the 596 PCEP session is successfully established. 598 Open message 599 ::= 600 601 The Open message MUST contain exactly one OPEN object (see 602 Section 7.2). Various session characteristics are specified within 603 the OPEN object. 605 Once an Open message has been sent to a PCEP peer, the sender MUST 606 start an initialization timer called KeepWait after the expiration of 607 which if neither an Open message has been received nor a PCErr 608 message in case of disagreement of the session characteristics, the 609 TCP connection MUST be released (see Section 10 for details). 611 The KeepWait timer has a fixed value of 1 minute. 613 Upon the receipt of an Open message, the receiving PCEP peer MUST 614 determine whether the suggested PCEP session characteristics are 615 acceptable. If at least one of the characteristic(s) is not 616 acceptable by the receiving peer, it MUST send an Error message. The 617 Error message SHOULD also contain the related Open object: for each 618 unacceptable session parameter, an acceptable parameter value SHOULD 619 be proposed in the appropriate field of the Open object in place of 620 the originally proposed value. The PCEP peer MAY decide to resend an 621 Open message with different session characteristics. If a second 622 Open message is received with the same set of parameters or with 623 parameters that are still unacceptable, the receiving peer MUST send 624 an Error message and it MUST immediately close the TCP connection. 625 Details about error message can be found in Section 7.14. 627 If the PCEP session characteristics are acceptable, the receiving 628 PCEP peer MUST consequently send a Keepalive message (defined in 629 Section 6.3) that would serve as an acknowledgment. 631 The PCEP session is considered as established once both PCEP peers 632 have received a Keepalive message from their peer. 634 6.3. Keepalive message 636 A Keepalive message is a PCEP message sent by a PCC or a PCE in order 637 to keep the session in active state. The Message-Type field of the 638 PCEP common header for the Keepalive message is set to 2 (To be 639 confirmed by IANA). The Keepalive message does not contain any 640 object. 642 PCEP has its own keepalive mechanism used to ensure of the liveness 643 of the PCEP session. This requires the determination of the 644 frequency at which each PCEP peer sends keepalive messages. 645 Asymmetric values may be chosen; thus there is no constraints 646 mandating the use of identical keepalive frequencies by both PCEP 647 peers. The DeadTimer is defined as the period of time after the 648 expiration of which a PCEP peer declares the session down if no PCEP 649 message has been received (keepalive or any other PCEP message: thus, 650 any PCEP message acts as a keepalive message). Similarly, there is 651 no constraints mandating the use of identical DeadTimers by both PCEP 652 peers. The minimum KeepAliveTimer value is 1 second. 654 Keepalive messages are used either to acknowledge an Open message if 655 the receiving PCEP peer agrees on the session characteristics and to 656 ensure the liveness of the PCEP session. Keepalive messages are sent 657 at the frequency specified in the OPEN object carried within an Open 658 message. Because any PCEP message may serve as Keepalive an 659 implementation may either decide to send Keepalive messages at fixed 660 intervals regardless on whether other PCEP messages might have been 661 sent since the last sent Keepalive message or may decide to differ 662 the sending of the next Keepalive message based on the time at which 663 the last PCEP message (other than Keepalive) has been sent. 665 Keepalive message 666 ::= 668 6.4. Path Computation Request (PCReq) message 670 A Path Computation Request message (also referred to as a PCReq 671 message) is a PCEP message sent by a PCC to a PCE so as to request a 672 path computation. The Message-Type field of the PCEP common header 673 for the PCReq message is set to 3 (To be confirmed by IANA). 675 There is are two mandatory objects that MUST be included within a 676 PCReq message: the RP and the END-POINTS objects (see section 677 Section 7). If one of these objects is missing, the receiving PCE 678 MUST send an error message to the requesting PCC. Other objects are 679 optional. 681 The format of a PCReq message is as follows: 682 ::= 683 [] 684 686 where: 687 ::=[] 688 ::=[] 690 ::= 691 692 [] 693 [] 694 [] 695 [] 696 [] 697 [] 698 where: 700 ::=[] 702 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD- 703 BALANCING objects are defined in Section 7. The special case of two 704 BANDWIDTH objects is discussed in details in Section 7.6. 706 6.5. Path Computation Reply (PCRep) message 708 The PCEP Path Computation Reply message (also referred to as a PCRep 709 message) is a PCEP message sent by a PCE to a requesting PCC in 710 response to a previously received PCReq message. The Message-Type 711 field of the PCEP common header is set to 4 (To be confirmed by 712 IANA). 714 The PCRep message MUST contain at least one RP object. For each 715 reply that is bundled into a single PCReq message, an RP object MUST 716 be included that contains a Request-ID-number identical to the one 717 specified in the RP object carried in the corresponding PCReq message 718 (see Section 7.3for the definition of the RP object). 720 A PCRep message may contain a set of computed path(s) corresponding 721 to either a single path computation request with load-balancing (see 722 Section 7.15) or multiple path computation requests originated by a 723 requesting PCC. The PCRep message may also contain multiple 724 acceptable paths corresponding to the same request. 726 The bundling of multiple replies to a set of path computation 727 requests within a single PCRep message is supported by PCEP. If a 728 PCE receives non-synchronized path computation requests by means of 729 one or more PCReq messages from a requesting PCC it MAY decide to 730 bundle the computed paths within a single PCRep message so as to 731 reduce the control plane load. Note that the counter side of such an 732 approach is the introduction of additional delays for some path 733 computation requests of the set. Conversely, a PCE that receives 734 multiple requests within the same PCReq message, it MAY decide to 735 provide each computed path in separate PCRep messages. 737 If the path computation request can be satisfied (the PCE finds a set 738 of path(s) that satisfy the set of constraint(s)), the set of 739 computed path(s) specified by means of ERO object(s) is inserted in 740 the PCRep message. The ERO object is defined in Section 7.8. Such a 741 situation where multiple computed paths are provided in a PCRep 742 message is discussed in detail in Section 7.12. Furthermore, when a 743 PCC requests the computation a set of paths for a total amount of 744 bandwidth of X by means of a LOAD-BALANCING object carried within a 745 PCReq message, the ERO of each computed path may be followed by a 746 BANDWIDTH object as discussed in section Section 7.15. 748 If the path computation request cannot be satisfied, the PCRep 749 message MUST include a NO-PATH object. The NO-PATH object (described 750 in Section 7.4) may also comprise other information (e.g reasons for 751 the path computation failure). 753 The format of a PCRep message is as follows: 754 ::= 755 757 where: 758 ::=[] 760 ::= 761 [] 762 [] 764 ::=[] 766 ::= 767 [] 768 [] 769 [] 770 [] 772 where: 773 ::=[] 775 6.6. Notification (PCNtf) message 777 The PCEP Notification message (also referred to as the PCNtf message) 778 can either be sent by a PCE to a PCC or by a PCC to a PCE so as to 779 notify of a specific event. The Message-Type field of the PCEP 780 common header is set to 5 (To be confirmed by IANA). 782 The PCNtf message MUST carry at least one NOTIFICATION object and may 783 contain several NOTIFICATION objects should the PCE or the PCC intend 784 to notify of multiple events. The NOTIFICATION object is defined in 785 Section 7.13. The PCNtf message MAY also contain an RP object (see 786 Section 7.3 when the notification refers to a particular path 787 computation request. 789 The PCNtf message may be sent by a PCC or a PCE in response to a 790 request or in an unsolicited manner. 792 The format of a PCNtf message is as follows: 793 ::= 794 796 ::= [] 798 ::= [] 799 801 :== 803 := 805 6.7. Error (PCErr) Message 807 The PCEP Error message (also referred to as a PCErr message) is sent 808 when a protocol error condition is met. The Message-Type field of 809 the PCEP common header is set to 6 (To be confirmed by IANA). 811 The PCErr message is either sent by a PCC or a PCE in response to a 812 request or in an unsolicited manner. In the former case, the PCErr 813 message MUST include the set of RP objects related to the pending 814 path computation request(s) that triggered the protocol error 815 condition. In the later case (unsolicited), no RP object is inserted 816 in the PCErr message. No RP object is inserted in a PCErr when the 817 error condition occurred during the initialization phase. A PCErr 818 message MUST contain a PCEP-ERROR object specifying the PCEP error 819 condition. The PCEP-ERROR object is defined in section Section 7.14. 821 The format of a PCErr message is as follows: 822 ::= 823 824 [] 826 :==[] 827 ::=[] 828 830 :==[] 832 :==[] 833 The procedure upon the reception of a PCErr message is defined in 834 Section 7.14. 836 6.8. Close message 838 The Close message is a PCEP message that is either sent by a PCC to a 839 PCE or by a PCE to a PCC in order to close a PCEP session. The 840 Message-Type field of the PCEP common header for the Open message is 841 set to 7 (To be confirmed by IANA). 843 Close message 844 ::= 845 846 The Close message MUST contain exactly one CLOSE object (see 847 Section 6.8). 849 Upon the receipt of a Close message, the receiving PCEP peer MUST 850 cancel all pending requests and MUST close the TCP connection. 852 7. Object Formats 854 7.1. Common object header 856 A PCEP object carried within a PCEP message consists of one or more 857 32-bit words with a common header which has the following format: 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Object-Class | OT |Res|P|I| Object Length (bytes) | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | | 864 // (Object body) // 865 | | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 Figure 8: PCEP common object header 870 Object-Class (8 bits): identifies the PCEP object class. 872 OT (Object-Type - 4 bits): identifies the PCEP object type. 874 The Object-Class and Object-Type fields are managed by IANA. 876 The Object-Class and Object-Type fields uniquely identify each PCEP 877 object. 879 Res flags (2 bits). Reserved field. This field MUST be set to zero 880 on transmission and MUST be ignored on receipt. 882 P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify 883 in a PCReq message sent to a PCE whether the object must be taken 884 into account by the PCE during path computation or is just optional. 885 When the P flag is set, the object MUST be taken into account by the 886 PCE. Conversely, when the P flag is cleared, the object is optional 887 and the PCE is free to ignore it if not supported. 889 I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 890 message to indicate to a PCC whether or not an optional object was 891 processed. The PCE MAY include the ignored optional object in its 892 reply and set the I flag to indicate that the optional object was 893 ignored during path computation. When the I flag is cleared, the PCE 894 indicates that the optional object was processed during the path 895 computation. The setting of the I flag for optional objects is 896 purely indicative and optional. The I flag has no meaning in a PCRep 897 message when the P flag had been set in the corresponding PCRep 898 message. 900 If the PCE does not understand an object with the P flag set or 901 understands the object but decides to ignore the object, the entire 902 PCEP message MUST be rejected and the PCE MUST send a PCErr message 903 with Error-Type="Unknown Object" or "Not supported Object". 905 Object Length (16 bits). Specifies the total object length including 906 the header, in bytes. The Object Length field MUST always be a 907 multiple of 4, and at least 4. The maximum object content length is 908 65528 bytes. 910 7.2. OPEN object 912 The OPEN object MUST be present in each Open message and MAY be 913 present in a PCErr message. There MUST be only one OPEN object per 914 Open or PCErr message. 916 The OPEN object contains a set of fields used to specify the PCEP 917 version, Keepalive frequency, DeadTimer, PCEP session ID along with 918 various flags. The OPEN object may also contain a set of TLVs used 919 to convey various session characteristics such as the detailed PCE 920 capabilities, policy rules and so on. No such TLV is currently 921 defined. 923 OPEN Object-Class is to be assigned by IANA (recommended value=1) 925 OPEN Object-Type is to be assigned by IANA (recommended value=1) 926 The format of the OPEN object body is as follows: 927 0 1 2 3 928 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 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Ver | Flags | Keepalive | Deadtimer | SID | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | | 933 // Optional TLV(s) // 934 | | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 Figure 9: OPEN Object format 938 Ver (Ver - 4 bits): PCEP version. Current version is 1. 940 Flags (4 bits): No Flags are currently defined. Unassigned bits are 941 considered as reserved and MUST be set to zero on transmission. 943 Keepalive (8 bits): minimum period of time (in seconds) between the 944 sending of PCEP messages. The minimum value for the Keepalive is 1 945 second. When set to 0, once the session is established, no further 946 Keepalive messages need to be sent to the remote peer. A RECOMMENDED 947 value for the keepalive frequency is 30 seconds. 949 DeadTimer (8 bits): specifies the amount of time after the expiration 950 of which a PCEP peer declares the session with the sender of the Open 951 message down if no PCEP message has been received. The DeadTimer 952 MUST be set to 0 if the Keepalive is set to 0. A RECOMMENDED value 953 for the DeadTimer is 4 times the value of the Keepalive. 955 SID (PCEP session-ID - 8 bits): specifies a 2 octet unsigned PCEP 956 session number that identifies the current session. The SID MUST be 957 incremented each time a new PCEP session is established and is mainly 958 used for logging and troubleshooting purposes. 960 Optional TLVs may be included within the OPEN object body to specify 961 PCC or PCE characteristics. The specification of such TLVs is 962 outside the scope of this document. 964 When present in an Open message, the OPEN object specifies the 965 proposed PCEP session characteristics. Upon receiving unacceptable 966 PCEP session characteristics during the PCEP session initialization 967 phase, the receiving PCEP peer (PCE) MAY include an OPEN object 968 within the PCErr message so as to propose alternative session 969 characteristic values. 971 7.3. RP Object 973 The RP (Request Parameters) object MUST be carried within each PCReq 974 and PCRep messages and MAY be carried within PCNtf and PCErr 975 messages. The P flag of the RP object MUST be set in PCReq and PCReq 976 messages and MUST be cleared in PCNtf and PCErr messages. The RP 977 object is used to specify various characteristics of the path 978 computation request. 980 7.3.1. Object definition 982 RP Object-Class is to be assigned by IANA (recommended value=2) 984 RP Object-Type is to be assigned by IANA (recommended value=1) 986 The format of the RP object body is as follows: 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Reserved | Flags |O|B|R| Pri | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Request-ID-number | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | | 995 // Optional TLV(s) // 996 | | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 Figure 10: RP object body format 1001 The RP object body has a variable length and may contain additional 1002 TLVs. No TLVs are currently defined. 1004 Reserved (8 bits): Reserved: This field MUST be set to zero on 1005 transmission and MUST be ignored on receipt. 1007 Flags: 18 bits - The following flags are currently defined: 1009 Pri (Priority - 3 bits): the Priority field may be used by the 1010 requesting PCC to specify to the PCE the request's priority from 1 to 1011 7. The decision of which priority should be used for a specific 1012 request is of a local matter and MUST be set to 0 when unused. 1013 Furthermore, the use of the path computation request priority by the 1014 PCE's scheduler is implementation specific and out of the scope of 1015 this document. Note that it is not required for a PCE to support the 1016 priority field: in this case, it is RECOMMENDED to set the priority 1017 field to 0 by the PCC in the RP object. If the PCE does not take 1018 into account the request priority, it is RECOMMENDED to set the 1019 priority field to 0 in the RP object carried within the corresponding 1020 PCRep message, regardless of the priority value contained in the RP 1021 object carried within the corresponding PCReq message. A higher 1022 numerical value of the priority field reflects a higher priority. 1023 Note that it is the responsibility of the network administrator to 1024 make use of the priority values in a consistent manner across the 1025 various PCC(s). The ability of a PCE to support requests 1026 prioritization may be dynamically discovered by the PCC(s) by means 1027 of PCE capability discovery. If not advertised by the PCE, a PCC may 1028 decide to set the request priority and will learn the ability of the 1029 PCE the support request prioritization by observing the Priority 1030 field of the RP object received in the PCRep message. If the value 1031 of the Pri field is set to 0, this means that the PCE does not 1032 support the handling of request priorities: in other words, the path 1033 computation request has been honoured but without taking the request 1034 priority into account. 1036 R (Reoptimization - 1 bit): when set, the requesting PCC specifies 1037 that the PCReq message relates to the reoptimization of an existing 1038 TE LSP in which case, in addition to the TE LSP attributes, the 1039 current path of the existing TE LSP to be reoptimized MUST be 1040 provided in the PCReq (except for 0-bandwidth TE LSP) message by 1041 means of an RRO object defined in Section 7.9. 1043 B (Bi-directional - 1 bit): when set, the PCC specifies that the path 1044 computation request relates to a bidirectional TE LSP that has the 1045 same traffic engineering requirements including fate sharing, 1046 protection and restoration, LSRs, and resource requirements (e.g. 1047 latency and jitter) in each direction. When cleared, the TE LSP is 1048 unidirectional. 1050 O (strict/lOose - 1 bit): when set, in a PCReq message, this 1051 indicates that a loose path is acceptable. Otherwise, when cleared, 1052 this indicates to the PCE that a path exclusively made of strict hops 1053 is required. In a PCRep message, when the O bit is set this 1054 indicates that the returned path is a loose path, otherwise (the O 1055 bit is cleared), the returned path is made of strict hops. 1057 Unassigned bits are considered as reserved and MUST be set to zero on 1058 transmission. 1060 Request-ID-number (32 bits). The Request-ID-number value combined 1061 with the source IP address of the PCC and the PCE address uniquely 1062 identify the path computation request context. The Request-ID-number 1063 MUST be incremented each time a new request is sent to the PCE. The 1064 value 0x0000000 is considered as invalid. If no path computation 1065 reply is received from the PCE, and the PCC wishes to resend its 1066 request, the same Request-ID-number MUST be used. Conversely, 1067 different Request-ID-number MUST be used for different requests sent 1068 to a PCE. The same Request-ID-number may be used for path 1069 computation requests sent to different PCEs. The path computation 1070 reply is unambiguously identified by the IP source address of the 1071 replying PCE. 1073 7.3.2. Handling of the RP object 1075 If a PCReq message is received without containing an RP object, the 1076 PCE MUST send a PCErr message to the requesting PCC with Error- 1077 type="Required Object missing" and Error-value="RP Object missing". 1079 If the O bit of the RP message carried within a PCReq message is set 1080 and local policy has been configured on the PCE to not provide 1081 explicit path(s) (for instance, for confidentiality reasons), a PCErr 1082 message MUST be sent by the PCE to the requesting PCC and the pending 1083 path computation request MUST be discarded. The Error-type is 1084 "Policy Violation" and Error-value is "O bit set". 1086 R bit: when the R bit of the RP object is set in a PCReq message, 1087 this indicates that the path computation request relates to the 1088 reoptimization of an existing TE LSP. In this case, the PCC MUST 1089 also provide the strict/loose path by including an RRO object in the 1090 PCReq message so as to avoid/limit double bandwidth counting if and 1091 only if the TE LSP is a non 0-bandwidth TE LSP. If the PCC has not 1092 requested a strict path (O bit set), a reoptimization can still be 1093 requested by the PCC but this implies for the PCE to be either 1094 stateful (keep track of the previously computed path with the 1095 associated list of strict hops) or to have the ability to retrieve 1096 the complete required path segment. Alternatively the PCC MUST be 1097 able to inform PCE of the working path with associated list of strict 1098 hops in PCReq. The absence of an RRO in the PCReq message for a non 1099 0-bandwidth TE LSP when the R bit of the RP object is set MUST 1100 trigger the sending of a PCErr message with Error-type="Required 1101 Object Missing" and Error-value="RRO Object missing for 1102 reoptimization". 1104 If the PCC receives a PCRep message that contains a RP object 1105 referring to an unknown Request-ID-Number, the PCC MUST send a PCErr 1106 message with Error-Type="Unknown request reference". 1108 7.4. NO-PATH Object 1110 The No-PATH object is used in PCRep messages in response to an 1111 unsuccessful path computation request (the PCE could not find a path 1112 satisfying the set of constraints). When a PCE cannot find a path 1113 satisfying a set of constraints, it MUST include a NO-PATH object in 1114 the PCRep message. The NO-PATH object is used to report the 1115 impossibility to find a path that satisfies the set of constraints. 1116 Optionally, if the PCE supports such capability, the NO-PATH object 1117 MAY contain an optional NO-PATH-VECTOR TLV defined below and the 1118 PCRep message MAY also contain a list of objects that specify the set 1119 of constraints that could not be satisfied. The PCE MAY just 1120 replicate the set of object(s) that was received that was the cause 1121 of the unsuccessful computation or MAY optionally report a suggested 1122 value for which a path could have been found. 1124 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1126 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1127 The format of the NO-PATH object body is as follows: 1128 0 1 2 3 1129 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 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 |C| Flags | Reserved | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | | 1134 // Optional TLV(s) // 1135 | | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 Figure 11: NO-PATH object format 1140 Optionally, a TLV named NO-PATH-VECTOR MAY be included in the 1141 NO-PATH object that specifies the reason that led to unsuccessful path computation. 1143 The NO-PATH-VECTOR TLV is composed of 1 octet for the type, 1144 1 octet specifying the number of bytes in the value field, followed by 1145 a fix length value field of 32-bits flags field used to report the reason(s) 1146 that led to unsuccessful path computation The NO-PATH-VECTOR TLV is padded 1147 to eight-octet alignment. 1149 TYPE: To be assigned by IANA 1150 LENGTH: 4 1151 VALUE: 32-bits flags field 1153 IANA is requested to manage the space of flags carried in the NO-PATH-VECTOR TLV (see IANA section). 1155 The following flags are currently defined: 1157 0x01: PCE currently unavailable 1158 0x02: Unknown destination 1159 The NO-PATH object body has a variable length and may contain 1160 additional TLVs. The only TLV currently defined is the NO-PATH- 1161 VECTOR TLV defined below. 1163 Flags (16 bits). The following flags are currently defined: 1165 Reserved: This field MUST be set to zero on transmission and MUST be 1166 ignored on receipt. 1168 C flag (1 bit): when set, the PCE indicates the set of unsatisfied 1169 constraints (reasons why a path could not be found) in the PCRep 1170 message by including the relevant PCEP objects. When cleared, no 1171 reason is specified. 1173 Example: consider the case of a PCC that sends a path computation 1174 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1175 find a path for X MBits/s. In this case, the PCE must include in the 1176 PCRep message a NO-PATH object. Optionally the PCE may also include 1177 the original BANDWIDTH object so as to indicate that the reason for 1178 the unsuccessful computation is the bandwidth constraint (in this 1179 case, the C flag is set). If the PCE supports such capability it may 1180 alternatively include the BANDWIDTH Object and report a value of Y in 1181 the bandwidth field of the BANDWIDTH object (in this case, the C flag 1182 is set) where Y refers to the bandwidth for which a TE LSP with the 1183 same other characteristics could have been computed. 1185 When the NO-PATH object is absent from a PCRep message, the path 1186 computation request has been fully satisfied and the corresponding 1187 path(s) is/are provided in the PCRep message. 1189 7.5. END-POINT Object 1191 The END-POINTS object is used in a PCReq message to specify the 1192 source IP address and the destination IP address of the path for 1193 which a path computation is requested. Note that the source and 1194 destination addresses specified in the END-POINTS object may or may 1195 not correspond to the source and destination IP address of the TE LSP 1196 but rather to a path segment. Two END-POINTS objects (for IPv4 and 1197 IPv6) are defined. 1199 END-POINTS Object-Class is to be assigned by IANA (recommended 1200 value=4) 1202 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 1203 for IPv4 and 2 for IPv6) 1204 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1205 as follows: 1207 0 1 2 3 1208 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 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Source IPv4 address | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Destination IPv4 address | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 Figure 12: END-POINTS object body format for IPv4 1217 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 1219 0 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | | 1223 | Source IPv6 address (16 bytes) | 1224 | | 1225 | | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | | 1228 | Destination IPv6 address (16 bytes) | 1229 | | 1230 | | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 Figure 13: END-POINTS object body format for IPv6 1235 The END-POINTS object body has a fixed length of 8 octets for IPv4 1236 and 32 octets for IPv6. 1238 7.6. BANDWIDTH Object 1240 The BANDWIDTH object is used to specify the requested bandwidth for a 1241 TE LSP. 1243 If the requested bandwidth is equal to 0, the BANDWIDTH object is 1244 optional. Conversely, if the requested bandwidth is non equal to 0, 1245 the PCReq message MUST contain a BANDWIDTH object. 1247 In the case of the reoptimization of a TE LSP, the bandwidth of the 1248 existing TE LSP MUST also be included in addition to the requested 1249 bandwidth if and only if the two values differ. Consequently, two 1250 Object-Type are defined that refer to the requested bandwidth and the 1251 bandwidth of the TE LSP for which a reoptimization is being 1252 performed. 1254 The BANDWIDTH object may be carried within PCReq and PCRep messages. 1256 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1257 value=5) 1259 Two Object-Type are defined for the BANDWIDTH object: 1261 o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by 1262 IANA (recommended value=1) 1264 o Bandwidth of an existing TE LSP for which a reoptimization is 1265 requested. BANDWIDTH Object-Type is to be assigned by IANA 1266 (recommended value=2) 1268 The format of the BANDWIDTH object body is as follows: 1269 0 1 2 3 1270 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 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Bandwidth | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Figure 14: BANDWIDTH object body format 1276 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1277 IEEE floating point format, expressed in bytes per second. 1279 The BANDWIDTH object body has a fixed length of 4 octets. 1281 7.7. METRIC Object 1283 The METRIC object is optional and can be used for several purposes. 1285 In a PCReq message, a PCC MAY insert a METRIC object: 1287 o To indicate the metric that MUST be optimized by the path 1288 computation algorithm (IGP metric, TE metric, Hop counts). 1289 Currently, three metrics are defined: the IGP cost and the TE 1290 metric (see [RFC3785]) and the number of hops traversed by a TE 1291 LSP. 1293 o To indicate a bound on the path cost than MUST NOT be exceeded for 1294 the path to be considered as acceptable by the PCC. 1296 In a PCRep message, the METRIC object MAY be inserted so as to 1297 provide the cost for the computed path. It MAY also be inserted 1298 within a PCRep with the NO-PATH object to indicate that the metric 1299 constraint could not be satisfied. 1301 The path computation algorithmic aspects used by the PCE to optimize 1302 a path with respect to a specific metric are outside the scope of 1303 this document. 1305 It must be understood that such path metric is only meaningful if 1306 used consistently: for instance, if the delay of a path computation 1307 segment is exchanged between two PCEs residing in different domains, 1308 consistent ways of defining the delay must be used. 1310 The absence of the METRIC object MUST be interpreted by the PCE as a 1311 path computation request for which the PCE may choose the metric to 1312 be used. 1314 METRIC Object-Class is to be assigned by IANA (recommended value=6) 1316 METRIC Object-Type is to be assigned by IANA (recommended value=1) 1318 The format of the METRIC object body is as follows: 1319 0 1 2 3 1320 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 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Reserved | Flags |C|B| T | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | metric-value | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 Figure 15: METRIC object body format 1329 The METRIC object body has a fixed length of 8 octets. 1331 Reserved (16 bits): This field MUST be set to zero on transmission 1332 and MUST be ignored on receipt. 1334 T (Type - 8 bits): Specifies the metric type. 1336 Three values are currently defined: 1338 o T=1: IGP metric 1340 o T=2: TE metric 1342 o T=3: Hop Counts 1344 B (Bound - 1 bit): When set in a PCReq message, the metric-value 1345 indicates a bound (a maximum) for the path cost that must not be 1346 exceeded for the PCC to consider the computed path as acceptable. 1347 When the B flag is cleared, the metric-value field is not used to 1348 reflect a bound constraint. 1350 C (Cost - 1 bit): When set in a PECReq message, this indicates that 1351 the PCE MUST provide the computed path cost (should a path satisfying 1352 the constraints be found) in the PCRep message for the corresponding 1353 metric. 1355 Metric-value (32 bits): metric value encoded in 32 bits in IEEE 1356 floating point format. 1358 Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 1359 message. There MUST be at most one instance of the METRIC object for 1360 each metric type. In two or more instances of a METRIC object are 1361 present for a metric type, only the first instance MUST be considered 1362 and other instances MUST be ignored. 1364 In a PCReq message the presence of multiple METRIC object can be used 1365 to specify a multi-parameters (e.g. a metric may be a constraint or a 1366 parameter to minimize/maximize) objective function or multiple bounds 1367 for different constraints where at most one METRIC object must be 1368 used to indicate the metric to optimize (B-flag is cleared): the 1369 other METRIC object MUST be used to reflect bound constraints (B-Flag 1370 is set). 1372 A METRIC object used to indicate the metric to optimize during the 1373 path computation MUST have the B-Flag cleared and the T-Flag set to 1374 the appropriate value. When the path computation relates to the 1375 reoptimization of an exiting TE LSP (in which case R-Flag of the RP 1376 object is set) an implementation MAY decide to set the metric-value 1377 field to the cost of the TE LSP to be reoptimized with regards to a 1378 specific metric type. 1380 A METRIC object used to reflect a bound MUST have the B-Flag set, the 1381 T-Flag and metric-value field set to the appropriate values. 1383 In a PCRep message, unless not allowed by PCE policy, at least one 1384 METRIC object MUST be present that reports the computed path cost if 1385 the C bit of the METRIC object was set in the corresponding path 1386 computation request (the B-flag MUST be cleared); optionally the 1387 PCRep message MAY contain additional METRIC objects that correspond 1388 to bound constraints, in which case the metric-value MUST be equal to 1389 the corresponding path metric cost (the B-flag MUST be set). If no 1390 path satisfying the constraints could be found by the PCE, the METRIC 1391 objects MAY also be present in the PCRep message with the NO-PATH 1392 object to indicate the constraint metric that could be satisfied. 1394 Example: if a PCC sends a path computation request to a PCE where the 1395 metric to optimize is the IGP metric and the TE metric must not 1396 exceed the value of M, two METRIC object are inserted in the PCReq 1397 message: 1399 o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000 1401 o Second METRIC Object with B=1, T=2, metric-value=M 1403 If a path satisfying the set of constraints can be found by the PCE 1404 and no policy preventing to provide the path cost is in place, the 1405 PCE inserts one METRIC object with B=0, T=1, metric-value= computed 1406 IGP path cost. Additionally, the PCE may insert a second METRIC 1407 object with B=1, T=2, metric-value= computed TE path cost. 1409 7.8. Explicit Route Object 1411 The ERO is used to encode a TE LSP. The ERO is carried within a 1412 PCRep message to provide the computed TE LSP should have the path 1413 computation been successful. 1415 The contents of this object are identical in encoding to the contents 1416 of the Explicit Route Object defined in [RFC3209], [RFC3473] and 1417 [RFC3477]. That is, the object is constructed from a series of sub- 1418 objects. Any RSVP ERO sub-object already defined or that could be 1419 defined in the future for use in the ERO is acceptable in this 1420 object. 1422 PCEP ERO sub-object types correspond to RSVP ERO sub-object types. 1424 Since the explicit path is available for immediate signaling by the 1425 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1426 and fields in this object are identical to those defined for the ERO. 1428 ERO Object-Class is to be assigned by IANA (recommended value=7) 1430 ERO Object-Type is to be assigned by IANA (recommended value=1) 1432 7.9. Route Record Object 1434 The RRO is used to record the route followed by a TE LSP. The PCEP 1435 RRO is exclusively carried within a PCReq message so as to specify 1436 the route followed by a TE LSP for which a reoptimization is desired. 1438 The contents of this object are identical in encoding to the contents 1439 of the Route Record Object defined in [RFC3209], [RFC3473] and 1440 [RFC3477]. That is, the object is constructed from a series of sub- 1441 objects. Any RSVP RRO sub-object already defined or that could be 1442 defined in the future for use in the RRO is acceptable in this 1443 object. 1445 The meanings of all of the sub-objects and fields in this object are 1446 identical to those defined for the RRO. 1448 PCEP RRO sub-object types correspond to RSVP RRO sub-object types. 1450 RRO Object-Class is to be assigned by IANA (recommended value=8) 1452 RRO Object-Type is to be assigned by IANA (recommended value=1) 1454 7.10. LSPA Object 1456 The LSPA object is optional and specifies various TE LSP attributes 1457 to be taken into account by the PCE during path computation. The 1458 LSPA (LSP Attributes) object can either be carried within a PCReq 1459 message or a PCRep message in case of unsuccessful path computation 1460 (in this case, the PCRep message also contains a NO-PATH object and 1461 the LSPA object is used to indicate the set of constraint(s) that 1462 could not be satisfied). Most of the fields of the LSPA object are 1463 identical to the fields of the SESSION-ATTRIBUTE object defined in 1464 [RFC3209] and [RFC4090]. When absent from the PCReq message, this 1465 means that the Setup and Holding priorities are equal to 0, and there 1466 are no affinity constraints. 1468 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1470 LSPA Object-Types is to be assigned by IANA (recommended value=1) 1472 The format of the LSPA object body is: 1474 0 1 2 3 1475 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 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Exclude-any | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Include-any | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | Include-all | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | Setup Prio | Holding Prio | Flags |L| Reserved | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | | 1486 // Optional TLV(s) // 1487 | | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 Figure 16: LSPA object body format 1491 Setup Prio (Setup Priority - 8 bits). The priority of the session 1492 with respect to taking resources, in the range of 0 to 7. The value 1493 0 is the highest priority. The Setup Priority is used in deciding 1494 whether this session can preempt another session. 1496 Holding Prio (Holding Priority - 8 bits). The priority of the 1497 session with respect to holding resources, in the range of 0 to 7. 1498 The value 0 is the highest priority. Holding Priority is used in 1499 deciding whether this session can be preempted by another session. 1500 Flags 1502 The flag L corresponds to the "Local protection desired" bit 1503 ([RFC3209]) of the SESSION-ATTRIBUTE Object. 1505 L Flag (Local protection desired). When set, this means that the 1506 computed path must include links protected with Fast Reroute as 1507 defined in [RFC4090]. 1509 Reserved (8 bits): This field MUST be set to zero on transmission and 1510 MUST be ignored on receipt. 1512 Note that the Optional TLV field may contain additional TE LSP 1513 attributes as defined in [RFC4420]. 1515 7.11. IRO Object 1517 The IRO (Include Route Object) object is optional and can be used to 1518 specify that the computed path MUST traverse a set of specified 1519 network elements. The IRO object MAY be carried within PCReq and 1520 PCRep messages. When carried within a PCRep message with the NO-PATH 1521 object, the IRO indicates the set of elements that fail the PCE to 1522 find a path. 1524 IRO Object-Class is to be assigned by IANA (recommended value=10) 1526 IRO Object-Type is to be assigned by IANA (recommended value=1) 1528 0 1 2 3 1529 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 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | | 1532 // (Subobjects) // 1533 | | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 Figure 17: IRO object body format 1537 Subobjects The IRO object is made of sub-object(s) identical to the 1538 ones defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs. 1540 The following subobject types are supported. 1542 Type Subobject 1543 1 IPv4 prefix 1544 2 IPv6 prefix 1545 4 Unnumbered Interface ID 1546 32 Autonomous system number 1547 The L bit of such sub-object has no meaning within an IRO object. 1549 7.12. SVEC Object 1551 7.12.1. Notion of Dependent and Synchronized path computation requests 1553 Independent versus dependent path computation requests: path 1554 computation requests are said to be independent if they are not 1555 related to each other. Conversely a set of dependent path 1556 computation requests is such that their computations cannot be 1557 performed independently of each other (a typical example of dependent 1558 requests is the computation of a set of diverse paths. 1560 Synchronized versus non-synchronized path computation requests: a set 1561 of path computation requests is said to be non-synchronized if their 1562 respective treatment (path computations) can be performed by a PCE in 1563 a serialized and independent fashion. 1565 There are various circumstances where the synchronization of a set of 1566 path computations may be beneficial or required. 1568 Consider the case of a set of N TE LSPs for which a PCC needs to send 1569 path computation requests to a PCE. The first solution consists of 1570 sending N separate PCReq messages to the selected PCE. In this case, 1571 the path computation requests are non synchronized. Note that the 1572 PCC may chose to distribute the set of N requests across K PCEs for 1573 load balancing purpose. Considering that M (with M+-+-+-+-+-+-+ | | 2308 | | | KeepWait |----+ | 2309 | +--| |<---+ | 2310 |+-----+-+-+-+-+-+-+ | | 2311 || | | | 2312 || | | | 2313 || V | | 2314 || +->+-+-+-+-+-+-+----+ | 2315 || | | OpenWait |-------+ 2316 || +--| |<------+ 2317 ||+----+-+-+-+-+-+-+<---+ | 2318 ||| | | | 2319 ||| | | | 2320 ||| V | | 2321 ||| +->+-+-+-+-+-+-+ | | 2322 ||| | |TCPPending |----+ | 2323 ||| +--| | | 2324 |||+---+-+-+-+-+-+-+<---+ | 2325 |||| | | | 2326 |||| | | | 2327 |||| V | | 2328 |||+--->+-+-+-+-+ | | 2329 ||+---->| Idle |-------+ | 2330 |+----->| |----------+ 2331 +------>+-+-+-+-+ 2333 Figure 23: PCEP Finite State Machine for the PCC 2335 PCEP defines the following set of variables: 2337 TCPConnect: timer (in seconds) started after having initialized a TCP 2338 connection using the PCEP well-known TCP port. The value of the 2339 TCPConnect timer is 60 seconds. 2341 TCPRetry: specifies the number of times the system has tried to 2342 establish a TCP connection with a PCEP peer without success. 2344 TCPMaxRetry: Maximum number of times the system tries to establish a 2345 TCP connection using the PCEP well-known TCP port before going back 2346 to the Idle state. The value of the TCPMaxRetry is 5. 2348 OpenWait: timer (in seconds) that corresponds to the amount of time a 2349 PCEP peer will wait to receive an Open message from the PCEP peer 2350 after the expiration of which the system releases the PCEP resource 2351 and go back to the Idle state. 2353 KeepWait: timer that corresponds to the amount of time a PCEP peer 2354 will wait to receive a KeepAlive or a PCErr message from the PCEP 2355 peer after the expiration of which the system releases the PCEP 2356 resource and go back to the Idle state. The KeepWait timer has a 2357 fixed value of 1 minute. 2359 OpenRetry: specifies the number of times the system has received an 2360 Open message with unacceptable PCEP session characteristics. 2362 The following two states variable are defined: 2364 RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system 2365 has received an acceptable Open message. 2367 LocalOK: the LocalOK variable is a Boolean set to 1 if the system has 2368 received a Keepalive message acknowledging that the Open message sent 2369 to the peer was valid. 2371 Idle State: 2373 The idle state is the initial PCEP state where PCEP (also referred to 2374 as "the system") waits for an initialization event that can either be 2375 manually triggered by the user (configuration) or automatically 2376 triggered by various events. In Idle state, PCEP resources are 2377 allocated (memory, potential process, ...) but no PCEP messages are 2378 accepted from any PCEP peer. The system listens the well-known PCEP 2379 TCP port. 2381 The following set of variable are initialized: 2383 TCPRetry=0, 2384 LocalOK=0, 2386 RemoteOK=0, 2388 OpenRetry=0. 2390 Upon detection of a local initialization event (e.g. user 2391 configuration to establish a PCEP session with a particular PCEP 2392 peer, local event triggering the establishment of a PCEP session with 2393 a PCEP peer, ...), the system: 2395 o Starts the TCPConnect timer, 2397 o Initiates of a TCP connection with the PCEP peer, 2399 o Increments the TCPRetry variable, 2401 o Moves to the TCPPending state. 2403 Upon receiving a TCP connection on the well-known PCEP TCP port, if 2404 the PCE is in congested state, the PCE MUST immediately send a PCErr 2405 with Notification-type=2, Notification-value=1 along with the 2406 optional CONGESTION-DURATION TLV (see Section 7.13). 2408 Upon receiving a TCP connection on the well-known PCEP TCP port, if 2409 the TCP connection establishment succeeds, the system: 2411 o Sends an Open message, 2413 o Starts the OpenWait timer, 2415 o Stars the KeepWait timer, 2417 o Moves to the OpenWait state. 2419 It is expected that an implementation will use an exponentially 2420 increase timer between automatically generated Initialization events 2421 and between retrials of TCP connection establishments. 2423 TCPPending State 2425 If the TCP connection establishment succeeds, the system: 2427 o Sends an Open message, 2429 o Starts the OpenWait timer, 2430 o Starts the KeepWait timer, 2432 o Moves to the OpenWait state. 2434 If the TCP connection establishment fails (an error is detected 2435 during the TCP connection establishment) or the TCPConnectTimer 2436 expires: 2438 If TCPRetry =TCPMaxRetry the system moves to the Idle State 2440 If TCPRetry < TCPMaxRetry the system: 2442 o Starts the TCPConnect timer, 2444 o Initiates of a TCP connection with the PCEP peer, 2446 o Increments the TCPRetry variable, 2448 o Stays in the TPCPending state. 2450 If the system detects that the PCEP peer tries to simultaneously 2451 establish a TCP connection, it stops the TCP connection establishment 2452 if and only if the PCEP peer has a higher IP address and moves to the 2453 Idle state. This guarantees that in case of "collision" a single TCP 2454 connection is established. 2456 OpenWait State: 2458 In the OpenWait state, the system waits for an Open message from its 2459 PCEP peer. 2461 If the system receives an Open message from the PCEP peer before the 2462 expiration of the OpenWait timer, PCEP checks the PCEP session 2463 attributes (Keepalive frequency, DeadTimer, ...). 2465 If an error is detected (e.g. malformed Open message, presence of two 2466 Open objects, ...), PCEP generates an error notification, the PCEP 2467 peer sends a PCErr message with Error-Type=1 and Error-value=1. The 2468 system releases the PCEP resources for the PCEP peer, closes the TCP 2469 connection and moves to the Idle state. 2471 If no errors are detected, PCEP increments the OpenRetry variable. 2473 If OpenRetry=2, the PCEP peer sends a PCErr with Error-Type=1 and 2474 Error-value=5, the system releases the PCEP resources for that peer, 2475 and moves back to the Idle state. 2477 If no errors are detected and the session characteristics are 2478 acceptable to the local system, the system: 2480 o Sends a Keepalive message to the PCEP peer, 2482 o Starts the Keepalive timer, 2484 o Sets the RemoteOK variable to 1. 2486 If LocalOK=1 the system moves to the UP state. 2488 If LocalOK=0 the system moves to the KeepWait state. 2490 If no errors are detected but the session characteristics are 2491 unacceptable and non-negotiable, the PCEP peer sends a PCErr with 2492 Error-Type=1 and Error-value=3, the system releases the PCEP 2493 resources for that peer, and moves back to the Idle state. 2495 If no errors are detected, OpenRetry=1, the session characteristics 2496 are unacceptable but negotiable (such as the Keepalive frequency or 2497 the DeadTimer), the system: 2499 o sends a PCErr message with Error-Type=1 and Error-value=4 that 2500 contains proposed acceptable session characteristics, 2502 o If LocalOK=1, the system stays in the OpenWait state 2504 o If LocalOK=0, the system moves to the KeepWait state 2506 If no Open message is received before the expiration of the OpenWait 2507 timer, the PCEP peer sends a PCErr message with Error-Type=1 and 2508 Error-value=2, the system releases the PCEP resources for the PCEP 2509 peer, closes the TCP connection and moves to the Idle state. 2511 KeepWait State 2513 In the Keepwait state, the system waits for the receipt of a 2514 Keepalive from its PCEP peer acknowledging its Open message or a 2515 PCErr message in response to unacceptable PCEP session 2516 characteristics proposed in the Open message. 2518 If a Keepalive message is received before the expiration of the 2519 KeepWait timer, LocalOK=1 2521 If RemoteOK=1, the system moves to the UP state. 2523 If RemoteOK=0, the system moves to the OpenWait State. 2525 If a PCErr message is received before the expiration of the KeepWait 2526 timer: 2528 1. If the proposed values are unacceptable, the PCEP peer sends a 2529 PCErr message with Error-Type=1 and Error-value=6 and the system 2530 releases the PCEP resources for that PCEP peer, closes the TCP 2531 connection and moves to the Idle state. 2533 2. If the proposed values are acceptable, the system adjusts its 2534 PCEP session characteristics according to the proposed values 2535 received in the PCErr message restarts the KeepWait timer and 2536 sends a new Open message. If RemoteOK=1, the system stays in the 2537 KeepWait state. If RemoteOK=0, the system moves to the OpenWait 2538 state. 2540 If neither a Keepalive nor a PCErr is received after the expiration 2541 of the KeepWait timer, the PCEP peer sends a PCErr message with 2542 Error-Type=1 and Error-value=7 and, system releases the PCEP 2543 resources for that PCEP peer, closes the TCP connection and moves to 2544 the Idle State. 2546 UP State 2548 In the UP state, the PCEP peer starts exchanging PCEP messages 2549 according to the session characteristics. 2551 If the Keepalive timer expires, the system sends a Keepalive message. 2553 If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from 2554 the PCEP peer after the expiration of the DeadTimer, the systems 2555 sends a PCErr message with a PCEP-ERROR object (Error-type=9, Error- 2556 value=1), terminates PCEP session according to the procedure defined 2557 in Section 6.8, releases the PCEP resources for that PCEP peer, 2558 closes the TCP connection and moves to the Idle State. 2560 If a malformed message is received, the system terminates the PCEP 2561 session according to the procedure defined in Section 6.8, the system 2562 releases the PCEP resources for that PCEP peer, closes the TCP 2563 connection and moves to the Idle State. 2565 If the TCP connection fails, the system releases the PCEP resources 2566 for that PCEP peer, closes the TCP connection and moves to the Idle 2567 State. 2569 11. Security Considerations 2571 PCEP could be the target of the following attacks: 2573 o Spoofing (PCC or PCE impersonation) 2575 o Snooping (message interception) 2577 o Falsification 2579 o Denial of Service 2581 A PCEP attack may have significant impact, particularly in an 2582 inter-AS context as PCEP facilitates inter-AS path establishment. 2583 Several mechanisms are proposed below, so as to ensure 2584 authentication, integrity and privacy of PCEP Communications, and 2585 also to protect against DoS attacks. 2587 11.1. PCEP Authentication and Integrity 2589 It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to 2590 provide for the authenticity and integrity of PCEP messages. This 2591 will allow protecting against PCE or PCC impersonation and also 2592 against message content falsification. 2594 This requires the maintenance, exchange and configuration of MD-5 2595 keys on PCCs and PCEs. Note that such maintenance may be especially 2596 onerous to the operators as pointed out in 2597 [I-D.ietf-rpsec-bgpsecrec]. Hence it is important to limit the 2598 number of keys while ensuring the required level of security. 2600 MD-5 signature faces some limitations, as per explained in [RFC2385]. 2601 Note that when one digest technique stronger than MD5 is specified 2602 and implemented, PCEP could be easily upgraded to use it. 2604 11.2. PCEP Privacy 2606 Ensuring PCEP communication privacy is of key importance, especially 2607 in an inter-AS context, where PCEP communication end-points do not 2608 reside in the same AS, as an attacker that intercept a PCE message 2609 could obtain sensitive information related to computed paths and 2610 resources. Privacy can be ensured thanks to encryption. To ensure 2611 privacy of PCEP communication, IPSec [RFC2406] tunnels MAY be used 2612 between PCC and PCEs or between PCEs. Note that this could also be 2613 used to ensure Authentication and Integrity, in which case, TCP MD-5 2614 option would not be required. 2616 11.3. Protection against Denial of Service attacks 2618 PCEP can be the target of TCP DoS attacks, such as for instance SYN 2619 attacks, as all protocols running on top of TCP. PCEP can use the 2620 same mechanisms as defined in [RFC3036] to mitigate the threat of 2621 such attacks: 2623 o A PCE should avoid promiscuous TCP listens for PCEP TCP session 2624 establishment. It should use only listens that are specific to 2625 authorized PCCs. 2627 o The use of the MD5 option helps somewhat since it prevents a SYN 2628 from being accepted unless the MD5 segment checksum is valid. 2629 However, the receiver must compute the checksum before it can 2630 decide to discard an otherwise acceptable SYN segment. 2632 o The use of access-list on the PCE so as to restrict access to 2633 authorized PCCs. 2635 11.4. Request input shaping/policing 2637 A PCEP implementation may be subject to Denial Of Service attacks 2638 consisting of sending a very large number of PCEP messages (e.g. 2639 PCReq messages). Thus, especially in multi-Service Providers 2640 environments, a PCE implementation should implement request input 2641 shaping/policing so as to throttle the amount of received PCEP 2642 messages without compromising the implementation behavior. 2644 12. Authors' addresses 2646 This document was the collective work of several authors. The 2647 content of this document was contributed by the editors and the co- 2648 authors listed below: 2650 Arthi Ayyangar 2651 Nuova Systems 2652 2600 San Tomas Expressway 2653 Santa Clara, CA 95051 2654 USA 2656 Email: arthi@nuovasystems.com 2658 Eiji Oki 2659 NTT 2660 Midori 3-9-11 2661 Musashino, Tokyo, 180-8585 2662 JAPAN 2664 Email: oki.eiji@lab.ntt.co.jp 2666 Alia Atlas 2667 Google 2668 1600 Amphitheatre Parkway 2669 Montain View, CA 94043 2670 USA 2672 Email: akatlas@alum.mit.edu 2674 Andrew Dolganow 2675 Alcatel 2676 600 March Road 2677 Ottawa, ON K2K 2E6 2678 CANADA 2680 Email: andrew.dolganow@alcatel.com 2682 Yuichi Ikejiri 2683 NTT Communications Corporation 2684 1-1-6 Uchisaiwai-cho, Chiyoda-ku 2685 Tokyo, 100-819 2686 JAPAN 2688 Email: y.ikejiri@ntt.com 2690 Kenji Kumaki 2691 KDDI Corporation 2692 Garden Air Tower Iidabashi, Chiyoda-ku, 2693 Tokyo, 102-8460 2694 JAPAN 2696 Email: ke-kumaki@kddi.com 2698 13. Acknowledgements 2700 The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash, 2701 Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard 2702 Douville and Jon Parker for their very valuable input. Special thank 2703 to Adrian Farrel for his very valuable suggestions. 2705 14. References 2706 14.1. Normative References 2708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2709 Requirement Levels", BCP 14, RFC 2119, March 1997. 2711 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2712 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2713 Functional Specification", RFC 2205, September 1997. 2715 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2716 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2717 Tunnels", RFC 3209, December 2001. 2719 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2720 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2721 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2723 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 2724 in Resource ReSerVation Protocol - Traffic Engineering 2725 (RSVP-TE)", RFC 3477, January 2003. 2727 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 2728 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 2729 May 2005. 2731 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2732 Element (PCE)-Based Architecture", RFC 4655, August 2006. 2734 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 2735 Communication Protocol Generic Requirements", RFC 4657, 2736 September 2006. 2738 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 2739 (PCE) Discovery", RFC 4674, October 2006. 2741 14.2. Informative References 2743 [I-D.ietf-ccamp-inter-domain-rsvp-te] 2744 Ayyangar, A. and J. Vasseur, "Inter domain MPLS and GMPLS 2745 Traffic Engineering - RSVP-TE extensions", 2746 draft-ietf-ccamp-inter-domain-rsvp-te-04 (work in 2747 progress), January 2007. 2749 [I-D.ietf-pce-disco-proto-isis] 2750 Roux, J., "IS-IS protocol extensions for Path Computation 2751 Element (PCE) Discovery", 2752 draft-ietf-pce-disco-proto-isis-01 (work in progress), 2753 December 2006. 2755 [I-D.ietf-pce-disco-proto-ospf] 2756 Roux, J., "OSPF protocol extensions for Path Computation 2757 Element (PCE) Discovery", 2758 draft-ietf-pce-disco-proto-ospf-01 (work in progress), 2759 December 2006. 2761 [I-D.ietf-pce-inter-layer-req] 2762 Oki, E., "PCC-PCE Communication Requirements for Inter- 2763 Layer Traffic Engineering", 2764 draft-ietf-pce-inter-layer-req-03 (work in progress), 2765 October 2006. 2767 [I-D.ietf-pce-interas-pcecp-reqs] 2768 Bitar, N., "Inter-AS Requirements for the Path Computation 2769 Element Communication Protocol (PCECP)", 2770 draft-ietf-pce-interas-pcecp-reqs-01 (work in progress), 2771 October 2006. 2773 [I-D.ietf-pce-pcecp-interarea-reqs] 2774 Roux, J., "PCE Communication Protocol (PCECP) Specific 2775 Requirements for Inter-Area Multi Protocol Label 2776 Switching (MPLS) and Generalized MPLS (GMPLS) Traffic 2777 Engineering", draft-ietf-pce-pcecp-interarea-reqs-05 (work 2778 in progress), December 2006. 2780 [I-D.ietf-rpsec-bgpsecrec] 2781 Christian, B. and T. Tauber, "BGP Security Requirements", 2782 draft-ietf-rpsec-bgpsecrec-06 (work in progress), 2783 June 2006. 2785 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2786 April 1992. 2788 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 2789 Signature Option", RFC 2385, August 1998. 2791 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 2792 Payload (ESP)", RFC 2406, November 1998. 2794 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2795 B. Thomas, "LDP Specification", RFC 3036, January 2001. 2797 [RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and 2798 T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric 2799 as a second MPLS Traffic Engineering (TE) Metric", BCP 87, 2800 RFC 3785, May 2004. 2802 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 2803 June 2005. 2805 [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A. 2806 Ayyangar, "Encoding of Attributes for Multiprotocol Label 2807 Switching (MPLS) Label Switched Path (LSP) Establishment 2808 Using Resource ReserVation Protocol-Traffic Engineering 2809 (RSVP-TE)", RFC 4420, February 2006. 2811 Appendix A. Compliance with the PCECP Requirement Document 2813 The aim of this section is to list the set of requirements set forth 2814 in [RFC4657] that are not satisfied by the current revision of this 2815 document. This only concerns the requirements listed as MUST 2816 according to [RFC2119]. 2818 Here is the list of currently unsatisfied requirements: 2820 o Allow to select/prefer from advertised list of standard objective 2821 functions/options 2823 o Allow to customize objective function/options 2825 o Support "unsynchronized" & "synchronized" objective functions 2827 PCEP is a flexible protocol allowing for the addition of new message 2828 and objects type. With regards to the requirement liste above, the 2829 Working Group has decided to cover those requirements in a separate 2830 document. 2832 Appendix B. PCEP Variables 2834 PCEP defines the following configurable variables: 2836 KeepAlive timer: minimum period of time between the sending of PCEP 2837 messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A 2838 suggested value for the Keepalive timer is 30 seconds. 2840 DeadTimer: period of timer after the expiration of which a PCEP peer 2841 declared the session down if no PCEP message has been received. 2843 SyncTimer: the SYNC timer is used in the case of synchronized path 2844 computation request using the SVEC object defined in Section 7.12.3. 2845 Consider the case where a PCReq message is received by a PCE that 2846 contains the SVEC object referring to M synchronized path computation 2847 requests. If after the expiration of the SYNC timer all the M path 2848 computation requests have not been received, a protocol error is 2849 triggered and the PCE MUST cancel the whole set of path computation 2850 requests. A RECOMMENDED value for the SYNC timer is 60 seconds. 2852 Authors' Addresses 2854 JP Vasseur (editor) 2855 Cisco Systems, Inc 2856 1414 Massachusetts Avenue 2857 Boxborough, MA 01719 2858 USA 2860 Email: jpv@cisco.com 2862 JL Le Roux (editor) 2863 France Telecom 2864 2, Avenue Pierre-Marzin 2865 Lannion, 22307 2866 FRANCE 2868 Email: jeanlouis.leroux@orange-ftgroup.com 2870 Full Copyright Statement 2872 Copyright (C) The IETF Trust (2007). 2874 This document is subject to the rights, licenses and restrictions 2875 contained in BCP 78, and except as set forth therein, the authors 2876 retain all their rights. 2878 This document and the information contained herein are provided on an 2879 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2880 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2881 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2882 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2883 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2884 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2886 Intellectual Property 2888 The IETF takes no position regarding the validity or scope of any 2889 Intellectual Property Rights or other rights that might be claimed to 2890 pertain to the implementation or use of the technology described in 2891 this document or the extent to which any license under such rights 2892 might or might not be available; nor does it represent that it has 2893 made any independent effort to identify any such rights. Information 2894 on the procedures with respect to rights in RFC documents can be 2895 found in BCP 78 and BCP 79. 2897 Copies of IPR disclosures made to the IETF Secretariat and any 2898 assurances of licenses to be made available, or the result of an 2899 attempt made to obtain a general license or permission for the use of 2900 such proprietary rights by implementers or users of this 2901 specification can be obtained from the IETF on-line IPR repository at 2902 http://www.ietf.org/ipr. 2904 The IETF invites any interested party to bring to its attention any 2905 copyrights, patents or patent applications, or other proprietary 2906 rights that may cover technology that may be required to implement 2907 this standard. Please address the information to the IETF at 2908 ietf-ipr@ietf.org. 2910 Acknowledgment 2912 Funding for the RFC Editor function is provided by the IETF 2913 Administrative Support Activity (IASA).