idnits 2.17.1 draft-ietf-pce-pcep-15.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 3515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3539. 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 (September 8, 2008) is 5708 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 3145, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-09) exists of draft-farrel-rtg-common-bnf-00 == Outdated reference: A later version (-15) exists of draft-ietf-pce-inter-layer-req-07 == Outdated reference: A later version (-11) exists of draft-ietf-pce-manageability-requirements-04 == 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 (-02) exists of draft-kkoushik-pce-pcep-mib-01 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4420 (Obsoleted by RFC 5420) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems 3 Intended status: Standards Track JL. Le Roux, Ed. 4 Expires: March 12, 2009 France Telecom 5 September 8, 2008 7 Path Computation Element (PCE) Communication Protocol (PCEP) 8 draft-ietf-pce-pcep-15.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 March 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Architectural Protocol Overview (Model) . . . . . . . . . . . 6 60 4.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Architectural Protocol Overview . . . . . . . . . . . . . 6 62 4.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 7 63 4.2.2. Session Keepalive . . . . . . . . . . . . . . . . . . 8 64 4.2.3. Path Computation Request Sent By a PCC to a PCE . . . 9 65 4.2.4. Path Computation Reply Sent By The PCE to a PCC . . . 10 66 4.2.5. Notification . . . . . . . . . . . . . . . . . . . . . 12 67 4.2.6. Error . . . . . . . . . . . . . . . . . . . . . . . . 14 68 4.2.7. Termination of the PCEP Session . . . . . . . . . . . 14 69 4.2.8. Intermitent versus Permanent PCEP Session . . . . . . 15 70 5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 15 71 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 15 72 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 16 73 6.2. Open Message . . . . . . . . . . . . . . . . . . . . . . . 16 74 6.3. Keepalive Message . . . . . . . . . . . . . . . . . . . . 18 75 6.4. Path Computation Request (PCReq) Message . . . . . . . . . 19 76 6.5. Path Computation Reply (PCRep) Message . . . . . . . . . . 20 77 6.6. Notification (PCNtf) Message . . . . . . . . . . . . . . . 21 78 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 22 79 6.8. Close Message . . . . . . . . . . . . . . . . . . . . . . 23 80 6.9. Reception of Unknown Messages . . . . . . . . . . . . . . 23 81 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 23 82 7.1. PCE TLV Format . . . . . . . . . . . . . . . . . . . . . . 23 83 7.2. Common Object Header . . . . . . . . . . . . . . . . . . . 24 84 7.3. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 25 85 7.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 27 86 7.4.1. Object Definition . . . . . . . . . . . . . . . . . . 27 87 7.4.2. Handling of the RP Object . . . . . . . . . . . . . . 30 88 7.5. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 31 89 7.6. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 34 90 7.7. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 35 91 7.8. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 36 92 7.9. Explicit Route Object . . . . . . . . . . . . . . . . . . 39 93 7.10. Reported Route Object . . . . . . . . . . . . . . . . . . 40 94 7.11. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 40 95 7.12. Include Route Object Object . . . . . . . . . . . . . . . 42 96 7.13. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 42 97 7.13.1. Notion of Dependent and Synchronized Path 98 Computation Requests . . . . . . . . . . . . . . . . . 42 99 7.13.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 44 100 7.13.3. Handling of the SVEC Object . . . . . . . . . . . . . 45 101 7.14. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 46 102 7.15. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 49 103 7.16. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 53 104 7.17. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 54 105 8. Manageability Considerations . . . . . . . . . . . . . . . . . 55 106 8.1. Control of Function and Policy . . . . . . . . . . . . . . 56 107 8.2. Information and Data Models . . . . . . . . . . . . . . . 57 108 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 57 109 8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 57 110 8.5. Requirements on Other Protocols and Functional 111 Components . . . . . . . . . . . . . . . . . . . . . . . . 58 112 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 58 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 114 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 59 115 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 59 116 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 59 117 9.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 60 118 9.5. Notification Object . . . . . . . . . . . . . . . . . . . 61 119 9.6. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 61 120 9.7. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 62 121 9.8. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 63 122 9.9. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 63 123 9.10. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 64 124 9.11. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 64 125 10. Security Considerations . . . . . . . . . . . . . . . . . . . 64 126 10.1. PCEP Authentication and Integrity . . . . . . . . . . . . 65 127 10.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 65 128 10.3. Protection Against Denial of Service Attacks . . . . . . . 65 129 10.3.1. Protection Against TCP DoS Attacks . . . . . . . . . . 65 130 10.3.2. Request Input Shaping/Policing . . . . . . . . . . . . 66 131 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 66 132 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67 133 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 134 13.1. Normative References . . . . . . . . . . . . . . . . . . . 67 135 13.2. Informative References . . . . . . . . . . . . . . . . . . 68 136 13.3. References . . . . . . . . . . . . . . . . . . . . . . . . 70 137 Appendix A. PCEP Finite State Machine (FSM) . . . . . . . . . . . 70 138 Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 77 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78 140 Intellectual Property and Copyright Statements . . . . . . . . . . 79 142 1. Introduction 144 [RFC4655] describes the motivations and architecture for a Path 145 Compuation Element (PCE) based model for the computation of 146 Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic 147 Engineering Label Swtich Paths (TE LSPs). The model allows for the 148 separation of PCE from Path Computation Client (PCC), and allows for 149 the cooperation between PCEs. This necessitates a communication 150 protocol between PCC and PCE, and between PCEs. [RFC4657] states the 151 generic requirements for such a protocol including the requirement 152 for using the same protocol between PCC and PCE, and between PCEs. 153 Additional application-specific requirements (for scenarios such as 154 inter-area, inter-AS, etc.) are not included in [RFC4657], but there 155 is a requirement that any solution protocol must be easily extensible 156 to handle other requirements as they are introduced in application- 157 specific requirements documents. Examples of such application- 158 specific requirements are [RFC4927], 159 [I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req]. 161 This document specifies the Path Computation Element Communication 162 Protocol (PCEP) for communications between a PCC and a PCE, or 163 between two PCEs, in compliance with [RFC4657]. Such interactions 164 include path computation requests and path computation replies as 165 well as notifications of specific states related to the use of a PCE 166 in the context of MPLS and GMPLS Traffic Engineering. 168 PCEP is designed to be flexible and extensible so as to easily allow 169 for the addition of further messages and objects, should further 170 requirements be expressed in the future. 172 2. Terminology 174 Terminology used in this document 176 AS: Autonomous System. 178 Explicit path: Full explicit path from start to destination made of a 179 list of strict hops where a hop may be an abstract node such as an 180 AS. 182 IGP area: OSPF area or IS-IS level. 184 Inter-domain TE LSP: A TE LSP whose path transits at least two 185 different domains where a domain can be an IGP area, an Autonomous 186 System or a sub-AS (BGP confederations). 188 PCC: Path Computation Client: any client application requesting a 189 path computation to be performed by a Path Computation Element. 191 PCE: Path Computation Element: an entity (component, application or 192 network node) that is capable of computing a network path or route 193 based on a network graph and applying computational constraints. 195 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or a 196 PCE). 198 TED: Traffic Engineering Database that contains the topology and 199 resource information of the domain. The TED may be fed by IGP 200 extensions or potentially by other means. 202 TE LSP: Traffic Engineering Label Switched Path. 204 Strict/loose path: mix of strict and loose hops comprising at least 205 one loose hop representing the destination where a hop may be an 206 abstract node such as an AS. 208 Within this document, when describing PCE-PCE communications, the 209 requesting PCE fills the role of a PCC. This provides a saving in 210 documentation without loss of function. 212 The message formats in this document are specified using Backus Naur 213 Format (BNF) encoding as specified in [I-D.farrel-rtg-common-bnf]. 215 3. Assumptions 217 [RFC4655] describes various types of PCE. PCEP does not make any 218 assumption and thus does not impose any constraint on the nature of 219 the PCE. 221 Moreover, it is assumed that the PCE has the required information 222 (usually including network topology and resource information) so as 223 to perform the computation of a path for a TE LSP. Such information 224 can be gathered by routing protocols or by some other means. The way 225 in which the information is gathered is out of the scope of this 226 document. 228 Similarly, no assumption is made about the discovery method used by a 229 PCC to discover a set of PCEs (e.g., via static configuration or 230 dynamic discovery) and on the algorithm used to select a PCE. For 231 reference, [RFC4674] defines a list of requirements for dynamic PCE 232 discovery and IGP-based solutions for such PCE discovery are 233 specified in [RFC5088] and [RFC5089]. 235 4. Architectural Protocol Overview (Model) 237 The aim of this section is to describe the PCEP model in the spirit 238 of [RFC4101]. An architecture protocol overview (the big picture of 239 the protocol) is provided in this section. Protocol details can be 240 found in further sections. 242 4.1. Problem 244 The PCE-based architecture used for the computation of path for MPLS 245 and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the 246 PCE are not collocated, a communication protocol between the PCC and 247 the PCE is needed. PCEP is such a protocol designed specifically for 248 communications between a PCC and a PCE or between two PCEs in 249 compliance with [RFC4657]: a PCC may use PCEP to send a path 250 computation request for one or more TE LSPs to a PCE and the PCE may 251 reply with a set of computed paths if one or more paths can be found 252 that satisfies the set of constraints. 254 4.2. Architectural Protocol Overview 256 PCEP operates over TCP, which fulfils the requirements for reliable 257 messaging and flow control without further protocol work. 259 Several PCEP messages are defined: 261 - Open and Keepalive messages are used to initiate and maintain a 262 PCEP session respectively. 264 - PCReq: a PCEP message sent by a PCC to a PCE to request a path 265 computation. 267 - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path 268 computation request. A PCRep message can either contain a set of 269 computed paths if the request can be satisfied, or a negative reply 270 if not. The negative reply may indicate the reason why no path could 271 be found. 273 - PCNtf: a PCEP notification message either sent by a PCC to a PCE or 274 a PCE to a PCC to notify of a specific event. 276 - PCErr: a PCEP message sent upon the occurrence of a protocol error 277 condition. 279 - Close message: a message used to close a PCEP session. 281 The set of available PCEs may be either statically configured on a 282 PCC or dynamically discovered. The mechanisms used to discover one 283 or more PCEs and to select a PCE are out of the scope of this 284 document. 286 A PCC may have PCEP sessions with more than one PCE and similarly a 287 PCE may have PCEP sessions with multiple PCCs. 289 Each PCEP message is regarded as a single transmission unit and parts 290 of messages MUST NOT be interleaved. So, for example, a PCC sending 291 a PCReq and wishing to close the session, must complete sending the 292 request message before starting to send a Close message. 294 4.2.1. Initialization Phase 296 The initialization phase consists of two successive steps (described 297 in a schematic form in Figure 1): 299 1) Establishment of a TCP connection (3-way handshake) between the 300 PCC and the PCE. 302 2) Establishment of a PCEP session over the TCP connection. 304 Once the TCP connection is established, the PCC and the PCE (also 305 referred to as "PCEP peers") initiate PCEP session establishment 306 during which various session parameters are negotiated. These 307 parameters are carried within Open messages and include the Keepalive 308 timer, the Deadtimer and potentially other detailed capabilities and 309 policy rules that specify the conditions under which path computation 310 requests may be sent to the PCE. If the PCEP session establishment 311 phase fails because the PCEP peers disagree on the session parameters 312 or one of the PCEP peers does not answer after the expiration of the 313 establishment timer, the TCP connection is immediately closed. 314 Successive retries are permitted but an implementation should make 315 use of an exponential back-off session establishment retry procedure. 317 Keepalive messages are used to acknowledge Open messages, and once 318 the PCEP session has been successfully established. 320 Only one PCEP session can exist between a pair of PCEP peers at any 321 one time. Only one TCP connection on the PCEP port can exist between 322 a pair of PCEP peers at any one time. 324 Details about the Open message and the Keepalive message can be found 325 in Section 6.2 and Section 6.3 respectively. 327 +-+-+ +-+-+ 328 |PCC| |PCE| 329 +-+-+ +-+-+ 330 | | 331 | Open msg | 332 |-------- | 333 | \ Open msg | 334 | \ ---------| 335 | \/ | 336 | /\ | 337 | / -------->| 338 | / | 339 |<------ Keepalive| 340 | --------| 341 |Keepalive / | 342 |-------- / | 343 | \/ | 344 | /\ | 345 |<------ ---------->| 346 | | 348 Figure 1: PCEP Initialization phase (initiated by a PCC) 350 (Note that once the PCEP session is established, the exchange of 351 Keepalive messages is optional) 353 4.2.2. Session Keepalive 355 Once a session has been established, a PCE or PCC may want to know 356 that its PCEP peer is still available for use. 358 It can rely on TCP for this information, but it is possible that the 359 remote PCEP function has failed without disturbing the TCP 360 connection. It is also possible to rely on the mechanisms built into 361 the TCP implementations, but these might not provide sufficiently 362 timely notifications of failures. Lastly, a PCC could wait until it 363 has a path computation request to send and use its failed 364 transmission or the failure to receive a response as evidence that 365 the session has failed, but this is clearly inefficient. 367 In order to handle this situation, PCEP includes a keepalive 368 mechanism based on a Keepalive timer, a Dead timer, and a Keepalive 369 message. 371 Each end of a PCEP session runs a Keepalive timer. It restarts the 372 timer every time it sends a message on the session. When the timer 373 expires, it sends a Keepalive message. Other traffic may serve as 374 Keepalive (see Section 6.3). 376 The ends of the PCEP session also run Dead timers, and they restart 377 them whenever a message is received on the session. If one end of 378 the session receives no message before the Dead timer expires, it 379 declares the session dead. 381 Note that this means that the Keepalive message is unresponded and 382 does not form part of a two-way keepalive handshake as used in some 383 protocols. Also note that the mechanism is designed to reduce to a 384 minimum the amount of keepalive traffic on the session. 386 The keepalive traffic on the session may be unbalanced according to 387 the requirements of the session ends. Each end of the session can 388 specify (on an Open message) the Keepalive timer that it will use 389 (i.e., how often it will transmit a Keepalive message if there is no 390 other traffic) and a Dead timer that it recommends its peer to use 391 (i.e., how long the peer should wait before declaring the session 392 dead if it receives no traffic). The session ends may use different 393 Keepalive timer values. 395 The minimum value of the Keepalive timer is 1 second, and it is 396 specified in units of 1 second. The recommended default value is 30 397 seconds. The timer may be disabled by setting it to zero. 399 The recommended default for the Dead timer is 4 times the value of 400 the Keepalive timer used by the remote peer. This means that there 401 is never any risk of congesting TCP with excessive Keepalive 402 messages. 404 4.2.3. Path Computation Request Sent By a PCC to a PCE 405 +-+-+ +-+-+ 406 |PCC| |PCE| 407 +-+-+ +-+-+ 408 1)Path computation | | 409 event | | 410 2)PCE Selection | | 411 3)Path computation |---- PCReq message--->| 412 request sent to | | 413 the selected PCE | | 415 Figure 2: Path Computation request 417 Once a PCC has successfully established a PCEP session with one or 418 more PCEs, if an event is triggered that requires the computation of 419 a set of paths, the PCC first selects one or more PCE. Note that the 420 PCE selection decision process may have taken place prior to the PCEP 421 session establishment. 423 Once the PCC has selected a PCE, it sends the PCE a path computation 424 request to the PCE (PCReq message) that contains a variety of objects 425 that specify the set of constraints and attributes for the path to be 426 computed. For example "Compute a TE LSP path with source IP 427 address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B 428 Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may 429 desire to specify the urgency of such request by assigning a request 430 priority. Each request is uniquely identified by a request-id number 431 and the PCC-PCE address pair. The process is shown in a schematic 432 form in Figure 2. 434 Note that multiple path computation requests may be outstanding from 435 one PCC to a PCE at any time. 437 Details about the PCReq message can be found in Section 6.4 439 4.2.4. Path Computation Reply Sent By The PCE to a PCC 440 +-+-+ +-+-+ 441 |PCC| |PCE| 442 +-+-+ +-+-+ 443 | | 444 |---- PCReq message--->| 445 | |1) Path computation 446 | |request received 447 | | 448 | |2)Path successfully 449 | |computed 450 | | 451 | |3) Computed paths 452 | |sent to the PCC 453 | | 454 |<--- PCRep message ---| 455 | (Positive reply) | 457 Figure 3a: Path Computation Request With Successful 458 Path Computation 460 +-+-+ +-+-+ 461 |PCC| |PCE| 462 +-+-+ +-+-+ 463 | | 464 | | 465 |---- PCReq message--->| 466 | |1) Path computation 467 | |request received 468 | | 469 | |2) No Path found that 470 | |satisfies the request 471 | | 472 | |3) Negative reply sent to 473 | |the PCC (optionally with 474 | |various additional 475 | |information) 476 |<--- PCRep message ---| 477 | (Negative reply) | 479 Figure 3b: Path Computation Request With Unsuccessful 480 Path Computation 482 Upon receiving a path computation request from a PCC, the PCE 483 triggers a path computation, the result of which can either be: 485 o Positive (Figure 3-a): the PCE manages to compute a path that 486 satisfies the set of required constraints, in which case the PCE 487 returns the set of computed paths to the requesting PCC. Note 488 that PCEP supports the capability to send a single request that 489 requires the computation of more than one path (e.g., computation 490 of a set of link-diverse paths). 492 o Negative (Figure 3-b): no path could be found that satisfies the 493 set of constraints. In this case, a PCE may provide the set of 494 constraints that led to the path computation failure. Upon 495 receiving a negative reply, a PCC may decide to resend a modified 496 request or take any other appropriate action. 498 Details about the PCRep message can be found in Section 6.5. 500 4.2.5. Notification 502 There are several circumstances in which a PCE may want to notify a 503 PCC of a specific event. For example, suppose that the PCE suddenly 504 gets overloaded, potentially leading to unacceptable response times. 505 The PCE may want to notify one or more PCCs that some of their 506 requests (listed in the notification) will not be satisfied or may 507 experience unacceptable delays. Upon receiving such notification, 508 the PCC may decide to redirect its path computation requests to 509 another PCE should an alternate PCE be available. Similarly, a PCC 510 may desire to notify a PCE of a particular event such as the 511 cancellation of pending requests. 513 +-+-+ +-+-+ 514 |PCC| |PCE| 515 +-+-+ +-+-+ 516 1)Path computation | | 517 event | | 518 2)PCE Selection | | 519 3)Path computation |---- PCReq message--->| 520 request X sent to | |4) Path computation 521 the selected PCE | |request queued 522 | | 523 | | 524 5) Path computation| | 525 request X cancelled| | 526 |---- PCNtf message -->| 527 | |6) Path computation 528 | |request X cancelled 530 Figure 4: Example of PCC Notification (Cancellation 531 Notification) 532 Sent To a PCE 534 +-+-+ +-+-+ 535 |PCC| |PCE| 536 +-+-+ +-+-+ 537 1)Path computation | | 538 event | | 539 2)PCE Selection | | 540 3)Path computation |---- PCReq message--->| 541 request X sent to | |4) Path computation 542 the selected PCE | |request queued 543 | | 544 | | 545 | |5) PCE gets overloaded 546 | | 547 | | 548 | |6) Path computation 549 | |request X cancelled 550 | | 551 |<--- PCNtf message----| 553 Figure 5: Example of PCE Notification (Cancellation 554 Notification) Sent To a PCC 556 Details about the PCNtf message can be found in Section 6.6. 558 4.2.6. Error 560 The PCEP Error message (also referred to as a PCErr message) is sent 561 in several situations: when a protocol error condition is met or when 562 the request is not compliant with the PCEP specification (e.g., 563 capability not supported, reception of a message with a mandatory 564 missing object, policy violation, unexpected message, unknown request 565 reference, ...). 567 +-+-+ +-+-+ 568 |PCC| |PCE| 569 +-+-+ +-+-+ 570 1)Path computation | | 571 event | | 572 2)PCE Selection | | 573 3)Path computation |---- PCReq message--->| 574 request X sent to | |4) Reception of a 575 the selected PCE | |malformed object 576 | | 577 | |5) Request discarded 578 | | 579 |<-- PCErr message ---| 580 | | 582 Figure 6: Example of Error message Sent By a PCE To a PCC 583 In Reply To The Reception Of a Malformed Object 585 Details about the PCErr message can be found in Section 6.7. 587 4.2.7. Termination of the PCEP Session 589 When one of the PCEP peers desires to terminate a PCEP session it 590 first sends a PCEP Close message and then closes the TCP connection. 591 If the PCEP session is terminated by the PCE, the PCC clears all the 592 states related to pending requests previously sent to the PCE. 593 Similarly, if the PCC terminates a PCEP session the PCE clears all 594 pending path computation requests sent by the PCC in question as well 595 as the related states. A Close message can only be sent to terminate 596 a PCEP session if the PCEP session has previously been established. 598 In case of TCP connection failure, the PCEP session is immediately 599 terminated. 601 Details about the Close message can be found in Section 6.8. 603 4.2.8. Intermitent versus Permanent PCEP Session 605 An implementation may decide to keep the PCEP session alive (and thus 606 the corresponding TCP connection) for an unlimited time (this may for 607 instance be appropriate when path computation requests are sent on a 608 frequent basis so as to avoid to open a TCP connection each time a 609 path computation request is needed, which would incur additional 610 processing delays). Conversely, in some other circumstances, it may 611 be desirable to systematically open and close a PCEP session for each 612 PCEP request (for instance when sending a path computation request is 613 a rare event). 615 5. Transport Protocol 617 PCEP operates over TCP using a registered TCP port (to be assigned by 618 IANA). This allows the requirements of reliable messaging and flow 619 control to be met without further protocol work. All PCEP message 620 MUST be sent using the registered TCP port for the source and 621 destination TCP port. 623 6. PCEP Messages 625 A PCEP message consists of a common header followed by a variable 626 length body made of a set of objects that can either be mandatory or 627 optional. In the context of this document, an object is said to be 628 mandatory in a PCEP message when the object MUST be included for the 629 message to be considered as valid. A PCEP message with a missing 630 mandatory object MUST trigger an Error message (see Section 7.15). 631 Conversely, if an object is optional, the object may or may not be 632 present. 634 A flag referred to as the P flag is defined in the common header of 635 each PCEP object (see Section 7.2). When this flag is set in an 636 object in a PCReq, the PCE MUST take the information carried in the 637 object into account during the path computation. For example, the 638 METRIC object defined in Section 7.8 allows a PCC to specify a 639 bounded acceptable path cost. The METRIC object is optional, but a 640 PCC may set a flag to ensure that the constraint is taken into 641 account. In this case, if the constraint cannot be taken into 642 account by the PCE, the PCE MUST trigger an Error message. 644 For each PCEP message type, rules are defined that specify the set of 645 objects that the message can carry. We use the Backus-Naur Form 646 (BNF) (see [RFC4234]) to specify such rules. Square brackets refer 647 to optional sub-sequences. An implementation MUST form the PCEP 648 messages using the object ordering specified in this document. 650 6.1. Common header 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Ver | Flags | Message-Type | Message-Length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Figure 7: PCEP Message Common Header 660 Ver (Version - 3 bits): PCEP version number. Current version is 661 version 1. 663 Flags (5 bits): no flags are currently defined. Unassigned bits are 664 considered as reserved. They MUST be set to zero on transmission and 665 MUST be ignored on receipt. 667 Message-Type (8 bits): 669 The following message types are currently defined (to be confirmed by 670 IANA). 671 Value Meaning 672 1 Open 673 2 Keepalive 674 3 Path Computation Request 675 4 Path Computation Reply 676 5 Notification 677 6 Error 678 7 Close 680 Message-Length (16 bits): total length of the PCEP message expressed 681 in bytes including the common header. 683 6.2. Open Message 685 The Open message is a PCEP message sent by a PCC to a PCE and a PCE 686 to a PCC in order to establish a PCEP session. The Message-Type 687 field of the PCEP common header for the Open message is set to 1 (To 688 be confirmed by IANA). 690 Once the TCP connection has been successfully established, the first 691 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 692 an Open message as specified in Appendix A. 694 Any message received prior to an Open message MUST trigger a protocol 695 error condition causing a PCErr message to be sent with Error-Type 696 'PCEP session establishment failure' and Error-Value 'reception of an 697 invalid Open message or a non Open message' and the PCEP session 698 establishment attempt MUST be terminated by closing the TCP 699 connection. 701 The Open message is used to establish a PCEP session between the PCEP 702 peers. During the establishment phase the PCEP peers exchange 703 several session characteristics. If both parties agree on such 704 characteristics the PCEP session is successfully established. 706 Open message 707 ::= 708 709 The Open message MUST contain exactly one OPEN object (see 710 Section 7.3). 712 Various session characteristics are specified within the OPEN object. 713 Once the TCP connection has been successfully established the sender 714 MUST start an initialization timer called OpenWait after the 715 expiration of which if no Open message has been received it sends a 716 PCErr message and releases the TCP connection (see Appendix A for 717 details). 719 Once an Open message has been sent to a PCEP peer, the sender MUST 720 start an initialization timer called KeepWait after the expiration of 721 which if neither a Keepalive message has been received nor a PCErr 722 message in case of disagreement of the session characteristics, a 723 PCErr message MUST be sent and the TCP connection MUST be released 724 (see Appendix A for details). 726 The KeepWait timer has a fixed value of 1 minute. 728 Upon the receipt of an Open message, the receiving PCEP peer MUST 729 determine whether the suggested PCEP session characteristics are 730 acceptable. If at least one of the characteristics is not acceptable 731 by the receiving peer, it MUST send an Error message. The Error 732 message SHOULD also contain the related Open object: for each 733 unacceptable session parameter, an acceptable parameter value SHOULD 734 be proposed in the appropriate field of the Open object in place of 735 the originally proposed value. The PCEP peer MAY decide to resend an 736 Open message with different session characteristics. If a second 737 Open message is received with the same set of parameters or with 738 parameters that are still unacceptable, the receiving peer MUST send 739 an Error message and it MUST immediately close the TCP connection. 740 Details about error message can be found in Section 7.15. Successive 741 retries are permitted but an implementation SHOULD make use of an 742 exponential back-off session establishment retry procedure. 744 If the PCEP session characteristics are acceptable, the receiving 745 PCEP peer MUST send a Keepalive message (defined in Section 6.3) that 746 serves as an acknowledgment. 748 The PCEP session is considered as established once both PCEP peers 749 have received a Keepalive message from their peer. 751 A PCEP implementation is free to process received requests in any 752 order. For example, the requests may be processed in the order they 753 are received, re-ordered and assigned priority according to local 754 policy, re-ordered according to the priority encoded in the RP Object 755 (Section 7.4.1), or processed in parallel. 757 6.3. Keepalive Message 759 A Keepalive message is a PCEP message sent by a PCC or a PCE in order 760 to keep the session in active state. The Keepalive message is also 761 used in response to an Open message to acknowledge that an Open 762 message has been received and that the PCEP session characteristics 763 are acceptable. The Message-Type field of the PCEP common header for 764 the Keepalive message is set to 2 (To be confirmed by IANA). The 765 Keepalive message does not contain any object. 767 PCEP has its own keepalive mechanism used to ensure of the liveness 768 of the PCEP session. This requires the determination of the 769 frequency at which each PCEP peer sends Keepalive messages. 770 Asymmetric values may be chosen; thus there is no constraint 771 mandating the use of identical keepalive frequencies by both PCEP 772 peers. The DeadTimer is defined as the period of time after the 773 expiration of which a PCEP peer declares the session down if no PCEP 774 message has been received (Keepalive or any other PCEP message: thus, 775 any PCEP message acts as a Keepalive message). Similarly, there is 776 no constraints mandating the use of identical DeadTimers by both PCEP 777 peers. The minimum Keepalive timer value is 1 second. Deployments 778 SHOULD consider carefully the impact of using low values for the 779 Keepalive timer as these might not give rise to the expected results 780 in periods of temporary network instability. 782 Keepalive messages are sent at the frequency specified in the OPEN 783 object carried within an Open message according to the rules 784 specified in Section 7.3. Because any PCEP message may serve as 785 Keepalive, an implementation may either decide to send Keepalive 786 messages at fixed intervals regardless on whether other PCEP messages 787 might have been sent since the last sent Keepalive message, or may 788 decide to differ the sending of the next Keepalive message based on 789 the time at which the last PCEP message (other than Keepalive) was 790 sent. 792 Note that sending Keepalive messages to keep the session alive is 793 optional and PCEP peers may decide to not send Keepalive messages 794 once the PCEP session is established in which case the peer that does 795 not receive Keepalive messages does not expect to receive them and 796 MUST NOT declare the session as inactive. 798 Keepalive message 799 ::= 801 6.4. Path Computation Request (PCReq) Message 803 A Path Computation Request message (also referred to as a PCReq 804 message) is a PCEP message sent by a PCC to a PCE to request a path 805 computation. A PCReq message may carry more than one path 806 computation request. The Message-Type field of the PCEP common 807 header for the PCReq message is set to 3 (To be confirmed by IANA). 809 There are two mandatory objects that MUST be included within a PCReq 810 message: the RP and the END-POINTS objects (see section Section 7). 811 If one or both of these objects is missing, the receiving PCE MUST 812 send an error message to the requesting PCC. Other objects are 813 optional. 815 The format of a PCReq message is as follows: 816 ::= 817 [] 818 820 where: 821 ::=[] 822 ::=[] 824 ::= 825 826 [] 827 [] 828 [] 829 [[]] 830 [] 831 [] 832 where: 834 ::=[] 836 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 837 BALANCING objects are defined in Section 7. The special case of two 838 BANDWIDTH objects is discussed in detail in Section 7.7. 840 6.5. Path Computation Reply (PCRep) Message 842 The PCEP Path Computation Reply message (also referred to as a PCRep 843 message) is a PCEP message sent by a PCE to a requesting PCC in 844 response to a previously received PCReq message. The Message-Type 845 field of the PCEP common header is set to 4 (To be confirmed by 846 IANA). 848 The bundling of multiple replies to a set of path computation 849 requests within a single PCRep message is supported by PCEP. If a 850 PCE receives non-synchronized path computation requests by means of 851 one or more PCReq messages from a requesting PCC it MAY decide to 852 bundle the computed paths within a single PCRep message so as to 853 reduce the control plane load. Note that the counter side of such an 854 approach is the introduction of additional delays for some path 855 computation requests of the set. Conversely, a PCE that receives 856 multiple requests within the same PCReq message MAY decide to provide 857 each computed path in separate PCRep messages or within the same 858 PCRep message. A PCRep message may contain positive and negative 859 replies. 861 A PCRep message may contain a set of computed paths corresponding to 862 either a single path computation request with load-balancing (see 863 Section 7.16) or multiple path computation requests originated by a 864 requesting PCC. The PCRep message may also contain multiple 865 acceptable paths corresponding to the same request. 867 The PCRep message MUST contain at least one RP object. For each 868 reply that is bundled into a single PCReq message, an RP object MUST 869 be included that contains a Request-ID-number identical to the one 870 specified in the RP object carried in the corresponding PCReq message 871 (see Section 7.4 for the definition of the RP object). 873 If the path computation request can be satisfied (the PCE finds a set 874 of paths that satisfy the set of constraints), the set of computed 875 paths specified by means of ERO objects is inserted in the PCRep 876 message. The ERO is defined in Section 7.9. The situation where 877 multiple computed paths are provided in a PCRep message is discussed 878 in detail in Section 7.13. Furthermore, when a PCC requests the 879 computation of a set of paths for a total amount of bandwidth by 880 means of a LOAD-BALANCING object carried within a PCReq message, the 881 ERO of each computed path may be followed by a BANDWIDTH object as 882 discussed in section Section 7.16. 884 If the path computation request cannot be satisfied, the PCRep 885 message MUST include a NO-PATH object. The NO-PATH object (described 886 in Section 7.5) may also contain other information (e.g, reasons for 887 the path computation failure). 889 The format of a PCRep message is as follows: 890 ::= 891 893 where: 894 ::=[] 896 ::= 897 [] 898 [] 899 [] 901 ::=[] 903 ::= 905 where: 907 ::=[] 908 [] 909 [] 910 [] 912 ::=[] 914 6.6. Notification (PCNtf) Message 916 The PCEP Notification message (also referred to as the PCNtf message) 917 can be sent either by a PCE to a PCC, or by a PCC to a PCE, to notify 918 of a specific event. The Message-Type field of the PCEP common 919 header is set to 5 (To be confirmed by IANA). 921 The PCNtf message MUST carry at least one NOTIFICATION object and MAY 922 contain several NOTIFICATION objects should the PCE or the PCC intend 923 to notify of multiple events. The NOTIFICATION object is defined in 924 Section 7.14. The PCNtf message MAY also contain RP objects (see 925 Section 7.4 when the notification refers to particular path 926 computation requests. 928 The PCNtf message may be sent by a PCC or a PCE in response to a 929 request or in an unsolicited manner. 931 The format of a PCNtf message is as follows: 932 ::= 933 935 ::= [] 937 ::= [] 938 940 ::=[] 942 ::=[] 944 6.7. Error (PCErr) Message 946 The PCEP Error message (also referred to as a PCErr message) is sent 947 in several situations: when a protocol error condition is met or when 948 the request is not compliant with the PCEP specification (e.g., 949 reception of a malformed message, reception of a message with a 950 mandatory missing object, policy violation, unexpected message, 951 unknown request reference, ...). The Message-Type field of the PCEP 952 common header is set to 6 (To be confirmed by IANA). 954 The PCErr message is sent by a PCC or a PCE in response to a request 955 or in an unsolicited manner. If the PCErr message is sent in 956 response to a request, the PCErr message MUST include the set of RP 957 objects related to the pending path computation requests that 958 triggered the error condition. In the later case (unsolicited), no 959 RP object is inserted in the PCErr message. For example, no RP 960 object is inserted in a PCErr when the error condition occurred 961 during the initialization phase. A PCErr message MUST contain a 962 PCEP-ERROR object specifying the PCEP error condition. The PCEP- 963 ERROR object is defined in section Section 7.15. 965 The format of a PCErr message is as follows: 966 ::= 967 ( [] ) | 968 [] 970 ::=[] 971 ::=[] 972 973 ::=[] 974 ::=[] 976 The procedure upon the receipt of a PCErr message is defined in 977 Section 7.15. 979 6.8. Close Message 981 The Close message is a PCEP message that is either sent by a PCC to a 982 PCE or by a PCE to a PCC in order to close an established PCEP 983 session. The Message-Type field of the PCEP common header for the 984 Close message is set to 7 (To be confirmed by IANA). 986 Close message 987 ::= 988 990 The Close message MUST contain exactly one CLOSE object (see 991 Section 6.8). If more than one CLOSE object is present, the first 992 MUST be processed and subsequent objects ignored. 994 Upon the receipt of a valid Close message, the receiving PCEP peer 995 MUST cancel all pending requests, it MUST close the TCP connection 996 and MUST NOT send any further PCEP messages on the PCEP session. 998 6.9. Reception of Unknown Messages 1000 A PCEP implementation that receives an unrecognized PCEP message MUST 1001 send a PCErr message with Error-value=2 (capability not supported). 1003 If a PCC/PCE receives unrecognized messages at a rate equal of 1004 greater than MAX-UNKNOWN-MESSAGES unknown message requests per 1005 minute, the PCC/PCE MUST send a PCEP CLOSE message with close 1006 value="Reception of an unacceptable number of unknown PCEP message". 1007 A RECOMMENDED value for MAX-UNKOWN-MESSAGES is 5. The PCC/PCE MUST 1008 close the TCP session and MUST NOT send any further PCEP messages on 1009 the PCEP session. 1011 7. Object Formats 1013 PCEP objects have a common format. They begin with a common object 1014 header (see Section 7.2). This is followed by object-specific fields 1015 defined for each different object. The object may also include one 1016 or more type-length-value (TLV) encoded data sets. Each TLV has the 1017 same structure as described in Section 7.1. 1019 7.1. PCE TLV Format 1021 A PCEP object may include a set of one or more optional TLVs. 1023 All PCEP TLVs have the following format: 1025 Type: 2 bytes 1026 Length: 2 bytes 1027 Value: variable 1028 A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes 1029 specifying the TLV length, and a value field. 1031 The Length field defines the length of the value portion in bytes. 1032 The TLV is padded to 4-bytes alignment; padding is not included in 1033 the Length field (so a three byte value would have a length of three, 1034 but the total size of the TLV would be eight bytes). 1036 Unrecognized TLVs MUST be ignored. 1038 IANA management of the PCEP Object TLV type identifier codespace is 1039 described in Section 9. 1041 7.2. Common Object Header 1043 A PCEP object carried within a PCEP message consists of one or more 1044 32-bit words with a common header which has the following format: 1045 0 1 2 3 1046 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 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Object-Class | OT |Res|P|I| Object Length (bytes) | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | | 1051 // (Object body) // 1052 | | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 Figure 8: PCEP common object header 1057 Object-Class (8 bits): identifies the PCEP object class. 1059 OT (Object-Type - 4 bits): identifies the PCEP object type. 1061 The Object-Class and Object-Type fields are managed by IANA. 1063 The Object-Class and Object-Type fields uniquely identify each PCEP 1064 object. 1066 Res flags (2 bits). Reserved field. This field MUST be set to zero 1067 on transmission and MUST be ignored on receipt. 1069 o P flag (Processing-Rule - 1-bit): the P flag allows a PCC to 1070 specify in a PCReq message sent to a PCE whether the object must 1071 be taken into account by the PCE during path computation or is 1072 just optional. When the P flag is set, the object MUST be taken 1073 into account by the PCE. Conversely, when the P flag is cleared, 1074 the object is optional and the PCE is free to ignore it. 1076 o I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 1077 message to indicate to a PCC whether or not an optional object was 1078 processed. The PCE MAY include the ignored optional object in its 1079 reply and set the I flag to indicate that the optional object was 1080 ignored during path computation. When the I flag is cleared, the 1081 PCE indicates that the optional object was processed during the 1082 path computation. The setting of the I flag for optional objects 1083 is purely indicative and optional. The I flag has no meaning in a 1084 PCRep message when the P flag has been set in the corresponding 1085 PCReq message. 1087 If the PCE does not understand an object with the P flag set or 1088 understands the object but decides to ignore the object, the entire 1089 PCEP message MUST be rejected and the PCE MUST send a PCErr message 1090 with Error-Type="Unknown Object" or "Not supported Object" along with 1091 the corresponding RP object. Note that if a PCReq includes multiple 1092 requests, only requests for which an object with the P flag set is 1093 unknown/unrecognized MUST be rejected. 1095 Object Length (16 bits). Specifies the total object length including 1096 the header, in bytes. The Object Length field MUST always be a 1097 multiple of 4, and at least 4. The maximum object content length is 1098 65528 bytes. 1100 7.3. OPEN Object 1102 The OPEN object MUST be present in each Open message and MAY be 1103 present in a PCErr message. There MUST be only one OPEN object per 1104 Open or PCErr message. 1106 The OPEN object contains a set of fields used to specify the PCEP 1107 version, Keepalive frequency, DeadTimer, PCEP session ID along with 1108 various flags. The OPEN object may also contain a set of TLVs used 1109 to convey various session characteristics such as the detailed PCE 1110 capabilities, policy rules and so on. No TLVs are currently defined. 1112 OPEN Object-Class is to be assigned by IANA (recommended value=1) 1114 OPEN Object-Type is to be assigned by IANA (recommended value=1) 1115 The format of the OPEN object body is as follows: 1117 0 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Ver | Flags | Keepalive | DeadTimer | SID | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | | 1123 // Optional TLVs // 1124 | | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 Figure 9: OPEN Object format 1129 Ver (3 bits): PCEP version. Current version is 1. 1131 Flags (5 bits): No Flags are currently defined. Unassigned bits are 1132 considered as reserved. They MUST be set to zero on transmission and 1133 MUST be ignored on receipt. 1135 Keepalive (8 bits): maximum period of time (in seconds) between two 1136 consecutive PCEP messages sent by the sender of this message. The 1137 minimum value for the Keepalive is 1 second. When set to 0, once the 1138 session is established, no further Keepalive messages are sent to the 1139 remote peer. A RECOMMENDED value for the keepalive frequency is 30 1140 seconds. 1142 DeadTimer (8 bits): specifies the amount of time after the expiration 1143 of which the PCEP peer can declare the session with the sender of the 1144 Open message down if no PCEP message has been received. The 1145 DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is 1146 set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value 1147 of the Keepalive. 1149 Example: 1151 A sends an Open message to B with Keepalive=10 seconds and 1152 Deadtimer=40 seconds. This means that A sends Keepalive messages (or 1153 any other PCEP message) to B every 10 seconds and B can declare the 1154 PCEP session with A down if no PCEP message has been received from A 1155 within any 40 second period. 1157 SID (PCEP session-ID - 8 bits): unsigned PCEP session number that 1158 identifies the current session. The SID MUST be incremented each 1159 time a new PCEP session is established and is used for logging and 1160 troubleshooting purposes. Each increment SHOULD have a value of 1 1161 and may cause a wrap back to zero. 1163 The SID is used to disambiguate instances of sessions to the same 1164 peer. A PCEP implementation could use a single source of SIDs across 1165 all peers, or one source for each peer. The former might constrain 1166 the implementation to only 256 concurrent sessions. The latter 1167 potentially requires more states. There is one SID number in each 1168 direction. 1170 Optional TLVs may be included within the OPEN object body to specify 1171 PCC or PCE characteristics. The specification of such TLVs is 1172 outside the scope of this document. 1174 When present in an Open message, the OPEN object specifies the 1175 proposed PCEP session characteristics. Upon receiving unacceptable 1176 PCEP session characteristics during the PCEP session initialization 1177 phase, the receiving PCEP peer (PCE) MAY include an OPEN object 1178 within the PCErr message so as to propose alternative acceptable 1179 session characteristic values. 1181 7.4. RP Object 1183 The RP (Request Parameters) object MUST be carried within each PCReq 1184 and PCRep messages and MAY be carried within PCNtf and PCErr 1185 messages. The RP object is used to specify various characteristics 1186 of the path computation request. 1188 The P flag of the RP object MUST be set in PCReq and PCReq messages 1189 and MUST be cleared in PCNtf and PCErr messages. If the RP objet is 1190 received with the P flag set incorrectely according to the rules 1191 states above, the receiving peer MUST send a PCErr message with 1192 Error-type=10 and Error-value=1. The corresponding path computation 1193 request MUST be cancelled by the PCE without further notification. 1195 7.4.1. Object Definition 1197 RP Object-Class is to be assigned by IANA (recommended value=2) 1199 RP Object-Type is to be assigned by IANA (recommended value=1) 1200 The format of the RP object body is as follows: 1202 0 1 2 3 1203 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 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | Flags |O|B|R| Pri | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Request-ID-number | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | | 1210 // Optional TLVs // 1211 | | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 Figure 10: RP object body format 1216 The RP object body has a variable length and may contain additional 1217 TLVs. No TLVs are currently defined. 1219 Flags (24 bits) 1221 The following flags are currently defined: 1223 o Pri (Priority - 3 bits): the Priority field may be used by the 1224 requesting PCC to specify to the PCE the request's priority from 1 1225 to 7. The decision of which priority should be used for a 1226 specific request is of a local matter and MUST be set to 0 when 1227 unused. Furthermore, the use of the path computation request 1228 priority by the PCE's scheduler is implementation specific and out 1229 of the scope of this document. Note that it is not required for a 1230 PCE to support the priority field: in this case, it is RECOMMENDED 1231 that the PCC set the priority field to 0 in the RP object. If the 1232 PCE does not take into account the request priority, it is 1233 RECOMMENDED to set the priority field to 0 in the RP object 1234 carried within the corresponding PCRep message, regardless of the 1235 priority value contained in the RP object carried within the 1236 corresponding PCReq message. A higher numerical value of the 1237 priority field reflects a higher priority. Note that it is the 1238 responsibility of the network administrator to make use of the 1239 priority values in a consistent manner across the various PCCs. 1240 The ability of a PCE to support request prioritization MAY be 1241 dynamically discovered by the PCCs by means of PCE capability 1242 discovery. If not advertised by the PCE, a PCC may decide to set 1243 the request priority and will learn the ability of the PCE to 1244 support request prioritization by observing the Priority field of 1245 the RP object received in the PCRep message. If the value of the 1246 Pri field is set to 0, this means that the PCE does not support 1247 the handling of request priorities: in other words, the path 1248 computation request has been honoured but without taking the 1249 request priority into account. 1251 o R (Reoptimization - 1 bit): when set, the requesting PCC specifies 1252 that the PCReq message relates to the reoptimization of an 1253 existing TE LSP. For all TE LSPs except 0-bandwidth LSPs, when 1254 the R bit is set, an RRO (see Section 7.10) MUST be included in 1255 the PCReq message to show the path of the existing TE LSP. Also, 1256 for all TE LSPs except 0-bandwidth LSPs, then the R bit is set, 1257 the existing bandwidth of the TE LSP to be reoptimized MUST be 1258 supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH 1259 object is in addition to the instance of that object used to 1260 describe the desired bandwidth of the reoptimized LSP. For 1261 0-bandwidth LSPs, the RRO and BANDWIDTH objects that report the 1262 characteristics of the existing TE LSP are optional. 1264 o B (Bi-directional - 1 bit): when set, the PCC specifies that the 1265 path computation request relates to a bidirectional TE LSP that 1266 has the same traffic engineering requirements including fate 1267 sharing, protection and restoration, LSRs, TE Links, and resource 1268 requirements (e.g., latency and jitter) in each direction. When 1269 cleared, the TE LSP is unidirectional. 1271 o O (strict/loose - 1 bit): when set, in a PCReq message, this 1272 indicates that a loose path is acceptable. Otherwise, when 1273 cleared, this indicates to the PCE that a path exclusively made of 1274 strict hops is required. In a PCRep message, when the O bit is 1275 set this indicates that the returned path is a loose path, 1276 otherwise (the O bit is cleared), the returned path is made of 1277 strict hops. 1279 Unassigned bits are considered as reserved. They MUST be set to zero 1280 on transmission and MUST be ignored on receipt. 1282 Request-ID-number (32 bits). The Request-ID-number value combined 1283 with the source IP address of the PCC and the PCE address uniquely 1284 identify the path computation request context. The Request-ID-number 1285 is used for disambiguation between pending requests and thus it MUST 1286 be changed (such as by incrementing it) each time a new request is 1287 sent to the PCE, and may wrap. 1289 The value 0x00000000 is considered as invalid. 1291 If no path computation reply is received from the PCE (e.g. request 1292 dropped by the PCE because of memory overflow), and the PCC wishes to 1293 resend its request, the same Request-ID-number MUST be used. Upon 1294 receiving a path computation request from a PCC with the same 1295 Request-ID-number the PCE SHOULD treat the request as a new request 1296 but an implementation MAY choose to cach path computation replies in 1297 order to quickly handle restranmission without having to handle twice 1298 a path computation request should have the first request been dropped 1299 or lost. Upon receiving a path computation reply from a PCE with the 1300 same Request-ID-number the PCC SHOULD silently discard the path 1301 computation reply. 1303 Conversely, different Request-ID-number MUST be used for different 1304 requests sent to a PCE. 1306 The same Request-ID-number MAY be used for path computation requests 1307 sent to different PCEs. The path computation reply is unambiguously 1308 identified by the IP source address of the replying PCE. 1310 7.4.2. Handling of the RP Object 1312 If a PCReq message is received that does not contain an RP object, 1313 the PCE MUST send a PCErr message to the requesting PCC with Error- 1314 type="Required Object missing" and Error-value="RP Object missing". 1316 If the O bit of the RP message carried within a PCReq message is 1317 cleared and local policy has been configured on the PCE to not 1318 provide explicit paths (for instance, for confidentiality reasons), a 1319 PCErr message MUST be sent by the PCE to the requesting PCC and the 1320 pending path computation request MUST be discarded. The Error-type 1321 is "Policy Violation" and Error-value is "O bit cleared". 1323 R bit: when the R bit of the RP object is set in a PCReq message, 1324 this indicates that the path computation request relates to the 1325 reoptimization of an existing TE LSP. In this case, the PCC MUST 1326 also provide the strict/loose path by including an RRO object in the 1327 PCReq message so as to avoid/limit double bandwidth counting if and 1328 only if the TE LSP is a non-0-bandwidth TE LSP. If the PCC has not 1329 requested a strict path (O bit set), a reoptimization can still be 1330 requested by the PCC but this requires that the PCE either be 1331 stateful (keep track of the previously computed path with the 1332 associated list of strict hops), or have the ability to retrieve the 1333 complete required path segment. Alternatively the PCC MUST inform 1334 the PCE of the working path with the associated list of strict hops 1335 in PCReq. The absence of an RRO in the PCReq message for a non-0- 1336 bandwidth TE LSP when the R bit of the RP object is set MUST trigger 1337 the sending of a PCErr message with Error-type="Required Object 1338 Missing" and Error-value="RRO Object missing for reoptimization". 1340 If a PCC/PCE receives a PCRep/PCReq message that contains a RP object 1341 referring to an unknown Request-ID-Number, the PCC/PCE MUST send a 1342 PCErr message with Error-Type="Unknown request reference". This is 1343 used for debugging purposes. If a PCC/PCE receives PCRep/PCReq at a 1344 rate equal of greater than MAX-UNKOWN-REQUESTS unknown requests per 1345 minute, the PCC/PCE MUST send a PCEP CLOSE message with close 1346 value="Reception of an unacceptable number of unknown requests/ 1347 replies". A RECOMMENDED value for MAX-UNKOWN-REQUESTS is 5. The 1348 PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP 1349 messages on the PCEP session. 1351 The reception of a PCEP message that contains a RP object referring 1352 to a Request-ID-number=0x00000000 MUST be treated similarly to an 1353 unkown request. 1355 7.5. NO-PATH Object 1357 The NO-PATH object is used in PCRep messages in response to an 1358 unsuccessful path computation request (the PCE could not find a path 1359 satisfying the set of constraints). When a PCE cannot find a path 1360 satisfying a set of constraints, it MUST include a NO-PATH object in 1361 the PCRep message. 1363 There are several categories of issue that can lead to a negative 1364 reply. For example, the PCE chain might be broken (should there be 1365 more than one PCE involved in the path computation) or no path 1366 obeying the set constraints could be found. The "NI (Nature of 1367 Issue)" field in the NO-PATH object is used to report the error 1368 category. 1370 Optionally, if the PCE supports such capability, the NO-PATH object 1371 MAY contain an optional NO-PATH-VECTOR TLV defined below and used to 1372 provide more information on the reasons that led to a negative reply. 1373 The PCRep message MAY also contain a list of objects that specify the 1374 set of constraints that could not be satisfied. The PCE MAY just 1375 replicate the set of objects that was received that was the cause of 1376 the unsuccessful computation or MAY optionally report a suggested 1377 value for which a path could have been found (in which case the value 1378 differs from the value in the original request). 1380 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1382 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1383 The format of the NO-PATH object body is as follows: 1385 0 1 2 3 1386 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 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 |Nature Of Issue|C| Flags | Reserved | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | | 1391 // Optional TLVs // 1392 | | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 Figure 11: NO-PATH Object Format 1397 NI - Nature Of Issue (8 bits): the NI field is used to report the 1398 nature of the issue that led to a negative reply. Two values are 1399 currently defined: 1401 0x00: No path satisfying the set of constraints could be found 1403 0x01: PCE chain broken 1405 The Nature Of Issue field value can be used by the PCC for various 1406 purposes: 1408 o Constraint adjustement before re-issuing a new path computation 1409 request, 1411 o Explicit selection of a new PCE chain, 1413 o Logging of the error type for futher action by the network 1414 admistrator 1416 IANA management of the NI field codespace is described in Section 9. 1418 Flags (16 bits). 1420 The following flag is currently defined: 1422 C flag (1 bit): when set, the PCE indicates the set of unsatisfied 1423 constraints (reasons why a path could not be found) in the PCRep 1424 message by including the relevant PCEP objects. When cleared, no 1425 failing constraints are specified. The C flag has no meaning and is 1426 ignored unless the NI field is set to 0x00. 1428 Unassigned bits are considered as reserved. They MUST be set to zero 1429 on transmission and MUST be ignored on receipt. 1431 Reserved (8 bits): This field MUST be set to zero on transmission and 1432 MUST be ignored on receipt. 1434 The NO-PATH object body has a variable length and may contain 1435 additional TLVs. The only TLV currently defined is the NO-PATH- 1436 VECTOR TLV defined below. 1438 Example: consider the case of a PCC that sends a path computation 1439 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1440 find a path for X MBits/s. In this case, the PCE must include in the 1441 PCRep message a NO-PATH object. Optionally the PCE may also include 1442 the original BANDWIDTH object so as to indicate that the reason for 1443 the unsuccessful computation is the bandwidth constraint (in this 1444 case, the NI field value is 0x00 and C flag is set). If the PCE 1445 supports such capability it may alternatively include the BANDWIDTH 1446 Object and report a value of Y in the bandwidth field of the 1447 BANDWIDTH object (in this case, the C flag is set) where Y refers to 1448 the bandwidth for which a TE LSP with the same other characteristics 1449 could have been computed. 1451 When the NO-PATH object is absent from a PCRep message, the path 1452 computation request has been fully satisfied and the corresponding 1453 paths are provided in the PCRep message. 1455 An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH 1456 object in order to provide more information on the reasons that led 1457 to a negative reply. 1459 The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in 1460 section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying 1461 the TLV length (length of the value portion in bytes) followed by a fixed 1462 length value field of 32-bit flags field. 1464 TYPE: To be assigned by IANA (suggested value=1) 1465 LENGTH: 4 1466 VALUE: 32-bit flags field 1468 IANA is requested to manage the space of flags carried in the NO- 1469 PATH-VECTOR TLV (see Section 9). 1471 The following flags are currently defined: 1473 o Bit number: 1 - PCE currently unavailable 1475 o Bit number: 2 - Unknown destination 1477 o Bit number: 3 - Unknown source 1479 7.6. END-POINT Object 1481 The END-POINTS object is used in a PCReq message to specify the 1482 source IP address and the destination IP address of the path for 1483 which a path computation is requested. The P flag of the END-POINT 1484 object MUST be set. If the END-POINT objet is received with the P 1485 flag cleared, the receiving peer MUST send a PCErr message with 1486 Error-type=10 and Error-value=1. The corresponding path computation 1487 request MUST be cancelled by the PCE without further notification. 1489 Note that the source and destination addresses specified in the END- 1490 POINTS object may or may not correspond to the source and destination 1491 IP address of the TE LSP but rather to a path segment. Two END- 1492 POINTS objects (for IPv4 and IPv6) are defined. 1494 END-POINTS Object-Class is to be assigned by IANA (recommended 1495 value=4) 1497 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 1498 for IPv4 and 2 for IPv6) 1499 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1500 as follows: 1502 0 1 2 3 1503 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 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | Source IPv4 address | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | Destination IPv4 address | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 Figure 12: END-POINTS Object Body Format for IPv4 1512 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 1514 0 1 2 3 1515 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 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | | 1518 | Source IPv6 address (16 bytes) | 1519 | | 1520 | | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | | 1523 | Destination IPv6 address (16 bytes) | 1524 | | 1525 | | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 Figure 13: END-POINTS Object Body Format for IPv6 1530 The END-POINTS object body has a fixed length of 8 bytes for IPv4 and 1531 32 bytes for IPv6. 1533 If more than one END-POINTS object is present, the first MUST be 1534 processed and subsequent objects ignored. 1536 7.7. BANDWIDTH Object 1538 The BANDWIDTH object is used to specify the requested bandwidth for a 1539 TE LSP. The notion of bandwidth is similar to the one used for RSVP 1540 signaling in [RFC2205], [RFC3209] and [RFC3473]. 1542 If the requested bandwidth is equal to 0, the BANDWIDTH object is 1543 optional. Conversely, if the requested bandwidth is non equal to 0, 1544 the PCReq message MUST contain a BANDWIDTH object. 1546 In the case of the reoptimization of a TE LSP, the bandwidth of the 1547 existing TE LSP MUST also be included in addition to the requested 1548 bandwidth if and only if the two values differ. Consequently, two 1549 Object-Type values are defined that refer to the requested bandwidth 1550 and the bandwidth of the TE LSP for which a reoptimization is being 1551 performed. 1553 The BANDWIDTH object may be carried within PCReq and PCRep messages. 1555 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1556 value=5) 1558 Two Object-Type values are defined for the BANDWIDTH object: 1560 o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by 1561 IANA (recommended value=1) 1563 o Bandwidth of an existing TE LSP for which a reoptimization is 1564 requested. BANDWIDTH Object-Type is to be assigned by IANA 1565 (recommended value=2) 1567 The format of the BANDWIDTH object body is as follows: 1569 0 1 2 3 1570 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 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Bandwidth | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 Figure 14: BANDWIDTH Object Body Format 1577 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1578 IEEE floating point format (see [IEEE.754.1985]), expressed in bytes 1579 per second. Refer to Section 3.1.2 of [RFC3471] for a table of 1580 commonly used values. 1582 The BANDWIDTH object body has a fixed length of 4 bytes. 1584 7.8. METRIC Object 1586 The METRIC object is optional and can be used for several purposes. 1588 In a PCReq message, a PCC MAY insert one of more METRIC objects: 1590 o To indicate the metric that MUST be optimized by the path 1591 computation algorithm (IGP metric, TE metric, Hop counts). 1592 Currently, three metrics are defined: the IGP cost, the TE metric 1593 (see [RFC3785]) and the number of hops traversed by a TE LSP. 1595 o To indicate a bound on the path cost that MUST NOT be exceeded for 1596 the path to be considered as acceptable by the PCC. 1598 In a PCRep message, the METRIC object MAY be inserted so as to 1599 provide the cost for the computed path. It MAY also be inserted 1600 within a PCRep with the NO-PATH object to indicate that the metric 1601 constraint could not be satisfied. 1603 The path computation algorithmic aspects used by the PCE to optimize 1604 a path with respect to a specific metric are outside the scope of 1605 this document. 1607 It must be understood that such path metrics are only meaningful if 1608 used consistently: for instance, if the delay of a computed path 1609 segment is exchanged between two PCEs residing in different domains, 1610 consistent ways of defining the delay must be used. 1612 The absence of the METRIC object MUST be interpreted by the PCE as a 1613 path computation request for which no constraints need be applied to 1614 any of the metrics. 1616 METRIC Object-Class is to be assigned by IANA (recommended value=6) 1618 METRIC Object-Type is to be assigned by IANA (recommended value=1) 1620 The format of the METRIC object body is as follows: 1622 0 1 2 3 1623 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 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 | Reserved | Flags |C|B| T | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | metric-value | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 Figure 15: METRIC Object Body Format 1632 The METRIC object body has a fixed length of 8 bytes. 1634 Reserved (16 bits): This field MUST be set to zero on transmission 1635 and MUST be ignored on receipt. 1637 T (Type - 8 bits): Specifies the metric type. 1639 Three values are currently defined: 1641 o T=1: IGP metric 1643 o T=2: TE metric 1645 o T=3: Hop Counts 1647 Flags (8 bits): Two flags are currently defined: 1649 o B (Bound - 1 bit): When set in a PCReq message, the metric-value 1650 indicates a bound (a maximum) for the path metric that must not be 1651 exceeded for the PCC to consider the computed path as acceptable. 1652 The path metric must be less than or equal to the value specified 1653 in the Metric-value field. When the B flag is cleared, the 1654 metric-value field is not used to reflect a bound constraint. 1656 o C (Computed Metric - 1 bit): When set in a PCReq message, this 1657 indicates that the PCE MUST provide the computed path metric value 1658 (should a path satisfying the constraints be found) in the PCRep 1659 message for the corresponding metric. 1661 Unassigned flags MUST be set to zero on transmission and MUST be 1662 ignored on receipt. 1664 Metric-value (32 bits): metric value encoded in 32 bits in IEEE 1665 floating point format (See [IEEE.754.1985]). 1667 Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 1668 message. There MUST be at most one instance of the METRIC object for 1669 each metric type with the same B flag value. If two or more 1670 instances of a METRIC object with the same B flag value are present 1671 for a metric type, only the first instance MUST be considered and 1672 other instances MUST be ignored. 1674 The presence of two METRIC objects of the same type with a different 1675 value of the B-Flag in a PCEReq message is allowed. Furthermore, it 1676 is also allowed to insert in a PCReq message two METRIC objects with 1677 different types that have both their B-Flag cleared: in this case, an 1678 objective function must be used by the PCE to solve a multi-parameter 1679 constraint problem. 1681 A METRIC object used to indicate the metric to optimize during the 1682 path computation MUST have the B-Flag cleared and the C-Flag set to 1683 the appropriate value. When the path computation relates to the 1684 reoptimization of an exiting TE LSP (in which case R-Flag of the RP 1685 object is set) an implementation MAY decide to set the metric-value 1686 field to the computed value of the metric of the TE LSP to be 1687 reoptimized with regards to a specific metric type. 1689 A METRIC object used to reflect a bound MUST have the B-Flag set, the 1690 C-Flag and metric-value field set to the appropriate values. 1692 In a PCRep message, unless not allowed by PCE policy, at least one 1693 METRIC object MUST be present that reports the computed path metric 1694 if the C bit of the METRIC object was set in the corresponding path 1695 computation request (the B-flag MUST be cleared). The C-flag has no 1696 meaning in a PCRep message. Optionally the PCRep message MAY contain 1697 additional METRIC objects that correspond to bound constraints, in 1698 which case the metric-value MUST be equal to the corresponding 1699 computed path metric (the B-flag MUST be set). If no path satisfying 1700 the constraints could be found by the PCE, the METRIC objects MAY 1701 also be present in the PCRep message with the NO-PATH object to 1702 indicate the constraint metric that could be satisfied. 1704 Example: if a PCC sends a path computation request to a PCE where the 1705 metric to optimize is the IGP metric and the TE metric must not 1706 exceed the value of M, two METRIC object are inserted in the PCReq 1707 message: 1709 o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000 1711 o Second METRIC Object with B=1, T=2, metric-value=M 1713 If a path satisfying the set of constraints can be found by the PCE 1714 and there is no policy that prevents the return of the computed 1715 metric, the PCE inserts one METRIC object with B=0, T=1, metric- 1716 value= computed IGP path cost. Additionally, the PCE may insert a 1717 second METRIC object with B=1, T=2, metric-value= computed TE path 1718 cost. 1720 7.9. Explicit Route Object 1722 The ERO is used to encode the path of a TE LSP through the network. 1723 The ERO is carried within a PCRep message to provide the computed TE 1724 LSP should the path computation have been successful. 1726 The contents of this object are identical in encoding to the contents 1727 of the Resource Reservation Protocol Traffic Engineering Extensions 1728 (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473] 1729 and [RFC3477]. That is, the object is constructed from a series of 1730 sub-objects. Any RSVP-TE ERO sub-object already defined or that 1731 could be defined in the future for use in the RSVP-TE ERO is 1732 acceptable in this object. 1734 PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types. 1736 Since the explicit path is available for immediate signaling by the 1737 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1738 and fields in this object are identical to those defined for the ERO. 1740 ERO Object-Class is to be assigned by IANA (recommended value=7) 1742 ERO Object-Type is to be assigned by IANA (recommended value=1) 1744 7.10. Reported Route Object 1746 The RRO is exclusively carried within a PCReq message so as to report 1747 the route followed by a TE LSP for which a reoptimization is desired. 1749 The contents of this object are identical in encoding to the contents 1750 of the Route Record Object defined in [RFC3209], [RFC3473] and 1751 [RFC3477]. That is, the object is constructed from a series of sub- 1752 objects. Any RSVP-TE RRO sub-object already defined or that could be 1753 defined in the future for use in the RSVP-TE RRO is acceptable in 1754 this object. 1756 The meanings of all of the sub-objects and fields in this object are 1757 identical to those defined for the RSVP-TE RRO. 1759 PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types. 1761 RRO Object-Class is to be assigned by IANA (recommended value=8) 1763 RRO Object-Type is to be assigned by IANA (recommended value=1) 1765 7.11. LSPA Object 1767 The LSPA object is optional and specifies various TE LSP attributes 1768 to be taken into account by the PCE during path computation. The 1769 LSPA (LSP Attributes) object can be carried within a PCReq message, 1770 or a PCRep message in case of unsuccessful path computation (in this 1771 case, the PCRep message also contains a NO-PATH object and the LSPA 1772 object is used to indicate the set of constraints that could not be 1773 satisfied). Most of the fields of the LSPA object are identical to 1774 the fields of the SESSION-ATTRIBUTE (C-Type = 7) object defined in 1775 [RFC3209] and [RFC4090]. When absent from the PCReq message, this 1776 means that the Setup and Holding priorities are equal to 0, and there 1777 are no affinity constraints. See section 4.7.4 of [RFC3209] for a 1778 detailed description of the use of resource affinities. 1780 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1782 LSPA Object-Types is to be assigned by IANA (recommended value=1) 1783 The format of the LSPA object body is: 1785 0 1 2 3 1786 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 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Exclude-any | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Include-any | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Include-all | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Setup Prio | Holding Prio | Flags |L| Reserved | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | | 1797 // Optional TLVs // 1798 | | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 Figure 16: LSPA Object Body Format 1802 Setup Prio (Setup Priority - 8 bits). The priority of the TE LSP 1803 with respect to taking resources, in the range of 0 to 7. The value 1804 0 is the highest priority. The Setup Priority is used in deciding 1805 whether this session can preempt another session. 1807 Holding Prio (Holding Priority - 8 bits). The priority of the TE LSP 1808 with respect to holding resources, in the range of 0 to 7. The value 1809 0 is the highest priority. Holding Priority is used in deciding 1810 whether this session can be preempted by another session. 1812 Flags (8 bits) 1814 The flag L corresponds to the "Local protection desired" bit 1815 ([RFC3209]) of the SESSION-ATTRIBUTE Object. 1817 L Flag (Local protection desired). When set, this means that the 1818 computed path must include links protected with Fast Reroute as 1819 defined in [RFC4090]. 1821 Unassigned flags MUST be set to zero on transmission and MUST be 1822 ignored on receipt. 1824 Reserved (8 bits): This field MUST be set to zero on transmission and 1825 MUST be ignored on receipt. 1827 Note that Optional TLVs may be defined in the future to carry 1828 additional TE LSP attributes such as those defined in [RFC4420]. 1830 7.12. Include Route Object Object 1832 The IRO (Include Route Object) is optional and can be used to specify 1833 that the computed path MUST traverse a set of specified network 1834 elements. The IRO MAY be carried within PCReq and PCRep messages. 1835 When carried within a PCRep message with the NO-PATH object, the IRO 1836 indicates the set of elements that cause de PCE to fail to find a 1837 path. 1839 IRO Object-Class is to be assigned by IANA (recommended value=10) 1841 IRO Object-Type is to be assigned by IANA (recommended value=1) 1843 0 1 2 3 1844 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 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | | 1847 // (Subobjects) // 1848 | | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 Figure 17: IRO Body Format 1853 Subobjects: The IRO is made of subobjects identical to the ones 1854 defined in [RFC3209], [RFC3473] and [RFC3477] where the IRO subobject 1855 type is identical to the subobject type defined in the related 1856 documents. 1858 The following subobject types are supported. 1860 Type Subobject 1861 1 IPv4 prefix 1862 2 IPv6 prefix 1863 4 Unnumbered Interface ID 1864 32 Autonomous system number 1865 The L bit of such sub-object has no meaning within an IRO. 1867 7.13. SVEC Object 1869 7.13.1. Notion of Dependent and Synchronized Path Computation Requests 1871 Independent versus dependent path computation requests: path 1872 computation requests are said to be independent if they are not 1873 related to each other. Conversely a set of dependent path 1874 computation requests is such that their computations cannot be 1875 performed independently of each other (a typical example of dependent 1876 requests is the computation of a set of diverse paths). 1878 Synchronized versus non-synchronized path computation requests: a set 1879 of path computation requests is said to be non-synchronized if their 1880 respective treatment (path computations) can be performed by a PCE in 1881 a serialized and independent fashion. 1883 There are various circumstances where the synchronization of a set of 1884 path computations may be beneficial or required. 1886 Consider the case of a set of N TE LSPs for which a PCC needs to send 1887 path computation requests to a PCE. The first solution consists of 1888 sending N separate PCReq messages to the selected PCE. In this case, 1889 the path computation requests are non-synchronized. Note that the 1890 PCC may chose to distribute the set of N requests across K PCEs for 1891 load balancing purposes. Considering that M (with M+-+-+-+-+-+-+ | | 3160 | | | KeepWait |----+ | 3161 | +--| |<---+ | 3162 |+-----+-+-+-+-+-+-+ | | 3163 || | | | 3164 || | | | 3165 || V | | 3166 || +->+-+-+-+-+-+-+----+ | 3167 || | | OpenWait |-------+ 3168 || +--| |<------+ 3169 ||+----+-+-+-+-+-+-+<---+ | 3170 ||| | | | 3171 ||| | | | 3172 ||| V | | 3173 ||| +->+-+-+-+-+-+-+ | | 3174 ||| | |TCPPending |----+ | 3175 ||| +--| | | 3176 |||+---+-+-+-+-+-+-+<---+ | 3177 |||| | | | 3178 |||| | | | 3179 |||| V | | 3180 |||+--->+-+-+-+-+ | | 3181 ||+---->| Idle |-------+ | 3182 |+----->| |----------+ 3183 +------>+-+-+-+-+ 3185 Figure 23: PCEP Finite State Machine for the PCC 3187 PCEP defines the following set of variables: 3189 Connect: timer (in seconds) started after having initialized a TCP 3190 connection using the PCEP registered TCP port. The value of the 3191 TCPConnect timer is 60 seconds. 3193 ConnectRetry: specifies the number of times the system has tried to 3194 establish a TCP connection with a PCEP peer without success. 3196 ConnectMaxRetry: Maximum number of times the system tries to 3197 establish a TCP connection using the PCEP registered TCP port before 3198 going back to the Idle state. The value of the ConnectMaxRetry is 5. 3200 OpenWait: timer that corresponds to the amount of time a PCEP peer 3201 will wait to receive an Open message from the PCEP peer after the 3202 expiration of which the system releases the PCEP resource and go back 3203 to the Idle state. The OpenWait timer has a fixed value of 60 3204 seconds. 3206 KeepWait: timer that corresponds to the amount of time a PCEP peer 3207 will wait to receive a Keepalive or a PCErr message from the PCEP 3208 peer after the expiration of which the system releases the PCEP 3209 resource and go back to the Idle state. The KeepWait timer has a 3210 fixed value of 60 seconds. 3212 OpenRetry: specifies the number of times the system has received an 3213 Open message with unacceptable PCEP session characteristics. 3215 The following two states variable are defined: 3217 RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system 3218 has received an acceptable Open message. 3220 LocalOK: the LocalOK variable is a Boolean set to 1 if the system has 3221 received a Keepalive message acknowledging that the Open message sent 3222 to the peer was valid. 3224 Idle State: 3226 The idle state is the initial PCEP state where PCEP (also referred to 3227 as "the system") waits for an initialization event that can either be 3228 manually triggered by the user (configuration) or automatically 3229 triggered by various events. In Idle state, PCEP resources are 3230 allocated (memory, potential process, ...) but no PCEP messages are 3231 accepted from any PCEP peer. The system listens the registered PCEP 3232 TCP port. 3234 The following set of variable are initialized: 3236 TCPRetry=0, 3238 LocalOK=0, 3240 RemoteOK=0, 3242 OpenRetry=0. 3244 Upon detection of a local initialization event (e.g. user 3245 configuration to establish a PCEP session with a particular PCEP 3246 peer, local event triggering the establishment of a PCEP session with 3247 a PCEP peer such as the automatic detection of a PCEP peer, ...), the 3248 system: 3250 o Initiates of a TCP connection with the PCEP peer, 3252 o Starts the Connect timer, 3254 o Moves to the TCPPending state. 3256 Upon receiving a TCP connection on the registered PCEP TCP port, if 3257 the TCP connection establishment succeeds, the system: 3259 o Sends an Open message, 3261 o Starts the OpenWait timer, 3263 o Moves to the OpenWait state. 3265 If the connection establishment fails, the system remains in the Idle 3266 state. Any other event received in the Idle state is ignored. 3268 It is expected that an implementation will use an exponentially 3269 increasing timer between automatically generated Initialization 3270 events and between retries of TCP connection establishment. 3272 TCPPending State 3274 If the TCP connection establishment succeeds, the system: 3276 o Sends an Open message, 3278 o Starts the OpenWait timer, 3280 o Moves to the OpenWait state. 3282 If the TCP connection establishment fails (an error is detected 3283 during the TCP connection establishment) or the Connect timer 3284 expires: 3286 o If ConnectRetry =ConnectMaxRetry the system moves to the Idle 3287 State 3289 o If ConnectRetry < ConnectMaxRetry the system: 3291 1. Initiates of a TCP connection with the PCEP peer, 3293 2. Increments the ConnectRetry variable, 3294 3. Restarts the Connect timer, 3296 4. Stays in the TPCPending state. 3298 In response to any other event the system releases the PCEP resources 3299 for that peer and moves back to the Idle state. 3301 OpenWait State: 3303 In the OpenWait state, the system waits for an Open message from its 3304 PCEP peer. 3306 If the system receives an Open message from the PCEP peer before the 3307 expiration of the OpenWait timer, the system first examines all of 3308 its sessions that are in the OpenWait or KeepWait state. If another 3309 session with the same PCEP peer already exists (same IP address), 3310 then the system performs the following collision resolution 3311 procedure: 3313 o If the system has initiated the current session and it has a lower 3314 IP address than the PCEP Peer, the system closes the TCP 3315 connection, releases the PCEP resources for the pending session 3316 and moves back to the Idle state. 3318 o If the session was initiated by the PCEP peer and the system has a 3319 higher IP address that the PCEP Peer, the system closes the TCP 3320 connection, releases the PCEP resources for the pending session, 3321 and moves back to the Idle state. 3323 o Otherwise, the system checks the PCEP session attributes 3324 (Keepalive frequency, DeadTimer, ...). 3326 If an error is detected (e.g. malformed Open message, reception of a 3327 message that is not an Open message, presence of two Open objects, 3328 ...), PCEP generates an error notification, the PCEP peer sends a 3329 PCErr message with Error-Type=1 and Error-value=1. The system 3330 releases the PCEP resources for the PCEP peer, closes the TCP 3331 connection and moves to the Idle state. 3333 If no errors are detected, OpenRetry=1 and the session 3334 characteristics are unacceptable, the PCEP peer sends a PCErr with 3335 Error-Type=1 and Error-value=5, the system releases the PCEP 3336 resources for that peer and moves back to the Idle state. 3338 If no errors are detected, and the session characteristics are 3339 acceptable to the local system, the system: 3341 o Sends a Keepalive message to the PCEP peer, 3343 o Starts the Keepalive timer, 3345 o Sets the RemoteOK variable to 1. 3347 If LocalOK=1 the system clears the OpenWait timer and moves to the UP 3348 state. 3350 If LocalOK=0 the system clears the OpenWait timer, starts the 3351 KeepWait timer and moves to the KeepWait state. 3353 If no errors are detected, but the session characteristics are 3354 unacceptable and non-negotiable, the PCEP peer sends a PCErr with 3355 Error-Type=1 and Error-value=3, the system releases the PCEP 3356 resources for that peer, and moves back to the Idle state. 3358 If no errors are detected, and OpenRetry is 0, and the session 3359 characteristics are unacceptable but negotiable (such as, the 3360 Keepalive period or the DeadTimer), then the system: 3362 o Increments the OpenRetry variable, 3364 o Sends a PCErr message with Error-Type=1 and Error-value=4 that 3365 contains proposed acceptable session characteristics, 3367 o If LocalOK=1, the system restarts the OpenWait timer and stays in 3368 the OpenWait state 3370 o If LocalOK=0, the system clears the OpenWait timer, starts the 3371 KeepWait timer and moves to the KeepWait state 3373 If no Open message is received before the expiration of the OpenWait 3374 timer, the PCEP peer sends a PCErr message with Error-Type=1 and 3375 Error-value=2, the system releases the PCEP resources for the PCEP 3376 peer, closes the TCP connection and moves to the Idle state. 3378 In response to any other event the system releases the PCEP resources 3379 for that peer and moves back to the Idle state. 3381 KeepWait State 3383 In the Keepwait state, the system waits for the receipt of a 3384 Keepalive from its PCEP peer acknowledging its Open message or a 3385 PCErr message in response to unacceptable PCEP session 3386 characteristics proposed in the Open message. 3388 If an error is detected (e.g. malformed Keepalive message), PCEP 3389 generates an error notification, the PCEP peer sends a PCErr message 3390 with Error-Type=1 and Error-value=1. The system releases the PCEP 3391 resources for the PCEP peer, closes the TCP connection and moves to 3392 the Idle state. 3394 If a Keepalive message is received before the expiration of the 3395 KeepWait timer, then the system sets LocalOK=1 and: 3397 o If RemoteOK=1, the system clears the KeepWait timer and moves to 3398 the UP state. 3400 o If RemoteOK=0, the system clears the KeepWait timer, starts the 3401 OpenWait timer and moves to the OpenWait State. 3403 If a PCErr message is received before the expiration of the KeepWait 3404 timer: 3406 1. If the proposed values are unacceptable, the PCEP peer sends a 3407 PCErr message with Error-Type=1 and Error-value=6 and the system 3408 releases the PCEP resources for that PCEP peer, closes the TCP 3409 connection and moves to the Idle state. 3411 2. If the proposed values are acceptable, the system adjusts its 3412 PCEP session characteristics according to the proposed values 3413 received in the PCErr message restarts the KeepWait timer and 3414 sends a new Open message. If RemoteOK=1, the system restarts the 3415 KeepWait timer and stays in the KeepWait state. If RemoteOK=0, 3416 the system clears the KeepWait timer, start the OpenWait timer 3417 and moves to the OpenWait state. 3419 If neither a Keepalive nor a PCErr is received after the expiration 3420 of the KeepWait timer, the PCEP peer sends a PCErr message with 3421 Error-Type=1 and Error-value=7 and, system releases the PCEP 3422 resources for that PCEP peer, closes the TCP connection and moves to 3423 the Idle State. 3425 In response to any other event the system releases the PCEP resources 3426 for that peer and moves back to the Idle state. 3428 UP State 3430 In the UP state, the PCEP peer starts exchanging PCEP messages 3431 according to the session characteristics. 3433 If the Keepalive timer expires, the system restarts the Keepalive 3434 timer and sends a Keepalive message. 3436 If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from 3437 the PCEP peer before the expiration of the DeadTimer, the system 3438 terminates PCEP session according to the procedure defined in 3439 Section 6.8, releases the PCEP resources for that PCEP peer, closes 3440 the TCP connection and moves to the Idle State. 3442 If a malformed message is received, the system terminates the PCEP 3443 session according to the procedure defined in Section 6.8, releases 3444 the PCEP resources for that PCEP peer, closes the TCP connection and 3445 moves to the Idle State. 3447 If the system detects that the PCEP peer tries to setup a second TCP 3448 connection, it stops the TCP connection establishment and sends a 3449 PCErr with Error-Type=9. 3451 If the TCP connection fails, the system releases the PCEP resources 3452 for that PCEP peer, closes the TCP connection and moves to the Idle 3453 State. 3455 Appendix B. PCEP Variables 3457 PCEP defines the following configurable variables: 3459 Keepalive timer: minimum period of time between the sending of PCEP 3460 messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A 3461 suggested value for the Keepalive timer is 30 seconds. 3463 DeadTimer: period of timer after the expiration of which a PCEP peer 3464 declared the session down if no PCEP message has been received. 3466 SyncTimer: the SYNC timer is used in the case of synchronized path 3467 computation request using the SVEC object defined in Section 7.13.3. 3468 Consider the case where a PCReq message is received by a PCE that 3469 contains the SVEC object referring to M synchronized path computation 3470 requests. If after the expiration of the SYNC timer all the M path 3471 computation requests have not been received, a protocol error is 3472 triggered and the PCE MUST cancel the whole set of path computation 3473 requests. The aim of the SyncTimer is to avoid the storage of unused 3474 synchronized request should one of them get lost for some reasons 3475 (e.g a misbehaving PCC). Thus the value of the Synctimer must be 3476 large enough to avoid the expiration of the timer under normal 3477 circumstances. A RECOMMENDED value for the SYNC timer is 60 seconds. 3479 MAX-UNKNOWN-REQUESTS: A RECOMMENDED value is 5. 3481 MAX-UNKNOWN-MESSAGES: A RECOMMENDED value is 5. 3483 Authors' Addresses 3485 JP Vasseur (editor) 3486 Cisco Systems 3487 1414 Massachusetts Avenue 3488 Boxborough, MA 01719 3489 USA 3491 Email: jpv@cisco.com 3493 JL Le Roux (editor) 3494 France Telecom 3495 2, Avenue Pierre-Marzin 3496 Lannion, 22307 3497 FRANCE 3499 Email: jeanlouis.leroux@orange-ftgroup.com 3501 Full Copyright Statement 3503 Copyright (C) The IETF Trust (2008). 3505 This document is subject to the rights, licenses and restrictions 3506 contained in BCP 78, and except as set forth therein, the authors 3507 retain all their rights. 3509 This document and the information contained herein are provided on an 3510 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3511 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3512 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3513 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3514 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3515 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3517 Intellectual Property 3519 The IETF takes no position regarding the validity or scope of any 3520 Intellectual Property Rights or other rights that might be claimed to 3521 pertain to the implementation or use of the technology described in 3522 this document or the extent to which any license under such rights 3523 might or might not be available; nor does it represent that it has 3524 made any independent effort to identify any such rights. Information 3525 on the procedures with respect to rights in RFC documents can be 3526 found in BCP 78 and BCP 79. 3528 Copies of IPR disclosures made to the IETF Secretariat and any 3529 assurances of licenses to be made available, or the result of an 3530 attempt made to obtain a general license or permission for the use of 3531 such proprietary rights by implementers or users of this 3532 specification can be obtained from the IETF on-line IPR repository at 3533 http://www.ietf.org/ipr. 3535 The IETF invites any interested party to bring to its attention any 3536 copyrights, patents or patent applications, or other proprietary 3537 rights that may cover technology that may be required to implement 3538 this standard. Please address the information to the IETF at 3539 ietf-ipr@ietf.org.