idnits 2.17.1 draft-ietf-pce-pcep-19.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 3909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3933. 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 (November 17, 2008) is 5629 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: 'IEEE.754.1985' is mentioned on line 3539, but not defined == Unused Reference: 'RFC1321' is defined on line 3461, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-09) exists of draft-farrel-rtg-common-bnf-07 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-04 == Outdated reference: A later version (-15) exists of draft-ietf-pce-inter-layer-req-08 == Outdated reference: A later version (-11) exists of draft-ietf-pce-manageability-requirements-05 == Outdated reference: A later version (-09) exists of draft-ietf-pce-monitoring-03 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-02 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4420 (Obsoleted by RFC 5420) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems 3 Intended status: Standards Track JL. Le Roux, Ed. 4 Expires: May 21, 2009 France Telecom 5 November 17, 2008 7 Path Computation Element (PCE) Communication Protocol (PCEP) 8 draft-ietf-pce-pcep-19.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 May 21, 2009. 35 Abstract 37 This document specifies the Path Computation Element Communication 38 Protocol (PCEP) for communications between a Path Computation Client 39 (PCC) and a Path Computation Element (PCE), or between two PCEs. 40 Such interactions include path computation requests and path 41 computation replies as well as notifications of specific states 42 related to the use of a PCE in the context of Multiprotocol Label 43 Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP 44 is designed to be flexible and extensible so as to easily allow for 45 the addition of further messages and objects, should further 46 requirements be expressed in the future. 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Architectural Protocol Overview (Model) . . . . . . . . . . . 7 60 4.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Architectural Protocol Overview . . . . . . . . . . . . . 7 62 4.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 8 63 4.2.2. Session Keepalive . . . . . . . . . . . . . . . . . . 9 64 4.2.3. Path Computation Request Sent By a PCC to a PCE . . . 10 65 4.2.4. Path Computation Reply Sent By The PCE to a PCC . . . 11 66 4.2.5. Notification . . . . . . . . . . . . . . . . . . . . . 13 67 4.2.6. Error . . . . . . . . . . . . . . . . . . . . . . . . 15 68 4.2.7. Termination of the PCEP Session . . . . . . . . . . . 15 69 4.2.8. Intermitent versus Permanent PCEP Session . . . . . . 16 70 5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 16 71 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 16 72 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 17 73 6.2. Open Message . . . . . . . . . . . . . . . . . . . . . . . 17 74 6.3. Keepalive Message . . . . . . . . . . . . . . . . . . . . 19 75 6.4. Path Computation Request (PCReq) Message . . . . . . . . . 20 76 6.5. Path Computation Reply (PCRep) Message . . . . . . . . . . 21 77 6.6. Notification (PCNtf) Message . . . . . . . . . . . . . . . 22 78 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 23 79 6.8. Close Message . . . . . . . . . . . . . . . . . . . . . . 24 80 6.9. Reception of Unknown Messages . . . . . . . . . . . . . . 24 81 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 24 82 7.1. PCE TLV Format . . . . . . . . . . . . . . . . . . . . . . 24 83 7.2. Common Object Header . . . . . . . . . . . . . . . . . . . 25 84 7.3. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 26 85 7.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 28 86 7.4.1. Object Definition . . . . . . . . . . . . . . . . . . 28 87 7.4.2. Handling of the RP Object . . . . . . . . . . . . . . 31 88 7.5. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 32 89 7.6. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 35 90 7.7. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 36 91 7.8. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 37 92 7.9. Explicit Route Object . . . . . . . . . . . . . . . . . . 40 93 7.10. Reported Route Object . . . . . . . . . . . . . . . . . . 41 94 7.11. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 41 95 7.12. Include Route Object Object . . . . . . . . . . . . . . . 43 96 7.13. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 43 97 7.13.1. Notion of Dependent and Synchronized Path 98 Computation Requests . . . . . . . . . . . . . . . . . 43 99 7.13.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 45 100 7.13.3. Handling of the SVEC Object . . . . . . . . . . . . . 46 101 7.14. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 47 102 7.15. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 50 103 7.16. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 54 104 7.17. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 55 105 8. Manageability Considerations . . . . . . . . . . . . . . . . . 56 106 8.1. Control of Function and Policy . . . . . . . . . . . . . . 57 107 8.2. Information and Data Models . . . . . . . . . . . . . . . 58 108 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 58 109 8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 58 110 8.5. Requirements on Other Protocols and Functional 111 Components . . . . . . . . . . . . . . . . . . . . . . . . 59 112 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 59 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 114 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 60 115 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 60 116 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 60 117 9.4. PCEP Message Common Header . . . . . . . . . . . . . . . . 61 118 9.5. Open Object Flag Field . . . . . . . . . . . . . . . . . . 62 119 9.6. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 62 120 9.7. NO-PATH Object Flag Field . . . . . . . . . . . . . . . . 63 121 9.8. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 63 122 9.9. LSPA Object Flag Field . . . . . . . . . . . . . . . . . . 64 123 9.10. SVEC Object Flag Field . . . . . . . . . . . . . . . . . . 65 124 9.11. Notification Object . . . . . . . . . . . . . . . . . . . 65 125 9.12. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 66 126 9.13. LOAD-BALANCING Object Flag Field . . . . . . . . . . . . . 68 127 9.14. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 68 128 9.15. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 69 129 9.16. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 69 130 10. Security Considerations . . . . . . . . . . . . . . . . . . . 69 131 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 69 132 10.2. TCP Security Techniques . . . . . . . . . . . . . . . . . 70 133 10.3. PCEP Authentication and Integrity . . . . . . . . . . . . 71 134 10.4. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 71 135 10.5. Key Configuration and Exchange . . . . . . . . . . . . . . 72 136 10.6. Access Policy . . . . . . . . . . . . . . . . . . . . . . 73 137 10.7. Protection Against Denial of Service Attacks . . . . . . . 74 138 10.7.1. Protection Against TCP DoS Attacks . . . . . . . . . . 74 139 10.7.2. Request Input Shaping/Policing . . . . . . . . . . . . 75 140 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 75 141 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 142 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77 143 13.1. Normative References . . . . . . . . . . . . . . . . . . . 77 144 13.2. Informative References . . . . . . . . . . . . . . . . . . 77 145 13.3. References . . . . . . . . . . . . . . . . . . . . . . . . 80 146 Appendix A. PCEP Finite State Machine (FSM) . . . . . . . . . . . 80 147 Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 87 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 149 Intellectual Property and Copyright Statements . . . . . . . . . . 89 151 1. Introduction 153 [RFC4655] describes the motivations and architecture for a Path 154 Compuation Element (PCE) based model for the computation of 155 Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic 156 Engineering Label Swtich Paths (TE LSPs). The model allows for the 157 separation of PCE from Path Computation Client (PCC), and allows for 158 the cooperation between PCEs. This necessitates a communication 159 protocol between PCC and PCE, and between PCEs. [RFC4657] states the 160 generic requirements for such a protocol including the requirement 161 for using the same protocol between PCC and PCE, and between PCEs. 162 Additional application-specific requirements (for scenarios such as 163 inter-area, inter-AS, etc.) are not included in [RFC4657], but there 164 is a requirement that any solution protocol must be easily extensible 165 to handle other requirements as they are introduced in application- 166 specific requirements documents. Examples of such application- 167 specific requirements are [RFC4927], 168 [I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req]. 170 This document specifies the Path Computation Element Communication 171 Protocol (PCEP) for communications between a PCC and a PCE, or 172 between two PCEs, in compliance with [RFC4657]. Such interactions 173 include path computation requests and path computation replies as 174 well as notifications of specific states related to the use of a PCE 175 in the context of MPLS and GMPLS Traffic Engineering. 177 PCEP is designed to be flexible and extensible so as to easily allow 178 for the addition of further messages and objects, should further 179 requirements be expressed in the future. 181 2. Terminology 183 Terminology used in this document 185 AS: Autonomous System. 187 Explicit path: Full explicit path from start to destination made of a 188 list of strict hops where a hop may be an abstract node such as an 189 AS. 191 IGP area: OSPF area or IS-IS level. 193 Inter-domain TE LSP: A TE LSP whose path transits at least two 194 different domains where a domain can be an IGP area, an Autonomous 195 System or a sub-AS (BGP confederations). 197 PCC: Path Computation Client: any client application requesting a 198 path computation to be performed by a Path Computation Element. 200 PCE: Path Computation Element: an entity (component, application or 201 network node) that is capable of computing a network path or route 202 based on a network graph and applying computational constraints. 204 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or a 205 PCE). 207 TED: Traffic Engineering Database that contains the topology and 208 resource information of the domain. The TED may be fed by IGP 209 extensions or potentially by other means. 211 TE LSP: Traffic Engineering Label Switched Path. 213 Strict/loose path: mix of strict and loose hops comprising at least 214 one loose hop representing the destination where a hop may be an 215 abstract node such as an AS. 217 Within this document, when describing PCE-PCE communications, the 218 requesting PCE fills the role of a PCC. This provides a saving in 219 documentation without loss of function. 221 The message formats in this document are specified using Backus Naur 222 Format (BNF) encoding as specified in [I-D.farrel-rtg-common-bnf]. 224 3. Assumptions 226 [RFC4655] describes various types of PCE. PCEP does not make any 227 assumption and thus does not impose any constraint on the nature of 228 the PCE. 230 Moreover, it is assumed that the PCE has the required information 231 (usually including network topology and resource information) so as 232 to perform the computation of a path for a TE LSP. Such information 233 can be gathered by routing protocols or by some other means. The way 234 in which the information is gathered is out of the scope of this 235 document. 237 Similarly, no assumption is made about the discovery method used by a 238 PCC to discover a set of PCEs (e.g., via static configuration or 239 dynamic discovery) and on the algorithm used to select a PCE. For 240 reference, [RFC4674] defines a list of requirements for dynamic PCE 241 discovery and IGP-based solutions for such PCE discovery are 242 specified in [RFC5088] and [RFC5089]. 244 4. Architectural Protocol Overview (Model) 246 The aim of this section is to describe the PCEP model in the spirit 247 of [RFC4101]. An architecture protocol overview (the big picture of 248 the protocol) is provided in this section. Protocol details can be 249 found in further sections. 251 4.1. Problem 253 The PCE-based architecture used for the computation of path for MPLS 254 and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the 255 PCE are not collocated, a communication protocol between the PCC and 256 the PCE is needed. PCEP is such a protocol designed specifically for 257 communications between a PCC and a PCE or between two PCEs in 258 compliance with [RFC4657]: a PCC may use PCEP to send a path 259 computation request for one or more TE LSPs to a PCE and the PCE may 260 reply with a set of computed paths if one or more paths can be found 261 that satisfies the set of constraints. 263 4.2. Architectural Protocol Overview 265 PCEP operates over TCP, which fulfils the requirements for reliable 266 messaging and flow control without further protocol work. 268 Several PCEP messages are defined: 270 - Open and Keepalive messages are used to initiate and maintain a 271 PCEP session respectively. 273 - PCReq: a PCEP message sent by a PCC to a PCE to request a path 274 computation. 276 - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path 277 computation request. A PCRep message can either contain a set of 278 computed paths if the request can be satisfied, or a negative reply 279 if not. The negative reply may indicate the reason why no path could 280 be found. 282 - PCNtf: a PCEP notification message either sent by a PCC to a PCE or 283 a PCE to a PCC to notify of a specific event. 285 - PCErr: a PCEP message sent upon the occurrence of a protocol error 286 condition. 288 - Close message: a message used to close a PCEP session. 290 The set of available PCEs may be either statically configured on a 291 PCC or dynamically discovered. The mechanisms used to discover one 292 or more PCEs and to select a PCE are out of the scope of this 293 document. 295 A PCC may have PCEP sessions with more than one PCE and similarly a 296 PCE may have PCEP sessions with multiple PCCs. 298 Each PCEP message is regarded as a single transmission unit and parts 299 of messages MUST NOT be interleaved. So, for example, a PCC sending 300 a PCReq and wishing to close the session, must complete sending the 301 request message before starting to send a Close message. 303 4.2.1. Initialization Phase 305 The initialization phase consists of two successive steps (described 306 in a schematic form in Figure 1): 308 1) Establishment of a TCP connection (3-way handshake) between the 309 PCC and the PCE. 311 2) Establishment of a PCEP session over the TCP connection. 313 Once the TCP connection is established, the PCC and the PCE (also 314 referred to as "PCEP peers") initiate PCEP session establishment 315 during which various session parameters are negotiated. These 316 parameters are carried within Open messages and include the Keepalive 317 timer, the Deadtimer and potentially other detailed capabilities and 318 policy rules that specify the conditions under which path computation 319 requests may be sent to the PCE. If the PCEP session establishment 320 phase fails because the PCEP peers disagree on the session parameters 321 or one of the PCEP peers does not answer after the expiration of the 322 establishment timer, the TCP connection is immediately closed. 323 Successive retries are permitted but an implementation should make 324 use of an exponential back-off session establishment retry procedure. 326 Keepalive messages are used to acknowledge Open messages, and once 327 the PCEP session has been successfully established. 329 Only one PCEP session can exist between a pair of PCEP peers at any 330 one time. Only one TCP connection on the PCEP port can exist between 331 a pair of PCEP peers at any one time. 333 Details about the Open message and the Keepalive message can be found 334 in Section 6.2 and Section 6.3 respectively. 336 +-+-+ +-+-+ 337 |PCC| |PCE| 338 +-+-+ +-+-+ 339 | | 340 | Open msg | 341 |-------- | 342 | \ Open msg | 343 | \ ---------| 344 | \/ | 345 | /\ | 346 | / -------->| 347 | / | 348 |<------ Keepalive| 349 | --------| 350 |Keepalive / | 351 |-------- / | 352 | \/ | 353 | /\ | 354 |<------ ---------->| 355 | | 357 Figure 1: PCEP Initialization phase (initiated by a PCC) 359 (Note that once the PCEP session is established, the exchange of 360 Keepalive messages is optional) 362 4.2.2. Session Keepalive 364 Once a session has been established, a PCE or PCC may want to know 365 that its PCEP peer is still available for use. 367 It can rely on TCP for this information, but it is possible that the 368 remote PCEP function has failed without disturbing the TCP 369 connection. It is also possible to rely on the mechanisms built into 370 the TCP implementations, but these might not provide sufficiently 371 timely notifications of failures. Lastly, a PCC could wait until it 372 has a path computation request to send and use its failed 373 transmission or the failure to receive a response as evidence that 374 the session has failed, but this is clearly inefficient. 376 In order to handle this situation, PCEP includes a keepalive 377 mechanism based on a Keepalive timer, a Dead timer, and a Keepalive 378 message. 380 Each end of a PCEP session runs a Keepalive timer. It restarts the 381 timer every time it sends a message on the session. When the timer 382 expires, it sends a Keepalive message. Other traffic may serve as 383 Keepalive (see Section 6.3). 385 The ends of the PCEP session also run Dead timers, and they restart 386 them whenever a message is received on the session. If one end of 387 the session receives no message before the Dead timer expires, it 388 declares the session dead. 390 Note that this means that the Keepalive message is unresponded and 391 does not form part of a two-way keepalive handshake as used in some 392 protocols. Also note that the mechanism is designed to reduce to a 393 minimum the amount of keepalive traffic on the session. 395 The keepalive traffic on the session may be unbalanced according to 396 the requirements of the session ends. Each end of the session can 397 specify (on an Open message) the Keepalive timer that it will use 398 (i.e., how often it will transmit a Keepalive message if there is no 399 other traffic) and a Dead timer that it recommends its peer to use 400 (i.e., how long the peer should wait before declaring the session 401 dead if it receives no traffic). The session ends may use different 402 Keepalive timer values. 404 The minimum value of the Keepalive timer is 1 second, and it is 405 specified in units of 1 second. The recommended default value is 30 406 seconds. The timer may be disabled by setting it to zero. 408 The recommended default for the Dead timer is 4 times the value of 409 the Keepalive timer used by the remote peer. This means that there 410 is never any risk of congesting TCP with excessive Keepalive 411 messages. 413 4.2.3. Path Computation Request Sent By a PCC to a PCE 414 +-+-+ +-+-+ 415 |PCC| |PCE| 416 +-+-+ +-+-+ 417 1)Path computation | | 418 event | | 419 2)PCE Selection | | 420 3)Path computation |---- PCReq message--->| 421 request sent to | | 422 the selected PCE | | 424 Figure 2: Path Computation request 426 Once a PCC has successfully established a PCEP session with one or 427 more PCEs, if an event is triggered that requires the computation of 428 a set of paths, the PCC first selects one or more PCE. Note that the 429 PCE selection decision process may have taken place prior to the PCEP 430 session establishment. 432 Once the PCC has selected a PCE, it sends the PCE a path computation 433 request to the PCE (PCReq message) that contains a variety of objects 434 that specify the set of constraints and attributes for the path to be 435 computed. For example "Compute a TE LSP path with source IP 436 address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B 437 Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may 438 desire to specify the urgency of such request by assigning a request 439 priority. Each request is uniquely identified by a request-id number 440 and the PCC-PCE address pair. The process is shown in a schematic 441 form in Figure 2. 443 Note that multiple path computation requests may be outstanding from 444 one PCC to a PCE at any time. 446 Details about the PCReq message can be found in Section 6.4 448 4.2.4. Path Computation Reply Sent By The PCE to a PCC 449 +-+-+ +-+-+ 450 |PCC| |PCE| 451 +-+-+ +-+-+ 452 | | 453 |---- PCReq message--->| 454 | |1) Path computation 455 | |request received 456 | | 457 | |2)Path successfully 458 | |computed 459 | | 460 | |3) Computed paths 461 | |sent to the PCC 462 | | 463 |<--- PCRep message ---| 464 | (Positive reply) | 466 Figure 3a: Path Computation Request With Successful 467 Path Computation 469 +-+-+ +-+-+ 470 |PCC| |PCE| 471 +-+-+ +-+-+ 472 | | 473 | | 474 |---- PCReq message--->| 475 | |1) Path computation 476 | |request received 477 | | 478 | |2) No Path found that 479 | |satisfies the request 480 | | 481 | |3) Negative reply sent to 482 | |the PCC (optionally with 483 | |various additional 484 | |information) 485 |<--- PCRep message ---| 486 | (Negative reply) | 488 Figure 3b: Path Computation Request With Unsuccessful 489 Path Computation 491 Upon receiving a path computation request from a PCC, the PCE 492 triggers a path computation, the result of which can either be: 494 o Positive (Figure 3-a): the PCE manages to compute a path that 495 satisfies the set of required constraints, in which case the PCE 496 returns the set of computed paths to the requesting PCC. Note 497 that PCEP supports the capability to send a single request that 498 requires the computation of more than one path (e.g., computation 499 of a set of link-diverse paths). 501 o Negative (Figure 3-b): no path could be found that satisfies the 502 set of constraints. In this case, a PCE may provide the set of 503 constraints that led to the path computation failure. Upon 504 receiving a negative reply, a PCC may decide to resend a modified 505 request or take any other appropriate action. 507 Details about the PCRep message can be found in Section 6.5. 509 4.2.5. Notification 511 There are several circumstances in which a PCE may want to notify a 512 PCC of a specific event. For example, suppose that the PCE suddenly 513 gets overloaded, potentially leading to unacceptable response times. 514 The PCE may want to notify one or more PCCs that some of their 515 requests (listed in the notification) will not be satisfied or may 516 experience unacceptable delays. Upon receiving such notification, 517 the PCC may decide to redirect its path computation requests to 518 another PCE should an alternate PCE be available. Similarly, a PCC 519 may desire to notify a PCE of a particular event such as the 520 cancellation of pending requests. 522 +-+-+ +-+-+ 523 |PCC| |PCE| 524 +-+-+ +-+-+ 525 1)Path computation | | 526 event | | 527 2)PCE Selection | | 528 3)Path computation |---- PCReq message--->| 529 request X sent to | |4) Path computation 530 the selected PCE | |request queued 531 | | 532 | | 533 5) Path computation| | 534 request X cancelled| | 535 |---- PCNtf message -->| 536 | |6) Path computation 537 | |request X cancelled 539 Figure 4: Example of PCC Notification (Cancellation 540 Notification) 541 Sent To a PCE 543 +-+-+ +-+-+ 544 |PCC| |PCE| 545 +-+-+ +-+-+ 546 1)Path computation | | 547 event | | 548 2)PCE Selection | | 549 3)Path computation |---- PCReq message--->| 550 request X sent to | |4) Path computation 551 the selected PCE | |request queued 552 | | 553 | | 554 | |5) PCE gets overloaded 555 | | 556 | | 557 | |6) Path computation 558 | |request X cancelled 559 | | 560 |<--- PCNtf message----| 562 Figure 5: Example of PCE Notification (Cancellation 563 Notification) Sent To a PCC 565 Details about the PCNtf message can be found in Section 6.6. 567 4.2.6. Error 569 The PCEP Error message (also referred to as a PCErr message) is sent 570 in several situations: when a protocol error condition is met or when 571 the request is not compliant with the PCEP specification (e.g., 572 capability not supported, reception of a message with a mandatory 573 missing object, policy violation, unexpected message, unknown request 574 reference, ...). 576 +-+-+ +-+-+ 577 |PCC| |PCE| 578 +-+-+ +-+-+ 579 1)Path computation | | 580 event | | 581 2)PCE Selection | | 582 3)Path computation |---- PCReq message--->| 583 request X sent to | |4) Reception of a 584 the selected PCE | |malformed object 585 | | 586 | |5) Request discarded 587 | | 588 |<-- PCErr message ---| 589 | | 591 Figure 6: Example of Error message Sent By a PCE To a PCC 592 In Reply To The Reception Of a Malformed Object 594 Details about the PCErr message can be found in Section 6.7. 596 4.2.7. Termination of the PCEP Session 598 When one of the PCEP peers desires to terminate a PCEP session it 599 first sends a PCEP Close message and then closes the TCP connection. 600 If the PCEP session is terminated by the PCE, the PCC clears all the 601 states related to pending requests previously sent to the PCE. 602 Similarly, if the PCC terminates a PCEP session the PCE clears all 603 pending path computation requests sent by the PCC in question as well 604 as the related states. A Close message can only be sent to terminate 605 a PCEP session if the PCEP session has previously been established. 607 In case of TCP connection failure, the PCEP session is immediately 608 terminated. 610 Details about the Close message can be found in Section 6.8. 612 4.2.8. Intermitent versus Permanent PCEP Session 614 An implementation may decide to keep the PCEP session alive (and thus 615 the corresponding TCP connection) for an unlimited time (this may for 616 instance be appropriate when path computation requests are sent on a 617 frequent basis so as to avoid to open a TCP connection each time a 618 path computation request is needed, which would incur additional 619 processing delays). Conversely, in some other circumstances, it may 620 be desirable to systematically open and close a PCEP session for each 621 PCEP request (for instance when sending a path computation request is 622 a rare event). 624 5. Transport Protocol 626 PCEP operates over TCP using a registered TCP port (to be assigned by 627 IANA). This allows the requirements of reliable messaging and flow 628 control to be met without further protocol work. All PCEP message 629 MUST be sent using the registered TCP port for the source and 630 destination TCP port. 632 6. PCEP Messages 634 A PCEP message consists of a common header followed by a variable 635 length body made of a set of objects that can either be mandatory or 636 optional. In the context of this document, an object is said to be 637 mandatory in a PCEP message when the object MUST be included for the 638 message to be considered as valid. A PCEP message with a missing 639 mandatory object MUST trigger an Error message (see Section 7.15). 640 Conversely, if an object is optional, the object may or may not be 641 present. 643 A flag referred to as the P flag is defined in the common header of 644 each PCEP object (see Section 7.2). When this flag is set in an 645 object in a PCReq, the PCE MUST take the information carried in the 646 object into account during the path computation. For example, the 647 METRIC object defined in Section 7.8 allows a PCC to specify a 648 bounded acceptable path cost. The METRIC object is optional, but a 649 PCC may set a flag to ensure that the constraint is taken into 650 account. In this case, if the constraint cannot be taken into 651 account by the PCE, the PCE MUST trigger an Error message. 653 For each PCEP message type, rules are defined that specify the set of 654 objects that the message can carry. We use the Backus-Naur Form 655 (BNF) (see [I-D.farrel-rtg-common-bnf]) to specify such rules. 656 Square brackets refer to optional sub-sequences. An implementation 657 MUST form the PCEP messages using the object ordering specified in 658 this document. 660 6.1. Common header 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Ver | Flags | Message-Type | Message-Length | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Figure 7: PCEP Message Common Header 670 Ver (Version - 3 bits): PCEP version number. Current version is 671 version 1. 673 Flags (5 bits): no flags are currently defined. Unassigned bits are 674 considered as reserved. They MUST be set to zero on transmission and 675 MUST be ignored on receipt. 677 Message-Type (8 bits): 679 The following message types are currently defined (to be confirmed by 680 IANA). 681 Value Meaning 682 1 Open 683 2 Keepalive 684 3 Path Computation Request 685 4 Path Computation Reply 686 5 Notification 687 6 Error 688 7 Close 690 Message-Length (16 bits): total length of the PCEP message expressed 691 in bytes including the common header. 693 6.2. Open Message 695 The Open message is a PCEP message sent by a PCC to a PCE and a PCE 696 to a PCC in order to establish a PCEP session. The Message-Type 697 field of the PCEP common header for the Open message is set to 1 (To 698 be confirmed by IANA). 700 Once the TCP connection has been successfully established, the first 701 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 702 an Open message as specified in Appendix A. 704 Any message received prior to an Open message MUST trigger a protocol 705 error condition causing a PCErr message to be sent with Error-Type 706 'PCEP session establishment failure' and Error-Value 'reception of an 707 invalid Open message or a non Open message' and the PCEP session 708 establishment attempt MUST be terminated by closing the TCP 709 connection. 711 The Open message is used to establish a PCEP session between the PCEP 712 peers. During the establishment phase the PCEP peers exchange 713 several session characteristics. If both parties agree on such 714 characteristics the PCEP session is successfully established. 716 Open message 717 ::= 718 719 The Open message MUST contain exactly one OPEN object (see 720 Section 7.3). 722 Various session characteristics are specified within the OPEN object. 723 Once the TCP connection has been successfully established the sender 724 MUST start an initialization timer called OpenWait after the 725 expiration of which if no Open message has been received it sends a 726 PCErr message and releases the TCP connection (see Appendix A for 727 details). 729 Once an Open message has been sent to a PCEP peer, the sender MUST 730 start an initialization timer called KeepWait after the expiration of 731 which if neither a Keepalive message has been received nor a PCErr 732 message in case of disagreement of the session characteristics, a 733 PCErr message MUST be sent and the TCP connection MUST be released 734 (see Appendix A for details). 736 The KeepWait timer has a fixed value of 1 minute. 738 Upon the receipt of an Open message, the receiving PCEP peer MUST 739 determine whether the suggested PCEP session characteristics are 740 acceptable. If at least one of the characteristics is not acceptable 741 by the receiving peer, it MUST send an Error message. The Error 742 message SHOULD also contain the related Open object: for each 743 unacceptable session parameter, an acceptable parameter value SHOULD 744 be proposed in the appropriate field of the Open object in place of 745 the originally proposed value. The PCEP peer MAY decide to resend an 746 Open message with different session characteristics. If a second 747 Open message is received with the same set of parameters or with 748 parameters that are still unacceptable, the receiving peer MUST send 749 an Error message and it MUST immediately close the TCP connection. 750 Details about error message can be found in Section 7.15. Successive 751 retries are permitted but an implementation SHOULD make use of an 752 exponential back-off session establishment retry procedure. 754 If the PCEP session characteristics are acceptable, the receiving 755 PCEP peer MUST send a Keepalive message (defined in Section 6.3) that 756 serves as an acknowledgment. 758 The PCEP session is considered as established once both PCEP peers 759 have received a Keepalive message from their peer. 761 A PCEP implementation is free to process received requests in any 762 order. For example, the requests may be processed in the order they 763 are received, re-ordered and assigned priority according to local 764 policy, re-ordered according to the priority encoded in the RP Object 765 (Section 7.4.1), or processed in parallel. 767 6.3. Keepalive Message 769 A Keepalive message is a PCEP message sent by a PCC or a PCE in order 770 to keep the session in active state. The Keepalive message is also 771 used in response to an Open message to acknowledge that an Open 772 message has been received and that the PCEP session characteristics 773 are acceptable. The Message-Type field of the PCEP common header for 774 the Keepalive message is set to 2 (To be confirmed by IANA). The 775 Keepalive message does not contain any object. 777 PCEP has its own keepalive mechanism used to ensure of the liveness 778 of the PCEP session. This requires the determination of the 779 frequency at which each PCEP peer sends Keepalive messages. 780 Asymmetric values may be chosen; thus there is no constraint 781 mandating the use of identical keepalive frequencies by both PCEP 782 peers. The DeadTimer is defined as the period of time after the 783 expiration of which a PCEP peer declares the session down if no PCEP 784 message has been received (Keepalive or any other PCEP message: thus, 785 any PCEP message acts as a Keepalive message). Similarly, there is 786 no constraints mandating the use of identical DeadTimers by both PCEP 787 peers. The minimum Keepalive timer value is 1 second. Deployments 788 SHOULD consider carefully the impact of using low values for the 789 Keepalive timer as these might not give rise to the expected results 790 in periods of temporary network instability. 792 Keepalive messages are sent at the frequency specified in the OPEN 793 object carried within an Open message according to the rules 794 specified in Section 7.3. Because any PCEP message may serve as 795 Keepalive, an implementation may either decide to send Keepalive 796 messages at fixed intervals regardless on whether other PCEP messages 797 might have been sent since the last sent Keepalive message, or may 798 decide to differ the sending of the next Keepalive message based on 799 the time at which the last PCEP message (other than Keepalive) was 800 sent. 802 Note that sending Keepalive messages to keep the session alive is 803 optional and PCEP peers may decide to not send Keepalive messages 804 once the PCEP session is established in which case the peer that does 805 not receive Keepalive messages does not expect to receive them and 806 MUST NOT declare the session as inactive. 808 Keepalive message 809 ::= 811 6.4. Path Computation Request (PCReq) Message 813 A Path Computation Request message (also referred to as a PCReq 814 message) is a PCEP message sent by a PCC to a PCE to request a path 815 computation. A PCReq message may carry more than one path 816 computation request. The Message-Type field of the PCEP common 817 header for the PCReq message is set to 3 (To be confirmed by IANA). 819 There are two mandatory objects that MUST be included within a PCReq 820 message: the RP and the END-POINTS objects (see section Section 7). 821 If one or both of these objects is missing, the receiving PCE MUST 822 send an error message to the requesting PCC. Other objects are 823 optional. 825 The format of a PCReq message is as follows: 826 ::= 827 [] 828 830 where: 831 ::=[] 832 ::=[] 834 ::= 835 836 [] 837 [] 838 [] 839 [[]] 840 [] 841 [] 842 where: 844 ::=[] 846 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 847 BALANCING objects are defined in Section 7. The special case of two 848 BANDWIDTH objects is discussed in detail in Section 7.7. 850 6.5. Path Computation Reply (PCRep) Message 852 The PCEP Path Computation Reply message (also referred to as a PCRep 853 message) is a PCEP message sent by a PCE to a requesting PCC in 854 response to a previously received PCReq message. The Message-Type 855 field of the PCEP common header is set to 4 (To be confirmed by 856 IANA). 858 The bundling of multiple replies to a set of path computation 859 requests within a single PCRep message is supported by PCEP. If a 860 PCE receives non-synchronized path computation requests by means of 861 one or more PCReq messages from a requesting PCC it MAY decide to 862 bundle the computed paths within a single PCRep message so as to 863 reduce the control plane load. Note that the counter side of such an 864 approach is the introduction of additional delays for some path 865 computation requests of the set. Conversely, a PCE that receives 866 multiple requests within the same PCReq message MAY decide to provide 867 each computed path in separate PCRep messages or within the same 868 PCRep message. A PCRep message may contain positive and negative 869 replies. 871 A PCRep message may contain a set of computed paths corresponding to 872 either a single path computation request with load-balancing (see 873 Section 7.16) or multiple path computation requests originated by a 874 requesting PCC. The PCRep message may also contain multiple 875 acceptable paths corresponding to the same request. 877 The PCRep message MUST contain at least one RP object. For each 878 reply that is bundled into a single PCReq message, an RP object MUST 879 be included that contains a Request-ID-number identical to the one 880 specified in the RP object carried in the corresponding PCReq message 881 (see Section 7.4 for the definition of the RP object). 883 If the path computation request can be satisfied (the PCE finds a set 884 of paths that satisfy the set of constraints), the set of computed 885 paths specified by means of ERO objects is inserted in the PCRep 886 message. The ERO is defined in Section 7.9. The situation where 887 multiple computed paths are provided in a PCRep message is discussed 888 in detail in Section 7.13. Furthermore, when a PCC requests the 889 computation of a set of paths for a total amount of bandwidth by 890 means of a LOAD-BALANCING object carried within a PCReq message, the 891 ERO of each computed path may be followed by a BANDWIDTH object as 892 discussed in section Section 7.16. 894 If the path computation request cannot be satisfied, the PCRep 895 message MUST include a NO-PATH object. The NO-PATH object (described 896 in Section 7.5) may also contain other information (e.g, reasons for 897 the path computation failure). 899 The format of a PCRep message is as follows: 900 ::= 901 903 where: 904 ::=[] 906 ::= 907 [] 908 [] 909 [] 911 ::=[] 913 ::= 915 where: 917 ::=[] 918 [] 919 [] 920 [] 922 ::=[] 924 6.6. Notification (PCNtf) Message 926 The PCEP Notification message (also referred to as the PCNtf message) 927 can be sent either by a PCE to a PCC, or by a PCC to a PCE, to notify 928 of a specific event. The Message-Type field of the PCEP common 929 header is set to 5 (To be confirmed by IANA). 931 The PCNtf message MUST carry at least one NOTIFICATION object and MAY 932 contain several NOTIFICATION objects should the PCE or the PCC intend 933 to notify of multiple events. The NOTIFICATION object is defined in 934 Section 7.14. The PCNtf message MAY also contain RP objects (see 935 Section 7.4 when the notification refers to particular path 936 computation requests. 938 The PCNtf message may be sent by a PCC or a PCE in response to a 939 request or in an unsolicited manner. 941 The format of a PCNtf message is as follows: 942 ::= 943 945 ::= [] 947 ::= [] 948 950 ::=[] 952 ::=[] 954 6.7. Error (PCErr) Message 956 The PCEP Error message (also referred to as a PCErr message) is sent 957 in several situations: when a protocol error condition is met or when 958 the request is not compliant with the PCEP specification (e.g., 959 reception of a malformed message, reception of a message with a 960 mandatory missing object, policy violation, unexpected message, 961 unknown request reference, ...). The Message-Type field of the PCEP 962 common header is set to 6 (To be confirmed by IANA). 964 The PCErr message is sent by a PCC or a PCE in response to a request 965 or in an unsolicited manner. If the PCErr message is sent in 966 response to a request, the PCErr message MUST include the set of RP 967 objects related to the pending path computation requests that 968 triggered the error condition. In the later case (unsolicited), no 969 RP object is inserted in the PCErr message. For example, no RP 970 object is inserted in a PCErr when the error condition occurred 971 during the initialization phase. A PCErr message MUST contain a 972 PCEP-ERROR object specifying the PCEP error condition. The PCEP- 973 ERROR object is defined in section Section 7.15. 975 The format of a PCErr message is as follows: 976 ::= 977 ( [] ) | 978 [] 980 ::=[] 981 ::=[] 982 983 ::=[] 984 ::=[] 986 The procedure upon the receipt of a PCErr message is defined in 987 Section 7.15. 989 6.8. Close Message 991 The Close message is a PCEP message that is either sent by a PCC to a 992 PCE or by a PCE to a PCC in order to close an established PCEP 993 session. The Message-Type field of the PCEP common header for the 994 Close message is set to 7 (To be confirmed by IANA). 996 Close message 997 ::= 998 1000 The Close message MUST contain exactly one CLOSE object (see 1001 Section 6.8). If more than one CLOSE object is present, the first 1002 MUST be processed and subsequent objects ignored. 1004 Upon the receipt of a valid Close message, the receiving PCEP peer 1005 MUST cancel all pending requests, it MUST close the TCP connection 1006 and MUST NOT send any further PCEP messages on the PCEP session. 1008 6.9. Reception of Unknown Messages 1010 A PCEP implementation that receives an unrecognized PCEP message MUST 1011 send a PCErr message with Error-value=2 (capability not supported). 1013 If a PCC/PCE receives unrecognized messages at a rate equal of 1014 greater than MAX-UNKNOWN-MESSAGES unknown message requests per 1015 minute, the PCC/PCE MUST send a PCEP CLOSE message with close 1016 value="Reception of an unacceptable number of unknown PCEP message". 1017 A RECOMMENDED value for MAX-UNKOWN-MESSAGES is 5. The PCC/PCE MUST 1018 close the TCP session and MUST NOT send any further PCEP messages on 1019 the PCEP session. 1021 7. Object Formats 1023 PCEP objects have a common format. They begin with a common object 1024 header (see Section 7.2). This is followed by object-specific fields 1025 defined for each different object. The object may also include one 1026 or more type-length-value (TLV) encoded data sets. Each TLV has the 1027 same structure as described in Section 7.1. 1029 7.1. PCE TLV Format 1031 A PCEP object may include a set of one or more optional TLVs. 1033 All PCEP TLVs have the following format: 1035 Type: 2 bytes 1036 Length: 2 bytes 1037 Value: variable 1038 A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes 1039 specifying the TLV length, and a value field. 1041 The Length field defines the length of the value portion in bytes. 1042 The TLV is padded to 4-bytes alignment; padding is not included in 1043 the Length field (so a three byte value would have a length of three, 1044 but the total size of the TLV would be eight bytes). 1046 Unrecognized TLVs MUST be ignored. 1048 IANA management of the PCEP Object TLV type identifier codespace is 1049 described in Section 9. 1051 7.2. Common Object Header 1053 A PCEP object carried within a PCEP message consists of one or more 1054 32-bit words with a common header which has the following format: 1055 0 1 2 3 1056 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 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Object-Class | OT |Res|P|I| Object Length (bytes) | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | | 1061 // (Object body) // 1062 | | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Figure 8: PCEP common object header 1067 Object-Class (8 bits): identifies the PCEP object class. 1069 OT (Object-Type - 4 bits): identifies the PCEP object type. 1071 The Object-Class and Object-Type fields are managed by IANA. 1073 The Object-Class and Object-Type fields uniquely identify each PCEP 1074 object. 1076 Res flags (2 bits). Reserved field. This field MUST be set to zero 1077 on transmission and MUST be ignored on receipt. 1079 o P flag (Processing-Rule - 1-bit): the P flag allows a PCC to 1080 specify in a PCReq message sent to a PCE whether the object must 1081 be taken into account by the PCE during path computation or is 1082 just optional. When the P flag is set, the object MUST be taken 1083 into account by the PCE. Conversely, when the P flag is cleared, 1084 the object is optional and the PCE is free to ignore it. 1086 o I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 1087 message to indicate to a PCC whether or not an optional object was 1088 processed. The PCE MAY include the ignored optional object in its 1089 reply and set the I flag to indicate that the optional object was 1090 ignored during path computation. When the I flag is cleared, the 1091 PCE indicates that the optional object was processed during the 1092 path computation. The setting of the I flag for optional objects 1093 is purely indicative and optional. The I flag has no meaning in a 1094 PCRep message when the P flag has been set in the corresponding 1095 PCReq message. 1097 If the PCE does not understand an object with the P flag set or 1098 understands the object but decides to ignore the object, the entire 1099 PCEP message MUST be rejected and the PCE MUST send a PCErr message 1100 with Error-Type="Unknown Object" or "Not supported Object" along with 1101 the corresponding RP object. Note that if a PCReq includes multiple 1102 requests, only requests for which an object with the P flag set is 1103 unknown/unrecognized MUST be rejected. 1105 Object Length (16 bits). Specifies the total object length including 1106 the header, in bytes. The Object Length field MUST always be a 1107 multiple of 4, and at least 4. The maximum object content length is 1108 65528 bytes. 1110 7.3. OPEN Object 1112 The OPEN object MUST be present in each Open message and MAY be 1113 present in a PCErr message. There MUST be only one OPEN object per 1114 Open or PCErr message. 1116 The OPEN object contains a set of fields used to specify the PCEP 1117 version, Keepalive frequency, DeadTimer, PCEP session ID along with 1118 various flags. The OPEN object may also contain a set of TLVs used 1119 to convey various session characteristics such as the detailed PCE 1120 capabilities, policy rules and so on. No TLVs are currently defined. 1122 OPEN Object-Class is to be assigned by IANA (recommended value=1) 1124 OPEN Object-Type is to be assigned by IANA (recommended value=1) 1125 The format of the OPEN 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 | Ver | Flags | Keepalive | DeadTimer | SID | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | | 1133 // Optional TLVs // 1134 | | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 Figure 9: OPEN Object format 1139 Ver (3 bits): PCEP version. Current version is 1. 1141 Flags (5 bits): No Flags are currently defined. Unassigned bits are 1142 considered as reserved. They MUST be set to zero on transmission and 1143 MUST be ignored on receipt. 1145 Keepalive (8 bits): maximum period of time (in seconds) between two 1146 consecutive PCEP messages sent by the sender of this message. The 1147 minimum value for the Keepalive is 1 second. When set to 0, once the 1148 session is established, no further Keepalive messages are sent to the 1149 remote peer. A RECOMMENDED value for the keepalive frequency is 30 1150 seconds. 1152 DeadTimer (8 bits): specifies the amount of time after the expiration 1153 of which the PCEP peer can declare the session with the sender of the 1154 Open message down if no PCEP message has been received. The 1155 DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is 1156 set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value 1157 of the Keepalive. 1159 Example: 1161 A sends an Open message to B with Keepalive=10 seconds and 1162 Deadtimer=40 seconds. This means that A sends Keepalive messages (or 1163 any other PCEP message) to B every 10 seconds and B can declare the 1164 PCEP session with A down if no PCEP message has been received from A 1165 within any 40 second period. 1167 SID (PCEP session-ID - 8 bits): unsigned PCEP session number that 1168 identifies the current session. The SID MUST be incremented each 1169 time a new PCEP session is established and is used for logging and 1170 troubleshooting purposes. Each increment SHOULD have a value of 1 1171 and may cause a wrap back to zero. 1173 The SID is used to disambiguate instances of sessions to the same 1174 peer. A PCEP implementation could use a single source of SIDs across 1175 all peers, or one source for each peer. The former might constrain 1176 the implementation to only 256 concurrent sessions. The latter 1177 potentially requires more states. There is one SID number in each 1178 direction. 1180 Optional TLVs may be included within the OPEN object body to specify 1181 PCC or PCE characteristics. The specification of such TLVs is 1182 outside the scope of this document. 1184 When present in an Open message, the OPEN object specifies the 1185 proposed PCEP session characteristics. Upon receiving unacceptable 1186 PCEP session characteristics during the PCEP session initialization 1187 phase, the receiving PCEP peer (PCE) MAY include an OPEN object 1188 within the PCErr message so as to propose alternative acceptable 1189 session characteristic values. 1191 7.4. RP Object 1193 The RP (Request Parameters) object MUST be carried within each PCReq 1194 and PCRep messages and MAY be carried within PCNtf and PCErr 1195 messages. The RP object is used to specify various characteristics 1196 of the path computation request. 1198 The P flag of the RP object MUST be set in PCReq and PCReq messages 1199 and MUST be cleared in PCNtf and PCErr messages. If the RP objet is 1200 received with the P flag set incorrectely according to the rules 1201 states above, the receiving peer MUST send a PCErr message with 1202 Error-type=10 and Error-value=1. The corresponding path computation 1203 request MUST be cancelled by the PCE without further notification. 1205 7.4.1. Object Definition 1207 RP Object-Class is to be assigned by IANA (recommended value=2) 1209 RP Object-Type is to be assigned by IANA (recommended value=1) 1210 The format of the RP object body is as follows: 1212 0 1 2 3 1213 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 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Flags |O|B|R| Pri | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Request-ID-number | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | | 1220 // Optional TLVs // 1221 | | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 Figure 10: RP object body format 1226 The RP object body has a variable length and may contain additional 1227 TLVs. No TLVs are currently defined. 1229 Flags (32 bits) 1231 The following flags are currently defined: 1233 o Pri (Priority - 3 bits): the Priority field may be used by the 1234 requesting PCC to specify to the PCE the request's priority from 1 1235 to 7. The decision of which priority should be used for a 1236 specific request is of a local matter and MUST be set to 0 when 1237 unused. Furthermore, the use of the path computation request 1238 priority by the PCE's scheduler is implementation specific and out 1239 of the scope of this document. Note that it is not required for a 1240 PCE to support the priority field: in this case, it is RECOMMENDED 1241 that the PCC set the priority field to 0 in the RP object. If the 1242 PCE does not take into account the request priority, it is 1243 RECOMMENDED to set the priority field to 0 in the RP object 1244 carried within the corresponding PCRep message, regardless of the 1245 priority value contained in the RP object carried within the 1246 corresponding PCReq message. A higher numerical value of the 1247 priority field reflects a higher priority. Note that it is the 1248 responsibility of the network administrator to make use of the 1249 priority values in a consistent manner across the various PCCs. 1250 The ability of a PCE to support request prioritization MAY be 1251 dynamically discovered by the PCCs by means of PCE capability 1252 discovery. If not advertised by the PCE, a PCC may decide to set 1253 the request priority and will learn the ability of the PCE to 1254 support request prioritization by observing the Priority field of 1255 the RP object received in the PCRep message. If the value of the 1256 Pri field is set to 0, this means that the PCE does not support 1257 the handling of request priorities: in other words, the path 1258 computation request has been honoured but without taking the 1259 request priority into account. 1261 o R (Reoptimization - 1 bit): when set, the requesting PCC specifies 1262 that the PCReq message relates to the reoptimization of an 1263 existing TE LSP. For all TE LSPs except 0-bandwidth LSPs, when 1264 the R bit is set, an RRO (see Section 7.10) MUST be included in 1265 the PCReq message to show the path of the existing TE LSP. Also, 1266 for all TE LSPs except 0-bandwidth LSPs, then the R bit is set, 1267 the existing bandwidth of the TE LSP to be reoptimized MUST be 1268 supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH 1269 object is in addition to the instance of that object used to 1270 describe the desired bandwidth of the reoptimized LSP. For 1271 0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the 1272 characteristics of the existing TE LSP are optional. 1274 o B (Bi-directional - 1 bit): when set, the PCC specifies that the 1275 path computation request relates to a bidirectional TE LSP that 1276 has the same traffic engineering requirements including fate 1277 sharing, protection and restoration, LSRs, TE Links, and resource 1278 requirements (e.g., latency and jitter) in each direction. When 1279 cleared, the TE LSP is unidirectional. 1281 o O (strict/loose - 1 bit): when set, in a PCReq message, this 1282 indicates that a loose path is acceptable. Otherwise, when 1283 cleared, this indicates to the PCE that a path exclusively made of 1284 strict hops is required. In a PCRep message, when the O bit is 1285 set this indicates that the returned path is a loose path, 1286 otherwise (the O bit is cleared), the returned path is made of 1287 strict hops. 1289 Unassigned bits are considered as reserved. They MUST be set to zero 1290 on transmission and MUST be ignored on receipt. 1292 Request-ID-number (32 bits). The Request-ID-number value combined 1293 with the source IP address of the PCC and the PCE address uniquely 1294 identify the path computation request context. The Request-ID-number 1295 is used for disambiguation between pending requests and thus it MUST 1296 be changed (such as by incrementing it) each time a new request is 1297 sent to the PCE, and may wrap. 1299 The value 0x00000000 is considered as invalid. 1301 If no path computation reply is received from the PCE (e.g. request 1302 dropped by the PCE because of memory overflow), and the PCC wishes to 1303 resend its request, the same Request-ID-number MUST be used. Upon 1304 receiving a path computation request from a PCC with the same 1305 Request-ID-number the PCE SHOULD treat the request as a new request 1306 but an implementation MAY choose to cach path computation replies in 1307 order to quickly handle restranmission without having to handle twice 1308 a path computation request should have the first request been dropped 1309 or lost. Upon receiving a path computation reply from a PCE with the 1310 same Request-ID-number the PCC SHOULD silently discard the path 1311 computation reply. 1313 Conversely, different Request-ID-number MUST be used for different 1314 requests sent to a PCE. 1316 The same Request-ID-number MAY be used for path computation requests 1317 sent to different PCEs. The path computation reply is unambiguously 1318 identified by the IP source address of the replying PCE. 1320 7.4.2. Handling of the RP Object 1322 If a PCReq message is received that does not contain an RP object, 1323 the PCE MUST send a PCErr message to the requesting PCC with Error- 1324 type="Required Object missing" and Error-value="RP Object missing". 1326 If the O bit of the RP message carried within a PCReq message is 1327 cleared and local policy has been configured on the PCE to not 1328 provide explicit paths (for instance, for confidentiality reasons), a 1329 PCErr message MUST be sent by the PCE to the requesting PCC and the 1330 pending path computation request MUST be discarded. The Error-type 1331 is "Policy Violation" and Error-value is "O bit cleared". 1333 R bit: when the R bit of the RP object is set in a PCReq message, 1334 this indicates that the path computation request relates to the 1335 reoptimization of an existing TE LSP. In this case, the PCC MUST 1336 also provide the strict/loose path by including an RRO object in the 1337 PCReq message so as to avoid/limit double bandwidth counting if and 1338 only if the TE LSP is a non-0-bandwidth TE LSP. If the PCC has not 1339 requested a strict path (O bit set), a reoptimization can still be 1340 requested by the PCC but this requires that the PCE either be 1341 stateful (keep track of the previously computed path with the 1342 associated list of strict hops), or have the ability to retrieve the 1343 complete required path segment. Alternatively the PCC MUST inform 1344 the PCE of the working path with the associated list of strict hops 1345 in PCReq. The absence of an RRO in the PCReq message for a non-0- 1346 bandwidth TE LSP when the R bit of the RP object is set MUST trigger 1347 the sending of a PCErr message with Error-type="Required Object 1348 Missing" and Error-value="RRO Object missing for reoptimization". 1350 If a PCC/PCE receives a PCRep/PCReq message that contains a RP object 1351 referring to an unknown Request-ID-Number, the PCC/PCE MUST send a 1352 PCErr message with Error-Type="Unknown request reference". This is 1353 used for debugging purposes. If a PCC/PCE receives PCRep/PCReq at a 1354 rate equal of greater than MAX-UNKOWN-REQUESTS unknown requests per 1355 minute, the PCC/PCE MUST send a PCEP CLOSE message with close 1356 value="Reception of an unacceptable number of unknown requests/ 1357 replies". A RECOMMENDED value for MAX-UNKOWN-REQUESTS is 5. The 1358 PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP 1359 messages on the PCEP session. 1361 The reception of a PCEP message that contains a RP object referring 1362 to a Request-ID-number=0x00000000 MUST be treated similarly to an 1363 unkown request. 1365 7.5. NO-PATH Object 1367 The NO-PATH object is used in PCRep messages in response to an 1368 unsuccessful path computation request (the PCE could not find a path 1369 satisfying the set of constraints). When a PCE cannot find a path 1370 satisfying a set of constraints, it MUST include a NO-PATH object in 1371 the PCRep message. 1373 There are several categories of issue that can lead to a negative 1374 reply. For example, the PCE chain might be broken (should there be 1375 more than one PCE involved in the path computation) or no path 1376 obeying the set constraints could be found. The "NI (Nature of 1377 Issue)" field in the NO-PATH object is used to report the error 1378 category. 1380 Optionally, if the PCE supports such capability, the NO-PATH object 1381 MAY contain an optional NO-PATH-VECTOR TLV defined below and used to 1382 provide more information on the reasons that led to a negative reply. 1383 The PCRep message MAY also contain a list of objects that specify the 1384 set of constraints that could not be satisfied. The PCE MAY just 1385 replicate the set of objects that was received that was the cause of 1386 the unsuccessful computation or MAY optionally report a suggested 1387 value for which a path could have been found (in which case the value 1388 differs from the value in the original request). 1390 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1392 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1393 The format of the NO-PATH object body is as follows: 1395 0 1 2 3 1396 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 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 |Nature Of Issue|C| Flags | Reserved | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | | 1401 // Optional TLVs // 1402 | | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 Figure 11: NO-PATH Object Format 1407 NI - Nature Of Issue (8 bits): the NI field is used to report the 1408 nature of the issue that led to a negative reply. Two values are 1409 currently defined: 1411 0x00: No path satisfying the set of constraints could be found 1413 0x01: PCE chain broken 1415 The Nature Of Issue field value can be used by the PCC for various 1416 purposes: 1418 o Constraint adjustement before re-issuing a new path computation 1419 request, 1421 o Explicit selection of a new PCE chain, 1423 o Logging of the error type for futher action by the network 1424 admistrator 1426 IANA management of the NI field codespace is described in Section 9. 1428 Flags (16 bits). 1430 The following flag is currently defined: 1432 C flag (1 bit): when set, the PCE indicates the set of unsatisfied 1433 constraints (reasons why a path could not be found) in the PCRep 1434 message by including the relevant PCEP objects. When cleared, no 1435 failing constraints are specified. The C flag has no meaning and is 1436 ignored unless the NI field is set to 0x00. 1438 Unassigned bits are considered as reserved. They MUST be set to zero 1439 on transmission and MUST be ignored on receipt. 1441 Reserved (8 bits): This field MUST be set to zero on transmission and 1442 MUST be ignored on receipt. 1444 The NO-PATH object body has a variable length and may contain 1445 additional TLVs. The only TLV currently defined is the NO-PATH- 1446 VECTOR TLV defined below. 1448 Example: consider the case of a PCC that sends a path computation 1449 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1450 find a path for X MBits/s. In this case, the PCE must include in the 1451 PCRep message a NO-PATH object. Optionally the PCE may also include 1452 the original BANDWIDTH object so as to indicate that the reason for 1453 the unsuccessful computation is the bandwidth constraint (in this 1454 case, the NI field value is 0x00 and C flag is set). If the PCE 1455 supports such capability it may alternatively include the BANDWIDTH 1456 Object and report a value of Y in the bandwidth field of the 1457 BANDWIDTH object (in this case, the C flag is set) where Y refers to 1458 the bandwidth for which a TE LSP with the same other characteristics 1459 could have been computed. 1461 When the NO-PATH object is absent from a PCRep message, the path 1462 computation request has been fully satisfied and the corresponding 1463 paths are provided in the PCRep message. 1465 An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH 1466 object in order to provide more information on the reasons that led 1467 to a negative reply. 1469 The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in 1470 section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying 1471 the TLV length (length of the value portion in bytes) followed by a fixed 1472 length value field of 32-bit flags field. 1474 TYPE: To be assigned by IANA (suggested value=1) 1475 LENGTH: 4 1476 VALUE: 32-bit flags field 1478 IANA is requested to manage the space of flags carried in the NO- 1479 PATH-VECTOR TLV (see Section 9). 1481 The following flags are currently defined: 1483 o Bit number: 31 - PCE currently unavailable 1485 o Bit number: 30 - Unknown destination 1487 o Bit number: 29 - Unknown source 1489 7.6. END-POINT Object 1491 The END-POINTS object is used in a PCReq message to specify the 1492 source IP address and the destination IP address of the path for 1493 which a path computation is requested. The P flag of the END-POINT 1494 object MUST be set. If the END-POINT objet is received with the P 1495 flag cleared, the receiving peer MUST send a PCErr message with 1496 Error-type=10 and Error-value=1. The corresponding path computation 1497 request MUST be cancelled by the PCE without further notification. 1499 Note that the source and destination addresses specified in the END- 1500 POINTS object may or may not correspond to the source and destination 1501 IP address of the TE LSP but rather to a path segment. Two END- 1502 POINTS objects (for IPv4 and IPv6) are defined. 1504 END-POINTS Object-Class is to be assigned by IANA (recommended 1505 value=4) 1507 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 1508 for IPv4 and 2 for IPv6) 1509 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1510 as follows: 1512 0 1 2 3 1513 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 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Source IPv4 address | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Destination IPv4 address | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 Figure 12: END-POINTS Object Body Format for IPv4 1522 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 1524 0 1 2 3 1525 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 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | | 1528 | Source IPv6 address (16 bytes) | 1529 | | 1530 | | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | | 1533 | Destination IPv6 address (16 bytes) | 1534 | | 1535 | | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 Figure 13: END-POINTS Object Body Format for IPv6 1540 The END-POINTS object body has a fixed length of 8 bytes for IPv4 and 1541 32 bytes for IPv6. 1543 If more than one END-POINTS object is present, the first MUST be 1544 processed and subsequent objects ignored. 1546 7.7. BANDWIDTH Object 1548 The BANDWIDTH object is used to specify the requested bandwidth for a 1549 TE LSP. The notion of bandwidth is similar to the one used for RSVP 1550 signaling in [RFC2205], [RFC3209] and [RFC3473]. 1552 If the requested bandwidth is equal to 0, the BANDWIDTH object is 1553 optional. Conversely, if the requested bandwidth is non equal to 0, 1554 the PCReq message MUST contain a BANDWIDTH object. 1556 In the case of the reoptimization of a TE LSP, the bandwidth of the 1557 existing TE LSP MUST also be included in addition to the requested 1558 bandwidth if and only if the two values differ. Consequently, two 1559 Object-Type values are defined that refer to the requested bandwidth 1560 and the bandwidth of the TE LSP for which a reoptimization is being 1561 performed. 1563 The BANDWIDTH object may be carried within PCReq and PCRep messages. 1565 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1566 value=5) 1568 Two Object-Type values are defined for the BANDWIDTH object: 1570 o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by 1571 IANA (recommended value=1) 1573 o Bandwidth of an existing TE LSP for which a reoptimization is 1574 requested. BANDWIDTH Object-Type is to be assigned by IANA 1575 (recommended value=2) 1577 The format of the BANDWIDTH object body is as follows: 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Bandwidth | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 Figure 14: BANDWIDTH Object Body Format 1587 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1588 IEEE floating point format (see [IEEE.754.1985]), expressed in bytes 1589 per second. Refer to Section 3.1.2 of [RFC3471] for a table of 1590 commonly used values. 1592 The BANDWIDTH object body has a fixed length of 4 bytes. 1594 7.8. METRIC Object 1596 The METRIC object is optional and can be used for several purposes. 1598 In a PCReq message, a PCC MAY insert one of more METRIC objects: 1600 o To indicate the metric that MUST be optimized by the path 1601 computation algorithm (IGP metric, TE metric, Hop counts). 1602 Currently, three metrics are defined: the IGP cost, the TE metric 1603 (see [RFC3785]) and the number of hops traversed by a TE LSP. 1605 o To indicate a bound on the path cost that MUST NOT be exceeded for 1606 the path to be considered as acceptable by the PCC. 1608 In a PCRep message, the METRIC object MAY be inserted so as to 1609 provide the cost for the computed path. It MAY also be inserted 1610 within a PCRep with the NO-PATH object to indicate that the metric 1611 constraint could not be satisfied. 1613 The path computation algorithmic aspects used by the PCE to optimize 1614 a path with respect to a specific metric are outside the scope of 1615 this document. 1617 It must be understood that such path metrics are only meaningful if 1618 used consistently: for instance, if the delay of a computed path 1619 segment is exchanged between two PCEs residing in different domains, 1620 consistent ways of defining the delay must be used. 1622 The absence of the METRIC object MUST be interpreted by the PCE as a 1623 path computation request for which no constraints need be applied to 1624 any of the metrics. 1626 METRIC Object-Class is to be assigned by IANA (recommended value=6) 1628 METRIC Object-Type is to be assigned by IANA (recommended value=1) 1630 The format of the METRIC object body is as follows: 1632 0 1 2 3 1633 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 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Reserved | Flags |C|B| T | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | metric-value | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 Figure 15: METRIC Object Body Format 1642 The METRIC object body has a fixed length of 8 bytes. 1644 Reserved (16 bits): This field MUST be set to zero on transmission 1645 and MUST be ignored on receipt. 1647 T (Type - 8 bits): Specifies the metric type. 1649 Three values are currently defined: 1651 o T=1: IGP metric 1653 o T=2: TE metric 1655 o T=3: Hop Counts 1657 Flags (8 bits): Two flags are currently defined: 1659 o B (Bound - 1 bit): When set in a PCReq message, the metric-value 1660 indicates a bound (a maximum) for the path metric that must not be 1661 exceeded for the PCC to consider the computed path as acceptable. 1662 The path metric must be less than or equal to the value specified 1663 in the Metric-value field. When the B flag is cleared, the 1664 metric-value field is not used to reflect a bound constraint. 1666 o C (Computed Metric - 1 bit): When set in a PCReq message, this 1667 indicates that the PCE MUST provide the computed path metric value 1668 (should a path satisfying the constraints be found) in the PCRep 1669 message for the corresponding metric. 1671 Unassigned flags MUST be set to zero on transmission and MUST be 1672 ignored on receipt. 1674 Metric-value (32 bits): metric value encoded in 32 bits in IEEE 1675 floating point format (See [IEEE.754.1985]). 1677 Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 1678 message. There MUST be at most one instance of the METRIC object for 1679 each metric type with the same B flag value. If two or more 1680 instances of a METRIC object with the same B flag value are present 1681 for a metric type, only the first instance MUST be considered and 1682 other instances MUST be ignored. 1684 The presence of two METRIC objects of the same type with a different 1685 value of the B-Flag in a PCEReq message is allowed. Furthermore, it 1686 is also allowed to insert in a PCReq message two METRIC objects with 1687 different types that have both their B-Flag cleared: in this case, an 1688 objective function must be used by the PCE to solve a multi-parameter 1689 constraint problem. 1691 A METRIC object used to indicate the metric to optimize during the 1692 path computation MUST have the B-Flag cleared and the C-Flag set to 1693 the appropriate value. When the path computation relates to the 1694 reoptimization of an exiting TE LSP (in which case R-Flag of the RP 1695 object is set) an implementation MAY decide to set the metric-value 1696 field to the computed value of the metric of the TE LSP to be 1697 reoptimized with regards to a specific metric type. 1699 A METRIC object used to reflect a bound MUST have the B-Flag set, the 1700 C-Flag and metric-value field set to the appropriate values. 1702 In a PCRep message, unless not allowed by PCE policy, at least one 1703 METRIC object MUST be present that reports the computed path metric 1704 if the C bit of the METRIC object was set in the corresponding path 1705 computation request (the B-flag MUST be cleared). The C-flag has no 1706 meaning in a PCRep message. Optionally the PCRep message MAY contain 1707 additional METRIC objects that correspond to bound constraints, in 1708 which case the metric-value MUST be equal to the corresponding 1709 computed path metric (the B-flag MUST be set). If no path satisfying 1710 the constraints could be found by the PCE, the METRIC objects MAY 1711 also be present in the PCRep message with the NO-PATH object to 1712 indicate the constraint metric that could be satisfied. 1714 Example: if a PCC sends a path computation request to a PCE where the 1715 metric to optimize is the IGP metric and the TE metric must not 1716 exceed the value of M, two METRIC object are inserted in the PCReq 1717 message: 1719 o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000 1721 o Second METRIC Object with B=1, T=2, metric-value=M 1723 If a path satisfying the set of constraints can be found by the PCE 1724 and there is no policy that prevents the return of the computed 1725 metric, the PCE inserts one METRIC object with B=0, T=1, metric- 1726 value= computed IGP path cost. Additionally, the PCE may insert a 1727 second METRIC object with B=1, T=2, metric-value= computed TE path 1728 cost. 1730 7.9. Explicit Route Object 1732 The ERO is used to encode the path of a TE LSP through the network. 1733 The ERO is carried within a PCRep message to provide the computed TE 1734 LSP should the path computation have been successful. 1736 The contents of this object are identical in encoding to the contents 1737 of the Resource Reservation Protocol Traffic Engineering Extensions 1738 (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473] 1739 and [RFC3477]. That is, the object is constructed from a series of 1740 sub-objects. Any RSVP-TE ERO sub-object already defined or that 1741 could be defined in the future for use in the RSVP-TE ERO is 1742 acceptable in this object. 1744 PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types. 1746 Since the explicit path is available for immediate signaling by the 1747 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1748 and fields in this object are identical to those defined for the ERO. 1750 ERO Object-Class is to be assigned by IANA (recommended value=7) 1752 ERO Object-Type is to be assigned by IANA (recommended value=1) 1754 7.10. Reported Route Object 1756 The RRO is exclusively carried within a PCReq message so as to report 1757 the route followed by a TE LSP for which a reoptimization is desired. 1759 The contents of this object are identical in encoding to the contents 1760 of the Route Record Object defined in [RFC3209], [RFC3473] and 1761 [RFC3477]. That is, the object is constructed from a series of sub- 1762 objects. Any RSVP-TE RRO sub-object already defined or that could be 1763 defined in the future for use in the RSVP-TE RRO is acceptable in 1764 this object. 1766 The meanings of all of the sub-objects and fields in this object are 1767 identical to those defined for the RSVP-TE RRO. 1769 PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types. 1771 RRO Object-Class is to be assigned by IANA (recommended value=8) 1773 RRO Object-Type is to be assigned by IANA (recommended value=1) 1775 7.11. LSPA Object 1777 The LSPA object is optional and specifies various TE LSP attributes 1778 to be taken into account by the PCE during path computation. The 1779 LSPA (LSP Attributes) object can be carried within a PCReq message, 1780 or a PCRep message in case of unsuccessful path computation (in this 1781 case, the PCRep message also contains a NO-PATH object and the LSPA 1782 object is used to indicate the set of constraints that could not be 1783 satisfied). Most of the fields of the LSPA object are identical to 1784 the fields of the SESSION-ATTRIBUTE (C-Type = 7) object defined in 1785 [RFC3209] and [RFC4090]. When absent from the PCReq message, this 1786 means that the Setup and Holding priorities are equal to 0, and there 1787 are no affinity constraints. See section 4.7.4 of [RFC3209] for a 1788 detailed description of the use of resource affinities. 1790 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1792 LSPA Object-Types is to be assigned by IANA (recommended value=1) 1793 The format of the LSPA object body is: 1795 0 1 2 3 1796 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 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | Exclude-any | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | Include-any | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | Include-all | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Setup Prio | Holding Prio | Flags |L| Reserved | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | | 1807 // Optional TLVs // 1808 | | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 Figure 16: LSPA Object Body Format 1812 Setup Prio (Setup Priority - 8 bits). The priority of the TE LSP 1813 with respect to taking resources, in the range of 0 to 7. The value 1814 0 is the highest priority. The Setup Priority is used in deciding 1815 whether this session can preempt another session. 1817 Holding Prio (Holding Priority - 8 bits). The priority of the TE LSP 1818 with respect to holding resources, in the range of 0 to 7. The value 1819 0 is the highest priority. Holding Priority is used in deciding 1820 whether this session can be preempted by another session. 1822 Flags (8 bits) 1824 The flag L corresponds to the "Local protection desired" bit 1825 ([RFC3209]) of the SESSION-ATTRIBUTE Object. 1827 L Flag (Local protection desired). When set, this means that the 1828 computed path must include links protected with Fast Reroute as 1829 defined in [RFC4090]. 1831 Unassigned flags MUST be set to zero on transmission and MUST be 1832 ignored on receipt. 1834 Reserved (8 bits): This field MUST be set to zero on transmission and 1835 MUST be ignored on receipt. 1837 Note that Optional TLVs may be defined in the future to carry 1838 additional TE LSP attributes such as those defined in [RFC4420]. 1840 7.12. Include Route Object Object 1842 The IRO (Include Route Object) is optional and can be used to specify 1843 that the computed path MUST traverse a set of specified network 1844 elements. The IRO MAY be carried within PCReq and PCRep messages. 1845 When carried within a PCRep message with the NO-PATH object, the IRO 1846 indicates the set of elements that cause de PCE to fail to find a 1847 path. 1849 IRO Object-Class is to be assigned by IANA (recommended value=10) 1851 IRO Object-Type is to be assigned by IANA (recommended value=1) 1853 0 1 2 3 1854 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 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | | 1857 // (Subobjects) // 1858 | | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 Figure 17: IRO Body Format 1863 Subobjects: The IRO is made of subobjects identical to the ones 1864 defined in [RFC3209], [RFC3473] and [RFC3477] where the IRO subobject 1865 type is identical to the subobject type defined in the related 1866 documents. 1868 The following subobject types are supported. 1870 Type Subobject 1871 1 IPv4 prefix 1872 2 IPv6 prefix 1873 4 Unnumbered Interface ID 1874 32 Autonomous system number 1875 The L bit of such sub-object has no meaning within an IRO. 1877 7.13. SVEC Object 1879 7.13.1. Notion of Dependent and Synchronized Path Computation Requests 1881 Independent versus dependent path computation requests: path 1882 computation requests are said to be independent if they are not 1883 related to each other. Conversely a set of dependent path 1884 computation requests is such that their computations cannot be 1885 performed independently of each other (a typical example of dependent 1886 requests is the computation of a set of diverse paths). 1888 Synchronized versus non-synchronized path computation requests: a set 1889 of path computation requests is said to be non-synchronized if their 1890 respective treatment (path computations) can be performed by a PCE in 1891 a serialized and independent fashion. 1893 There are various circumstances where the synchronization of a set of 1894 path computations may be beneficial or required. 1896 Consider the case of a set of N TE LSPs for which a PCC needs to send 1897 path computation requests to a PCE. The first solution consists of 1898 sending N separate PCReq messages to the selected PCE. In this case, 1899 the path computation requests are non-synchronized. Note that the 1900 PCC may chose to distribute the set of N requests across K PCEs for 1901 load balancing purposes. Considering that M (with M+-+-+-+-+-+-+ | | 3554 | | | KeepWait |----+ | 3555 | +--| |<---+ | 3556 |+-----+-+-+-+-+-+-+ | | 3557 || | | | 3558 || | | | 3559 || V | | 3560 || +->+-+-+-+-+-+-+----+ | 3561 || | | OpenWait |-------+ 3562 || +--| |<------+ 3563 ||+----+-+-+-+-+-+-+<---+ | 3564 ||| | | | 3565 ||| | | | 3566 ||| V | | 3567 ||| +->+-+-+-+-+-+-+ | | 3568 ||| | |TCPPending |----+ | 3569 ||| +--| | | 3570 |||+---+-+-+-+-+-+-+<---+ | 3571 |||| | | | 3572 |||| | | | 3573 |||| V | | 3574 |||+--->+-+-+-+-+ | | 3575 ||+---->| Idle |-------+ | 3576 |+----->| |----------+ 3577 +------>+-+-+-+-+ 3579 Figure 23: PCEP Finite State Machine for the PCC 3581 PCEP defines the following set of variables: 3583 Connect: timer (in seconds) started after having initialized a TCP 3584 connection using the PCEP registered TCP port. The value of the 3585 TCPConnect timer is 60 seconds. 3587 ConnectRetry: specifies the number of times the system has tried to 3588 establish a TCP connection with a PCEP peer without success. 3590 ConnectMaxRetry: Maximum number of times the system tries to 3591 establish a TCP connection using the PCEP registered TCP port before 3592 going back to the Idle state. The value of the ConnectMaxRetry is 5. 3594 OpenWait: timer that corresponds to the amount of time a PCEP peer 3595 will wait to receive an Open message from the PCEP peer after the 3596 expiration of which the system releases the PCEP resource and go back 3597 to the Idle state. The OpenWait timer has a fixed value of 60 3598 seconds. 3600 KeepWait: timer that corresponds to the amount of time a PCEP peer 3601 will wait to receive a Keepalive or a PCErr message from the PCEP 3602 peer after the expiration of which the system releases the PCEP 3603 resource and go back to the Idle state. The KeepWait timer has a 3604 fixed value of 60 seconds. 3606 OpenRetry: specifies the number of times the system has received an 3607 Open message with unacceptable PCEP session characteristics. 3609 The following two states variable are defined: 3611 RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system 3612 has received an acceptable Open message. 3614 LocalOK: the LocalOK variable is a Boolean set to 1 if the system has 3615 received a Keepalive message acknowledging that the Open message sent 3616 to the peer was valid. 3618 Idle State: 3620 The idle state is the initial PCEP state where PCEP (also referred to 3621 as "the system") waits for an initialization event that can either be 3622 manually triggered by the user (configuration) or automatically 3623 triggered by various events. In Idle state, PCEP resources are 3624 allocated (memory, potential process, ...) but no PCEP messages are 3625 accepted from any PCEP peer. The system listens the registered PCEP 3626 TCP port. 3628 The following set of variable are initialized: 3630 TCPRetry=0, 3632 LocalOK=0, 3634 RemoteOK=0, 3636 OpenRetry=0. 3638 Upon detection of a local initialization event (e.g. user 3639 configuration to establish a PCEP session with a particular PCEP 3640 peer, local event triggering the establishment of a PCEP session with 3641 a PCEP peer such as the automatic detection of a PCEP peer, ...), the 3642 system: 3644 o Initiates of a TCP connection with the PCEP peer, 3646 o Starts the Connect timer, 3648 o Moves to the TCPPending state. 3650 Upon receiving a TCP connection on the registered PCEP TCP port, if 3651 the TCP connection establishment succeeds, the system: 3653 o Sends an Open message, 3655 o Starts the OpenWait timer, 3657 o Moves to the OpenWait state. 3659 If the connection establishment fails, the system remains in the Idle 3660 state. Any other event received in the Idle state is ignored. 3662 It is expected that an implementation will use an exponentially 3663 increasing timer between automatically generated Initialization 3664 events and between retries of TCP connection establishment. 3666 TCPPending State 3668 If the TCP connection establishment succeeds, the system: 3670 o Sends an Open message, 3672 o Starts the OpenWait timer, 3674 o Moves to the OpenWait state. 3676 If the TCP connection establishment fails (an error is detected 3677 during the TCP connection establishment) or the Connect timer 3678 expires: 3680 o If ConnectRetry =ConnectMaxRetry the system moves to the Idle 3681 State 3683 o If ConnectRetry < ConnectMaxRetry the system: 3685 1. Initiates of a TCP connection with the PCEP peer, 3687 2. Increments the ConnectRetry variable, 3688 3. Restarts the Connect timer, 3690 4. Stays in the TPCPending state. 3692 In response to any other event the system releases the PCEP resources 3693 for that peer and moves back to the Idle state. 3695 OpenWait State: 3697 In the OpenWait state, the system waits for an Open message from its 3698 PCEP peer. 3700 If the system receives an Open message from the PCEP peer before the 3701 expiration of the OpenWait timer, the system first examines all of 3702 its sessions that are in the OpenWait or KeepWait state. If another 3703 session with the same PCEP peer already exists (same IP address), 3704 then the system performs the following collision resolution 3705 procedure: 3707 o If the system has initiated the current session and it has a lower 3708 IP address than the PCEP Peer, the system closes the TCP 3709 connection, releases the PCEP resources for the pending session 3710 and moves back to the Idle state. 3712 o If the session was initiated by the PCEP peer and the system has a 3713 higher IP address that the PCEP Peer, the system closes the TCP 3714 connection, releases the PCEP resources for the pending session, 3715 and moves back to the Idle state. 3717 o Otherwise, the system checks the PCEP session attributes 3718 (Keepalive frequency, DeadTimer, ...). 3720 If an error is detected (e.g. malformed Open message, reception of a 3721 message that is not an Open message, presence of two Open objects, 3722 ...), PCEP generates an error notification, the PCEP peer sends a 3723 PCErr message with Error-Type=1 and Error-value=1. The system 3724 releases the PCEP resources for the PCEP peer, closes the TCP 3725 connection and moves to the Idle state. 3727 If no errors are detected, OpenRetry=1 and the session 3728 characteristics are unacceptable, the PCEP peer sends a PCErr with 3729 Error-Type=1 and Error-value=5, the system releases the PCEP 3730 resources for that peer and moves back to the Idle state. 3732 If no errors are detected, and the session characteristics are 3733 acceptable to the local system, the system: 3735 o Sends a Keepalive message to the PCEP peer, 3737 o Starts the Keepalive timer, 3739 o Sets the RemoteOK variable to 1. 3741 If LocalOK=1 the system clears the OpenWait timer and moves to the UP 3742 state. 3744 If LocalOK=0 the system clears the OpenWait timer, starts the 3745 KeepWait timer and moves to the KeepWait state. 3747 If no errors are detected, but the session characteristics are 3748 unacceptable and non-negotiable, the PCEP peer sends a PCErr with 3749 Error-Type=1 and Error-value=3, the system releases the PCEP 3750 resources for that peer, and moves back to the Idle state. 3752 If no errors are detected, and OpenRetry is 0, and the session 3753 characteristics are unacceptable but negotiable (such as, the 3754 Keepalive period or the DeadTimer), then the system: 3756 o Increments the OpenRetry variable, 3758 o Sends a PCErr message with Error-Type=1 and Error-value=4 that 3759 contains proposed acceptable session characteristics, 3761 o If LocalOK=1, the system restarts the OpenWait timer and stays in 3762 the OpenWait state 3764 o If LocalOK=0, the system clears the OpenWait timer, starts the 3765 KeepWait timer and moves to the KeepWait state 3767 If no Open message is received before the expiration of the OpenWait 3768 timer, the PCEP peer sends a PCErr message with Error-Type=1 and 3769 Error-value=2, the system releases the PCEP resources for the PCEP 3770 peer, closes the TCP connection and moves to the Idle state. 3772 In response to any other event the system releases the PCEP resources 3773 for that peer and moves back to the Idle state. 3775 KeepWait State 3777 In the Keepwait state, the system waits for the receipt of a 3778 Keepalive from its PCEP peer acknowledging its Open message or a 3779 PCErr message in response to unacceptable PCEP session 3780 characteristics proposed in the Open message. 3782 If an error is detected (e.g. malformed Keepalive message), PCEP 3783 generates an error notification, the PCEP peer sends a PCErr message 3784 with Error-Type=1 and Error-value=1. The system releases the PCEP 3785 resources for the PCEP peer, closes the TCP connection and moves to 3786 the Idle state. 3788 If a Keepalive message is received before the expiration of the 3789 KeepWait timer, then the system sets LocalOK=1 and: 3791 o If RemoteOK=1, the system clears the KeepWait timer and moves to 3792 the UP state. 3794 o If RemoteOK=0, the system clears the KeepWait timer, starts the 3795 OpenWait timer and moves to the OpenWait State. 3797 If a PCErr message is received before the expiration of the KeepWait 3798 timer: 3800 1. If the proposed values are unacceptable, the PCEP peer sends a 3801 PCErr message with Error-Type=1 and Error-value=6 and the system 3802 releases the PCEP resources for that PCEP peer, closes the TCP 3803 connection and moves to the Idle state. 3805 2. If the proposed values are acceptable, the system adjusts its 3806 PCEP session characteristics according to the proposed values 3807 received in the PCErr message restarts the KeepWait timer and 3808 sends a new Open message. If RemoteOK=1, the system restarts the 3809 KeepWait timer and stays in the KeepWait state. If RemoteOK=0, 3810 the system clears the KeepWait timer, start the OpenWait timer 3811 and moves to the OpenWait state. 3813 If neither a Keepalive nor a PCErr is received after the expiration 3814 of the KeepWait timer, the PCEP peer sends a PCErr message with 3815 Error-Type=1 and Error-value=7 and, system releases the PCEP 3816 resources for that PCEP peer, closes the TCP connection and moves to 3817 the Idle State. 3819 In response to any other event the system releases the PCEP resources 3820 for that peer and moves back to the Idle state. 3822 UP State 3824 In the UP state, the PCEP peer starts exchanging PCEP messages 3825 according to the session characteristics. 3827 If the Keepalive timer expires, the system restarts the Keepalive 3828 timer and sends a Keepalive message. 3830 If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from 3831 the PCEP peer before the expiration of the DeadTimer, the system 3832 terminates PCEP session according to the procedure defined in 3833 Section 6.8, releases the PCEP resources for that PCEP peer, closes 3834 the TCP connection and moves to the Idle State. 3836 If a malformed message is received, the system terminates the PCEP 3837 session according to the procedure defined in Section 6.8, releases 3838 the PCEP resources for that PCEP peer, closes the TCP connection and 3839 moves to the Idle State. 3841 If the system detects that the PCEP peer tries to setup a second TCP 3842 connection, it stops the TCP connection establishment and sends a 3843 PCErr with Error-Type=9. 3845 If the TCP connection fails, the system releases the PCEP resources 3846 for that PCEP peer, closes the TCP connection and moves to the Idle 3847 State. 3849 Appendix B. PCEP Variables 3851 PCEP defines the following configurable variables: 3853 Keepalive timer: minimum period of time between the sending of PCEP 3854 messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A 3855 suggested value for the Keepalive timer is 30 seconds. 3857 DeadTimer: period of timer after the expiration of which a PCEP peer 3858 declared the session down if no PCEP message has been received. 3860 SyncTimer: the SYNC timer is used in the case of synchronized path 3861 computation request using the SVEC object defined in Section 7.13.3. 3862 Consider the case where a PCReq message is received by a PCE that 3863 contains the SVEC object referring to M synchronized path computation 3864 requests. If after the expiration of the SYNC timer all the M path 3865 computation requests have not been received, a protocol error is 3866 triggered and the PCE MUST cancel the whole set of path computation 3867 requests. The aim of the SyncTimer is to avoid the storage of unused 3868 synchronized request should one of them get lost for some reasons 3869 (e.g a misbehaving PCC). Thus the value of the Synctimer must be 3870 large enough to avoid the expiration of the timer under normal 3871 circumstances. A RECOMMENDED value for the SYNC timer is 60 seconds. 3873 MAX-UNKNOWN-REQUESTS: A RECOMMENDED value is 5. 3875 MAX-UNKNOWN-MESSAGES: A RECOMMENDED value is 5. 3877 Authors' Addresses 3879 JP Vasseur (editor) 3880 Cisco Systems 3881 1414 Massachusetts Avenue 3882 Boxborough, MA 01719 3883 USA 3885 Email: jpv@cisco.com 3887 JL Le Roux (editor) 3888 France Telecom 3889 2, Avenue Pierre-Marzin 3890 Lannion, 22307 3891 FRANCE 3893 Email: jeanlouis.leroux@orange-ftgroup.com 3895 Full Copyright Statement 3897 Copyright (C) The IETF Trust (2008). 3899 This document is subject to the rights, licenses and restrictions 3900 contained in BCP 78, and except as set forth therein, the authors 3901 retain all their rights. 3903 This document and the information contained herein are provided on an 3904 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3905 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3906 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3907 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3908 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3909 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3911 Intellectual Property 3913 The IETF takes no position regarding the validity or scope of any 3914 Intellectual Property Rights or other rights that might be claimed to 3915 pertain to the implementation or use of the technology described in 3916 this document or the extent to which any license under such rights 3917 might or might not be available; nor does it represent that it has 3918 made any independent effort to identify any such rights. Information 3919 on the procedures with respect to rights in RFC documents can be 3920 found in BCP 78 and BCP 79. 3922 Copies of IPR disclosures made to the IETF Secretariat and any 3923 assurances of licenses to be made available, or the result of an 3924 attempt made to obtain a general license or permission for the use of 3925 such proprietary rights by implementers or users of this 3926 specification can be obtained from the IETF on-line IPR repository at 3927 http://www.ietf.org/ipr. 3929 The IETF invites any interested party to bring to its attention any 3930 copyrights, patents or patent applications, or other proprietary 3931 rights that may cover technology that may be required to implement 3932 this standard. Please address the information to the IETF at 3933 ietf-ipr@ietf.org.