idnits 2.17.1 draft-ietf-pce-pcep-05.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 on line 2816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2840. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (January 12, 2007) is 6307 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 2652, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-inter-domain-rsvp-te' is defined on line 2684, 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) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 10 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: July 16, 2007 France Telecom 5 January 12, 2007 7 Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 8 draft-ietf-pce-pcep-05.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 July 16, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (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 MPLS and GMPLS Traffic 47 Engineering. The PCEP protocol is designed to be flexible and 48 extensible so as to easily allow for the addition of further messages 49 and objects, should further requirements be expressed in the future. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Transport protocol . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Architectural Protocol Overview (Model) . . . . . . . . . . . 6 64 5.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Architectural Protocol Overview . . . . . . . . . . . . . 6 66 5.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 7 67 5.2.2. Path computation request sent by a PCC to a PCE . . . 8 68 5.2.3. Path computation reply sent by the PCE to a PCC . . . 9 69 5.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 11 70 5.2.5. Termination of the PCEP Session . . . . . . . . . . . 12 71 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 13 72 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 13 73 6.2. Open message . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.3. Keepalive message . . . . . . . . . . . . . . . . . . . . 15 75 6.4. Path Computation Request (PCReq) message . . . . . . . . . 16 76 6.5. Path Computation Reply (PCRep) message . . . . . . . . . . 17 77 6.6. Notification (PCNtf) message . . . . . . . . . . . . . . . 18 78 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 19 79 6.8. Close message . . . . . . . . . . . . . . . . . . . . . . 20 80 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 20 81 7.1. Common object header . . . . . . . . . . . . . . . . . . . 20 82 7.2. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 22 83 7.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 23 84 7.3.1. Object definition . . . . . . . . . . . . . . . . . . 23 85 7.3.2. Handling of the RP object . . . . . . . . . . . . . . 25 86 7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 26 87 7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 28 88 7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 29 89 7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 30 90 7.8. ERO Object . . . . . . . . . . . . . . . . . . . . . . . . 33 91 7.9. RRO Object . . . . . . . . . . . . . . . . . . . . . . . . 33 92 7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 34 93 7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 36 94 7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 36 95 7.12.1. Notion of Dependent and Synchronized path 96 computation requests . . . . . . . . . . . . . . . . . 36 97 7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 38 98 7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 39 99 7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 40 100 7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 43 101 7.15. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 46 102 7.16. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 47 103 8. Manageability Considerations . . . . . . . . . . . . . . . . . 48 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 105 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 48 106 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 49 107 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 49 108 9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 50 109 9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 51 110 9.6. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 52 111 10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 53 112 11. Security Considerations . . . . . . . . . . . . . . . . . . . 58 113 11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 59 114 11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 59 115 11.3. Protection against Denial of Service attacks . . . . . . . 59 116 11.4. Request input shaping/policing . . . . . . . . . . . . . . 60 117 12. Authors' addresses . . . . . . . . . . . . . . . . . . . . . . 60 118 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 119 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 120 14.1. Normative References . . . . . . . . . . . . . . . . . . . 61 121 14.2. Informative References . . . . . . . . . . . . . . . . . . 62 122 Appendix A. Compliance with the PCECP Requirement Document . . . 63 123 Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 64 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 125 Intellectual Property and Copyright Statements . . . . . . . . . . 66 127 1. Terminology 129 Terminology used in this document 131 Explicit path: full explicit path from start to destination made of a 132 list of strict hops where a hop may be an abstract node such as an 133 AS. 135 IGP Area: OSPF Area or IS-IS level. 137 Inter-domain TE LSP: A TE LSP whose path transits across at least two 138 different domains where a domain can either be an IGP area, an 139 Autonomous System or a sub-AS (BGP confederations). 141 PCC: Path Computation Client: any client application requesting a 142 path computation to be performed by a Path Computation Element. 144 PCE: Path Computation Element: an entity (component, application or 145 network node) that is capable of computing a network path or route 146 based on a network graph and applying computational constraints. 148 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the 149 PCE). 151 TED: Traffic Engineering Database which contains the topology and 152 resource information of the domain. The TED may be fed by IGP 153 extensions or potentially by other means. 155 TE LSP: Traffic Engineering Label Switched Path. 157 Strict/loose path: mix of strict and loose hops comprising of at 158 least one loose hop representing the destination where a hop may be 159 an abstract node such as an AS. 161 Within this document, when describing PCE-PCE communications, the 162 requesting PCE fills the role of a PCC. This provides a saving in 163 documentation without loss of function. 165 2. Introduction 167 [RFC4655]describes the motivations and architecture for a PCE-based 168 model for the computation of MPLS and GMPLS TE LSPs. The model 169 allows the separation of PCE from PCC, and allows cooperation between 170 PCEs. This necessitates a communication protocol between PCC and 171 PCE, and between PCEs. 173 [RFC4657] states the generic requirements for such a protocol 174 including the requirement for using the same protocol between PCC and 175 PCE, and between PCEs. Additional application-specific requirements 176 (for scenarios such as inter-area, inter-AS, etc.) are not included 177 in [RFC4657], but there is a requirement that any solution protocol 178 must be easily extensible to handle other requirements as they are 179 introduced in application-specific requirements documents. Examples 180 of such application-specific requirements are 181 [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. 187 Such interactions include path computation requests and path 188 computation replies as well as notifications of specific states 189 related to the use of a PCE in the context of MPLS and GMPLS Traffic 190 Engineering. 192 The PCEP protocol is designed to be flexible and extensible so as to 193 easily allow for the addition of further messages and objects, should 194 further 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. Transport protocol 218 PCEP operates over TCP using a well-known TCP port (to be assigned by 219 IANA). This allows the requirements of reliable messaging and flow 220 control to be met without further protocol work. 222 An implementation may decide to keep the TCP session alive for an 223 unlimited time (this may for instance be appropriate when path 224 computation requests are sent on a frequent basis so as to avoid to 225 open a TCP session each time a path computation request is needed 226 that would incur additional processing delays). Conversely, in some 227 other circumstances, it may be desirable to systematically open and 228 close the TCP connection for each PCEP request (for instance when 229 sending of path computation request is a rare event). 231 5. Architectural Protocol Overview (Model) 233 The aim of this section is to describe the PCEP protocol model in the 234 spirit of [RFC4101]. An architecture protocol overview (the big 235 picture of the protocol) is provided in this section. Protocol 236 details can be found in further sections. 238 5.1. Problem 240 The PCE-based architecture used for the computation of MPLS and GMPLS 241 TE LSP is described in [RFC4655]. When the PCC and the PCE are not 242 collocated, a communication protocol between the PCC and the PCE is 243 needed. PCEP is such a protocol designed specifically for 244 communications between a PCC and a PCE or between two PCEs: a PCC may 245 use PCEP to send a path computation request for one or more TE LSP(s) 246 to a PCE and such a PCE may reply with a set of computed path(s) if 247 one or more path(s) satisfying the set of constraints can be found. 249 5.2. Architectural Protocol Overview 251 PCEP operates over TCP, which allows the requirements of reliable 252 messaging and flow control to be met without further protocol work. 254 Several PCEP messages are defined: 256 - Open and Keepalive messages are used to initiate and maintain a 257 PCEP session respectively. 259 - PCReq: a PCEP message sent by a PCC to a PCE to request a path 260 computation. 262 - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path 263 computation request. A PCRep message can either contain a set of 264 computed path(s) if the request could be satisfied or a negative 265 reply otherwise. 267 - PCNtf: a PCEP notification message either sent by a PCC to a PCE or 268 a PCE to a PCC to notify of specific event. 270 - PCErr: a PCEP message sent upon the occurrence of a protocol error 271 condition. 273 - Close message: a message used to close a PCEP session. 275 The set of available PCE(s) may be either statically configured on a 276 PCC or dynamically discovered. 278 The mechanisms used to discover one or more PCE(s) and to select a 279 PCE are out of the scope of this document. 281 A PCC may have PCEP sessions with more than one PCE and similarly a 282 PCE may have PCEP sessions with multiple PCCs. 284 The establishment of a PCEP session is always inititated by the PCC. 286 5.2.1. Initialization Phase 288 The initialization phase consists of two successive steps (described 289 in a schematic form in Figure 1): 291 1) Establishment of a TCP connection (3-way handshake) between the 292 PCC and the PCE. 294 2) Establishment of a PCEP session over the TCP connection. 296 Once the TCP connection is established, the PCC and the PCE (also 297 referred to as "PCEP peers") initiate a PCEP session establishment 298 during which various session parameters are negotiated. These 299 parameters are carried within Open messages and include the keepalive 300 timer, the Deadtimer and potentially other detailed capabilities and 301 policy rules that specify the conditions under which path computation 302 requests may be sent to the PCE. If the PCEP session establishment 303 phase fails because the PCEP peers disagree on the exchanged 304 parameters or one of the PCEP peers does not answer after the 305 expiration of the establishment timer, the TCP connection is 306 immediately closed. Successive retries are permitted but an 307 implementation SHOULD make use of an exponential back-off session 308 establishment retry procedure. 310 Keepalive messages are used to acknowledge Open messages and once the 311 PCEP session has been successfully established, Keepalive messages 312 are exchanged between PCEP peers to ensure the liveness of the PCEP 313 session. 315 A single PCEP session can exist between a pair a PCEP peers. 317 Details about the Open message and the Keepalive messages can be 318 found in . (Section 6.2) and Section 6.3 respectively. 320 +-+-+ +-+-+ 321 |PCC| |PCE| 322 +-+-+ +-+-+ 323 | | 324 |---- Open message --->| 325 | | 326 |<--- Open message ----| 327 | | 328 | | 329 | | 330 |<--- Keepalive -------| 331 | | 332 |---- Keepalive ------>| 334 Figure 1: PCEP Initialization phase (initiated by a PCC) 336 5.2.2. Path computation request sent by a PCC to a PCE 338 +-+-+ +-+-+ 339 |PCC| |PCE| 340 +-+-+ +-+-+ 341 1)Path computation | | 342 event | | 343 2)PCE Selection | | 344 3)Path computation |---- PCReq message--->| 345 request sent to | | 346 the selected PCE | | 348 Figure 2: Path computation request 350 Once a PCC (or a PCE) has successfully established a PCEP session 351 with one or more PCEs, if an event is triggered that requires the 352 computation of a set of path(s), the PCC first selects one of more 353 PCE(s) to send the request to. Note that the PCE selection decision 354 process may have taken place prior to the PCEP session establishment. 356 Once the PCC has selected a PCE, it sends a path computation request 357 to the PCE (PCReq message) that contains a variety of objects that 358 specify the set of constraints and attributes for the path to be 359 computed. For example "Compute a TE LSP path with source IP 360 address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B 361 Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may 362 desire to specify the urgency of such request by assigning a request 363 priority. Each request is uniquely identified by a request-id number 364 and the PCC-PCE address pair. The process is shown in a schematic 365 form in figure 2. 367 Details about the PCReq message can be found in Section 6.4 369 5.2.3. Path computation reply sent by the PCE to a PCC 370 +-+-+ +-+-+ 371 |PCC| |PCE| 372 +-+-+ +-+-+ 373 | | 374 |---- PCReq message--->| 375 | |1) Path computation 376 | |request received 377 | | 378 | |2)Path successfully 379 | |computed 380 | | 381 | |3) Computed path(s) sent 382 | |to the PCC 383 |<--- PCRep message ---| 384 | (Positive reply) | 386 Figure 3a: Path computation request with successful path computation 388 +-+-+ +-+-+ 389 |PCC| |PCE| 390 +-+-+ +-+-+ 391 | | 392 | | 393 |---- PCReq message--->| 394 | |1) Path computation 395 | |request received 396 | | 397 | |2) No Path found that 398 | |satisfies the request 399 | | 400 | |3) Negative reply sent to 401 | |the PCC (optionally with 402 | |various additional 403 | |information) 404 |<--- PCRep message ---| 405 | (Negative reply) | 407 Figure 3b: Path computation request with unsuccessful path computation 408 Upon receiving a path computation request from a PCC, the PCE 409 triggers a path computation, the result of which can either be: 411 - Positive (Figure 3-a): the PCE manages to compute a path satisfying 412 the set of required constraints, in which case the PCE returns the 413 set of computed path(s) to the requesting PCC. Note that PCEP 414 supports the capability to send a single request which requires the 415 computation of more than one path (e.g. computation of a set of link- 416 diverse paths). 418 - Negative (Figure 3-b): no path could be found that satisfies the 419 set of constraints. In this case, a PCE may provide the set of 420 constraints that led to the path computation failure. Upon receiving 421 a negative reply, a PCC may decide to resend a modified request or 422 take any other appropriate action. 424 Details about the PCRep message can be found in Section 6.5. 426 5.2.4. Notification 428 There are several circumstances whereby a PCE may want to notify a 429 PCC of a specific event. For example, suppose that the PCE suddenly 430 experiences some congestion that would lead to unacceptable response 431 times. The PCE may want to notify one or more PCCs that some of 432 their requests (listed in the notification) will not be satisfied or 433 may experience unacceptable delays. Upon receiving such 434 notification, the PCC may decide to redirect it(s) path computation 435 request(s) towards another PCE, if an alternate PCE is available. 436 Similarly, a PCC may desire to notify a PCE of particular event such 437 as the cancellation of pending request(s). 439 +-+-+ +-+-+ 440 |PCC| |PCE| 441 +-+-+ +-+-+ 442 1)Path computation | | 443 event | | 444 2)PCE Selection | | 445 3)Path computation |---- PCReq message--->| 446 request X sent to | |4) Path computation 447 the selected PCE | |triggered 448 | | 449 | | 450 5) Path computation| | 451 request X cancelled| | 452 |---- PCNtf message -->| 453 | |6) Path computation 454 | |request X cancelled 456 Figure 4: Example of PCC notification (request cancellation) sent to a PCE 458 +-+-+ +-+-+ 459 |PCC| |PCE| 460 +-+-+ +-+-+ 461 1)Path computation | | 462 event | | 463 2)PCE Selection | | 464 3)Path computation |---- PCReq message--->| 465 request X sent to | |4) Path computation 466 the selected PCE | |triggered 467 | | 468 | | 469 | |5) PCE experiencing 470 | |congestion 471 | | 472 | |6) Path computation 473 | |request X cancelled 474 | | 475 |<--- PCNtf message----| 477 Figure 5: Example of PCE notification (request(s) cancellation) sent to a PCC 479 Details about the PCNtf message can be found in Section 6.6. 481 5.2.5. Termination of the PCEP Session 483 When one of the PCEP peers desires to terminate a PCEP session it 484 first sends a PCEP Close message and then close the TCP connection. 486 If the PCEP session is terminated by the PCE, the PCC clears all the 487 states related to pending requests previously sent to the PCE. 488 Similarly, if the PCC terminates a PCEP session the PCE clears all 489 pending path computation requests sent by the PCC in question as well 490 as the related states. A Close message can only be sent to terminate 491 a PCEP session if the PCEP session has previously been established. 493 In case of TCP connection failure, the PCEP session SHOULD be 494 maintained for a period of time equal to the DeadTimer. 496 Details about the Close message can be found in Section 6.8. 498 6. PCEP Messages 500 A PCEP message consists of a common header followed by a variable 501 length body made of a set of objects that can either be mandatory or 502 optional. In the context of this document, an object is said to be 503 mandatory in a PCEP message when the object MUST be included for the 504 message to be considered as valid. Thus a PCEP message with a 505 missing mandatory object MUST be considered as a malformed message 506 and such condition MUST trigger an Error message. Conversely, if an 507 object is optional, the object may or may not be present. 509 A flag referred to as the P flag is defined in the common header of 510 each PCEP object (see Section 7.1) that can be set by a PCEP peer to 511 enforce a PCE to take into account the related information during the 512 path computation. For example, the METRIC object allows a PCC to 513 specify a bounded acceptable path cost. The COST object is optional 514 but a PCC may set a flag to ensure that such constraint is taken into 515 account. Similarly to the previous case, if such constraint cannot 516 be taken into account by the PCE, this should trigger an Error 517 message. 519 For each PCEP message type a set of rules is defined that specify the 520 set of objects that the message can carry. We use the Backus-Naur 521 Form (BNF) to specify such rules. Square brackets refer to optional 522 sub-sequences. An implementation MUST form the PCEP messages using 523 the object ordering specified in this document. 525 6.1. Common header 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Ver | Flags | Message-Type | Reserved | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Message-Lenght | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Figure 6: PCEP message common header 535 Ver (Version - 4 bits): PCEP protocol version number. Current 536 version is version 1. 538 Flags (8 bits): no flags are currently defined. 540 Message-Type (8 bits): 542 The following message types are currently defined (to be confirmed by 543 IANA). 544 Value Meaning 545 1 Open 546 2 Keepalive 547 3 Path Computation Request 548 4 Path Computation Reply 549 5 Notification 550 6 Error 551 7 Close 552 Message Length (32 bits): total length of the PCEP message expressed 553 in bytes including the common header. 555 6.2. Open message 557 The Open message is a PCEP message sent by a PCC to a PCE and a PCE 558 to a PCC in order to establish a PCEP session. The Message-Type 559 field of the PCEP common header for the Open message is set to 1 (To 560 be confirmed by IANA). 562 Once the TCP connection has been successfully established, the first 563 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 564 an Open message. Any message received prior to an Open message MUST 565 trigger a protocol error condition and the PCEP session MUST be 566 terminated. The Open message is used to establish a PCEP session 567 between the PCEP peers. During the establishment phase the PCEP 568 peers exchange several session characteristics. If both parties 569 agree on such characteristics the PCEP session is successfully 570 established. 572 Open message 573 ::= 574 575 The Open message MUST contain exactly one OPEN object (see 576 Section 7.2). Various session characteristics are specified within 577 the OPEN object. 579 Once an Open message has been sent to a PCEP peer, the sender MUST 580 start an initialization timer called KeepWait after the expiration of 581 which if neither an Open message has been received nor a PCErr 582 message in case of disagreement of the session characteristics, the 583 TCP connection MUST be released (see Section 10for details). 585 The KeepWait timer has a fixed value of 1 minute. 587 Upon the receipt of an Open message, the receiving PCEP peer MUST 588 determine whether the suggested PCEP session characteristics are 589 acceptable. If at least one of the characteristic(s) is not 590 acceptable by the receiving peer, it MUST send an Error message. The 591 Error message SHOULD also contain the related Open object: for each 592 unacceptable session parameter, an acceptable parameter value SHOULD 593 be proposed in the appropriate field of the Open object in place of 594 the originally proposed value. The PCEP peer MAY decide to resend an 595 Open message with different session characteristics. If a second 596 Open message is received with the same set of parameters or with 597 parameters that are still unacceptable, the receiving peer MUST send 598 an Error message and it MUST immediately close the TCP connection. 599 Details about error message can be found in Section 7.14. 601 If the PCEP session characteristics are acceptable, the receiving 602 PCEP peer MUST consequently send a Keepalive message (defined in 603 Section 6.3) that would serve as an acknowledgment. 605 The PCEP session is considered as established once both PCEP peers 606 have received a Keepalive message from their peer. 608 6.3. Keepalive message 610 A Keepalive message is a PCEP message sent by a PCC or a PCE in order 611 to keep the session in active state. The Message-Type field of the 612 PCEP common header for the Keepalive message is set to 2 (To be 613 confirmed by IANA). The Keepalive message does not contain any 614 object. 616 Keepalive: PCEP has its own keepalive mechanism used to ensure of the 617 liveness of the PCEP session. This requires the determination of the 618 frequency at which each PCEP peer sends keepalive messages. 619 Asymmetric values may be chosen; thus there is no constraints 620 mandating the use of identical keepalive frequencies by both PCEP 621 peers. The DeadTimer is defined as the period of time after the 622 expiration of which a PCEP peer declares the session down if no PCEP 623 message has been received (keepalive or any other PCEP message: thus, 624 any PCEP message acts as a keepalive message). Similarly, there is 625 no constraints mandating the use of identical DeadTimers by both PCEP 626 peers. The minimum KeepAliveTimer value is 1 second. 628 Keepalive messages are used either to acknowledge an Open message if 629 the receiving PCEP peer agrees on the session characteristics and to 630 ensure the liveness of the PCEP session. Keepalive messages are sent 631 at the frequency specified in the OPEN object carried within an Open 632 message. Because any PCEP message may serve as Keepalive an 633 implementation may either decide to send Keepalive messages at the 634 same frequency regardless on whether other PCEP messages might have 635 been sent since the last sent Keepalive message or may decide to 636 differ the sending of the next Keepalive message based on the time at 637 which the last PCEP message (other than Keepalive) was sent. 639 Keepalive message 640 ::= 642 6.4. Path Computation Request (PCReq) message 644 A Path Computation Request message (also referred to as a PCReq 645 message) is a PCEP message sent by a PCC to a PCE so as to request a 646 path computation. The Message-Type field of the PCEP common header 647 for the PCReq message is set to 3 (To be confirmed by IANA). 649 There are two mandatory objects that MUST be included within a PCReq 650 message: the RP and the END-POINTS objects (see section Section 7). 651 If one of these objects is missing, the receiving PCE MUST send an 652 error message to the requesting PCC. Other objects are optional. 654 The format of a PCReq message is as follows: 655 ::= 656 [] 657 659 where: 660 ::=[] 661 ::=[] 663 ::= 664 [] 665 [] 666 [] 667 [] 668 [] 669 [] 670 [] 671 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD- 672 BALANCING objects are defined in Section 7. The special case of two 673 BANDWIDTH objects is discussed in details in Section 7.6. 675 6.5. Path Computation Reply (PCRep) message 677 The PCEP Path Computation Reply message (also referred to as a PCRep 678 message) is a PCEP message sent by a PCE to a requesting PCC in 679 response to a previously received PCReq message. The Message-Type 680 field of the PCEP common header is set to 4 (To be confirmed by 681 IANA). 683 The PCRep message MUST contain at least one RP object. For each 684 reply that is bundled into a single PCReq message, an RP object MUST 685 be included that contains a Request-ID-number identical to the one 686 specified in the RP object carried in the corresponding PCReq message 687 (see Section 7.3for the definition of the RP object). 689 A PCRep message may contain a set of computed path(s) corresponding 690 to either a single path computation request with load-balancing (see 691 Section 7.15) or multiple path computation requests originated by a 692 requesting PCC. The PCRep message may also contain multiple 693 acceptable paths corresponding to the same request. 695 The bundling of multiple replies to a set of path computation 696 requests within a single PCRep message is supported by the PCEP 697 protocol. If a PCE receives non-synchronized path computation 698 requests by means of one or more PCReq messages from a requesting PCC 699 it may decide to bundle the computed paths within a single PCRep 700 message so as to reduce the control plane load. Note that the 701 counter side of such an approach is the introduction of additional 702 delays for some path computation requests of the set. Conversely, a 703 PCE that receives multiple requests within the same PCReq message, 704 may decide to provide each computed path in separate PCRep messages. 706 If the path computation request can be satisfied (the PCE finds a set 707 of path(s) that satisfy the set of constraint(s)), the set of 708 computed path(s) specified by means of ERO object(s) is inserted in 709 the PCRep message. The ERO object is defined in Section 7.8. Such a 710 situation where multiple computed paths are provided in a PCRep 711 message is discussed in detail in Section 7.12. Furthermore, when a 712 PCC requests the computation a set of paths for a total amount of 713 bandwidth of X by means of a LOAD-BALANCING object carried within a 714 PCReq message, the ERO of each computed path may be followed by a 715 BANDWIDTH object as discussed in section Section 7.15. 717 If the path computation request cannot be satisfied, the PCRep 718 message MUST include a NO-PATH object. The NO-PATH object (described 719 in Section 7.4) may also comprise other information (e.g reasons for 720 the path computation failure). 722 The format of a PCRep message is as follows: 723 ::= 724 [] 725 727 where: 728 ::=[] 729 ::=[] 731 ::= 732 [] 733 [] 735 ::=[] 737 ::= 738 [] 739 [] 740 [] 741 [] 743 6.6. Notification (PCNtf) message 745 The PCEP Notification message (also referred to as the PCNtf message) 746 can either be sent by a PCE to a PCC or by a PCC to a PCE so as to 747 notify of a specific event. The Message-Type field of the PCEP 748 common header is set to 5 (To be Confirmed by IANA). 750 The PCNtf message MUST carry at least one NOTIFICATION object and may 751 contain several NOTIFICATION objects should the PCE or the PCC intend 752 to notify of multiple events. The NOTIFICATION object is defined in 753 Section 7.13. The PCNtf message may also contain an RP object (see 754 Section 7.3 when the notification refers to a particular path 755 computation request. 757 The PCNtf message may be sent by a PCC or a PCE in response to a 758 request or in an unsolicited manner. 760 The format of a PCNtf message is as follows: 761 ::= 762 764 ::= [] 766 ::= [] 767 769 :== 771 := 773 6.7. Error (PCErr) Message 775 The PCEP Error message (also referred to as a PCErr message) is sent 776 when a protocol error condition is met. The Message-Type field of 777 the PCEP common header is set to 6. 779 The PCErr message may be sent by a PCC or a PCE in response to a 780 request or in an unsolicited manner. In the former case, the PCErr 781 message MUST include the set of RP objects related to the pending 782 path computation request(s) that triggered the protocol error 783 condition. In the later case (unsollicited), no RP object is 784 inserted in the PCErr message. No RP object is inserted in a PCErr 785 when the error condition occurred during the initialization phase. A 786 PCErr message MUST contain a PCEP-ERROR object specifying the PCEP 787 error condition. The PCEP-ERROR object is defined in section 788 Section 7.14. 790 The format of a PCErr message is as follows: 791 ::= 792 793 [] 795 :==[] 796 ::=[] 797 799 :==[] 801 :==[] 802 The procedure upon the reception of a PCErr message is defined in 803 Section 7.14. 805 6.8. Close message 807 The Close message is a PCEP message sent by either a PCC to a PCE or 808 by a PCE to a PCC in order to close a PCEP session. The Message-Type 809 field of the PCEP common header for the Open message is set to 7 (To 810 be confirmed by IANA). 812 Close message 813 ::= 814 815 The Close message MUST contain exactly one CLOSE object (see 816 Section 6.8). 818 Upon the receipt of a Close message, the receiving PCEP peer MUST 819 cancel all pending requests and MUST close the TCP connection. 821 7. Object Formats 823 7.1. Common object header 824 A PCEP object carried within a PCEP message consists of one or more 825 32-bit words with a common header which has the following format: 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Object-Class | OT |Res|P|I| Object Length (bytes) | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | | 832 // (Object body) // 833 | | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Figure 8: PCEP common object header 838 Object-Class (8 bits): identifies the PCEP object class. 840 OT (Object-Type - 4 bits): identifies the PCEP object type. 842 The Object-Class and Object-Type fields are managed by IANA. 844 The Object-Class and Object-Type fields uniquely identify each PCEP 845 object. 847 Res flags (2 bits). Reserved field (MUST be set to 0). 849 P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify 850 in a PCReq message sent to a PCE whether the object must be taken 851 into account by the PCE during path computation or is just optional. 852 When the P flag is set, the object MUST be taken into account by the 853 PCE. Conversely, when the P flag is cleared, the object is optional 854 and the PCE is free to ignore it if not supported. 856 I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 857 message to indicate to a PCC whether or not an optional object was 858 processed. The PCE MAY include the ignored optional object in its 859 reply and set the I flag to indicate that the optional object was 860 ignored during path computation. When the I flag is cleared, the PCE 861 indicates that the optional object was processed during the path 862 computation. The setting of the I flag for optional objects is 863 purely indicative and optional. The I flag MUST be cleared if the P 864 flag is set. 866 If the PCE does not understand an object with the P Flag set or 867 understands the object but decides to ignore the object, the entire 868 PCEP message MUST be rejected and the PCE MUST send a PCErr message 869 with Error-Type="Unknown Object" or "Not supported Object". 871 Object Length (16 bits). Specifies the total object length including 872 the header, in bytes. The Object Length field MUST always be a 873 multiple of 4, and at least 4. The maximum object content length is 874 65528 bytes. 876 7.2. OPEN object 878 The OPEN object MUST be present in each Open message and may be 879 present in PCErr message. There MUST be only one OPEN object per 880 Open or PCErr message. 882 The OPEN object contains a set of fields used to specify the PCEP 883 protocol version, Keepalive frequency, DeadTimer, PCEP session ID 884 along with various flags. The OPEN object may also contain a set of 885 TLVs used to convey various session characteristics such as the 886 detailed PCE capabilities, policy rules and so on. No such TLV is 887 currently defined. 889 OPEN Object-Class is to be assigned by IANA (recommended value=1) 891 OPEN Object-Type is to be assigned by IANA (recommended value=1) 893 The format of the OPEN object body is as follows: 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Ver | Flags | Keepalive | Deadtimer | SID | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | | 900 // Optional TLV(s) // 901 | | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 Figure 9: OPEN Object format 905 Ver (Ver - 3 bits): PCEP version. Current version is 1. 907 Keepalive (8 bits): minimum period of time (in seconds) between the 908 sending of PCEP messages. The minimum value for the Keepalive is 1 909 second. When set to 0, once the session is established, no further 910 keepalives need to be sent to the remote peer. A RECOMMENDED value 911 for the keepalive frequency is 30 seconds. 913 DeadTimer (8 bits): specifies the amount of time after the expiration 914 of which a PCEP peer declares the session with the sender of the Open 915 message down if no PCEP message has been received. The DeadTimer 916 MUST be set to 0 if the Keepalive is set to 0. A RECOMMENDED value 917 for the DeadTimer is 4 times the value of the Keepalive. 919 SID (PCEP session-ID - 8 bits): specifies a 2 octet unsigned PCEP 920 session number that identifies the current session. The SID MUST be 921 incremented each time a new PCEP session is established and is mainly 922 used for logging and troubleshooting purposes. 924 Flags (5 bits): No Flags are currently defined. 926 Optional TLVs may be included within the OPEN object body to specify 927 PCC or PCE characteristics. The specification of such TLVs is 928 outside the scope of this document. 930 When present in an Open message, the OPEN object specifies the 931 proposed PCEP session characteristics. Upon receiving unacceptable 932 PCEP session characteristics during the PCEP session initialization 933 phase, the receiving PCEP peer (PCE) MAY include a PCEP object within 934 the PCErr message so as to propose alternative session characteristic 935 values. 937 7.3. RP Object 939 The RP (Request Parameters) object MUST be carried within each PCReq 940 and PCRep messages and MAY be carried within PCNtf and PCErr 941 messages. The P flag of the RP object MUST be set. The RP object is 942 used to specify various characteristics of the path computation 943 request. 945 7.3.1. Object definition 947 RP Object-Class is to be assigned by IANA (recommended value=2) 949 RP Object-Type is to be assigned by IANA (recommended value=1) 950 The format of the RP object body is as follows: 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Reserved | Flags |F|O|B|R| Pri | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Request-ID-number | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | | 959 // Optional TLV(s) // 960 | | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 Figure 10: RP object body format 965 The RP object body has a variable length and may contain additional 966 TLVs. No TLVs are currently defined. 968 Flags: 18 bits - The following flags are currently defined: 970 Pri (Priority - 3 bits): the Priority field may be used by the 971 requesting PCC to specify to the PCE the request's priority from 1 to 972 7. The decision of which priority should be used for a specific 973 request is of a local matter and MUST be set to 0 when unused. 974 Furthermore, the use of the path computation request priority by the 975 PCE's requests scheduler is implementation specific and out of the 976 scope of this document. Note that it is not required for a PCE to 977 support the priority field: in this case, it is RECOMMENDED to set 978 the priority field to 0 by the PCC in the RP object. If the PCE does 979 not take into account the request priority, it is RECOMMENDED to set 980 the priority field to 0 in the RP object carried within the 981 corresponding PCRep message, regardless of the priority value 982 contained in the RP object carried within the corresponding PCReq 983 message. A higher numerical value of the priority field reflects a 984 higher priority. Note that it is the responsibility of the network 985 administrator to make use of the priority values in a consistent 986 manner across the various PCC(s). The ability of a PCE to support 987 requests prioritization may be dynamically discovered by the PCC(s) 988 by means of PCE capability discovery. If not advertised by the PCE, 989 a PCC may decide to set the request priority and will learn the 990 ability of the PCE the support request prioritization by observing 991 the Priority field of the RP object received in the PCRep message. 992 If the value of the Pri field is set to 0, this means that the PCE 993 does not support the handling of request priorities: in other words, 994 the path computation request has been honoured but without taking the 995 request priority into account. 997 R (Reoptimization - 1 bit): when set, the requesting PCC specifies 998 that the PCReq message relates to the reoptimization of an existing 999 TE LSP in which case, in addition to the TE LSP attributes, the 1000 current path of the existing TE LSP to be reoptimized MUST be 1001 provided in the PCReq (except for 0-bandwidth TE LSP) message by 1002 means of an RRO object defined in Section 7.9. 1004 B (Bi-directional - 1 bit): when set, the PCC specifies that the path 1005 computation request relates to a bidirectional TE LSP that has the 1006 same traffic engineering requirements including fate sharing, 1007 protection and restoration, LSRs, and resource requirements (e.g. 1008 latency and jitter) in each direction. When cleared, the TE LSP is 1009 unidirectional. 1011 O (strict/lOose - 1 bit): when set, in a PCReq message, this 1012 indicates that a strict/loose path is acceptable. Otherwise, when 1013 cleared, this indicates to the PCE that an explicit path is required. 1014 In a PCRep message, when the O bit is set this indicates that the 1015 returned path is strict/loose, otherwise (the O bit is cleared), the 1016 returned path is explicit. 1018 F (Fail - 1 bit): when set, the requesting PCC requires the 1019 computation of a new path for a TE LSP that has failed in which case 1020 the path of the existing TE LSP MUST be provided in the PCReq (except 1021 for 0-bandwidth TE LSP) message by means of an RRO object defined in 1022 Section 7.9. This is to avoid double bandwidth booking should the 1023 TED not be yet updated or the corresponding resources not be yet 1024 released. 1026 Request-ID-number (32 bits). The Request-ID-number value combined 1027 with the source IP address of the PCC and the PCE address uniquely 1028 identify the path computation request context. The Request-ID-number 1029 MUST be incremented each time a new request is sent to the PCE. The 1030 value 0x0000000 is considered as invalid. If no path computation 1031 reply is received from the PCE, and the PCC wishes to resend its 1032 request, the same Request-ID-number MUST be used. Conversely, 1033 different Request-ID-number MUST be used for different requests sent 1034 to a PCE. The same Request-ID-number may be used for path 1035 computation requests sent to different PCEs. The path computation 1036 reply is unambiguously identified by the IP source address of the 1037 replying PCE. 1039 7.3.2. Handling of the RP object 1041 If a PCReq message is received without containing an RP object, the 1042 PCE MUST send a PCErr message to the requesting PCC with Error- 1043 type="Required Object missing" and Error-value="RP Object missing". 1045 If the O bit of the RP message carried within a PCReq message is set 1046 and local policy has been configured on the PCE to not provide 1047 explicit path(s) (for instance, for confidentiality reasons), a PCErr 1048 message MUST be sent by the PCE to the requesting PCC and the pending 1049 path computation request MUST be discarded. The Error-type is 1050 "Policy Violation" and Error-value is "O bit set". 1052 R bit: when the R bit of the RP object is set in a PCReq message, 1053 this indicates that the path computation request relates to the 1054 reoptimization of an existing TE LSP. In this case, the PCC MUST 1055 also provide the explicit or strict/loose path by including an RRO 1056 object in the PCReq message so as to avoid double bandwidth counting 1057 if and only if the TE LSP is a non 0-bandwidth TE LSP. If the PCC 1058 has previously requested a non-explicit path (O bit set), a 1059 reoptimization can still be requested by the PCC but this implies for 1060 the PCE to be either stateful (keep track of the previously computed 1061 path with the associated list of strict hops) or to have the ability 1062 to retrieve the complete required path segment. Alternatively the 1063 PCC MUST be able to inform PCE of the working path with associated 1064 list of strict hops in PCReq. The absence of an RRO in the PCReq 1065 message for a non 0-bandwidth TE LSP when the R bit of the RP object 1066 is set MUST trigger the sending of a PCErr message with Error- 1067 type="Required Object Missing" and Error-value="RRO Object missing 1068 for reoptimization". 1070 If the PCC receives a PCRep message that contains a RP object 1071 referring to an unknown Request-ID-Number, the PCC MUST send a PCErr 1072 message with Error-Type="Unknown request reference". 1074 7.4. NO-PATH Object 1076 The No-PATH object is used in PCRep messages in response to an 1077 unsuccessful path computation request (the PCE could not find a path 1078 satisfying the set of constraints). When a PCE cannot find a path 1079 satisfying a set of constraints, it MUST include a NO-PATH object in 1080 the PCRep message. The NO-PATH object is used to report the 1081 impossibility to find a path that satisfies the set of constraints. 1082 Optionally, if the PCE supports such capability, the NO-PATH object 1083 MAY contain an optional NO-PATH-VECTOR TLV defined below and the 1084 PCRep message MAY also contain a list of objects that specify the set 1085 of constraints that could not be satisfied. The PCE MAY just 1086 replicate the set of object(s) that was received that was the cause 1087 of the unsuccessful computation or MAY optionally report a suggested 1088 value for which a path could have been found. 1090 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1092 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1093 The format of the NO-PATH object body is as follows: 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 |C| Flags | Reserved | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | | 1100 // Optional TLV(s) // 1101 | | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Figure 11: NO-PATH object format 1106 Optionally, a TLV named NO-PATH-VECTOR MAY be included in the 1107 NO-PATH object that specifies the reason that led to unsuccesful path computation. 1109 The NO-PATH-VECTOR TLV is composed of 1 octet for the type, 1110 1 octet specifying the number of bytes in the value field, followed by 1111 a fix length value field of 32-bits flags field used to report the reason(s) 1112 that led to unsuccesful path computation The NO-PATH-VECTOR TLV is padded 1113 to eight-octet alignment. 1115 TYPE: To be assigned by IANA 1116 LENGTH: 4 1117 VALUE: 32-bits flags field 1119 IANA is requested to manage the space of flags carried in the NO-PATH-VECTOR TLV (see IANA section). 1121 The following flags are currently defined: 1123 0x01: PCE currently unavailable 1124 0x02: Unknown destination 1125 The NO-PATH object body has a variable length and may contain 1126 additional TLVs. 1128 The only TLV currently defined is the NO-PATH-VECTOR TLV defined 1129 below. 1131 Flags (16 bits). The following flags are currently defined: 1133 C flag (1 bit): when set, the PCE indicates the set of unsatisfied 1134 constraints (reasons why a path could not be found) in the PCRep 1135 message by including the relevant PCEP objects. When cleared, no 1136 reason is specified. 1138 Example: consider the case of a PCC that sends a path computation 1139 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1140 find a path for X MBits/s. In this case, the PCE must include in the 1141 PCRep message a NO-PATH object. Optionally the PCE may also include 1142 the original BANDWIDTH object so as to indicate that the reason for 1143 the unsuccessful computation is the bandwidth constraint (in this 1144 case, the C flag is set). If the PCE supports such capability it may 1145 alternatively include the BANDWIDTH Object and report a value of Y in 1146 the bandwidth field of the BANDWIDTH object (in this case, the C flag 1147 is set) where Y refers to the bandwidth for which a TE LSP with the 1148 same other characteristics could have been computed. 1150 When the NO-PATH object is absent from a PCRep message, the path 1151 computation request has been fully satisfied and the corresponding 1152 path(s) is/are provided in the PCRep message. 1154 7.5. END-POINT Object 1156 The END-POINTS object is used in a PCReq message to specify the 1157 source IP address and the destination IP address of the path for 1158 which a path computation is requested. Note that the source and 1159 destination addresses specified in the END-POINTS object may or may 1160 not correspond to the source and destination IP address of the TE LSP 1161 but rather to a path segment. Two END-POINTS objects (for IPv4 and 1162 IPv6) are defined. 1164 END-POINTS Object-Class is to be assigned by IANA (recommended 1165 value=4) 1167 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 1168 for IPv4 and 2 for IPv6) 1169 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1170 as follows: 1172 0 1 2 3 1173 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 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Source IPv4 address | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Destination IPv4 address | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 Figure 12: END-POINTS object body format for IPv4 1182 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 1184 0 1 2 3 1185 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | | 1188 | Source IPv6 address (16 bytes) | 1189 | | 1190 | | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | | 1193 | Destination IPv6 address (16 bytes) | 1194 | | 1195 | | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 Figure 13: END-POINTS object body format for IPv6 1200 The END-POINTS object body has a fixed length of 8 octets for IPv4 1201 and 32 octets for IPv6. 1203 7.6. BANDWIDTH Object 1205 The BANDWIDTH object is optional and can be used to specify the 1206 requested bandwidth for a TE LSP. In the case of a non existing TE 1207 LSP, the BANDWIDTH object MUST be included in the PCReq message so as 1208 to specify the required bandwidth for the new TE LSP. In the case of 1209 the reoptimization of an existing TE LSP, the bandwidth of the 1210 existing TE LSP MUST also be included in addition to the requested 1211 bandwidth if and only if the two values differ. Consequently, two 1212 Object-Type are defined that refer to the requested bandwidth and the 1213 bandwidth of a existing TE LSP for which a reoptimization is being 1214 performed. 1216 The BANDWIDTH object may be carried within PCReq and PCRep messages. 1218 The absence of the BANDWIDTH object MUST be interpreted by the PCE as 1219 a path computation request related to a 0 bandwidth TE LSP. 1221 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1222 value=5) 1224 Two Object-Type are defined for the BANDWIDTH object: 1226 o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by 1227 IANA (recommended value=1) 1229 o Bandwidth of an existing TE LSP for which a reoptimization is 1230 requested. BANDWIDTH Object-Type is to be assigned by IANA 1231 (recommended value=2) 1233 The format of the BANDWIDTH object body is as follows: 1234 0 1 2 3 1235 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 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | Bandwidth | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 Figure 14: BANDWIDTH object body format 1241 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1242 IEEE floating point format, expressed in bytes per second. 1244 The BANDWIDTH object body has a fixed length of 4 octets. 1246 7.7. METRIC Object 1248 The METRIC object is optional and can be used for several purposes. 1250 In a PCReq message, a PCC MAY insert a METRIC object: 1252 o To indicate the metric that MUST be optimized by the path 1253 computation algorithm. Currently, two metrics are defined: the 1254 IGP cost and the TE metric (see [RFC3785]). 1256 o To indicate a bound on the path cost than MUST NOT be exceeded for 1257 the path to be considered as acceptable by the PCC. 1259 In a PCRep message, the METRIC object MAY be inserted so as to 1260 provide the cost for the computed path. It MAY also be inserted 1261 within a PCRep with the NO-PATH object to indicate that the metric 1262 constraint could not be satisfied. 1264 The path computation algorithmic aspects used by the PCE to optimize 1265 a path with respect to a specific metric are outside the scope of 1266 this document. 1268 It must be understood that such path metric is only meaningful if 1269 used consistently: for instance, if the delay of a path computation 1270 segment is exchanged between two PCE residing in different domains, 1271 consistent ways of defining the delay must be used. 1273 The absence of the METRIC object MUST be interpreted by the PCE as a 1274 path computation request for which the PCE may choose the metric to 1275 be used. 1277 METRIC Object-Class is to be assigned by IANA (recommended value=6) 1279 METRIC Object-Type is to be assigned by IANA (recommended value=1) 1281 The format of the METRIC object body is as follows: 1282 0 1 2 3 1283 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 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Reserved | Flags |C|B| T | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | metric-value | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 Figure 15: METRIC object body format 1292 T (Type - 8 bits): Specifies the metric type. 1294 Two values are currently defined: 1296 o T=1: The IGP metric 1298 o T=2: The TE cost 1300 B (Bound - 1 bit): When set in a PCReq message, the metric-value 1301 indicates a bound (a maximum) for the path cost that must not be 1302 exceeded for the PCC to consider the computed path as acceptable. 1303 When the B flag is cleared, the metric-value field MUST be set to 1304 0x0000. The B flag MUST always be cleared in a PCRep message. 1306 C (Cost - 1 bit): When set in a PECReq message, this indicates that 1307 the PCE MUST provide the computed path cost (should a path satisfying 1308 the constraints be found) in the PCRep message for the corresponding 1309 metric. 1311 Metric-value (32 bits): metric value encoded in 32 bits in IEEE 1312 floating point format. 1314 The METRIC object body has a fixed length of 8 octets. 1316 Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 1317 message. 1319 In a PCReq message the presence of multiple METRIC object can be used 1320 to specify a multi-parameters (e.g. a metric may be a constraint or a 1321 parameter to minimize/maximize) objective function or multiple bounds 1322 for different constraints where at most one METRIC object must be 1323 used to indicate the metric to optimize (B-flag is cleared): the 1324 other METRIC object MUST be used to reflect bound constraints (B-Flag 1325 is set). 1327 A METRIC object used to indicate the metric to optimize during the 1328 path computation MUST have the B-Flag cleared, the metric-value field 1329 set to 0x0000 and the T-Flag set to the appropriate value. 1331 A METRIC object used to reflect a bound MUST have the B-Flag set, the 1332 T-Flag and metric-value field set to the appropriate values. 1334 In a PCRep message, unless not allowed by PCE policy, at least one 1335 METRIC object MUST be present that reports the computed path cost if 1336 the C bit of the METRIC object was set in the corresponding path 1337 computation request (the B-flag MUST be cleared); optionally the 1338 PCRep message MAY contain additional METRIC objects that correspond 1339 to bound constraints, in which case the metric-value MUST be equal to 1340 the corresponding path metric cost (the B-flag MUST be set). If no 1341 path satisfying the constraints could be found by the PCE, the METRIC 1342 objects MAY also be present in the PCRep message with the NO-PATH 1343 object to indicate the constraint metric that could be satisfied. 1345 Example: if a PCC sends a path computation request to a PCE where the 1346 metric to optimize is the IGP metric and the TE metric must not 1347 exceed the value of M, two METRIC object are inserted in the PCReq 1348 message: 1350 o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000 1352 o Second METRIC Object with B=1, T=2, metric-value=M 1354 If a path satisfying the set of constraints can be found by the PCE 1355 and no policy preventing to provide the path cost in place, the PCE 1356 inserts one METRIC object with B=0, T=1, metric-value= computed IGP 1357 path cost. Additionally, the PCE may insert a second METRIC object 1358 with B=1, T=2, metric-value= computed TE path cost: the second METRIC 1359 object MUST be inserted if the corresponding C bit was set in the 1360 path computation request. 1362 7.8. ERO Object 1364 The ERO object is used to encode a TE LSP. The ERO Object is carried 1365 within a PCRep message to provide the computed TE LSP should have the 1366 path computation been successful. 1368 The contents of this object are identical in encoding to the contents 1369 of the Explicit Route Object defined in [RFC3209], [RFC3473] and 1370 [RFC3477]. That is, the object is constructed from a series of sub- 1371 objects. Any RSVP ERO sub-object already defined or that could be 1372 defined in the future for use in the ERO is acceptable in this 1373 object. 1375 PCEP ERO sub-object types correspond to RSVP ERO sub-object types. 1377 Since the explicit path is available for immediate signaling by the 1378 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1379 and fields in this object are identical to those defined for the ERO. 1381 ERO Object-Class is to be assigned by IANA (recommended value=7) 1383 ERO Object-Type is to be assigned by IANA (recommended value=1) 1385 7.9. RRO Object 1387 The RRO object is used to record the route followed by a TE LSP. The 1388 PCEP RRO object is exclusively carried within a PCReq message so as 1389 to specify the route followed by a TE LSP for which a reoptimization 1390 is desired. 1392 The contents of this object are identical in encoding to the contents 1393 of the Route Record Object defined in [RFC3209], [RFC3473] and 1394 [RFC3477]. That is, the object is constructed from a series of sub- 1395 objects. Any RSVP RRO sub-object already defined or that could be 1396 defined in the future for use in the RRO is acceptable in this 1397 object. 1399 The meanings of all of the sub-objects and fields in this object are 1400 identical to those defined for the RRO. 1402 PCEP RRO sub-object types correspond to RSVP RRO sub-object types. 1404 RRO Object-Class is to be assigned by IANA (recommended value=8) 1406 RRO Object-Type is to be assigned by IANA (recommended value=1) 1408 7.10. LSPA Object 1410 The LSPA object is optional and specifies various TE LSP attributes 1411 to be taken into account by the PCE during path computation. The 1412 LSPA (LSP Attributes) object can either be carried within a PCReq 1413 message or a PCRep message in case of unsuccessful path computation 1414 (in this case, the PCRep message also contains a NO-PATH object and 1415 the LSPA object is used to indicate the set of constraint(s) that 1416 could not be satisfied). Most of the fields of the LSPA object are 1417 identical to the fields of the SESSION-ATTRIBUTE object defined in 1418 [RFC3209] and [RFC4090]. When absent from the PCReq message, this 1419 means that the Setup and Holding priorities are equal to 0, and there 1420 are no affinity constraints. 1422 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1424 Two Objects-Types are defined for the LSPA object: LSPA without 1425 resource affinity (Object-Type to be assigned by IANA with 1426 recommended value=1) and LSPA with resource affinity (Object-type=2). 1428 The format of the LSPA object body with and without resource affinity 1429 are as follows: 1430 0 1 2 3 1431 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 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | Setup Prio | Holding Prio | Flags |L| Reserved | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | | 1436 // Optional TLV(s) // 1437 | | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 Figure 16: LSPA object body format (without resource affinity) 1442 0 1 2 3 1443 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 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | Exclude-any | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Include-any | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Include-all | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Setup Prio | Holding Prio | Flags |L| Reserved | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | | 1454 // Optional TLV(s) // 1455 | | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 Figure 17: LSPA object body format (with resource affinity) 1460 Setup Prio (Setup Priority - 8 bits). The priority of the session 1461 with respect to taking resources, in the range of 0 to 7. The value 1462 0 is the highest priority. The Setup Priority is used in deciding 1463 whether this session can preempt another session. 1465 Holding Prio (Holding Priority - 8 bits). The priority of the 1466 session with respect to holding resources, in the range of 0 to 7. 1467 The value 0 is the highest priority. Holding Priority is used in 1468 deciding whether this session can be preempted by another session. 1469 Flags 1471 The flag L corresponds to the "Local protection desired" bit 1472 ([RFC3209]) of the SESSION-ATTRIBUTE Object. 1474 L Flag (Local protection desired). When set, this means that the 1475 computed path must include links protected with Fast Reroute as 1476 defined in [RFC4090]. 1478 7.11. IRO Object 1480 The IRO (Include Route Object) object is optional and can be used to 1481 specify that the computed path MUST traverse a set of specified 1482 network elements. The IRO object MAY be carried within PCReq and 1483 PCRep messages. When carried within a PCRep message with the NO-PATH 1484 object, the IRO indicates the set of elements that fail the PCE to 1485 find a path. 1487 IRO Object-Class is to be assigned by IANA (recommended value=10) 1489 IRO Object-Type is to be assigned by IANA (recommended value=1) 1491 0 1 2 3 1492 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 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | | 1495 // (Subobjects) // 1496 | | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 Figure 18: IRO object body format 1500 Subobjects The IRO object is made of sub-object(s) identical to the 1501 ones defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs. 1503 The following subobject types are supported. 1505 Type Subobject 1506 1 IPv4 prefix 1507 2 IPv6 prefix 1508 4 Unnumbered Interface ID 1509 32 Autonomous system number 1510 The L bit of such sub-object has no meaning within an IRO object. 1512 7.12. SVEC Object 1514 7.12.1. Notion of Dependent and Synchronized path computation requests 1516 Independent versus dependent path computation requests: path 1517 computation requests are said to be independent if they are not 1518 related to each other. Conversely a set of dependent path 1519 computation requests is such that they MUST be computed 1520 simultaneously: a typical example of dependent requests is the 1521 computation of a set of diverse paths. 1523 Synchronized versus non-synchronized path computation requests: a set 1524 of path computation requests is said to be non-synchronized if their 1525 respective treatment (path computations) can be performed by a PCE in 1526 a serialized and independent fashion. 1528 There are various circumstances where the synchronization of a set of 1529 path computations may be beneficial or required. 1531 Consider the case of a set of N TE LSPs for which a PCC needs to send 1532 path computation requests to a PCE. The first solution consists of 1533 sending N separate PCReq messages to the selected PCE. In this case, 1534 the path computation requests are non synchronized. Note that the 1535 PCC may chose to distribute the set of N requests across K PCEs for 1536 load balancing purpose. Considering that M (with M+-+-+-+-+-+-+ | | 2250 | | | KeepWait |----+ | 2251 | +--| |<---+ | 2252 |+-----+-+-+-+-+-+-+ | | 2253 || | | | 2254 || | | | 2255 || V | | 2256 || +->+-+-+-+-+-+-+----+ | 2257 || | | OpenWait |-------+ 2258 || +--| |<------+ 2259 ||+----+-+-+-+-+-+-+<---+ | 2260 ||| | | | 2261 ||| | | | 2262 ||| V | | 2263 ||| +->+-+-+-+-+-+-+ | | 2264 ||| | |TCPPending |----+ | 2265 ||| +--| | | 2266 |||+---+-+-+-+-+-+-+<---+ | 2267 |||| | | | 2268 |||| | | | 2269 |||| V | | 2270 |||+--->+-+-+-+-+ | | 2271 ||+---->| Idle |-------+ | 2272 |+----->| |----------+ 2273 +------>+-+-+-+-+ 2275 Figure 15: PCEP Finite State Machine for the PCC 2277 PCEP defines the following set of variables: 2279 TCPConnect: timer (in seconds) started after having initialized a TCP 2280 connection using the PCEP well-known TCP port. The value of the 2281 TCPConnect timer is 60 seconds. 2283 TCPRetry: specifies the number of times the system has tried to 2284 establish a TCP connection with a PCEP peer without success. 2286 TCPMaxRetry: Maximum number of times the system tries to establish a 2287 TCP connection using the PCEP well-known TCP port before going back 2288 to the Idle state. The value of the TCPMaxRetry is 5. 2290 OpenWait: timer (in seconds) that corresponds to the amount of time a 2291 PCEP peer will wait to receive an Open message from the PCEP peer 2292 after the expiration of which the system releases the PCEP resource 2293 and go back to the Idle state. 2295 KeepWait: timer that corresponds to the amount of time a PCEP peer 2296 will wait to receive a KeepAlive or a PCErr message from the PCEP 2297 peer after the expiration of which the system releases the PCEP 2298 resource and go back to the Idle state. The KeepWait timer has a 2299 fixed value of 1 minute. 2301 OpenRetry: specifies the number of times the system has received an 2302 Open message with unacceptable PCEP session characteristics. 2304 The following two states variable are defined: 2306 RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system 2307 has received an acceptable Open message. 2309 LocalOK: the LocalOK variable is a Boolean set to 1 if the system has 2310 received a Keepalive message acknowledging that the Open message sent 2311 to the peer was valid. 2313 Idle State: 2315 The idle state is the initial PCEP state where PCEP (also referred to 2316 as "the system") waits for an initialization event that can either be 2317 manually triggered by the user (configuration) or automatically 2318 triggered by various events. In Idle state, PCEP resources are 2319 allocated (memory, potential process, ...) but no PCEP messages are 2320 accepted from any PCEP peer. The system listens the well-known PCEP 2321 TCP port. 2323 The following set of variable are initialized: 2325 TCPRetry=0, 2327 LocalOK=0, 2329 RemoteOK=0, 2331 OpenRetry=0. 2333 Upon detection of a local initialization event (e.g. user 2334 configuration to establish a PCEP session with a particular PCEP 2335 peer, local event triggering the establishment of a PCEP session with 2336 a PCEP peer, ...), the system: 2338 o Starts the TCPConnect timer, 2340 o Initiates of a TCP connection with the PCEP peer, 2342 o Increments the TCPRetry variable, 2344 o Moves to the TCPPending state. 2346 Upon receiving a TCP connection on the well-known PCEP TCP port, if 2347 the PCE is in congested state, the PCE MUST immediately send a PCErr 2348 with Notification-type=2, Notification-value=1 along with the 2349 optional CONGESTION-DURATION TLV (see Section 7.13). 2351 Upon receiving a TCP connection on the well-known PCEP TCP port, if 2352 the TCP connection establishment succeeds, the system: 2354 o Sends an Open message, 2356 o Starts the OpenWait timer, 2358 o Stars the KeepWait timer, 2360 o Moves to the OpenWait state. 2362 It is expected that an implementation will use an exponentially 2363 increase timer between automatically generated Initialization events 2364 and between retrials of TCP connection establishments. 2366 TCPPending State 2368 If the TCP connection establishment succeeds, the system: 2370 o Sends an Open message, 2372 o Starts the OpenWait timer, 2374 o Starts the KeepWait timer, 2376 o Moves to the OpenWait state. 2378 If the TCP connection establishement fails (an error is detected 2379 during the TCP connection establishment) or the TCPConnectTimer 2380 expires: 2382 If TCPRetry =TCPMaxRetry the system moves to the Idle State 2384 If TCPRetry < TCPMaxRetry the system: 2386 o Starts the TCPConnect timer, 2388 o Initiates of a TCP connection with the PCEP peer, 2390 o Increments the TCPRetry variable, 2392 o Stays in the TPCPending state. 2394 If the system detects that the PCEP peer tries to simultaneously 2395 establish a TCP connection, it stops the TCP connection establishment 2396 if and only if the PCEP peer has a higher IP address and moves to the 2397 Idle state. This guarantees that in case of "collision" a single TCP 2398 connection is established. 2400 OpenWait State: 2402 In the OpenWait state, the system waits for an Open message from its 2403 PCEP peer. 2405 If the system receives an Open message from the PCEP peer before the 2406 expiration of the OpenWait timer, PCEP checks the PCEP session 2407 attributes (Keepalive frequency, DeadTimer, ...). 2409 If an error is detected (e.g. malformed Open message, presence of two 2410 Open objects, ...), PCEP generates an error notification, the PCEP 2411 peer sends a PCErr message with Error-Type=1 and Error-value=1. The 2412 system releases the PCEP resources for the PCEP peer, closes the TCP 2413 connection and moves to the Idle state. 2415 If no errors are detected, PCEP increments the OpenRetry variable. 2417 If OpenRetry=2, the PCEP peer sends a PCErr with Error-Type=1 and 2418 Error-value=5, the system releases the PCEP resources for that peer, 2419 and moves back to the Idle state. 2421 If no errors are detected and the session characteristics are 2422 acceptable to the local system, the system: 2424 o Sends a Keepalive message to the PCEP peer, 2426 o Starts the Keepalive timer, 2428 o Sets the RemoteOK variable to 1. 2430 If LocalOK=1 the system moves to the UP state. 2432 If LocalOK=0 the system moves to the KeepWait state. 2434 If no errors are detected but the session charateristics are 2435 unacceptable and non-negotiable, the PCEP peer sends a PCErr with 2436 Error-Type=1 and Error-value=3, the system releases the PCEP 2437 resources for that peer, and moves back to the Idle state. 2439 If no errors are detected, OpenRetry=1, the session charateristics 2440 are unacceptable but negotiable (such as the Keepalive frequency or 2441 the DeadTimer), the system: 2443 o sends a PCErr message with Error-Type=1 and Error-value=4 that 2444 contains proposed acceptable session characteristics, 2446 o If LocalOK=1, the system stays in the OpenWait state 2448 o If LocalOK=0, the system moves to the KeepWait state 2450 If no Open message is received before the expiration of the OpenWait 2451 timer, the PCEP peer sends a PCErr message with Error-Type=1 and 2452 Error-value=2, the system releases the PCEP resources for the PCEP 2453 peer, closes the TCP connection and moves to the Idle state. 2455 KeepWait State 2457 In the Keepwait state, the system waits for the receipt of a 2458 Keepalive from its PCEP peer acknowledging its Open message or a 2459 PCErr message in response to unacceptable PCEP session 2460 characteristics proposed in the Open message. 2462 If a Keepalive message is received before the expiration of the 2463 KeepWait timer, LocalOK=1 2465 If RemoteOK=1, the system moves to the UP state. 2467 If RemoteOK=0, the system moves to the OpenWait State. 2469 If a PCErr message is received before the expiration of the KeepWait 2470 timer: 2472 1. If the proposed values are unacceptable, the PCEP peer sends a 2473 PCErr message with Error-Type=1 and Error-value=6 and the system 2474 releases the PCEP resources for that PCEP peer, closes the TCP 2475 connection and moves to the Idle state. 2477 2. If the proposed values are acceptable, the sytem adjusts its PCEP 2478 session characteristics according to the proposed values received 2479 in the PCErr message restarts the KeepWait timer and sends a new 2480 Open message. If RemoteOK=1, the system stays in the KeepWait 2481 state. If RemoteOK=0, the system moves to the OpenWait state. 2483 If neither a Keepalive nor a PCErr is received after the expiration 2484 of the KeepWait timer, the PCEP peer sends a PCErr message with 2485 Error-Type=1 and Error-value=7 and, system releases the PCEP 2486 resources for that PCEP peer, closes the TCP connection and moves to 2487 the Idle State. 2489 UP State 2491 In the UP state, the PCEP peer starts exchanging PCEP messages 2492 according to the session characteristics. 2494 If the Keepalive timer expires, the systens sends a Keepalive 2495 message. 2497 If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from 2498 the PCEP peer after the expiration of the DeadTimer, the systems 2499 sends a PCErr message with a PCEP-ERROR object (Error-type=9, Error- 2500 value=1), terminates PCEP session according to the procedure defined 2501 in Section 6.8, releases the PCEP resources for that PCEP peer, 2502 closes the TCP connection and moves to the Idle State. 2504 If a malformed PCEP message is received or the TCP connection fails, 2505 the systems sends a PCEP CLOSE message, the system releases the PCEP 2506 resources for that PCEP peer, closes the TCP connection and moves to 2507 the Idle State. 2509 11. Security Considerations 2511 The PCEP protocol could be the target of the following attacks: 2513 o Spoofing (PCC or PCE impersonation) 2515 o Snooping (message interception) 2517 o Falsification 2519 o Denial of Service 2521 A PCEP attack may have significant impact, particularly in an 2522 inter-AS context as PCEP facilitates inter-AS path establishment. 2523 Several mechanisms are proposed below, so as to ensure 2524 authentication, integrity and privacy of PCEP Communications, and 2525 also to protect against DoS attacks. 2527 11.1. PCEP Authentication and Integrity 2529 It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to 2530 provide for the authenticity and integrity of PCEP messages. This 2531 will allow protecting against PCE or PCC impersonation and also 2532 against message content falsification. 2534 This requires the maintenance, exchange and configuration of MD-5 2535 keys on PCCs and PCEs. Note that such maintenance may be especially 2536 onerous to the operators as pointed out in 2537 [I-D.ietf-rpsec-bgpsecrec]. Hence it is important to limit the 2538 number of keys while ensuring the required level of security. 2540 MD-5 signature faces some limitations, as per explained in [RFC2385]. 2541 Note that when one digest technique stronger than MD5 is specified 2542 and implemented, PCEP could be easily upgraded to use it. 2544 11.2. PCEP Privacy 2546 Ensuring PCEP communication privacy is of key importance, especially 2547 in an inter-AS context, where PCEP communication end-points do not 2548 reside in the same AS, as an attacker that intercept a PCE message 2549 could obtain sensitive information related to computed paths and 2550 resources. Privacy can be ensured thanks to encryption. To ensure 2551 privacy of PCEP communication, IPSec [RFC2406] tunnels MAY be used 2552 between PCC and PCEs or between PCEs. Note that this could also be 2553 used to ensure Authentication and Integrity, in which case, TCP MD-5 2554 option would not be required. 2556 11.3. Protection against Denial of Service attacks 2558 PCEP can be the target of TCP DoS attacks, such as for instance SYN 2559 attacks, as all protocols running on top of TCP. PCEP can use the 2560 same mechanisms as defined in [RFC3036] to mitigate the threat of 2561 such attacks: 2563 o A PCE should avoid promiscuous TCP listens for PCEP TCP session 2564 establishment. It should use only listens that are specific to 2565 authorized PCCs. 2567 o The use of the MD5 option helps somewhat since it prevents a SYN 2568 from being accepted unless the MD5 segment checksum is valid. 2569 However, the receiver must compute the checksum before it can 2570 decide to discard an otherwise acceptable SYN segment. 2572 o The use of access-list on the PCE so as to restrict access to 2573 authorized PCCs. 2575 11.4. Request input shaping/policing 2577 A PCEP implementation may be subject to Denial Of Service attacks 2578 consisting of sending a very large number of PCEP messages (e.g. 2579 PCReq messages). Thus, especially in multi-Service Providers 2580 environments, a PCE implementation should implement request input 2581 shaping/policing so as to throttle the amount of received PCEP 2582 messages without compromising the implementation behavior. 2584 12. Authors' addresses 2586 This document was the collective work of several authors. The 2587 content of this document was contributed by the editors and the co- 2588 authors listed below: 2590 Arthi Ayyangar 2591 Nuova Systems 2592 2600 San Tomas Expressway 2593 Santa Clara, CA 95051 2594 USA 2596 Email: arthi@nuovasystems.com 2598 Eiji Oki 2599 NTT 2600 Midori 3-9-11 2601 Musashino, Tokyo, 180-8585 2602 JAPAN 2604 Email: oki.eiji@lab.ntt.co.jp 2606 Alia Atlas 2607 Google 2608 1600 Amphitheatre Parkway 2609 Montain View, CA 94043 2610 USA 2612 Email: akatlas@alum.mit.edu 2614 Andrew Dolganow 2615 Alcatel 2616 600 March Road 2617 Ottawa, ON K2K 2E6 2618 CANADA 2620 Email: andrew.dolganow@alcatel.com 2622 Yuichi Ikejiri 2623 NTT Communications Corporation 2624 1-1-6 Uchisaiwai-cho, Chiyoda-ku 2625 Tokyo, 100-819 2626 JAPAN 2628 Email: y.ikejiri@ntt.com 2630 Kenji Kumaki 2631 KDDI Corporation 2632 Garden Air Tower Iidabashi, Chiyoda-ku, 2633 Tokyo, 102-8460 2634 JAPAN 2636 Email: ke-kumaki@kddi.com 2638 13. Acknowledgements 2640 The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash, 2641 Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard 2642 Douville and Jon Parker for their very valuable input. Special thank 2643 to Adrian Farrel for his very valuable suggestions. 2645 14. References 2647 14.1. Normative References 2649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2650 Requirement Levels", BCP 14, RFC 2119, March 1997. 2652 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2653 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2654 Functional Specification", RFC 2205, September 1997. 2656 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2657 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2658 Tunnels", RFC 3209, December 2001. 2660 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2661 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2662 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2664 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 2665 in Resource ReSerVation Protocol - Traffic Engineering 2666 (RSVP-TE)", RFC 3477, January 2003. 2668 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 2669 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 2670 May 2005. 2672 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2673 Element (PCE)-Based Architecture", RFC 4655, August 2006. 2675 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 2676 Communication Protocol Generic Requirements", RFC 4657, 2677 September 2006. 2679 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 2680 (PCE) Discovery", RFC 4674, October 2006. 2682 14.2. Informative References 2684 [I-D.ietf-ccamp-inter-domain-rsvp-te] 2685 Ayyangar, A. and J. Vasseur, "Inter domain MPLS and GMPLS 2686 Traffic Engineering - RSVP-TE extensions", 2687 draft-ietf-ccamp-inter-domain-rsvp-te-04 (work in 2688 progress), January 2007. 2690 [I-D.ietf-pce-disco-proto-isis] 2691 Roux, J., "IS-IS protocol extensions for Path Computation 2692 Element (PCE) Discovery", 2693 draft-ietf-pce-disco-proto-isis-01 (work in progress), 2694 December 2006. 2696 [I-D.ietf-pce-disco-proto-ospf] 2697 Roux, J., "OSPF protocol extensions for Path Computation 2698 Element (PCE) Discovery", 2699 draft-ietf-pce-disco-proto-ospf-01 (work in progress), 2700 December 2006. 2702 [I-D.ietf-pce-inter-layer-req] 2703 Oki, E., "PCC-PCE Communication Requirements for Inter- 2704 Layer Traffic Engineering", 2705 draft-ietf-pce-inter-layer-req-03 (work in progress), 2706 October 2006. 2708 [I-D.ietf-pce-interas-pcecp-reqs] 2709 Bitar, N., "Inter-AS Requirements for the Path Computation 2710 Element Communication Protocol (PCECP)", 2711 draft-ietf-pce-interas-pcecp-reqs-01 (work in progress), 2712 October 2006. 2714 [I-D.ietf-pce-pcecp-interarea-reqs] 2715 Roux, J., "PCE Communication Protocol (PCECP) Specific 2716 Requirements for Inter-Area Multi Protocol Label 2717 Switching (MPLS) and Generalized MPLS (GMPLS) Traffic 2718 Engineering", draft-ietf-pce-pcecp-interarea-reqs-05 (work 2719 in progress), December 2006. 2721 [I-D.ietf-rpsec-bgpsecrec] 2722 Christian, B. and T. Tauber, "BGP Security Requirements", 2723 draft-ietf-rpsec-bgpsecrec-06 (work in progress), 2724 June 2006. 2726 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2727 April 1992. 2729 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 2730 Signature Option", RFC 2385, August 1998. 2732 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 2733 Payload (ESP)", RFC 2406, November 1998. 2735 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2736 B. Thomas, "LDP Specification", RFC 3036, January 2001. 2738 [RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and 2739 T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric 2740 as a second MPLS Traffic Engineering (TE) Metric", BCP 87, 2741 RFC 3785, May 2004. 2743 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 2744 June 2005. 2746 Appendix A. Compliance with the PCECP Requirement Document 2748 The aim of this section is to list the set of requirements set forth 2749 in [RFC4657] that are not satisfied by the current revision of this 2750 document. This only concerns the requirements listed as MUST 2751 according to [RFC2119]. 2753 Here is the list of currently unsatisfied requirements: 2755 o Allow to select/prefer from advertised list of standard objective 2756 functions/options 2758 o Allow to customize objective function/options 2760 o Support "unsynchronized" & "synchronized" objective functions 2762 o Protocol recovery support resynchronization of information & 2763 requests between sender & receiver. 2765 Appendix B. PCEP Variables 2767 PCEP defines the following configurable variables: 2769 KeepAlive timer: minimum period of time between the sending of PCEP 2770 messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A 2771 suggested value for the Keepalive timer is 30 seconds. 2773 DeadTimer: period of timer after the expiration of which a PCEP peer 2774 declared the session down if no PCEP message has been received. 2776 SyncTimer: the SYNC timer is used in the case of synchronized path 2777 computation request using the SVEC object defined in Section 7.12.3. 2778 Consider the case where a PCReq message is received by a PCE that 2779 contains the SVEC object referring to M synchronized path computation 2780 requests. If after the expiration of the SYNC timer all the M path 2781 computation requests have not been received, a protocol error is 2782 triggered and the PCE MUST cancel the whole set of path computation 2783 requests. A RECOMMENDED value for the SYNC timer is 60 seconds. 2785 Authors' Addresses 2787 JP Vasseur (editor) 2788 Cisco Systems, Inc 2789 1414 Massachusetts Avenue 2790 Boxborough, MA 01719 2791 USA 2793 Email: jpv@cisco.com 2794 JL Le Roux (editor) 2795 France Telecom 2796 2, Avenue Pierre-Marzin 2797 Lannion, 22307 2798 FRANCE 2800 Email: jeanlouis.leroux@orange-ftgroup.com 2802 Full Copyright Statement 2804 Copyright (C) The Internet Society (2007). 2806 This document is subject to the rights, licenses and restrictions 2807 contained in BCP 78, and except as set forth therein, the authors 2808 retain all their rights. 2810 This document and the information contained herein are provided on an 2811 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2812 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2813 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2814 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2815 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2816 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2818 Intellectual Property 2820 The IETF takes no position regarding the validity or scope of any 2821 Intellectual Property Rights or other rights that might be claimed to 2822 pertain to the implementation or use of the technology described in 2823 this document or the extent to which any license under such rights 2824 might or might not be available; nor does it represent that it has 2825 made any independent effort to identify any such rights. Information 2826 on the procedures with respect to rights in RFC documents can be 2827 found in BCP 78 and BCP 79. 2829 Copies of IPR disclosures made to the IETF Secretariat and any 2830 assurances of licenses to be made available, or the result of an 2831 attempt made to obtain a general license or permission for the use of 2832 such proprietary rights by implementers or users of this 2833 specification can be obtained from the IETF on-line IPR repository at 2834 http://www.ietf.org/ipr. 2836 The IETF invites any interested party to bring to its attention any 2837 copyrights, patents or patent applications, or other proprietary 2838 rights that may cover technology that may be required to implement 2839 this standard. Please address the information to the IETF at 2840 ietf-ipr@ietf.org. 2842 Acknowledgment 2844 Funding for the RFC Editor function is provided by the IETF 2845 Administrative Support Activity (IASA).