idnits 2.17.1 draft-ietf-pce-pcep-10.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 3319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3343. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 57 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 11, 2008) is 5919 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-15) exists of draft-ietf-pce-inter-layer-req-06 == Outdated reference: A later version (-06) exists of draft-ietf-pce-interas-pcecp-reqs-03 == Outdated reference: A later version (-11) exists of draft-ietf-pce-manageability-requirements-02 == Outdated reference: A later version (-09) exists of draft-ietf-pce-monitoring-01 == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-09 == Outdated reference: A later version (-02) exists of draft-kkoushik-pce-pcep-mib-01 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4420 (Obsoleted by RFC 5420) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems 3 Intended status: Standards Track JL. Le Roux, Ed. 4 Expires: August 14, 2008 France Telecom 5 February 11, 2008 7 Path Computation Element (PCE) Communication Protocol (PCEP) 8 draft-ietf-pce-pcep-10.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 14, 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) . . . . . . . . . . . 5 64 4.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Architectural Protocol Overview . . . . . . . . . . . . . 6 66 4.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 7 67 4.2.2. Path Computation Request Sent By a PCC to a PCE . . . 8 68 4.2.3. Path Computation Reply Sent By The PCE to a PCC . . . 9 69 4.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 11 70 4.2.5. Error . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 21 82 6.8. Close Message . . . . . . . . . . . . . . . . . . . . . . 22 83 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 22 84 7.1. PCE TLV Format . . . . . . . . . . . . . . . . . . . . . . 22 85 7.2. Common Object Header . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . 37 96 7.11. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 37 97 7.12. Include Route Object Object . . . . . . . . . . . . . . . 39 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 . . . . . . . . . . . . . . . . . . . 43 104 7.15. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 46 105 7.16. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 50 106 7.17. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 51 107 8. Manageability Considerations . . . . . . . . . . . . . . . . . 52 108 8.1. Control of Function and Policy . . . . . . . . . . . . . . 52 109 8.2. Information and Data Models . . . . . . . . . . . . . . . 54 110 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 54 111 8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 54 112 8.5. Requirements on Other Protocols and Functional 113 Components . . . . . . . . . . . . . . . . . . . . . . . . 55 114 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 55 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 116 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 55 117 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 55 118 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 56 119 9.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 57 120 9.5. Notification Object . . . . . . . . . . . . . . . . . . . 58 121 9.6. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 58 122 9.7. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 59 123 9.8. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 60 124 9.9. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 60 125 9.10. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 61 126 9.11. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 61 127 10. Security Considerations . . . . . . . . . . . . . . . . . . . 61 128 10.1. PCEP Authentication and Integrity . . . . . . . . . . . . 62 129 10.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 62 130 10.3. Protection Against Denial of Service Attacks . . . . . . . 62 131 10.3.1. Protection Against TCP DoS Attacks . . . . . . . . . . 62 132 10.3.2. Request Input Shaping/Policing . . . . . . . . . . . . 63 133 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 63 134 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 135 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 136 13.1. Normative References . . . . . . . . . . . . . . . . . . . 65 137 13.2. Informative References . . . . . . . . . . . . . . . . . . 65 138 Appendix A. PCEP Finite State Machine (FSM) . . . . . . . . . . . 67 139 Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 74 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74 141 Intellectual Property and Copyright Statements . . . . . . . . . . 76 143 1. Introduction 145 [RFC4655] describes the motivations and architecture for a Path 146 Compuation Element (PCE) based model for the computation of 147 Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic 148 Engineering Label Swtich Paths (TE LSPs). The model allows for the 149 separation of PCE from Path Computation Client (PCC), and allows for 150 the cooperation between PCEs. This necessitates a communication 151 protocol between PCC and PCE, and between PCEs. [RFC4657] states the 152 generic requirements for such a protocol including the requirement 153 for using the same protocol between PCC and PCE, and between PCEs. 154 Additional application-specific requirements (for scenarios such as 155 inter-area, inter-AS, etc.) are not included in [RFC4657], but there 156 is a requirement that any solution protocol must be easily extensible 157 to handle other requirements as they are introduced in application- 158 specific requirements documents. Examples of such application- 159 specific requirements are [RFC4927], 160 [I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req]. 162 This document specifies the Path Computation Element Communication 163 Protocol (PCEP) for communications between a PCC and a PCE, or 164 between two PCEs, in compliance with [RFC4657]. Such interactions 165 include path computation requests and path computation replies as 166 well as notifications of specific states related to the use of a PCE 167 in the context of MPLS and GMPLS Traffic Engineering. 169 PCEP is designed to be flexible and extensible so as to easily allow 170 for the addition of further messages and objects, should further 171 requirements be expressed in the future. 173 2. Terminology 175 Terminology used in this document 177 AS: Autonomous System. 179 Explicit path: Full explicit path from start to destination made of a 180 list of strict hops where a hop may be an abstract node such as an 181 AS. 183 IGP area: OSPF area or IS-IS level. 185 Inter-domain TE LSP: A TE LSP whose path transits at least two 186 different domains where a domain can be an IGP area, an Autonomous 187 System or a sub-AS (BGP confederations). 189 PCC: Path Computation Client: any client application requesting a 190 path computation to be performed by a Path Computation Element. 192 PCE: Path Computation Element: an entity (component, application or 193 network node) that is capable of computing a network path or route 194 based on a network graph and applying computational constraints. 196 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or a 197 PCE). 199 TED: Traffic Engineering Database that contains the topology and 200 resource information of the domain. The TED may be fed by IGP 201 extensions or potentially by other means. 203 TE LSP: Traffic Engineering Label Switched Path. 205 Strict/loose path: mix of strict and loose hops comprising at least 206 one loose hop representing the destination where a hop may be an 207 abstract node such as an AS. 209 Within this document, when describing PCE-PCE communications, the 210 requesting PCE fills the role of a PCC. This provides a saving in 211 documentation without loss of function. 213 3. Assumptions 215 [RFC4655] describes various types of PCE. PCEP does not make any 216 assumption and thus does not impose any constraint on the nature of 217 the PCE. 219 Moreover, it is assumed that the PCE has the required information 220 (usually including network topology and resource information) so as 221 to perform the computation of a path for a TE LSP. Such information 222 can be gathered by routing protocols or by some other means. The way 223 in which the information is gathered is out of the scope of this 224 document. 226 Similarly, no assumption is made about the discovery method used by a 227 PCC to discover a set of PCEs (e.g., via static configuration or 228 dynamic discovery) and on the algorithm used to select a PCE. For 229 reference, [RFC4674] defines a list of requirements for dynamic PCE 230 discovery and IGP-based solutions for such PCE discovery are 231 specified in [RFC5088] and [RFC5089]. 233 4. Architectural Protocol Overview (Model) 235 The aim of this section is to describe the PCEP model in the spirit 236 of [RFC4101]. An architecture protocol overview (the big picture of 237 the protocol) is provided in this section. Protocol details can be 238 found in further sections. 240 4.1. Problem 242 The PCE-based architecture used for the computation of path for MPLS 243 and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the 244 PCE are not collocated, a communication protocol between the PCC and 245 the PCE is needed. PCEP is such a protocol designed specifically for 246 communications between a PCC and a PCE or between two PCEs in 247 compliance with [RFC4657]: a PCC may use PCEP to send a path 248 computation request for one or more TE LSPs to a PCE and the PCE may 249 reply with a set of computed paths if one or more path(s) can be 250 found that satisfies the set of constraints. 252 4.2. Architectural Protocol Overview 254 PCEP operates over TCP, which fulfils the requirements for reliable 255 messaging and flow control without further protocol work. 257 Several PCEP messages are defined: 259 - Open and Keepalive messages are used to initiate and maintain a 260 PCEP session respectively. 262 - PCReq: a PCEP message sent by a PCC to a PCE to request a path 263 computation. 265 - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path 266 computation request. A PCRep message can either contain a set of 267 computed paths if the request can be satisfied, or a negative reply 268 if not. The negative reply may indicate the reason why no path could 269 be found. 271 - PCNtf: a PCEP notification message either sent by a PCC to a PCE or 272 a PCE to a PCC to notify of a specific event. 274 - PCErr: a PCEP message sent upon the occurrence of a protocol error 275 condition. 277 - Close message: a message used to close a PCEP session. 279 The set of available PCE(s) may be either statically configured on a 280 PCC or dynamically discovered. The mechanisms used to discover one 281 or more PCEs and to select a PCE are out of the scope of this 282 document. 284 A PCC may have PCEP sessions with more than one PCE and similarly a 285 PCE may have PCEP sessions with multiple PCCs. 287 4.2.1. Initialization Phase 289 The initialization phase consists of two successive steps (described 290 in a schematic form in Figure 1): 292 1) Establishment of a TCP connection (3-way handshake) between the 293 PCC and the PCE. 295 2) Establishment of a PCEP session over the TCP connection. 297 Once the TCP connection is established, the PCC and the PCE (also 298 referred to as "PCEP peers") initiate PCEP session establishment 299 during which various session parameters are negotiated. These 300 parameters are carried within Open messages and include the Keepalive 301 timer, the Deadtimer and potentially other detailed capabilities and 302 policy rules that specify the conditions under which path computation 303 requests may be sent to the PCE. If the PCEP session establishment 304 phase fails because the PCEP peers disagree on the session parameters 305 or one of the PCEP peers does not answer after the expiration of the 306 establishment timer, the TCP connection is immediately closed. 307 Successive retries are permitted but an implementation should make 308 use of an exponential back-off session establishment retry procedure. 310 Keepalive messages are used to acknowledge Open messages, and once 311 the PCEP session has been successfully established, Keepalive 312 messages may be exchanged between PCEP peers to ensure the liveness 313 of the PCEP session. 315 Only one PCEP session can exist between a pair a PCEP peers at any 316 one time. 318 Details about the Open message and the Keepalive message can be found 319 inSection 6.2 and Section 6.3 respectively. 321 +-+-+ +-+-+ 322 |PCC| |PCE| 323 +-+-+ +-+-+ 324 | | 325 | Open msg | 326 |-------- | 327 | \ Open msg | 328 | \ ---------| 329 | \/ | 330 | /\ | 331 | / -------->| 332 | / | 333 |<------ Keepalive| 334 | --------| 335 |Keeplaive / | 336 |-------- / | 337 | \/ | 338 | /\ | 339 |<------ ---------->| 340 | | 341 : : 342 : : 343 | | 344 |---- Keepalive ----->| 345 | | 346 |<--- Keepalive ------| 347 | | 349 Figure 1: PCEP Initialization phase (initiated by a PCC) 351 (Note that once the PCEP session is established, the exchange of 352 Keepalive messages is optional) 354 4.2.2. Path Computation Request Sent By a PCC to a PCE 355 +-+-+ +-+-+ 356 |PCC| |PCE| 357 +-+-+ +-+-+ 358 1)Path computation | | 359 event | | 360 2)PCE Selection | | 361 3)Path computation |---- PCReq message--->| 362 request sent to | | 363 the selected PCE | | 365 Figure 2: Path Computation request 367 Once a PCC has successfully established a PCEP session with one or 368 more PCEs, if an event is triggered that requires the computation of 369 a set of paths, the PCC first selects one or more PCE. Note that the 370 PCE selection decision process may have taken place prior to the PCEP 371 session establishment. 373 Once the PCC has selected a PCE, it sends the PCE a path computation 374 request to the PCE (PCReq message) that contains a variety of objects 375 that specify the set of constraints and attributes for the path to be 376 computed. For example "Compute a TE LSP path with source IP 377 address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B 378 Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may 379 desire to specify the urgency of such request by assigning a request 380 priority. Each request is uniquely identified by a request-id number 381 and the PCC-PCE address pair. The process is shown in a schematic 382 form in Figure 2. 384 Details about the PCReq message can be found in Section 6.4 386 4.2.3. Path Computation Reply Sent By The PCE to a PCC 387 +-+-+ +-+-+ 388 |PCC| |PCE| 389 +-+-+ +-+-+ 390 | | 391 |---- PCReq message--->| 392 | |1) Path computation 393 | |request received 394 | | 395 | |2)Path successfully 396 | |computed 397 | | 398 | |3) Computed path(s) 399 | |sent 400 | |to the PCC 401 |<--- PCRep message ---| 402 | (Positive reply) | 404 Figure 3a: Path Computation Request With Successful 405 Path Computation 407 +-+-+ +-+-+ 408 |PCC| |PCE| 409 +-+-+ +-+-+ 410 | | 411 | | 412 |---- PCReq message--->| 413 | |1) Path computation 414 | |request received 415 | | 416 | |2) No Path found that 417 | |satisfies the request 418 | | 419 | |3) Negative reply sent to 420 | |the PCC (optionally with 421 | |various additional 422 | |information) 423 |<--- PCRep message ---| 424 | (Negative reply) | 426 Figure 3b: Path Computation Request With Unsuccessful 427 Path Computation 429 Upon receiving a path computation request from a PCC, the PCE 430 triggers a path computation, the result of which can either be: 432 o Positive (Figure 3-a): the PCE manages to compute a path that 433 satisfies the set of required constraints, in which case the PCE 434 returns the set of computed paths to the requesting PCC. Note 435 that PCEP supports the capability to send a single request that 436 requires the computation of more than one path (e.g., computation 437 of a set of link-diverse paths). 439 o Negative (Figure 3-b): no path could be found that satisfies the 440 set of constraints. In this case, a PCE may provide the set of 441 constraints that led to the path computation failure. Upon 442 receiving a negative reply, a PCC may decide to resend a modified 443 request or take any other appropriate action. 445 Details about the PCRep message can be found in Section 6.5. 447 4.2.4. Notification 449 There are several circumstances in which a PCE may want to notify a 450 PCC of a specific event. For example, suppose that the PCE suddenly 451 gets overloaded, potentially leading to unacceptable response times. 452 The PCE may want to notify one or more PCCs that some of their 453 requests (listed in the notification) will not be satisfied or may 454 experience unacceptable delays. Upon receiving such notification, 455 the PCC may decide to redirect its path computation requests to 456 another PCE should an alternate PCE be available. Similarly, a PCC 457 may desire to notify a PCE of a particular event such as the 458 cancellation of pending requests. 460 +-+-+ +-+-+ 461 |PCC| |PCE| 462 +-+-+ +-+-+ 463 1)Path computation | | 464 event | | 465 2)PCE Selection | | 466 3)Path computation |---- PCReq message--->| 467 request X sent to | |4) Path computation 468 the selected PCE | |request queued 469 | | 470 | | 471 5) Path computation| | 472 request X cancelled| | 473 |---- PCNtf message -->| 474 | |6) Path computation 475 | |request X cancelled 477 Figure 4: Example of PCC Notification (Cancellation 478 Notification) 479 Sent To a PCE 481 +-+-+ +-+-+ 482 |PCC| |PCE| 483 +-+-+ +-+-+ 484 1)Path computation | | 485 event | | 486 2)PCE Selection | | 487 3)Path computation |---- PCReq message--->| 488 request X sent to | |4) Path computation 489 the selected PCE | |request queued 490 | | 491 | | 492 | |5) PCE gets overloaded 493 | | 494 | | 495 | |6) Path computation 496 | |request X cancelled 497 | | 498 |<--- PCNtf message----| 500 Figure 5: Example of PCE Notification (Cancellation 501 Notification) Sent To a PCC 503 Details about the PCNtf message can be found in Section 6.6. 505 4.2.5. Error 507 The PCEP Error message (also referred to as a PCErr message) is sent 508 in several situations: when a protocol error condition is met or when 509 the request is not compliant with the PCEP specification (e.g., 510 reception of a malformed message, reception of a message with a 511 mandatory missing object, policy violation, unexpected message, 512 unknown request reference, ...). 514 +-+-+ +-+-+ 515 |PCC| |PCE| 516 +-+-+ +-+-+ 517 1)Path computation | | 518 event | | 519 2)PCE Selection | | 520 3)Path computation |---- PCReq message--->| 521 request X sent to | |4) Reception of a 522 the selected PCE | |malformed object 523 | | 524 | |5) Request discarded 525 | | 526 |<-- PCErr message ---| 527 | | 529 Figure 6: Example of Error message Sent By a PCE To a PCC 530 In Reply To The Reception Of a Malformed Object 532 Details about the PCErr message can be found in Section 6.7. 534 4.2.6. Termination of the PCEP Session 536 When one of the PCEP peers desires to terminate a PCEP session it 537 first sends a PCEP Close message and then closes the TCP connection. 538 If the PCEP session is terminated by the PCE, the PCC clears all the 539 states related to pending requests previously sent to the PCE. 540 Similarly, if the PCC terminates a PCEP session the PCE clears all 541 pending path computation requests sent by the PCC in question as well 542 as the related states. A Close message can only be sent to terminate 543 a PCEP session if the PCEP session has previously been established. 545 In case of TCP connection failure, the PCEP session is immediately 546 terminated. 548 Details about the Close message can be found in Section 6.8. 550 4.2.7. Intermitent versus Permanent PCEP Session 552 An implementation may decide to keep the PCEP session alive (and thus 553 the corresponding TCP connection) for an unlimited time (this may for 554 instance be appropriate when path computation requests are sent on a 555 frequent basis so as to avoid to open a TCP connection each time a 556 path computation request is needed, which would incur additional 557 processing delays). Conversely, in some other circumstances, it may 558 be desirable to systematically open and close a PCEP session for each 559 PCEP request (for instance when sending a path computation request is 560 a rare event). 562 5. Transport Protocol 564 PCEP operates over TCP using a well-known TCP port (to be assigned by 565 IANA). This allows the requirements of reliable messaging and flow 566 control to be met without further protocol work. 568 6. PCEP Messages 570 A PCEP message consists of a common header followed by a variable 571 length body made of a set of objects that can either be mandatory or 572 optional. In the context of this document, an object is said to be 573 mandatory in a PCEP message when the object MUST be included for the 574 message to be considered as valid. A PCEP message with a missing 575 mandatory object MUST trigger an Error message (see Section 7.15). 576 Conversely, if an object is optional, the object may or may not be 577 present. 579 A flag referred to as the P flag is defined in the common header of 580 each PCEP object (see Section 7.2). When this flag is set in an 581 object in a PCReq, the PCE MUST take the information carried in the 582 object into account during the path computation. For example, the 583 METRIC object defined in Section 7.8 allows a PCC to specify a 584 bounded acceptable path cost. The METRIC object is optional, but a 585 PCC may set a flag to ensure that the constraint is taken into 586 account. In this case, if the constraint cannot be taken into 587 account by the PCE, the PCE MUST trigger an Error message. 589 For each PCEP message type, rules are defined that specify the set of 590 objects that the message can carry. We use the Backus-Naur Form 591 (BNF) (see [RFC4234]) to specify such rules. Square brackets refer 592 to optional sub-sequences. An implementation MUST form the PCEP 593 messages using the object ordering specified in this document. 595 6.1. Common header 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Ver | Flags | Message-Type | Message-Length | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Figure 7: PCEP Message Common Header 605 Ver (Version - 3 bits): PCEP version number. Current version is 606 version 1. 608 Flags (5 bits): no flags are currently defined. Unassigned bits are 609 considered as reserved and MUST be set to zero on transmission. 611 Message-Type (8 bits): 613 The following message types are currently defined (to be confirmed by 614 IANA). 615 Value Meaning 616 1 Open 617 2 Keepalive 618 3 Path Computation Request 619 4 Path Computation Reply 620 5 Notification 621 6 Error 622 7 Close 624 Message-Length (16 bits): total length of the PCEP message expressed 625 in bytes including the common header. 627 6.2. Open Message 629 The Open message is a PCEP message sent by a PCC to a PCE and a PCE 630 to a PCC in order to establish a PCEP session. The Message-Type 631 field of the PCEP common header for the Open message is set to 1 (To 632 be confirmed by IANA). 634 Once the TCP connection has been successfully established, the first 635 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 636 an Open message as specified in Appendix A. Any message received 637 prior to an Open message MUST trigger a protocol error condition and 638 the PCEP session MUST be terminated. The Open message is used to 639 establish a PCEP session between the PCEP peers. During the 640 establishment phase the PCEP peers exchange several session 641 characteristics. If both parties agree on such characteristics the 642 PCEP session is successfully established. TOTO 643 Open message 644 ::= 645 646 The Open message MUST contain exactly one OPEN object (see 647 Section 7.3). 649 Various session characteristics are specified within the OPEN object. 650 Once the TCP connection has been successfully established the sender 651 MUST start an initialization timer called OpenWait after the 652 expiration of which if no Open message has been received it sends a 653 PCErr message and releases the TCP connection (see Appendix A for 654 details). 656 Once an Open message has been sent to a PCEP peer, the sender MUST 657 start an initialization timer called KeepWait after the expiration of 658 which if neither a KeepAlive message has been received nor a PCErr 659 message in case of disagreement of the session characteristics, a 660 PCErr message MUST be sent and the TCP connection MUST be released 661 (see Appendix A for details). 663 The KeepWait timer has a fixed value of 1 minute. 665 Upon the receipt of an Open message, the receiving PCEP peer MUST 666 determine whether the suggested PCEP session characteristics are 667 acceptable. If at least one of the characteristic(s) is not 668 acceptable by the receiving peer, it MUST send an Error message. The 669 Error message SHOULD also contain the related Open object: for each 670 unacceptable session parameter, an acceptable parameter value SHOULD 671 be proposed in the appropriate field of the Open object in place of 672 the originally proposed value. The PCEP peer MAY decide to resend an 673 Open message with different session characteristics. If a second 674 Open message is received with the same set of parameters or with 675 parameters that are still unacceptable, the receiving peer MUST send 676 an Error message and it MUST immediately close the TCP connection. 677 Details about error message can be found in Section 7.15. 679 If the PCEP session characteristics are acceptable, the receiving 680 PCEP peer MUST send a Keepalive message (defined in Section 6.3) that 681 serves as an acknowledgment. 683 The PCEP session is considered as established once both PCEP peers 684 have received a Keepalive message from their peer. 686 6.3. Keepalive Message 688 A Keepalive message is a PCEP message sent by a PCC or a PCE in order 689 to keep the session in active state. The Keepalive message is also 690 used in response to an Open message to acknowledge that an Open 691 message has been received and that the PCEP session characteristics 692 are acceptable. The Message-Type field of the PCEP common header for 693 the Keepalive message is set to 2 (To be confirmed by IANA). The 694 Keepalive message does not contain any object. 696 PCEP has its own keepalive mechanism used to ensure of the liveness 697 of the PCEP session. This requires the determination of the 698 frequency at which each PCEP peer sends Keepalive messages. 699 Asymmetric values may be chosen; thus there is no constraint 700 mandating the use of identical keepalive frequencies by both PCEP 701 peers. The DeadTimer is defined as the period of time after the 702 expiration of which a PCEP peer declares the session down if no PCEP 703 message has been received (Keepalive or any other PCEP message: thus, 704 any PCEP message acts as a Keepalive message). Similarly, there is 705 no constraints mandating the use of identical DeadTimers by both PCEP 706 peers. The minimum KeepAlive timer value is 1 second. 708 Keepalive messages are sent at the frequency specified in the OPEN 709 object carried within an Open message according to the rules 710 speciifed in Section 7.3. Because any PCEP message may serve as 711 Keepalive, an implementation may either decide to send Keepalive 712 messages at fixed intervals regardless on whether other PCEP messages 713 might have been sent since the last sent Keepalive message, or may 714 decide to differ the sending of the next Keepalive message based on 715 the time at which the last PCEP message (other than Keepalive) was 716 sent. 718 Note that sending Keepalive messages to keep the session alive is 719 optional and PCEP peers may decide to not send Keepalive messages 720 once the PCEP session is established in which case the peer that does 721 not receive Keepalive messages does not expect to receive them and 722 MUST NOT declare the session as inactive. 724 Keepalive message 725 ::= 727 6.4. Path Computation Request (PCReq) Message 729 A Path Computation Request message (also referred to as a PCReq 730 message) is a PCEP message sent by a PCC to a PCE to request a path 731 computation. A PCReq message may carry more than one path 732 computation request. The Message-Type field of the PCEP common 733 header for the PCReq message is set to 3 (To be confirmed by IANA). 735 There are two mandatory objects that MUST be included within a PCReq 736 message: the RP and the END-POINTS objects (see section Section 7). 737 If one or both of these objects is missing, the receiving PCE MUST 738 send an error message to the requesting PCC. Other objects are 739 optional. 741 The format of a PCReq message is as follows: 742 ::= 743 [] 744 746 where: 747 ::=[] 748 ::=[] 750 ::= 751 752 [] 753 [] 754 [] 755 [[]] 756 [] 757 [] 758 where: 760 ::=[] 762 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 763 BALANCING objects are defined in Section 7. The special case of two 764 BANDWIDTH objects is discussed in detail in Section 7.7. 766 6.5. Path Computation Reply (PCRep) Message 768 The PCEP Path Computation Reply message (also referred to as a PCRep 769 message) is a PCEP message sent by a PCE to a requesting PCC in 770 response to a previously received PCReq message. The Message-Type 771 field of the PCEP common header is set to 4 (To be confirmed by 772 IANA). 774 The bundling of multiple replies to a set of path computation 775 requests within a single PCRep message is supported by PCEP. If a 776 PCE receives non-synchronized path computation requests by means of 777 one or more PCReq messages from a requesting PCC it MAY decide to 778 bundle the computed paths within a single PCRep message so as to 779 reduce the control plane load. Note that the counter side of such an 780 approach is the introduction of additional delays for some path 781 computation requests of the set. Conversely, a PCE that receives 782 multiple requests within the same PCReq message MAY decide to provide 783 each computed path in separate PCRep messages or within the same 784 PCRep message. A PCRep message may contain positive and negative 785 replies. 787 A PCRep message may contain a set of computed path(s) corresponding 788 to either a single path computation request with load-balancing (see 789 Section 7.16) or multiple path computation requests originated by a 790 requesting PCC. The PCRep message may also contain multiple 791 acceptable paths corresponding to the same request. 793 The PCRep message MUST contain at least one RP object. For each 794 reply that is bundled into a single PCReq message, an RP object MUST 795 be included that contains a Request-ID-number identical to the one 796 specified in the RP object carried in the corresponding PCReq message 797 (see Section 7.4 for the definition of the RP object). 799 If the path computation request can be satisfied (the PCE finds a set 800 of paths that satisfy the set of constraints), the set of computed 801 paths specified by means of ERO objects is inserted in the PCRep 802 message. The ERO is defined in Section 7.9. The situation where 803 multiple computed paths are provided in a PCRep message is discussed 804 in detail in Section 7.13. Furthermore, when a PCC requests the 805 computation of a set of paths for a total amount of bandwidth by 806 means of a LOAD-BALANCING object carried within a PCReq message, the 807 ERO of each computed path may be followed by a BANDWIDTH object as 808 discussed in section Section 7.16. 810 If the path computation request cannot be satisfied, the PCRep 811 message MUST include a NO-PATH object. The NO-PATH object (described 812 in Section 7.5) may also contain other information (e.g, reasons for 813 the path computation failure). 815 The format of a PCRep message is as follows: 816 ::= 817 819 where: 820 ::=[] 822 ::= 823 [] 824 [] 825 [] 827 ::=[] 829 ::= 831 where: 833 ::=[] 834 [] 835 [] 836 [] 838 ::=[] 840 6.6. Notification (PCNtf) Message 842 The PCEP Notification message (also referred to as the PCNtf message) 843 can be sent either by a PCE to a PCC, or by a PCC to a PCE, to notify 844 of a specific event. The Message-Type field of the PCEP common 845 header is set to 5 (To be confirmed by IANA). 847 The PCNtf message MUST carry at least one NOTIFICATION object and MAY 848 contain several NOTIFICATION objects should the PCE or the PCC intend 849 to notify of multiple events. The NOTIFICATION object is defined in 850 Section 7.14. The PCNtf message MAY also contain RP objects (see 851 Section 7.4 when the notification refers to particular path 852 computation requests. 854 The PCNtf message may be sent by a PCC or a PCE in response to a 855 request or in an unsolicited manner. 857 The format of a PCNtf message is as follows: 858 ::= 859 861 ::= [] 863 ::= [] 864 866 ::= 868 ::= 870 6.7. Error (PCErr) Message 872 The PCEP Error message (also referred to as a PCErr message) is sent 873 in several situations: when a protocol error condition is met or when 874 the request is not compliant with the PCEP specification (e.g., 875 reception of a malformed message, reception of a message with a 876 mandatory missing object, policy violation, unexpected message, 877 unknown request reference, ...). The Message-Type field of the PCEP 878 common header is set to 6 (To be confirmed by IANA). 880 The PCErr message is sent by a PCC or a PCE in response to a request 881 or in an unsolicited manner. If the PCErr message is sent in 882 response to a request, the PCErr message MUST include the set of RP 883 objects related to the pending path computation requests that 884 triggered the error condition. In the later case (unsolicited), no 885 RP object is inserted in the PCErr message. For example, no RP 886 object is inserted in a PCErr when the error condition occurred 887 during the initialization phase. A PCErr message MUST contain a 888 PCEP-ERROR object specifying the PCEP error condition. The PCEP- 889 ERROR object is defined in section Section 7.15. 891 The format of a PCErr message is as follows: 892 ::= 893 ( [] ) | 894 [] 896 ::=[] 897 ::=[] 898 899 ::=[] 900 ::=[] 902 The procedure upon the receipt of a PCErr message is defined in 903 Section 7.15. 905 6.8. Close Message 907 The Close message is a PCEP message that is either sent by a PCC to a 908 PCE or by a PCE to a PCC in order to close an established PCEP 909 session. The Message-Type field of the PCEP common header for the 910 Close message is set to 7 (To be confirmed by IANA). 912 Close message 913 ::= 914 916 The Close message MUST contain exactly one CLOSE object (see 917 Section 6.8). If more than one CLOSE object is present, the first 918 MUST be processed and subsequent objects ignored. 920 Upon the receipt of a vlaid Close message, the receiving PCEP peer 921 MUST cancel all pending requests, it MUST close the TCP connection 922 and MUST NOT send any further PCEP messages on the PCEP session. 924 7. Object Formats 926 PCEP objects have a common format. They begin with a common object 927 header (see Section 7.2). This is followed by object-specific fields 928 defined for each different object. The object may also include one 929 or more type-length-value (TLV) encoded data sets. Each TLV has the 930 same structure as described in Section 7.1. 932 7.1. PCE TLV Format 934 A PCEP object may include a set of one or more optional TLVs. 936 All PCEP TLVs have the following format: 938 Type: 2 bytes 939 Length: 2 bytes 940 Value: variable 941 A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes 942 specifying the TLV length, and a value field. 944 The Length field defines the length of the value portion in bytes. 945 The TLV is padded to 4-bytes alignment; padding is not included in 946 the Length field (so a three byte value would have a length of three, 947 but the total size of the TLV would be eight bytes). 949 Unrecognized TLVs MUST be ignored. 951 IANA management of the PCEP Object TLV type identifier codespace is 952 described in Section 9. 954 7.2. Common Object Header 956 A PCEP object carried within a PCEP message consists of one or more 957 32-bit words with a common header which has the following format: 958 0 1 2 3 959 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 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Object-Class | OT |Res|P|I| Object Length (bytes) | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | | 964 // (Object body) // 965 | | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 Figure 8: PCEP common object header 970 Object-Class (8 bits): identifies the PCEP object class. 972 OT (Object-Type - 4 bits): identifies the PCEP object type. 974 The Object-Class and Object-Type fields are managed by IANA. 976 The Object-Class and Object-Type fields uniquely identify each PCEP 977 object. 979 Res flags (2 bits). Reserved field. This field MUST be set to zero 980 on transmission and MUST be ignored on receipt. Unassigned bits are 981 considered as reserved. They MUST be set to zero on transmission and 982 MUST be ignored on receipt. 984 o P flag (Processing-Rule - 1-bit): the P flag allows a PCC to 985 specify in a PCReq message sent to a PCE whether the object must 986 be taken into account by the PCE during path computation or is 987 just optional. When the P flag is set, the object MUST be taken 988 into account by the PCE. Conversely, when the P flag is cleared, 989 the object is optional and the PCE is free to ignore it. 991 o I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 992 message to indicate to a PCC whether or not an optional object was 993 processed. The PCE MAY include the ignored optional object in its 994 reply and set the I flag to indicate that the optional object was 995 ignored during path computation. When the I flag is cleared, the 996 PCE indicates that the optional object was processed during the 997 path computation. The setting of the I flag for optional objects 998 is purely indicative and optional. The I flag has no meaning in a 999 PCRep message when the P flag has been set in the corresponding 1000 PCReq message. 1002 If the PCE does not understand an object with the P flag set or 1003 understands the object but decides to ignore the object, the entire 1004 PCEP message MUST be rejected and the PCE MUST send a PCErr message 1005 with Error-Type="Unknown Object" or "Not supported Object" along with 1006 the corresponding RP object. Note that if a PCReq includes multiple 1007 requests, only requests for which an object with the P flag set is 1008 unknown/unrecognized MUST be rejected. 1010 Object Length (16 bits). Specifies the total object length including 1011 the header, in bytes. The Object Length field MUST always be a 1012 multiple of 4, and at least 4. The maximum object content length is 1013 65528 bytes. 1015 7.3. OPEN Object 1017 The OPEN object MUST be present in each Open message and MAY be 1018 present in a PCErr message. There MUST be only one OPEN object per 1019 Open or PCErr message. 1021 The OPEN object contains a set of fields used to specify the PCEP 1022 version, Keepalive frequency, DeadTimer, PCEP session ID along with 1023 various flags. The OPEN object may also contain a set of TLVs used 1024 to convey various session characteristics such as the detailed PCE 1025 capabilities, policy rules and so on. No TLVs are currently defined. 1027 OPEN Object-Class is to be assigned by IANA (recommended value=1) 1029 OPEN Object-Type is to be assigned by IANA (recommended value=1) 1031 The format of the OPEN object body is as follows: 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Ver | Flags | Keepalive | DeadTimer | SID | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | | 1039 // Optional TLV(s) // 1040 | | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 Figure 9: OPEN Object format 1045 Ver (3 bits): PCEP version. Current version is 1. 1047 Flags (5 bits): No Flags are currently defined. Unassigned bits are 1048 considered as reserved and MUST be set to zero on transmission. 1050 Keepalive (8 bits): maximum period of time (in seconds) between two 1051 consecutive PCEP messages sent by the sender of this message. The 1052 minimum value for the Keepalive is 1 second. When set to 0, once the 1053 session is established, no further Keepalive messages are sent to the 1054 remote peer. A RECOMMENDED value for the keepalive frequency is 30 1055 seconds. 1057 DeadTimer (8 bits): specifies the amount of time after the expiration 1058 of which the PCEP peer can declare the session with the sender of the 1059 Open message down if no PCEP message has been received. The 1060 DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is 1061 set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value 1062 of the Keepalive. 1064 Example: 1066 A sends an Open message to B with Keepalive=10 seconds and 1067 Deadtimer=30 seconds. This means that A sends Keepalive messages (or 1068 ay other PCEP message) to B every 10 seconds and B can declare the 1069 PCEP session with A down if no PCEP message has been received from A 1070 within any 30 second period. 1072 SID (PCEP session-ID - 8 bits): unsigned PCEP session number that 1073 identifies the current session. The SID MUST be incremented each 1074 time a new PCEP session is established and is used for logging and 1075 troubleshooting purposes. There is one SID number in each direction. 1077 Optional TLVs may be included within the OPEN object body to specify 1078 PCC or PCE characteristics. The specification of such TLVs is 1079 outside the scope of this document. 1081 When present in an Open message, the OPEN object specifies the 1082 proposed PCEP session characteristics. Upon receiving unacceptable 1083 PCEP session characteristics during the PCEP session initialization 1084 phase, the receiving PCEP peer (PCE) MAY include an OPEN object 1085 within the PCErr message so as to propose alternative acceptable 1086 session characteristic values. 1088 7.4. RP Object 1090 The RP (Request Parameters) object MUST be carried within each PCReq 1091 and PCRep messages and MAY be carried within PCNtf and PCErr 1092 messages. The RP object is used to specify various characteristics 1093 of the path computation request. 1095 The P flag of the RP object MUST be set in PCReq and PCReq messages 1096 and MUST be cleared in PCNtf and PCErr messages. If the RP objet is 1097 received with the P flag set incorrectely according to the rules 1098 states above, the receiving peer MUST send a PCErr message with 1099 Error-type=10 and Error-value=1. The corresponding path computation 1100 request MUST be cancelled by the PCE without further notification. 1102 7.4.1. Object Definition 1104 RP Object-Class is to be assigned by IANA (recommended value=2) 1106 RP Object-Type is to be assigned by IANA (recommended value=1) 1108 The format of the RP object body is as follows: 1110 0 1 2 3 1111 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 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Flags |O|B|R| Pri | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Request-ID-number | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | | 1118 // Optional TLV(s) // 1119 | | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 Figure 10: RP object body format 1124 The RP object body has a variable length and may contain additional 1125 TLVs. No TLVs are currently defined. 1127 Flags (24 bits) 1129 The following flags are currently defined: 1131 o Pri (Priority - 3 bits): the Priority field may be used by the 1132 requesting PCC to specify to the PCE the request's priority from 1 1133 to 7. The decision of which priority should be used for a 1134 specific request is of a local matter and MUST be set to 0 when 1135 unused. Furthermore, the use of the path computation request 1136 priority by the PCE's scheduler is implementation specific and out 1137 of the scope of this document. Note that it is not required for a 1138 PCE to support the priority field: in this case, it is RECOMMENDED 1139 that the PCC set the priority field to 0 in the RP object. If the 1140 PCE does not take into account the request priority, it is 1141 RECOMMENDED to set the priority field to 0 in the RP object 1142 carried within the corresponding PCRep message, regardless of the 1143 priority value contained in the RP object carried within the 1144 corresponding PCReq message. A higher numerical value of the 1145 priority field reflects a higher priority. Note that it is the 1146 responsibility of the network administrator to make use of the 1147 priority values in a consistent manner across the various PCCs. 1148 The ability of a PCE to support request prioritization MAY be 1149 dynamically discovered by the PCCs by means of PCE capability 1150 discovery. If not advertised by the PCE, a PCC may decide to set 1151 the request priority and will learn the ability of the PCE to 1152 support request prioritization by observing the Priority field of 1153 the RP object received in the PCRep message. If the value of the 1154 Pri field is set to 0, this means that the PCE does not support 1155 the handling of request priorities: in other words, the path 1156 computation request has been honoured but without taking the 1157 request priority into account. 1159 o R (Reoptimization - 1 bit): when set, the requesting PCC specifies 1160 that the PCReq message relates to the reoptimization of an 1161 existing TE LSP in which case, in addition to the TE LSP 1162 attributes, the current path of the existing TE LSP to be 1163 reoptimized MUST be provided in the PCReq (except for 0-bandwidth 1164 TE LSPs) message by means of an RRO object defined in Section 7.10 1165 and (again except in the case of 0-bandwidth TE LSPs) the existing 1166 bandwidth of the LSP to be reoptimized MUST be supplied in an 1167 additional BANDWIDTH object as described in Section 7.7. 1169 o B (Bi-directional - 1 bit): when set, the PCC specifies that the 1170 path computation request relates to a bidirectional TE LSP that 1171 has the same traffic engineering requirements including fate 1172 sharing, protection and restoration, LSRs, TE Links, and resource 1173 requirements (e.g., latency and jitter) in each direction. When 1174 cleared, the TE LSP is unidirectional. 1176 o O (strict/loose - 1 bit): when set, in a PCReq message, this 1177 indicates that a loose path is acceptable. Otherwise, when 1178 cleared, this indicates to the PCE that a path exclusively made of 1179 strict hops is required. In a PCRep message, when the O bit is 1180 set this indicates that the returned path is a loose path, 1181 otherwise (the O bit is cleared), the returned path is made of 1182 strict hops. 1184 Unassigned bits are considered as reserved and MUST be set to zero on 1185 transmission. 1187 Request-ID-number (32 bits). The Request-ID-number value combined 1188 with the source IP address of the PCC and the PCE address uniquely 1189 identify the path computation request context. The Request-ID-number 1190 MUST be incremented each time a new request is sent to the PCE. The 1191 value 0x0000000 is considered as invalid. If no path computation 1192 reply is received from the PCE, and the PCC wishes to resend its 1193 request, the same Request-ID-number MUST be used. Conversely, 1194 different Request-ID-number MUST be used for different requests sent 1195 to a PCE. The same Request-ID-number MAY be used for path 1196 computation requests sent to different PCEs. The path computation 1197 reply is unambiguously identified by the IP source address of the 1198 replying PCE. 1200 7.4.2. Handling of the RP Object 1202 If a PCReq message is received that does not contain an RP object, 1203 the PCE MUST send a PCErr message to the requesting PCC with Error- 1204 type="Required Object missing" and Error-value="RP Object missing". 1206 If the O bit of the RP message carried within a PCReq message is 1207 cleared and local policy has been configured on the PCE to not 1208 provide explicit paths (for instance, for confidentiality reasons), a 1209 PCErr message MUST be sent by the PCE to the requesting PCC and the 1210 pending path computation request MUST be discarded. The Error-type 1211 is "Policy Violation" and Error-value is "O bit cleared". 1213 R bit: when the R bit of the RP object is set in a PCReq message, 1214 this indicates that the path computation request relates to the 1215 reoptimization of an existing TE LSP. In this case, the PCC MUST 1216 also provide the strict/loose path by including an RRO object in the 1217 PCReq message so as to avoid/limit double bandwidth counting if and 1218 only if the TE LSP is a non-0-bandwidth TE LSP. If the PCC has not 1219 requested a strict path (O bit set), a reoptimization can still be 1220 requested by the PCC but this requires that the PCE either be 1221 stateful (keep track of the previously computed path with the 1222 associated list of strict hops), or have the ability to retrieve the 1223 complete required path segment. Alternatively the PCC MUST inform 1224 the PCE of the working path with the associated list of strict hops 1225 in PCReq. The absence of an RRO in the PCReq message for a non-0- 1226 bandwidth TE LSP when the R bit of the RP object is set MUST trigger 1227 the sending of a PCErr message with Error-type="Required Object 1228 Missing" and Error-value="RRO Object missing for reoptimization". 1230 If the PCC receives a PCRep message that contains a RP object 1231 referring to an unknown Request-ID-Number, the PCC MUST send a PCErr 1232 message with Error-Type="Unknown request reference". 1234 7.5. NO-PATH Object 1236 The NO-PATH object is used in PCRep messages in response to an 1237 unsuccessful path computation request (the PCE could not find a path 1238 satisfying the set of constraints). When a PCE cannot find a path 1239 satisfying a set of constraints, it MUST include a NO-PATH object in 1240 the PCRep message. 1242 There are several categories of issue that can lead to a negative 1243 reply. For example, the PCE chain might be broken (should there be 1244 more than one PCE involved in the path computation) or no path 1245 obeying the set constraints could be found. The "NI (Nature of 1246 Issue)" field in the NO-PATH object is used to report the error 1247 category. 1249 Optionally, if the PCE supports such capability, the NO-PATH object 1250 MAY contain an optional NO-PATH-VECTOR TLV defined below and used to 1251 provide more information on the reasons that led to a negative reply. 1252 The PCRep message MAY also contain a list of objects that specify the 1253 set of constraints that could not be satisfied. The PCE MAY just 1254 replicate the set of objects that was received that was the cause of 1255 the unsuccessful computation or MAY optionally report a suggested 1256 value for which a path could have been found (in which case the value 1257 differs from the value in the original request). 1259 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1261 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1263 The format of the NO-PATH object body is as follows: 1265 0 1 2 3 1266 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 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 |Nature Of Issue|C| Flags | Reserved | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | | 1271 // Optional TLV(s) // 1272 | | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Figure 11: NO-PATH Object Format 1277 NI - Nature Of Issue (8 bits): the NI field is used to report the 1278 nature of the issue that led to a negative reply. Two values are 1279 currently defined: 1281 0x00: No path satisfying the set of constraints could be found 1283 0x01: PCE chain broken 1285 IANA management of the NI field codespace is described in Section 9. 1287 Flags (16 bits). 1289 The following flag is currently defined: 1291 C flag (1 bit): when set, the PCE indicates the set of unsatisfied 1292 constraints (reasons why a path could not be found) in the PCRep 1293 message by including the relevant PCEP objects. When cleared, no 1294 failing constraints are specified. The C flag has no meaning and is 1295 ignored unless the NI field is set to 0x00. 1297 Reserved (8 bits): This field MUST be set to zero on transmission and 1298 MUST be ignored on receipt. 1300 The NO-PATH object body has a variable length and may contain 1301 additional TLVs. The only TLV currently defined is the NO-PATH- 1302 VECTOR TLV defined below. 1304 Example: consider the case of a PCC that sends a path computation 1305 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1306 find a path for X MBits/s. In this case, the PCE must include in the 1307 PCRep message a NO-PATH object. Optionally the PCE may also include 1308 the original BANDWIDTH object so as to indicate that the reason for 1309 the unsuccessful computation is the bandwidth constraint (in this 1310 case, the NI field value is 0x00 and C flag is set). If the PCE 1311 supports such capability it may alternatively include the BANDWIDTH 1312 Object and report a value of Y in the bandwidth field of the 1313 BANDWIDTH object (in this case, the C flag is set) where Y refers to 1314 the bandwidth for which a TE LSP with the same other characteristics 1315 could have been computed. 1317 When the NO-PATH object is absent from a PCRep message, the path 1318 computation request has been fully satisfied and the corresponding 1319 paths are provided in the PCRep message. 1321 An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH 1322 object in order to provide more information on the reasons that led 1323 to a negative reply. 1325 The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in 1326 section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying 1327 the TLV length (length of the value portion in bytes) followed by a fixed 1328 length value field of 32-bit flags field. 1330 TYPE: To be assigned by IANA (suggested value=1) 1331 LENGTH: 1 1332 VALUE: 32-bit flags field 1334 IANA is requested to manage the space of flags carried in the NO- 1335 PATH-VECTOR TLV (see Section 9). 1337 The following flags are currently defined: 1339 o Bit number: 1 - PCE currently unavailable 1341 o Bit number: 2 - Unknown destination 1343 o Bit number: 3 - Unknown source 1345 7.6. END-POINT Object 1347 The END-POINTS object is used in a PCReq message to specify the 1348 source IP address and the destination IP address of the path for 1349 which a path computation is requested. The P flag of the END-POINT 1350 object MUST be set. If the END-POINT objet is received with the P 1351 flag cleared, the receiving peer MUST send a PCErr message with 1352 Error-type=10 and Error-value=1. The corresponding path computation 1353 request MUST be cancelled by the PCE without further notification. 1355 Note that the source and destination addresses specified in the END- 1356 POINTS object may or may not correspond to the source and destination 1357 IP address of the TE LSP but rather to a path segment. Two END- 1358 POINTS objects (for IPv4 and IPv6) are defined. 1360 END-POINTS Object-Class is to be assigned by IANA (recommended 1361 value=4) 1363 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 1364 for IPv4 and 2 for IPv6) 1365 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1366 as follows: 1368 0 1 2 3 1369 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 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Source IPv4 address | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Destination IPv4 address | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 Figure 12: END-POINTS Object Body Format for IPv4 1378 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 1380 0 1 2 3 1381 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 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | | 1384 | Source IPv6 address (16 bytes) | 1385 | | 1386 | | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | | 1389 | Destination IPv6 address (16 bytes) | 1390 | | 1391 | | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 Figure 13: END-POINTS Object Body Format for IPv6 1396 The END-POINTS object body has a fixed length of 8 bytes for IPv4 and 1397 32 bytes for IPv6. 1399 If more than one END-POINTS object is present, the first MUST be 1400 processed and subsequent objects ignored. 1402 7.7. BANDWIDTH Object 1404 The BANDWIDTH object is used to specify the requested bandwidth for a 1405 TE LSP. 1407 If the requested bandwidth is equal to 0, the BANDWIDTH object is 1408 optional. Conversely, if the requested bandwidth is non equal to 0, 1409 the PCReq message MUST contain a BANDWIDTH object. 1411 In the case of the reoptimization of a TE LSP, the bandwidth of the 1412 existing TE LSP MUST also be included in addition to the requested 1413 bandwidth if and only if the two values differ. Consequently, two 1414 Object-Type values are defined that refer to the requested bandwidth 1415 and the bandwidth of the TE LSP for which a reoptimization is being 1416 performed. 1418 The BANDWIDTH object may be carried within PCReq and PCRep messages. 1420 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1421 value=5) 1423 Two Object-Type values are defined for the BANDWIDTH object: 1425 o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by 1426 IANA (recommended value=1) 1428 o Bandwidth of an existing TE LSP for which a reoptimization is 1429 requested. BANDWIDTH Object-Type is to be assigned by IANA 1430 (recommended value=2) 1432 The format of the BANDWIDTH object body is as follows: 1434 0 1 2 3 1435 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 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | Bandwidth | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 Figure 14: BANDWIDTH Object Body Format 1442 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1443 IEEE floating point format, expressed in bytes per second. Refer to 1444 Section 3.1.2 of [RFC3471] for a table of commonly used values. 1446 The BANDWIDTH object body has a fixed length of 4 bytes. 1448 7.8. METRIC Object 1450 The METRIC object is optional and can be used for several purposes. 1452 In a PCReq message, a PCC MAY insert one of more METRIC objects: 1454 o To indicate the metric that MUST be optimized by the path 1455 computation algorithm (IGP metric, TE metric, Hop counts). 1456 Currently, three metrics are defined: the IGP cost, the TE metric 1457 (see [RFC3785]) and the number of hops traversed by a TE LSP. 1459 o To indicate a bound on the path cost that MUST NOT be exceeded for 1460 the path to be considered as acceptable by the PCC. 1462 In a PCRep message, the METRIC object MAY be inserted so as to 1463 provide the cost for the computed path. It MAY also be inserted 1464 within a PCRep with the NO-PATH object to indicate that the metric 1465 constraint could not be satisfied. 1467 The path computation algorithmic aspects used by the PCE to optimize 1468 a path with respect to a specific metric are outside the scope of 1469 this document. 1471 It must be understood that such path metrics are only meaningful if 1472 used consistently: for instance, if the delay of a computed path 1473 segment is exchanged between two PCEs residing in different domains, 1474 consistent ways of defining the delay must be used. 1476 The absence of the METRIC object MUST be interpreted by the PCE as a 1477 path computation request for which no constraints need be applied to 1478 any of the metrics. 1480 METRIC Object-Class is to be assigned by IANA (recommended value=6) 1482 METRIC Object-Type is to be assigned by IANA (recommended value=1) 1484 The format of the METRIC object body is as follows: 1486 0 1 2 3 1487 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 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Reserved | Flags |C|B| T | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | metric-value | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 Figure 15: METRIC Object Body Format 1496 The METRIC object body has a fixed length of 8 bytes. 1498 Reserved (16 bits): This field MUST be set to zero on transmission 1499 and MUST be ignored on receipt. 1501 T (Type - 8 bits): Specifies the metric type. 1503 Three values are currently defined: 1505 o T=1: IGP metric 1507 o T=2: TE metric 1508 o T=3: Hop Counts 1510 Flags (8 bits): Two flags are currently defined: 1512 o B (Bound - 1 bit): When set in a PCReq message, the metric-value 1513 indicates a bound (a maximum) for the path metric that must not be 1514 exceeded for the PCC to consider the computed path as acceptable. 1515 The path metric must be less than or equal to the value specified 1516 in the Metric-value field. When the B flag is cleared, the 1517 metric-value field is not used to reflect a bound constraint. 1519 o C (Computed Metric - 1 bit): When set in a PCReq message, this 1520 indicates that the PCE MUST provide the computed path metric value 1521 (should a path satisfying the constraints be found) in the PCRep 1522 message for the corresponding metric. 1524 Unassigned flags MUST be set to zero on transmission and MUST be 1525 ignored on receipt. 1527 Metric-value (32 bits): metric value encoded in 32 bits in IEEE 1528 floating point format. 1530 Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 1531 message. There MUST be at most one instance of the METRIC object for 1532 each metric type with the same B flag value. If two or more 1533 instances of a METRIC object with the same B flag value are present 1534 for a metric type, only the first instance MUST be considered and 1535 other instances MUST be ignored. 1537 The presence of two METRIC objects of the same type with a different 1538 value of the B-Flag in a PCEReq message is allowed. Furthermore, it 1539 is also allowed to insert in a PCReq message two METRIC objects with 1540 the same type that have both their B-Flag cleared: in this case, an 1541 objective function must be used by the PCE to solve a multi-parameter 1542 constraint problem. 1544 A METRIC object used to indicate the metric to optimize during the 1545 path computation MUST have the B-Flag cleared and the C-Flag set to 1546 the appropriate value. When the path computation relates to the 1547 reoptimization of an exiting TE LSP (in which case R-Flag of the RP 1548 object is set) an implementation MAY decide to set the metric-value 1549 field to the computed value of the metric of the TE LSP to be 1550 reoptimized with regards to a specific metric type. 1552 A METRIC object used to reflect a bound MUST have the B-Flag set, the 1553 C-Flag and metric-value field set to the appropriate values. 1555 In a PCRep message, unless not allowed by PCE policy, at least one 1556 METRIC object MUST be present that reports the computed path metric 1557 if the C bit of the METRIC object was set in the corresponding path 1558 computation request (the B-flag MUST be cleared). The C-flag has no 1559 meaning in a PCRep message. Optionally the PCRep message MAY contain 1560 additional METRIC objects that correspond to bound constraints, in 1561 which case the metric-value MUST be equal to the corresponding 1562 computed path metric (the B-flag MUST be set). If no path satisfying 1563 the constraints could be found by the PCE, the METRIC objects MAY 1564 also be present in the PCRep message with the NO-PATH object to 1565 indicate the constraint metric that could be satisfied. 1567 Example: if a PCC sends a path computation request to a PCE where the 1568 metric to optimize is the IGP metric and the TE metric must not 1569 exceed the value of M, two METRIC object are inserted in the PCReq 1570 message: 1572 o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000 1574 o Second METRIC Object with B=1, T=2, metric-value=M 1576 If a path satisfying the set of constraints can be found by the PCE 1577 and there is no policy that prevents the return of the computed 1578 metric, the PCE inserts one METRIC object with B=0, T=1, metric- 1579 value= computed IGP path cost. Additionally, the PCE may insert a 1580 second METRIC object with B=1, T=2, metric-value= computed TE path 1581 cost. 1583 7.9. Explicit Route Object 1585 The ERO is used to encode the path of a TE LSP through the network. 1586 The ERO is carried within a PCRep message to provide the computed TE 1587 LSP should the path computation have been successful. 1589 The contents of this object are identical in encoding to the contents 1590 of the Resource Reservation Protocol Traffic Engineering Extensions 1591 (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473] 1592 and [RFC3477]. That is, the object is constructed from a series of 1593 sub-objects. Any RSVP-TE ERO sub-object already defined or that 1594 could be defined in the future for use in the RSVP-TE ERO is 1595 acceptable in this object. 1597 PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types. 1599 Since the explicit path is available for immediate signaling by the 1600 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1601 and fields in this object are identical to those defined for the ERO. 1603 ERO Object-Class is to be assigned by IANA (recommended value=7) 1604 ERO Object-Type is to be assigned by IANA (recommended value=1) 1606 7.10. Reported Route Object 1608 The RRO is exclusively carried within a PCReq message so as to report 1609 the route followed by a TE LSP for which a reoptimization is desired. 1611 The contents of this object are identical in encoding to the contents 1612 of the Route Record Object defined in [RFC3209], [RFC3473] and 1613 [RFC3477]. That is, the object is constructed from a series of sub- 1614 objects. Any RSVP-TE RRO sub-object already defined or that could be 1615 defined in the future for use in the RSVP-TE RRO is acceptable in 1616 this object. 1618 The meanings of all of the sub-objects and fields in this object are 1619 identical to those defined for the RSVP-TE RRO. 1621 PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types. 1623 RRO Object-Class is to be assigned by IANA (recommended value=8) 1625 RRO Object-Type is to be assigned by IANA (recommended value=1) 1627 7.11. LSPA Object 1629 The LSPA object is optional and specifies various TE LSP attributes 1630 to be taken into account by the PCE during path computation. The 1631 LSPA (LSP Attributes) object can be carried within a PCReq message, 1632 or a PCRep message in case of unsuccessful path computation (in this 1633 case, the PCRep message also contains a NO-PATH object and the LSPA 1634 object is used to indicate the set of constraints that could not be 1635 satisfied). Most of the fields of the LSPA object are identical to 1636 the fields of the SESSION-ATTRIBUTE (C-Type = 7) object defined in 1637 [RFC3209] and [RFC4090]. When absent from the PCReq message, this 1638 means that the Setup and Holding priorities are equal to 0, and there 1639 are no affinity constraints. 1641 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1643 LSPA Object-Types is to be assigned by IANA (recommended value=1) 1644 The format of the LSPA object body is: 1646 0 1 2 3 1647 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 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Exclude-any | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Include-any | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | Include-all | 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | Setup Prio | Holding Prio | Flags |L| Reserved | 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | | 1658 // Optional TLV(s) // 1659 | | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 Figure 16: LSPA Object Body Format 1663 Setup Prio (Setup Priority - 8 bits). The priority of the TE LSP 1664 with respect to taking resources, in the range of 0 to 7. The value 1665 0 is the highest priority. The Setup Priority is used in deciding 1666 whether this session can preempt another session. 1668 Holding Prio (Holding Priority - 8 bits). The priority of the TE LSP 1669 with respect to holding resources, in the range of 0 to 7. The value 1670 0 is the highest priority. Holding Priority is used in deciding 1671 whether this session can be preempted by another session. 1673 Flags (8 bits) 1675 The flag L corresponds to the "Local protection desired" bit 1676 ([RFC3209]) of the SESSION-ATTRIBUTE Object. 1678 L Flag (Local protection desired). When set, this means that the 1679 computed path must include links protected with Fast Reroute as 1680 defined in [RFC4090]. 1682 Unassigned flags MUST be set to zero on transmission and MUST be 1683 ignored on receipt. 1685 Reserved (8 bits): This field MUST be set to zero on transmission and 1686 MUST be ignored on receipt. 1688 Note that Optional TLVs may be defined in the future to carry 1689 additional TE LSP attributes such as those defined in [RFC4420]. 1691 7.12. Include Route Object Object 1693 The IRO (Include Route Object) is optional and can be used to specify 1694 that the computed path MUST traverse a set of specified network 1695 elements. The IRO MAY be carried within PCReq and PCRep messages. 1696 When carried within a PCRep message with the NO-PATH object, the IRO 1697 indicates the set of elements that cause de PCE to fail to find a 1698 path. 1700 IRO Object-Class is to be assigned by IANA (recommended value=10) 1702 IRO Object-Type is to be assigned by IANA (recommended value=1) 1704 0 1 2 3 1705 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 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | | 1708 // (Subobjects) // 1709 | | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 Figure 17: IRO Body Format 1714 Subobjects: The IRO is made of subobjects identical to the ones 1715 defined in [RFC3209], [RFC3473] and [RFC3477] where the IRO subobject 1716 type is identical to the subobject type defined in the related 1717 documents. 1719 The following subobject types are supported. 1721 Type Subobject 1722 1 IPv4 prefix 1723 2 IPv6 prefix 1724 4 Unnumbered Interface ID 1725 32 Autonomous system number 1726 The L bit of such sub-object has no meaning within an IRO. 1728 7.13. SVEC Object 1730 7.13.1. Notion of Dependent and Synchronized Path Computation Requests 1732 Independent versus dependent path computation requests: path 1733 computation requests are said to be independent if they are not 1734 related to each other. Conversely a set of dependent path 1735 computation requests is such that their computations cannot be 1736 performed independently of each other (a typical example of dependent 1737 requests is the computation of a set of diverse paths). 1739 Synchronized versus non-synchronized path computation requests: a set 1740 of path computation requests is said to be non-synchronized if their 1741 respective treatment (path computations) can be performed by a PCE in 1742 a serialized and independent fashion. 1744 There are various circumstances where the synchronization of a set of 1745 path computations may be beneficial or required. 1747 Consider the case of a set of N TE LSPs for which a PCC needs to send 1748 path computation requests to a PCE. The first solution consists of 1749 sending N separate PCReq messages to the selected PCE. In this case, 1750 the path computation requests are non-synchronized. Note that the 1751 PCC may chose to distribute the set of N requests across K PCEs for 1752 load balancing purposes. Considering that M (with M+-+-+-+-+-+-+ | | 2970 | | | KeepWait |----+ | 2971 | +--| |<---+ | 2972 |+-----+-+-+-+-+-+-+ | | 2973 || | | | 2974 || | | | 2975 || V | | 2976 || +->+-+-+-+-+-+-+----+ | 2977 || | | OpenWait |-------+ 2978 || +--| |<------+ 2979 ||+----+-+-+-+-+-+-+<---+ | 2980 ||| | | | 2981 ||| | | | 2982 ||| V | | 2983 ||| +->+-+-+-+-+-+-+ | | 2984 ||| | |TCPPending |----+ | 2985 ||| +--| | | 2986 |||+---+-+-+-+-+-+-+<---+ | 2987 |||| | | | 2988 |||| | | | 2989 |||| V | | 2990 |||+--->+-+-+-+-+ | | 2991 ||+---->| Idle |-------+ | 2992 |+----->| |----------+ 2993 +------>+-+-+-+-+ 2995 Figure 23: PCEP Finite State Machine for the PCC 2997 PCEP defines the following set of variables: 2999 Connect: timer (in seconds) started after having initialized a TCP 3000 connection using the PCEP well-known TCP port. The value of the 3001 TCPConnect timer is 60 seconds. 3003 ConnectRetry: specifies the number of times the system has tried to 3004 establish a TCP connection with a PCEP peer without success. 3006 ConnectMaxRetry: Maximum number of times the system tries to 3007 establish a TCP connection using the PCEP well-known TCP port before 3008 going back to the Idle state. The value of the ConnectMaxRetry is 5. 3010 OpenWait: timer that corresponds to the amount of time a PCEP peer 3011 will wait to receive an Open message from the PCEP peer after the 3012 expiration of which the system releases the PCEP resource and go back 3013 to the Idle state. The OpenWait timer has a fixed value of 60 3014 seconds. 3016 KeepWait: timer that corresponds to the amount of time a PCEP peer 3017 will wait to receive a KeepAlive or a PCErr message from the PCEP 3018 peer after the expiration of which the system releases the PCEP 3019 resource and go back to the Idle state. The KeepWait timer has a 3020 fixed value of 60 seconds. 3022 OpenRetry: specifies the number of times the system has received an 3023 Open message with unacceptable PCEP session characteristics. 3025 The following two states variable are defined: 3027 RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system 3028 has received an acceptable Open message. 3030 LocalOK: the LocalOK variable is a Boolean set to 1 if the system has 3031 received a Keepalive message acknowledging that the Open message sent 3032 to the peer was valid. 3034 Idle State: 3036 The idle state is the initial PCEP state where PCEP (also referred to 3037 as "the system") waits for an initialization event that can either be 3038 manually triggered by the user (configuration) or automatically 3039 triggered by various events. In Idle state, PCEP resources are 3040 allocated (memory, potential process, ...) but no PCEP messages are 3041 accepted from any PCEP peer. The system listens the well-known PCEP 3042 TCP port. 3044 The following set of variable are initialized: 3046 TCPRetry=0, 3048 LocalOK=0, 3050 RemoteOK=0, 3052 OpenRetry=0. 3054 Upon detection of a local initialization event (e.g. user 3055 configuration to establish a PCEP session with a particular PCEP 3056 peer, local event triggering the establishment of a PCEP session with 3057 a PCEP peer such as the automatic detection of a PCEP peer, ...), the 3058 system: 3060 o Initiates of a TCP connection with the PCEP peer, 3062 o Starts the Connect timer, 3064 o Moves to the TCPPending state. 3066 Upon receiving a TCP connection on the well-known PCEP TCP port, if 3067 the TCP connection establishment succeeds, the system: 3069 o Sends an Open message, 3071 o Starts the OpenWait timer, 3073 o Moves to the OpenWait state. 3075 If the connection establishment fails, the system remains in the Idle 3076 state. Any other event received in the Idle state is ignored. 3078 It is expected that an implementation will use an exponentially 3079 increasing timer between automatically generated Initialization 3080 events and between retries of TCP connection establishment. 3082 TCPPending State 3084 If the TCP connection establishment succeeds, the system: 3086 o Sends an Open message, 3088 o Starts the OpenWait timer, 3090 o Moves to the OpenWait state. 3092 If the TCP connection establishment fails (an error is detected 3093 during the TCP connection establishment) or the Connect timer 3094 expires: 3096 o If ConnectRetry =ConnectMaxRetry the system moves to the Idle 3097 State 3099 o If ConnectRetry < ConnectMaxRetry the system: 3101 1. Initiates of a TCP connection with the PCEP peer, 3103 2. Increments the ConnectRetry variable, 3104 3. Restarts the Connect timer, 3106 4. Stays in the TPCPending state. 3108 In response to any other event the system releases the PCEP resources 3109 for that peer and moves back to the Idle state. 3111 OpenWait State: 3113 In the OpenWait state, the system waits for an Open message from its 3114 PCEP peer. 3116 If the system receives an Open message from the PCEP peer before the 3117 expiration of the OpenWait timer, the system first examines all of 3118 its sessions that are in the OpenWait or KeepWait state. If another 3119 session with the same PCEP peer already exists (same IP address), 3120 then the system performs the following collision resolution 3121 procedure: 3123 o If the system has initiated the current session and it has a lower 3124 IP address than the PCEP Peer, the system closes the TCP 3125 connection, releases the PCEP resources for the pending session 3126 and moves back to the Idle state. 3128 o If the session was initiated by the PCEP peer and the system has a 3129 higher IP address that the PCEP Peer, the system closes the TCP 3130 connection, releases the PCEP resources for the pending session, 3131 and moves back to the Idle state. 3133 o Otherwise, the system checks the PCEP session attributes 3134 (Keepalive frequency, DeadTimer, ...). 3136 If an error is detected (e.g. malformed Open message, reception of a 3137 message that is not an Open message, presence of two Open objects, 3138 ...), PCEP generates an error notification, the PCEP peer sends a 3139 PCErr message with Error-Type=1 and Error-value=1. The system 3140 releases the PCEP resources for the PCEP peer, closes the TCP 3141 connection and moves to the Idle state. 3143 If no errors are detected, PCEP increments the OpenRetry variable. 3145 If no errors are detected, OpenRetry=1 and the session 3146 characteristics are unacceptable, the PCEP peer sends a PCErr with 3147 Error-Type=1 and Error-value=5, the system releases the PCEP 3148 resources for that peer and moves back to the Idle state. 3150 If no errors are detected, and the session characteristics are 3151 acceptable to the local system, the system: 3153 o Sends a Keepalive message to the PCEP peer, 3155 o Starts the Keepalive timer, 3157 o Sets the RemoteOK variable to 1. 3159 If LocalOK=1 the system clears the OpenWait timer and moves to the UP 3160 state. 3162 If LocalOK=0 the system clears the OpenWait timer, starts the 3163 KeepWait timer and moves to the KeepWait state. 3165 If no errors are detected, but the session characteristics are 3166 unacceptable and non-negotiable, the PCEP peer sends a PCErr with 3167 Error-Type=1 and Error-value=3, the system releases the PCEP 3168 resources for that peer, and moves back to the Idle state. 3170 If no errors are detected, and OpenRetry is 0, and the session 3171 characteristics are unacceptable but negotiable (such as, the 3172 Keepalive period or the DeadTimer), then the system: 3174 o Increments the OpenRetry variable, 3176 o Sends a PCErr message with Error-Type=1 and Error-value=4 that 3177 contains proposed acceptable session characteristics, 3179 o If LocalOK=1, the system restarts the OpenWait timer and stays in 3180 the OpenWait state 3182 o If LocalOK=0, the system clears the OpenWait timer, starts the 3183 KeepWait timer and moves to the KeepWait state 3185 If no Open message is received before the expiration of the OpenWait 3186 timer, the PCEP peer sends a PCErr message with Error-Type=1 and 3187 Error-value=2, the system releases the PCEP resources for the PCEP 3188 peer, closes the TCP connection and moves to the Idle state. 3190 In response to any other event the system releases the PCEP resources 3191 for that peer and moves back to the Idle state. 3193 KeepWait State 3195 In the Keepwait state, the system waits for the receipt of a 3196 Keepalive from its PCEP peer acknowledging its Open message or a 3197 PCErr message in response to unacceptable PCEP session 3198 characteristics proposed in the Open message. 3200 If an error is detected (e.g. malformed Keepalive message), PCEP 3201 generates an error notification, the PCEP peer sends a PCErr message 3202 with Error-Type=1 and Error-value=1. The system releases the PCEP 3203 resources for the PCEP peer, closes the TCP connection and moves to 3204 the Idle state. 3206 If a Keepalive message is received before the expiration of the 3207 KeepWait timer, then the system sets LocalOK=1 and: 3209 o If RemoteOK=1, the system clears the KeepWait timer and moves to 3210 the UP state. 3212 o If RemoteOK=0, the system clears the KeepWait timer, starts the 3213 OpenWait timer and moves to the OpenWait State. 3215 If a PCErr message is received before the expiration of the KeepWait 3216 timer: 3218 1. If the proposed values are unacceptable, the PCEP peer sends a 3219 PCErr message with Error-Type=1 and Error-value=6 and the system 3220 releases the PCEP resources for that PCEP peer, closes the TCP 3221 connection and moves to the Idle state. 3223 2. If the proposed values are acceptable, the system adjusts its 3224 PCEP session characteristics according to the proposed values 3225 received in the PCErr message restarts the KeepWait timer and 3226 sends a new Open message. If RemoteOK=1, the system restarts the 3227 KeepWait timer and stays in the KeepWait state. If RemoteOK=0, 3228 the system clears the KeepWait timer, start the OpenWait timer 3229 and moves to the OpenWait state. 3231 If neither a Keepalive nor a PCErr is received after the expiration 3232 of the KeepWait timer, the PCEP peer sends a PCErr message with 3233 Error-Type=1 and Error-value=7 and, system releases the PCEP 3234 resources for that PCEP peer, closes the TCP connection and moves to 3235 the Idle State. 3237 In response to any other event the system releases the PCEP resources 3238 for that peer and moves back to the Idle state. 3240 UP State 3242 In the UP state, the PCEP peer starts exchanging PCEP messages 3243 according to the session characteristics. 3245 If the Keepalive timer expires, the system restarts the Keepalive 3246 timer and sends a Keepalive message. 3248 If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from 3249 the PCEP peer before the expiration of the DeadTimer, the system 3250 terminates PCEP session according to the procedure defined in 3251 Section 6.8, releases the PCEP resources for that PCEP peer, closes 3252 the TCP connection and moves to the Idle State. 3254 If a malformed message is received, the system terminates the PCEP 3255 session according to the procedure defined in Section 6.8, releases 3256 the PCEP resources for that PCEP peer, closes the TCP connection and 3257 moves to the Idle State. 3259 If the system detects that the PCEP peer tries to setup a second TCP 3260 connection, it stops the TCP connection establishment and sends a 3261 PCErr with Error-Type=9. 3263 If the TCP connection fails, the system releases the PCEP resources 3264 for that PCEP peer, closes the TCP connection and moves to the Idle 3265 State. 3267 Appendix B. PCEP Variables 3269 PCEP defines the following configurable variables: 3271 KeepAlive timer: minimum period of time between the sending of PCEP 3272 messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A 3273 suggested value for the Keepalive timer is 30 seconds. 3275 DeadTimer: period of timer after the expiration of which a PCEP peer 3276 declared the session down if no PCEP message has been received. 3278 SyncTimer: the SYNC timer is used in the case of synchronized path 3279 computation request using the SVEC object defined in Section 7.13.3. 3280 Consider the case where a PCReq message is received by a PCE that 3281 contains the SVEC object referring to M synchronized path computation 3282 requests. If after the expiration of the SYNC timer all the M path 3283 computation requests have not been received, a protocol error is 3284 triggered and the PCE MUST cancel the whole set of path computation 3285 requests. A RECOMMENDED value for the SYNC timer is 60 seconds. 3287 Authors' Addresses 3289 JP Vasseur (editor) 3290 Cisco Systems 3291 1414 Massachusetts Avenue 3292 Boxborough, MA 01719 3293 USA 3295 Email: jpv@cisco.com 3297 JL Le Roux (editor) 3298 France Telecom 3299 2, Avenue Pierre-Marzin 3300 Lannion, 22307 3301 FRANCE 3303 Email: jeanlouis.leroux@orange-ftgroup.com 3305 Full Copyright Statement 3307 Copyright (C) The IETF Trust (2008). 3309 This document is subject to the rights, licenses and restrictions 3310 contained in BCP 78, and except as set forth therein, the authors 3311 retain all their rights. 3313 This document and the information contained herein are provided on an 3314 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3315 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3316 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3317 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3318 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3319 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3321 Intellectual Property 3323 The IETF takes no position regarding the validity or scope of any 3324 Intellectual Property Rights or other rights that might be claimed to 3325 pertain to the implementation or use of the technology described in 3326 this document or the extent to which any license under such rights 3327 might or might not be available; nor does it represent that it has 3328 made any independent effort to identify any such rights. Information 3329 on the procedures with respect to rights in RFC documents can be 3330 found in BCP 78 and BCP 79. 3332 Copies of IPR disclosures made to the IETF Secretariat and any 3333 assurances of licenses to be made available, or the result of an 3334 attempt made to obtain a general license or permission for the use of 3335 such proprietary rights by implementers or users of this 3336 specification can be obtained from the IETF on-line IPR repository at 3337 http://www.ietf.org/ipr. 3339 The IETF invites any interested party to bring to its attention any 3340 copyrights, patents or patent applications, or other proprietary 3341 rights that may cover technology that may be required to implement 3342 this standard. Please address the information to the IETF at 3343 ietf-ipr@ietf.org. 3345 Acknowledgment 3347 Funding for the RFC Editor function is provided by the IETF 3348 Administrative Support Activity (IASA).