idnits 2.17.1 draft-ietf-pce-pcep-09.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 3168. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3186. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3192. 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 61 instances of too long lines in the document, the longest one being 57 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 6005 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) == Outdated reference: A later version (-15) exists of draft-ietf-pce-inter-layer-req-06 == Outdated reference: A later version (-06) exists of draft-ietf-pce-interas-pcecp-reqs-03 == Outdated reference: A later version (-11) exists of draft-ietf-pce-manageability-requirements-02 == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-08 == 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 3036 (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 4420 (Obsoleted by RFC 5420) Summary: 2 errors (**), 0 flaws (~~), 6 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: May 19, 2008 France Telecom 5 November 16, 2007 7 Path Computation Element (PCE) communication Protocol (PCEP) 8 draft-ietf-pce-pcep-09.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 19, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies the Path Computation Element communication 42 Protocol (PCEP) for communications between a Path Computation Client 43 (PCC) and a Path Computation Element (PCE), or between two PCEs. 44 Such interactions include path computation requests and path 45 computation replies as well as notifications of specific states 46 related to the use of a PCE in the context of Multiprotocol Label 47 Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. The 48 PCEP protocol is designed to be flexible and extensible so as to 49 easily allow for the addition of further messages and objects, should 50 further requirements be expressed in the future. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [RFC2119]. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Architectural Protocol Overview (Model) . . . . . . . . . . . 5 64 4.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2. Architectural Protocol Overview . . . . . . . . . . . . . 6 66 4.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 7 67 4.2.2. Path computation request sent by a PCC to a PCE . . . 8 68 4.2.3. Path computation reply sent by the PCE to a PCC . . . 9 69 4.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 11 70 4.2.5. Error . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2.6. Termination of the PCEP Session . . . . . . . . . . . 13 72 5. Transport protocol . . . . . . . . . . . . . . . . . . . . . . 13 73 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 14 75 6.2. Open message . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.3. Keepalive message . . . . . . . . . . . . . . . . . . . . 16 77 6.4. Path Computation Request (PCReq) message . . . . . . . . . 17 78 6.5. Path Computation Reply (PCRep) message . . . . . . . . . . 18 79 6.6. Notification (PCNtf) message . . . . . . . . . . . . . . . 20 80 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 21 81 6.8. Close message . . . . . . . . . . . . . . . . . . . . . . 21 82 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 22 83 7.1. PCE TLV Format . . . . . . . . . . . . . . . . . . . . . . 22 84 7.2. Common object header . . . . . . . . . . . . . . . . . . . 22 85 7.3. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 24 86 7.4. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 25 87 7.4.1. Object definition . . . . . . . . . . . . . . . . . . 25 88 7.4.2. Handling of the RP object . . . . . . . . . . . . . . 28 89 7.5. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 28 90 7.6. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 31 91 7.7. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 32 92 7.8. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 33 93 7.9. Explicit Route Object . . . . . . . . . . . . . . . . . . 36 94 7.10. Route Record Object . . . . . . . . . . . . . . . . . . . 36 95 7.11. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 37 96 7.12. Include Route Object Object . . . . . . . . . . . . . . . 39 97 7.13. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 39 98 7.13.1. Notion of Dependent and Synchronized path 99 computation requests . . . . . . . . . . . . . . . . . 39 100 7.13.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 41 101 7.13.3. Handling of the SVEC Object . . . . . . . . . . . . . 42 102 7.14. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 43 103 7.15. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 46 104 7.16. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 50 105 7.17. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 51 106 8. Manageability Considerations . . . . . . . . . . . . . . . . . 52 107 8.1. Control of Function and Policy . . . . . . . . . . . . . . 52 108 8.2. Information and Data Models . . . . . . . . . . . . . . . 54 109 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 54 110 8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 54 111 8.5. Requirements on Other Protocols and Functional 112 Componentssection . . . . . . . . . . . . . . . . . . . . 55 113 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 55 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 115 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 55 116 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 55 117 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 55 118 9.4. Notification Object . . . . . . . . . . . . . . . . . . . 57 119 9.5. PCEP Error Object . . . . . . . . . . . . . . . . . . . . 57 120 9.6. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 58 121 9.7. PCEP TLV format . . . . . . . . . . . . . . . . . . . . . 59 122 9.8. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 59 123 10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 59 124 11. Security Considerations . . . . . . . . . . . . . . . . . . . 66 125 11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 66 126 11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 67 127 11.3. Protection against Denial of Service attacks . . . . . . . 67 128 11.4. Request input shaping/policing . . . . . . . . . . . . . . 67 129 12. Authors' addresses . . . . . . . . . . . . . . . . . . . . . . 68 130 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 131 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 132 14.1. Normative References . . . . . . . . . . . . . . . . . . . 69 133 14.2. Informative References . . . . . . . . . . . . . . . . . . 69 134 Appendix A. PCEP Variables . . . . . . . . . . . . . . . . . . . 71 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72 136 Intellectual Property and Copyright Statements . . . . . . . . . . 73 138 1. Terminology 140 Terminology used in this document 142 AS: Autonomous System. 144 Explicit path: full explicit path from start to destination made of a 145 list of strict hops where a hop may be an abstract node such as an 146 AS. 148 IGP area: OSPF area or IS-IS level. 150 Inter-domain TE LSP: A TE LSP whose path transits across at least two 151 different domains where a domain can either be an IGP area, an 152 Autonomous System or a sub-AS (BGP confederations). 154 PCC: Path Computation Client: any client application requesting a 155 path computation to be performed by a Path Computation Element. 157 PCE: Path Computation Element: an entity (component, application or 158 network node) that is capable of computing a network path or route 159 based on a network graph and applying computational constraints. 161 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or a 162 PCE). 164 TED: Traffic Engineering Database that contains the topology and 165 resource information of the domain. The TED may be fed by IGP 166 extensions or potentially by other means. 168 TE LSP: Traffic Engineering Label Switched Path. 170 Strict/loose path: mix of strict and loose hops comprising of at 171 least one loose hop representing the destination where a hop may be 172 an abstract node such as an AS. 174 Within this document, when describing PCE-PCE communications, the 175 requesting PCE fills the role of a PCC. This provides a saving in 176 documentation without loss of function. 178 2. Introduction 180 [RFC4655] describes the motivations and architecture for a PCE-based 181 model for the computation of MPLS and GMPLS TE LSPs. The model 182 allows for the separation of PCE from PCC, and allows for the 183 cooperation between PCEs. This necessitates a communication protocol 184 between PCC and PCE, and between PCEs. [RFC4657] states the generic 185 requirements for such protocol including the requirement for using 186 the same protocol between PCC and PCE, and between PCEs. Additional 187 application-specific requirements (for scenarios such as inter-area, 188 inter-AS, etc.) are not included in [RFC4657], but there is a 189 requirement that any solution protocol must be easily extensible to 190 handle other requirements as they are introduced in application- 191 specific requirements documents. Examples of such application- 192 specific requirements are [RFC4927], 193 [I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req]. 195 This document specifies the Path Computation Element communication 196 Protocol (PCEP) for communications between a Path Computation Client 197 (PCC) and a Path Computation Element (PCE), or between two PCEs, in 198 compliance with [RFC4657]. Such interactions include path 199 computation requests and path computation replies as well as 200 notifications of specific states related to the use of a PCE in the 201 context of MPLS and GMPLS Traffic Engineering. 203 PCEP is designed to be flexible and extensible so as to easily allow 204 for the addition of further messages and objects, should further 205 requirements be expressed in the future. 207 3. Assumptions 209 [RFC4655] describes various types of PCE. PCEP does not make any 210 assumption and thus does not impose any constraint on the nature of 211 the PCE. 213 Moreover, it is assumed that the PCE gets the required information so 214 as to perform the computation of TE LSP that usually requires network 215 topology and resource information. Such information can be gathered 216 by routing protocols or by some other means, the gathering of which 217 is out of the scope of this document. 219 Similarly, no assumption is made on the discovery method used by a 220 PCC to discover a set of PCEs (e.g. via static configuration or 221 dynamic discovery) and on the algorithm used to select a PCE. For 222 the sake of reference [RFC4674] defines a list of requirements for 223 dynamic PCE discovery and IGP-based solutions for such PCE discovery 224 are specified in [I-D.ietf-pce-disco-proto-ospf] and 225 [I-D.ietf-pce-disco-proto-isis]. 227 4. Architectural Protocol Overview (Model) 229 The aim of this section is to describe the PCEP model in the spirit 230 of [RFC4101]. An architecture protocol overview (the big picture of 231 the protocol) is provided in this section. Protocol details can be 232 found in further sections. 234 4.1. Problem 236 The PCE-based architecture used for the computation of MPLS and GMPLS 237 TE LSP is described in [RFC4655]. When the PCC and the PCE are not 238 collocated, a communication protocol between the PCC and the PCE is 239 needed. PCEP is such a protocol designed specifically for 240 communications between a PCC and a PCE or between two PCEs in 241 compliance with [RFC4657]: a PCC may use PCEP to send a path 242 computation request for one or more TE LSP(s) to a PCE and the PCE 243 may reply with a set of computed path(s) if one or more path(s) that 244 satisfy the set of constraints can be found. 246 4.2. Architectural Protocol Overview 248 PCEP operates over TCP, which fulfils the requirements for reliable 249 messaging and flow control without further protocol work. 251 Several PCEP messages are defined: 253 - Open and Keepalive messages are used to initiate and maintain a 254 PCEP session respectively. 256 - PCReq: a PCEP message sent by a PCC to a PCE to request a path 257 computation. 259 - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path 260 computation request. A PCRep message can either contain a set of 261 computed path(s) if the request can be satisfied or a negative reply 262 otherwise in which case the negative reply may also indicate the 263 reason why no path could be found. 265 - PCNtf: a PCEP notification message either sent by a PCC to a PCE or 266 a PCE to a PCC to notify of a specific event. 268 - PCErr: a PCEP message sent upon the occurrence of a protocol error 269 condition. 271 - Close message: a message used to close a PCEP session. 273 The set of available PCE(s) may either be statically configured on a 274 PCC or dynamically discovered. The mechanisms used to discover one 275 or more PCE(s) and to select a PCE are out of the scope of this 276 document. 278 A PCC may have PCEP sessions with more than one PCE and similarly a 279 PCE may have PCEP sessions with multiple PCCs. 281 4.2.1. Initialization Phase 283 The initialization phase consists of two successive steps (described 284 in a schematic form in Figure 1): 286 1) Establishment of a TCP connection (3-way handshake) between the 287 PCC and the PCE. 289 2) Establishment of a PCEP session over the TCP connection. 291 Once the TCP connection is established, the PCC and the PCE (also 292 referred to as "PCEP peers") initiate a PCEP session establishment 293 during which various session parameters are negotiated. These 294 parameters are carried within Open messages and include the Keepalive 295 timer, the Deadtimer and potentially other detailed capabilities and 296 policy rules that specify the conditions under which path computation 297 requests may be sent to the PCE. If the PCEP session establishment 298 phase fails because the PCEP peers disagree on the session parameters 299 or one of the PCEP peers does not answer after the expiration of the 300 establishment timer, the TCP connection is immediately closed. 301 Successive retries are permitted but an implementation should make 302 use of an exponential back-off session establishment retry procedure. 304 Keepalive messages are used to acknowledge Open messages and once the 305 PCEP session has been successfully established, Keepalive messages 306 may be exchanged between PCEP peers to ensure the liveness of the 307 PCEP session. 309 A single PCEP session can exist between a pair a PCEP peers. 311 Details about the Open message and the Keepalive messages can be 312 found inSection 6.2 and Section 6.3 respectively. 314 +-+-+ +-+-+ 315 |PCC| |PCE| 316 +-+-+ +-+-+ 317 | | 318 |---- Open message --->| 319 | | 320 |<--- Open message ----| 321 | | 322 | | 323 | | 324 |<--- Keepalive -------| 325 | | 326 |---- Keepalive ------>| 328 Figure 1: PCEP Initialization phase (initiated by a PCC) 330 (Note that the exchange of Keepalive messages is optional) 332 4.2.2. Path computation request sent by a PCC to a PCE 334 +-+-+ +-+-+ 335 |PCC| |PCE| 336 +-+-+ +-+-+ 337 1)Path computation | | 338 event | | 339 2)PCE Selection | | 340 3)Path computation |---- PCReq message--->| 341 request sent to | | 342 the selected PCE | | 344 Figure 2: Path computation request 346 Once a PCC has successfully established a PCEP session with one or 347 more PCEs, if an event is triggered that requires the computation of 348 a set of path(s), the PCC first selects one or more PCE(s). Note 349 that the PCE selection decision process may have taken place prior to 350 the PCEP session establishment. 352 Once the PCC has selected a PCE, it sends a path computation request 353 to the PCE (PCReq message) that contains a variety of objects that 354 specify the set of constraints and attributes for the path to be 355 computed. For example "Compute a TE LSP path with source IP 356 address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B 357 Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may 358 desire to specify the urgency of such request by assigning a request 359 priority. Each request is uniquely identified by a request-id number 360 and the PCC-PCE address pair. The process is shown in a schematic 361 form in figure 2. 363 Details about the PCReq message can be found in Section 6.4 365 4.2.3. Path computation reply sent by the PCE to a PCC 366 +-+-+ +-+-+ 367 |PCC| |PCE| 368 +-+-+ +-+-+ 369 | | 370 |---- PCReq message--->| 371 | |1) Path computation 372 | |request received 373 | | 374 | |2)Path successfully 375 | |computed 376 | | 377 | |3) Computed path(s) sent 378 | |to the PCC 379 |<--- PCRep message ---| 380 | (Positive reply) | 382 Figure 3a: Path computation request with successful path computation 384 +-+-+ +-+-+ 385 |PCC| |PCE| 386 +-+-+ +-+-+ 387 | | 388 | | 389 |---- PCReq message--->| 390 | |1) Path computation 391 | |request received 392 | | 393 | |2) No Path found that 394 | |satisfies the request 395 | | 396 | |3) Negative reply sent to 397 | |the PCC (optionally with 398 | |various additional 399 | |information) 400 |<--- PCRep message ---| 401 | (Negative reply) | 403 Figure 3b: Path computation request with unsuccessful path computation 405 Upon receiving a path computation request from a PCC, the PCE 406 triggers a path computation, the result of which can either be: 408 o Positive (Figure 3-a): the PCE manages to compute a path that 409 satisfies the set of required constraints, in which case the PCE 410 returns the set of computed path(s) to the requesting PCC. Note 411 that PCEP supports the capability to send a single request that 412 requires the computation of more than one path (e.g. computation 413 of a set of link-diverse paths). 415 o Negative (Figure 3-b): no path could be found that satisfies the 416 set of constraints. In this case, a PCE may provide the set of 417 constraints that led to the path computation failure. Upon 418 receiving a negative reply, a PCC may decide to resend a modified 419 request or take any other appropriate action. 421 Details about the PCRep message can be found in Section 6.5. 423 4.2.4. Notification 425 There are several circumstances whereby a PCE may want to notify a 426 PCC of a specific event. For example, suppose that the PCE suddenly 427 gets overloaded thus potentially leading to unacceptable response 428 times. The PCE may want to notify one or more PCCs that some of 429 their requests (listed in the notification) will not be satisfied or 430 may experience unacceptable delays. Upon receiving such 431 notification, the PCC may decide to redirect it(s) path computation 432 request(s) to another PCE should an alternate PCE be available. 433 Similarly, a PCC may desire to notify a PCE of a particular event 434 such as the cancellation of pending request(s). 436 +-+-+ +-+-+ 437 |PCC| |PCE| 438 +-+-+ +-+-+ 439 1)Path computation | | 440 event | | 441 2)PCE Selection | | 442 3)Path computation |---- PCReq message--->| 443 request X sent to | |4) Path computation 444 the selected PCE | |triggered 445 | | 446 | | 447 5) Path computation| | 448 request X cancelled| | 449 |---- PCNtf message -->| 450 | |6) Path computation 451 | |request X cancelled 453 Figure 4: Example of PCC notification (cancellation notification) sent to a PCE 455 +-+-+ +-+-+ 456 |PCC| |PCE| 457 +-+-+ +-+-+ 458 1)Path computation | | 459 event | | 460 2)PCE Selection | | 461 3)Path computation |---- PCReq message--->| 462 request X sent to | |4) Path computation 463 the selected PCE | |triggered 464 | | 465 | | 466 | |5) PCE gets overloaded 467 | | 468 | | 469 | |6) Path computation 470 | |request X cancelled 471 | | 472 |<--- PCNtf message----| 474 Figure 5: Example of PCE notification (cancellation notification) sent to a PCC 476 Details about the PCNtf message can be found in Section 6.6. 478 4.2.5. Error 480 PCEP Error messages are sent when a protocol error condition is met 481 (e.g. unknown object, non supported object, policy violation, ...). 483 +-+-+ +-+-+ 484 |PCC| |PCE| 485 +-+-+ +-+-+ 486 1)Path computation | | 487 event | | 488 2)PCE Selection | | 489 3)Path computation |---- PCReq message--->| 490 request X sent to | |4) Path computation 491 the selected PCE | |triggered => Policy 492 | |violation ! 493 | |5) Request discarded 494 | | 495 |<-- PCErr message ---| 496 | | 498 Figure 6: Example of Error message (policy violation) sent by a PCE 500 Details about the PCErr message can be found in Section 6.7. 502 4.2.6. Termination of the PCEP Session 504 When one of the PCEP peers desires to terminate a PCEP session it 505 first sends a PCEP Close message and then closes the TCP connection. 506 If the PCEP session is terminated by the PCE, the PCC clears all the 507 states related to pending requests previously sent to the PCE. 508 Similarly, if the PCC terminates a PCEP session the PCE clears all 509 pending path computation requests sent by the PCC in question as well 510 as the related states. A Close message can only be sent to terminate 511 a PCEP session if the PCEP session has previously been established. 513 In case of TCP connection failure, the PCEP session is immediately 514 terminated. 516 Details about the Close message can be found in Section 6.8. 518 5. Transport protocol 520 PCEP operates over TCP using a well-known TCP port (to be assigned by 521 IANA). This allows the requirements of reliable messaging and flow 522 control to be met without further protocol work. 524 An implementation may decide to keep the TCP connection alive for an 525 unlimited time (this may for instance be appropriate when path 526 computation requests are sent on a frequent basis so as to avoid to 527 open a TCP connection each time a path computation request is needed, 528 which would incur additional processing delays). Conversely, in some 529 other circumstances, it may be desirable to systematically open and 530 close the TCP connection for each PCEP request (for instance when 531 sending a path computation request is a rare event). 533 6. PCEP Messages 535 A PCEP message consists of a common header followed by a variable 536 length body made of a set of objects that can either be mandatory or 537 optional. In the context of this document, an object is said to be 538 mandatory in a PCEP message when the object MUST be included for the 539 message to be considered as valid. A PCEP message with a missing 540 mandatory object MUST trigger an Error message (see Section 7.15). 541 Conversely, if an object is optional, the object may or may not be 542 present. 544 A flag referred to as the P flag is defined in the common header of 545 each PCEP object (see Section 7.2) that can be set by a PCEP peer to 546 enforce a PCE to take into account the related information during the 547 path computation. For example, the METRIC object defined in 548 Section 7.8 allows a PCC to specify a bounded acceptable path cost. 549 The METRIC object is optional but a PCC may set a flag to ensure that 550 such constraint is taken into account. Similarly to the previous 551 case, if such constraint cannot be taken into account by the PCE, the 552 PCE MUST trigger an Error message. 554 For each PCEP message type, rules are defined that specify the set of 555 objects that the message can carry. We use the Backus-Naur Form 556 (BNF) to specify such rules. Square brackets refer to optional sub- 557 sequences. An implementation MUST form the PCEP messages using the 558 object ordering specified in this document. 560 6.1. Common header 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Ver | Flags | Message-Type | Message-Lenght | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Figure 7: PCEP message common header 569 Ver (Version - 3 bits): PCEP version number. Current version is 570 version 1. 572 Flags (5 bits): no flags are currently defined. Unassigned bits are 573 considered as reserved and MUST be set to zero on transmission. 575 Message-Type (8 bits): 577 The following message types are currently defined (to be confirmed by 578 IANA). 579 Value Meaning 580 1 Open 581 2 Keepalive 582 3 Path Computation Request 583 4 Path Computation Reply 584 5 Notification 585 6 Error 586 7 Close 588 Message-Length (16 bits): total length of the PCEP message expressed 589 in bytes including the common header. 591 6.2. Open message 593 The Open message is a PCEP message sent by a PCC to a PCE and a PCE 594 to a PCC in order to establish a PCEP session. The Message-Type 595 field of the PCEP common header for the Open message is set to 1 (To 596 be confirmed by IANA). 598 Once the TCP connection has been successfully established, the first 599 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 600 an Open message as specified in Section 10. Any message received 601 prior to an Open message MUST trigger a protocol error condition and 602 the PCEP session MUST be terminated. The Open message is used to 603 establish a PCEP session between the PCEP peers. During the 604 establishment phase the PCEP peers exchange several session 605 characteristics. If both parties agree on such characteristics the 606 PCEP session is successfully established. 608 Open message 609 ::= 610 611 The Open message MUST contain exactly one OPEN object (see 612 Section 7.3). Various session characteristics are specified within 613 the OPEN object. Once the TCP connection has been successfully 614 established the sender MUST start an initialization timer called 615 OpenWait after the expiration of which if no Open message has been 616 received it sends a PCErr message and releases the TCP connection 617 (see Section 10 for details). 619 Once an Open message has been sent to a PCEP peer, the sender MUST 620 start an initialization timer called KeepWait after the expiration of 621 which if neither a KeepAlive message has been received nor a PCErr 622 message in case of disagreement of the session characteristics, a 623 PCErr message MUST be sent and the TCP connection MUST be released 624 (see Section 10 for details). 626 The KeepWait timer has a fixed value of 1 minute. 628 Upon the receipt of an Open message, the receiving PCEP peer MUST 629 determine whether the suggested PCEP session characteristics are 630 acceptable. If at least one of the characteristic(s) is not 631 acceptable by the receiving peer, it MUST send an Error message. The 632 Error message SHOULD also contain the related Open object: for each 633 unacceptable session parameter, an acceptable parameter value SHOULD 634 be proposed in the appropriate field of the Open object in place of 635 the originally proposed value. The PCEP peer MAY decide to resend an 636 Open message with different session characteristics. If a second 637 Open message is received with the same set of parameters or with 638 parameters that are still unacceptable, the receiving peer MUST send 639 an Error message and it MUST immediately close the TCP connection. 640 Details about error message can be found in Section 7.15. 642 If the PCEP session characteristics are acceptable, the receiving 643 PCEP peer MUST consequently send a Keepalive message (defined in 644 Section 6.3) that would serve as an acknowledgment. 646 The PCEP session is considered as established once both PCEP peers 647 have received a Keepalive message from their peer. 649 6.3. Keepalive message 651 A Keepalive message is a PCEP message sent by a PCC or a PCE in order 652 to keep the session in active state. The Message-Type field of the 653 PCEP common header for the Keepalive message is set to 2 (To be 654 confirmed by IANA). The Keepalive message does not contain any 655 object. 657 PCEP has its own keepalive mechanism used to ensure of the liveness 658 of the PCEP session. This requires the determination of the 659 frequency at which each PCEP peer sends keepalive messages. 660 Asymmetric values may be chosen; thus there is no constraint 661 mandating the use of identical keepalive frequencies by both PCEP 662 peers. The DeadTimer is defined as the period of time after the 663 expiration of which a PCEP peer declares the session down if no PCEP 664 message has been received (keepalive or any other PCEP message: thus, 665 any PCEP message acts as a keepalive message). Similarly, there is 666 no constraints mandating the use of identical DeadTimers by both PCEP 667 peers. The minimum KeepAlive timer value is 1 second. 669 Keepalive messages are used to acknowledge an Open message if the 670 receiving PCEP peer agrees on the session characteristics and to 671 ensure the liveness of the PCEP session. Keepalive messages are sent 672 at the frequency specified in the OPEN object carried within an Open 673 message. Because any PCEP message may serve as Keepalive an 674 implementation may either decide to send Keepalive messages at fixed 675 intervals regardless on whether other PCEP messages might have been 676 sent since the last sent Keepalive message or may decide to differ 677 the sending of the next Keepalive message based on the time at which 678 the last PCEP message (other than Keepalive) has been sent. 680 Note that sending Keepalive messages to maintain the session alive is 681 optional and PCEP peers may decide to not send Keepalive messages 682 once the PCEP session is established. 684 Keepalive message 685 ::= 687 6.4. Path Computation Request (PCReq) message 689 A Path Computation Request message (also referred to as a PCReq 690 message) is a PCEP message sent by a PCC to a PCE so as to request a 691 path computation. The Message-Type field of the PCEP common header 692 for the PCReq message is set to 3 (To be confirmed by IANA). 694 There are two mandatory objects that MUST be included within a PCReq 695 message: the RP and the END-POINTS objects (see section Section 7). 696 If one of these objects is missing, the receiving PCE MUST send an 697 error message to the requesting PCC. Other objects are optional. 699 The format of a PCReq message is as follows: 700 ::= 701 [] 702 704 where: 705 ::=[] 706 ::=[] 708 ::= 709 710 [] 711 [] 712 [] 713 [] 714 [] 715 [] 716 [] 717 where: 719 ::=[] 721 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 722 BALANCING objects are defined in Section 7. The special case of two 723 BANDWIDTH objects is discussed in details in Section 7.7. 725 6.5. Path Computation Reply (PCRep) message 727 The PCEP Path Computation Reply message (also referred to as a PCRep 728 message) is a PCEP message sent by a PCE to a requesting PCC in 729 response to a previously received PCReq message. The Message-Type 730 field of the PCEP common header is set to 4 (To be confirmed by 731 IANA). 733 The PCRep message MUST contain at least one RP object. For each 734 reply that is bundled into a single PCReq message, an RP object MUST 735 be included that contains a Request-ID-number identical to the one 736 specified in the RP object carried in the corresponding PCReq message 737 (see Section 7.4 for the definition of the RP object). 739 A PCRep message may contain a set of computed path(s) corresponding 740 to either a single path computation request with load-balancing (see 741 Section 7.16) or multiple path computation requests originated by a 742 requesting PCC. The PCRep message may also contain multiple 743 acceptable paths corresponding to the same request. 745 The bundling of multiple replies to a set of path computation 746 requests within a single PCRep message is supported by PCEP. If a 747 PCE receives non-synchronized path computation requests by means of 748 one or more PCReq messages from a requesting PCC it MAY decide to 749 bundle the computed paths within a single PCRep message so as to 750 reduce the control plane load. Note that the counter side of such an 751 approach is the introduction of additional delays for some path 752 computation requests of the set. Conversely, a PCE that receives 753 multiple requests within the same PCReq message MAY decide to provide 754 each computed path in separate PCRep messages or within the same 755 PCRep message. 757 If the path computation request can be satisfied (the PCE finds a set 758 of path(s) that satisfy the set of constraint(s)), the set of 759 computed path(s) specified by means of ERO object(s) is inserted in 760 the PCRep message. The ERO object is defined in Section 7.9. Such a 761 situation where multiple computed paths are provided in a PCRep 762 message is discussed in detail in Section 7.13. Furthermore, when a 763 PCC requests the computation a set of paths for a total amount of 764 bandwidth of X by means of a LOAD-BALANCING object carried within a 765 PCReq message, the ERO of each computed path may be followed by a 766 BANDWIDTH object as discussed in section Section 7.16. 768 If the path computation request cannot be satisfied, the PCRep 769 message MUST include a NO-PATH object. The NO-PATH object (described 770 in Section 7.5) may also comprise other information (e.g reasons for 771 the path computation failure). 773 The format of a PCRep message is as follows: 774 ::= 775 777 where: 778 ::=[] 780 ::= 781 [] 782 [] 783 [] 785 ::=[] 787 ::= 789 where: 791 ::=[] 792 [] 793 [] 794 [] 796 ::=[] 798 6.6. Notification (PCNtf) message 800 The PCEP Notification message (also referred to as the PCNtf message) 801 can either be sent by a PCE to a PCC or by a PCC to a PCE so as to 802 notify of a specific event. The Message-Type field of the PCEP 803 common header is set to 5 (To be confirmed by IANA). 805 The PCNtf message MUST carry at least one NOTIFICATION object and may 806 contain several NOTIFICATION objects should the PCE or the PCC intend 807 to notify of multiple events. The NOTIFICATION object is defined in 808 Section 7.14. The PCNtf message MAY also contain an RP object (see 809 Section 7.4 when the notification refers to a particular path 810 computation request. 812 The PCNtf message may be sent by a PCC or a PCE in response to a 813 request or in an unsolicited manner. 815 The format of a PCNtf message is as follows: 816 ::= 817 819 ::= [] 821 ::= [] 822 824 :== 826 := 828 6.7. Error (PCErr) Message 830 The PCEP Error message (also referred to as a PCErr message) is sent 831 when a protocol error condition is met. The Message-Type field of 832 the PCEP common header is set to 6 (To be confirmed by IANA). 834 The PCErr message is either sent by a PCC or a PCE in response to a 835 request or in an unsolicited manner. In the former case, the PCErr 836 message MUST include the set of RP objects related to the pending 837 path computation request(s) that triggered the protocol error 838 condition. In the later case (unsolicited), no RP object is inserted 839 in the PCErr message. No RP object is inserted in a PCErr when the 840 error condition occurred during the initialization phase. A PCErr 841 message MUST contain a PCEP-ERROR object specifying the PCEP error 842 condition. The PCEP-ERROR object is defined in section Section 7.15. 844 The format of a PCErr message is as follows: 845 ::= 846 847 [] 849 :==[] 850 ::=[] 851 853 :==[] 855 :==[] 856 The procedure upon the reception of a PCErr message is defined in 857 Section 7.15. 859 6.8. Close message 861 The Close message is a PCEP message that is either sent by a PCC to a 862 PCE or by a PCE to a PCC in order to close an established PCEP 863 session. The Message-Type field of the PCEP common header for the 864 Close message is set to 7 (To be confirmed by IANA). 866 Close message 867 ::= 868 869 The Close message MUST contain exactly one CLOSE object (see 870 Section 6.8). 872 Upon the receipt of a Close message, the receiving PCEP peer MUST 873 cancel all pending requests and MUST close the TCP connection. 875 7. Object Formats 877 7.1. PCE TLV Format 879 A PCEP object may include a set of one or more optional TLV(s). 881 All PCEP TLVs have the following format: 883 Type: 2 bytes 884 Lenght: 2 bytes 885 Value 886 A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes 887 specifying the TLV length, and a value field. 889 The Length field defines the length of the value portion in bytes. 890 The TLV is padded to 4-bytes alignment; padding is not included in 891 the Length field (so a three bytes value would have a length of 892 three, but the total size of the TLV would be eight bytes). 894 Unrecognized TLVs MUST be ignored. 896 IANA is requested to managed the PCEP Object TLV. 898 7.2. Common object header 899 A PCEP object carried within a PCEP message consists of one or more 900 32-bit words with a common header which has the following format: 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Object-Class | OT |Res|P|I| Object Length (bytes) | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | | 907 // (Object body) // 908 | | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 Figure 8: PCEP common object header 913 Object-Class (8 bits): identifies the PCEP object class. 915 OT (Object-Type - 4 bits): identifies the PCEP object type. 917 The Object-Class and Object-Type fields are managed by IANA. 919 The Object-Class and Object-Type fields uniquely identify each PCEP 920 object. 922 Res flags (2 bits). Reserved field. This field MUST be set to zero 923 on transmission and MUST be ignored on receipt. 925 o P flag (Processing-Rule - 1-bit): the P flag allows a PCC to 926 specify in a PCReq message sent to a PCE whether the object must 927 be taken into account by the PCE during path computation or is 928 just optional. When the P flag is set, the object MUST be taken 929 into account by the PCE. Conversely, when the P flag is cleared, 930 the object is optional and the PCE is free to ignore it if not 931 supported. 933 o I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 934 message to indicate to a PCC whether or not an optional object was 935 processed. The PCE MAY include the ignored optional object in its 936 reply and set the I flag to indicate that the optional object was 937 ignored during path computation. When the I flag is cleared, the 938 PCE indicates that the optional object was processed during the 939 path computation. The setting of the I flag for optional objects 940 is purely indicative and optional. The I flag has no meaning in a 941 PCRep message when the P flag had been set in the corresponding 942 PCRep message. 944 If the PCE does not understand an object with the P flag set or 945 understands the object but decides to ignore the object, the entire 946 PCEP message MUST be rejected and the PCE MUST send a PCErr message 947 with Error-Type="Unknown Object" or "Not supported Object" along with 948 the corresponding RP object. Note that if a PCReq includes multiple 949 requests, only requests for which an object with the P flag set is 950 unknown/unrecognized MUST be rejected. 952 Object Length (16 bits). Specifies the total object length including 953 the header, in bytes. The Object Length field MUST always be a 954 multiple of 4, and at least 4. The maximum object content length is 955 65528 bytes. 957 7.3. OPEN object 959 The OPEN object MUST be present in each Open message and MAY be 960 present in a PCErr message. There MUST be only one OPEN object per 961 Open or PCErr message. 963 The OPEN object contains a set of fields used to specify the PCEP 964 version, Keepalive frequency, DeadTimer, PCEP session ID along with 965 various flags. The OPEN object may also contain a set of TLVs used 966 to convey various session characteristics such as the detailed PCE 967 capabilities, policy rules and so on. No TLVs are currently defined. 969 OPEN Object-Class is to be assigned by IANA (recommended value=1) 971 OPEN Object-Type is to be assigned by IANA (recommended value=1) 973 The format of the OPEN object body is as follows: 974 0 1 2 3 975 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 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Ver | Flags | Keepalive | Deadtimer | SID | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | | 980 // Optional TLV(s) // 981 | | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Figure 9: OPEN Object format 985 Ver (3 bits): PCEP version. Current version is 1. 987 Flags (5 bits): No Flags are currently defined. Unassigned bits are 988 considered as reserved and MUST be set to zero on transmission. 990 Keepalive (8 bits): maximum period of time (in seconds) between the 991 sending of PCEP messages. The minimum value for the Keepalive is 1 992 second. When set to 0, once the session is established, no further 993 Keepalive messages need to be sent to the remote peer. A RECOMMENDED 994 value for the keepalive frequency is 30 seconds. 996 DeadTimer (8 bits): specifies the amount of time after the expiration 997 of which the PCEP peer can declare the session with the sender of the 998 Open message down if no PCEP message has been received. The 999 DeadTimer MUST be set to 0 if the Keepalive is set to 0. A 1000 RECOMMENDED value for the DeadTimer is 4 times the value of the 1001 Keepalive. 1003 Example 1005 A sends an Open message to B with Keepalive=10 seconds and 1006 Deadtimer=30 seconds. This means that A sends Keepalive messages (or 1007 ay other PCEP message) to B every 30 seconds and B can declare the 1008 PCEP session with A down if no PCEP has been received from A. 1010 SID (PCEP session-ID - 8 bits): unsigned PCEP session number that 1011 identifies the current session. The SID MUST be incremented each 1012 time a new PCEP session is established and is mainly used for logging 1013 and troubleshooting purposes. 1015 Optional TLVs may be included within the OPEN object body to specify 1016 PCC or PCE characteristics. The specification of such TLVs is 1017 outside the scope of this document. 1019 When present in an Open message, the OPEN object specifies the 1020 proposed PCEP session characteristics. Upon receiving unacceptable 1021 PCEP session characteristics during the PCEP session initialization 1022 phase, the receiving PCEP peer (PCE) MAY include an OPEN object 1023 within the PCErr message so as to propose alternative acceptable 1024 session characteristic values. 1026 7.4. RP Object 1028 The RP (Request Parameters) object MUST be carried within each PCReq 1029 and PCRep messages and MAY be carried within PCNtf and PCErr 1030 messages. The RP object is used to specify various characteristics 1031 of the path computation request. 1033 The P flag of the RP object MUST be set in PCReq and PCReq messages 1034 and MUST be cleared in PCNtf and PCErr messages. If the RP objet is 1035 received with the P flag set incorrectely according to the rules 1036 states above, the receiving peer MUST send a PCErr message with 1037 Error-type=10 and Error-value=1. The corresponding path computation 1038 request MUST be cancelled by the PCE without further notification. 1040 7.4.1. Object definition 1042 RP Object-Class is to be assigned by IANA (recommended value=2) 1043 RP Object-Type is to be assigned by IANA (recommended value=1) 1045 The format of the RP object body is as follows: 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Reserved | Flags |O|B|R| Pri | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Request-ID-number | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | | 1054 // Optional TLV(s) // 1055 | | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 Figure 10: RP object body format 1060 The RP object body has a variable length and may contain additional 1061 TLVs. No TLVs are currently defined. 1063 Reserved (8 bits): Reserved: This field MUST be set to zero on 1064 transmission and MUST be ignored on receipt. 1066 Flags (24 bits) 1068 The following flags are currently defined: 1070 o Pri (Priority - 3 bits): the Priority field may be used by the 1071 requesting PCC to specify to the PCE the request's priority from 1 1072 to 7. The decision of which priority should be used for a 1073 specific request is of a local matter and MUST be set to 0 when 1074 unused. Furthermore, the use of the path computation request 1075 priority by the PCE's scheduler is implementation specific and out 1076 of the scope of this document. Note that it is not required for a 1077 PCE to support the priority field: in this case, it is RECOMMENDED 1078 to set the priority field to 0 by the PCC in the RP object. If 1079 the PCE does not take into account the request priority, it is 1080 RECOMMENDED to set the priority field to 0 in the RP object 1081 carried within the corresponding PCRep message, regardless of the 1082 priority value contained in the RP object carried within the 1083 corresponding PCReq message. A higher numerical value of the 1084 priority field reflects a higher priority. Note that it is the 1085 responsibility of the network administrator to make use of the 1086 priority values in a consistent manner across the various PCC(s). 1087 The ability of a PCE to support requests prioritization may be 1088 dynamically discovered by the PCC(s) by means of PCE capability 1089 discovery. If not advertised by the PCE, a PCC may decide to set 1090 the request priority and will learn the ability of the PCE to 1091 support request prioritization by observing the Priority field of 1092 the RP object received in the PCRep message. If the value of the 1093 Pri field is set to 0, this means that the PCE does not support 1094 the handling of request priorities: in other words, the path 1095 computation request has been honoured but without taking the 1096 request priority into account. 1098 o R (Reoptimization - 1 bit): when set, the requesting PCC specifies 1099 that the PCReq message relates to the reoptimization of an 1100 existing TE LSP in which case, in addition to the TE LSP 1101 attributes, the current path of the existing TE LSP to be 1102 reoptimized MUST be provided in the PCReq (except for 0-bandwidth 1103 TE LSP) message by means of an RRO object defined in Section 7.10. 1105 o B (Bi-directional - 1 bit): when set, the PCC specifies that the 1106 path computation request relates to a bidirectional TE LSP that 1107 has the same traffic engineering requirements including fate 1108 sharing, protection and restoration, LSRs, and resource 1109 requirements (e.g. latency and jitter) in each direction. When 1110 cleared, the TE LSP is unidirectional. 1112 o O (strict/lOose - 1 bit): when set, in a PCReq message, this 1113 indicates that a loose path is acceptable. Otherwise, when 1114 cleared, this indicates to the PCE that a path exclusively made of 1115 strict hops is required. In a PCRep message, when the O bit is 1116 set this indicates that the returned path is a loose path, 1117 otherwise (the O bit is cleared), the returned path is made of 1118 strict hops. 1120 Unassigned bits are considered as reserved and MUST be set to zero on 1121 transmission. 1123 Request-ID-number (32 bits). The Request-ID-number value combined 1124 with the source IP address of the PCC and the PCE address uniquely 1125 identify the path computation request context. The Request-ID-number 1126 MUST be incremented each time a new request is sent to the PCE. The 1127 value 0x0000000 is considered as invalid. If no path computation 1128 reply is received from the PCE, and the PCC wishes to resend its 1129 request, the same Request-ID-number MUST be used. Conversely, 1130 different Request-ID-number MUST be used for different requests sent 1131 to a PCE. The same Request-ID-number may be used for path 1132 computation requests sent to different PCEs. The path computation 1133 reply is unambiguously identified by the IP source address of the 1134 replying PCE. 1136 7.4.2. Handling of the RP object 1138 If a PCReq message is received without containing an RP object, the 1139 PCE MUST send a PCErr message to the requesting PCC with Error- 1140 type="Required Object missing" and Error-value="RP Object missing". 1142 If the O bit of the RP message carried within a PCReq message is 1143 cleared and local policy has been configured on the PCE to not 1144 provide explicit path(s) (for instance, for confidentiality reasons), 1145 a PCErr message MUST be sent by the PCE to the requesting PCC and the 1146 pending path computation request MUST be discarded. The Error-type 1147 is "Policy Violation" and Error-value is "O bit cleared". 1149 R bit: when the R bit of the RP object is set in a PCReq message, 1150 this indicates that the path computation request relates to the 1151 reoptimization of an existing TE LSP. In this case, the PCC MUST 1152 also provide the strict/loose path by including an RRO object in the 1153 PCReq message so as to avoid/limit double bandwidth counting if and 1154 only if the TE LSP is a non 0-bandwidth TE LSP. If the PCC has not 1155 requested a strict path (O bit set), a reoptimization can still be 1156 requested by the PCC but this implies for the PCE to be either 1157 stateful (keep track of the previously computed path with the 1158 associated list of strict hops) or to have the ability to retrieve 1159 the complete required path segment. Alternatively the PCC MUST be 1160 able to inform PCE of the working path with associated list of strict 1161 hops in PCReq. The absence of an RRO in the PCReq message for a non 1162 0-bandwidth TE LSP when the R bit of the RP object is set MUST 1163 trigger the sending of a PCErr message with Error-type="Required 1164 Object Missing" and Error-value="RRO Object missing for 1165 reoptimization". 1167 If the PCC receives a PCRep message that contains a RP object 1168 referring to an unknown Request-ID-Number, the PCC MUST send a PCErr 1169 message with Error-Type="Unknown request reference". 1171 7.5. NO-PATH Object 1173 The NO-PATH object is used in PCRep messages in response to an 1174 unsuccessful path computation request (the PCE could not find a path 1175 satisfying the set of constraints). When a PCE cannot find a path 1176 satisfying a set of constraints, it MUST include a NO-PATH object in 1177 the PCRep message. The NO-PATH object is used to report the 1178 impossibility to find a path that satisfies the set of constraints. 1180 There are potentially several categories of issues that can lead to a 1181 negative reply. For example, the PCE chain might be broken (should 1182 there be more than one PCE involved in the path computation) or no 1183 path obeying the set constraints could be found. The "NI (Nature of 1184 Issue)" field in the NO-PATH object is used to report the error 1185 category. 1187 Optionally, if the PCE supports such capability, the NO-PATH object 1188 MAY contain an optional NO-PATH-VECTOR TLV defined below used to 1189 provide more information on the reasons that led to a negative reply 1190 and the PCRep message MAY also contain a list of objects that specify 1191 the set of constraints that could not be satisfied. The PCE MAY just 1192 replicate the set of object(s) that was received that was the cause 1193 of the unsuccessful computation or MAY optionally report a suggested 1194 value for which a path could have been found. 1196 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1198 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1200 The format of the NO-PATH object body is as follows: 1201 0 1 2 3 1202 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 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 |Nature Of Issue|C| Flags | Reserved | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | | 1207 // Optional TLV(s) // 1208 | | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 Figure 11: NO-PATH object format 1213 NI - Nature Of Issue (8 bits): the NI field is used to report the 1214 nature of the issue that led to a negative reply. Two values are 1215 currently defined: 1217 0x00: No path satisfying the set of constraints could be found 1219 0x01: PCE chain broken 1221 Flags (16 bits). 1223 The following flag is currently defined: 1225 C flag (1 bit): when set, the PCE indicates the set of unsatisfied 1226 constraints (reasons why a path could not be found) in the PCRep 1227 message by including the relevant PCEP objects. When cleared, no 1228 reason is specified. When the C bit is set, the NI field value MUST 1229 be 0x00. 1231 Reserved (8 bits): This field MUST be set to zero on transmission and 1232 MUST be ignored on receipt. 1234 The NO-PATH object body has a variable length and may contain 1235 additional TLVs. The only TLV currently defined is the NO-PATH- 1236 VECTOR TLV defined below. 1238 Example: consider the case of a PCC that sends a path computation 1239 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1240 find a path for X MBits/s. In this case, the PCE must include in the 1241 PCRep message a NO-PATH object. Optionally the PCE may also include 1242 the original BANDWIDTH object so as to indicate that the reason for 1243 the unsuccessful computation is the bandwidth constraint (in this 1244 case, the NI field value is 0x00 and C flag is set). If the PCE 1245 supports such capability it may alternatively include the BANDWIDTH 1246 Object and report a value of Y in the bandwidth field of the 1247 BANDWIDTH object (in this case, the C flag is set) where Y refers to 1248 the bandwidth for which a TE LSP with the same other characteristics 1249 could have been computed. 1251 When the NO-PATH object is absent from a PCRep message, the path 1252 computation request has been fully satisfied and the corresponding 1253 path(s) is/are provided in the PCRep message. 1255 An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH 1256 object in order to provide more information on the reasons that led 1257 to a negative reply. 1259 The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in section 7.1 1260 and is comprised of 2 bytes for the type, 2 bytes specifying the TLV length (length of 1261 the value portion in bytes) followed by a fix length value field of 32-bits flags field. 1263 TYPE: To be assigned by IANA (suggested value=1) 1264 LENGTH: 1 1265 VALUE: 32-bits flags field 1267 IANA is requested to manage the space of flags carried in the NO- 1268 PATH-VECTOR TLV (see Section 9). 1270 The following flags are currently defined: 1272 o 0x01: PCE currently unavailable 1274 o 0x02: Unknown destination 1276 o 0x03: Unknown source 1278 7.6. END-POINT Object 1280 The END-POINTS object is used in a PCReq message to specify the 1281 source IP address and the destination IP address of the path for 1282 which a path computation is requested. The P flag of the END-POINT 1283 object MUST be set. If the END-POINT objet is received with the P 1284 flag cleared, the receiving peer MUST send a PCErr message with 1285 Error-type=10 and Error-value=1. The corresponding path computation 1286 request MUST be cancelled by the PCE without further notification. 1288 Note that the source and destination addresses specified in the END- 1289 POINTS object may or may not correspond to the source and destination 1290 IP address of the TE LSP but rather to a path segment. Two END- 1291 POINTS objects (for IPv4 and IPv6) are defined. 1293 END-POINTS Object-Class is to be assigned by IANA (recommended 1294 value=4) 1296 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 1297 for IPv4 and 2 for IPv6) 1298 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1299 as follows: 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Source IPv4 address | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Destination IPv4 address | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 Figure 12: END-POINTS object body format for IPv4 1311 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 1313 0 1 2 3 1314 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 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | | 1317 | Source IPv6 address (16 bytes) | 1318 | | 1319 | | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | | 1322 | Destination IPv6 address (16 bytes) | 1323 | | 1324 | | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 Figure 13: END-POINTS object body format for IPv6 1329 The END-POINTS object body has a fixed length of 8 bytes for IPv4 and 1330 32 bytes for IPv6. 1332 7.7. BANDWIDTH Object 1334 The BANDWIDTH object is used to specify the requested bandwidth for a 1335 TE LSP. 1337 If the requested bandwidth is equal to 0, the BANDWIDTH object is 1338 optional. Conversely, if the requested bandwidth is non equal to 0, 1339 the PCReq message MUST contain a BANDWIDTH object. 1341 In the case of the reoptimization of a TE LSP, the bandwidth of the 1342 existing TE LSP MUST also be included in addition to the requested 1343 bandwidth if and only if the two values differ. Consequently, two 1344 Object-Type are defined that refer to the requested bandwidth and the 1345 bandwidth of the TE LSP for which a reoptimization is being 1346 performed. 1348 The BANDWIDTH object may be carried within PCReq and PCRep messages. 1350 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1351 value=5) 1353 Two Object-Type are defined for the BANDWIDTH object: 1355 o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by 1356 IANA (recommended value=1) 1358 o Bandwidth of an existing TE LSP for which a reoptimization is 1359 requested. BANDWIDTH Object-Type is to be assigned by IANA 1360 (recommended value=2) 1362 The format of the BANDWIDTH object body is as follows: 1363 0 1 2 3 1364 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 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | Bandwidth | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 Figure 14: BANDWIDTH object body format 1370 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1371 IEEE floating point format, expressed in bytes per second. 1373 The BANDWIDTH object body has a fixed length of 4 bytes. 1375 7.8. METRIC Object 1377 The METRIC object is optional and can be used for several purposes. 1379 In a PCReq message, a PCC MAY insert a METRIC object: 1381 o To indicate the metric that MUST be optimized by the path 1382 computation algorithm (IGP metric, TE metric, Hop counts). 1383 Currently, three metrics are defined: the IGP cost, the TE metric 1384 (see [RFC3785]) and the number of hops traversed by a TE LSP. 1386 o To indicate a bound on the path cost that MUST NOT be exceeded for 1387 the path to be considered as acceptable by the PCC. 1389 In a PCRep message, the METRIC object MAY be inserted so as to 1390 provide the cost for the computed path. It MAY also be inserted 1391 within a PCRep with the NO-PATH object to indicate that the metric 1392 constraint could not be satisfied. 1394 The path computation algorithmic aspects used by the PCE to optimize 1395 a path with respect to a specific metric are outside the scope of 1396 this document. 1398 It must be understood that such path metric is only meaningful if 1399 used consistently: for instance, if the delay of a path computation 1400 segment is exchanged between two PCEs residing in different domains, 1401 consistent ways of defining the delay must be used. 1403 The absence of the METRIC object MUST be interpreted by the PCE as a 1404 path computation request for which the PCE may choose the metric to 1405 be used. 1407 METRIC Object-Class is to be assigned by IANA (recommended value=6) 1409 METRIC Object-Type is to be assigned by IANA (recommended value=1) 1411 The format of the METRIC object body is as follows: 1412 0 1 2 3 1413 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 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | Reserved | Flags |C|B| T | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | metric-value | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 Figure 15: METRIC object body format 1422 The METRIC object body has a fixed length of 8 bytes. 1424 Reserved (16 bits): This field MUST be set to zero on transmission 1425 and MUST be ignored on receipt. 1427 T (Type - 8 bits): Specifies the metric type. 1429 Three values are currently defined: 1431 o T=1: IGP metric 1433 o T=2: TE metric 1435 o T=3: Hop Counts 1437 Flags (8 bits): Two flags are currently defined: 1439 o B (Bound - 1 bit): When set in a PCReq message, the metric-value 1440 indicates a bound (a maximum) for the path cost that must not be 1441 exceeded for the PCC to consider the computed path as acceptable. 1443 When the B flag is cleared, the metric-value field is not used to 1444 reflect a bound constraint. 1446 o C (Cost - 1 bit): When set in a PCReq message, this indicates that 1447 the PCE MUST provide the computed path cost (should a path 1448 satisfying the constraints be found) in the PCRep message for the 1449 corresponding metric. 1451 Unassigned flags MUST be set to zero on transmission and MUST be 1452 ignored on receipt. 1454 Metric-value (32 bits): metric value encoded in 32 bits in IEEE 1455 floating point format. 1457 Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 1458 message. There MUST be at most one instance of the METRIC object for 1459 each metric type with the same B flag value. If two or more 1460 instances of a METRIC object with the same B flag value are present 1461 for a metric type, only the first instance MUST be considered and 1462 other instances MUST be ignored. 1464 In a PCReq message the presence of multiple METRIC objects can be 1465 used to specify a multi-parameters (e.g. a metric may be a constraint 1466 or a parameter to minimize/maximize) objective function or multiple 1467 bounds for different constraints where at most one METRIC object must 1468 be used to indicate the metric to optimize (B-flag is cleared): the 1469 other METRIC object MUST be used to reflect bound constraints (B-Flag 1470 is set). If a PCReq message is received that contains two METRIC 1471 objects with the B flag set, the receiving peer MUST send a PCErr 1472 message with Error-type=10 and Error-value=2. 1474 A METRIC object used to indicate the metric to optimize during the 1475 path computation MUST have the B-Flag cleared and the T-Flag set to 1476 the appropriate value. When the path computation relates to the 1477 reoptimization of an exiting TE LSP (in which case R-Flag of the RP 1478 object is set) an implementation MAY decide to set the metric-value 1479 field to the cost of the TE LSP to be reoptimized with regards to a 1480 specific metric type. 1482 A METRIC object used to reflect a bound MUST have the B-Flag set, the 1483 T-Flag and metric-value field set to the appropriate values. 1485 In a PCRep message, unless not allowed by PCE policy, at least one 1486 METRIC object MUST be present that reports the computed path cost in 1487 particular if the C bit of the METRIC object was set in the 1488 corresponding path computation request (the B-flag MUST be cleared); 1489 optionally the PCRep message MAY contain additional METRIC objects 1490 that correspond to bound constraints, in which case the metric-value 1491 MUST be equal to the corresponding path metric cost (the B-flag MUST 1492 be set). If no path satisfying the constraints could be found by the 1493 PCE, the METRIC objects MAY also be present in the PCRep message with 1494 the NO-PATH object to indicate the constraint metric that could be 1495 satisfied. 1497 Example: if a PCC sends a path computation request to a PCE where the 1498 metric to optimize is the IGP metric and the TE metric must not 1499 exceed the value of M, two METRIC object are inserted in the PCReq 1500 message: 1502 o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000 1504 o Second METRIC Object with B=1, T=2, metric-value=M 1506 If a path satisfying the set of constraints can be found by the PCE 1507 and no policy preventing to provide the path cost is in place, the 1508 PCE inserts one METRIC object with B=0, T=1, metric-value= computed 1509 IGP path cost. Additionally, the PCE may insert a second METRIC 1510 object with B=1, T=2, metric-value= computed TE path cost. 1512 7.9. Explicit Route Object 1514 The ERO is used to encode a TE LSP. The ERO is carried within a 1515 PCRep message to provide the computed TE LSP should have the path 1516 computation been successful. 1518 The contents of this object are identical in encoding to the contents 1519 of the Explicit Route Object defined in [RFC3209], [RFC3473] and 1520 [RFC3477]. That is, the object is constructed from a series of sub- 1521 objects. Any RSVP ERO sub-object already defined or that could be 1522 defined in the future for use in the ERO is acceptable in this 1523 object. 1525 PCEP ERO sub-object types correspond to RSVP ERO sub-object types. 1527 Since the explicit path is available for immediate signaling by the 1528 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1529 and fields in this object are identical to those defined for the ERO. 1531 ERO Object-Class is to be assigned by IANA (recommended value=7) 1533 ERO Object-Type is to be assigned by IANA (recommended value=1) 1535 7.10. Route Record Object 1537 The RRO is used to record the route followed by a TE LSP. The PCEP 1538 RRO is exclusively carried within a PCReq message so as to specify 1539 the route followed by a TE LSP for which a reoptimization is desired. 1541 The contents of this object are identical in encoding to the contents 1542 of the Route Record Object defined in [RFC3209], [RFC3473] and 1543 [RFC3477]. That is, the object is constructed from a series of sub- 1544 objects. Any RSVP RRO sub-object already defined or that could be 1545 defined in the future for use in the RRO is acceptable in this 1546 object. 1548 The meanings of all of the sub-objects and fields in this object are 1549 identical to those defined for the RRO. 1551 PCEP RRO sub-object types correspond to RSVP RRO sub-object types. 1553 RRO Object-Class is to be assigned by IANA (recommended value=8) 1555 RRO Object-Type is to be assigned by IANA (recommended value=1) 1557 7.11. LSPA Object 1559 The LSPA object is optional and specifies various TE LSP attributes 1560 to be taken into account by the PCE during path computation. The 1561 LSPA (LSP Attributes) object can either be carried within a PCReq 1562 message or a PCRep message in case of unsuccessful path computation 1563 (in this case, the PCRep message also contains a NO-PATH object and 1564 the LSPA object is used to indicate the set of constraint(s) that 1565 could not be satisfied). Most of the fields of the LSPA object are 1566 identical to the fields of the SESSION-ATTRIBUTE object defined in 1567 [RFC3209] and [RFC4090]. When absent from the PCReq message, this 1568 means that the Setup and Holding priorities are equal to 0, and there 1569 are no affinity constraints. 1571 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1573 LSPA Object-Types is to be assigned by IANA (recommended value=1) 1574 The format of the LSPA object body is: 1576 0 1 2 3 1577 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | Exclude-any | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | Include-any | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 | Include-all | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Setup Prio | Holding Prio | Flags |L| Reserved | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | | 1588 // Optional TLV(s) // 1589 | | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 Figure 16: LSPA object body format 1593 Setup Prio (Setup Priority - 8 bits). The priority of the session 1594 with respect to taking resources, in the range of 0 to 7. The value 1595 0 is the highest priority. The Setup Priority is used in deciding 1596 whether this session can preempt another session. 1598 Holding Prio (Holding Priority - 8 bits). The priority of the 1599 session with respect to holding resources, in the range of 0 to 7. 1600 The value 0 is the highest priority. Holding Priority is used in 1601 deciding whether this session can be preempted by another session. 1603 Flags (8 bits) 1605 The flag L corresponds to the "Local protection desired" bit 1606 ([RFC3209]) of the SESSION-ATTRIBUTE Object. 1608 L Flag (Local protection desired). When set, this means that the 1609 computed path must include links protected with Fast Reroute as 1610 defined in [RFC4090]. 1612 Unassigned flags MUST be set to zero on transmission and MUST be 1613 ignored on receipt. 1615 Reserved (8 bits): This field MUST be set to zero on transmission and 1616 MUST be ignored on receipt. 1618 Note that Optional TLVs may be defined in the future to carry 1619 additional TE LSP attributes such as those defined in [RFC4420]. 1621 7.12. Include Route Object Object 1623 The IRO (Include Route Object) is optional and can be used to specify 1624 that the computed path MUST traverse a set of specified network 1625 elements. The IRO MAY be carried within PCReq and PCRep messages. 1626 When carried within a PCRep message with the NO-PATH object, the IRO 1627 indicates the set of elements that fail the PCE to find a path. 1629 IRO Object-Class is to be assigned by IANA (recommended value=10) 1631 IRO Object-Type is to be assigned by IANA (recommended value=1) 1633 0 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | | 1637 // (Subobjects) // 1638 | | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 Figure 17: IRO body format 1642 Subobjects The IRO is made of sub-object(s) identical to the ones 1643 defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs. 1645 The following subobject types are supported. 1647 Type Subobject 1648 1 IPv4 prefix 1649 2 IPv6 prefix 1650 4 Unnumbered Interface ID 1651 32 Autonomous system number 1652 The L bit of such sub-object has no meaning within an IRO. 1654 7.13. SVEC Object 1656 7.13.1. Notion of Dependent and Synchronized path computation requests 1658 Independent versus dependent path computation requests: path 1659 computation requests are said to be independent if they are not 1660 related to each other. Conversely a set of dependent path 1661 computation requests is such that their computations cannot be 1662 performed independently of each other (a typical example of dependent 1663 requests is the computation of a set of diverse paths). 1665 Synchronized versus non-synchronized path computation requests: a set 1666 of path computation requests is said to be non-synchronized if their 1667 respective treatment (path computations) can be performed by a PCE in 1668 a serialized and independent fashion. 1670 There are various circumstances where the synchronization of a set of 1671 path computations may be beneficial or required. 1673 Consider the case of a set of N TE LSPs for which a PCC needs to send 1674 path computation requests to a PCE. The first solution consists of 1675 sending N separate PCReq messages to the selected PCE. In this case, 1676 the path computation requests are non synchronized. Note that the 1677 PCC may chose to distribute the set of N requests across K PCEs for 1678 load balancing purpose. Considering that M (with M+-+-+-+-+-+-+ | | 2568 | | | KeepWait |----+ | 2569 | +--| |<---+ | 2570 |+-----+-+-+-+-+-+-+ | | 2571 || | | | 2572 || | | | 2573 || V | | 2574 || +->+-+-+-+-+-+-+----+ | 2575 || | | OpenWait |-------+ 2576 || +--| |<------+ 2577 ||+----+-+-+-+-+-+-+<---+ | 2578 ||| | | | 2579 ||| | | | 2580 ||| V | | 2581 ||| +->+-+-+-+-+-+-+ | | 2582 ||| | |TCPPending |----+ | 2583 ||| +--| | | 2584 |||+---+-+-+-+-+-+-+<---+ | 2585 |||| | | | 2586 |||| | | | 2587 |||| V | | 2588 |||+--->+-+-+-+-+ | | 2589 ||+---->| Idle |-------+ | 2590 |+----->| |----------+ 2591 +------>+-+-+-+-+ 2593 Figure 23: PCEP Finite State Machine for the PCC 2595 PCEP defines the following set of variables: 2597 Connect: timer (in seconds) started after having initialized a TCP 2598 connection using the PCEP well-known TCP port. The value of the 2599 TCPConnect timer is 60 seconds. 2601 ConnectRetry: specifies the number of times the system has tried to 2602 establish a TCP connection with a PCEP peer without success. 2604 ConnectMaxRetry: Maximum number of times the system tries to 2605 establish a TCP connection using the PCEP well-known TCP port before 2606 going back to the Idle state. The value of the ConnectMaxRetry is 5. 2608 OpenWait: timer that corresponds to the amount of time a PCEP peer 2609 will wait to receive an Open message from the PCEP peer after the 2610 expiration of which the system releases the PCEP resource and go back 2611 to the Idle state. The OpenWait timer has a fixed value of 60 2612 seconds. 2614 KeepWait: timer that corresponds to the amount of time a PCEP peer 2615 will wait to receive a KeepAlive or a PCErr message from the PCEP 2616 peer after the expiration of which the system releases the PCEP 2617 resource and go back to the Idle state. The KeepWait timer has a 2618 fixed value of 60 seconds. 2620 OpenRetry: specifies the number of times the system has received an 2621 Open message with unacceptable PCEP session characteristics. 2623 The following two states variable are defined: 2625 RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system 2626 has received an acceptable Open message. 2628 LocalOK: the LocalOK variable is a Boolean set to 1 if the system has 2629 received a Keepalive message acknowledging that the Open message sent 2630 to the peer was valid. 2632 Idle State: 2634 The idle state is the initial PCEP state where PCEP (also referred to 2635 as "the system") waits for an initialization event that can either be 2636 manually triggered by the user (configuration) or automatically 2637 triggered by various events. In Idle state, PCEP resources are 2638 allocated (memory, potential process, ...) but no PCEP messages are 2639 accepted from any PCEP peer. The system listens the well-known PCEP 2640 TCP port. 2642 The following set of variable are initialized: 2644 TCPRetry=0, 2646 LocalOK=0, 2648 RemoteOK=0, 2650 OpenRetry=0. 2652 Upon detection of a local initialization event (e.g. user 2653 configuration to establish a PCEP session with a particular PCEP 2654 peer, local event triggering the establishment of a PCEP session with 2655 a PCEP peer such as the automatic detection of a PCEP peer, ...), the 2656 system: 2658 o Initiates of a TCP connection with the PCEP peer, 2660 o Starts the Connect timer, 2662 o Moves to the TCPPending state. 2664 Upon receiving a TCP connection on the well-known PCEP TCP port, if 2665 the TCP connection establishment succeeds, the system: 2667 o Sends an Open message, 2669 o Starts the OpenWait timer, 2671 o Moves to the OpenWait state. 2673 If the connection establishment fails, the system remains in the Idle 2674 state. Any other event received in the Idle state is ignored. 2676 It is expected that an implementation will use an exponentially 2677 increase timer between automatically generated Initialization events 2678 and between retrials of TCP connection establishments. 2680 TCPPending State 2682 If the TCP connection establishment succeeds, the system: 2684 o Sends an Open message, 2686 o Starts the OpenWait timer, 2688 o Moves to the OpenWait state. 2690 If the TCP connection establishment fails (an error is detected 2691 during the TCP connection establishment) or the Connect timer 2692 expires: 2694 If ConnectRetry =ConnectMaxRetry the system moves to the Idle State 2696 If ConnectRetry < ConnectMaxRetry the system: 2698 o Initiates of a TCP connection with the PCEP peer, 2700 o Increments the ConnectRetry variable, 2702 o Restarts the Connect timer, 2703 o Stays in the TPCPending state. 2705 In response to any other event the system releases the PCEP resources 2706 for that peer and moves back to the Idle state. 2708 OpenWait State: 2710 In the OpenWait state, the system waits for an Open message from its 2711 PCEP peer. 2713 If the system receives an Open message from the PCEP peer before the 2714 expiration of the OpenWait timer, the system first examines all of 2715 its sessions that are in the OpenWait or KeepWait state. If another 2716 session with the same PCEP peer already exists (same IP address), 2717 then the system performs the following collision resolution 2718 procedure: 2720 o If the system has initiated the current session and has a lower IP 2721 address than the PCEP Peer, the system closes the TCP connection, 2722 releases the PCEP resources for the pending session and moves back 2723 to the Idle state. 2725 o If the session was initiated by the PCEP peer and the system has a 2726 higher IP address that the PCEP Peer, the system closes the TCP 2727 connection, releases the PCEP resources for the pending session, 2728 and moves back to the Idle state. 2730 o Otherwise, the system checks the PCEP session attributes 2731 (Keepalive frequency, DeadTimer, ...). 2733 If an error is detected (e.g. malformed Open message, presence of two 2734 Open objects, ...), PCEP generates an error notification, the PCEP 2735 peer sends a PCErr message with Error-Type=1 and Error-value=1. The 2736 system releases the PCEP resources for the PCEP peer, closes the TCP 2737 connection and moves to the Idle state. 2739 If no errors are detected, PCEP increments the OpenRetry variable. 2741 If no errors are detected, OpenRetry=1 and the session 2742 characteristics are unacceptable, the PCEP peer sends a PCErr with 2743 Error-Type=1 and Error-value=5, the system releases the PCEP 2744 resources for that peer and moves back to the Idle state. 2746 If no errors are detected and the session characteristics are 2747 acceptable to the local system, the system: 2749 o Sends a Keepalive message to the PCEP peer, 2751 o Starts the Keepalive timer, 2753 o Sets the RemoteOK variable to 1. 2755 If LocalOK=1 the system clears the OpenWait timer and moves to the UP 2756 state. 2758 If LocalOK=0 the system clears the OpenWait timer, starts the 2759 KeepWait timer and moves to the KeepWait state. 2761 If no errors are detected but the session characteristics are 2762 unacceptable and non-negotiable, the PCEP peer sends a PCErr with 2763 Error-Type=1 and Error-value=3, the system releases the PCEP 2764 resources for that peer, and moves back to the Idle state. 2766 If no errors are detected, OpenRetry=0, the session characteristics 2767 are unacceptable but negotiable (such as the Keepalive period or the 2768 DeadTimer), the system: 2770 o Increments the OpenRetry variable, 2772 o Sends a PCErr message with Error-Type=1 and Error-value=4 that 2773 contains proposed acceptable session characteristics, 2775 o If LocalOK=1, the system restarts the OpenWait timer and stays in 2776 the OpenWait state 2778 o If LocalOK=0, the system clears the OpenWait timer, starts the 2779 KeepWait timer and moves to the KeepWait state 2781 If no Open message is received before the expiration of the OpenWait 2782 timer, the PCEP peer sends a PCErr message with Error-Type=1 and 2783 Error-value=2, the system releases the PCEP resources for the PCEP 2784 peer, closes the TCP connection and moves to the Idle state. 2786 In response to any other event the system releases the PCEP resources 2787 for that peer and moves back to the Idle state. 2789 KeepWait State 2791 In the Keepwait state, the system waits for the receipt of a 2792 Keepalive from its PCEP peer acknowledging its Open message or a 2793 PCErr message in response to unacceptable PCEP session 2794 characteristics proposed in the Open message. 2796 If an error is detected (e.g. malformed Keepalive message), PCEP 2797 generates an error notification, the PCEP peer sends a PCErr message 2798 with Error-Type=1 and Error-value=1. The system releases the PCEP 2799 resources for the PCEP peer, closes the TCP connection and moves to 2800 the Idle state. 2802 If a Keepalive message is received before the expiration of the 2803 KeepWait timer, then the system sets LocalOK=1 and: 2805 o If RemoteOK=1, the system clears the KeepWait timer and moves to 2806 the UP state. 2808 o If RemoteOK=0, the system clears the KeepWait timer, starts the 2809 OpenWait timer and moves to the OpenWait State. 2811 If a PCErr message is received before the expiration of the KeepWait 2812 timer: 2814 1. If the proposed values are unacceptable, the PCEP peer sends a 2815 PCErr message with Error-Type=1 and Error-value=6 and the system 2816 releases the PCEP resources for that PCEP peer, closes the TCP 2817 connection and moves to the Idle state. 2819 2. If the proposed values are acceptable, the system adjusts its 2820 PCEP session characteristics according to the proposed values 2821 received in the PCErr message restarts the KeepWait timer and 2822 sends a new Open message. If RemoteOK=1, the system restarts the 2823 KeepWait timer and stays in the KeepWait state. If RemoteOK=0, 2824 the system clears the KeepWait timer, start the OpenWait timer 2825 and moves to the OpenWait state. 2827 If neither a Keepalive nor a PCErr is received after the expiration 2828 of the KeepWait timer, the PCEP peer sends a PCErr message with 2829 Error-Type=1 and Error-value=7 and, system releases the PCEP 2830 resources for that PCEP peer, closes the TCP connection and moves to 2831 the Idle State. 2833 In response to any other event the system releases the PCEP resources 2834 for that peer and moves back to the Idle state. 2836 UP State 2838 In the UP state, the PCEP peer starts exchanging PCEP messages 2839 according to the session characteristics. 2841 If the Keepalive timer expires, the system restarts the Keepalive 2842 timer and sends a Keepalive message. 2844 If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from 2845 the PCEP peer after the expiration of the DeadTimer, the system 2846 terminates PCEP session according to the procedure defined in 2847 Section 6.8, releases the PCEP resources for that PCEP peer, closes 2848 the TCP connection and moves to the Idle State. 2850 If a malformed message is received, the system terminates the PCEP 2851 session according to the procedure defined in Section 6.8, releases 2852 the PCEP resources for that PCEP peer, closes the TCP connection and 2853 moves to the Idle State. 2855 If the system detects that the PCEP peer tries to setup a second TCP 2856 connection, it stops the TCP connection establishment and sends a 2857 PCErr with Error-Type=9. 2859 If the TCP connection fails, the system releases the PCEP resources 2860 for that PCEP peer, closes the TCP connection and moves to the Idle 2861 State. 2863 11. Security Considerations 2865 PCEP could be the target of the following attacks: 2867 o Spoofing (PCC or PCE impersonation) 2869 o Snooping (message interception) 2871 o Falsification 2873 o Denial of Service 2875 A PCEP attack may have significant impact, particularly in an 2876 inter-AS context as PCEP facilitates inter-AS path establishment. 2877 Several mechanisms are proposed below, so as to ensure 2878 authentication, integrity and privacy of PCEP Communications, and 2879 also to protect against DoS attacks. 2881 11.1. PCEP Authentication and Integrity 2883 It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to 2884 provide for the authenticity and integrity of PCEP messages. This 2885 will allow protecting against PCE or PCC impersonation and also 2886 against message content falsification. 2888 This requires the maintenance, exchange and configuration of MD-5 2889 keys on PCCs and PCEs. Note that such maintenance may be especially 2890 onerous to the operators as pointed out in 2891 [I-D.ietf-rpsec-bgpsecrec]. Hence it is important to limit the 2892 number of keys while ensuring the required level of security. 2894 MD-5 signature faces some limitations, as per explained in [RFC2385]. 2895 Note that when one digest technique stronger than MD5 is specified 2896 and implemented, PCEP could be easily upgraded to use it. 2898 11.2. PCEP Privacy 2900 Ensuring PCEP communication privacy is of key importance, especially 2901 in an inter-AS context, where PCEP communication end-points do not 2902 reside in the same AS, as an attacker that intercept a PCE message 2903 could obtain sensitive information related to computed paths and 2904 resources. Privacy can be ensured thanks to encryption. To ensure 2905 privacy of PCEP communication, IPSec [RFC4303] tunnels MAY be used 2906 between PCC and PCEs or between PCEs. Note that this could also be 2907 used to ensure Authentication and Integrity, in which case, TCP MD-5 2908 option would not be required. 2910 11.3. Protection against Denial of Service attacks 2912 PCEP can be the target of TCP DoS attacks, such as for instance SYN 2913 attacks, as all protocols running on top of TCP. PCEP can use the 2914 same mechanisms as defined in [RFC3036] to mitigate the threat of 2915 such attacks: 2917 o A PCE should avoid promiscuous TCP listens for PCEP TCP connection 2918 establishment. It should use only listens that are specific to 2919 authorized PCCs. 2921 o The use of the MD5 option helps somewhat since it prevents a SYN 2922 from being accepted unless the MD5 segment checksum is valid. 2923 However, the receiver must compute the checksum before it can 2924 decide to discard an otherwise acceptable SYN segment. 2926 o The use of access-list on the PCE so as to restrict access to 2927 authorized PCCs. 2929 11.4. Request input shaping/policing 2931 A PCEP implementation may be subject to Denial Of Service attacks 2932 consisting of sending a very large number of PCEP messages (e.g. 2933 PCReq messages). Thus, especially in multi-Service Providers 2934 environments, a PCE implementation should implement request input 2935 shaping/policing so as to throttle the amount of received PCEP 2936 messages without compromising the implementation behavior. 2938 12. Authors' addresses 2940 This document was the collective work of several authors. The 2941 content of this document was contributed by the editors and the co- 2942 authors listed below: 2944 Arthi Ayyangar 2945 Nuova Systems 2946 2600 San Tomas Expressway 2947 Santa Clara, CA 95051 2948 USA 2950 Email: arthi@nuovasystems.com 2952 Eiji Oki 2953 NTT 2954 Midori 3-9-11 2955 Musashino, Tokyo, 180-8585 2956 JAPAN 2958 Email: oki.eiji@lab.ntt.co.jp 2960 Alia Atlas 2961 Google 2962 1600 Amphitheatre Parkway 2963 Montain View, CA 94043 2964 USA 2966 Email: akatlas@alum.mit.edu 2968 Andrew Dolganow 2969 Alcatel 2970 600 March Road 2971 Ottawa, ON K2K 2E6 2972 CANADA 2974 Email: andrew.dolganow@alcatel.com 2976 Yuichi Ikejiri 2977 NTT Communications Corporation 2978 1-1-6 Uchisaiwai-cho, Chiyoda-ku 2979 Tokyo, 100-819 2980 JAPAN 2982 Email: y.ikejiri@ntt.com 2983 Kenji Kumaki 2984 KDDI Corporation 2985 Garden Air Tower Iidabashi, Chiyoda-ku, 2986 Tokyo, 102-8460 2987 JAPAN 2989 Email: ke-kumaki@kddi.com 2991 13. Acknowledgements 2993 The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash, 2994 Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard 2995 Douville, Jon Parker, Martin German and Dennis Aristow for their very 2996 valuable input. Special thank to Adrian Farrel for his very valuable 2997 suggestions. The authors would also like to thank Fabien Verhaeghe 2998 for the very fruitfull discussions and useful suggestions. 3000 14. References 3002 14.1. Normative References 3004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3005 Requirement Levels", BCP 14, RFC 2119, March 1997. 3007 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 3008 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 3009 Tunnels", RFC 3209, December 2001. 3011 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 3012 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 3013 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 3015 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 3016 in Resource ReSerVation Protocol - Traffic Engineering 3017 (RSVP-TE)", RFC 3477, January 2003. 3019 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 3020 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 3021 May 2005. 3023 14.2. Informative References 3025 [I-D.ietf-pce-disco-proto-isis] 3026 Roux, J., "IS-IS Protocol Extensions for Path Computation 3027 Element (PCE) Discovery", 3028 draft-ietf-pce-disco-proto-isis-08 (work in progress), 3029 September 2007. 3031 [I-D.ietf-pce-disco-proto-ospf] 3032 Roux, J., "OSPF Protocol Extensions for Path Computation 3033 Element (PCE) Discovery", 3034 draft-ietf-pce-disco-proto-ospf-08 (work in progress), 3035 September 2007. 3037 [I-D.ietf-pce-inter-layer-req] 3038 Oki, E., "PCC-PCE Communication and PCE Discovery 3039 Requirements for Inter-Layer Traffic Engineering", 3040 draft-ietf-pce-inter-layer-req-06 (work in progress), 3041 November 2007. 3043 [I-D.ietf-pce-interas-pcecp-reqs] 3044 Bitar, N., "Inter-AS Requirements for the Path Computation 3045 Element Communication Protocol (PCECP)", 3046 draft-ietf-pce-interas-pcecp-reqs-03 (work in progress), 3047 July 2007. 3049 [I-D.ietf-pce-manageability-requirements] 3050 Farrel, A., "Inclusion of Manageability Sections in PCE 3051 Working Group Drafts", 3052 draft-ietf-pce-manageability-requirements-02 (work in 3053 progress), August 2007. 3055 [I-D.ietf-rpsec-bgpsecrec] 3056 Christian, B. and T. Tauber, "BGP Security Requirements", 3057 draft-ietf-rpsec-bgpsecrec-08 (work in progress), 3058 July 2007. 3060 [I-D.kkoushik-pce-pcep-mib] 3061 Stephan, E. and K. Koushik, "PCE communication 3062 protocol(PCEP) Management Information Base", 3063 draft-kkoushik-pce-pcep-mib-01 (work in progress), 3064 July 2007. 3066 [I-D.vasseur-pce-monitoring] 3067 Vasseur, J., "A set of monitoring tools for Path 3068 Computation Element based Architecture", 3069 draft-vasseur-pce-monitoring-03 (work in progress), 3070 May 2007. 3072 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3073 April 1992. 3075 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 3076 Signature Option", RFC 2385, August 1998. 3078 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 3079 B. Thomas, "LDP Specification", RFC 3036, January 2001. 3081 [RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and 3082 T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric 3083 as a second MPLS Traffic Engineering (TE) Metric", BCP 87, 3084 RFC 3785, May 2004. 3086 [RFC4022] Raghunarayan, R., "Management Information Base for the 3087 Transmission Control Protocol (TCP)", RFC 4022, 3088 March 2005. 3090 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 3091 June 2005. 3093 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 3094 RFC 4303, December 2005. 3096 [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A. 3097 Ayyangar, "Encoding of Attributes for Multiprotocol Label 3098 Switching (MPLS) Label Switched Path (LSP) Establishment 3099 Using Resource ReserVation Protocol-Traffic Engineering 3100 (RSVP-TE)", RFC 4420, February 2006. 3102 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 3103 Element (PCE)-Based Architecture", RFC 4655, August 2006. 3105 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 3106 Communication Protocol Generic Requirements", RFC 4657, 3107 September 2006. 3109 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 3110 (PCE) Discovery", RFC 4674, October 2006. 3112 [RFC4927] Le Roux, J., "Path Computation Element Communication 3113 Protocol (PCECP) Specific Requirements for Inter-Area MPLS 3114 and GMPLS Traffic Engineering", RFC 4927, June 2007. 3116 Appendix A. PCEP Variables 3118 PCEP defines the following configurable variables: 3120 KeepAlive timer: minimum period of time between the sending of PCEP 3121 messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A 3122 suggested value for the Keepalive timer is 30 seconds. 3124 DeadTimer: period of timer after the expiration of which a PCEP peer 3125 declared the session down if no PCEP message has been received. 3127 SyncTimer: the SYNC timer is used in the case of synchronized path 3128 computation request using the SVEC object defined in Section 7.13.3. 3129 Consider the case where a PCReq message is received by a PCE that 3130 contains the SVEC object referring to M synchronized path computation 3131 requests. If after the expiration of the SYNC timer all the M path 3132 computation requests have not been received, a protocol error is 3133 triggered and the PCE MUST cancel the whole set of path computation 3134 requests. A RECOMMENDED value for the SYNC timer is 60 seconds. 3136 Authors' Addresses 3138 JP Vasseur (editor) 3139 Cisco Systems 3140 1414 Massachusetts Avenue 3141 Boxborough, MA 01719 3142 USA 3144 Email: jpv@cisco.com 3146 JL Le Roux (editor) 3147 France Telecom 3148 2, Avenue Pierre-Marzin 3149 Lannion, 22307 3150 FRANCE 3152 Email: jeanlouis.leroux@orange-ftgroup.com 3154 Full Copyright Statement 3156 Copyright (C) The IETF Trust (2007). 3158 This document is subject to the rights, licenses and restrictions 3159 contained in BCP 78, and except as set forth therein, the authors 3160 retain all their rights. 3162 This document and the information contained herein are provided on an 3163 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3164 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3165 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3166 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3167 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3168 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3170 Intellectual Property 3172 The IETF takes no position regarding the validity or scope of any 3173 Intellectual Property Rights or other rights that might be claimed to 3174 pertain to the implementation or use of the technology described in 3175 this document or the extent to which any license under such rights 3176 might or might not be available; nor does it represent that it has 3177 made any independent effort to identify any such rights. Information 3178 on the procedures with respect to rights in RFC documents can be 3179 found in BCP 78 and BCP 79. 3181 Copies of IPR disclosures made to the IETF Secretariat and any 3182 assurances of licenses to be made available, or the result of an 3183 attempt made to obtain a general license or permission for the use of 3184 such proprietary rights by implementers or users of this 3185 specification can be obtained from the IETF on-line IPR repository at 3186 http://www.ietf.org/ipr. 3188 The IETF invites any interested party to bring to its attention any 3189 copyrights, patents or patent applications, or other proprietary 3190 rights that may cover technology that may be required to implement 3191 this standard. Please address the information to the IETF at 3192 ietf-ipr@ietf.org. 3194 Acknowledgment 3196 Funding for the RFC Editor function is provided by the IETF 3197 Administrative Support Activity (IASA).