idnits 2.17.1 draft-ietf-pce-pcep-18.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 3750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3774. 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 2, 2008) is 5647 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 3380, but not defined == Unused Reference: 'RFC1321' is defined on line 3302, 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-03 == 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-02 == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-09 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-01 == Outdated reference: A later version (-02) exists of draft-kkoushik-pce-pcep-mib-01 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 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 (~~), 11 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 6, 2009 France Telecom 5 November 2, 2008 7 Path Computation Element (PCE) Communication Protocol (PCEP) 8 draft-ietf-pce-pcep-18.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 6, 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. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 61 118 9.5. Notification Object . . . . . . . . . . . . . . . . . . . 62 119 9.6. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 62 120 9.7. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 63 121 9.8. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 64 122 9.9. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 64 123 9.10. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 65 124 9.11. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 65 125 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65 126 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 65 127 10.2. TCP Security Techniques . . . . . . . . . . . . . . . . . 66 128 10.3. PCEP Authentication and Integrity . . . . . . . . . . . . 67 129 10.4. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 67 130 10.5. Key Configuration and Exchange . . . . . . . . . . . . . . 68 131 10.6. Access Policy . . . . . . . . . . . . . . . . . . . . . . 69 132 10.7. Protection Against Denial of Service Attacks . . . . . . . 70 133 10.7.1. Protection Against TCP DoS Attacks . . . . . . . . . . 70 134 10.7.2. Request Input Shaping/Policing . . . . . . . . . . . . 71 135 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 71 136 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72 137 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 138 13.1. Normative References . . . . . . . . . . . . . . . . . . . 73 139 13.2. Informative References . . . . . . . . . . . . . . . . . . 73 140 13.3. References . . . . . . . . . . . . . . . . . . . . . . . . 76 141 Appendix A. PCEP Finite State Machine (FSM) . . . . . . . . . . . 76 142 Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 83 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 144 Intellectual Property and Copyright Statements . . . . . . . . . . 85 146 1. Introduction 148 [RFC4655] describes the motivations and architecture for a Path 149 Compuation Element (PCE) based model for the computation of 150 Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic 151 Engineering Label Swtich Paths (TE LSPs). The model allows for the 152 separation of PCE from Path Computation Client (PCC), and allows for 153 the cooperation between PCEs. This necessitates a communication 154 protocol between PCC and PCE, and between PCEs. [RFC4657] states the 155 generic requirements for such a protocol including the requirement 156 for using the same protocol between PCC and PCE, and between PCEs. 157 Additional application-specific requirements (for scenarios such as 158 inter-area, inter-AS, etc.) are not included in [RFC4657], but there 159 is a requirement that any solution protocol must be easily extensible 160 to handle other requirements as they are introduced in application- 161 specific requirements documents. Examples of such application- 162 specific requirements are [RFC4927], 163 [I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req]. 165 This document specifies the Path Computation Element Communication 166 Protocol (PCEP) for communications between a PCC and a PCE, or 167 between two PCEs, in compliance with [RFC4657]. Such interactions 168 include path computation requests and path computation replies as 169 well as notifications of specific states related to the use of a PCE 170 in the context of MPLS and GMPLS Traffic Engineering. 172 PCEP is designed to be flexible and extensible so as to easily allow 173 for the addition of further messages and objects, should further 174 requirements be expressed in the future. 176 2. Terminology 178 Terminology used in this document 180 AS: Autonomous System. 182 Explicit path: Full explicit path from start to destination made of a 183 list of strict hops where a hop may be an abstract node such as an 184 AS. 186 IGP area: OSPF area or IS-IS level. 188 Inter-domain TE LSP: A TE LSP whose path transits at least two 189 different domains where a domain can be an IGP area, an Autonomous 190 System or a sub-AS (BGP confederations). 192 PCC: Path Computation Client: any client application requesting a 193 path computation to be performed by a Path Computation Element. 195 PCE: Path Computation Element: an entity (component, application or 196 network node) that is capable of computing a network path or route 197 based on a network graph and applying computational constraints. 199 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or a 200 PCE). 202 TED: Traffic Engineering Database that contains the topology and 203 resource information of the domain. The TED may be fed by IGP 204 extensions or potentially by other means. 206 TE LSP: Traffic Engineering Label Switched Path. 208 Strict/loose path: mix of strict and loose hops comprising at least 209 one loose hop representing the destination where a hop may be an 210 abstract node such as an AS. 212 Within this document, when describing PCE-PCE communications, the 213 requesting PCE fills the role of a PCC. This provides a saving in 214 documentation without loss of function. 216 The message formats in this document are specified using Backus Naur 217 Format (BNF) encoding as specified in [I-D.farrel-rtg-common-bnf]. 219 3. Assumptions 221 [RFC4655] describes various types of PCE. PCEP does not make any 222 assumption and thus does not impose any constraint on the nature of 223 the PCE. 225 Moreover, it is assumed that the PCE has the required information 226 (usually including network topology and resource information) so as 227 to perform the computation of a path for a TE LSP. Such information 228 can be gathered by routing protocols or by some other means. The way 229 in which the information is gathered is out of the scope of this 230 document. 232 Similarly, no assumption is made about the discovery method used by a 233 PCC to discover a set of PCEs (e.g., via static configuration or 234 dynamic discovery) and on the algorithm used to select a PCE. For 235 reference, [RFC4674] defines a list of requirements for dynamic PCE 236 discovery and IGP-based solutions for such PCE discovery are 237 specified in [RFC5088] and [RFC5089]. 239 4. Architectural Protocol Overview (Model) 241 The aim of this section is to describe the PCEP model in the spirit 242 of [RFC4101]. An architecture protocol overview (the big picture of 243 the protocol) is provided in this section. Protocol details can be 244 found in further sections. 246 4.1. Problem 248 The PCE-based architecture used for the computation of path for MPLS 249 and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the 250 PCE are not collocated, a communication protocol between the PCC and 251 the PCE is needed. PCEP is such a protocol designed specifically for 252 communications between a PCC and a PCE or between two PCEs in 253 compliance with [RFC4657]: a PCC may use PCEP to send a path 254 computation request for one or more TE LSPs to a PCE and the PCE may 255 reply with a set of computed paths if one or more paths can be found 256 that satisfies the set of constraints. 258 4.2. Architectural Protocol Overview 260 PCEP operates over TCP, which fulfils the requirements for reliable 261 messaging and flow control without further protocol work. 263 Several PCEP messages are defined: 265 - Open and Keepalive messages are used to initiate and maintain a 266 PCEP session respectively. 268 - PCReq: a PCEP message sent by a PCC to a PCE to request a path 269 computation. 271 - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path 272 computation request. A PCRep message can either contain a set of 273 computed paths if the request can be satisfied, or a negative reply 274 if not. The negative reply may indicate the reason why no path could 275 be found. 277 - PCNtf: a PCEP notification message either sent by a PCC to a PCE or 278 a PCE to a PCC to notify of a specific event. 280 - PCErr: a PCEP message sent upon the occurrence of a protocol error 281 condition. 283 - Close message: a message used to close a PCEP session. 285 The set of available PCEs may be either statically configured on a 286 PCC or dynamically discovered. The mechanisms used to discover one 287 or more PCEs and to select a PCE are out of the scope of this 288 document. 290 A PCC may have PCEP sessions with more than one PCE and similarly a 291 PCE may have PCEP sessions with multiple PCCs. 293 Each PCEP message is regarded as a single transmission unit and parts 294 of messages MUST NOT be interleaved. So, for example, a PCC sending 295 a PCReq and wishing to close the session, must complete sending the 296 request message before starting to send a Close message. 298 4.2.1. Initialization Phase 300 The initialization phase consists of two successive steps (described 301 in a schematic form in Figure 1): 303 1) Establishment of a TCP connection (3-way handshake) between the 304 PCC and the PCE. 306 2) Establishment of a PCEP session over the TCP connection. 308 Once the TCP connection is established, the PCC and the PCE (also 309 referred to as "PCEP peers") initiate PCEP session establishment 310 during which various session parameters are negotiated. These 311 parameters are carried within Open messages and include the Keepalive 312 timer, the Deadtimer and potentially other detailed capabilities and 313 policy rules that specify the conditions under which path computation 314 requests may be sent to the PCE. If the PCEP session establishment 315 phase fails because the PCEP peers disagree on the session parameters 316 or one of the PCEP peers does not answer after the expiration of the 317 establishment timer, the TCP connection is immediately closed. 318 Successive retries are permitted but an implementation should make 319 use of an exponential back-off session establishment retry procedure. 321 Keepalive messages are used to acknowledge Open messages, and once 322 the PCEP session has been successfully established. 324 Only one PCEP session can exist between a pair of PCEP peers at any 325 one time. Only one TCP connection on the PCEP port can exist between 326 a pair of PCEP peers at any one time. 328 Details about the Open message and the Keepalive message can be found 329 in Section 6.2 and Section 6.3 respectively. 331 +-+-+ +-+-+ 332 |PCC| |PCE| 333 +-+-+ +-+-+ 334 | | 335 | Open msg | 336 |-------- | 337 | \ Open msg | 338 | \ ---------| 339 | \/ | 340 | /\ | 341 | / -------->| 342 | / | 343 |<------ Keepalive| 344 | --------| 345 |Keepalive / | 346 |-------- / | 347 | \/ | 348 | /\ | 349 |<------ ---------->| 350 | | 352 Figure 1: PCEP Initialization phase (initiated by a PCC) 354 (Note that once the PCEP session is established, the exchange of 355 Keepalive messages is optional) 357 4.2.2. Session Keepalive 359 Once a session has been established, a PCE or PCC may want to know 360 that its PCEP peer is still available for use. 362 It can rely on TCP for this information, but it is possible that the 363 remote PCEP function has failed without disturbing the TCP 364 connection. It is also possible to rely on the mechanisms built into 365 the TCP implementations, but these might not provide sufficiently 366 timely notifications of failures. Lastly, a PCC could wait until it 367 has a path computation request to send and use its failed 368 transmission or the failure to receive a response as evidence that 369 the session has failed, but this is clearly inefficient. 371 In order to handle this situation, PCEP includes a keepalive 372 mechanism based on a Keepalive timer, a Dead timer, and a Keepalive 373 message. 375 Each end of a PCEP session runs a Keepalive timer. It restarts the 376 timer every time it sends a message on the session. When the timer 377 expires, it sends a Keepalive message. Other traffic may serve as 378 Keepalive (see Section 6.3). 380 The ends of the PCEP session also run Dead timers, and they restart 381 them whenever a message is received on the session. If one end of 382 the session receives no message before the Dead timer expires, it 383 declares the session dead. 385 Note that this means that the Keepalive message is unresponded and 386 does not form part of a two-way keepalive handshake as used in some 387 protocols. Also note that the mechanism is designed to reduce to a 388 minimum the amount of keepalive traffic on the session. 390 The keepalive traffic on the session may be unbalanced according to 391 the requirements of the session ends. Each end of the session can 392 specify (on an Open message) the Keepalive timer that it will use 393 (i.e., how often it will transmit a Keepalive message if there is no 394 other traffic) and a Dead timer that it recommends its peer to use 395 (i.e., how long the peer should wait before declaring the session 396 dead if it receives no traffic). The session ends may use different 397 Keepalive timer values. 399 The minimum value of the Keepalive timer is 1 second, and it is 400 specified in units of 1 second. The recommended default value is 30 401 seconds. The timer may be disabled by setting it to zero. 403 The recommended default for the Dead timer is 4 times the value of 404 the Keepalive timer used by the remote peer. This means that there 405 is never any risk of congesting TCP with excessive Keepalive 406 messages. 408 4.2.3. Path Computation Request Sent By a PCC to a PCE 409 +-+-+ +-+-+ 410 |PCC| |PCE| 411 +-+-+ +-+-+ 412 1)Path computation | | 413 event | | 414 2)PCE Selection | | 415 3)Path computation |---- PCReq message--->| 416 request sent to | | 417 the selected PCE | | 419 Figure 2: Path Computation request 421 Once a PCC has successfully established a PCEP session with one or 422 more PCEs, if an event is triggered that requires the computation of 423 a set of paths, the PCC first selects one or more PCE. Note that the 424 PCE selection decision process may have taken place prior to the PCEP 425 session establishment. 427 Once the PCC has selected a PCE, it sends the PCE a path computation 428 request to the PCE (PCReq message) that contains a variety of objects 429 that specify the set of constraints and attributes for the path to be 430 computed. For example "Compute a TE LSP path with source IP 431 address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B 432 Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may 433 desire to specify the urgency of such request by assigning a request 434 priority. Each request is uniquely identified by a request-id number 435 and the PCC-PCE address pair. The process is shown in a schematic 436 form in Figure 2. 438 Note that multiple path computation requests may be outstanding from 439 one PCC to a PCE at any time. 441 Details about the PCReq message can be found in Section 6.4 443 4.2.4. Path Computation Reply Sent By The PCE to a PCC 444 +-+-+ +-+-+ 445 |PCC| |PCE| 446 +-+-+ +-+-+ 447 | | 448 |---- PCReq message--->| 449 | |1) Path computation 450 | |request received 451 | | 452 | |2)Path successfully 453 | |computed 454 | | 455 | |3) Computed paths 456 | |sent to the PCC 457 | | 458 |<--- PCRep message ---| 459 | (Positive reply) | 461 Figure 3a: Path Computation Request With Successful 462 Path Computation 464 +-+-+ +-+-+ 465 |PCC| |PCE| 466 +-+-+ +-+-+ 467 | | 468 | | 469 |---- PCReq message--->| 470 | |1) Path computation 471 | |request received 472 | | 473 | |2) No Path found that 474 | |satisfies the request 475 | | 476 | |3) Negative reply sent to 477 | |the PCC (optionally with 478 | |various additional 479 | |information) 480 |<--- PCRep message ---| 481 | (Negative reply) | 483 Figure 3b: Path Computation Request With Unsuccessful 484 Path Computation 486 Upon receiving a path computation request from a PCC, the PCE 487 triggers a path computation, the result of which can either be: 489 o Positive (Figure 3-a): the PCE manages to compute a path that 490 satisfies the set of required constraints, in which case the PCE 491 returns the set of computed paths to the requesting PCC. Note 492 that PCEP supports the capability to send a single request that 493 requires the computation of more than one path (e.g., computation 494 of a set of link-diverse paths). 496 o Negative (Figure 3-b): no path could be found that satisfies the 497 set of constraints. In this case, a PCE may provide the set of 498 constraints that led to the path computation failure. Upon 499 receiving a negative reply, a PCC may decide to resend a modified 500 request or take any other appropriate action. 502 Details about the PCRep message can be found in Section 6.5. 504 4.2.5. Notification 506 There are several circumstances in which a PCE may want to notify a 507 PCC of a specific event. For example, suppose that the PCE suddenly 508 gets overloaded, potentially leading to unacceptable response times. 509 The PCE may want to notify one or more PCCs that some of their 510 requests (listed in the notification) will not be satisfied or may 511 experience unacceptable delays. Upon receiving such notification, 512 the PCC may decide to redirect its path computation requests to 513 another PCE should an alternate PCE be available. Similarly, a PCC 514 may desire to notify a PCE of a particular event such as the 515 cancellation of pending requests. 517 +-+-+ +-+-+ 518 |PCC| |PCE| 519 +-+-+ +-+-+ 520 1)Path computation | | 521 event | | 522 2)PCE Selection | | 523 3)Path computation |---- PCReq message--->| 524 request X sent to | |4) Path computation 525 the selected PCE | |request queued 526 | | 527 | | 528 5) Path computation| | 529 request X cancelled| | 530 |---- PCNtf message -->| 531 | |6) Path computation 532 | |request X cancelled 534 Figure 4: Example of PCC Notification (Cancellation 535 Notification) 536 Sent To a PCE 538 +-+-+ +-+-+ 539 |PCC| |PCE| 540 +-+-+ +-+-+ 541 1)Path computation | | 542 event | | 543 2)PCE Selection | | 544 3)Path computation |---- PCReq message--->| 545 request X sent to | |4) Path computation 546 the selected PCE | |request queued 547 | | 548 | | 549 | |5) PCE gets overloaded 550 | | 551 | | 552 | |6) Path computation 553 | |request X cancelled 554 | | 555 |<--- PCNtf message----| 557 Figure 5: Example of PCE Notification (Cancellation 558 Notification) Sent To a PCC 560 Details about the PCNtf message can be found in Section 6.6. 562 4.2.6. Error 564 The PCEP Error message (also referred to as a PCErr message) is sent 565 in several situations: when a protocol error condition is met or when 566 the request is not compliant with the PCEP specification (e.g., 567 capability not supported, reception of a message with a mandatory 568 missing object, policy violation, unexpected message, unknown request 569 reference, ...). 571 +-+-+ +-+-+ 572 |PCC| |PCE| 573 +-+-+ +-+-+ 574 1)Path computation | | 575 event | | 576 2)PCE Selection | | 577 3)Path computation |---- PCReq message--->| 578 request X sent to | |4) Reception of a 579 the selected PCE | |malformed object 580 | | 581 | |5) Request discarded 582 | | 583 |<-- PCErr message ---| 584 | | 586 Figure 6: Example of Error message Sent By a PCE To a PCC 587 In Reply To The Reception Of a Malformed Object 589 Details about the PCErr message can be found in Section 6.7. 591 4.2.7. Termination of the PCEP Session 593 When one of the PCEP peers desires to terminate a PCEP session it 594 first sends a PCEP Close message and then closes the TCP connection. 595 If the PCEP session is terminated by the PCE, the PCC clears all the 596 states related to pending requests previously sent to the PCE. 597 Similarly, if the PCC terminates a PCEP session the PCE clears all 598 pending path computation requests sent by the PCC in question as well 599 as the related states. A Close message can only be sent to terminate 600 a PCEP session if the PCEP session has previously been established. 602 In case of TCP connection failure, the PCEP session is immediately 603 terminated. 605 Details about the Close message can be found in Section 6.8. 607 4.2.8. Intermitent versus Permanent PCEP Session 609 An implementation may decide to keep the PCEP session alive (and thus 610 the corresponding TCP connection) for an unlimited time (this may for 611 instance be appropriate when path computation requests are sent on a 612 frequent basis so as to avoid to open a TCP connection each time a 613 path computation request is needed, which would incur additional 614 processing delays). Conversely, in some other circumstances, it may 615 be desirable to systematically open and close a PCEP session for each 616 PCEP request (for instance when sending a path computation request is 617 a rare event). 619 5. Transport Protocol 621 PCEP operates over TCP using a registered TCP port (to be assigned by 622 IANA). This allows the requirements of reliable messaging and flow 623 control to be met without further protocol work. All PCEP message 624 MUST be sent using the registered TCP port for the source and 625 destination TCP port. 627 6. PCEP Messages 629 A PCEP message consists of a common header followed by a variable 630 length body made of a set of objects that can either be mandatory or 631 optional. In the context of this document, an object is said to be 632 mandatory in a PCEP message when the object MUST be included for the 633 message to be considered as valid. A PCEP message with a missing 634 mandatory object MUST trigger an Error message (see Section 7.15). 635 Conversely, if an object is optional, the object may or may not be 636 present. 638 A flag referred to as the P flag is defined in the common header of 639 each PCEP object (see Section 7.2). When this flag is set in an 640 object in a PCReq, the PCE MUST take the information carried in the 641 object into account during the path computation. For example, the 642 METRIC object defined in Section 7.8 allows a PCC to specify a 643 bounded acceptable path cost. The METRIC object is optional, but a 644 PCC may set a flag to ensure that the constraint is taken into 645 account. In this case, if the constraint cannot be taken into 646 account by the PCE, the PCE MUST trigger an Error message. 648 For each PCEP message type, rules are defined that specify the set of 649 objects that the message can carry. We use the Backus-Naur Form 650 (BNF) (see [I-D.farrel-rtg-common-bnf]) to specify such rules. 651 Square brackets refer to optional sub-sequences. An implementation 652 MUST form the PCEP messages using the object ordering specified in 653 this document. 655 6.1. Common header 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Ver | Flags | Message-Type | Message-Length | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Figure 7: PCEP Message Common Header 665 Ver (Version - 3 bits): PCEP version number. Current version is 666 version 1. 668 Flags (5 bits): no flags are currently defined. Unassigned bits are 669 considered as reserved. They MUST be set to zero on transmission and 670 MUST be ignored on receipt. 672 Message-Type (8 bits): 674 The following message types are currently defined (to be confirmed by 675 IANA). 676 Value Meaning 677 1 Open 678 2 Keepalive 679 3 Path Computation Request 680 4 Path Computation Reply 681 5 Notification 682 6 Error 683 7 Close 685 Message-Length (16 bits): total length of the PCEP message expressed 686 in bytes including the common header. 688 6.2. Open Message 690 The Open message is a PCEP message sent by a PCC to a PCE and a PCE 691 to a PCC in order to establish a PCEP session. The Message-Type 692 field of the PCEP common header for the Open message is set to 1 (To 693 be confirmed by IANA). 695 Once the TCP connection has been successfully established, the first 696 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 697 an Open message as specified in Appendix A. 699 Any message received prior to an Open message MUST trigger a protocol 700 error condition causing a PCErr message to be sent with Error-Type 701 'PCEP session establishment failure' and Error-Value 'reception of an 702 invalid Open message or a non Open message' and the PCEP session 703 establishment attempt MUST be terminated by closing the TCP 704 connection. 706 The Open message is used to establish a PCEP session between the PCEP 707 peers. During the establishment phase the PCEP peers exchange 708 several session characteristics. If both parties agree on such 709 characteristics the PCEP session is successfully established. 711 Open message 712 ::= 713 714 The Open message MUST contain exactly one OPEN object (see 715 Section 7.3). 717 Various session characteristics are specified within the OPEN object. 718 Once the TCP connection has been successfully established the sender 719 MUST start an initialization timer called OpenWait after the 720 expiration of which if no Open message has been received it sends a 721 PCErr message and releases the TCP connection (see Appendix A for 722 details). 724 Once an Open message has been sent to a PCEP peer, the sender MUST 725 start an initialization timer called KeepWait after the expiration of 726 which if neither a Keepalive message has been received nor a PCErr 727 message in case of disagreement of the session characteristics, a 728 PCErr message MUST be sent and the TCP connection MUST be released 729 (see Appendix A for details). 731 The KeepWait timer has a fixed value of 1 minute. 733 Upon the receipt of an Open message, the receiving PCEP peer MUST 734 determine whether the suggested PCEP session characteristics are 735 acceptable. If at least one of the characteristics is not acceptable 736 by the receiving peer, it MUST send an Error message. The Error 737 message SHOULD also contain the related Open object: for each 738 unacceptable session parameter, an acceptable parameter value SHOULD 739 be proposed in the appropriate field of the Open object in place of 740 the originally proposed value. The PCEP peer MAY decide to resend an 741 Open message with different session characteristics. If a second 742 Open message is received with the same set of parameters or with 743 parameters that are still unacceptable, the receiving peer MUST send 744 an Error message and it MUST immediately close the TCP connection. 745 Details about error message can be found in Section 7.15. Successive 746 retries are permitted but an implementation SHOULD make use of an 747 exponential back-off session establishment retry procedure. 749 If the PCEP session characteristics are acceptable, the receiving 750 PCEP peer MUST send a Keepalive message (defined in Section 6.3) that 751 serves as an acknowledgment. 753 The PCEP session is considered as established once both PCEP peers 754 have received a Keepalive message from their peer. 756 A PCEP implementation is free to process received requests in any 757 order. For example, the requests may be processed in the order they 758 are received, re-ordered and assigned priority according to local 759 policy, re-ordered according to the priority encoded in the RP Object 760 (Section 7.4.1), or processed in parallel. 762 6.3. Keepalive Message 764 A Keepalive message is a PCEP message sent by a PCC or a PCE in order 765 to keep the session in active state. The Keepalive message is also 766 used in response to an Open message to acknowledge that an Open 767 message has been received and that the PCEP session characteristics 768 are acceptable. The Message-Type field of the PCEP common header for 769 the Keepalive message is set to 2 (To be confirmed by IANA). The 770 Keepalive message does not contain any object. 772 PCEP has its own keepalive mechanism used to ensure of the liveness 773 of the PCEP session. This requires the determination of the 774 frequency at which each PCEP peer sends Keepalive messages. 775 Asymmetric values may be chosen; thus there is no constraint 776 mandating the use of identical keepalive frequencies by both PCEP 777 peers. The DeadTimer is defined as the period of time after the 778 expiration of which a PCEP peer declares the session down if no PCEP 779 message has been received (Keepalive or any other PCEP message: thus, 780 any PCEP message acts as a Keepalive message). Similarly, there is 781 no constraints mandating the use of identical DeadTimers by both PCEP 782 peers. The minimum Keepalive timer value is 1 second. Deployments 783 SHOULD consider carefully the impact of using low values for the 784 Keepalive timer as these might not give rise to the expected results 785 in periods of temporary network instability. 787 Keepalive messages are sent at the frequency specified in the OPEN 788 object carried within an Open message according to the rules 789 specified in Section 7.3. Because any PCEP message may serve as 790 Keepalive, an implementation may either decide to send Keepalive 791 messages at fixed intervals regardless on whether other PCEP messages 792 might have been sent since the last sent Keepalive message, or may 793 decide to differ the sending of the next Keepalive message based on 794 the time at which the last PCEP message (other than Keepalive) was 795 sent. 797 Note that sending Keepalive messages to keep the session alive is 798 optional and PCEP peers may decide to not send Keepalive messages 799 once the PCEP session is established in which case the peer that does 800 not receive Keepalive messages does not expect to receive them and 801 MUST NOT declare the session as inactive. 803 Keepalive message 804 ::= 806 6.4. Path Computation Request (PCReq) Message 808 A Path Computation Request message (also referred to as a PCReq 809 message) is a PCEP message sent by a PCC to a PCE to request a path 810 computation. A PCReq message may carry more than one path 811 computation request. The Message-Type field of the PCEP common 812 header for the PCReq message is set to 3 (To be confirmed by IANA). 814 There are two mandatory objects that MUST be included within a PCReq 815 message: the RP and the END-POINTS objects (see section Section 7). 816 If one or both of these objects is missing, the receiving PCE MUST 817 send an error message to the requesting PCC. Other objects are 818 optional. 820 The format of a PCReq message is as follows: 821 ::= 822 [] 823 825 where: 826 ::=[] 827 ::=[] 829 ::= 830 831 [] 832 [] 833 [] 834 [[]] 835 [] 836 [] 837 where: 839 ::=[] 841 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 842 BALANCING objects are defined in Section 7. The special case of two 843 BANDWIDTH objects is discussed in detail in Section 7.7. 845 6.5. Path Computation Reply (PCRep) Message 847 The PCEP Path Computation Reply message (also referred to as a PCRep 848 message) is a PCEP message sent by a PCE to a requesting PCC in 849 response to a previously received PCReq message. The Message-Type 850 field of the PCEP common header is set to 4 (To be confirmed by 851 IANA). 853 The bundling of multiple replies to a set of path computation 854 requests within a single PCRep message is supported by PCEP. If a 855 PCE receives non-synchronized path computation requests by means of 856 one or more PCReq messages from a requesting PCC it MAY decide to 857 bundle the computed paths within a single PCRep message so as to 858 reduce the control plane load. Note that the counter side of such an 859 approach is the introduction of additional delays for some path 860 computation requests of the set. Conversely, a PCE that receives 861 multiple requests within the same PCReq message MAY decide to provide 862 each computed path in separate PCRep messages or within the same 863 PCRep message. A PCRep message may contain positive and negative 864 replies. 866 A PCRep message may contain a set of computed paths corresponding to 867 either a single path computation request with load-balancing (see 868 Section 7.16) or multiple path computation requests originated by a 869 requesting PCC. The PCRep message may also contain multiple 870 acceptable paths corresponding to the same request. 872 The PCRep message MUST contain at least one RP object. For each 873 reply that is bundled into a single PCReq message, an RP object MUST 874 be included that contains a Request-ID-number identical to the one 875 specified in the RP object carried in the corresponding PCReq message 876 (see Section 7.4 for the definition of the RP object). 878 If the path computation request can be satisfied (the PCE finds a set 879 of paths that satisfy the set of constraints), the set of computed 880 paths specified by means of ERO objects is inserted in the PCRep 881 message. The ERO is defined in Section 7.9. The situation where 882 multiple computed paths are provided in a PCRep message is discussed 883 in detail in Section 7.13. Furthermore, when a PCC requests the 884 computation of a set of paths for a total amount of bandwidth by 885 means of a LOAD-BALANCING object carried within a PCReq message, the 886 ERO of each computed path may be followed by a BANDWIDTH object as 887 discussed in section Section 7.16. 889 If the path computation request cannot be satisfied, the PCRep 890 message MUST include a NO-PATH object. The NO-PATH object (described 891 in Section 7.5) may also contain other information (e.g, reasons for 892 the path computation failure). 894 The format of a PCRep message is as follows: 895 ::= 896 898 where: 899 ::=[] 901 ::= 902 [] 903 [] 904 [] 906 ::=[] 908 ::= 910 where: 912 ::=[] 913 [] 914 [] 915 [] 917 ::=[] 919 6.6. Notification (PCNtf) Message 921 The PCEP Notification message (also referred to as the PCNtf message) 922 can be sent either by a PCE to a PCC, or by a PCC to a PCE, to notify 923 of a specific event. The Message-Type field of the PCEP common 924 header is set to 5 (To be confirmed by IANA). 926 The PCNtf message MUST carry at least one NOTIFICATION object and MAY 927 contain several NOTIFICATION objects should the PCE or the PCC intend 928 to notify of multiple events. The NOTIFICATION object is defined in 929 Section 7.14. The PCNtf message MAY also contain RP objects (see 930 Section 7.4 when the notification refers to particular path 931 computation requests. 933 The PCNtf message may be sent by a PCC or a PCE in response to a 934 request or in an unsolicited manner. 936 The format of a PCNtf message is as follows: 937 ::= 938 940 ::= [] 942 ::= [] 943 945 ::=[] 947 ::=[] 949 6.7. Error (PCErr) Message 951 The PCEP Error message (also referred to as a PCErr message) is sent 952 in several situations: when a protocol error condition is met or when 953 the request is not compliant with the PCEP specification (e.g., 954 reception of a malformed message, reception of a message with a 955 mandatory missing object, policy violation, unexpected message, 956 unknown request reference, ...). The Message-Type field of the PCEP 957 common header is set to 6 (To be confirmed by IANA). 959 The PCErr message is sent by a PCC or a PCE in response to a request 960 or in an unsolicited manner. If the PCErr message is sent in 961 response to a request, the PCErr message MUST include the set of RP 962 objects related to the pending path computation requests that 963 triggered the error condition. In the later case (unsolicited), no 964 RP object is inserted in the PCErr message. For example, no RP 965 object is inserted in a PCErr when the error condition occurred 966 during the initialization phase. A PCErr message MUST contain a 967 PCEP-ERROR object specifying the PCEP error condition. The PCEP- 968 ERROR object is defined in section Section 7.15. 970 The format of a PCErr message is as follows: 971 ::= 972 ( [] ) | 973 [] 975 ::=[] 976 ::=[] 977 978 ::=[] 979 ::=[] 981 The procedure upon the receipt of a PCErr message is defined in 982 Section 7.15. 984 6.8. Close Message 986 The Close message is a PCEP message that is either sent by a PCC to a 987 PCE or by a PCE to a PCC in order to close an established PCEP 988 session. The Message-Type field of the PCEP common header for the 989 Close message is set to 7 (To be confirmed by IANA). 991 Close message 992 ::= 993 995 The Close message MUST contain exactly one CLOSE object (see 996 Section 6.8). If more than one CLOSE object is present, the first 997 MUST be processed and subsequent objects ignored. 999 Upon the receipt of a valid Close message, the receiving PCEP peer 1000 MUST cancel all pending requests, it MUST close the TCP connection 1001 and MUST NOT send any further PCEP messages on the PCEP session. 1003 6.9. Reception of Unknown Messages 1005 A PCEP implementation that receives an unrecognized PCEP message MUST 1006 send a PCErr message with Error-value=2 (capability not supported). 1008 If a PCC/PCE receives unrecognized messages at a rate equal of 1009 greater than MAX-UNKNOWN-MESSAGES unknown message requests per 1010 minute, the PCC/PCE MUST send a PCEP CLOSE message with close 1011 value="Reception of an unacceptable number of unknown PCEP message". 1012 A RECOMMENDED value for MAX-UNKOWN-MESSAGES is 5. The PCC/PCE MUST 1013 close the TCP session and MUST NOT send any further PCEP messages on 1014 the PCEP session. 1016 7. Object Formats 1018 PCEP objects have a common format. They begin with a common object 1019 header (see Section 7.2). This is followed by object-specific fields 1020 defined for each different object. The object may also include one 1021 or more type-length-value (TLV) encoded data sets. Each TLV has the 1022 same structure as described in Section 7.1. 1024 7.1. PCE TLV Format 1026 A PCEP object may include a set of one or more optional TLVs. 1028 All PCEP TLVs have the following format: 1030 Type: 2 bytes 1031 Length: 2 bytes 1032 Value: variable 1033 A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes 1034 specifying the TLV length, and a value field. 1036 The Length field defines the length of the value portion in bytes. 1037 The TLV is padded to 4-bytes alignment; padding is not included in 1038 the Length field (so a three byte value would have a length of three, 1039 but the total size of the TLV would be eight bytes). 1041 Unrecognized TLVs MUST be ignored. 1043 IANA management of the PCEP Object TLV type identifier codespace is 1044 described in Section 9. 1046 7.2. Common Object Header 1048 A PCEP object carried within a PCEP message consists of one or more 1049 32-bit words with a common header which has the following format: 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Object-Class | OT |Res|P|I| Object Length (bytes) | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | | 1056 // (Object body) // 1057 | | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 Figure 8: PCEP common object header 1062 Object-Class (8 bits): identifies the PCEP object class. 1064 OT (Object-Type - 4 bits): identifies the PCEP object type. 1066 The Object-Class and Object-Type fields are managed by IANA. 1068 The Object-Class and Object-Type fields uniquely identify each PCEP 1069 object. 1071 Res flags (2 bits). Reserved field. This field MUST be set to zero 1072 on transmission and MUST be ignored on receipt. 1074 o P flag (Processing-Rule - 1-bit): the P flag allows a PCC to 1075 specify in a PCReq message sent to a PCE whether the object must 1076 be taken into account by the PCE during path computation or is 1077 just optional. When the P flag is set, the object MUST be taken 1078 into account by the PCE. Conversely, when the P flag is cleared, 1079 the object is optional and the PCE is free to ignore it. 1081 o I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 1082 message to indicate to a PCC whether or not an optional object was 1083 processed. The PCE MAY include the ignored optional object in its 1084 reply and set the I flag to indicate that the optional object was 1085 ignored during path computation. When the I flag is cleared, the 1086 PCE indicates that the optional object was processed during the 1087 path computation. The setting of the I flag for optional objects 1088 is purely indicative and optional. The I flag has no meaning in a 1089 PCRep message when the P flag has been set in the corresponding 1090 PCReq message. 1092 If the PCE does not understand an object with the P flag set or 1093 understands the object but decides to ignore the object, the entire 1094 PCEP message MUST be rejected and the PCE MUST send a PCErr message 1095 with Error-Type="Unknown Object" or "Not supported Object" along with 1096 the corresponding RP object. Note that if a PCReq includes multiple 1097 requests, only requests for which an object with the P flag set is 1098 unknown/unrecognized MUST be rejected. 1100 Object Length (16 bits). Specifies the total object length including 1101 the header, in bytes. The Object Length field MUST always be a 1102 multiple of 4, and at least 4. The maximum object content length is 1103 65528 bytes. 1105 7.3. OPEN Object 1107 The OPEN object MUST be present in each Open message and MAY be 1108 present in a PCErr message. There MUST be only one OPEN object per 1109 Open or PCErr message. 1111 The OPEN object contains a set of fields used to specify the PCEP 1112 version, Keepalive frequency, DeadTimer, PCEP session ID along with 1113 various flags. The OPEN object may also contain a set of TLVs used 1114 to convey various session characteristics such as the detailed PCE 1115 capabilities, policy rules and so on. No TLVs are currently defined. 1117 OPEN Object-Class is to be assigned by IANA (recommended value=1) 1119 OPEN Object-Type is to be assigned by IANA (recommended value=1) 1120 The format of the OPEN object body is as follows: 1122 0 1 2 3 1123 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 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Ver | Flags | Keepalive | DeadTimer | SID | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | | 1128 // Optional TLVs // 1129 | | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 Figure 9: OPEN Object format 1134 Ver (3 bits): PCEP version. Current version is 1. 1136 Flags (5 bits): No Flags are currently defined. Unassigned bits are 1137 considered as reserved. They MUST be set to zero on transmission and 1138 MUST be ignored on receipt. 1140 Keepalive (8 bits): maximum period of time (in seconds) between two 1141 consecutive PCEP messages sent by the sender of this message. The 1142 minimum value for the Keepalive is 1 second. When set to 0, once the 1143 session is established, no further Keepalive messages are sent to the 1144 remote peer. A RECOMMENDED value for the keepalive frequency is 30 1145 seconds. 1147 DeadTimer (8 bits): specifies the amount of time after the expiration 1148 of which the PCEP peer can declare the session with the sender of the 1149 Open message down if no PCEP message has been received. The 1150 DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is 1151 set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value 1152 of the Keepalive. 1154 Example: 1156 A sends an Open message to B with Keepalive=10 seconds and 1157 Deadtimer=40 seconds. This means that A sends Keepalive messages (or 1158 any other PCEP message) to B every 10 seconds and B can declare the 1159 PCEP session with A down if no PCEP message has been received from A 1160 within any 40 second period. 1162 SID (PCEP session-ID - 8 bits): unsigned PCEP session number that 1163 identifies the current session. The SID MUST be incremented each 1164 time a new PCEP session is established and is used for logging and 1165 troubleshooting purposes. Each increment SHOULD have a value of 1 1166 and may cause a wrap back to zero. 1168 The SID is used to disambiguate instances of sessions to the same 1169 peer. A PCEP implementation could use a single source of SIDs across 1170 all peers, or one source for each peer. The former might constrain 1171 the implementation to only 256 concurrent sessions. The latter 1172 potentially requires more states. There is one SID number in each 1173 direction. 1175 Optional TLVs may be included within the OPEN object body to specify 1176 PCC or PCE characteristics. The specification of such TLVs is 1177 outside the scope of this document. 1179 When present in an Open message, the OPEN object specifies the 1180 proposed PCEP session characteristics. Upon receiving unacceptable 1181 PCEP session characteristics during the PCEP session initialization 1182 phase, the receiving PCEP peer (PCE) MAY include an OPEN object 1183 within the PCErr message so as to propose alternative acceptable 1184 session characteristic values. 1186 7.4. RP Object 1188 The RP (Request Parameters) object MUST be carried within each PCReq 1189 and PCRep messages and MAY be carried within PCNtf and PCErr 1190 messages. The RP object is used to specify various characteristics 1191 of the path computation request. 1193 The P flag of the RP object MUST be set in PCReq and PCReq messages 1194 and MUST be cleared in PCNtf and PCErr messages. If the RP objet is 1195 received with the P flag set incorrectely according to the rules 1196 states above, the receiving peer MUST send a PCErr message with 1197 Error-type=10 and Error-value=1. The corresponding path computation 1198 request MUST be cancelled by the PCE without further notification. 1200 7.4.1. Object Definition 1202 RP Object-Class is to be assigned by IANA (recommended value=2) 1204 RP Object-Type is to be assigned by IANA (recommended value=1) 1205 The format of the RP object body is as follows: 1207 0 1 2 3 1208 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 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Flags |O|B|R| Pri | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Request-ID-number | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | | 1215 // Optional TLVs // 1216 | | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 Figure 10: RP object body format 1221 The RP object body has a variable length and may contain additional 1222 TLVs. No TLVs are currently defined. 1224 Flags (24 bits) 1226 The following flags are currently defined: 1228 o Pri (Priority - 3 bits): the Priority field may be used by the 1229 requesting PCC to specify to the PCE the request's priority from 1 1230 to 7. The decision of which priority should be used for a 1231 specific request is of a local matter and MUST be set to 0 when 1232 unused. Furthermore, the use of the path computation request 1233 priority by the PCE's scheduler is implementation specific and out 1234 of the scope of this document. Note that it is not required for a 1235 PCE to support the priority field: in this case, it is RECOMMENDED 1236 that the PCC set the priority field to 0 in the RP object. If the 1237 PCE does not take into account the request priority, it is 1238 RECOMMENDED to set the priority field to 0 in the RP object 1239 carried within the corresponding PCRep message, regardless of the 1240 priority value contained in the RP object carried within the 1241 corresponding PCReq message. A higher numerical value of the 1242 priority field reflects a higher priority. Note that it is the 1243 responsibility of the network administrator to make use of the 1244 priority values in a consistent manner across the various PCCs. 1245 The ability of a PCE to support request prioritization MAY be 1246 dynamically discovered by the PCCs by means of PCE capability 1247 discovery. If not advertised by the PCE, a PCC may decide to set 1248 the request priority and will learn the ability of the PCE to 1249 support request prioritization by observing the Priority field of 1250 the RP object received in the PCRep message. If the value of the 1251 Pri field is set to 0, this means that the PCE does not support 1252 the handling of request priorities: in other words, the path 1253 computation request has been honoured but without taking the 1254 request priority into account. 1256 o R (Reoptimization - 1 bit): when set, the requesting PCC specifies 1257 that the PCReq message relates to the reoptimization of an 1258 existing TE LSP. For all TE LSPs except 0-bandwidth LSPs, when 1259 the R bit is set, an RRO (see Section 7.10) MUST be included in 1260 the PCReq message to show the path of the existing TE LSP. Also, 1261 for all TE LSPs except 0-bandwidth LSPs, then the R bit is set, 1262 the existing bandwidth of the TE LSP to be reoptimized MUST be 1263 supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH 1264 object is in addition to the instance of that object used to 1265 describe the desired bandwidth of the reoptimized LSP. For 1266 0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the 1267 characteristics of the existing TE LSP are optional. 1269 o B (Bi-directional - 1 bit): when set, the PCC specifies that the 1270 path computation request relates to a bidirectional TE LSP that 1271 has the same traffic engineering requirements including fate 1272 sharing, protection and restoration, LSRs, TE Links, and resource 1273 requirements (e.g., latency and jitter) in each direction. When 1274 cleared, the TE LSP is unidirectional. 1276 o O (strict/loose - 1 bit): when set, in a PCReq message, this 1277 indicates that a loose path is acceptable. Otherwise, when 1278 cleared, this indicates to the PCE that a path exclusively made of 1279 strict hops is required. In a PCRep message, when the O bit is 1280 set this indicates that the returned path is a loose path, 1281 otherwise (the O bit is cleared), the returned path is made of 1282 strict hops. 1284 Unassigned bits are considered as reserved. They MUST be set to zero 1285 on transmission and MUST be ignored on receipt. 1287 Request-ID-number (32 bits). The Request-ID-number value combined 1288 with the source IP address of the PCC and the PCE address uniquely 1289 identify the path computation request context. The Request-ID-number 1290 is used for disambiguation between pending requests and thus it MUST 1291 be changed (such as by incrementing it) each time a new request is 1292 sent to the PCE, and may wrap. 1294 The value 0x00000000 is considered as invalid. 1296 If no path computation reply is received from the PCE (e.g. request 1297 dropped by the PCE because of memory overflow), and the PCC wishes to 1298 resend its request, the same Request-ID-number MUST be used. Upon 1299 receiving a path computation request from a PCC with the same 1300 Request-ID-number the PCE SHOULD treat the request as a new request 1301 but an implementation MAY choose to cach path computation replies in 1302 order to quickly handle restranmission without having to handle twice 1303 a path computation request should have the first request been dropped 1304 or lost. Upon receiving a path computation reply from a PCE with the 1305 same Request-ID-number the PCC SHOULD silently discard the path 1306 computation reply. 1308 Conversely, different Request-ID-number MUST be used for different 1309 requests sent to a PCE. 1311 The same Request-ID-number MAY be used for path computation requests 1312 sent to different PCEs. The path computation reply is unambiguously 1313 identified by the IP source address of the replying PCE. 1315 7.4.2. Handling of the RP Object 1317 If a PCReq message is received that does not contain an RP object, 1318 the PCE MUST send a PCErr message to the requesting PCC with Error- 1319 type="Required Object missing" and Error-value="RP Object missing". 1321 If the O bit of the RP message carried within a PCReq message is 1322 cleared and local policy has been configured on the PCE to not 1323 provide explicit paths (for instance, for confidentiality reasons), a 1324 PCErr message MUST be sent by the PCE to the requesting PCC and the 1325 pending path computation request MUST be discarded. The Error-type 1326 is "Policy Violation" and Error-value is "O bit cleared". 1328 R bit: when the R bit of the RP object is set in a PCReq message, 1329 this indicates that the path computation request relates to the 1330 reoptimization of an existing TE LSP. In this case, the PCC MUST 1331 also provide the strict/loose path by including an RRO object in the 1332 PCReq message so as to avoid/limit double bandwidth counting if and 1333 only if the TE LSP is a non-0-bandwidth TE LSP. If the PCC has not 1334 requested a strict path (O bit set), a reoptimization can still be 1335 requested by the PCC but this requires that the PCE either be 1336 stateful (keep track of the previously computed path with the 1337 associated list of strict hops), or have the ability to retrieve the 1338 complete required path segment. Alternatively the PCC MUST inform 1339 the PCE of the working path with the associated list of strict hops 1340 in PCReq. The absence of an RRO in the PCReq message for a non-0- 1341 bandwidth TE LSP when the R bit of the RP object is set MUST trigger 1342 the sending of a PCErr message with Error-type="Required Object 1343 Missing" and Error-value="RRO Object missing for reoptimization". 1345 If a PCC/PCE receives a PCRep/PCReq message that contains a RP object 1346 referring to an unknown Request-ID-Number, the PCC/PCE MUST send a 1347 PCErr message with Error-Type="Unknown request reference". This is 1348 used for debugging purposes. If a PCC/PCE receives PCRep/PCReq at a 1349 rate equal of greater than MAX-UNKOWN-REQUESTS unknown requests per 1350 minute, the PCC/PCE MUST send a PCEP CLOSE message with close 1351 value="Reception of an unacceptable number of unknown requests/ 1352 replies". A RECOMMENDED value for MAX-UNKOWN-REQUESTS is 5. The 1353 PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP 1354 messages on the PCEP session. 1356 The reception of a PCEP message that contains a RP object referring 1357 to a Request-ID-number=0x00000000 MUST be treated similarly to an 1358 unkown request. 1360 7.5. NO-PATH Object 1362 The NO-PATH object is used in PCRep messages in response to an 1363 unsuccessful path computation request (the PCE could not find a path 1364 satisfying the set of constraints). When a PCE cannot find a path 1365 satisfying a set of constraints, it MUST include a NO-PATH object in 1366 the PCRep message. 1368 There are several categories of issue that can lead to a negative 1369 reply. For example, the PCE chain might be broken (should there be 1370 more than one PCE involved in the path computation) or no path 1371 obeying the set constraints could be found. The "NI (Nature of 1372 Issue)" field in the NO-PATH object is used to report the error 1373 category. 1375 Optionally, if the PCE supports such capability, the NO-PATH object 1376 MAY contain an optional NO-PATH-VECTOR TLV defined below and used to 1377 provide more information on the reasons that led to a negative reply. 1378 The PCRep message MAY also contain a list of objects that specify the 1379 set of constraints that could not be satisfied. The PCE MAY just 1380 replicate the set of objects that was received that was the cause of 1381 the unsuccessful computation or MAY optionally report a suggested 1382 value for which a path could have been found (in which case the value 1383 differs from the value in the original request). 1385 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1387 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1388 The format of the NO-PATH object body is as follows: 1390 0 1 2 3 1391 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 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 |Nature Of Issue|C| Flags | Reserved | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | | 1396 // Optional TLVs // 1397 | | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 Figure 11: NO-PATH Object Format 1402 NI - Nature Of Issue (8 bits): the NI field is used to report the 1403 nature of the issue that led to a negative reply. Two values are 1404 currently defined: 1406 0x00: No path satisfying the set of constraints could be found 1408 0x01: PCE chain broken 1410 The Nature Of Issue field value can be used by the PCC for various 1411 purposes: 1413 o Constraint adjustement before re-issuing a new path computation 1414 request, 1416 o Explicit selection of a new PCE chain, 1418 o Logging of the error type for futher action by the network 1419 admistrator 1421 IANA management of the NI field codespace is described in Section 9. 1423 Flags (16 bits). 1425 The following flag is currently defined: 1427 C flag (1 bit): when set, the PCE indicates the set of unsatisfied 1428 constraints (reasons why a path could not be found) in the PCRep 1429 message by including the relevant PCEP objects. When cleared, no 1430 failing constraints are specified. The C flag has no meaning and is 1431 ignored unless the NI field is set to 0x00. 1433 Unassigned bits are considered as reserved. They MUST be set to zero 1434 on transmission and MUST be ignored on receipt. 1436 Reserved (8 bits): This field MUST be set to zero on transmission and 1437 MUST be ignored on receipt. 1439 The NO-PATH object body has a variable length and may contain 1440 additional TLVs. The only TLV currently defined is the NO-PATH- 1441 VECTOR TLV defined below. 1443 Example: consider the case of a PCC that sends a path computation 1444 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1445 find a path for X MBits/s. In this case, the PCE must include in the 1446 PCRep message a NO-PATH object. Optionally the PCE may also include 1447 the original BANDWIDTH object so as to indicate that the reason for 1448 the unsuccessful computation is the bandwidth constraint (in this 1449 case, the NI field value is 0x00 and C flag is set). If the PCE 1450 supports such capability it may alternatively include the BANDWIDTH 1451 Object and report a value of Y in the bandwidth field of the 1452 BANDWIDTH object (in this case, the C flag is set) where Y refers to 1453 the bandwidth for which a TE LSP with the same other characteristics 1454 could have been computed. 1456 When the NO-PATH object is absent from a PCRep message, the path 1457 computation request has been fully satisfied and the corresponding 1458 paths are provided in the PCRep message. 1460 An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH 1461 object in order to provide more information on the reasons that led 1462 to a negative reply. 1464 The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in 1465 section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying 1466 the TLV length (length of the value portion in bytes) followed by a fixed 1467 length value field of 32-bit flags field. 1469 TYPE: To be assigned by IANA (suggested value=1) 1470 LENGTH: 4 1471 VALUE: 32-bit flags field 1473 IANA is requested to manage the space of flags carried in the NO- 1474 PATH-VECTOR TLV (see Section 9). 1476 The following flags are currently defined: 1478 o Bit number: 31 - PCE currently unavailable 1480 o Bit number: 30 - Unknown destination 1482 o Bit number: 29 - Unknown source 1484 7.6. END-POINT Object 1486 The END-POINTS object is used in a PCReq message to specify the 1487 source IP address and the destination IP address of the path for 1488 which a path computation is requested. The P flag of the END-POINT 1489 object MUST be set. If the END-POINT objet is received with the P 1490 flag cleared, the receiving peer MUST send a PCErr message with 1491 Error-type=10 and Error-value=1. The corresponding path computation 1492 request MUST be cancelled by the PCE without further notification. 1494 Note that the source and destination addresses specified in the END- 1495 POINTS object may or may not correspond to the source and destination 1496 IP address of the TE LSP but rather to a path segment. Two END- 1497 POINTS objects (for IPv4 and IPv6) are defined. 1499 END-POINTS Object-Class is to be assigned by IANA (recommended 1500 value=4) 1502 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 1503 for IPv4 and 2 for IPv6) 1504 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1505 as follows: 1507 0 1 2 3 1508 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 | Source IPv4 address | 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 | Destination IPv4 address | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 Figure 12: END-POINTS Object Body Format for IPv4 1517 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 1519 0 1 2 3 1520 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 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | | 1523 | Source IPv6 address (16 bytes) | 1524 | | 1525 | | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | | 1528 | Destination IPv6 address (16 bytes) | 1529 | | 1530 | | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 Figure 13: END-POINTS Object Body Format for IPv6 1535 The END-POINTS object body has a fixed length of 8 bytes for IPv4 and 1536 32 bytes for IPv6. 1538 If more than one END-POINTS object is present, the first MUST be 1539 processed and subsequent objects ignored. 1541 7.7. BANDWIDTH Object 1543 The BANDWIDTH object is used to specify the requested bandwidth for a 1544 TE LSP. The notion of bandwidth is similar to the one used for RSVP 1545 signaling in [RFC2205], [RFC3209] and [RFC3473]. 1547 If the requested bandwidth is equal to 0, the BANDWIDTH object is 1548 optional. Conversely, if the requested bandwidth is non equal to 0, 1549 the PCReq message MUST contain a BANDWIDTH object. 1551 In the case of the reoptimization of a TE LSP, the bandwidth of the 1552 existing TE LSP MUST also be included in addition to the requested 1553 bandwidth if and only if the two values differ. Consequently, two 1554 Object-Type values are defined that refer to the requested bandwidth 1555 and the bandwidth of the TE LSP for which a reoptimization is being 1556 performed. 1558 The BANDWIDTH object may be carried within PCReq and PCRep messages. 1560 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1561 value=5) 1563 Two Object-Type values are defined for the BANDWIDTH object: 1565 o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by 1566 IANA (recommended value=1) 1568 o Bandwidth of an existing TE LSP for which a reoptimization is 1569 requested. BANDWIDTH Object-Type is to be assigned by IANA 1570 (recommended value=2) 1572 The format of the BANDWIDTH object body is as follows: 1574 0 1 2 3 1575 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 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | Bandwidth | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 Figure 14: BANDWIDTH Object Body Format 1582 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1583 IEEE floating point format (see [IEEE.754.1985]), expressed in bytes 1584 per second. Refer to Section 3.1.2 of [RFC3471] for a table of 1585 commonly used values. 1587 The BANDWIDTH object body has a fixed length of 4 bytes. 1589 7.8. METRIC Object 1591 The METRIC object is optional and can be used for several purposes. 1593 In a PCReq message, a PCC MAY insert one of more METRIC objects: 1595 o To indicate the metric that MUST be optimized by the path 1596 computation algorithm (IGP metric, TE metric, Hop counts). 1597 Currently, three metrics are defined: the IGP cost, the TE metric 1598 (see [RFC3785]) and the number of hops traversed by a TE LSP. 1600 o To indicate a bound on the path cost that MUST NOT be exceeded for 1601 the path to be considered as acceptable by the PCC. 1603 In a PCRep message, the METRIC object MAY be inserted so as to 1604 provide the cost for the computed path. It MAY also be inserted 1605 within a PCRep with the NO-PATH object to indicate that the metric 1606 constraint could not be satisfied. 1608 The path computation algorithmic aspects used by the PCE to optimize 1609 a path with respect to a specific metric are outside the scope of 1610 this document. 1612 It must be understood that such path metrics are only meaningful if 1613 used consistently: for instance, if the delay of a computed path 1614 segment is exchanged between two PCEs residing in different domains, 1615 consistent ways of defining the delay must be used. 1617 The absence of the METRIC object MUST be interpreted by the PCE as a 1618 path computation request for which no constraints need be applied to 1619 any of the metrics. 1621 METRIC Object-Class is to be assigned by IANA (recommended value=6) 1623 METRIC Object-Type is to be assigned by IANA (recommended value=1) 1625 The format of the METRIC object body is as follows: 1627 0 1 2 3 1628 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 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Reserved | Flags |C|B| T | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | metric-value | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 Figure 15: METRIC Object Body Format 1637 The METRIC object body has a fixed length of 8 bytes. 1639 Reserved (16 bits): This field MUST be set to zero on transmission 1640 and MUST be ignored on receipt. 1642 T (Type - 8 bits): Specifies the metric type. 1644 Three values are currently defined: 1646 o T=1: IGP metric 1648 o T=2: TE metric 1650 o T=3: Hop Counts 1652 Flags (8 bits): Two flags are currently defined: 1654 o B (Bound - 1 bit): When set in a PCReq message, the metric-value 1655 indicates a bound (a maximum) for the path metric that must not be 1656 exceeded for the PCC to consider the computed path as acceptable. 1657 The path metric must be less than or equal to the value specified 1658 in the Metric-value field. When the B flag is cleared, the 1659 metric-value field is not used to reflect a bound constraint. 1661 o C (Computed Metric - 1 bit): When set in a PCReq message, this 1662 indicates that the PCE MUST provide the computed path metric value 1663 (should a path satisfying the constraints be found) in the PCRep 1664 message for the corresponding metric. 1666 Unassigned flags MUST be set to zero on transmission and MUST be 1667 ignored on receipt. 1669 Metric-value (32 bits): metric value encoded in 32 bits in IEEE 1670 floating point format (See [IEEE.754.1985]). 1672 Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 1673 message. There MUST be at most one instance of the METRIC object for 1674 each metric type with the same B flag value. If two or more 1675 instances of a METRIC object with the same B flag value are present 1676 for a metric type, only the first instance MUST be considered and 1677 other instances MUST be ignored. 1679 The presence of two METRIC objects of the same type with a different 1680 value of the B-Flag in a PCEReq message is allowed. Furthermore, it 1681 is also allowed to insert in a PCReq message two METRIC objects with 1682 different types that have both their B-Flag cleared: in this case, an 1683 objective function must be used by the PCE to solve a multi-parameter 1684 constraint problem. 1686 A METRIC object used to indicate the metric to optimize during the 1687 path computation MUST have the B-Flag cleared and the C-Flag set to 1688 the appropriate value. When the path computation relates to the 1689 reoptimization of an exiting TE LSP (in which case R-Flag of the RP 1690 object is set) an implementation MAY decide to set the metric-value 1691 field to the computed value of the metric of the TE LSP to be 1692 reoptimized with regards to a specific metric type. 1694 A METRIC object used to reflect a bound MUST have the B-Flag set, the 1695 C-Flag and metric-value field set to the appropriate values. 1697 In a PCRep message, unless not allowed by PCE policy, at least one 1698 METRIC object MUST be present that reports the computed path metric 1699 if the C bit of the METRIC object was set in the corresponding path 1700 computation request (the B-flag MUST be cleared). The C-flag has no 1701 meaning in a PCRep message. Optionally the PCRep message MAY contain 1702 additional METRIC objects that correspond to bound constraints, in 1703 which case the metric-value MUST be equal to the corresponding 1704 computed path metric (the B-flag MUST be set). If no path satisfying 1705 the constraints could be found by the PCE, the METRIC objects MAY 1706 also be present in the PCRep message with the NO-PATH object to 1707 indicate the constraint metric that could be satisfied. 1709 Example: if a PCC sends a path computation request to a PCE where the 1710 metric to optimize is the IGP metric and the TE metric must not 1711 exceed the value of M, two METRIC object are inserted in the PCReq 1712 message: 1714 o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000 1716 o Second METRIC Object with B=1, T=2, metric-value=M 1718 If a path satisfying the set of constraints can be found by the PCE 1719 and there is no policy that prevents the return of the computed 1720 metric, the PCE inserts one METRIC object with B=0, T=1, metric- 1721 value= computed IGP path cost. Additionally, the PCE may insert a 1722 second METRIC object with B=1, T=2, metric-value= computed TE path 1723 cost. 1725 7.9. Explicit Route Object 1727 The ERO is used to encode the path of a TE LSP through the network. 1728 The ERO is carried within a PCRep message to provide the computed TE 1729 LSP should the path computation have been successful. 1731 The contents of this object are identical in encoding to the contents 1732 of the Resource Reservation Protocol Traffic Engineering Extensions 1733 (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473] 1734 and [RFC3477]. That is, the object is constructed from a series of 1735 sub-objects. Any RSVP-TE ERO sub-object already defined or that 1736 could be defined in the future for use in the RSVP-TE ERO is 1737 acceptable in this object. 1739 PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types. 1741 Since the explicit path is available for immediate signaling by the 1742 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1743 and fields in this object are identical to those defined for the ERO. 1745 ERO Object-Class is to be assigned by IANA (recommended value=7) 1747 ERO Object-Type is to be assigned by IANA (recommended value=1) 1749 7.10. Reported Route Object 1751 The RRO is exclusively carried within a PCReq message so as to report 1752 the route followed by a TE LSP for which a reoptimization is desired. 1754 The contents of this object are identical in encoding to the contents 1755 of the Route Record Object defined in [RFC3209], [RFC3473] and 1756 [RFC3477]. That is, the object is constructed from a series of sub- 1757 objects. Any RSVP-TE RRO sub-object already defined or that could be 1758 defined in the future for use in the RSVP-TE RRO is acceptable in 1759 this object. 1761 The meanings of all of the sub-objects and fields in this object are 1762 identical to those defined for the RSVP-TE RRO. 1764 PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types. 1766 RRO Object-Class is to be assigned by IANA (recommended value=8) 1768 RRO Object-Type is to be assigned by IANA (recommended value=1) 1770 7.11. LSPA Object 1772 The LSPA object is optional and specifies various TE LSP attributes 1773 to be taken into account by the PCE during path computation. The 1774 LSPA (LSP Attributes) object can be carried within a PCReq message, 1775 or a PCRep message in case of unsuccessful path computation (in this 1776 case, the PCRep message also contains a NO-PATH object and the LSPA 1777 object is used to indicate the set of constraints that could not be 1778 satisfied). Most of the fields of the LSPA object are identical to 1779 the fields of the SESSION-ATTRIBUTE (C-Type = 7) object defined in 1780 [RFC3209] and [RFC4090]. When absent from the PCReq message, this 1781 means that the Setup and Holding priorities are equal to 0, and there 1782 are no affinity constraints. See section 4.7.4 of [RFC3209] for a 1783 detailed description of the use of resource affinities. 1785 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1787 LSPA Object-Types is to be assigned by IANA (recommended value=1) 1788 The format of the LSPA object body is: 1790 0 1 2 3 1791 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 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Exclude-any | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Include-any | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 | Include-all | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | Setup Prio | Holding Prio | Flags |L| Reserved | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | | 1802 // Optional TLVs // 1803 | | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 Figure 16: LSPA Object Body Format 1807 Setup Prio (Setup Priority - 8 bits). The priority of the TE LSP 1808 with respect to taking resources, in the range of 0 to 7. The value 1809 0 is the highest priority. The Setup Priority is used in deciding 1810 whether this session can preempt another session. 1812 Holding Prio (Holding Priority - 8 bits). The priority of the TE LSP 1813 with respect to holding resources, in the range of 0 to 7. The value 1814 0 is the highest priority. Holding Priority is used in deciding 1815 whether this session can be preempted by another session. 1817 Flags (8 bits) 1819 The flag L corresponds to the "Local protection desired" bit 1820 ([RFC3209]) of the SESSION-ATTRIBUTE Object. 1822 L Flag (Local protection desired). When set, this means that the 1823 computed path must include links protected with Fast Reroute as 1824 defined in [RFC4090]. 1826 Unassigned flags MUST be set to zero on transmission and MUST be 1827 ignored on receipt. 1829 Reserved (8 bits): This field MUST be set to zero on transmission and 1830 MUST be ignored on receipt. 1832 Note that Optional TLVs may be defined in the future to carry 1833 additional TE LSP attributes such as those defined in [RFC4420]. 1835 7.12. Include Route Object Object 1837 The IRO (Include Route Object) is optional and can be used to specify 1838 that the computed path MUST traverse a set of specified network 1839 elements. The IRO MAY be carried within PCReq and PCRep messages. 1840 When carried within a PCRep message with the NO-PATH object, the IRO 1841 indicates the set of elements that cause de PCE to fail to find a 1842 path. 1844 IRO Object-Class is to be assigned by IANA (recommended value=10) 1846 IRO Object-Type is to be assigned by IANA (recommended value=1) 1848 0 1 2 3 1849 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 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | | 1852 // (Subobjects) // 1853 | | 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 Figure 17: IRO Body Format 1858 Subobjects: The IRO is made of subobjects identical to the ones 1859 defined in [RFC3209], [RFC3473] and [RFC3477] where the IRO subobject 1860 type is identical to the subobject type defined in the related 1861 documents. 1863 The following subobject types are supported. 1865 Type Subobject 1866 1 IPv4 prefix 1867 2 IPv6 prefix 1868 4 Unnumbered Interface ID 1869 32 Autonomous system number 1870 The L bit of such sub-object has no meaning within an IRO. 1872 7.13. SVEC Object 1874 7.13.1. Notion of Dependent and Synchronized Path Computation Requests 1876 Independent versus dependent path computation requests: path 1877 computation requests are said to be independent if they are not 1878 related to each other. Conversely a set of dependent path 1879 computation requests is such that their computations cannot be 1880 performed independently of each other (a typical example of dependent 1881 requests is the computation of a set of diverse paths). 1883 Synchronized versus non-synchronized path computation requests: a set 1884 of path computation requests is said to be non-synchronized if their 1885 respective treatment (path computations) can be performed by a PCE in 1886 a serialized and independent fashion. 1888 There are various circumstances where the synchronization of a set of 1889 path computations may be beneficial or required. 1891 Consider the case of a set of N TE LSPs for which a PCC needs to send 1892 path computation requests to a PCE. The first solution consists of 1893 sending N separate PCReq messages to the selected PCE. In this case, 1894 the path computation requests are non-synchronized. Note that the 1895 PCC may chose to distribute the set of N requests across K PCEs for 1896 load balancing purposes. Considering that M (with M+-+-+-+-+-+-+ | | 3395 | | | KeepWait |----+ | 3396 | +--| |<---+ | 3397 |+-----+-+-+-+-+-+-+ | | 3398 || | | | 3399 || | | | 3400 || V | | 3401 || +->+-+-+-+-+-+-+----+ | 3402 || | | OpenWait |-------+ 3403 || +--| |<------+ 3404 ||+----+-+-+-+-+-+-+<---+ | 3405 ||| | | | 3406 ||| | | | 3407 ||| V | | 3408 ||| +->+-+-+-+-+-+-+ | | 3409 ||| | |TCPPending |----+ | 3410 ||| +--| | | 3411 |||+---+-+-+-+-+-+-+<---+ | 3412 |||| | | | 3413 |||| | | | 3414 |||| V | | 3415 |||+--->+-+-+-+-+ | | 3416 ||+---->| Idle |-------+ | 3417 |+----->| |----------+ 3418 +------>+-+-+-+-+ 3420 Figure 23: PCEP Finite State Machine for the PCC 3422 PCEP defines the following set of variables: 3424 Connect: timer (in seconds) started after having initialized a TCP 3425 connection using the PCEP registered TCP port. The value of the 3426 TCPConnect timer is 60 seconds. 3428 ConnectRetry: specifies the number of times the system has tried to 3429 establish a TCP connection with a PCEP peer without success. 3431 ConnectMaxRetry: Maximum number of times the system tries to 3432 establish a TCP connection using the PCEP registered TCP port before 3433 going back to the Idle state. The value of the ConnectMaxRetry is 5. 3435 OpenWait: timer that corresponds to the amount of time a PCEP peer 3436 will wait to receive an Open message from the PCEP peer after the 3437 expiration of which the system releases the PCEP resource and go back 3438 to the Idle state. The OpenWait timer has a fixed value of 60 3439 seconds. 3441 KeepWait: timer that corresponds to the amount of time a PCEP peer 3442 will wait to receive a Keepalive or a PCErr message from the PCEP 3443 peer after the expiration of which the system releases the PCEP 3444 resource and go back to the Idle state. The KeepWait timer has a 3445 fixed value of 60 seconds. 3447 OpenRetry: specifies the number of times the system has received an 3448 Open message with unacceptable PCEP session characteristics. 3450 The following two states variable are defined: 3452 RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system 3453 has received an acceptable Open message. 3455 LocalOK: the LocalOK variable is a Boolean set to 1 if the system has 3456 received a Keepalive message acknowledging that the Open message sent 3457 to the peer was valid. 3459 Idle State: 3461 The idle state is the initial PCEP state where PCEP (also referred to 3462 as "the system") waits for an initialization event that can either be 3463 manually triggered by the user (configuration) or automatically 3464 triggered by various events. In Idle state, PCEP resources are 3465 allocated (memory, potential process, ...) but no PCEP messages are 3466 accepted from any PCEP peer. The system listens the registered PCEP 3467 TCP port. 3469 The following set of variable are initialized: 3471 TCPRetry=0, 3473 LocalOK=0, 3475 RemoteOK=0, 3477 OpenRetry=0. 3479 Upon detection of a local initialization event (e.g. user 3480 configuration to establish a PCEP session with a particular PCEP 3481 peer, local event triggering the establishment of a PCEP session with 3482 a PCEP peer such as the automatic detection of a PCEP peer, ...), the 3483 system: 3485 o Initiates of a TCP connection with the PCEP peer, 3487 o Starts the Connect timer, 3489 o Moves to the TCPPending state. 3491 Upon receiving a TCP connection on the registered PCEP TCP port, if 3492 the TCP connection establishment succeeds, the system: 3494 o Sends an Open message, 3496 o Starts the OpenWait timer, 3498 o Moves to the OpenWait state. 3500 If the connection establishment fails, the system remains in the Idle 3501 state. Any other event received in the Idle state is ignored. 3503 It is expected that an implementation will use an exponentially 3504 increasing timer between automatically generated Initialization 3505 events and between retries of TCP connection establishment. 3507 TCPPending State 3509 If the TCP connection establishment succeeds, the system: 3511 o Sends an Open message, 3513 o Starts the OpenWait timer, 3515 o Moves to the OpenWait state. 3517 If the TCP connection establishment fails (an error is detected 3518 during the TCP connection establishment) or the Connect timer 3519 expires: 3521 o If ConnectRetry =ConnectMaxRetry the system moves to the Idle 3522 State 3524 o If ConnectRetry < ConnectMaxRetry the system: 3526 1. Initiates of a TCP connection with the PCEP peer, 3528 2. Increments the ConnectRetry variable, 3529 3. Restarts the Connect timer, 3531 4. Stays in the TPCPending state. 3533 In response to any other event the system releases the PCEP resources 3534 for that peer and moves back to the Idle state. 3536 OpenWait State: 3538 In the OpenWait state, the system waits for an Open message from its 3539 PCEP peer. 3541 If the system receives an Open message from the PCEP peer before the 3542 expiration of the OpenWait timer, the system first examines all of 3543 its sessions that are in the OpenWait or KeepWait state. If another 3544 session with the same PCEP peer already exists (same IP address), 3545 then the system performs the following collision resolution 3546 procedure: 3548 o If the system has initiated the current session and it has a lower 3549 IP address than the PCEP Peer, the system closes the TCP 3550 connection, releases the PCEP resources for the pending session 3551 and moves back to the Idle state. 3553 o If the session was initiated by the PCEP peer and the system has a 3554 higher IP address that the PCEP Peer, the system closes the TCP 3555 connection, releases the PCEP resources for the pending session, 3556 and moves back to the Idle state. 3558 o Otherwise, the system checks the PCEP session attributes 3559 (Keepalive frequency, DeadTimer, ...). 3561 If an error is detected (e.g. malformed Open message, reception of a 3562 message that is not an Open message, presence of two Open objects, 3563 ...), PCEP generates an error notification, the PCEP peer sends a 3564 PCErr message with Error-Type=1 and Error-value=1. The system 3565 releases the PCEP resources for the PCEP peer, closes the TCP 3566 connection and moves to the Idle state. 3568 If no errors are detected, OpenRetry=1 and the session 3569 characteristics are unacceptable, the PCEP peer sends a PCErr with 3570 Error-Type=1 and Error-value=5, the system releases the PCEP 3571 resources for that peer and moves back to the Idle state. 3573 If no errors are detected, and the session characteristics are 3574 acceptable to the local system, the system: 3576 o Sends a Keepalive message to the PCEP peer, 3578 o Starts the Keepalive timer, 3580 o Sets the RemoteOK variable to 1. 3582 If LocalOK=1 the system clears the OpenWait timer and moves to the UP 3583 state. 3585 If LocalOK=0 the system clears the OpenWait timer, starts the 3586 KeepWait timer and moves to the KeepWait state. 3588 If no errors are detected, but the session characteristics are 3589 unacceptable and non-negotiable, the PCEP peer sends a PCErr with 3590 Error-Type=1 and Error-value=3, the system releases the PCEP 3591 resources for that peer, and moves back to the Idle state. 3593 If no errors are detected, and OpenRetry is 0, and the session 3594 characteristics are unacceptable but negotiable (such as, the 3595 Keepalive period or the DeadTimer), then the system: 3597 o Increments the OpenRetry variable, 3599 o Sends a PCErr message with Error-Type=1 and Error-value=4 that 3600 contains proposed acceptable session characteristics, 3602 o If LocalOK=1, the system restarts the OpenWait timer and stays in 3603 the OpenWait state 3605 o If LocalOK=0, the system clears the OpenWait timer, starts the 3606 KeepWait timer and moves to the KeepWait state 3608 If no Open message is received before the expiration of the OpenWait 3609 timer, the PCEP peer sends a PCErr message with Error-Type=1 and 3610 Error-value=2, the system releases the PCEP resources for the PCEP 3611 peer, closes the TCP connection and moves to the Idle state. 3613 In response to any other event the system releases the PCEP resources 3614 for that peer and moves back to the Idle state. 3616 KeepWait State 3618 In the Keepwait state, the system waits for the receipt of a 3619 Keepalive from its PCEP peer acknowledging its Open message or a 3620 PCErr message in response to unacceptable PCEP session 3621 characteristics proposed in the Open message. 3623 If an error is detected (e.g. malformed Keepalive message), PCEP 3624 generates an error notification, the PCEP peer sends a PCErr message 3625 with Error-Type=1 and Error-value=1. The system releases the PCEP 3626 resources for the PCEP peer, closes the TCP connection and moves to 3627 the Idle state. 3629 If a Keepalive message is received before the expiration of the 3630 KeepWait timer, then the system sets LocalOK=1 and: 3632 o If RemoteOK=1, the system clears the KeepWait timer and moves to 3633 the UP state. 3635 o If RemoteOK=0, the system clears the KeepWait timer, starts the 3636 OpenWait timer and moves to the OpenWait State. 3638 If a PCErr message is received before the expiration of the KeepWait 3639 timer: 3641 1. If the proposed values are unacceptable, the PCEP peer sends a 3642 PCErr message with Error-Type=1 and Error-value=6 and the system 3643 releases the PCEP resources for that PCEP peer, closes the TCP 3644 connection and moves to the Idle state. 3646 2. If the proposed values are acceptable, the system adjusts its 3647 PCEP session characteristics according to the proposed values 3648 received in the PCErr message restarts the KeepWait timer and 3649 sends a new Open message. If RemoteOK=1, the system restarts the 3650 KeepWait timer and stays in the KeepWait state. If RemoteOK=0, 3651 the system clears the KeepWait timer, start the OpenWait timer 3652 and moves to the OpenWait state. 3654 If neither a Keepalive nor a PCErr is received after the expiration 3655 of the KeepWait timer, the PCEP peer sends a PCErr message with 3656 Error-Type=1 and Error-value=7 and, system releases the PCEP 3657 resources for that PCEP peer, closes the TCP connection and moves to 3658 the Idle State. 3660 In response to any other event the system releases the PCEP resources 3661 for that peer and moves back to the Idle state. 3663 UP State 3665 In the UP state, the PCEP peer starts exchanging PCEP messages 3666 according to the session characteristics. 3668 If the Keepalive timer expires, the system restarts the Keepalive 3669 timer and sends a Keepalive message. 3671 If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from 3672 the PCEP peer before the expiration of the DeadTimer, the system 3673 terminates PCEP session according to the procedure defined in 3674 Section 6.8, releases the PCEP resources for that PCEP peer, closes 3675 the TCP connection and moves to the Idle State. 3677 If a malformed message is received, the system terminates the PCEP 3678 session according to the procedure defined in Section 6.8, releases 3679 the PCEP resources for that PCEP peer, closes the TCP connection and 3680 moves to the Idle State. 3682 If the system detects that the PCEP peer tries to setup a second TCP 3683 connection, it stops the TCP connection establishment and sends a 3684 PCErr with Error-Type=9. 3686 If the TCP connection fails, the system releases the PCEP resources 3687 for that PCEP peer, closes the TCP connection and moves to the Idle 3688 State. 3690 Appendix B. PCEP Variables 3692 PCEP defines the following configurable variables: 3694 Keepalive timer: minimum period of time between the sending of PCEP 3695 messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A 3696 suggested value for the Keepalive timer is 30 seconds. 3698 DeadTimer: period of timer after the expiration of which a PCEP peer 3699 declared the session down if no PCEP message has been received. 3701 SyncTimer: the SYNC timer is used in the case of synchronized path 3702 computation request using the SVEC object defined in Section 7.13.3. 3703 Consider the case where a PCReq message is received by a PCE that 3704 contains the SVEC object referring to M synchronized path computation 3705 requests. If after the expiration of the SYNC timer all the M path 3706 computation requests have not been received, a protocol error is 3707 triggered and the PCE MUST cancel the whole set of path computation 3708 requests. The aim of the SyncTimer is to avoid the storage of unused 3709 synchronized request should one of them get lost for some reasons 3710 (e.g a misbehaving PCC). Thus the value of the Synctimer must be 3711 large enough to avoid the expiration of the timer under normal 3712 circumstances. A RECOMMENDED value for the SYNC timer is 60 seconds. 3714 MAX-UNKNOWN-REQUESTS: A RECOMMENDED value is 5. 3716 MAX-UNKNOWN-MESSAGES: A RECOMMENDED value is 5. 3718 Authors' Addresses 3720 JP Vasseur (editor) 3721 Cisco Systems 3722 1414 Massachusetts Avenue 3723 Boxborough, MA 01719 3724 USA 3726 Email: jpv@cisco.com 3728 JL Le Roux (editor) 3729 France Telecom 3730 2, Avenue Pierre-Marzin 3731 Lannion, 22307 3732 FRANCE 3734 Email: jeanlouis.leroux@orange-ftgroup.com 3736 Full Copyright Statement 3738 Copyright (C) The IETF Trust (2008). 3740 This document is subject to the rights, licenses and restrictions 3741 contained in BCP 78, and except as set forth therein, the authors 3742 retain all their rights. 3744 This document and the information contained herein are provided on an 3745 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3746 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3747 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3748 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3749 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3750 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3752 Intellectual Property 3754 The IETF takes no position regarding the validity or scope of any 3755 Intellectual Property Rights or other rights that might be claimed to 3756 pertain to the implementation or use of the technology described in 3757 this document or the extent to which any license under such rights 3758 might or might not be available; nor does it represent that it has 3759 made any independent effort to identify any such rights. Information 3760 on the procedures with respect to rights in RFC documents can be 3761 found in BCP 78 and BCP 79. 3763 Copies of IPR disclosures made to the IETF Secretariat and any 3764 assurances of licenses to be made available, or the result of an 3765 attempt made to obtain a general license or permission for the use of 3766 such proprietary rights by implementers or users of this 3767 specification can be obtained from the IETF on-line IPR repository at 3768 http://www.ietf.org/ipr. 3770 The IETF invites any interested party to bring to its attention any 3771 copyrights, patents or patent applications, or other proprietary 3772 rights that may cover technology that may be required to implement 3773 this standard. Please address the information to the IETF at 3774 ietf-ipr@ietf.org.