idnits 2.17.1 draft-ietf-pce-pcep-00.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 27. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2090. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2096. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2394), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 47. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 48 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 559 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1346 has weird spacing: '...umbered inter...' == Line 2104 has weird spacing: '...afts as refer...' == Line 2396 has weird spacing: '...ses and restr...' == Line 2400 has weird spacing: '... This docum...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: L (Link diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST not have any link in common. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: N (Node diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST not have any node in common. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: S (SRLG diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST not share any SRLG (Shared Risk Link Group). -- 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 (November 2005) is 6736 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PCE-COM-GEN-REQ' is mentioned on line 196, but not defined == Missing Reference: 'RSPV-TE' is mentioned on line 1209, but not defined == Missing Reference: 'GRSVP' is mentioned on line 1186, but not defined == Missing Reference: 'G-MPLS' is mentioned on line 1339, but not defined == Missing Reference: 'RFC2385' is mentioned on line 2041, but not defined ** Obsolete undefined reference: RFC 2385 (Obsoleted by RFC 5925) == Unused Reference: 'RFC' is defined on line 2117, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 2120, but no explicit reference was found in the text == Unused Reference: 'RFC3979' is defined on line 2123, but no explicit reference was found in the text == Unused Reference: 'RSVP' is defined on line 2126, but no explicit reference was found in the text == Unused Reference: 'COPS' is defined on line 2139, but no explicit reference was found in the text == Unused Reference: 'SCTP' is defined on line 2142, but no explicit reference was found in the text == Unused Reference: 'TCP' is defined on line 2145, but no explicit reference was found in the text == Unused Reference: 'DS-TE-PROTO' is defined on line 2148, but no explicit reference was found in the text == Unused Reference: 'G-RECV-E2E-SIG' is defined on line 2152, but no explicit reference was found in the text == Unused Reference: 'PCE-GEN-COM-REQ' is defined on line 2266, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RTG' is defined on line 2173, but no explicit reference was found in the text == Unused Reference: 'INT-AREA-REQ' is defined on line 2177, but no explicit reference was found in the text == Unused Reference: 'INT-AS-REQ' is defined on line 2181, but no explicit reference was found in the text == Unused Reference: 'INT-DOMAIN-FRWK' is defined on line 2185, but no explicit reference was found in the text == Unused Reference: 'MGT' is defined on line 2189, but no explicit reference was found in the text == Unused Reference: 'XRO' is defined on line 2193, but no explicit reference was found in the text == Unused Reference: 'DOBB' is defined on line 2206, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03 -- No information found for draft-ietf-pce-arch - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'IPSEC') (Obsoleted by RFC 4303, RFC 4305) Summary: 13 errors (**), 0 flaws (~~), 33 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group JP Vasseur (Editor) 2 Cisco System Inc. 3 IETF Internet Draft JL Le Roux 4 France Telecom 5 Arthi Ayyangar 6 Juniper Networks 7 Eiji Oki 8 Yuichi Ikejiri 9 NTT 10 Alia Atlas 11 Google, Inc 12 Andrew Dolganow 13 Alcatel 14 Proposed Status: Standard 15 Expires: May 2006 November 2005 17 Path Computation Element (PCE) communication Protocol (PCEP) 18 - Version 1 - 20 draft-ietf-pce-pcep-00.txt 22 Status of this Memo 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware 26 have been or will be disclosed, and any of which he or she becomes 27 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Copyright Notice 47 Copyright (C) The Internet Society (2005). All Rights Reserved. 49 Abstract 51 This document specifies the Path Computation Element communication 52 Protocol (PCEP) for communications between a Path Computation Client 53 (PCC) and a Path Computation Element (PCE), or between two PCEs. Such 54 interactions include path computation requests and path computation 55 replies as well as notifications of specific states related to the 56 use of a PCE in the context of MPLS and GMPLS Traffic Engineering. 57 The PCEP protocol is designed to be flexible and extensible so as to 58 easily allow for the addition of further messages and objects, should 59 further requirements be expressed in the future. 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC-2119. 67 Table of Contents 69 1. Terminology................................................3 70 2. Introduction...............................................4 71 3. Assumptions................................................4 72 4. Transport protocol.........................................5 73 5. Architectural Protocol Overview (Model)....................5 74 5.1. Problem..................................................5 75 5.2. Architectural Protocol Overview..........................6 76 5.2.1. Initialization phase...................................6 77 5.2.2. Path computation request sent by a PCC to a PCE........7 78 5.2.3. Path computation reply sent by the PCE to a PCC........8 79 5.2.4. Notifications..........................................9 80 5.2.5. Termination of the PCEP Session........................10 81 6. PCEP messages..............................................10 82 6.1. Common header............................................10 83 6.2. Open message.............................................11 84 6.3. Keepalive message........................................13 85 6.4. Path Computation Request (PCReq) message.................13 86 6.5. Path Computation Reply (PCRep) message...................14 87 6.6. Notification (PCNtf) message.............................15 88 6.7. Error (PCErr) message....................................15 89 7. Object Formats.............................................16 90 7.1. Common object header.....................................16 91 7.2. OPEN Object..............................................18 92 7.3. RP Object................................................19 93 7.4. NO-PATH Object...........................................20 94 7.5. END-POINTS Object........................................21 95 7.6. BANDWIDTH object.........................................22 96 7.7. DELAY Object.............................................23 97 7.8. ERO Object...............................................24 98 7.9. RRO Object...............................................24 99 7.10. LSPA Object.............................................24 100 7.11. IRO Object..............................................26 101 7.12. SVEC Object.............................................27 102 7.13. NOTIFICATION object.....................................28 103 7.14. PCEP-ERROR object.......................................31 104 8. Independent versus synchronized path computation requests..34 105 9. Elements of procedure......................................35 106 9.1. Non recognized or non support object received in a 107 PCReq message 108 9.2. RP object................................................35 109 9.3. SVEC object..............................................36 110 10. Manageability Considerations..............................36 111 11. IANA Considerations.......................................36 112 11.1. TCP port................................................36 113 11.2. PCEP Objects............................................36 114 11.3. Notification............................................39 115 11.4. PCEP Error..............................................39 116 12. Security Considerations...................................40 117 12.1. PCEP Authentication and Integrity.......................40 118 12.2. PCEP Privacy............................................40 119 12.3. Protection against Denial of Service attacks............41 120 13. Intellectual Property Statement...........................41 121 14. Acknowledgment............................................42 122 15. References................................................42 123 15.1. Normative references....................................42 124 15.2. Informative References..................................43 125 16. Authors' Address..........................................44 127 Appendix A: Compliance of PCEP to the set of requirements 128 specified in draft-ietf-pce-comm-protocol-gen-reqs........... 45 130 1. Terminology 132 Terminology used in this document 134 IGP Area: OSPF Area or IS-IS level 136 Inter-domain TE LSP: A TE LSP whose path transits across at least 137 two different domains where a domain can either be an IGP area, an 138 Autonomous System or a sub-AS (BGP confederations). 140 PCC: Path Computation Client: any client application requesting a 141 path computation to be performed by a Path Computation Element. 143 PCE: Path Computation Element: an entity (component, application or 144 network node) that is capable of computing a network path or route 145 based on a network graph and applying computational constraints. 147 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the 148 PCE). 150 PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a 151 Detour LSP. 153 TED: Traffic Engineering Database which contains the topology and 154 resource information of the domain. The TED may be fed by IGP 155 extensions or potentially by other means. 157 Explicit path: full explicit path from start to destination made of a 158 list of strict hops where a hop may be an abstract node such as an 159 AS. 161 Strict/loose path: mix of strict and loose hops comprising of at 162 least one loose hop representing the destination where a hop may be 163 an abstract node such as an AS. 165 Within this document, when PCE-PCE communications are being 166 described, the requesting PCE fills the role of a PCC. This provides 167 a saving in documentation without loss of function. 169 2. Introduction 171 [PCE-ARCH] describes the motivations and architecture for a PCE-based 172 model to perform path computation for MPLS and GMPLS TE LSPs. The 173 model allows the separation of PCE from PCC, and allows cooperation 174 between PCEs. This necessitates a communication protocol between PCC 175 and PCE, and between PCEs. 177 [PCE-COM-GEN-REQ] states the generic requirements for such a protocol 178 including a requirement that the same protocol must be used between 179 PCC and PCE, and between PCEs. Additional application-specific 180 requirements (for scenarios such as inter-area, inter-AS, etc.) are 181 not included in [PCE-COM-GEN-REQ], but there is a requirement that 182 any solution protocol must be easily extensible to handle other 183 requirements as they are introduced in application-specific 184 requirements documents. 186 This document specifies the Path Computation Element communication 187 Protocol (PCEP) for communications between Path Computation Client 188 (PCC) and a Path Computation Element (PCE),or between two PCEs. Such 189 interactions include path computation requests and path computation 190 replies as well as notifications of specific states related to the 191 use of a PCE in the context of MPLS and GMPLS Traffic Engineering. 192 The PCEP protocol is designed to be flexible and extensible so as to 193 easily allow for the addition of further messages and objects, should 194 further requirements be expressed in the future. 196 The compliance of PCEP to the set of requirements stated in [PCE-COM- 197 GEN-REQ] is covered in Appendix A. 199 3. Assumptions 201 [PCE-ARCH] describes various types of PCE: it is important to note 202 that no assumption is made on the nature of the PCE in this document. 204 Moreover, it is assumed that the PCE gets the required information so 205 as to perform TE LSP path computation which usually requires network 206 topology and resource information that can be gathered by routing 207 protocols or by some other means. The retrieval of such information 208 is out of the scope of this document. 210 Similarly, no assumption is made on the discovery method used by a 211 PCC to discover a set of PCEs (e.g. via static configuration or 212 dynamic discovery) and select a PCE to send its path computation 213 request(s) to. For the sake of reference [PCE-DISC-REQ] defines a 214 list of requirements for dynamic PCE discovery. 216 4. Transport protocol 218 PCEP operates over TCP using the well-known TCP port (TBD by IANA). 219 This allows the requirements of reliable messaging and flow control 220 to be met without further protocol work. 222 An implementation may decide to keep the TCP session alive for an 223 unlimited time (this may for instance be the case should an 224 implementation have to send new requests frequently in which case the 225 TCP session will already be in place). Another motivation for leaving 226 the TCP connection open would be to avoid TCP connection 227 establishment time. This mode is also referred to as the "Permanent 228 mode". Conversely, in some other circumstances, it may be desirable 229 to systematically open and close the TCP connection for each PCEP 230 request (this may for instance be the case if sending of PCEP path 231 computation request is a rare event). This mode is referred to as the 232 "Per-request mode". 234 Since there are circumstances where the TCP connection state is used 235 to detect the PCC/PCE liveness (e.g case of a stateful PCE detecting 236 a PCC failure thanks to the TCP state), the desired mode MUST be 237 known by both the PCC and the PCE and is determined during the 238 initialization phase. 240 5. Architectural Protocol Overview (Model) 242 The aim of this section is to describe the PCEP protocol model in the 243 spirit of [WP]. An architecture protocol overview (the big picture of 244 the protocol) is provided in this section where details of the 245 protocol can be found in further sections. 247 5.1. Problem 249 The PCE-based architecture used for the computation of MPLS and GMPLS 250 TE LSP paths is described in [PCE-ARCH]. When the PCC and the PCE are 251 not collocated, a communication protocol between the PCC and the PCE 252 is required. PCEP is such a protocol designed specifically for 253 communications between a PCC and a PCE or between two PCEs: a PCC may 254 use PCEP to send a path computation request for one or more TE LSP(s) 255 to a PCE and such a PCE may reply with a set of computed path(s) if 256 one or more path(s) obeying the set of constraints can be found. 258 5.2. Architectural Protocol Overview 260 PCEP operates over TCP, which allows the requirements of reliable 261 messaging and flow control to be met without further protocol work. 263 Several PCEP messages are defined: 264 - Open and Keepalive messages are used to initiate and maintain a 265 PCEP session respectively. 266 - PCReq: a message sent by a PCC to a PCE to request a path 267 computation. 268 - PCRep: a message sent by a PCE to a PCC in reply to a path 269 computation request. A PCRep message can either contain a set of 270 computed path(s) if the request could be satisfied or a negative 271 reply otherwise. 272 - PCNtf: a notification message either sent by a PCC to a PCE or a 273 PCE to a PCC to notify of specific event. 274 - PCErr: a message related to a protocol error condition. 276 The set of available PCE(s) may be either statically configured on a 277 PCC or dynamically discovered (the mechanism for that discovery is 278 out of the scope of this document). A PCC may have PCEP sessions with 279 more than one PCE and similarly a PCE may have PCEP sessions with 280 multiple PCCs. A PCEP session establishment can either be triggered 281 by the PCC or the PCE. 283 5.2.1 Initialization phase 285 The initialization phase consists of two successive steps: 287 1) Establishment of a TCP connection (3-way handshake) between the 288 PCC and the PCE. 290 2) Establishment of a PCEP session over the TCP connection 291 Once the TCP connection is established, the PCC and the PCE (also 292 referred to as "PCEP peers") initiate a PCEP session establishment 293 during which various session parameters are advertised. Those 294 parameters are carried within Open messages and include the keepalive 295 timer, the PCEP session mode (per-request or permanent), potential 296 detailed capabilities and policy rules that specify the conditions 297 under which path computation requests may be sent to the PCE. If the 298 PCEP session establishment phase fails because the PCEP peers 299 disagree on the exchanged parameters or one of the peers does not 300 answer, the transport connection is immediately closed. Successive 301 retries are permitted but an implementation SHOULD make use of 302 exponential back-off. Keepalive messages are used to acknowledge Open 303 messages and once the PCEP session is established Keepalive messages 304 are exchanged between PCEP peers to ensure the liveness of the PCEP 305 session. 307 +-+-+ +-+-+ 308 |PCC| |PCE| 309 +-+-+ +-+-+ 310 | | 311 |---- Open message --->| 312 | | 313 |<--- Open message ----| 314 | | 315 | | 316 | | 317 |<--- Keepalive -------| 318 | | 319 |---- Keepalive ------>| 321 Figure 1: PCEP Initialization phase (triggered by a PCC) 323 5.2.2. Path computation request sent by a PCC to a PCE 325 Consider the diagram depicted in figure 2. 327 +-+-+ +-+-+ 328 |PCC| |PCE| 329 +-+-+ +-+-+ 330 1)Path computation | | 331 event | | 332 2)PCE Selection | | 333 3)Path computation |---- PCReq message--->| 334 request sent to | | 335 the selected PCE | | 337 Figure 2: Path computation request 339 Once a PCC (or a PCE) has successfully established a PCEP session 340 with one or more PCEs, if an event is triggered that requires the 341 computation of a path, the PCC first selects the PCE it desires to 342 send a path computation request to (note that the PCE selection may 343 be performed prior to the PCEP session establishment). Once a PCC has 344 selected a PCE, it sends a path computation request to the PCE (PCReq 345 message) that contains a variety of objects that specify the set of 346 constraints and attributes for the path to be computed. For example 347 "Compute a TE LSP path with source IP address=x.y.z.t, destination IP 348 address=x.y.z.t, bandwidth=X Mbit/s, Priority=Y, ...". 349 Additionally, the PCC may desire to specify the urgency of such 350 request by assigning a request priority. It is worth pointing out 351 that each request is uniquely identified by a request-id number and 352 the PCC-PCE addresses pair. The process is shown in a schematic form 353 in figure 2. 355 5.2.3. Path computation reply sent by the PCE to a PCC 357 +-+-+ +-+-+ 358 |PCC| |PCE| 359 +-+-+ +-+-+ 361 | | 362 |---- PCReq message--->| 363 | |1) Path computation 364 | |request received 365 | | 366 | |2)Path successfully 367 | |computed 368 | | 369 | |3) Computed path(s) sent 370 | |to the PCC 371 |<--- PCRep message ---| 372 | (Positive reply) | 374 Figure 3a: Path computation request with successful computation 376 +-+-+ +-+-+ 377 |PCC| |PCE| 378 +-+-+ +-+-+ 379 | | 380 | | 381 |---- PCReq message--->| 382 | |1) Path computation 383 | |request received 384 | | 385 | |2) No Path found that 386 | |satisfies the request 387 | | 388 | |3) Negative reply sent to 389 | |the PCC (optionally with 390 | |various additional 391 | |information) 392 |<--- PCRep message ---| 393 | (Negative reply) | 395 Figure 3b: Path computation request with unsuccessfull computation 397 Upon receiving a path computation request from a PCC, the PCE 398 triggers a path computation, the result of which can either be: 399 - Positive: the PCE manages to compute a path satisfying the set of 400 required constraints and returns the set of computed path(s) (note 401 that the PCEP protocol supports the capability to send a single 402 request which refers to the computation of multiple paths: for 403 example, compute two link diverse paths). This is illustrated in 404 figure 3a. 406 - Negative: no path could be computed that satisfies the request. In 407 this case, a PCE may provide the set of constraints that led to path 408 computation failure. Upon receiving a negative reply, a PCC may 409 decide to resend a modified request or take any other appropriate 410 action. This is illustrated in figure 3b. 412 5.2.4 Notifications 414 There are several circumstances whereby a PCE may want to notify a 415 PCC of a specific event. For example, suppose that the PCE suddenly 416 experiences some congestion that would lead to unacceptable response 417 times. The PCE may want to notify one or more PCCs that some of their 418 requests (listed in the notification) will not be satisfied, 419 potentially resulting in path computation redirections on the PCC 420 towards another PCE, if an alternate PCE is available. Similarly, a 421 PCC may desire to notify a PCE of particular event such as the 422 cancellation of pending request(s). 424 +-+-+ +-+-+ 425 |PCC| |PCE| 426 +-+-+ +-+-+ 427 1)Path computation | | 428 event | | 429 2)PCE Selection | | 430 3)Path computation |---- PCReq message--->| 431 request X sent to | |4) Path computation 432 the selected PCE | |triggered 433 | | 434 | | 435 5) Path computation| | 436 request X cancelled| | 437 |---- PCNtf message -->| 438 | |6) Path computation 439 | |request X cancelled 441 Figure 4: Example of PCC notification (request cancellation) sent to 442 a PCE 444 +-+-+ +-+-+ 445 |PCC| |PCE| 446 +-+-+ +-+-+ 447 1)Path computation | | 448 event | | 449 2)PCE Selection | | 450 3)Path computation |---- PCReq message--->| 451 request X sent to | |4) Path computation 452 the selected PCE | |triggered 453 | | 454 | | 455 | |5) PCE experiencing 456 | |congestion 457 | | 458 | |6) Path computation 459 | |request X cancelled 460 | | 461 |<--- PCNtf message----| 463 Figure 5: Example of PCEP notification (request(s) cancellation) send 464 to a PCC 466 5.2.5. Termination of the PCEP Session 468 When one of the PCEP peers desires to terminate a PCEP session it 469 MUST close the TCP connection. If the PCEP session is terminated by 470 the PCE, the PCC MUST clear all the states related to pending 471 requests sent to the PCE. Similarly, if the PCC terminates a PCEP 472 session the PCE MUST clear all pending path computation requests sent 473 by the PCC in question as well as the related states. 475 In case of TCP connection failure, the PCEP session SHOULD be 476 maintained for a period of time equal to the Deadtimer. 478 6. PCEP messages 480 A PCEP message consists of a common header followed by a variable 481 length body made of a set of objects that can either be mandatory or 482 optional. In the context of this document, an object is said to be 483 mandatory in a PCEP message when the object must be included in such 484 message for the message to be valid. Conversely, an object is said to 485 be optional the object may or may not be present. As specified in 486 section 7.1, a specific flag is also defined in each object that can 487 be set by a PCEP peer to enforce a PCE to take into account the 488 related information during the path computation. For example, the 489 DELAY object allows a PCC to specify in a path computation request a 490 bounded acceptable delay for the computed path. The DELAY object is 491 optional (does not have to be present in each path computation 492 request message) but a PCC may set a flag to ensure that the delay 493 constraint is being taken into account when present in a message. 495 For each PCEP message type a set of rules is defined which specifies 496 the set of possible objects that the message can carry. We use the 497 Backus-Naur Form (BNF) to specify such rules. Square brackets refer 498 to optional sub-sequences. An implementation MUST form the PCEP 499 messages using the order specified in this document. 501 If a mandatory object is missing in a received PCEP message the 502 recipient of the PCEP message MUST trigger a protocol error 503 condition. 505 6.1. Common header 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Flags | Message-Length | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Message-Type | Reserved | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 6 - PCEP message common header 517 Ver (Version): 3 bits 519 PCEP protocol version number. The current version is version 1 521 Flags: 8 bits 523 No Flags are currently defined 525 Message Length: 24 bits 527 Total length of the PCEP message expressed in bytes including 528 the common header. 530 Message-Type: 8 bits 532 The following message types are currently defined. 534 Value Meaning 535 1 Open 536 2 Keepalive 537 3 Path Computation Request 538 4 Path Computation Reply 539 5 Notification 540 6 Error 542 6.2. Open message 544 Once the TCP connection has been successfully established, the first 545 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 546 an Open message. The aim of the Open message is to establish a PCEP 547 session between the PCEP peers. During that phase the PCEP peers 548 exchange several session characteristics. If both parties agree on 549 such characteristics the PCEP session is successfully established. 551 The Message-Type field of the PCEP common header for the Open message 552 is set to 1. 554 ::= 555 557 The Open message MUST only contain a single OPEN object defined in 558 section 7. The various session characteristics specified within the 559 OPEN object are the keepalive frequency, session mode (permanent or 560 per-request) and potentially some optional parameters such as the 561 detailed PCE capabilities and policy rules that specify the 562 conditions under which path computation requests may be sent to the 563 PCE. Details related to PCE capabilities discovery by means of PCEP 564 are out of the scope of this document. 566 Keepalive: PCEP has its own keepalive mechanism used to ensure of the 567 liveness of the PCEP session. This requires the determination of the 568 frequency at which each PCEP peer sends the keepalive messages. 569 Asymmetric values may be chosen; thus there is no constraints 570 mandating the use of identical keepalive frequencies by both PCEP 571 peers. The Deadtimer is defined as the period of time after the 572 expiration of which a PCEP peer declares the session down if no PCEP 573 message has been received (keepalive or any other PCEP message: thus, 574 any PCEP message acts as a keepalive message). The minimum Keepalive 575 value is 1 second and the Deadtimer value is equal to 4 times the 576 Keepalive value. 578 Session mode: PCEP supports two session modes referred to as the 579 "permanent" and "per-request" modes. In the permanent mode, the PCEP 580 peers maintained a permanent PCEP session (and thus the TCP session 581 is also maintained) regardless of the rate at which PCEP messages are 582 exchanged. Such mode would typically be used to speed-up response 583 times. In the permanent mode, a loss of TCP session MUST be 584 interpreted as a communication failure. Conversely, in the 585 "per-request" mode, a PCEP session is established on-demand, when one or 586 more path computation requests are required and then closed by the 587 PCC once those path computation requests are satisfied. Both PCEP 588 peers MUST agree on the session mode; in case of disagreement, the 589 PCEP session establishment fails. 591 Elements of procedure: 592 - Once an Open message has been sent to a PCEP peer, the sender MUST 593 start an initialization timer called INIT-OPEN after the expiration 594 of which a similar Open message MUST be resent if no reply has been 595 received from the PCEP peer. The INIT-OPEN timer has a fixed value of 596 one minute. The maximum number of Open messages that can be sent 597 without any response from the PCEP peer is equal to 3. 598 - Upon the receipt of an Open message, the receiving PCEP peer MUST 599 determine whether the suggested PCEP session characteristics are 600 acceptable. If one or more characteristic(s) is not acceptable by the 601 receiving peer, it MUST send a PCErr message with Error-type=8, 602 Error-value=1. The PCErr message MUST also comprise an Open object: 603 for each unacceptable session parameter, an acceptable parameter 604 value MUST be proposed in the appropriate field of the Open object in 605 place of the originally proposed value. The PCEP peer may decide to 606 resend an Open message with different session characteristics. 607 Consecutive retries SHOULD make use of exponential back-off so as to 608 avoid undesirable burden of session initialization. If a second Open 609 message is received with the same set of parameters or with 610 parameters differing from the proposed values, the receiving peer 611 MUST send a PCErr message with Error-Type=8, Error-value=2 and it 612 MUST immediately close the TCP connection. 614 If the PCEP session characteristics are acceptable, the receiving 615 PCEP peer MUST immediately send a Keepalive message as an 616 acknowledgment. 618 The PCEP session is considered as operational once both PCEP peers 619 have received a Keepalive message from their peer. 621 6.3. Keepalive message 623 Keepalive messages are used either to acknowledge an Open message if 624 the receiving PCEP peer agrees on the session characteristics and to 625 ensure the liveness of the PCEP session. Keepalive messages are sent 626 at the frequency specified in the OPEN object carried within an Open 627 message. 629 The Message-Type field of the PCEP common header for the Open message 630 is set to 2. 632 ::= 634 6.4. Path Computation Request (PCReq) message 636 A Path Computation Request message (also referred to as a PCReq 637 message) is sent by a PCC to a PCE so as to request a path 638 computation. The Message-Type field of the PCEP common header is set 639 to 3. 641 There are two mandatory objects that MUST be included within a PCReq 642 message: the RP and the END-POINTS objects (see section 7). If one of 643 these objects is missing, the receiving PCE MUST send an error 644 message to the requester (PCErr message). Other objects are optional. 646 The format of a PCReq message is as follows: 648 ::= 649 [] 650 652 where: 653 ::=[] 654 ::=[] 656 ::= 657 658 [] 659 [] 660 [] 661 [] 662 [] 664 [] 666 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, DELAY, ERO, XRO and IRO 667 objects are defined in section 7. 669 6.5. Path Computation Reply (PCRep) message 671 The PCEP Path Computation reply message (also referred to as a PCRep 672 message) is sent by a PCE to a requesting PCC in response to a 673 previously received PCReq message. The Message-Type field of the PCEP 674 common header is set to 4. 676 The PCRep message MUST comprise a RP object with a Request-ID-number 677 identical to the one specified in the RP object carried in the 678 corresponding PCReq message (see section 7 for the definition of the 679 RP object). 681 A PCRep may comprise multiple computed path(s) corresponding to 682 multiple path computation requests originated by a common requesting 683 PCC. The bundling of multiple responses within a single PCRep message 684 is supported by the PCEP protocol. If a PCE receives non-synchronized 685 path computation requests by means of one or more PCReq messages from 686 a requesting PCC it may decide to bundle the computed paths within a 687 single PCRep message so as to reduce the control plane load. Note 688 that the counter side of such an approach is the introduction of 689 additional delays for some path computation requests of the set. 691 If the path computation request can be successfully satisfied (the 692 PCE manages to compute a set of path(s) that obey the requested 693 constraint(s)), the set of computed path(s) specified by means of ERO 694 object(s) is inserted in the PCRep message. Such a situation where 695 multiple computed paths are provided in a PCRep message is discussed 696 in detail in section 8. 698 If the path computation request cannot be satisfied, the PCRep 699 message MUST include a NO-PATH object. The NO-PATH object (further 700 described in section 7) may also comprise other information (e.g 701 reasons for the path computation failure). 703 The format of a PCRep message is as follows: 705 ::= 706 [] 707 709 where: 710 ::=[] 711 ::=[] 713 ::= 714 [] 716 [] 717 [] 718 [] 719 [] 720 [] 721 [] 723 where: 724 :==[ 726 6.6. Notification (PCNtf) message 728 The PCEP Notification message (also referred to as the PCNtf message) 729 can either be sent by a PCE to a PCC or by a PCC to a PCE so as to 730 notify of a specific event. The Message-Type field of the PCEP common 731 header is set to 5. 733 The PCNtf message MUST carry at least one NOTIFICATION object and may 734 comprise several NOTIFICATION objects should the PCE or the PCC 735 intend to notify of multiple events. The NOTIFICATION object is 736 defined in section 7. The PCNtf message may also comprise an RP 737 object when the notification refers to a particular path computation 738 request. 740 The PCNtf message may be sent by a PCC or a PCE in response to a 741 request or in an unsolicited manner. 743 The format of a PCNtf message is as follows: 745 ::= 746 748 ::= [] 750 ::= [] 751 753 :== 754 := 756 The procedure upon the reception of a PCNtf message is defined in 757 section 9. 759 6.7. Error (PCErr) message 761 The PCEP Error message (also referred to as a PCErr message) is sent 762 when a protocol error condition is met. The Message-Type field of the 763 PCEP common header is set to 6. 765 The PCErr message may be sent by a PCC or a PCE in response to a 766 request or in an unsolicited manner. In the former case, the PCErr 767 message MUST include the set of RP objects related to the pending 768 path computation request(s) which triggered the protocol error 769 condition. In the later case (unsolicited), no RP object is inserted 770 within the PCErr message. No RP object is inserted in a PCErr when 771 the error condition occurred during the initialization phase. A PCErr 772 message MUST comprise a PCEP-ERROR object specifying the PCEP error 773 condition. The PCEP-ERROR object is defined in section 7. 775 The format of a PCErr message is as follows: 777 ::= 778 779 [] 781 :==[] 782 ::=[] 783 785 :==[] 786 :==[] 788 The procedure upon the reception of a PCErr message is defined in 789 section 9. 791 7. Object Formats 793 7.1. Common object header 795 A PCEP object carried within a PCEP message consists of one or more 796 32-bit words with a common header which has the following format: 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Object-Class | OT |Res|I|P| Object Length (bytes) | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | | 804 // (Object body) // 805 | | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Figure 8 - PCEP common object header 810 Object-Class (to be managed by IANA) 812 8-bit field that identifies the PCEP object class 814 OT (Object-Type) (to be managed by IANA) 816 4-bit field that identifies the PCEP object type 818 P flag (Processing-Rule) 819 1-bit flag which specifies whether the object must be taken into 820 account by the receiving PCEP peer or is just optional. When the P 821 flag is cleared, the object MUST be taken into account by the 822 receiving entity. If the PCC or the PCE does not understand the 823 object or understands the object but decides to ignore the object, 824 this MUST trigger a protocol error condition as defined in section 825 7. Conversely, when the P flag is set the object is optional and 826 can be silently ignored. 828 I flag 830 1-bit flag: the PCE set the I flag when the object is carried 831 within a PCRep message so as to indicate when the constraint was 832 optional and was ignored during path computation. 834 Res flags: 2-bit flag reserved (MUST be set to 0) 836 Object Length 838 16-bit field containing the total object length in bytes. The 839 Object Length field MUST always be a multiple of 4, and at least 840 4. 842 The maximum object content length is 65528 bytes. The Object-Class 843 and Object-Type fields uniquely identify each PCEP object. 845 The P bit is used to determine what action a node should take if it 846 does not recognize the Object-Class or Object-Type of a PCEP object 847 or decides not to take into account the object: there are two 848 possible ways a PCEP implementation can react. This choice is 849 determined by the P bit, as follows. 851 If P flag=0 853 The entire PCEP message MUST be rejected and the receiving PCEP peer 854 MUST send a PCErr message with a PCEP-ERROR Object ("Unkown Object" 855 or "Not supported Object"). 857 If P flag=1 859 The node MAY ignore the object and process the PCEP message if 860 possible. In that case (the message can be processed by ignoring the 861 object in question), the PCE SHOULD include the object in the 862 corresponding PCERep message. The I flag of the common header for 863 this object MUST be set. If the path computation cannot be performed, 864 a PCErr message MUST be sent to the requesting entity with a PCEP- 865 ERROR object (Error-type=2, "Unknown Object"). 867 7.2. OPEN Object 869 The OPEN object MUST be present in each Open message. There MUST be 870 only one OPEN object per Open message. 872 The OPEN object contains a set of fields used to specify the PCEP 873 protocol version, Keepalive frequency, PCEP session ID along with 874 various flags. The OPEN object may also contain a set of TLVs used to 875 convey various session characteristics such as the detailed PCE 876 capability, policy rules and so on. No TLV is currently defined. 878 OPEN Object-Class is to be assigned by IANA (recommended value=1) 879 OPEN Object-Type is to be assigned by IANA (recommended value=1) 881 The format of the OPEN object body is as follows: 883 0 1 2 3 884 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 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Ver | Keepalive | SID | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Reserved | |R| 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | | 891 // Optional TLV(s) // 892 | | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 Figure 9 - OPEN Object format 897 Version (Ver): 3 bits - Current version is 1. 899 Keepalive frequency (Keepalive): 16 bits. 901 Specifies the frequency in seconds at which the sender of the 902 Open message will send Keepalive messages. The minimum value for 903 the Keepalive is 1 second. When set to 0, no keepalive is sent 904 to the remote peer. A RECOMMENDED value for the keepalive 905 frequency is 30 seconds. 907 PCEP session-ID (SID): 13 bits. 908 Specifies a 2 octet unsigned PCEP session number that identifies 909 the current session. The SID MUST be incremented each time a new 910 PCEP session is established. 912 Flags 914 One flag is currently defined. 916 R flag: when cleared, this indicates that the sending PCEP peer 917 requires the establishment of a PCEP session in permanent mode. 918 When set, a per-request mode is requested. 920 Optional TLVs may be included within the Open message body to specify 921 PCC or PCE characteristics. 923 7.3. RP Object 925 The RP (Request Parameters) object MUST be carried within every PCReq 926 and PCRep messages and MAY be carried within PCNtf and PCErr 927 messages. 929 RP Object-Class is to be assigned by IANA (recommended value=2) 930 RP Object-Type is to be assigned by IANA (recommended value=1) 932 The format of the RP object body is as follows: 934 0 1 2 3 935 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 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Reserved | Flags |O|C|B|R| Pri | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Request-ID-number | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 // // 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Figure 10 - RP object body format 946 The RP object has a variable length and may contain additional TLVs. 947 No TLV is currently defined. 949 Flags: 18 bits - The following flags are currently defined: 951 Pri (Priority) field (3 bits) 953 This field may be used by the requesting PCC to specify to the 954 PCE the request's priority. The decision of which priority 955 should be used for a specific request is of a local matter and 956 MUST be set to 0 when unused. Furthermore, the use of the path 957 computation request priority by the PCE's requests scheduler is 958 implementation specific and out of the scope of this document. 959 Note that it is not required for a PCE to support the priority 960 field: in that case, the priority field SHOULD be set to 0 by 961 the PCC in the RP object. If the PCE does not take into account 962 the request priority, it is RECOMMENDED to set the priority 963 field to 0 in the RP object carried within the corresponding 964 PCRep message, regardless of the priority value contained in the 965 RP object carried within the corresponding PCReq message. A 966 higher numerical value of the priority field reflects a higher 967 priority. Note that it is the responsibility of the network 968 administrator to make use of the priority values in a consistent 969 manner across the various PCC(s). The ability of a PCE to 970 support requests prioritization may be dynamically discovered by 971 the PCC(s) by means of PCE capability discovery. If not 972 advertised by the PCE, a PCC may decide to set the request 973 priority and will learn the ability of the PCE the support 974 request prioritization by observing the Priority field of the RP 975 object received in the PCRep message. If the value of the Pri 976 field is set to 0, this means that the PCE does not support the 977 Pri field: in other words, the path computation request has been 978 honoured but without taking the request priority into account. 980 R (Reoptimization) bit: when set, the requesting PCC specifies 981 that the PCReq message relates to the reoptimization of an 982 existing TE LSP in which case the path of the existing TE LSP to 983 be reoptimized MUST be provided in the PCReq message by means of 984 an RRO object defined in section 7. 986 B (Bi-directional) bit: when set, the PCC specifies that the 987 path computation request relates to a bidirectional TE LSP (LSPs 988 that have the same traffic engineering requirements including 989 fate sharing, protection and restoration, LSRs, and resource 990 requirements (e.g., latency and jitter) in each direction). When 991 cleared, the TE LSP is unidirectional. 993 C (Cost) bit: when set, the PCE MUST provide the cost of the 994 computed path in the PCRep message. 996 O (strict/lOose): In a PCReq message, when set, this means that 997 a strict/loose path is acceptable. Otherwise, when cleared, this 998 indicates to the PCE that an explicit path is required. In a 999 PCRep message, when the O bit is set this indicates that the 1000 returned path is strict/loose, otherwise (the O bit is cleared), 1001 the returned path is explicit. 1003 Request-ID-number: 32 bits 1005 This value (combined with the source IP address of the PCC) 1006 uniquely identifies the path computation request context and 1007 MUST be incremented each time a new request is sent to the PCE. 1008 If no path computation reply is received from the PCE, and the 1009 PCC wishes to resend its request, the same Request-ID-number 1010 MUST be used. Conversely, different Request-ID-number MUST be 1011 used for different requests sent to a PCE. The same Request-ID- 1012 number may be used for path computation requests sent to 1013 different PCEs. The path computation reply is unambiguously 1014 identified by the IP source address of the replying PCE. 1016 7.4. NO-PATH Object 1018 When a PCE cannot find a path satisfying a set of constraints, it 1019 MUST include a NO-PATH object in the corresponding PCRep message. In 1020 its simplest form, the NO-PATH object is limited to a set of flags 1021 and just reports the impossibility to find a path that satisfies the 1022 set of constraints. Optionally, if the PCE supports such capability, 1023 the PCRep message MAY also comprise a list of objects that specify 1024 the set of constraints that could not be satisfied. When an object 1025 specifies a variety of constraints, the set of unsatisfied 1026 constraints can be unambiguously determined by the PCC after a simple 1027 comparison with the original requested constraints. 1029 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1030 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1032 The format of the NO-PATH object body is as follows: 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 |C|S| Flags | Reserved | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 Figure 11 - NO-PATH object format 1042 The NO-PATH object has a fixed length of 4 octets. 1044 Flags: 16 bits - The following flags are currently defined: 1046 C bit: when set, this indicates that the set of unsatisfied 1047 constraints (reasons why a path could not be found) is specified in 1048 the PCRep message by means of the relevant PCEP objects. When 1049 cleared, no reason is specified. 1051 For example, consider the case of a PCC that sends a path computation 1052 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1053 find a path for X MBits/s. In this case, the PCE includes in its path 1054 computation reply a NO-PATH object with the C flag set. In addition, 1055 the PCRep message carries the BANDWIDTH object and the bandwidth 1056 field value is equal to X. 1058 When the NO-PATH object is absent from a PCRep message, the path 1059 computation request has been fully satisfied and the corresponding 1060 path(s) is/are provided in the PCRep message. 1062 7.5. END-POINTS Object 1064 The END-POINTS object is used in a PCReq message to specify the 1065 source IP address and the destination IP address of the TE LSP for 1066 which a path computation is requested. Two END-POINTS objects (for 1067 IPv4 and IPv6) are defined. 1069 END-POINTS Object-Class is to be assigned by IANA (recommended 1070 value=4) 1071 END-POINTS Object-Type is to be assigned by IANA (recommended 1072 value=1 for IPv4 and 2 for IPv6) 1073 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1074 as follows: 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Source IPv4 address | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Destination IPv4 address | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 Figure 12 - END-POINTS object body format for IPv4 1086 The format of the END-POINTS object for IPv6 (Object-Type=2) is as 1087 follows: 1089 0 1 2 3 1090 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 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | | 1093 | Source IPv6 address (16 bytes) | 1094 | | 1095 | | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | | 1098 | Destination IPv6 address (16 bytes) | 1099 | | 1100 | | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 Figure 13 - END-POINTS object body format for IPv6 1105 7.6. BANDWIDTH object 1107 The BANDWIDTH object is optional and can be used to specify the 1108 requested bandwidth and may be carried within PCReq and PCRep 1109 messages. The absence of the BANDWIDTH object MUST be interpreted by 1110 the PCE as a path computation request related to a 0 bandwidth TE 1111 LSP. 1113 When carried within a PCReq message, the BANDWIDTH object specifies a 1114 bandwidth constraint that must be satisfied by the computed path(s) 1115 if P flag is cleared and MAY be ignored if the P flag is set. In a 1116 PCRep message, the BANDWIDTH object indicates that the bandwidth 1117 belong to the set of one or more constraint(s) that could be not 1118 satisfied. When absent from the PCRep message that means that the 1119 computed path satisfies the requested bandwidth constraint. 1121 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1122 value=5) 1123 BANDWIDTH Object-Type is to be assigned by IANA (recommended 1124 value=1) 1125 The format of the BANDWIDTH object body is as follows: 1127 0 1 2 3 1128 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 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | BANDWIDTH | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 Figure 14 - BANDWIDTH object body format 1135 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1136 IEEE floating point format, expressed in bytes per second. 1138 7.7. DELAY Object 1140 The DELAY object can be used to specify a strict delay constraint for 1141 the TE LSP. The delay constraint MUST be taken into account during 1142 path computation if P flag is cleared and MAY be ignored if the P 1143 flag is set. Note that the mechanism used by the PCE to retrieve the 1144 delays of each link is outside of the scope of this document (for the 1145 sake of illustration the link delay could be the IGP metric or a 1146 Service Provider may choose to use the TE metric to represent link 1147 delays). It must be understood that such path metric is only 1148 meaningful if used consistently: for instance, if the delay of a path 1149 computation segment is exchanged between two PCE residing in 1150 different domains, consistent ways of defining the delay must be 1151 used. The delay metric may be carried within PCReq and PCRep 1152 messages. The absence of the DELAY object MUST be interpreted by the 1153 PCE as a path computation request without delay constraint. When 1154 carried within a PCReq message, the DELAY object specifies a delay 1155 constraint that must be satisfied by the computed path(s). In a PCRep 1156 message and when the path computation was successful, the DELAY 1157 object indicates the delay(s) of the computed path(s). When the path 1158 computation was unsuccessful and the delay constraint was one of the 1159 mandatory constraints that could be satisfied the DELAY object MUST 1160 be present in the PCRep message. 1162 DELAY Object-Class is to be assigned by IANA (recommended value=6) 1163 DELAY Object-Type is to be assigned by IANA (recommended value=1) 1165 The format of the DELAY object body is as follows: 1167 0 1 2 3 1168 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 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | Delay | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 Figure 15 - DELAY object body format 1175 Delay: 32 bits. The requested delay constraint is encoded in 32 bits 1176 in IEEE floating point format, expressed in milliseconds. 1178 7.8. ERO Object 1180 The ERO object is used to encode a TE LSP path. If can either be 1181 carried within a PCReq message to specify the existing path of a TE 1182 LSP to be reoptimize or within a PCRep message to provide a computed 1183 TE LSP. 1185 The contents of this object are identical in encoding to the contents 1186 of the Explicit Route Object defined in [RSPV-TE], [GRSVP] and [RSVP- 1187 UNNUM]. That is, the object is constructed from a series of sub- 1188 objects. Any RSVP ERO sub-object already defined or that could be 1189 defined in the future for use in the ERO is acceptable in this 1190 object. 1192 PCEP ERO sub-object types correspond to RSVP ERO sub-object types. 1194 Since the explicit path is available for immediate signaling by the 1195 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1196 and fields in this object are identical to those defined for the ERO. 1198 ERO Object-Class is to be assigned by IANA (recommended value=7) 1199 ERO Object-Type is to be assigned by IANA (recommended value=1) 1201 7.9. RRO Object 1203 The RRO object is used to record the route followed by a TE LSP. The 1204 PCEP RRO object is exclusively carried within a PCReq message so as 1205 to specify the route followed by a TE LSP for which a reoptimization 1206 is desired. 1208 The contents of this object are identical in encoding to the contents 1209 of the Route Record Object defined in [RSPV-TE], [G-RSVP] and [RSVP- 1210 UNNUM]. That is, the object is constructed from a series of sub- 1211 objects. Any RSVP RRO sub-object already defined or that could be 1212 defined in the future for use in the RRO is acceptable in this 1213 object. 1215 The meanings of all of the sub-objects and fields in this object are 1216 identical to those defined for the RRO. 1218 PCEP RRO sub-object types correspond to RSVP RRO sub-object types. 1220 RRO Object-Class is to be assigned by IANA (recommended value=8) 1221 RRO Object-Type is to be assigned by IANA (recommended value=1) 1223 7.10. LSPA Object 1225 The LSPA object specifies various TE LSP attributes to be taken into 1226 account by the PCE during path computation. The LSPA (LSP Attributes) 1227 object can either be carried within a PCReq message or a PCRep 1228 message in case of unsuccessful path computation (in this case, the 1229 PCReq message also comprises a NO-PATH object and the LSPA object is 1230 used to indicate the set of constraint(s) that could not be 1231 satisfied). Most of the fields of the LSPA object are identical to 1232 the fields of the SESSION-ATTRIBUTE object defined in [RSVP-TE] and 1233 [FRR]. 1235 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1237 Two Objects-Types are defined for the LSPA object: LSPA without 1238 resource affinity (Object-Type to be assigned by IANA with 1239 recommended value=1) and LSPA with resource affinity (Object-type=2). 1241 The format of the LSPA object body with and without resource affinity 1242 are as follows: 1244 0 1 2 3 1245 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 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Setup Prio | Holding Prio | Flags |N|B|L| Reserved | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | | 1250 // Optional TLV(s) // 1251 | | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 Figure 16 - LSPA object body format (without resource affinity) 1256 0 1 2 3 1257 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 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Exclude-any | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Include-any | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Include-all | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Setup Prio | Holding Prio | Flags |N|B|L| Reserved | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | | 1268 // Optional TLV(s) // 1269 | | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 Figure 17 - LSPA object body format (with resource affinity) 1274 Setup Priority (8 bits) 1276 The priority of the session with respect to taking resources, 1277 in the range of 0 to 7. The value 0 is the highest priority. 1278 The Setup Priority is used in deciding whether this session can 1279 preempt another session. 1281 Holding Priority 1283 The priority of the session with respect to holding resources, 1284 in the range of 0 to 7. The value 0 is the highest priority. 1285 Holding Priority is used in deciding whether this session can 1286 be preempted by another session. 1288 Flags 1290 The flags L, B and N correspond to the "Local protection desired" 1291 bit ([RSVP-TE]), "Bandwidth protection desired" bit ([FRR]) and 1292 the "Node protection desired" bit ([FRR]) of the SESSION-ATTRIBUTE Object 1293 respectively. 1295 L Flag (Local protection desired) 1297 When set, this means that the computed path MUST included links 1298 protected with Fast Reroute as defined in [FRR]. 1300 B Flag (Bandwidth protection desired) 1302 When set, this means that the computed path MUST included links 1303 protected with Fast Reroute as defined in [FRR] and that benefit 1304 from bandwidth protection. The B flag MUST only be set if the L 1305 flag is set. 1307 N Flag (Node protection desired) 1309 When set, this means that the computed path MUST included links 1310 protected with Fast Reroute as defined in [FRR] and that such 1311 links MUST be protected with NNOP (Next-next hop backup tunnel). 1312 The N flag MUST only be set of the L flag is set. 1314 Note that the B flag and N flag are not exclusive. 1316 7.11. IRO Object 1318 The IRO (Include Route Object) object is optional and can be used to 1319 specify that the computed path must traverse a set of specified 1320 network elements. The IRO object may be carried within PCReq and 1321 PCRep messages. 1323 IRO Object-Class is to be assigned by IANA (recommended value=10) 1324 IRO Object-Type is to be assigned by IANA (recommended value=1) 1326 0 1327 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 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | | 1330 // (subobjects) | 1331 | | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 Figure 18 - IRO objet body format 1336 Subobjects 1338 The IRO object is made of sub-object(s) identical to the ones defined 1339 in [RSVP-TE], [G-MPLS] and [RSVP-UNNUM] for use in EROs. 1341 The following subobject types are supported: 1343 Type Subobject 1344 1 IPv4 prefix 1345 2 IPv6 prefix 1346 4 Unnumbered interface ID 1347 32 Autonomous system number 1349 The L bit of such sub-object has no meaning within an IRO object. 1351 The ERO object carried within a PCReq message is exclusively used in 1352 the context of a reoptimization path computation request, thus the 1353 need to define a new object (IRO) to specify the inclusion of 1354 specified network element(s) in a path. 1356 7.12. SVEC Object 1358 Section 8 details the circumstances under which it may be desirable 1359 and/or required to correlate several path computation requests. This 1360 leads to the specification of the SVEC object (Synchronization 1361 VECtor). The SVEC object is optional in a PCEP message. 1363 The aim of the SVEC object carried within a PCReq message is to 1364 specify the correlation of M path computation requests. The SVEC 1365 object is a variable length object that lists the set of M requests 1366 the computation of which MUST be synchronized. Each path computation 1367 request is uniquely identified by the Request-ID-number carried 1368 within the respective RP object. The SVEC object also contains a set 1369 of flags that specify the synchronization type. 1371 The SVEC object is carried within PCReq messages. 1373 SVEC Object-Class is to be assigned by IANA (recommended value=11) 1374 SVEC Object-Type is to be assigned by IANA (recommended value=1) 1376 One Object-Type is defined for this object to be assigned by IANA 1377 with a recommended value of 1. 1379 The format of the SVEC object body is as follows: 1381 0 1 2 3 1382 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 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | Reserved | Flags |S|N|L| 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | RP Object #1 | 1387 | | 1388 // // 1389 | RP Object #M | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 Figure 19 - SVEC body object format 1394 Flags 1396 Defines the synchronization type between multiple path computation 1397 requests. 1399 L (Link diverse) bit: when set, this indicates that the computed 1400 paths corresponding to the requests specified by the following RP 1401 objects MUST not have any link in common. 1403 N (Node diverse) bit: when set, this indicates that the computed 1404 paths corresponding to the requests specified by the following RP 1405 objects MUST not have any node in common. 1407 S (SRLG diverse) bit: when set, this indicates that the computed 1408 paths corresponding to the requests specified by the following RP 1409 objects MUST not share any SRLG (Shared Risk Link Group). 1411 The flags defined above are not exclusive. 1413 7.13. NOTIFICATION object 1415 The NOTIFICATION object is exclusively carried within a PCNtf message 1416 and can either be used in a message sent by a PCC to a PCE or by a 1417 PCE to a PCC so as to notify of an event. 1419 NOTIFICATION Object-Class is to be assigned by IANA (recommended 1420 value=12) 1421 NOTIFICATION Object-Type is to be assigned by IANA (recommended 1422 value=1) 1424 One Object-Type is defined for this object to be assigned by IANA 1425 with a recommended value of 1. 1427 The format of the NOTIFICATION body object is as follows: 1429 0 1 2 3 1430 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 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Length | Flags | Notification- | Notification- | 1433 | | | type | value | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | | 1436 // Optional TLV(s) // 1437 | | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 Figure 20 - NOTIFICATION body object format 1442 Length 1444 The Length contains the total length of the object in bytes and 1445 includes the Type and Length fields. This length must be a 1446 multiple of 4 and must be at least 12. 1448 Flags 1450 No flags are currently defined 1452 A NOTIFICATION object is characterized by a Notification-type that 1453 specifies the class of notification and the Notification-value that 1454 provides additional information related to the nature of the 1455 notification. Both the Notification-type and Notification-value 1456 should be managed by IANA (see IANA section). 1458 The following Notification-type and Notification-value values are 1459 currently defined: 1461 Notification-type=1: Pending Request cancelled 1463 Notification-value=1: PCC cancels a set of pending request(s) 1465 A Notification-type=1, Notification-value=1 indicates that the 1466 PCC wants to inform a PCE of the cancellation of a set of 1467 pending request(s). Such event could be triggered because of 1468 external conditions such as the receipt of a positive reply from 1469 another PCE (should the PCC have sent multiple requests to a set 1470 of PCEs for the same path computation request), a network event 1471 such as a network failure rendering the request obsolete or any 1472 other event(s) local to the PCC. A NOTIFICATION object with 1473 Notification-type=1, Notification-value=1 is exclusively carried 1474 within a PCNtf message sent by the PCC to the PCE. The RP object 1475 MUST also be present in the PCNtf message. Multiple RP objects 1476 may be carried within the PCNtf message in which case the 1477 notification applies to all of them. If such notification is 1478 received by a PCC from a PCE, the PCC MUST silently ignore the 1479 notification and no errors should be generated. 1481 Notification-value=2: PCE cancels a set of pending request(s) 1483 A Notification-type=1, Notification-value=2 indicates that the 1484 PCE wants to inform a PCC of the cancellation of a set of 1485 pending request(s). Such event could be triggered because of 1486 some PCE congested state or because of some path computation 1487 requests that are part the set of synchronized path computation 1488 requests are missing. A NOTIFICATION object with Notification- 1489 type=1, Notification-value=2 is exclusively carried within a 1490 PCNtf message sent by a PCE to a PCC. The RP object MUST also be 1491 present in the PCNtf message. Multiple RP objects may be 1492 comprised within the PCNtf message in which case the 1493 notification applies to all of them. If such notification is 1494 received by a PCE from a PCC, the PCE MUST silently ignore the 1495 notification and no errors should be generated. 1497 Notification-type=2: PCE congestion 1499 Notification-value=1 1501 A Notification-type=2, Notification-value=1 indicates to the 1502 PCC(s) that the PCE is currently in a congested state. If no RP 1503 objects are comprised in the PCNtf message, this indicates that 1504 no other requests SHOULD be sent to that PCE until the congested 1505 state is cleared: the pending requests are not affected and will 1506 be served. If some pending requests cannot be served due to the 1507 congested state, the PCE MUST also include a set of RP object(s) 1508 that identifies the set of pending requests which will not be 1509 honored and which will be cancelled by the PCE. In this case, 1510 the PCE does not have to send an additional PCNtf message with 1511 Notification-type=1 and Notification-value=2 since the list of 1512 cancelled requests is specified by including the corresponding 1513 set of RP object(s). If such notification is received by a PCE 1514 from a PCC, the PCE MUST silently ignore the notification and no 1515 errors should be generated. 1517 Optionally, a TLV named CONGESTION-DURATION may be included in 1518 the NOTIFICATION object that specifies the duration during which 1519 no further request should be sent to the PCE. Once this period 1520 has expired the PCE should no longer be considered in congested 1521 state. 1523 The CONGESTION-DURATION TLV is composed of 1 octet for the type, 1524 1 octet specifying the number of bytes in the value field 1525 followed by a fix length value field of 4 octets specifying the 1526 estimated PCE congestion duration in seconds. The CONGESTION- 1527 DURATION TLV is padded to eight-octet alignment 1529 TYPE: To be assigned by IANA 1530 LENGTH: 4 1531 VALUE: estimated congestion duration in seconds 1533 Notification-value=2 1535 A Notification-type=2, Notification-value=2 indicates that the 1536 PCE is no longer in congested state and is available to process 1537 new path computation requests. An implementation MUST make sure 1538 that a PCE sends such notification to every PCC to which a 1539 Notification message (with Notification-type=2, Notification- 1540 value=1) has been sent unless a CONGESTION-DURATION TLV has been 1541 included in the corresponding message and the PCE wishes to wait 1542 for the expiration of that period of time before receiving new 1543 requests. An implementation may decide to cancel such 1544 notification if the PCC is in down state for a specific period. 1545 A RECOMMENDED value for such delay is 1 hour. If such 1546 notification is received by a PCE from a PCC, the PCE MUST 1547 silently ignore the notification and no errors should be 1548 generated. 1550 It is RECOMMENDED to support some dampening notification procedure on 1551 the PCE so as to avoid too frequent congestion notifications and 1552 releases. For example, an implementation could make use of an 1553 hysteresis approach using a dual-thresholds mechanism triggering the 1554 sending of congestion notifications and releases. Furthermore, in 1555 case of high instabilities of the PCE resources, an additional 1556 dampening mechanism SHOULD be used (linear or exponential) to pace 1557 the notification frequency and avoid path computation requests 1558 oscillation. 1560 7.14. PCEP-ERROR object 1562 The PCEP-ERROR object is exclusively carried within a PCErr message 1563 and can either be used in a message sent by a PCC to a PCE or by a 1564 PCE to a PCC to notify of a PCEP protocol error. 1566 PCEP-ERROR Object-Class is to be assigned by IANA (recommended 1567 value=13) 1568 PCEP-ERROR Object-Type is to be assigned by IANA (recommended 1569 value=1) 1571 One Object-Type is defined for this object to be assigned by IANA 1572 with a recommended value of 1. 1574 The format of the PCEP-ERROR object body is as follows: 1576 0 1 2 3 1577 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 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | Length | Flags | Error-Type | Error-Value | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | | 1582 // Optional TLV(s) // 1583 | | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 Figure 21 - PCEP-ERROR object body format 1588 A PCEP-ERROR object is used to report a PCEP protocol error and is 1589 characterized by an Error-Type that specifies the type of error and 1590 an Error-value that provides additional information about the error 1591 type. Both the Error-Type and the Error-Value should be managed by 1592 IANA (see the IANA section). 1594 Length (8 bits) 1596 The Length contains the total length of the object in bytes 1597 including the Type and Length fields. This length must be a 1598 multiple of 4 and must be at least 8. 1600 Flags (8 bits) 1602 No flag is currently defined. 1604 Error-type (8 bits) 1606 The Error-type defines the class of error. 1608 Error-value (8 bits) 1610 Provides additional details about the error. 1612 Optionally the PCErr message may contain additional TLV so as to 1613 provide further information about the encountered error. No TLV is 1614 currently defined. 1616 A single PCErr message may contain multiple PCEP-ERROR objects. 1618 For each PCEP protocol error, an Error type and value is defined. 1620 Error-Type Meaning 1621 1 Capability not supported 1622 2 Unknown Object 1623 Error-value=1: Unrecognized object class 1624 Error-value=2: Unrecognized object Type 1625 3 Not supported object 1626 Error-value=1: Not supported object class 1627 Error-value=2: Not supported object Type 1628 4 Policy violation 1629 Error-value=1: C bit set (request rejected) 1630 Error-value=2: O bit set (request rejected) 1631 5 Required Object missing 1632 Error-value=1: RP object missing 1633 Error-value=2: RRO object missing for a reoptimization 1634 request (R bit of the RP object set) 1635 Error-value=3: END-POINTS object missing 1636 6 Synchronized path computation request missing 1637 7 Unknown request reference 1638 8 Unacceptable PCEP session characteristics 1639 Error-value=1: parameter negotiation 1640 Error-value=2: parameters negotiation failed 1641 9 Deadtimer expired 1643 In case of the Error-Type 1, the PCE indicates that the path 1644 computation request cannot be completed because it does not support 1645 one or more required capability. The corresponding path computation 1646 request MUST then be cancelled. 1648 If a PCEP message is received that carries a mandatory PCEP object (P 1649 flag cleared) not recognized by the PCEP peer or recognized but not 1650 supported, then the PCEP peer MUST send a PCErr message with a PCEP- 1651 ERROR object (Error-Type=2 and 3 respectively). The corresponding 1652 path computation request MUST be cancelled by the PCE without further 1653 notification. 1655 If a path computation request is received which is not compliant with 1656 an agreed policy between the PCC and the PCE, the PCE MUST send a 1657 PCErr message with a PCEP-ERROR object (Error-Type=4). The 1658 corresponding path computation MUST be cancelled. 1660 If a path computation request is received that does not contain a 1661 required object, the PCE MUST send a PCErr message with a PCEP-ERROR 1662 object (Error-Type=5). If there are multiple mandatory objects 1663 missing, the PCErr message MUST contain one PCEP-ERROR object per 1664 missing object. The corresponding path computation MUST be cancelled. 1666 If a PCC sends a synchronized path computation request to a PCE and 1667 the PCE does not receive all the synchronized path computation 1668 requests listed within the corresponding SVEC object during a 1669 configurable period of time, the PCE MUST send a PCErr message with a 1670 PCEP-ERROR object (Error-Type=6). The corresponding synchronized path 1671 computation MUST be cancelled. 1673 If a PCC receives a PCRep message related to an unknown path 1674 computation request, the PCC MUST send a PCErr message with a PCEP- 1675 ERROR object (Error-Type=6). In addition, the PCC MUST include in the 1676 PCErr message the unknown RP object. 1678 If one or more characteristic(s) is not acceptable by the receiving 1679 peer, it MUST send a PCErr message with Error-type=8, Error-value=1. 1680 The PCErr message MUST also comprise an Open object: for each 1681 unacceptable session parameter, an acceptable parameter value MUST be 1682 proposed in the appropriate field of the Open object in place of the 1683 originally proposed value. If a second Open message is received with 1684 the same set of parameters or with parameters differing from the 1685 proposed values, the receiving peer MUST send a PCErr message with 1686 Error-Type=8, Error-value=2 and it MUST immediately close the TCP 1687 connection. 1689 If a PCEP peer does not receive any PCEP message (Keepalive, PCReq, 1690 PCRep, PCNtf) during the Deadtimer period (equal to four times the 1691 Keepalive value advertised in the OPEN object) the PCEP peer MUST 1692 send a PCErr message with a PCEP-ERROR object (Error-type=9, Error- 1693 value=1). Additionally, the PCEP session MUST be terminated and the 1694 TCP connection MUST be closed. 1696 8. Independent versus synchronized path computation requests 1698 The PCEP protocol permits the bundling of multiple independent path 1699 computation requests within a single PCRep message. A set of path 1700 computation requests is said to be non synchronized if their 1701 respective treatment (path computations) can be performed by a PCE in 1702 a serialized and independent fashion. 1704 There are various circumstances where the synchronization of a set of 1705 path computations may be beneficial or required. 1707 Consider the case of a set of N TE LSPs for which a PCC needs to send 1708 path computation requests to a PCE so as to obtain their respective 1709 paths. The first solution consists of sending N separate PCReq 1710 messages to the selected PCE. In this case, the path computation 1711 requests are independent. Note that the PCC may chose to distribute 1712 the set of N requests across K PCEs for load balancing reasons. 1713 Considering that M (with M