idnits 2.17.1 draft-ietf-pce-pcep-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3467. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4420 (Obsoleted by RFC 5420) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 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 3 Intended status: Standards Track JL. Le Roux, Ed. 4 Created: March 15, 2008 France Telecom 5 Expires: September 15, 2008 7 Path Computation Element (PCE) Communication Protocol (PCEP) 8 draft-ietf-pce-pcep-11.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 September 15, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document specifies the Path Computation Element Communication 42 Protocol (PCEP) for communications between a Path Computation Client 43 (PCC) and a Path Computation Element (PCE), or between two PCEs. 44 Such interactions include path computation requests and path 45 computation replies as well as notifications of specific states 46 related to the use of a PCE in the context of Multiprotocol Label 47 Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP 48 is designed to be flexible and extensible so as to easily allow for 49 the addition of further messages and objects, should further 50 requirements be expressed in the future. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Architectural Protocol Overview (Model) . . . . . . . . . . . 6 64 4.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Architectural Protocol Overview . . . . . . . . . . . . . 6 66 4.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 7 67 4.2.2. Path Computation Request Sent By a PCC to a PCE . . . 8 68 4.2.3. Path Computation Reply Sent By The PCE to a PCC . . . 9 69 4.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 11 70 4.2.5. Error . . . . . . . . . . . . . . . . . . . . . . . . 13 71 4.2.6. Termination of the PCEP Session . . . . . . . . . . . 13 72 4.2.7. Intermitent versus Permanent PCEP Session . . . . . . 14 73 5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 14 74 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 15 76 6.2. Open Message . . . . . . . . . . . . . . . . . . . . . . . 15 77 6.3. Keepalive Message . . . . . . . . . . . . . . . . . . . . 16 78 6.4. Path Computation Request (PCReq) Message . . . . . . . . . 17 79 6.5. Path Computation Reply (PCRep) Message . . . . . . . . . . 18 80 6.6. Notification (PCNtf) Message . . . . . . . . . . . . . . . 20 81 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 20 82 6.8. Close Message . . . . . . . . . . . . . . . . . . . . . . 21 83 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 22 84 7.1. PCE TLV Format . . . . . . . . . . . . . . . . . . . . . . 22 85 7.2. Common Object Header . . . . . . . . . . . . . . . . . . . 22 86 7.3. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 24 87 7.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 25 88 7.4.1. Object Definition . . . . . . . . . . . . . . . . . . 26 89 7.4.2. Handling of the RP Object . . . . . . . . . . . . . . 28 90 7.5. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 28 91 7.6. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 31 92 7.7. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 32 93 7.8. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 33 94 7.9. Explicit Route Object . . . . . . . . . . . . . . . . . . 36 95 7.10. Reported Route Object . . . . . . . . . . . . . . . . . . 36 96 7.11. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 37 97 7.12. Include Route Object Object . . . . . . . . . . . . . . . 38 98 7.13. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 39 99 7.13.1. Notion of Dependent and Synchronized Path 100 Computation Requests . . . . . . . . . . . . . . . . . 39 101 7.13.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 41 102 7.13.3. Handling of the SVEC Object . . . . . . . . . . . . . 42 103 7.14. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 42 104 7.15. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 45 105 7.16. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 49 106 7.17. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 50 107 8. Manageability Considerations . . . . . . . . . . . . . . . . . 51 108 8.1. Control of Function and Policy . . . . . . . . . . . . . . 51 109 8.2. Information and Data Models . . . . . . . . . . . . . . . 53 110 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 53 111 8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 53 112 8.5. Requirements on Other Protocols and Functional 113 Components . . . . . . . . . . . . . . . . . . . . . . . . 54 114 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 54 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 116 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 54 117 9.2. PCEP Top-Level Registry . . . . . . . . . . . . . . . . . . 54 118 9.2.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . 54 119 9.2.2. PCEP Object . . . . . . . . . . . . . . . . . . . . . 55 120 9.2.3. RP Object . . . . . . . . . . . . . . . . . . . . . . 56 121 9.2.4. Notification Object . . . . . . . . . . . . . . . . . 57 122 9.2.5. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . 57 123 9.2.6. CLOSE Object . . . . . . . . . . . . . . . . . . . . . 59 124 9.2.7. NO-PATH Object . . . . . . . . . . . . . . . . . . . . 59 125 9.2.7.1. No-Path Nature of Issue . . . . . . . . . . . . . . 59 126 9.2.7.2. No-Path Bit Flags . . . . . . . . . . . . . . . . . 60 127 9.2.8. METRIC Object . . . . . . . . . . . . . . . . . . . . 60 128 9.2.8.1. Metric Type . . . . . . . . . . . . . . . . . . . . 60 129 9.2.8.2. Metric Control Flags . . . . . . . . . . . . . . . 60 130 9.2.9. PCEP TLV Type Indicators . . . . . . . . . . . . . . . 61 131 9.2.10. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . 61 132 10. Security Considerations . . . . . . . . . . . . . . . . . . . 62 133 10.1. PCEP Authentication and Integrity . . . . . . . . . . . . 62 134 10.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 62 135 10.3. Protection Against Denial of Service Attacks . . . . . . . 63 136 10.3.1. Protection Against TCP DoS Attacks . . . . . . . . . . 63 137 10.3.2. Request Input Shaping/Policing . . . . . . . . . . . . 63 138 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 63 139 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 140 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 141 13.1. Normative References . . . . . . . . . . . . . . . . . . . 65 142 13.2. Informative References . . . . . . . . . . . . . . . . . . 65 143 Appendix A. PCEP Finite State Machine (FSM) . . . . . . . . . . . 68 144 Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 74 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 146 Intellectual Property and Copyright Statements . . . . . . . . . . 76 148 1. Introduction 150 [RFC4655] describes the motivations and architecture for a Path 151 Compuation Element (PCE) based model for the computation of 152 Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic 153 Engineering Label Swtich Paths (TE LSPs). The model allows for the 154 separation of PCE from Path Computation Client (PCC), and allows for 155 the cooperation between PCEs. This necessitates a communication 156 protocol between PCC and PCE, and between PCEs. [RFC4657] states the 157 generic requirements for such a protocol including the requirement 158 for using the same protocol between PCC and PCE, and between PCEs. 159 Additional application-specific requirements (for scenarios such as 160 inter-area, inter-AS, etc.) are not included in [RFC4657], but there 161 is a requirement that any solution protocol must be easily extensible 162 to handle other requirements as they are introduced in application- 163 specific requirements documents. Examples of such application- 164 specific requirements are [RFC4927], 165 [I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req]. 167 This document specifies the Path Computation Element Communication 168 Protocol (PCEP) for communications between a PCC and a PCE, or 169 between two PCEs, in compliance with [RFC4657]. Such interactions 170 include path computation requests and path computation replies as 171 well as notifications of specific states related to the use of a PCE 172 in the context of MPLS and GMPLS Traffic Engineering. 174 PCEP is designed to be flexible and extensible so as to easily allow 175 for the addition of further messages and objects, should further 176 requirements be expressed in the future. 178 2. Terminology 180 Terminology used in this document 182 AS: Autonomous System. 184 Explicit path: Full explicit path from start to destination made of a 185 list of strict hops where a hop may be an abstract node such as an 186 AS. 188 IGP area: OSPF area or IS-IS level. 190 Inter-domain TE LSP: A TE LSP whose path transits at least two 191 different domains where a domain can be an IGP area, an Autonomous 192 System or a sub-AS (BGP confederations). 194 PCC: Path Computation Client: any client application requesting a 195 path computation to be performed by a Path Computation Element. 197 PCE: Path Computation Element: an entity (component, application or 198 network node) that is capable of computing a network path or route 199 based on a network graph and applying computational constraints. 201 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or a 202 PCE). 204 TED: Traffic Engineering Database that contains the topology and 205 resource information of the domain. The TED may be fed by IGP 206 extensions or potentially by other means. 208 TE LSP: Traffic Engineering Label Switched Path. 210 Strict/loose path: mix of strict and loose hops comprising at least 211 one loose hop representing the destination where a hop may be an 212 abstract node such as an AS. 214 Within this document, when describing PCE-PCE communications, the 215 requesting PCE fills the role of a PCC. This provides a saving in 216 documentation without loss of function. 218 3. Assumptions 220 [RFC4655] describes various types of PCE. PCEP does not make any 221 assumption and thus does not impose any constraint on the nature of 222 the PCE. 224 Moreover, it is assumed that the PCE has the required information 225 (usually including network topology and resource information) so as 226 to perform the computation of a path for a TE LSP. Such information 227 can be gathered by routing protocols or by some other means. The way 228 in which the information is gathered is out of the scope of this 229 document. 231 Similarly, no assumption is made about the discovery method used by a 232 PCC to discover a set of PCEs (e.g., via static configuration or 233 dynamic discovery) and on the algorithm used to select a PCE. For 234 reference, [RFC4674] defines a list of requirements for dynamic PCE 235 discovery and IGP-based solutions for such PCE discovery are 236 specified in [RFC5088] and [RFC5089]. 238 4. Architectural Protocol Overview (Model) 240 The aim of this section is to describe the PCEP model in the spirit 241 of [RFC4101]. An architecture protocol overview (the big picture of 242 the protocol) is provided in this section. Protocol details can be 243 found in further sections. 245 4.1. Problem 247 The PCE-based architecture used for the computation of path for MPLS 248 and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the 249 PCE are not collocated, a communication protocol between the PCC and 250 the PCE is needed. PCEP is such a protocol designed specifically for 251 communications between a PCC and a PCE or between two PCEs in 252 compliance with [RFC4657]: a PCC may use PCEP to send a path 253 computation request for one or more TE LSPs to a PCE and the PCE may 254 reply with a set of computed paths if one or more paths can be found 255 that satisfies the set of constraints. 257 4.2. Architectural Protocol Overview 259 PCEP operates over TCP, which fulfils the requirements for reliable 260 messaging and flow control without further protocol work. 262 Several PCEP messages are defined: 264 - Open and Keepalive messages are used to initiate and maintain a 265 PCEP session respectively. 267 - PCReq: a PCEP message sent by a PCC to a PCE to request a path 268 computation. 270 - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path 271 computation request. A PCRep message can either contain a set of 272 computed paths if the request can be satisfied, or a negative reply 273 if not. The negative reply may indicate the reason why no path 274 could be found. 276 - PCNtf: a PCEP notification message either sent by a PCC to a PCE or 277 a PCE to a PCC to notify of a specific event. 279 - PCErr: a PCEP message sent upon the occurrence of a protocol error 280 condition. 282 - Close message: a message used to close a PCEP session. 284 The set of available PCEs may be either statically configured on a 285 PCC or dynamically discovered. The mechanisms used to discover one 286 or more PCEs and to select a PCE are out of the scope of this 287 document. 289 A PCC may have PCEP sessions with more than one PCE and similarly a 290 PCE may have PCEP sessions with multiple PCCs. 292 4.2.1. Initialization Phase 294 The initialization phase consists of two successive steps (described 295 in a schematic form in Figure 1): 297 1) Establishment of a TCP connection (3-way handshake) between the 298 PCC and the PCE. 300 2) Establishment of a PCEP session over the TCP connection. 302 Once the TCP connection is established, the PCC and the PCE (also 303 referred to as "PCEP peers") initiate PCEP session establishment 304 during which various session parameters are negotiated. These 305 parameters are carried within Open messages and include the Keepalive 306 timer, the Deadtimer and potentially other detailed capabilities and 307 policy rules that specify the conditions under which path computation 308 requests may be sent to the PCE. If the PCEP session establishment 309 phase fails because the PCEP peers disagree on the session parameters 310 or one of the PCEP peers does not answer after the expiration of the 311 establishment timer, the TCP connection is immediately closed. 312 Successive retries are permitted but an implementation should make 313 use of an exponential back-off session establishment retry procedure. 315 Keepalive messages are used to acknowledge Open messages, and once 316 the PCEP session has been successfully established, Keepalive 317 messages may be exchanged between PCEP peers to ensure the liveness 318 of the PCEP session. 320 Only one PCEP session can exist between a pair a PCEP peers at any 321 one time. 323 Details about the Open message and the Keepalive message can be found 324 inSection 6.2 and Section 6.3 respectively. 326 +---+ +---+ 327 |PCC| |PCE| 328 +-+-+ +-+-+ 329 | | 330 | Open msg | 331 |-------- | 332 | \ Open msg | 333 | \ ---------| 334 | \/ | 335 | /\ | 336 | / -------->| 337 | / | 338 |<------ Keepalive| 339 | --------| 340 |Keeplaive / | 341 |-------- / | 342 | \/ | 343 | /\ | 344 |<------ ---------->| 345 | | 346 : : 347 : : 348 | | 349 |---- Keepalive ----->| 350 | | 351 |<--- Keepalive ------| 352 | | 354 Figure 1: PCEP Initialization phase (initiated by a PCC) 356 (Note that once the PCEP session is established, the exchange of 357 Keepalive messages is optional.) 359 4.2.2. Path Computation Request Sent By a PCC to a PCE 361 +---+ +---+ 362 |PCC| |PCE| 363 +-+-+ +-+-+ 364 1)Path computation | | 365 event | | 366 | | 367 2)PCE Selection | | 368 | | 369 3)Path computation | | 370 request sent to | | 371 the selected PCE | | 372 |---- PCReq message -->| 374 Figure 2: Path Computation request 376 Once a PCC has successfully established a PCEP session with one or 377 more PCEs, if an event is triggered that requires the computation of 378 a set of paths, the PCC first selects one or more PCE. Note that the 379 PCE selection decision process may have taken place prior to the PCEP 380 session establishment. 382 Once the PCC has selected a PCE, it sends the PCE a path computation 383 request to the PCE (PCReq message) that contains a variety of objects 384 that specify the set of constraints and attributes for the path to be 385 computed. For example "Compute a TE LSP path with source IP 386 address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B 387 Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may 388 desire to specify the urgency of such request by assigning a request 389 priority. Each request is uniquely identified by a request-id number 390 and the PCC-PCE address pair. The process is shown in a schematic 391 form in Figure 2. 393 Details about the PCReq message can be found in Section 6.4 395 4.2.3. Path Computation Reply Sent By The PCE to a PCC 397 +---+ +---+ 398 |PCC| |PCE| 399 +-+-+ +-+-+ 400 | | 401 |---- PCReq message--->| 402 | |1) Path computation 403 | |request received 404 | | 405 | |2)Path successfully 406 | |computed 407 | | 408 | |3) Computed paths 409 | |sent to the PCC 410 |<--- PCRep message ---| 411 | (Positive reply) | 413 Figure 3a: Path Computation Request With Successful 414 Path Computation 416 +---+ +---+ 417 |PCC| |PCE| 418 +-+-+ +-+-+ 419 | | 420 | | 421 |---- PCReq message -->| 422 | |1) Path computation 423 | |request received 424 | | 425 | |2) No Path found that 426 | |satisfies the request 427 | | 428 | |3) Negative reply sent to 429 | |the PCC (optionally with 430 | |various additional 431 | |information) 432 |<--- PCRep message ---| 433 | (Negative reply) | 435 Figure 3b: Path Computation Request With Unsuccessful 436 Path Computation 438 Upon receiving a path computation request from a PCC, the PCE 439 triggers a path computation, the result of which can either be: 441 o Positive (Figure 3-a): the PCE manages to compute a path that 442 satisfies the set of required constraints, in which case the PCE 443 returns the set of computed paths to the requesting PCC. Note 444 that PCEP supports the capability to send a single request that 445 requires the computation of more than one path (e.g., computation 446 of a set of link-diverse paths). 448 o Negative (Figure 3-b): no path could be found that satisfies the 449 set of constraints. In this case, a PCE may provide the set of 450 constraints that led to the path computation failure. Upon 451 receiving a negative reply, a PCC may decide to resend a modified 452 request or take any other appropriate action. 454 Details about the PCRep message can be found in Section 6.5. 456 4.2.4. Notification 458 There are several circumstances in which a PCE may want to notify a 459 PCC of a specific event. For example, suppose that the PCE suddenly 460 gets overloaded, potentially leading to unacceptable response times. 461 The PCE may want to notify one or more PCCs that some of their 462 requests (listed in the notification) will not be satisfied or may 463 experience unacceptable delays. Upon receiving such notification, 464 the PCC may decide to redirect its path computation requests to 465 another PCE should an alternate PCE be available. Similarly, a PCC 466 may desire to notify a PCE of a particular event such as the 467 cancellation of pending requests. 469 +---+ +---+ 470 |PCC| |PCE| 471 +-+-+ +-+-+ 472 1)Path computation | | 473 event | | 474 | | 475 2)PCE Selection | | 476 | | 477 3)Path computation | | 478 request X sent to | | 479 the selected PCE | | 480 |---- PCReq message -->| 481 | |4) Path computation 482 | |request queued 483 | | 484 5) Path computation| | 485 request X cancelled| | 486 |---- PCNtf message -->| 487 | |6) Path computation 488 | |request X cancelled 490 Figure 4: Example of PCC Notification (Cancellation 491 Notification) Sent To a PCE 493 +---+ +---+ 494 |PCC| |PCE| 495 +-+-+ +-+-+ 496 1)Path computation | | 497 event | | 498 | | 499 2)PCE Selection | | 500 | | 501 3)Path computation | | 502 request X sent to | | 503 the selected PCE | | 504 |---- PCReq message -->| 505 | |4) Path computation 506 | |request queued 507 | | 508 | |5) PCE gets overloaded 509 | | 510 | |6) Path computation 511 | |request X cancelled 512 |<--- PCNtf message ---| 514 Figure 5: Example of PCE Notification (Cancellation 515 Notification) Sent To a PCC 517 Details about the PCNtf message can be found in Section 6.6. 519 4.2.5. Error 521 The PCEP Error message (also referred to as a PCErr message) is sent 522 in several situations: when a protocol error condition is met or when 523 the request is not compliant with the PCEP specification (e.g., 524 reception of a malformed message, reception of a message with a 525 mandatory missing object, policy violation, unexpected message, 526 unknown request reference, ...). 528 +---+ +---+ 529 |PCC| |PCE| 530 +-+-+ +-+-+ 531 1)Path computation | | 532 event | | 533 | | 534 2)PCE Selection | | 535 | | 536 3)Path computation | | 537 request X sent to | | 538 the selected PCE | | 539 |---- PCReq message--->| 540 | |4) Reception of a 541 | |malformed object 542 | | 543 | |5) Request discarded 544 |<-- PCErr message ----| 546 Figure 6: Example of Error message Sent By a PCE To a PCC 547 In Reply To The Reception Of a Malformed Object 549 Details about the PCErr message can be found in Section 6.7. 551 4.2.6. Termination of the PCEP Session 553 When one of the PCEP peers desires to terminate a PCEP session it 554 first sends a PCEP Close message and then closes the TCP connection. 555 If the PCEP session is terminated by the PCE, the PCC clears all the 556 states related to pending requests previously sent to the PCE. 557 Similarly, if the PCC terminates a PCEP session the PCE clears all 558 pending path computation requests sent by the PCC in question as well 559 as the related states. A Close message can only be sent to terminate 560 a PCEP session if the PCEP session has previously been established. 562 In case of TCP connection failure, the PCEP session is immediately 563 terminated. 565 Details about the Close message can be found in Section 6.8. 567 4.2.7. Intermitent versus Permanent PCEP Session 569 An implementation may decide to keep the PCEP session alive (and thus 570 the corresponding TCP connection) for an unlimited time (this may for 571 instance be appropriate when path computation requests are sent on a 572 frequent basis so as to avoid to open a TCP connection each time a 573 path computation request is needed, which would incur additional 574 processing delays). Conversely, in some other circumstances, it may 575 be desirable to systematically open and close a PCEP session for each 576 PCEP request (for instance when sending a path computation request is 577 a rare event). 579 5. Transport Protocol 581 PCEP operates over TCP using a well-known TCP port (to be assigned by 582 IANA). This allows the requirements of reliable messaging and flow 583 control to be met without further protocol work. 585 6. PCEP Messages 587 A PCEP message consists of a common header followed by a variable 588 length body made of a set of objects that can either be mandatory or 589 optional. In the context of this document, an object is said to be 590 mandatory in a PCEP message when the object MUST be included for the 591 message to be considered as valid. A PCEP message with a missing 592 mandatory object MUST trigger an Error message (see Section 7.15). 593 Conversely, if an object is optional, the object may or may not be 594 present. 596 A flag referred to as the P flag is defined in the common header of 597 each PCEP object (see Section 7.2). When this flag is set in an 598 object in a PCReq, the PCE MUST take the information carried in the 599 object into account during the path computation. For example, the 600 METRIC object defined in Section 7.8 allows a PCC to specify a 601 bounded acceptable path cost. The METRIC object is optional, but a 602 PCC may set a flag to ensure that the constraint is taken into 603 account. In this case, if the constraint cannot be taken into 604 account by the PCE, the PCE MUST trigger an Error message. 606 For each PCEP message type, rules are defined that specify the set of 607 objects that the message can carry. We use the Backus-Naur Form 608 (BNF) to specify such rules. Square brackets refer to optional 609 sub-sequences. An implementation MUST form the PCEP messages using 610 the object ordering specified in this document. 612 6.1. Common header 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Ver | Flags | Message-Type | Message-Length | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 7: PCEP Message Common Header 622 Ver (Version - 3 bits): PCEP version number. Current version is 623 version 1. 625 Flags (5 bits): no flags are currently defined. Unassigned bits are 626 considered as reserved and MUST be set to zero on transmission. 628 Message-Type (8 bits): 630 The following message types are currently defined (to be confirmed by 631 IANA). 632 Value Meaning 633 1 Open 634 2 Keepalive 635 3 Path Computation Request 636 4 Path Computation Reply 637 5 Notification 638 6 Error 639 7 Close 641 Message-Length (16 bits): total length of the PCEP message expressed 642 in bytes including the common header. 644 6.2. Open Message 646 The Open message is a PCEP message sent by a PCC to a PCE and a PCE 647 to a PCC in order to establish a PCEP session. The Message-Type 648 field of the PCEP common header for the Open message is set to 1 (To 649 be confirmed by IANA). 651 Once the TCP connection has been successfully established, the first 652 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 653 an Open message as specified in Appendix A. Any message received 654 prior to an Open message MUST trigger a protocol error condition and 655 the PCEP session MUST be terminated. The Open message is used to 656 establish a PCEP session between the PCEP peers. During the 657 establishment phase the PCEP peers exchange several session 658 characteristics. If both parties agree on such characteristics the 659 PCEP session is successfully established. TOTO 660 Open message 661 ::= 662 664 The Open message MUST contain exactly one OPEN object (see 665 Section 7.3). 667 Various session characteristics are specified within the OPEN object. 668 Once the TCP connection has been successfully established the sender 669 MUST start an initialization timer called OpenWait after the 670 expiration of which if no Open message has been received it sends a 671 PCErr message and releases the TCP connection (see Appendix A for 672 details). 674 Once an Open message has been sent to a PCEP peer, the sender MUST 675 start an initialization timer called KeepWait after the expiration of 676 which if neither a KeepAlive message has been received nor a PCErr 677 message in case of disagreement of the session characteristics, a 678 PCErr message MUST be sent and the TCP connection MUST be released 679 (see Appendix A for details). 681 The KeepWait timer has a fixed value of 1 minute. 683 Upon the receipt of an Open message, the receiving PCEP peer MUST 684 determine whether the suggested PCEP session characteristics are 685 acceptable. If at least one of the characteristics is not 686 acceptable by the receiving peer, it MUST send an Error message. The 687 Error message SHOULD also contain the related Open object: for each 688 unacceptable session parameter, an acceptable parameter value SHOULD 689 be proposed in the appropriate field of the Open object in place of 690 the originally proposed value. The PCEP peer MAY decide to resend an 691 Open message with different session characteristics. If a second 692 Open message is received with the same set of parameters or with 693 parameters that are still unacceptable, the receiving peer MUST send 694 an Error message and it MUST immediately close the TCP connection. 695 Details about error message can be found in Section 7.15. 697 If the PCEP session characteristics are acceptable, the receiving 698 PCEP peer MUST send a Keepalive message (defined in Section 6.3) that 699 serves as an acknowledgment. 701 The PCEP session is considered as established once both PCEP peers 702 have received a Keepalive message from their peer. 704 6.3. Keepalive Message 706 A Keepalive message is a PCEP message sent by a PCC or a PCE in order 707 to keep the session in active state. The Keepalive message is also 708 used in response to an Open message to acknowledge that an Open 709 message has been received and that the PCEP session characteristics 710 are acceptable. The Message-Type field of the PCEP common header for 711 the Keepalive message is set to 2 (To be confirmed by IANA). The 712 Keepalive message does not contain any object. 714 PCEP has its own keepalive mechanism used to ensure of the liveness 715 of the PCEP session. This requires the determination of the 716 frequency at which each PCEP peer sends Keepalive messages. 717 Asymmetric values may be chosen; thus there is no constraint 718 mandating the use of identical keepalive frequencies by both PCEP 719 peers. The DeadTimer is defined as the period of time after the 720 expiration of which a PCEP peer declares the session down if no PCEP 721 message has been received (Keepalive or any other PCEP message: thus, 722 any PCEP message acts as a Keepalive message). Similarly, there is 723 no constraints mandating the use of identical DeadTimers by both PCEP 724 peers. The minimum KeepAlive timer value is 1 second. 726 Keepalive messages are sent at the frequency specified in the OPEN 727 object carried within an Open message according to the rules 728 speciifed in Section 7.3. Because any PCEP message may serve as 729 Keepalive, an implementation may either decide to send Keepalive 730 messages at fixed intervals regardless on whether other PCEP messages 731 might have been sent since the last sent Keepalive message, or may 732 decide to differ the sending of the next Keepalive message based on 733 the time at which the last PCEP message (other than Keepalive) was 734 sent. 736 Note that sending Keepalive messages to keep the session alive is 737 optional and PCEP peers may decide to not send Keepalive messages 738 once the PCEP session is established in which case the peer that does 739 not receive Keepalive messages does not expect to receive them and 740 MUST NOT declare the session as inactive. 742 Keepalive message 743 ::= 745 6.4. Path Computation Request (PCReq) Message 747 A Path Computation Request message (also referred to as a PCReq 748 message) is a PCEP message sent by a PCC to a PCE to request a path 749 computation. A PCReq message may carry more than one path 750 computation request. The Message-Type field of the PCEP common 751 header for the PCReq message is set to 3 (To be confirmed by IANA). 753 There are two mandatory objects that MUST be included within a PCReq 754 message: the RP and the END-POINTS objects (see section Section 7). 755 If one or both of these objects is missing, the receiving PCE MUST 756 send an error message to the requesting PCC. Other objects are 757 optional. 759 The format of a PCReq message is as follows: 760 ::= 761 [] 762 764 where: 765 ::=[] 766 ::=[] 768 ::= 769 770 [] 771 [] 772 [] 773 [[]] 774 [] 775 [] 776 where: 778 ::=[] 780 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 781 BALANCING objects are defined in Section 7. The special case of two 782 BANDWIDTH objects is discussed in detail in Section 7.7. 784 6.5. Path Computation Reply (PCRep) Message 786 The PCEP Path Computation Reply message (also referred to as a PCRep 787 message) is a PCEP message sent by a PCE to a requesting PCC in 788 response to a previously received PCReq message. The Message-Type 789 field of the PCEP common header is set to 4 (To be confirmed by 790 IANA). 792 The bundling of multiple replies to a set of path computation 793 requests within a single PCRep message is supported by PCEP. If a 794 PCE receives non-synchronized path computation requests by means of 795 one or more PCReq messages from a requesting PCC it MAY decide to 796 bundle the computed paths within a single PCRep message so as to 797 reduce the control plane load. Note that the counter side of such an 798 approach is the introduction of additional delays for some path 799 computation requests of the set. Conversely, a PCE that receives 800 multiple requests within the same PCReq message MAY decide to provide 801 each computed path in separate PCRep messages or within the same 802 PCRep message. A PCRep message may contain positive and negative 803 replies. 805 A PCRep message may contain a set of computed paths corresponding to 806 either a single path computation request with load-balancing (see 807 Section 7.16) or multiple path computation requests originated by a 808 requesting PCC. The PCRep message may also contain multiple 809 acceptable paths corresponding to the same request. 811 The PCRep message MUST contain at least one RP object. For each 812 reply that is bundled into a single PCReq message, an RP object MUST 813 be included that contains a Request-ID-number identical to the one 814 specified in the RP object carried in the corresponding PCReq message 815 (see Section 7.4 for the definition of the RP object). 817 If the path computation request can be satisfied (the PCE finds a set 818 of paths that satisfy the set of constraints), the set of computed 819 paths specified by means of ERO objects is inserted in the PCRep 820 message. The ERO is defined in Section 7.9. The situation where 821 multiple computed paths are provided in a PCRep message is discussed 822 in detail in Section 7.13. Furthermore, when a PCC requests the 823 computation of a set of paths for a total amount of bandwidth by 824 means of a LOAD-BALANCING object carried within a PCReq message, the 825 ERO of each computed path may be followed by a BANDWIDTH object as 826 discussed in section Section 7.16. 828 If the path computation request cannot be satisfied, the PCRep 829 message MUST include a NO-PATH object. The NO-PATH object (described 830 in Section 7.5) may also contain other information (e.g, reasons for 831 the path computation failure). 833 The format of a PCRep message is as follows: 834 ::= 835 837 where: 838 ::=[] 840 ::= 841 [] 842 [] 843 [] 845 ::=[] 847 ::= 849 where: 851 ::=[] 852 [] 853 [] 854 [] 856 ::=[] 858 6.6. Notification (PCNtf) Message 860 The PCEP Notification message (also referred to as the PCNtf message) 861 can be sent either by a PCE to a PCC, or by a PCC to a PCE, to notify 862 of a specific event. The Message-Type field of the PCEP common 863 header is set to 5 (To be confirmed by IANA). 865 The PCNtf message MUST carry at least one NOTIFICATION object and MAY 866 contain several NOTIFICATION objects should the PCE or the PCC intend 867 to notify of multiple events. The NOTIFICATION object is defined in 868 Section 7.14. The PCNtf message MAY also contain RP objects (see 869 Section 7.4 when the notification refers to particular path 870 computation requests. 872 The PCNtf message may be sent by a PCC or a PCE in response to a 873 request or in an unsolicited manner. 875 The format of a PCNtf message is as follows: 876 ::= 877 879 ::= [] 881 ::= [] 882 884 ::= 886 ::= 888 6.7. Error (PCErr) Message 890 The PCEP Error message (also referred to as a PCErr message) is sent 891 in several situations: when a protocol error condition is met or when 892 the request is not compliant with the PCEP specification (e.g., 893 reception of a malformed message, reception of a message with a 894 mandatory missing object, policy violation, unexpected message, 895 unknown request reference, ...). The Message-Type field of the PCEP 896 common header is set to 6 (To be confirmed by IANA). 898 The PCErr message is sent by a PCC or a PCE in response to a request 899 or in an unsolicited manner. If the PCErr message is sent in 900 response to a request, the PCErr message MUST include the set of RP 901 objects related to the pending path computation requests that 902 triggered the error condition. In the later case (unsolicited), no 903 RP object is inserted in the PCErr message. For example, no RP 904 object is inserted in a PCErr when the error condition occurred 905 during the initialization phase. A PCErr message MUST contain a 906 PCEP-ERROR object specifying the PCEP error condition. The PCEP- 907 ERROR object is defined in section Section 7.15. 909 The format of a PCErr message is as follows: 911 ::= 912 ( [] ) | 913 [] 915 ::=[] 916 ::=[] 917 918 ::=[] 919 ::=[] 921 The procedure upon the receipt of a PCErr message is defined in 922 Section 7.15. 924 6.8. Close Message 926 The Close message is a PCEP message that is either sent by a PCC to a 927 PCE or by a PCE to a PCC in order to close an established PCEP 928 session. The Message-Type field of the PCEP common header for the 929 Close message is set to 7 (To be confirmed by IANA). 931 Close message 932 ::= 933 935 The Close message MUST contain exactly one CLOSE object (see 936 Section 6.8). If more than one CLOSE object is present, the first 937 MUST be processed and subsequent objects ignored. 939 Upon the receipt of a vlaid Close message, the receiving PCEP peer 940 MUST cancel all pending requests, it MUST close the TCP connection 941 and MUST NOT send any further PCEP messages on the PCEP session. 943 7. Object Formats 945 PCEP objects have a common format. They begin with a common object 946 header (see Section 7.2). This is followed by object-specific fields 947 defined for each different object. The object may also include one 948 or more type-length-value (TLV) encoded data sets. Each TLV has the 949 same structure as described in Section 7.1. 951 7.1. PCE TLV Format 953 A PCEP object may include a set of one or more optional TLVs. 955 All PCEP TLVs have the following format: 957 Type: 2 bytes 958 Length: 2 bytes 959 Value: variable 960 A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes 961 specifying the TLV length, and a value field. 963 The Length field defines the length of the value portion in bytes. 964 The TLV is padded to 4-bytes alignment; padding is not included in 965 the Length field (so a three byte value would have a length of three, 966 but the total size of the TLV would be eight bytes). 968 Unrecognized TLVs MUST be ignored. 970 IANA management of the PCEP Object TLV type identifier codespace is 971 described in Section 9. 973 7.2. Common Object Header 975 A PCEP object carried within a PCEP message consists of one or more 976 32-bit words with a common header which has the following format: 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Object-Class | OT |Res|P|I| Object Length (bytes) | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | | 984 // (Object body) // 985 | | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 Figure 8: PCEP common object header 990 Object-Class (8 bits): identifies the PCEP object class. 992 OT (Object-Type - 4 bits): identifies the PCEP object type. 994 The Object-Class and Object-Type fields are managed by IANA. 996 The Object-Class and Object-Type fields uniquely identify each PCEP 997 object. 999 Res flags (2 bits). Reserved field. This field MUST be set to zero 1000 on transmission and MUST be ignored on receipt. Unassigned bits are 1001 considered as reserved. They MUST be set to zero on transmission and 1002 MUST be ignored on receipt. 1004 o P flag (Processing-Rule - 1-bit): the P flag allows a PCC to 1005 specify in a PCReq message sent to a PCE whether the object must 1006 be taken into account by the PCE during path computation or is 1007 just optional. When the P flag is set, the object MUST be taken 1008 into account by the PCE. Conversely, when the P flag is cleared, 1009 the object is optional and the PCE is free to ignore it. 1011 o I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 1012 message to indicate to a PCC whether or not an optional object was 1013 processed. The PCE MAY include the ignored optional object in its 1014 reply and set the I flag to indicate that the optional object was 1015 ignored during path computation. When the I flag is cleared, the 1016 PCE indicates that the optional object was processed during the 1017 path computation. The setting of the I flag for optional objects 1018 is purely indicative and optional. The I flag has no meaning in a 1019 PCRep message when the P flag has been set in the corresponding 1020 PCReq message. 1022 If the PCE does not understand an object with the P flag set or 1023 understands the object but decides to ignore the object, the entire 1024 PCEP message MUST be rejected and the PCE MUST send a PCErr message 1025 with Error-Type="Unknown Object" or "Not supported Object" along with 1026 the corresponding RP object. Note that if a PCReq includes multiple 1027 requests, only requests for which an object with the P flag set is 1028 unknown/unrecognized MUST be rejected. 1030 Object Length (16 bits). Specifies the total object length including 1031 the header, in bytes. The Object Length field MUST always be a 1032 multiple of 4, and at least 4. The maximum object content length is 1033 65528 bytes. 1035 7.3. OPEN Object 1037 The OPEN object MUST be present in each Open message and MAY be 1038 present in a PCErr message. There MUST be only one OPEN object per 1039 Open or PCErr message. 1041 The OPEN object contains a set of fields used to specify the PCEP 1042 version, Keepalive frequency, DeadTimer, PCEP session ID along with 1043 various flags. The OPEN object may also contain a set of TLVs used 1044 to convey various session characteristics such as the detailed PCE 1045 capabilities, policy rules and so on. No TLVs are currently defined. 1047 OPEN Object-Class is to be assigned by IANA (recommended value=1) 1049 OPEN Object-Type is to be assigned by IANA (recommended value=1) 1051 The format of the OPEN object body is as follows: 1053 0 1 2 3 1054 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 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Ver | Flags | Keepalive | DeadTimer | SID | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | | 1059 // Optional TLVs // 1060 | | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 Figure 9: OPEN Object format 1065 Ver (3 bits): PCEP version. Current version is 1. 1067 Flags (5 bits): No Flags are currently defined. Unassigned bits are 1068 considered as reserved and MUST be set to zero on transmission. 1070 Keepalive (8 bits): maximum period of time (in seconds) between two 1071 consecutive PCEP messages sent by the sender of this message. The 1072 minimum value for the Keepalive is 1 second. When set to 0, once the 1073 session is established, no further Keepalive messages are sent to the 1074 remote peer. A RECOMMENDED value for the keepalive frequency is 30 1075 seconds. 1077 DeadTimer (8 bits): specifies the amount of time after the expiration 1078 of which the PCEP peer can declare the session with the sender of the 1079 Open message down if no PCEP message has been received. The 1080 DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is 1081 set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value 1082 of the Keepalive. 1084 Example: 1086 A sends an Open message to B with Keepalive=10 seconds and 1087 Deadtimer=30 seconds. This means that A sends Keepalive messages (or 1088 ay other PCEP message) to B every 10 seconds and B can declare the 1089 PCEP session with A down if no PCEP message has been received from A 1090 within any 30 second period. 1092 SID (PCEP session-ID - 8 bits): unsigned PCEP session number that 1093 identifies the current session. The SID MUST be incremented each 1094 time a new PCEP session is established and is used for logging and 1095 troubleshooting purposes. There is one SID number in each direction. 1097 Optional TLVs may be included within the OPEN object body to specify 1098 PCC or PCE characteristics. The specification of such TLVs is 1099 outside the scope of this document. 1101 When present in an Open message, the OPEN object specifies the 1102 proposed PCEP session characteristics. Upon receiving unacceptable 1103 PCEP session characteristics during the PCEP session initialization 1104 phase, the receiving PCEP peer (PCE) MAY include an OPEN object 1105 within the PCErr message so as to propose alternative acceptable 1106 session characteristic values. 1108 7.4. RP Object 1110 The RP (Request Parameters) object MUST be carried within each PCReq 1111 and PCRep messages and MAY be carried within PCNtf and PCErr 1112 messages. The RP object is used to specify various characteristics 1113 of the path computation request. 1115 The P flag of the RP object MUST be set in PCReq and PCReq messages 1116 and MUST be cleared in PCNtf and PCErr messages. If the RP objet is 1117 received with the P flag set incorrectely according to the rules 1118 states above, the receiving peer MUST send a PCErr message with 1119 Error-type=10 and Error-value=1. The corresponding path computation 1120 request MUST be cancelled by the PCE without further notification. 1122 7.4.1. Object Definition 1124 RP Object-Class is to be assigned by IANA (recommended value=2) 1126 RP Object-Type is to be assigned by IANA (recommended value=1) 1128 The format of the RP object body is as follows: 1130 0 1 2 3 1131 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 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Flags |O|B|R| Pri | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Request-ID-number | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | | 1138 // Optional TLVs // 1139 | | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 Figure 10: RP object body format 1144 The RP object body has a variable length and may contain additional 1145 TLVs. No TLVs are currently defined. 1147 Flags (32 bits) 1149 The following flags are currently defined: 1151 o Pri (Priority - 3 bits): the Priority field may be used by the 1152 requesting PCC to specify to the PCE the request's priority from 1 1153 to 7. The decision of which priority should be used for a 1154 specific request is of a local matter and MUST be set to 0 when 1155 unused. Furthermore, the use of the path computation request 1156 priority by the PCE's scheduler is implementation specific and out 1157 of the scope of this document. Note that it is not required for a 1158 PCE to support the priority field: in this case, it is RECOMMENDED 1159 that the PCC set the priority field to 0 in the RP object. If the 1160 PCE does not take into account the request priority, it is 1161 RECOMMENDED to set the priority field to 0 in the RP object 1162 carried within the corresponding PCRep message, regardless of the 1163 priority value contained in the RP object carried within the 1164 corresponding PCReq message. A higher numerical value of the 1165 priority field reflects a higher priority. Note that it is the 1166 responsibility of the network administrator to make use of the 1167 priority values in a consistent manner across the various PCCs. 1168 The ability of a PCE to support request prioritization MAY be 1169 dynamically discovered by the PCCs by means of PCE capability 1170 discovery. If not advertised by the PCE, a PCC may decide to set 1171 the request priority and will learn the ability of the PCE to 1172 support request prioritization by observing the Priority field of 1173 the RP object received in the PCRep message. If the value of the 1174 Pri field is set to 0, this means that the PCE does not support 1175 the handling of request priorities: in other words, the path 1176 computation request has been honoured but without taking the 1177 request priority into account. 1179 o R (Reoptimization - 1 bit): when set, the requesting PCC specifies 1180 that the PCReq message relates to the reoptimization of an 1181 existing TE LSP in which case, in addition to the TE LSP 1182 attributes, the current path of the existing TE LSP to be 1183 reoptimized MUST be provided in the PCReq (except for 0-bandwidth 1184 TE LSPs) message by means of an RRO object defined in Section 7.10 1185 and (again except in the case of 0-bandwidth TE LSPs) the existing 1186 bandwidth of the LSP to be reoptimized MUST be supplied in an 1187 additional BANDWIDTH object as described in Section 7.7. 1189 o B (Bi-directional - 1 bit): when set, the PCC specifies that the 1190 path computation request relates to a bidirectional TE LSP that 1191 has the same traffic engineering requirements including fate 1192 sharing, protection and restoration, LSRs, TE Links, and resource 1193 requirements (e.g., latency and jitter) in each direction. When 1194 cleared, the TE LSP is unidirectional. 1196 o O (strict/loose - 1 bit): when set, in a PCReq message, this 1197 indicates that a loose path is acceptable. Otherwise, when 1198 cleared, this indicates to the PCE that a path exclusively made of 1199 strict hops is required. In a PCRep message, when the O bit is 1200 set this indicates that the returned path is a loose path, 1201 otherwise (the O bit is cleared), the returned path is made of 1202 strict hops. 1204 Unassigned bits are considered as reserved and MUST be set to zero on 1205 transmission. 1207 Request-ID-number (32 bits). The Request-ID-number value combined 1208 with the source IP address of the PCC and the PCE address uniquely 1209 identify the path computation request context. The Request-ID-number 1210 MUST be incremented each time a new request is sent to the PCE. The 1211 value 0x0000000 is considered as invalid. If no path computation 1212 reply is received from the PCE, and the PCC wishes to resend its 1213 request, the same Request-ID-number MUST be used. Conversely, 1214 different Request-ID-number MUST be used for different requests sent 1215 to a PCE. The same Request-ID-number MAY be used for path 1216 computation requests sent to different PCEs. The path computation 1217 reply is unambiguously identified by the IP source address of the 1218 replying PCE. 1220 7.4.2. Handling of the RP Object 1222 If a PCReq message is received that does not contain an RP object, 1223 the PCE MUST send a PCErr message to the requesting PCC with Error- 1224 type="Required Object missing" and Error-value="RP Object missing". 1226 If the O bit of the RP message carried within a PCReq message is 1227 cleared and local policy has been configured on the PCE to not 1228 provide explicit paths (for instance, for confidentiality reasons), a 1229 PCErr message MUST be sent by the PCE to the requesting PCC and the 1230 pending path computation request MUST be discarded. The Error-type 1231 is "Policy Violation" and Error-value is "O bit cleared". 1233 R bit: when the R bit of the RP object is set in a PCReq message, 1234 this indicates that the path computation request relates to the 1235 reoptimization of an existing TE LSP. In this case, the PCC MUST 1236 also provide the strict/loose path by including an RRO object in the 1237 PCReq message so as to avoid/limit double bandwidth counting if and 1238 only if the TE LSP is a non-0-bandwidth TE LSP. If the PCC has not 1239 requested a strict path (O bit set), a reoptimization can still be 1240 requested by the PCC but this requires that the PCE either be 1241 stateful (keep track of the previously computed path with the 1242 associated list of strict hops), or have the ability to retrieve the 1243 complete required path segment. Alternatively the PCC MUST inform 1244 the PCE of the working path with the associated list of strict hops 1245 in PCReq. The absence of an RRO in the PCReq message for a non-0- 1246 bandwidth TE LSP when the R bit of the RP object is set MUST trigger 1247 the sending of a PCErr message with Error-type="Required Object 1248 Missing" and Error-value="RRO Object missing for reoptimization". 1250 If the PCC receives a PCRep message that contains a RP object 1251 referring to an unknown Request-ID-Number, the PCC MUST send a PCErr 1252 message with Error-Type="Unknown request reference". 1254 7.5. NO-PATH Object 1256 The NO-PATH object is used in PCRep messages in response to an 1257 unsuccessful path computation request (the PCE could not find a path 1258 satisfying the set of constraints). When a PCE cannot find a path 1259 satisfying a set of constraints, it MUST include a NO-PATH object in 1260 the PCRep message. 1262 There are several categories of issue that can lead to a negative 1263 reply. For example, the PCE chain might be broken (should there be 1264 more than one PCE involved in the path computation) or no path 1265 obeying the set constraints could be found. The "NI (Nature of 1266 Issue)" field in the NO-PATH object is used to report the error 1267 category. 1269 Optionally, if the PCE supports such capability, the NO-PATH object 1270 MAY contain an optional NO-PATH-VECTOR TLV defined below and used to 1271 provide more information on the reasons that led to a negative reply. 1272 The PCRep message MAY also contain a list of objects that specify the 1273 set of constraints that could not be satisfied. The PCE MAY just 1274 replicate the set of objects that was received that was the cause of 1275 the unsuccessful computation or MAY optionally report a suggested 1276 value for which a path could have been found (in which case the value 1277 differs from the value in the original request). 1279 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1281 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1283 The format of the NO-PATH object body is as follows: 1285 0 1 2 3 1286 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 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 |Nature Of Issue|C| Flags | Reserved | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | | 1291 // Optional TLVs // 1292 | | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 Figure 11: NO-PATH Object Format 1297 NI - Nature Of Issue (8 bits): the NI field is used to report the 1298 nature of the issue that led to a negative reply. Two values are 1299 currently defined: 1301 0x00: No path satisfying the set of constraints could be found 1303 0x01: PCE chain broken 1305 IANA management of the NI field codespace is described in Section 9. 1307 Flags (16 bits). 1309 The following flag is currently defined: 1311 C flag (1 bit): when set, the PCE indicates the set of unsatisfied 1312 constraints (reasons why a path could not be found) in the PCRep 1313 message by including the relevant PCEP objects. When cleared, no 1314 failing constraints are specified. The C flag has no meaning and is 1315 ignored unless the NI field is set to 0x00. 1317 Reserved (8 bits): This field MUST be set to zero on transmission and 1318 MUST be ignored on receipt. 1320 The NO-PATH object body has a variable length and may contain 1321 additional TLVs. The only TLV currently defined is the NO-PATH- 1322 VECTOR TLV defined below. 1324 Example: consider the case of a PCC that sends a path computation 1325 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1326 find a path for X MBits/s. In this case, the PCE must include in the 1327 PCRep message a NO-PATH object. Optionally the PCE may also include 1328 the original BANDWIDTH object so as to indicate that the reason for 1329 the unsuccessful computation is the bandwidth constraint (in this 1330 case, the NI field value is 0x00 and C flag is set). If the PCE 1331 supports such capability it may alternatively include the BANDWIDTH 1332 Object and report a value of Y in the bandwidth field of the 1333 BANDWIDTH object (in this case, the C flag is set) where Y refers to 1334 the bandwidth for which a TE LSP with the same other characteristics 1335 could have been computed. 1337 When the NO-PATH object is absent from a PCRep message, the path 1338 computation request has been fully satisfied and the corresponding 1339 paths are provided in the PCRep message. 1341 An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH 1342 object in order to provide more information on the reasons that led 1343 to a negative reply. 1345 The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined 1346 in section 7.1 and is comprised of 2 bytes for the type, 2 bytes 1347 specifying the TLV length (length of the value portion in bytes) 1348 followed by a fixed length value field of 32-bit flags field. 1350 TYPE: To be assigned by IANA (suggested value=1) 1351 LENGTH: 1 1352 VALUE: 32-bit flags field 1354 IANA is requested to manage the space of flags carried in the NO- 1355 PATH-VECTOR TLV (see Section 9). 1357 The following flags are currently defined: 1359 o Bit number: 1 - PCE currently unavailable 1361 o Bit number: 2 - Unknown destination 1363 o Bit number: 3 - Unknown source 1365 7.6. END-POINT Object 1367 The END-POINTS object is used in a PCReq message to specify the 1368 source IP address and the destination IP address of the path for 1369 which a path computation is requested. The P flag of the END-POINT 1370 object MUST be set. If the END-POINT objet is received with the P 1371 flag cleared, the receiving peer MUST send a PCErr message with 1372 Error-type=10 and Error-value=1. The corresponding path computation 1373 request MUST be cancelled by the PCE without further notification. 1375 Note that the source and destination addresses specified in the END- 1376 POINTS object may or may not correspond to the source and destination 1377 IP address of the TE LSP but rather to a path segment. Two END- 1378 POINTS objects (for IPv4 and IPv6) are defined. 1380 END-POINTS Object-Class is to be assigned by IANA (recommended 1381 value=4). 1383 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 1384 for IPv4 and 2 for IPv6). 1386 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1387 as follows: 1389 0 1 2 3 1390 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 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Source IPv4 address | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Destination IPv4 address | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 Figure 12: END-POINTS Object Body Format for IPv4 1399 The format of the END-POINTS object for IPv6 (Object-Type=2) is as 1400 follows: 1402 0 1 2 3 1403 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 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | | 1406 | Source IPv6 address (16 bytes) | 1407 | | 1408 | | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | | 1411 | Destination IPv6 address (16 bytes) | 1412 | | 1413 | | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 Figure 13: END-POINTS Object Body Format for IPv6 1418 The END-POINTS object body has a fixed length of 8 bytes for IPv4 and 1419 32 bytes for IPv6. 1421 If more than one END-POINTS object is present, the first MUST be 1422 processed and subsequent objects ignored. 1424 7.7. BANDWIDTH Object 1426 The BANDWIDTH object is used to specify the requested bandwidth for a 1427 TE LSP. 1429 If the requested bandwidth is equal to 0, the BANDWIDTH object is 1430 optional. Conversely, if the requested bandwidth is non equal to 0, 1431 the PCReq message MUST contain a BANDWIDTH object. 1433 In the case of the reoptimization of a TE LSP, the bandwidth of the 1434 existing TE LSP MUST also be included in addition to the requested 1435 bandwidth if and only if the two values differ. Consequently, two 1436 Object-Type values are defined that refer to the requested bandwidth 1437 and the bandwidth of the TE LSP for which a reoptimization is being 1438 performed. 1440 The BANDWIDTH object may be carried within PCReq and PCRep messages. 1442 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1443 value=5) 1444 Two Object-Type values are defined for the BANDWIDTH object: 1446 o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by 1447 IANA (recommended value=1) 1449 o Bandwidth of an existing TE LSP for which a reoptimization is 1450 requested. BANDWIDTH Object-Type is to be assigned by IANA 1451 (recommended value=2) 1453 The format of the BANDWIDTH object body is as follows: 1455 0 1 2 3 1456 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 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | Bandwidth | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 Figure 14: BANDWIDTH Object Body Format 1463 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1464 IEEE floating point format, expressed in bytes per second. Refer to 1465 Section 3.1.2 of [RFC3471] for a table of commonly used values. 1467 The BANDWIDTH object body has a fixed length of 4 bytes. 1469 7.8. METRIC Object 1471 The METRIC object is optional and can be used for several purposes. 1473 In a PCReq message, a PCC MAY insert one of more METRIC objects: 1475 o To indicate the metric that MUST be optimized by the path 1476 computation algorithm (IGP metric, TE metric, Hop counts). 1477 Currently, three metrics are defined: the IGP cost, the TE metric 1478 (see [RFC3785]) and the number of hops traversed by a TE LSP. 1480 o To indicate a bound on the path cost that MUST NOT be exceeded for 1481 the path to be considered as acceptable by the PCC. 1483 In a PCRep message, the METRIC object MAY be inserted so as to 1484 provide the cost for the computed path. It MAY also be inserted 1485 within a PCRep with the NO-PATH object to indicate that the metric 1486 constraint could not be satisfied. 1488 The path computation algorithmic aspects used by the PCE to optimize 1489 a path with respect to a specific metric are outside the scope of 1490 this document. 1492 It must be understood that such path metrics are only meaningful if 1493 used consistently: for instance, if the delay of a computed path 1494 segment is exchanged between two PCEs residing in different domains, 1495 consistent ways of defining the delay must be used. 1497 The absence of the METRIC object MUST be interpreted by the PCE as a 1498 path computation request for which no constraints need be applied to 1499 any of the metrics. 1501 METRIC Object-Class is to be assigned by IANA (recommended value=6) 1503 METRIC Object-Type is to be assigned by IANA (recommended value=1) 1505 The format of the METRIC object body is as follows: 1507 0 1 2 3 1508 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 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 | Reserved | Flags |C|B| T | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 | metric-value | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 Figure 15: METRIC Object Body Format 1517 The METRIC object body has a fixed length of 8 bytes. 1519 Reserved (16 bits): This field MUST be set to zero on transmission 1520 and MUST be ignored on receipt. 1522 T (Type - 8 bits): Specifies the metric type. 1524 Three values are currently defined: 1526 o T=1: IGP metric 1528 o T=2: TE metric 1530 o T=3: Hop Counts 1532 Flags (8 bits): Two flags are currently defined: 1534 o B (Bound - 1 bit): When set in a PCReq message, the metric-value 1535 indicates a bound (a maximum) for the path metric that must not be 1536 exceeded for the PCC to consider the computed path as acceptable. 1537 The path metric must be less than or equal to the value specified 1538 in the Metric-value field. When the B flag is cleared, the 1539 metric-value field is not used to reflect a bound constraint. 1541 o C (Computed Metric - 1 bit): When set in a PCReq message, this 1542 indicates that the PCE MUST provide the computed path metric value 1543 (should a path satisfying the constraints be found) in the PCRep 1544 message for the corresponding metric. 1546 Unassigned flags MUST be set to zero on transmission and MUST be 1547 ignored on receipt. 1549 Metric-value (32 bits): metric value encoded in 32 bits in IEEE 1550 floating point format. 1552 Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 1553 message. There MUST be at most one instance of the METRIC object for 1554 each metric type with the same B flag value. If two or more 1555 instances of a METRIC object with the same B flag value are present 1556 for a metric type, only the first instance MUST be considered and 1557 other instances MUST be ignored. 1559 The presence of two METRIC objects of the same type with a different 1560 value of the B-Flag in a PCEReq message is allowed. Furthermore, it 1561 is also allowed to insert in a PCReq message two METRIC objects with 1562 the same type that have both their B-Flag cleared: in this case, an 1563 objective function must be used by the PCE to solve a multi-parameter 1564 constraint problem. 1566 A METRIC object used to indicate the metric to optimize during the 1567 path computation MUST have the B-Flag cleared and the C-Flag set to 1568 the appropriate value. When the path computation relates to the 1569 reoptimization of an exiting TE LSP (in which case R-Flag of the RP 1570 object is set) an implementation MAY decide to set the metric-value 1571 field to the computed value of the metric of the TE LSP to be 1572 reoptimized with regards to a specific metric type. 1574 A METRIC object used to reflect a bound MUST have the B-Flag set, the 1575 C-Flag and metric-value field set to the appropriate values. 1577 In a PCRep message, unless not allowed by PCE policy, at least one 1578 METRIC object MUST be present that reports the computed path metric 1579 if the C bit of the METRIC object was set in the corresponding path 1580 computation request (the B-flag MUST be cleared). The C-flag has no 1581 meaning in a PCRep message. Optionally the PCRep message MAY contain 1582 additional METRIC objects that correspond to bound constraints, in 1583 which case the metric-value MUST be equal to the corresponding 1584 computed path metric (the B-flag MUST be set). If no path satisfying 1585 the constraints could be found by the PCE, the METRIC objects MAY 1586 also be present in the PCRep message with the NO-PATH object to 1587 indicate the constraint metric that could be satisfied. 1589 Example: if a PCC sends a path computation request to a PCE where the 1590 metric to optimize is the IGP metric and the TE metric must not 1591 exceed the value of M, two METRIC object are inserted in the PCReq 1592 message: 1594 o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000 1596 o Second METRIC Object with B=1, T=2, metric-value=M 1598 If a path satisfying the set of constraints can be found by the PCE 1599 and there is no policy that prevents the return of the computed 1600 metric, the PCE inserts one METRIC object with B=0, T=1, metric- 1601 value= computed IGP path cost. Additionally, the PCE may insert a 1602 second METRIC object with B=1, T=2, metric-value= computed TE path 1603 cost. 1605 7.9. Explicit Route Object 1607 The ERO is used to encode the path of a TE LSP through the network. 1608 The ERO is carried within a PCRep message to provide the computed TE 1609 LSP should the path computation have been successful. 1611 The contents of this object are identical in encoding to the contents 1612 of the Resource Reservation Protocol Traffic Engineering Extensions 1613 (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473] 1614 and [RFC3477]. That is, the object is constructed from a series of 1615 sub-objects. Any RSVP-TE ERO sub-object already defined or that 1616 could be defined in the future for use in the RSVP-TE ERO is 1617 acceptable in this object. 1619 PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types. 1621 Since the explicit path is available for immediate signaling by the 1622 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1623 and fields in this object are identical to those defined for the ERO. 1625 ERO Object-Class is to be assigned by IANA (recommended value=7) 1627 ERO Object-Type is to be assigned by IANA (recommended value=1) 1629 7.10. Reported Route Object 1631 The RRO is exclusively carried within a PCReq message so as to report 1632 the route followed by a TE LSP for which a reoptimization is desired. 1634 The contents of this object are identical in encoding to the contents 1635 of the Route Record Object defined in [RFC3209], [RFC3473] and 1636 [RFC3477]. That is, the object is constructed from a series of sub- 1637 objects. Any RSVP-TE RRO sub-object already defined or that could be 1638 defined in the future for use in the RSVP-TE RRO is acceptable in 1639 this object. 1641 The meanings of all of the sub-objects and fields in this object are 1642 identical to those defined for the RSVP-TE RRO. 1644 PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types. 1646 RRO Object-Class is to be assigned by IANA (recommended value=8) 1648 RRO Object-Type is to be assigned by IANA (recommended value=1) 1650 7.11. LSPA Object 1652 The LSPA object is optional and specifies various TE LSP attributes 1653 to be taken into account by the PCE during path computation. The 1654 LSPA (LSP Attributes) object can be carried within a PCReq message, 1655 or a PCRep message in case of unsuccessful path computation (in this 1656 case, the PCRep message also contains a NO-PATH object and the LSPA 1657 object is used to indicate the set of constraints that could not be 1658 satisfied). Most of the fields of the LSPA object are identical to 1659 the fields of the SESSION-ATTRIBUTE (C-Type = 7) object defined in 1660 [RFC3209] and [RFC4090]. When absent from the PCReq message, this 1661 means that the Setup and Holding priorities are equal to 0, and there 1662 are no affinity constraints. 1664 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1666 LSPA Object-Types is to be assigned by IANA (recommended value=1) 1668 The format of the LSPA object body is: 1670 0 1 2 3 1671 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 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | Exclude-any | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Include-any | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Include-all | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | Setup Prio | Holding Prio | Flags |L| Reserved | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | | 1682 // Optional TLVs // 1683 | | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 Figure 16: LSPA Object Body Format 1688 Setup Prio (Setup Priority - 8 bits). The priority of the TE LSP 1689 with respect to taking resources, in the range of 0 to 7. The value 1690 0 is the highest priority. The Setup Priority is used in deciding 1691 whether this session can preempt another session. 1693 Holding Prio (Holding Priority - 8 bits). The priority of the TE LSP 1694 with respect to holding resources, in the range of 0 to 7. The value 1695 0 is the highest priority. Holding Priority is used in deciding 1696 whether this session can be preempted by another session. 1698 Flags (8 bits) 1700 The flag L corresponds to the "Local protection desired" bit 1701 ([RFC3209]) of the SESSION-ATTRIBUTE Object. 1703 L Flag (Local protection desired). When set, this means that the 1704 computed path must include links protected with Fast Reroute as 1705 defined in [RFC4090]. 1707 Unassigned flags MUST be set to zero on transmission and MUST be 1708 ignored on receipt. 1710 Reserved (8 bits): This field MUST be set to zero on transmission and 1711 MUST be ignored on receipt. 1713 Note that Optional TLVs may be defined in the future to carry 1714 additional TE LSP attributes such as those defined in [RFC4420]. 1716 7.12. Include Route Object Object 1718 The IRO (Include Route Object) is optional and can be used to specify 1719 that the computed path MUST traverse a set of specified network 1720 elements. The IRO MAY be carried within PCReq and PCRep messages. 1721 When carried within a PCRep message with the NO-PATH object, the IRO 1722 indicates the set of elements that cause de PCE to fail to find a 1723 path. 1725 IRO Object-Class is to be assigned by IANA (recommended value=10) 1727 IRO Object-Type is to be assigned by IANA (recommended value=1) 1729 0 1 2 3 1730 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 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | | 1733 // (Subobjects) // 1734 | | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 Figure 17: IRO Body Format 1739 Subobjects: The IRO is made of subobjects identical to the ones 1740 defined in [RFC3209], [RFC3473] and [RFC3477] where the IRO subobject 1741 type is identical to the subobject type defined in the related 1742 documents. 1744 The following subobject types are supported. 1746 Type Subobject 1747 1 IPv4 prefix 1748 2 IPv6 prefix 1749 4 Unnumbered Interface ID 1750 32 Autonomous system number 1752 The L bit of such sub-object has no meaning within an IRO. 1754 7.13. SVEC Object 1756 7.13.1. Notion of Dependent and Synchronized Path Computation Requests 1758 Independent versus dependent path computation requests: path 1759 computation requests are said to be independent if they are not 1760 related to each other. Conversely a set of dependent path 1761 computation requests is such that their computations cannot be 1762 performed independently of each other (a typical example of dependent 1763 requests is the computation of a set of diverse paths). 1765 Synchronized versus non-synchronized path computation requests: a set 1766 of path computation requests is said to be non-synchronized if their 1767 respective treatment (path computations) can be performed by a PCE in 1768 a serialized and independent fashion. 1770 There are various circumstances where the synchronization of a set of 1771 path computations may be beneficial or required. 1773 Consider the case of a set of N TE LSPs for which a PCC needs to send 1774 path computation requests to a PCE. The first solution consists of 1775 sending N separate PCReq messages to the selected PCE. In this case, 1776 the path computation requests are non-synchronized. Note that the 1777 PCC may chose to distribute the set of N requests across K PCEs for 1778 load balancing purposes. Considering that M (with M+-+-+-+-+-+-+ | | 3094 | | | KeepWait |----+ | 3095 | +--| |<---+ | 3096 |+-----+-+-+-+-+-+-+ | | 3097 || | | | 3098 || | | | 3099 || V | | 3100 || +->+-+-+-+-+-+-+----+ | 3101 || | | OpenWait |-------+ 3102 || +--| |<------+ 3103 ||+----+-+-+-+-+-+-+<---+ | 3104 ||| | | | 3105 ||| | | | 3106 ||| V | | 3107 ||| +->+-+-+-+-+-+-+ | | 3108 ||| | |TCPPending |----+ | 3109 ||| +--| | | 3110 |||+---+-+-+-+-+-+-+<---+ | 3111 |||| | | | 3112 |||| | | | 3113 |||| V | | 3114 |||+--->+-+-+-+-+ | | 3115 ||+---->| Idle |-------+ | 3116 |+----->| |----------+ 3117 +------>+-+-+-+-+ 3119 Figure 23: PCEP Finite State Machine for the PCC 3121 PCEP defines the following set of variables: 3123 Connect: timer (in seconds) started after having initialized a TCP 3124 connection using the PCEP well-known TCP port. The value of the 3125 TCPConnect timer is 60 seconds. 3127 ConnectRetry: specifies the number of times the system has tried to 3128 establish a TCP connection with a PCEP peer without success. 3130 ConnectMaxRetry: Maximum number of times the system tries to 3131 establish a TCP connection using the PCEP well-known TCP port before 3132 going back to the Idle state. The value of the ConnectMaxRetry is 5. 3134 OpenWait: timer that corresponds to the amount of time a PCEP peer 3135 will wait to receive an Open message from the PCEP peer after the 3136 expiration of which the system releases the PCEP resource and go back 3137 to the Idle state. The OpenWait timer has a fixed value of 60 3138 seconds. 3140 KeepWait: timer that corresponds to the amount of time a PCEP peer 3141 will wait to receive a KeepAlive or a PCErr message from the PCEP 3142 peer after the expiration of which the system releases the PCEP 3143 resource and go back to the Idle state. The KeepWait timer has a 3144 fixed value of 60 seconds. 3146 OpenRetry: specifies the number of times the system has received an 3147 Open message with unacceptable PCEP session characteristics. 3149 The following two states variable are defined: 3151 RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system 3152 has received an acceptable Open message. 3154 LocalOK: the LocalOK variable is a Boolean set to 1 if the system has 3155 received a Keepalive message acknowledging that the Open message sent 3156 to the peer was valid. 3158 Idle State: 3160 The idle state is the initial PCEP state where PCEP (also referred to 3161 as "the system") waits for an initialization event that can either be 3162 manually triggered by the user (configuration) or automatically 3163 triggered by various events. In Idle state, PCEP resources are 3164 allocated (memory, potential process, ...) but no PCEP messages are 3165 accepted from any PCEP peer. The system listens the well-known PCEP 3166 TCP port. 3168 The following set of variable are initialized: 3170 TCPRetry=0, 3172 LocalOK=0, 3174 RemoteOK=0, 3176 OpenRetry=0. 3178 Upon detection of a local initialization event (e.g. user 3179 configuration to establish a PCEP session with a particular PCEP 3180 peer, local event triggering the establishment of a PCEP session with 3181 a PCEP peer such as the automatic detection of a PCEP peer, ...), the 3182 system: 3184 o Initiates of a TCP connection with the PCEP peer, 3186 o Starts the Connect timer, 3188 o Moves to the TCPPending state. 3190 Upon receiving a TCP connection on the well-known PCEP TCP port, if 3191 the TCP connection establishment succeeds, the system: 3193 o Sends an Open message, 3195 o Starts the OpenWait timer, 3197 o Moves to the OpenWait state. 3199 If the connection establishment fails, the system remains in the Idle 3200 state. Any other event received in the Idle state is ignored. 3202 It is expected that an implementation will use an exponentially 3203 increasing timer between automatically generated Initialization 3204 events and between retries of TCP connection establishment. 3206 TCPPending State 3208 If the TCP connection establishment succeeds, the system: 3210 o Sends an Open message, 3212 o Starts the OpenWait timer, 3214 o Moves to the OpenWait state. 3216 If the TCP connection establishment fails (an error is detected 3217 during the TCP connection establishment) or the Connect timer 3218 expires: 3220 o If ConnectRetry =ConnectMaxRetry the system moves to the Idle 3221 State 3223 o If ConnectRetry < ConnectMaxRetry the system: 3225 1. Initiates of a TCP connection with the PCEP peer, 3226 2. Increments the ConnectRetry variable, 3228 3. Restarts the Connect timer, 3230 4. Stays in the TPCPending state. 3232 In response to any other event the system releases the PCEP resources 3233 for that peer and moves back to the Idle state. 3235 OpenWait State: 3237 In the OpenWait state, the system waits for an Open message from its 3238 PCEP peer. 3240 If the system receives an Open message from the PCEP peer before the 3241 expiration of the OpenWait timer, the system first examines all of 3242 its sessions that are in the OpenWait or KeepWait state. If another 3243 session with the same PCEP peer already exists (same IP address), 3244 then the system performs the following collision resolution 3245 procedure: 3247 o If the system has initiated the current session and it has a lower 3248 IP address than the PCEP Peer, the system closes the TCP 3249 connection, releases the PCEP resources for the pending session 3250 and moves back to the Idle state. 3252 o If the session was initiated by the PCEP peer and the system has a 3253 higher IP address that the PCEP Peer, the system closes the TCP 3254 connection, releases the PCEP resources for the pending session, 3255 and moves back to the Idle state. 3257 o Otherwise, the system checks the PCEP session attributes 3258 (Keepalive frequency, DeadTimer, ...). 3260 If an error is detected (e.g. malformed Open message, reception of a 3261 message that is not an Open message, presence of two Open objects, 3262 ...), PCEP generates an error notification, the PCEP peer sends a 3263 PCErr message with Error-Type=1 and Error-value=1. The system 3264 releases the PCEP resources for the PCEP peer, closes the TCP 3265 connection and moves to the Idle state. 3267 If no errors are detected, PCEP increments the OpenRetry variable. 3269 If no errors are detected, OpenRetry=1 and the session 3270 characteristics are unacceptable, the PCEP peer sends a PCErr with 3271 Error-Type=1 and Error-value=5, the system releases the PCEP 3272 resources for that peer and moves back to the Idle state. 3274 If no errors are detected, and the session characteristics are 3275 acceptable to the local system, the system: 3277 o Sends a Keepalive message to the PCEP peer, 3279 o Starts the Keepalive timer, 3281 o Sets the RemoteOK variable to 1. 3283 If LocalOK=1 the system clears the OpenWait timer and moves to the UP 3284 state. 3286 If LocalOK=0 the system clears the OpenWait timer, starts the 3287 KeepWait timer and moves to the KeepWait state. 3289 If no errors are detected, but the session characteristics are 3290 unacceptable and non-negotiable, the PCEP peer sends a PCErr with 3291 Error-Type=1 and Error-value=3, the system releases the PCEP 3292 resources for that peer, and moves back to the Idle state. 3294 If no errors are detected, and OpenRetry is 0, and the session 3295 characteristics are unacceptable but negotiable (such as, the 3296 Keepalive period or the DeadTimer), then the system: 3298 o Increments the OpenRetry variable, 3300 o Sends a PCErr message with Error-Type=1 and Error-value=4 that 3301 contains proposed acceptable session characteristics, 3303 o If LocalOK=1, the system restarts the OpenWait timer and stays in 3304 the OpenWait state 3306 o If LocalOK=0, the system clears the OpenWait timer, starts the 3307 KeepWait timer and moves to the KeepWait state 3309 If no Open message is received before the expiration of the OpenWait 3310 timer, the PCEP peer sends a PCErr message with Error-Type=1 and 3311 Error-value=2, the system releases the PCEP resources for the PCEP 3312 peer, closes the TCP connection and moves to the Idle state. 3314 In response to any other event the system releases the PCEP resources 3315 for that peer and moves back to the Idle state. 3317 KeepWait State 3319 In the Keepwait state, the system waits for the receipt of a 3320 Keepalive from its PCEP peer acknowledging its Open message or a 3321 PCErr message in response to unacceptable PCEP session 3322 characteristics proposed in the Open message. 3324 If an error is detected (e.g. malformed Keepalive message), PCEP 3325 generates an error notification, the PCEP peer sends a PCErr message 3326 with Error-Type=1 and Error-value=1. The system releases the PCEP 3327 resources for the PCEP peer, closes the TCP connection and moves to 3328 the Idle state. 3330 If a Keepalive message is received before the expiration of the 3331 KeepWait timer, then the system sets LocalOK=1 and: 3333 o If RemoteOK=1, the system clears the KeepWait timer and moves to 3334 the UP state. 3336 o If RemoteOK=0, the system clears the KeepWait timer, starts the 3337 OpenWait timer and moves to the OpenWait State. 3339 If a PCErr message is received before the expiration of the KeepWait 3340 timer: 3342 1. If the proposed values are unacceptable, the PCEP peer sends a 3343 PCErr message with Error-Type=1 and Error-value=6 and the system 3344 releases the PCEP resources for that PCEP peer, closes the TCP 3345 connection and moves to the Idle state. 3347 2. If the proposed values are acceptable, the system adjusts its 3348 PCEP session characteristics according to the proposed values 3349 received in the PCErr message restarts the KeepWait timer and 3350 sends a new Open message. If RemoteOK=1, the system restarts the 3351 KeepWait timer and stays in the KeepWait state. If RemoteOK=0, 3352 the system clears the KeepWait timer, start the OpenWait timer 3353 and moves to the OpenWait state. 3355 If neither a Keepalive nor a PCErr is received after the expiration 3356 of the KeepWait timer, the PCEP peer sends a PCErr message with 3357 Error-Type=1 and Error-value=7 and, system releases the PCEP 3358 resources for that PCEP peer, closes the TCP connection and moves to 3359 the Idle State. 3361 In response to any other event the system releases the PCEP resources 3362 for that peer and moves back to the Idle state. 3364 UP State 3366 In the UP state, the PCEP peer starts exchanging PCEP messages 3367 according to the session characteristics. 3369 If the Keepalive timer expires, the system restarts the Keepalive 3370 timer and sends a Keepalive message. 3372 If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from 3373 the PCEP peer before the expiration of the DeadTimer, the system 3374 terminates PCEP session according to the procedure defined in 3375 Section 6.8, releases the PCEP resources for that PCEP peer, closes 3376 the TCP connection and moves to the Idle State. 3378 If a malformed message is received, the system terminates the PCEP 3379 session according to the procedure defined in Section 6.8, releases 3380 the PCEP resources for that PCEP peer, closes the TCP connection and 3381 moves to the Idle State. 3383 If the system detects that the PCEP peer tries to setup a second TCP 3384 connection, it stops the TCP connection establishment and sends a 3385 PCErr with Error-Type=9. 3387 If the TCP connection fails, the system releases the PCEP resources 3388 for that PCEP peer, closes the TCP connection and moves to the Idle 3389 State. 3391 Appendix B. PCEP Variables 3393 PCEP defines the following configurable variables: 3395 KeepAlive timer: minimum period of time between the sending of PCEP 3396 messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A 3397 suggested value for the Keepalive timer is 30 seconds. 3399 DeadTimer: period of timer after the expiration of which a PCEP peer 3400 declared the session down if no PCEP message has been received. 3402 SyncTimer: the SYNC timer is used in the case of synchronized path 3403 computation request using the SVEC object defined in Section 7.13.3. 3404 Consider the case where a PCReq message is received by a PCE that 3405 contains the SVEC object referring to M synchronized path computation 3406 requests. If after the expiration of the SYNC timer all the M path 3407 computation requests have not been received, a protocol error is 3408 triggered and the PCE MUST cancel the whole set of path computation 3409 requests. A RECOMMENDED value for the SYNC timer is 60 seconds. 3411 Authors' Addresses 3413 JP Vasseur (editor) 3414 Cisco Systems 3415 1414 Massachusetts Avenue 3416 Boxborough, MA 01719 3417 USA 3419 Email: jpv@cisco.com 3421 JL Le Roux (editor) 3422 France Telecom 3423 2, Avenue Pierre-Marzin 3424 Lannion, 22307 3425 FRANCE 3427 Email: jeanlouis.leroux@orange-ftgroup.com 3429 Full Copyright Statement 3431 Copyright (C) The IETF Trust (2008). 3433 This document is subject to the rights, licenses and restrictions 3434 contained in BCP 78, and except as set forth therein, the authors 3435 retain all their rights. 3437 This document and the information contained herein are provided on an 3438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3439 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3440 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3441 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3442 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3445 Intellectual Property 3447 The IETF takes no position regarding the validity or scope of any 3448 Intellectual Property Rights or other rights that might be claimed to 3449 pertain to the implementation or use of the technology described in 3450 this document or the extent to which any license under such rights 3451 might or might not be available; nor does it represent that it has 3452 made any independent effort to identify any such rights. Information 3453 on the procedures with respect to rights in RFC documents can be 3454 found in BCP 78 and BCP 79. 3456 Copies of IPR disclosures made to the IETF Secretariat and any 3457 assurances of licenses to be made available, or the result of an 3458 attempt made to obtain a general license or permission for the use of 3459 such proprietary rights by implementers or users of this 3460 specification can be obtained from the IETF on-line IPR repository at 3461 http://www.ietf.org/ipr. 3463 The IETF invites any interested party to bring to its attention any 3464 copyrights, patents or patent applications, or other proprietary 3465 rights that may cover technology that may be required to implement 3466 this standard. Please address the information to the IETF at 3467 ietf-ipr@ietf.org. 3469 Acknowledgment 3471 Funding for the RFC Editor function is provided by the IETF 3472 Administrative Support Activity (IASA).