idnits 2.17.1 draft-ietf-pce-pcep-07.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 3019. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3030. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3037. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3043. 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 24 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 (March 2, 2007) is 6265 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) == Unused Reference: 'RFC2205' is defined on line 2824, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-inter-domain-rsvp-te' is defined on line 2856, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4657 ** Downref: Normative reference to an Informational RFC: RFC 4674 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-05 == Outdated reference: A later version (-08) exists of draft-ietf-pce-disco-proto-isis-02 == Outdated reference: A later version (-08) exists of draft-ietf-pce-disco-proto-ospf-02 == Outdated reference: A later version (-15) exists of draft-ietf-pce-inter-layer-req-03 == Outdated reference: A later version (-06) exists of draft-ietf-pce-interas-pcecp-reqs-01 == Outdated reference: A later version (-11) exists of draft-ietf-pce-manageability-requirements-01 == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-07 == Outdated reference: A later version (-02) exists of draft-kkoushik-pce-pcep-mib-00 == Outdated reference: A later version (-03) exists of draft-vasseur-pce-monitoring-02 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- 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: 5 errors (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems 3 Intended status: Standards Track JL. Le Roux, Ed. 4 Expires: September 3, 2007 France Telecom 5 March 2, 2007 7 Path Computation Element (PCE) communication Protocol (PCEP) 8 draft-ietf-pce-pcep-07.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 September 3, 2007. 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 . . . . . . . . . . . . . . . 19 80 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 20 81 6.8. Close message . . . . . . . . . . . . . . . . . . . . . . 20 82 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 21 83 7.1. Common object header . . . . . . . . . . . . . . . . . . . 21 84 7.2. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 22 85 7.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 24 86 7.3.1. Object definition . . . . . . . . . . . . . . . . . . 24 87 7.3.2. Handling of the RP object . . . . . . . . . . . . . . 26 88 7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 26 89 7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 29 90 7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 30 91 7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 31 92 7.8. Explicit Route Object . . . . . . . . . . . . . . . . . . 34 93 7.9. Record Route Object . . . . . . . . . . . . . . . . . . . 34 94 7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 35 95 7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 36 96 7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 37 97 7.12.1. Notion of Dependent and Synchronized path 98 computation requests . . . . . . . . . . . . . . . . . 37 99 7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 38 100 7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 40 101 7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 40 102 7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 43 103 7.15. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 47 104 7.16. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 48 105 8. Manageability Considerations . . . . . . . . . . . . . . . . . 49 106 8.1. Control of Function and Policy . . . . . . . . . . . . . . 49 107 8.2. Information and Data Models . . . . . . . . . . . . . . . 50 108 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 51 109 8.4. Verifying Correct Operation . . . . . . . . . . . . . . . 51 110 8.5. Requirements on Other Protocols and Functional 111 Componentssection . . . . . . . . . . . . . . . . . . . . 51 112 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 52 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 114 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 52 115 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 52 116 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 52 117 9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 54 118 9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 54 119 9.6. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 55 120 10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 56 121 11. Security Considerations . . . . . . . . . . . . . . . . . . . 61 122 11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 62 123 11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 62 124 11.3. Protection against Denial of Service attacks . . . . . . . 62 125 11.4. Request input shaping/policing . . . . . . . . . . . . . . 63 126 12. Authors' addresses . . . . . . . . . . . . . . . . . . . . . . 63 127 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 128 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 129 14.1. Normative References . . . . . . . . . . . . . . . . . . . 65 130 14.2. Informative References . . . . . . . . . . . . . . . . . . 65 131 Appendix A. Compliance with the PCECP Requirement Document . . . 67 132 Appendix B. PCEP Variables . . . . . . . . . . . . . . . . . . . 68 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 134 Intellectual Property and Copyright Statements . . . . . . . . . . 69 136 1. Terminology 138 Terminology used in this document 140 Explicit path: full explicit path from start to destination made of a 141 list of strict hops where a hop may be an abstract node such as an 142 AS. 144 IGP area: OSPF area or IS-IS level. 146 Inter-domain TE LSP: A TE LSP whose path transits across at least two 147 different domains where a domain can either be an IGP area, an 148 Autonomous System or a sub-AS (BGP confederations). 150 PCC: Path Computation Client: any client application requesting a 151 path computation to be performed by a Path Computation Element. 153 PCE: Path Computation Element: an entity (component, application or 154 network node) that is capable of computing a network path or route 155 based on a network graph and applying computational constraints. 157 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or a 158 PCE). 160 TED: Traffic Engineering Database that contains the topology and 161 resource information of the domain. The TED may be fed by IGP 162 extensions or potentially by other means. 164 TE LSP: Traffic Engineering Label Switched Path. 166 Strict/loose path: mix of strict and loose hops comprising of at 167 least one loose hop representing the destination where a hop may be 168 an abstract node such as an AS. 170 Within this document, when describing PCE-PCE communications, the 171 requesting PCE fills the role of a PCC. This provides a saving in 172 documentation without loss of function. 174 2. Introduction 176 [RFC4655] describes the motivations and architecture for a PCE-based 177 model for the computation of MPLS and GMPLS TE LSPs. The model 178 allows for the separation of PCE from PCC, and allows for the 179 cooperation between PCEs. This necessitates a communication protocol 180 between PCC and PCE, and between PCEs. [RFC4657] states the generic 181 requirements for such protocol including the requirement for using 182 the same protocol between PCC and PCE, and between PCEs. Additional 183 application-specific requirements (for scenarios such as inter-area, 184 inter-AS, etc.) are not included in [RFC4657], but there is a 185 requirement that any solution protocol must be easily extensible to 186 handle other requirements as they are introduced in application- 187 specific requirements documents. Examples of such application- 188 specific requirements are [I-D.ietf-pce-pcecp-interarea-reqs], 189 [I-D.ietf-pce-interas-pcecp-reqs] and [I-D.ietf-pce-inter-layer-req]. 191 This document specifies the Path Computation Element communication 192 Protocol (PCEP) for communications between a Path Computation Client 193 (PCC) and a Path Computation Element (PCE), or between two PCEs, in 194 compliance with [RFC4657]. Such interactions include path 195 computation requests and path computation replies as well as 196 notifications of specific states related to the use of a PCE in the 197 context of MPLS and GMPLS Traffic Engineering. 199 PCEP is designed to be flexible and extensible so as to easily allow 200 for the addition of further messages and objects, should further 201 requirements be expressed in the future. 203 3. Assumptions 205 [RFC4655] describes various types of PCE. PCEP does not make any 206 assumption and thus does not impose any constraint on the nature of 207 the PCE. 209 Moreover, it is assumed that the PCE gets the required information so 210 as to perform the computation of TE LSP that usually requires network 211 topology and resource information. Such information can be gathered 212 by routing protocols or by some other means, the gathering of which 213 is out of the scope of this document. 215 Similarly, no assumption is made on the discovery method used by a 216 PCC to discover a set of PCEs (e.g. via static configuration or 217 dynamic discovery) and on the algorithm used to select a PCE. For 218 the sake of reference [RFC4674] defines a list of requirements for 219 dynamic PCE discovery and IGP-based solutions for such PCE discovery 220 are specified in [I-D.ietf-pce-disco-proto-ospf] and 221 [I-D.ietf-pce-disco-proto-isis]. 223 4. Architectural Protocol Overview (Model) 225 The aim of this section is to describe the PCEP model in the spirit 226 of [RFC4101]. An architecture protocol overview (the big picture of 227 the protocol) is provided in this section. Protocol details can be 228 found in further sections. 230 4.1. Problem 232 The PCE-based architecture used for the computation of MPLS and GMPLS 233 TE LSP is described in [RFC4655]. When the PCC and the PCE are not 234 collocated, a communication protocol between the PCC and the PCE is 235 needed. PCEP is such a protocol designed specifically for 236 communications between a PCC and a PCE or between two PCEs in 237 compliance with [RFC4657]: a PCC may use PCEP to send a path 238 computation request for one or more TE LSP(s) to a PCE and the PCE 239 may reply with a set of computed path(s) if one or more path(s) that 240 satisfy the set of constraints can be found. 242 4.2. Architectural Protocol Overview 244 PCEP operates over TCP, which fulfils the requirements for reliable 245 messaging and flow control without further protocol work. 247 Several PCEP messages are defined: 249 - Open and Keepalive messages are used to initiate and maintain a 250 PCEP session respectively. 252 - PCReq: a PCEP message sent by a PCC to a PCE to request a path 253 computation. 255 - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path 256 computation request. A PCRep message can either contain a set of 257 computed path(s) if the request can be satisfied or a negative reply 258 otherwise. 260 - PCNtf: a PCEP notification message either sent by a PCC to a PCE or 261 a PCE to a PCC to notify of a specific event. 263 - PCErr: a PCEP message sent upon the occurrence of a protocol error 264 condition. 266 - Close message: a message used to close a PCEP session. 268 The set of available PCE(s) may be either statically configured on a 269 PCC or dynamically discovered. The mechanisms used to discover one 270 or more PCE(s) and to select a PCE are out of the scope of this 271 document. 273 A PCC may have PCEP sessions with more than one PCE and similarly a 274 PCE may have PCEP sessions with multiple PCCs. 276 4.2.1. Initialization Phase 278 The initialization phase consists of two successive steps (described 279 in a schematic form in Figure 1): 281 1) Establishment of a TCP connection (3-way handshake) between the 282 PCC and the PCE. 284 2) Establishment of a PCEP session over the TCP connection. 286 Once the TCP connection is established, the PCC and the PCE (also 287 referred to as "PCEP peers") initiate a PCEP session establishment 288 during which various session parameters are negotiated. These 289 parameters are carried within Open messages and include the Keepalive 290 timer, the Deadtimer and potentially other detailed capabilities and 291 policy rules that specify the conditions under which path computation 292 requests may be sent to the PCE. If the PCEP session establishment 293 phase fails because the PCEP peers disagree on the session parameters 294 or one of the PCEP peers does not answer after the expiration of the 295 establishment timer, the TCP connection is immediately closed. 296 Successive retries are permitted but an implementation SHOULD make 297 use of an exponential back-off session establishment retry procedure. 299 Keepalive messages are used to acknowledge Open messages and once the 300 PCEP session has been successfully established, Keepalive messages 301 are exchanged between PCEP peers to ensure the liveness of the PCEP 302 session. 304 A single PCEP session can exist between a pair a PCEP peers. 306 Details about the Open message and the Keepalive messages can be 307 found inSection 6.2 and Section 6.3 respectively. 309 +-+-+ +-+-+ 310 |PCC| |PCE| 311 +-+-+ +-+-+ 312 | | 313 |---- Open message --->| 314 | | 315 |<--- Open message ----| 316 | | 317 | | 318 | | 319 |<--- Keepalive -------| 320 | | 321 |---- Keepalive ------>| 323 Figure 1: PCEP Initialization phase (initiated by a PCC) 325 4.2.2. Path computation request sent by a PCC to a PCE 327 +-+-+ +-+-+ 328 |PCC| |PCE| 329 +-+-+ +-+-+ 330 1)Path computation | | 331 event | | 332 2)PCE Selection | | 333 3)Path computation |---- PCReq message--->| 334 request sent to | | 335 the selected PCE | | 337 Figure 2: Path computation request 339 Once a PCC has successfully established a PCEP session with one or 340 more PCEs, if an event is triggered that requires the computation of 341 a set of path(s), the PCC first selects one or more PCE(s) to send 342 the request to. Note that the PCE selection decision process may 343 have taken place prior to the PCEP session establishment. 345 Once the PCC has selected a PCE, it sends a path computation request 346 to the PCE (PCReq message) that contains a variety of objects that 347 specify the set of constraints and attributes for the path to be 348 computed. For example "Compute a TE LSP path with source IP 349 address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B 350 Mbit/s, Setup/Hold priority=P, ...". Additionally, the PCC may 351 desire to specify the urgency of such request by assigning a request 352 priority. Each request is uniquely identified by a request-id number 353 and the PCC-PCE address pair. The process is shown in a schematic 354 form in figure 2. 356 Details about the PCReq message can be found in Section 6.4 358 4.2.3. Path computation reply sent by the PCE to a PCC 359 +-+-+ +-+-+ 360 |PCC| |PCE| 361 +-+-+ +-+-+ 362 | | 363 |---- PCReq message--->| 364 | |1) Path computation 365 | |request received 366 | | 367 | |2)Path successfully 368 | |computed 369 | | 370 | |3) Computed path(s) sent 371 | |to the PCC 372 |<--- PCRep message ---| 373 | (Positive reply) | 375 Figure 3a: Path computation request with successful path computation 377 +-+-+ +-+-+ 378 |PCC| |PCE| 379 +-+-+ +-+-+ 380 | | 381 | | 382 |---- PCReq message--->| 383 | |1) Path computation 384 | |request received 385 | | 386 | |2) No Path found that 387 | |satisfies the request 388 | | 389 | |3) Negative reply sent to 390 | |the PCC (optionally with 391 | |various additional 392 | |information) 393 |<--- PCRep message ---| 394 | (Negative reply) | 396 Figure 3b: Path computation request with unsuccessful path computation 398 Upon receiving a path computation request from a PCC, the PCE 399 triggers a path computation, the result of which can either be: 401 - Positive (Figure 3-a): the PCE manages to compute a path that 402 satisfies the set of required constraints, in which case the PCE 403 returns the set of computed path(s) to the requesting PCC. Note that 404 PCEP supports the capability to send a single request which requires 405 the computation of more than one path (e.g. computation of a set of 406 link-diverse paths). 408 - Negative (Figure 3-b): no path could be found that satisfies the 409 set of constraints. In this case, a PCE may provide the set of 410 constraints that led to the path computation failure. Upon receiving 411 a negative reply, a PCC may decide to resend a modified request or 412 take any other appropriate action. 414 Details about the PCRep message can be found in Section 6.5. 416 4.2.4. Notification 418 There are several circumstances whereby a PCE may want to notify a 419 PCC of a specific event. For example, suppose that the PCE suddenly 420 experiences some congestion that would lead to unacceptable response 421 times. The PCE may want to notify one or more PCCs that some of 422 their requests (listed in the notification) will not be satisfied or 423 may experience unacceptable delays. Upon receiving such 424 notification, the PCC may decide to redirect it(s) path computation 425 request(s) to another PCE should an alternate PCE be available. 426 Similarly, a PCC may desire to notify a PCE of a particular event 427 such as the cancellation of pending request(s). 429 +-+-+ +-+-+ 430 |PCC| |PCE| 431 +-+-+ +-+-+ 432 1)Path computation | | 433 event | | 434 2)PCE Selection | | 435 3)Path computation |---- PCReq message--->| 436 request X sent to | |4) Path computation 437 the selected PCE | |triggered 438 | | 439 | | 440 5) Path computation| | 441 request X cancelled| | 442 |---- PCNtf message -->| 443 | |6) Path computation 444 | |request X cancelled 446 Figure 4: Example of PCC notification (cancellation notification) sent to a PCE 448 +-+-+ +-+-+ 449 |PCC| |PCE| 450 +-+-+ +-+-+ 451 1)Path computation | | 452 event | | 453 2)PCE Selection | | 454 3)Path computation |---- PCReq message--->| 455 request X sent to | |4) Path computation 456 the selected PCE | |triggered 457 | | 458 | | 459 | |5) PCE experiencing 460 | |congestion 461 | | 462 | |6) Path computation 463 | |request X cancelled 464 | | 465 |<--- PCNtf message----| 467 Figure 5: Example of PCE notification (cancellation notification) sent to a PCC 469 Details about the PCNtf message can be found in Section 6.6. 471 4.2.5. Error 473 PCEP Error messages are sent when a protocol error condition is met 474 (e.g. unknown object, non supported object, policy violation, ...). 476 +-+-+ +-+-+ 477 |PCC| |PCE| 478 +-+-+ +-+-+ 479 1)Path computation | | 480 event | | 481 2)PCE Selection | | 482 3)Path computation |---- PCReq message--->| 483 request X sent to | |4) Path computation 484 the selected PCE | |triggered => Policy 485 | |violation ! 486 | |5) Request discarded 487 | | 488 |<-- PCErr message ---| 489 | | 491 Figure 6: Example of Error message (policy violation) sent by a PCE 493 Details about the PCErr message can be found in Section 6.7. 495 4.2.6. Termination of the PCEP Session 497 When one of the PCEP peers desires to terminate a PCEP session it 498 first sends a PCEP Close message and then closes the TCP connection. 499 If the PCEP session is terminated by the PCE, the PCC clears all the 500 states related to pending requests previously sent to the PCE. 501 Similarly, if the PCC terminates a PCEP session the PCE clears all 502 pending path computation requests sent by the PCC in question as well 503 as the related states. A Close message can only be sent to terminate 504 a PCEP session if the PCEP session has previously been established. 506 In case of TCP connection failure, the PCEP session is immediately 507 terminated. 509 Details about the Close message can be found in Section 6.8. 511 5. Transport protocol 513 PCEP operates over TCP using a well-known TCP port (to be assigned by 514 IANA). This allows the requirements of reliable messaging and flow 515 control to be met without further protocol work. 517 An implementation may decide to keep the TCP connection alive for an 518 unlimited time (this may for instance be appropriate when path 519 computation requests are sent on a frequent basis so as to avoid to 520 open a TCP connection each time a path computation request is needed, 521 which would incur additional processing delays). Conversely, in some 522 other circumstances, it may be desirable to systematically open and 523 close the TCP connection for each PCEP request (for instance when 524 sending a path computation request is a rare event). 526 6. PCEP Messages 528 A PCEP message consists of a common header followed by a variable 529 length body made of a set of objects that can either be mandatory or 530 optional. In the context of this document, an object is said to be 531 mandatory in a PCEP message when the object MUST be included for the 532 message to be considered as valid. A PCEP message with a missing 533 mandatory object MUST trigger an Error message (see Section 7.14). 534 Conversely, if an object is optional, the object may or may not be 535 present. 537 A flag referred to as the P flag is defined in the common header of 538 each PCEP object (see Section 7.1) that can be set by a PCEP peer to 539 enforce a PCE to take into account the related information during the 540 path computation. For example, the METRIC object defined in 541 Section 7.7 allows a PCC to specify a bounded acceptable path cost. 542 The METRIC object is optional but a PCC may set a flag to ensure that 543 such constraint is taken into account. Similarly to the previous 544 case, if such constraint cannot be taken into account by the PCE, 545 this should trigger an Error message. 547 For each PCEP message type, rules are defined that specify the set of 548 objects that the message can carry. We use the Backus-Naur Form 549 (BNF) to specify such rules. Square brackets refer to optional sub- 550 sequences. An implementation MUST form the PCEP messages using the 551 object ordering specified in this document. 553 6.1. Common header 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Ver | Flags | Message-Type | Message-Lenght | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 7: PCEP message common header 562 Ver (Version - 3 bits): PCEP version number. Current version is 563 version 1. 565 Flags (5 bits): no flags are currently defined. Unassigned bits are 566 considered as reserved and MUST be set to zero on transmission. 568 Message-Type (8 bits): 570 The following message types are currently defined (to be confirmed by 571 IANA). 572 Value Meaning 573 1 Open 574 2 Keepalive 575 3 Path Computation Request 576 4 Path Computation Reply 577 5 Notification 578 6 Error 579 7 Close 581 Message-Length (16 bits): total length of the PCEP message expressed 582 in bytes including the common header. 584 6.2. Open message 586 The Open message is a PCEP message sent by a PCC to a PCE and a PCE 587 to a PCC in order to establish a PCEP session. The Message-Type 588 field of the PCEP common header for the Open message is set to 1 (To 589 be confirmed by IANA). 591 Once the TCP connection has been successfully established, the first 592 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 593 an Open message. Any message received prior to an Open message MUST 594 trigger a protocol error condition and the PCEP session MUST be 595 terminated. The Open message is used to establish a PCEP session 596 between the PCEP peers. During the establishment phase the PCEP 597 peers exchange several session characteristics. If both parties 598 agree on such characteristics the PCEP session is successfully 599 established. 601 Open message 602 ::= 603 604 The Open message MUST contain exactly one OPEN object (see 605 Section 7.2). Various session characteristics are specified within 606 the OPEN object. Once the TCP connection has been successfully 607 established the sender MUST start an initialization timer called 608 OpenWait after the expiration of which if no Open message has been 609 received it sends a PCErr message and releases the TCP connection 610 (see Section 10 for details). 612 Once an Open message has been sent to a PCEP peer, the sender MUST 613 start an initialization timer called KeepWait after the expiration of 614 which if neither a KeepAlive message has been received nor a PCErr 615 message in case of disagreement of the session characteristics, a 616 PCErr message MUST be sent and the TCP connection MUST be released 617 (see Section 10 for details). 619 The KeepWait timer has a fixed value of 1 minute. 621 Upon the receipt of an Open message, the receiving PCEP peer MUST 622 determine whether the suggested PCEP session characteristics are 623 acceptable. If at least one of the characteristic(s) is not 624 acceptable by the receiving peer, it MUST send an Error message. The 625 Error message SHOULD also contain the related Open object: for each 626 unacceptable session parameter, an acceptable parameter value SHOULD 627 be proposed in the appropriate field of the Open object in place of 628 the originally proposed value. The PCEP peer MAY decide to resend an 629 Open message with different session characteristics. If a second 630 Open message is received with the same set of parameters or with 631 parameters that are still unacceptable, the receiving peer MUST send 632 an Error message and it MUST immediately close the TCP connection. 633 Details about error message can be found in Section 7.14. 635 If the PCEP session characteristics are acceptable, the receiving 636 PCEP peer MUST consequently send a Keepalive message (defined in 637 Section 6.3) that would serve as an acknowledgment. 639 The PCEP session is considered as established once both PCEP peers 640 have received a Keepalive message from their peer. 642 6.3. Keepalive message 644 A Keepalive message is a PCEP message sent by a PCC or a PCE in order 645 to keep the session in active state. The Message-Type field of the 646 PCEP common header for the Keepalive message is set to 2 (To be 647 confirmed by IANA). The Keepalive message does not contain any 648 object. 650 PCEP has its own keepalive mechanism used to ensure of the liveness 651 of the PCEP session. This requires the determination of the 652 frequency at which each PCEP peer sends keepalive messages. 653 Asymmetric values may be chosen; thus there is no constraint 654 mandating the use of identical keepalive frequencies by both PCEP 655 peers. The DeadTimer is defined as the period of time after the 656 expiration of which a PCEP peer declares the session down if no PCEP 657 message has been received (keepalive or any other PCEP message: thus, 658 any PCEP message acts as a keepalive message). Similarly, there is 659 no constraints mandating the use of identical DeadTimers by both PCEP 660 peers. The minimum KeepAlive timer value is 1 second. 662 Keepalive messages are used to acknowledge an Open message if the 663 receiving PCEP peer agrees on the session characteristics and to 664 ensure the liveness of the PCEP session. Keepalive messages are sent 665 at the frequency specified in the OPEN object carried within an Open 666 message. Because any PCEP message may serve as Keepalive an 667 implementation may either decide to send Keepalive messages at fixed 668 intervals regardless on whether other PCEP messages might have been 669 sent since the last sent Keepalive message or may decide to differ 670 the sending of the next Keepalive message based on the time at which 671 the last PCEP message (other than Keepalive) has been sent. 673 Keepalive message 674 ::= 676 6.4. Path Computation Request (PCReq) message 678 A Path Computation Request message (also referred to as a PCReq 679 message) is a PCEP message sent by a PCC to a PCE so as to request a 680 path computation. The Message-Type field of the PCEP common header 681 for the PCReq message is set to 3 (To be confirmed by IANA). 683 There are two mandatory objects that MUST be included within a PCReq 684 message: the RP and the END-POINTS objects (see section Section 7). 685 If one of these objects is missing, the receiving PCE MUST send an 686 error message to the requesting PCC. Other objects are optional. 688 The format of a PCReq message is as follows: 689 ::= 690 [] 691 693 where: 694 ::=[] 695 ::=[] 697 ::= 698 699 [] 700 [] 701 [] 702 [] 703 [] 704 [] 705 where: 707 ::=[] 709 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 710 BALANCING objects are defined in Section 7. The special case of two 711 BANDWIDTH objects is discussed in details in Section 7.6. 713 6.5. Path Computation Reply (PCRep) message 715 The PCEP Path Computation Reply message (also referred to as a PCRep 716 message) is a PCEP message sent by a PCE to a requesting PCC in 717 response to a previously received PCReq message. The Message-Type 718 field of the PCEP common header is set to 4 (To be confirmed by 719 IANA). 721 The PCRep message MUST contain at least one RP object. For each 722 reply that is bundled into a single PCReq message, an RP object MUST 723 be included that contains a Request-ID-number identical to the one 724 specified in the RP object carried in the corresponding PCReq message 725 (see Section 7.3 for the definition of the RP object). 727 A PCRep message may contain a set of computed path(s) corresponding 728 to either a single path computation request with load-balancing (see 729 Section 7.15) or multiple path computation requests originated by a 730 requesting PCC. The PCRep message may also contain multiple 731 acceptable paths corresponding to the same request. 733 The bundling of multiple replies to a set of path computation 734 requests within a single PCRep message is supported by PCEP. If a 735 PCE receives non-synchronized path computation requests by means of 736 one or more PCReq messages from a requesting PCC it MAY decide to 737 bundle the computed paths within a single PCRep message so as to 738 reduce the control plane load. Note that the counter side of such an 739 approach is the introduction of additional delays for some path 740 computation requests of the set. Conversely, a PCE that receives 741 multiple requests within the same PCReq message, it MAY decide to 742 provide each computed path in separate PCRep messages. 744 If the path computation request can be satisfied (the PCE finds a set 745 of path(s) that satisfy the set of constraint(s)), the set of 746 computed path(s) specified by means of ERO object(s) is inserted in 747 the PCRep message. The ERO object is defined in Section 7.8. Such a 748 situation where multiple computed paths are provided in a PCRep 749 message is discussed in detail in Section 7.12. Furthermore, when a 750 PCC requests the computation a set of paths for a total amount of 751 bandwidth of X by means of a LOAD-BALANCING object carried within a 752 PCReq message, the ERO of each computed path may be followed by a 753 BANDWIDTH object as discussed in section Section 7.15. 755 If the path computation request cannot be satisfied, the PCRep 756 message MUST include a NO-PATH object. The NO-PATH object (described 757 in Section 7.4) may also comprise other information (e.g reasons for 758 the path computation failure). 760 The format of a PCRep message is as follows: 761 ::= 762 764 where: 765 ::=[] 767 ::= 768 [] 769 [] 771 ::=[] 773 ::= 774 [] 775 [] 776 [] 777 [] 779 where: 780 ::=[] 782 6.6. Notification (PCNtf) message 784 The PCEP Notification message (also referred to as the PCNtf message) 785 can either be sent by a PCE to a PCC or by a PCC to a PCE so as to 786 notify of a specific event. The Message-Type field of the PCEP 787 common header is set to 5 (To be confirmed by IANA). 789 The PCNtf message MUST carry at least one NOTIFICATION object and may 790 contain several NOTIFICATION objects should the PCE or the PCC intend 791 to notify of multiple events. The NOTIFICATION object is defined in 792 Section 7.13. The PCNtf message MAY also contain an RP object (see 793 Section 7.3 when the notification refers to a particular path 794 computation request. 796 The PCNtf message may be sent by a PCC or a PCE in response to a 797 request or in an unsolicited manner. 799 The format of a PCNtf message is as follows: 800 ::= 801 803 ::= [] 805 ::= [] 806 808 :== 810 := 812 6.7. Error (PCErr) Message 814 The PCEP Error message (also referred to as a PCErr message) is sent 815 when a protocol error condition is met. The Message-Type field of 816 the PCEP common header is set to 6 (To be confirmed by IANA). 818 The PCErr message is either sent by a PCC or a PCE in response to a 819 request or in an unsolicited manner. In the former case, the PCErr 820 message MUST include the set of RP objects related to the pending 821 path computation request(s) that triggered the protocol error 822 condition. In the later case (unsolicited), no RP object is inserted 823 in the PCErr message. No RP object is inserted in a PCErr when the 824 error condition occurred during the initialization phase. A PCErr 825 message MUST contain a PCEP-ERROR object specifying the PCEP error 826 condition. The PCEP-ERROR object is defined in section Section 7.14. 828 The format of a PCErr message is as follows: 829 ::= 830 831 [] 833 :==[] 834 ::=[] 835 837 :==[] 839 :==[] 840 The procedure upon the reception of a PCErr message is defined in 841 Section 7.14. 843 6.8. Close message 845 The Close message is a PCEP message that is either sent by a PCC to a 846 PCE or by a PCE to a PCC in order to close an established PCEP 847 session. The Message-Type field of the PCEP common header for the 848 Open message is set to 7 (To be confirmed by IANA). 850 Close message 851 ::= 852 853 The Close message MUST contain exactly one CLOSE object (see 854 Section 6.8). 856 Upon the receipt of a Close message, the receiving PCEP peer MUST 857 cancel all pending requests and MUST close the TCP connection. 859 7. Object Formats 861 7.1. Common object header 863 A PCEP object carried within a PCEP message consists of one or more 864 32-bit words with a common header which has the following format: 865 0 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Object-Class | OT |Res|P|I| Object Length (bytes) | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | | 871 // (Object body) // 872 | | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 Figure 8: PCEP common object header 877 Object-Class (8 bits): identifies the PCEP object class. 879 OT (Object-Type - 4 bits): identifies the PCEP object type. 881 The Object-Class and Object-Type fields are managed by IANA. 883 The Object-Class and Object-Type fields uniquely identify each PCEP 884 object. 886 Res flags (2 bits). Reserved field. This field MUST be set to zero 887 on transmission and MUST be ignored on receipt. 889 P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify 890 in a PCReq message sent to a PCE whether the object must be taken 891 into account by the PCE during path computation or is just optional. 892 When the P flag is set, the object MUST be taken into account by the 893 PCE. Conversely, when the P flag is cleared, the object is optional 894 and the PCE is free to ignore it if not supported. 896 I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 897 message to indicate to a PCC whether or not an optional object was 898 processed. The PCE MAY include the ignored optional object in its 899 reply and set the I flag to indicate that the optional object was 900 ignored during path computation. When the I flag is cleared, the PCE 901 indicates that the optional object was processed during the path 902 computation. The setting of the I flag for optional objects is 903 purely indicative and optional. The I flag has no meaning in a PCRep 904 message when the P flag had been set in the corresponding PCRep 905 message. 907 If the PCE does not understand an object with the P flag set or 908 understands the object but decides to ignore the object, the entire 909 PCEP message MUST be rejected and the PCE MUST send a PCErr message 910 with Error-Type="Unknown Object" or "Not supported Object". 912 Object Length (16 bits). Specifies the total object length including 913 the header, in bytes. The Object Length field MUST always be a 914 multiple of 4, and at least 4. The maximum object content length is 915 65528 bytes. 917 7.2. OPEN object 919 The OPEN object MUST be present in each Open message and MAY be 920 present in a PCErr message. There MUST be only one OPEN object per 921 Open or PCErr message. 923 The OPEN object contains a set of fields used to specify the PCEP 924 version, Keepalive frequency, DeadTimer, PCEP session ID along with 925 various flags. The OPEN object may also contain a set of TLVs used 926 to convey various session characteristics such as the detailed PCE 927 capabilities, policy rules and so on. No such TLV is currently 928 defined. 930 OPEN Object-Class is to be assigned by IANA (recommended value=1) 932 OPEN Object-Type is to be assigned by IANA (recommended value=1) 933 The format of the OPEN object body is as follows: 934 0 1 2 3 935 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Ver | Flags | Keepalive | Deadtimer | SID | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | | 940 // Optional TLV(s) // 941 | | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Figure 9: OPEN Object format 945 Ver (3 bits): PCEP version. Current version is 1. 947 Flags (5 bits): No Flags are currently defined. Unassigned bits are 948 considered as reserved and MUST be set to zero on transmission. 950 Keepalive (8 bits): maximum period of time (in seconds) between the 951 sending of PCEP messages. The minimum value for the Keepalive is 1 952 second. When set to 0, once the session is established, no further 953 Keepalive messages need to be sent to the remote peer. A RECOMMENDED 954 value for the keepalive frequency is 30 seconds. 956 DeadTimer (8 bits): specifies the amount of time after the expiration 957 of which a PCEP peer declares the session with the sender of the Open 958 message down if no PCEP message has been received. The DeadTimer 959 MUST be set to 0 if the Keepalive is set to 0. A RECOMMENDED value 960 for the DeadTimer is 4 times the value of the Keepalive. 962 SID (PCEP session-ID - 8 bits): specifies a 2 octet unsigned PCEP 963 session number that identifies the current session. The SID MUST be 964 incremented each time a new PCEP session is established and is mainly 965 used for logging and troubleshooting purposes. 967 Optional TLVs may be included within the OPEN object body to specify 968 PCC or PCE characteristics. The specification of such TLVs is 969 outside the scope of this document. 971 When present in an Open message, the OPEN object specifies the 972 proposed PCEP session characteristics. Upon receiving unacceptable 973 PCEP session characteristics during the PCEP session initialization 974 phase, the receiving PCEP peer (PCE) MAY include an OPEN object 975 within the PCErr message so as to propose alternative session 976 characteristic values. 978 7.3. RP Object 980 The RP (Request Parameters) object MUST be carried within each PCReq 981 and PCRep messages and MAY be carried within PCNtf and PCErr 982 messages. The P flag of the RP object MUST be set in PCReq and PCReq 983 messages and MUST be cleared in PCNtf and PCErr messages. The RP 984 object is used to specify various characteristics of the path 985 computation request. 987 7.3.1. Object definition 989 RP Object-Class is to be assigned by IANA (recommended value=2) 991 RP Object-Type is to be assigned by IANA (recommended value=1) 993 The format of the RP object body is as follows: 994 0 1 2 3 995 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 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Reserved | Flags |O|B|R| Pri | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Request-ID-number | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | | 1002 // Optional TLV(s) // 1003 | | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 Figure 10: RP object body format 1008 The RP object body has a variable length and may contain additional 1009 TLVs. No TLVs are currently defined. 1011 Reserved (8 bits): Reserved: This field MUST be set to zero on 1012 transmission and MUST be ignored on receipt. 1014 Flags: 18 bits - The following flags are currently defined: 1016 Pri (Priority - 3 bits): the Priority field may be used by the 1017 requesting PCC to specify to the PCE the request's priority from 1 to 1018 7. The decision of which priority should be used for a specific 1019 request is of a local matter and MUST be set to 0 when unused. 1020 Furthermore, the use of the path computation request priority by the 1021 PCE's scheduler is implementation specific and out of the scope of 1022 this document. Note that it is not required for a PCE to support the 1023 priority field: in this case, it is RECOMMENDED to set the priority 1024 field to 0 by the PCC in the RP object. If the PCE does not take 1025 into account the request priority, it is RECOMMENDED to set the 1026 priority field to 0 in the RP object carried within the corresponding 1027 PCRep message, regardless of the priority value contained in the RP 1028 object carried within the corresponding PCReq message. A higher 1029 numerical value of the priority field reflects a higher priority. 1030 Note that it is the responsibility of the network administrator to 1031 make use of the priority values in a consistent manner across the 1032 various PCC(s). The ability of a PCE to support requests 1033 prioritization may be dynamically discovered by the PCC(s) by means 1034 of PCE capability discovery. If not advertised by the PCE, a PCC may 1035 decide to set the request priority and will learn the ability of the 1036 PCE to support request prioritization by observing the Priority field 1037 of the RP object received in the PCRep message. If the value of the 1038 Pri field is set to 0, this means that the PCE does not support the 1039 handling of request priorities: in other words, the path computation 1040 request has been honoured but without taking the request priority 1041 into account. 1043 R (Reoptimization - 1 bit): when set, the requesting PCC specifies 1044 that the PCReq message relates to the reoptimization of an existing 1045 TE LSP in which case, in addition to the TE LSP attributes, the 1046 current path of the existing TE LSP to be reoptimized MUST be 1047 provided in the PCReq (except for 0-bandwidth TE LSP) message by 1048 means of an RRO object defined in Section 7.9. 1050 B (Bi-directional - 1 bit): when set, the PCC specifies that the path 1051 computation request relates to a bidirectional TE LSP that has the 1052 same traffic engineering requirements including fate sharing, 1053 protection and restoration, LSRs, and resource requirements (e.g. 1054 latency and jitter) in each direction. When cleared, the TE LSP is 1055 unidirectional. 1057 O (strict/lOose - 1 bit): when set, in a PCReq message, this 1058 indicates that a loose path is acceptable. Otherwise, when cleared, 1059 this indicates to the PCE that a path exclusively made of strict hops 1060 is required. In a PCRep message, when the O bit is set this 1061 indicates that the returned path is a loose path, otherwise (the O 1062 bit is cleared), the returned path is made of strict hops. 1064 Unassigned bits are considered as reserved and MUST be set to zero on 1065 transmission. 1067 Request-ID-number (32 bits). The Request-ID-number value combined 1068 with the source IP address of the PCC and the PCE address uniquely 1069 identify the path computation request context. The Request-ID-number 1070 MUST be incremented each time a new request is sent to the PCE. The 1071 value 0x0000000 is considered as invalid. If no path computation 1072 reply is received from the PCE, and the PCC wishes to resend its 1073 request, the same Request-ID-number MUST be used. Conversely, 1074 different Request-ID-number MUST be used for different requests sent 1075 to a PCE. The same Request-ID-number may be used for path 1076 computation requests sent to different PCEs. The path computation 1077 reply is unambiguously identified by the IP source address of the 1078 replying PCE. 1080 7.3.2. Handling of the RP object 1082 If a PCReq message is received without containing an RP object, the 1083 PCE MUST send a PCErr message to the requesting PCC with Error- 1084 type="Required Object missing" and Error-value="RP Object missing". 1086 If the O bit of the RP message carried within a PCReq message is 1087 cleared and local policy has been configured on the PCE to not 1088 provide explicit path(s) (for instance, for confidentiality reasons), 1089 a PCErr message MUST be sent by the PCE to the requesting PCC and the 1090 pending path computation request MUST be discarded. The Error-type 1091 is "Policy Violation" and Error-value is "O bit set". 1093 R bit: when the R bit of the RP object is set in a PCReq message, 1094 this indicates that the path computation request relates to the 1095 reoptimization of an existing TE LSP. In this case, the PCC MUST 1096 also provide the strict/loose path by including an RRO object in the 1097 PCReq message so as to avoid/limit double bandwidth counting if and 1098 only if the TE LSP is a non 0-bandwidth TE LSP. If the PCC has not 1099 requested a strict path (O bit set), a reoptimization can still be 1100 requested by the PCC but this implies for the PCE to be either 1101 stateful (keep track of the previously computed path with the 1102 associated list of strict hops) or to have the ability to retrieve 1103 the complete required path segment. Alternatively the PCC MUST be 1104 able to inform PCE of the working path with associated list of strict 1105 hops in PCReq. The absence of an RRO in the PCReq message for a non 1106 0-bandwidth TE LSP when the R bit of the RP object is set MUST 1107 trigger the sending of a PCErr message with Error-type="Required 1108 Object Missing" and Error-value="RRO Object missing for 1109 reoptimization". 1111 If the PCC receives a PCRep message that contains a RP object 1112 referring to an unknown Request-ID-Number, the PCC MUST send a PCErr 1113 message with Error-Type="Unknown request reference". 1115 7.4. NO-PATH Object 1117 The NO-PATH object is used in PCRep messages in response to an 1118 unsuccessful path computation request (the PCE could not find a path 1119 satisfying the set of constraints). When a PCE cannot find a path 1120 satisfying a set of constraints, it MUST include a NO-PATH object in 1121 the PCRep message. The NO-PATH object is used to report the 1122 impossibility to find a path that satisfies the set of constraints. 1123 Optionally, if the PCE supports such capability, the NO-PATH object 1124 MAY contain an optional NO-PATH-VECTOR TLV defined below and the 1125 PCRep message MAY also contain a list of objects that specify the set 1126 of constraints that could not be satisfied. The PCE MAY just 1127 replicate the set of object(s) that was received that was the cause 1128 of the unsuccessful computation or MAY optionally report a suggested 1129 value for which a path could have been found. 1131 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1133 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1134 The format of the NO-PATH object body is as follows: 1135 0 1 2 3 1136 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 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 |C| Flags | Reserved | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | | 1141 // Optional TLV(s) // 1142 | | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 Figure 11: NO-PATH object format 1147 Optionally, a TLV named NO-PATH-VECTOR MAY be included in the 1148 NO-PATH object that specifies the reason that led to unsuccessful path computation. 1150 The NO-PATH-VECTOR TLV is composed of 1 octet for the type, 1151 1 octet specifying the number of bytes in the value field, followed by 1152 a fix length value field of 32-bits flags field used to report the reason(s) 1153 that led to unsuccessful path computation The NO-PATH-VECTOR TLV is padded 1154 to eight-octet alignment. 1156 TYPE: To be assigned by IANA 1157 LENGTH: 4 1158 VALUE: 32-bits flags field 1160 IANA is requested to manage the space of flags carried in the NO-PATH-VECTOR TLV (see IANA section). 1162 The following flags are currently defined: 1164 0x01: PCE currently unavailable 1165 0x02: Unknown destination 1167 Flags (16 bits). 1169 The following flag is currently defined: 1171 C flag (1 bit): when set, the PCE indicates the set of unsatisfied 1172 constraints (reasons why a path could not be found) in the PCRep 1173 message by including the relevant PCEP objects. When cleared, no 1174 reason is specified. 1176 Reserved: This field MUST be set to zero on transmission and MUST be 1177 ignored on receipt. 1179 The NO-PATH object body has a variable length and may contain 1180 additional TLVs. The only TLV currently defined is the NO-PATH- 1181 VECTOR TLV defined below. 1183 Example: consider the case of a PCC that sends a path computation 1184 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1185 find a path for X MBits/s. In this case, the PCE must include in the 1186 PCRep message a NO-PATH object. Optionally the PCE may also include 1187 the original BANDWIDTH object so as to indicate that the reason for 1188 the unsuccessful computation is the bandwidth constraint (in this 1189 case, the C flag is set). If the PCE supports such capability it may 1190 alternatively include the BANDWIDTH Object and report a value of Y in 1191 the bandwidth field of the BANDWIDTH object (in this case, the C flag 1192 is set) where Y refers to the bandwidth for which a TE LSP with the 1193 same other characteristics could have been computed. 1195 When the NO-PATH object is absent from a PCRep message, the path 1196 computation request has been fully satisfied and the corresponding 1197 path(s) is/are provided in the PCRep message. 1199 7.5. END-POINT Object 1201 The END-POINTS object is used in a PCReq message to specify the 1202 source IP address and the destination IP address of the path for 1203 which a path computation is requested. Note that the source and 1204 destination addresses specified in the END-POINTS object may or may 1205 not correspond to the source and destination IP address of the TE LSP 1206 but rather to a path segment. Two END-POINTS objects (for IPv4 and 1207 IPv6) are defined. 1209 END-POINTS Object-Class is to be assigned by IANA (recommended 1210 value=4) 1212 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 1213 for IPv4 and 2 for IPv6) 1214 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1215 as follows: 1217 0 1 2 3 1218 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 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | Source IPv4 address | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Destination IPv4 address | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Figure 12: END-POINTS object body format for IPv4 1227 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 1229 0 1 2 3 1230 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 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | | 1233 | Source IPv6 address (16 bytes) | 1234 | | 1235 | | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | | 1238 | Destination IPv6 address (16 bytes) | 1239 | | 1240 | | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 Figure 13: END-POINTS object body format for IPv6 1245 The END-POINTS object body has a fixed length of 8 octets for IPv4 1246 and 32 octets for IPv6. 1248 7.6. BANDWIDTH Object 1250 The BANDWIDTH object is used to specify the requested bandwidth for a 1251 TE LSP. 1253 If the requested bandwidth is equal to 0, the BANDWIDTH object is 1254 optional. Conversely, if the requested bandwidth is non equal to 0, 1255 the PCReq message MUST contain a BANDWIDTH object. 1257 In the case of the reoptimization of a TE LSP, the bandwidth of the 1258 existing TE LSP MUST also be included in addition to the requested 1259 bandwidth if and only if the two values differ. Consequently, two 1260 Object-Type are defined that refer to the requested bandwidth and the 1261 bandwidth of the TE LSP for which a reoptimization is being 1262 performed. 1264 The BANDWIDTH object may be carried within PCReq and PCRep messages. 1266 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1267 value=5) 1269 Two Object-Type are defined for the BANDWIDTH object: 1271 o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by 1272 IANA (recommended value=1) 1274 o Bandwidth of an existing TE LSP for which a reoptimization is 1275 requested. BANDWIDTH Object-Type is to be assigned by IANA 1276 (recommended value=2) 1278 The format of the BANDWIDTH object body is as follows: 1279 0 1 2 3 1280 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 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Bandwidth | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 Figure 14: BANDWIDTH object body format 1286 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1287 IEEE floating point format, expressed in bytes per second. 1289 The BANDWIDTH object body has a fixed length of 4 octets. 1291 7.7. METRIC Object 1293 The METRIC object is optional and can be used for several purposes. 1295 In a PCReq message, a PCC MAY insert a METRIC object: 1297 o To indicate the metric that MUST be optimized by the path 1298 computation algorithm (IGP metric, TE metric, Hop counts). 1299 Currently, three metrics are defined: the IGP cost and the TE 1300 metric (see [RFC3785]) and the number of hops traversed by a TE 1301 LSP. 1303 o To indicate a bound on the path cost than MUST NOT be exceeded for 1304 the path to be considered as acceptable by the PCC. 1306 In a PCRep message, the METRIC object MAY be inserted so as to 1307 provide the cost for the computed path. It MAY also be inserted 1308 within a PCRep with the NO-PATH object to indicate that the metric 1309 constraint could not be satisfied. 1311 The path computation algorithmic aspects used by the PCE to optimize 1312 a path with respect to a specific metric are outside the scope of 1313 this document. 1315 It must be understood that such path metric is only meaningful if 1316 used consistently: for instance, if the delay of a path computation 1317 segment is exchanged between two PCEs residing in different domains, 1318 consistent ways of defining the delay must be used. 1320 The absence of the METRIC object MUST be interpreted by the PCE as a 1321 path computation request for which the PCE may choose the metric to 1322 be used. 1324 METRIC Object-Class is to be assigned by IANA (recommended value=6) 1326 METRIC Object-Type is to be assigned by IANA (recommended value=1) 1328 The format of the METRIC object body is as follows: 1329 0 1 2 3 1330 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 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Reserved | Flags |C|B| T | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | metric-value | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 Figure 15: METRIC object body format 1339 The METRIC object body has a fixed length of 8 octets. 1341 Reserved (16 bits): This field MUST be set to zero on transmission 1342 and MUST be ignored on receipt. 1344 T (Type - 8 bits): Specifies the metric type. 1346 Three values are currently defined: 1348 o T=1: IGP metric 1350 o T=2: TE metric 1352 o T=3: Hop Counts 1354 B (Bound - 1 bit): When set in a PCReq message, the metric-value 1355 indicates a bound (a maximum) for the path cost that must not be 1356 exceeded for the PCC to consider the computed path as acceptable. 1357 When the B flag is cleared, the metric-value field is not used to 1358 reflect a bound constraint. 1360 C (Cost - 1 bit): When set in a PCReq message, this indicates that 1361 the PCE MUST provide the computed path cost (should a path satisfying 1362 the constraints be found) in the PCRep message for the corresponding 1363 metric. 1365 Metric-value (32 bits): metric value encoded in 32 bits in IEEE 1366 floating point format. 1368 Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 1369 message. There MUST be at most one instance of the METRIC object for 1370 each metric type. If two or more instances of a METRIC object are 1371 present for a metric type, only the first instance MUST be considered 1372 and other instances MUST be ignored. 1374 In a PCReq message the presence of multiple METRIC object can be used 1375 to specify a multi-parameters (e.g. a metric may be a constraint or a 1376 parameter to minimize/maximize) objective function or multiple bounds 1377 for different constraints where at most one METRIC object must be 1378 used to indicate the metric to optimize (B-flag is cleared): the 1379 other METRIC object MUST be used to reflect bound constraints (B-Flag 1380 is set). 1382 A METRIC object used to indicate the metric to optimize during the 1383 path computation MUST have the B-Flag cleared and the T-Flag set to 1384 the appropriate value. When the path computation relates to the 1385 reoptimization of an exiting TE LSP (in which case R-Flag of the RP 1386 object is set) an implementation MAY decide to set the metric-value 1387 field to the cost of the TE LSP to be reoptimized with regards to a 1388 specific metric type. 1390 A METRIC object used to reflect a bound MUST have the B-Flag set, the 1391 T-Flag and metric-value field set to the appropriate values. 1393 In a PCRep message, unless not allowed by PCE policy, at least one 1394 METRIC object MUST be present that reports the computed path cost if 1395 the C bit of the METRIC object was set in the corresponding path 1396 computation request (the B-flag MUST be cleared); optionally the 1397 PCRep message MAY contain additional METRIC objects that correspond 1398 to bound constraints, in which case the metric-value MUST be equal to 1399 the corresponding path metric cost (the B-flag MUST be set). If no 1400 path satisfying the constraints could be found by the PCE, the METRIC 1401 objects MAY also be present in the PCRep message with the NO-PATH 1402 object to indicate the constraint metric that could be satisfied. 1404 Example: if a PCC sends a path computation request to a PCE where the 1405 metric to optimize is the IGP metric and the TE metric must not 1406 exceed the value of M, two METRIC object are inserted in the PCReq 1407 message: 1409 o First METRIC Object with B=0, T=1, C=1, metric-value=0x0000 1411 o Second METRIC Object with B=1, T=2, metric-value=M 1413 If a path satisfying the set of constraints can be found by the PCE 1414 and no policy preventing to provide the path cost is in place, the 1415 PCE inserts one METRIC object with B=0, T=1, metric-value= computed 1416 IGP path cost. Additionally, the PCE may insert a second METRIC 1417 object with B=1, T=2, metric-value= computed TE path cost. 1419 7.8. Explicit Route Object 1421 The ERO is used to encode a TE LSP. The ERO is carried within a 1422 PCRep message to provide the computed TE LSP should have the path 1423 computation been successful. 1425 The contents of this object are identical in encoding to the contents 1426 of the Explicit Route Object defined in [RFC3209], [RFC3473] and 1427 [RFC3477]. That is, the object is constructed from a series of sub- 1428 objects. Any RSVP ERO sub-object already defined or that could be 1429 defined in the future for use in the ERO is acceptable in this 1430 object. 1432 PCEP ERO sub-object types correspond to RSVP ERO sub-object types. 1434 Since the explicit path is available for immediate signaling by the 1435 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1436 and fields in this object are identical to those defined for the ERO. 1438 ERO Object-Class is to be assigned by IANA (recommended value=7) 1440 ERO Object-Type is to be assigned by IANA (recommended value=1) 1442 7.9. Record Route Object 1444 The RRO is used to record the route followed by a TE LSP. The PCEP 1445 RRO is exclusively carried within a PCReq message so as to specify 1446 the route followed by a TE LSP for which a reoptimization is desired. 1448 The contents of this object are identical in encoding to the contents 1449 of the Route Record Object defined in [RFC3209], [RFC3473] and 1450 [RFC3477]. That is, the object is constructed from a series of sub- 1451 objects. Any RSVP RRO sub-object already defined or that could be 1452 defined in the future for use in the RRO is acceptable in this 1453 object. 1455 The meanings of all of the sub-objects and fields in this object are 1456 identical to those defined for the RRO. 1458 PCEP RRO sub-object types correspond to RSVP RRO sub-object types. 1460 RRO Object-Class is to be assigned by IANA (recommended value=8) 1462 RRO Object-Type is to be assigned by IANA (recommended value=1) 1464 7.10. LSPA Object 1466 The LSPA object is optional and specifies various TE LSP attributes 1467 to be taken into account by the PCE during path computation. The 1468 LSPA (LSP Attributes) object can either be carried within a PCReq 1469 message or a PCRep message in case of unsuccessful path computation 1470 (in this case, the PCRep message also contains a NO-PATH object and 1471 the LSPA object is used to indicate the set of constraint(s) that 1472 could not be satisfied). Most of the fields of the LSPA object are 1473 identical to the fields of the SESSION-ATTRIBUTE object defined in 1474 [RFC3209] and [RFC4090]. When absent from the PCReq message, this 1475 means that the Setup and Holding priorities are equal to 0, and there 1476 are no affinity constraints. 1478 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1480 LSPA Object-Types is to be assigned by IANA (recommended value=1) 1482 The format of the LSPA object body is: 1484 0 1 2 3 1485 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 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Exclude-any | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Include-any | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Include-all | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Setup Prio | Holding Prio | Flags |L| Reserved | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | | 1496 // Optional TLV(s) // 1497 | | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 Figure 16: LSPA object body format 1501 Setup Prio (Setup Priority - 8 bits). The priority of the session 1502 with respect to taking resources, in the range of 0 to 7. The value 1503 0 is the highest priority. The Setup Priority is used in deciding 1504 whether this session can preempt another session. 1506 Holding Prio (Holding Priority - 8 bits). The priority of the 1507 session with respect to holding resources, in the range of 0 to 7. 1508 The value 0 is the highest priority. Holding Priority is used in 1509 deciding whether this session can be preempted by another session. 1510 Flags 1512 The flag L corresponds to the "Local protection desired" bit 1513 ([RFC3209]) of the SESSION-ATTRIBUTE Object. 1515 L Flag (Local protection desired). When set, this means that the 1516 computed path must include links protected with Fast Reroute as 1517 defined in [RFC4090]. 1519 Reserved (8 bits): This field MUST be set to zero on transmission and 1520 MUST be ignored on receipt. 1522 Note that the Optional TLV field may contain additional TE LSP 1523 attributes as defined in [RFC4420]. 1525 7.11. IRO Object 1527 The IRO (Include Route Object) object is optional and can be used to 1528 specify that the computed path MUST traverse a set of specified 1529 network elements. The IRO object MAY be carried within PCReq and 1530 PCRep messages. When carried within a PCRep message with the NO-PATH 1531 object, the IRO indicates the set of elements that fail the PCE to 1532 find a path. 1534 IRO Object-Class is to be assigned by IANA (recommended value=10) 1536 IRO Object-Type is to be assigned by IANA (recommended value=1) 1538 0 1 2 3 1539 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 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | | 1542 // (Subobjects) // 1543 | | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 Figure 17: IRO object body format 1547 Subobjects The IRO object is made of sub-object(s) identical to the 1548 ones defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs. 1550 The following subobject types are supported. 1552 Type Subobject 1553 1 IPv4 prefix 1554 2 IPv6 prefix 1555 4 Unnumbered Interface ID 1556 32 Autonomous system number 1557 The L bit of such sub-object has no meaning within an IRO object. 1559 7.12. SVEC Object 1561 7.12.1. Notion of Dependent and Synchronized path computation requests 1563 Independent versus dependent path computation requests: path 1564 computation requests are said to be independent if they are not 1565 related to each other. Conversely a set of dependent path 1566 computation requests is such that their computations cannot be 1567 performed independently of each other (a typical example of dependent 1568 requests is the computation of a set of diverse paths). 1570 Synchronized versus non-synchronized path computation requests: a set 1571 of path computation requests is said to be non-synchronized if their 1572 respective treatment (path computations) can be performed by a PCE in 1573 a serialized and independent fashion. 1575 There are various circumstances where the synchronization of a set of 1576 path computations may be beneficial or required. 1578 Consider the case of a set of N TE LSPs for which a PCC needs to send 1579 path computation requests to a PCE. The first solution consists of 1580 sending N separate PCReq messages to the selected PCE. In this case, 1581 the path computation requests are non synchronized. Note that the 1582 PCC may chose to distribute the set of N requests across K PCEs for 1583 load balancing purpose. Considering that M (with M+-+-+-+-+-+-+ | | 2422 | | | KeepWait |----+ | 2423 | +--| |<---+ | 2424 |+-----+-+-+-+-+-+-+ | | 2425 || | | | 2426 || | | | 2427 || V | | 2428 || +->+-+-+-+-+-+-+----+ | 2429 || | | OpenWait |-------+ 2430 || +--| |<------+ 2431 ||+----+-+-+-+-+-+-+<---+ | 2432 ||| | | | 2433 ||| | | | 2434 ||| V | | 2435 ||| +->+-+-+-+-+-+-+ | | 2436 ||| | |TCPPending |----+ | 2437 ||| +--| | | 2438 |||+---+-+-+-+-+-+-+<---+ | 2439 |||| | | | 2440 |||| | | | 2441 |||| V | | 2442 |||+--->+-+-+-+-+ | | 2443 ||+---->| Idle |-------+ | 2444 |+----->| |----------+ 2445 +------>+-+-+-+-+ 2447 Figure 23: PCEP Finite State Machine for the PCC 2449 PCEP defines the following set of variables: 2451 TCPConnect: timer (in seconds) started after having initialized a TCP 2452 connection using the PCEP well-known TCP port. The value of the 2453 TCPConnect timer is 60 seconds. 2455 TCPRetry: specifies the number of times the system has tried to 2456 establish a TCP connection with a PCEP peer without success. 2458 TCPMaxRetry: Maximum number of times the system tries to establish a 2459 TCP connection using the PCEP well-known TCP port before going back 2460 to the Idle state. The value of the TCPMaxRetry is 5. 2462 OpenWait: timer that corresponds to the amount of time a PCEP peer 2463 will wait to receive an Open message from the PCEP peer after the 2464 expiration of which the system releases the PCEP resource and go back 2465 to the Idle state. The OpenWait timer has a fixed value of 1 minute. 2467 KeepWait: timer that corresponds to the amount of time a PCEP peer 2468 will wait to receive a KeepAlive or a PCErr message from the PCEP 2469 peer after the expiration of which the system releases the PCEP 2470 resource and go back to the Idle state. The KeepWait timer has a 2471 fixed value of 1 minute. 2473 OpenRetry: specifies the number of times the system has received an 2474 Open message with unacceptable PCEP session characteristics. 2476 The following two states variable are defined: 2478 RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system 2479 has received an acceptable Open message. 2481 LocalOK: the LocalOK variable is a Boolean set to 1 if the system has 2482 received a Keepalive message acknowledging that the Open message sent 2483 to the peer was valid. 2485 Idle State: 2487 The idle state is the initial PCEP state where PCEP (also referred to 2488 as "the system") waits for an initialization event that can either be 2489 manually triggered by the user (configuration) or automatically 2490 triggered by various events. In Idle state, PCEP resources are 2491 allocated (memory, potential process, ...) but no PCEP messages are 2492 accepted from any PCEP peer. The system listens the well-known PCEP 2493 TCP port. 2495 The following set of variable are initialized: 2497 TCPRetry=0, 2498 LocalOK=0, 2500 RemoteOK=0, 2502 OpenRetry=0. 2504 Upon detection of a local initialization event (e.g. user 2505 configuration to establish a PCEP session with a particular PCEP 2506 peer, local event triggering the establishment of a PCEP session with 2507 a PCEP peer, ...), the system: 2509 o Starts the TCPConnect timer, 2511 o Initiates of a TCP connection with the PCEP peer, 2513 o Increments the TCPRetry variable, 2515 o Moves to the TCPPending state. 2517 Upon receiving a TCP connection on the well-known PCEP TCP port, if 2518 the TCP connection establishment succeeds, the system: 2520 o Sends an Open message, 2522 o Starts the OpenWait timer, 2524 o Stars the KeepWait timer, 2526 o Moves to the OpenWait state. 2528 It is expected that an implementation will use an exponentially 2529 increase timer between automatically generated Initialization events 2530 and between retrials of TCP connection establishments. 2532 TCPPending State 2534 If the TCP connection establishment succeeds, the system: 2536 o Sends an Open message, 2538 o Starts the OpenWait timer, 2540 o Starts the KeepWait timer, 2542 o Moves to the OpenWait state. 2544 If the TCP connection establishment fails (an error is detected 2545 during the TCP connection establishment) or the TCPConnectTimer 2546 expires: 2548 If TCPRetry =TCPMaxRetry the system moves to the Idle State 2550 If TCPRetry < TCPMaxRetry the system: 2552 o Starts the TCPConnect timer, 2554 o Initiates of a TCP connection with the PCEP peer, 2556 o Increments the TCPRetry variable, 2558 o Stays in the TPCPending state. 2560 If the system detects that the PCEP peer tries to simultaneously 2561 establish a TCP connection, it stops the TCP connection establishment 2562 if and only if the PCEP peer has a higher IP address and moves to the 2563 Idle state. This guarantees that in case of "collision" a single TCP 2564 connection is established. 2566 OpenWait State: 2568 In the OpenWait state, the system waits for an Open message from its 2569 PCEP peer. 2571 If the system receives an Open message from the PCEP peer before the 2572 expiration of the OpenWait timer, PCEP checks the PCEP session 2573 attributes (Keepalive frequency, DeadTimer, ...). 2575 If an error is detected (e.g. malformed Open message, presence of two 2576 Open objects, ...), PCEP generates an error notification, the PCEP 2577 peer sends a PCErr message with Error-Type=1 and Error-value=1. The 2578 system releases the PCEP resources for the PCEP peer, closes the TCP 2579 connection and moves to the Idle state. 2581 If no errors are detected, PCEP increments the OpenRetry variable. 2583 If no errors are detected, OpenRetry=2 and the session 2584 characteristics are unacceptable, the PCEP peer sends a PCErr with 2585 Error-Type=1 and Error-value=5, the system releases the PCEP 2586 resources for that peer and moves back to the Idle state. 2588 If no errors are detected and the session characteristics are 2589 acceptable to the local system, the system: 2591 o Sends a Keepalive message to the PCEP peer, 2592 o Starts the Keepalive timer, 2594 o Sets the RemoteOK variable to 1. 2596 If LocalOK=1 the system moves to the UP state. 2598 If LocalOK=0 the system moves to the KeepWait state. 2600 If no errors are detected but the session characteristics are 2601 unacceptable and non-negotiable, the PCEP peer sends a PCErr with 2602 Error-Type=1 and Error-value=3, the system releases the PCEP 2603 resources for that peer, and moves back to the Idle state. 2605 If no errors are detected, OpenRetry=1, the session characteristics 2606 are unacceptable but negotiable (such as the Keepalive frequency or 2607 the DeadTimer), the system: 2609 o sends a PCErr message with Error-Type=1 and Error-value=4 that 2610 contains proposed acceptable session characteristics, 2612 o If LocalOK=1, the system stays in the OpenWait state 2614 o If LocalOK=0, the system moves to the KeepWait state 2616 If no Open message is received before the expiration of the OpenWait 2617 timer, the PCEP peer sends a PCErr message with Error-Type=1 and 2618 Error-value=2, the system releases the PCEP resources for the PCEP 2619 peer, closes the TCP connection and moves to the Idle state. 2621 KeepWait State 2623 In the Keepwait state, the system waits for the receipt of a 2624 Keepalive from its PCEP peer acknowledging its Open message or a 2625 PCErr message in response to unacceptable PCEP session 2626 characteristics proposed in the Open message. 2628 If a Keepalive message is received before the expiration of the 2629 KeepWait timer, LocalOK=1 2631 If RemoteOK=1, the system moves to the UP state. 2633 If RemoteOK=0, the system moves to the OpenWait State. 2635 If a PCErr message is received before the expiration of the KeepWait 2636 timer: 2638 1. If the proposed values are unacceptable, the PCEP peer sends a 2639 PCErr message with Error-Type=1 and Error-value=6 and the system 2640 releases the PCEP resources for that PCEP peer, closes the TCP 2641 connection and moves to the Idle state. 2643 2. If the proposed values are acceptable, the system adjusts its 2644 PCEP session characteristics according to the proposed values 2645 received in the PCErr message restarts the KeepWait timer and 2646 sends a new Open message. If RemoteOK=1, the system stays in the 2647 KeepWait state. If RemoteOK=0, the system moves to the OpenWait 2648 state. 2650 If neither a Keepalive nor a PCErr is received after the expiration 2651 of the KeepWait timer, the PCEP peer sends a PCErr message with 2652 Error-Type=1 and Error-value=7 and, system releases the PCEP 2653 resources for that PCEP peer, closes the TCP connection and moves to 2654 the Idle State. 2656 UP State 2658 In the UP state, the PCEP peer starts exchanging PCEP messages 2659 according to the session characteristics. 2661 If the Keepalive timer expires, the system sends a Keepalive message. 2663 If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from 2664 the PCEP peer after the expiration of the DeadTimer, terminates PCEP 2665 session according to the procedure defined in Section 6.8, releases 2666 the PCEP resources for that PCEP peer, closes the TCP connection and 2667 moves to the Idle State. 2669 If a malformed message is received, the system terminates the PCEP 2670 session according to the procedure defined in Section 6.8, releases 2671 the PCEP resources for that PCEP peer, closes the TCP connection and 2672 moves to the Idle State. 2674 If the system detects that the PCEP peer tries to setup a second TCP 2675 connection, it stops the TCP connection establishment and sends a 2676 PCErr with Error-Type=10. 2678 If the TCP connection fails, the system releases the PCEP resources 2679 for that PCEP peer, closes the TCP connection and moves to the Idle 2680 State. 2682 11. Security Considerations 2684 PCEP could be the target of the following attacks: 2686 o Spoofing (PCC or PCE impersonation) 2688 o Snooping (message interception) 2690 o Falsification 2692 o Denial of Service 2694 A PCEP attack may have significant impact, particularly in an 2695 inter-AS context as PCEP facilitates inter-AS path establishment. 2696 Several mechanisms are proposed below, so as to ensure 2697 authentication, integrity and privacy of PCEP Communications, and 2698 also to protect against DoS attacks. 2700 11.1. PCEP Authentication and Integrity 2702 It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to 2703 provide for the authenticity and integrity of PCEP messages. This 2704 will allow protecting against PCE or PCC impersonation and also 2705 against message content falsification. 2707 This requires the maintenance, exchange and configuration of MD-5 2708 keys on PCCs and PCEs. Note that such maintenance may be especially 2709 onerous to the operators as pointed out in 2710 [I-D.ietf-rpsec-bgpsecrec]. Hence it is important to limit the 2711 number of keys while ensuring the required level of security. 2713 MD-5 signature faces some limitations, as per explained in [RFC2385]. 2714 Note that when one digest technique stronger than MD5 is specified 2715 and implemented, PCEP could be easily upgraded to use it. 2717 11.2. PCEP Privacy 2719 Ensuring PCEP communication privacy is of key importance, especially 2720 in an inter-AS context, where PCEP communication end-points do not 2721 reside in the same AS, as an attacker that intercept a PCE message 2722 could obtain sensitive information related to computed paths and 2723 resources. Privacy can be ensured thanks to encryption. To ensure 2724 privacy of PCEP communication, IPSec [RFC2406] tunnels MAY be used 2725 between PCC and PCEs or between PCEs. Note that this could also be 2726 used to ensure Authentication and Integrity, in which case, TCP MD-5 2727 option would not be required. 2729 11.3. Protection against Denial of Service attacks 2731 PCEP can be the target of TCP DoS attacks, such as for instance SYN 2732 attacks, as all protocols running on top of TCP. PCEP can use the 2733 same mechanisms as defined in [RFC3036] to mitigate the threat of 2734 such attacks: 2736 o A PCE should avoid promiscuous TCP listens for PCEP TCP connection 2737 establishment. It should use only listens that are specific to 2738 authorized PCCs. 2740 o The use of the MD5 option helps somewhat since it prevents a SYN 2741 from being accepted unless the MD5 segment checksum is valid. 2742 However, the receiver must compute the checksum before it can 2743 decide to discard an otherwise acceptable SYN segment. 2745 o The use of access-list on the PCE so as to restrict access to 2746 authorized PCCs. 2748 11.4. Request input shaping/policing 2750 A PCEP implementation may be subject to Denial Of Service attacks 2751 consisting of sending a very large number of PCEP messages (e.g. 2752 PCReq messages). Thus, especially in multi-Service Providers 2753 environments, a PCE implementation should implement request input 2754 shaping/policing so as to throttle the amount of received PCEP 2755 messages without compromising the implementation behavior. 2757 12. Authors' addresses 2759 This document was the collective work of several authors. The 2760 content of this document was contributed by the editors and the co- 2761 authors listed below: 2763 Arthi Ayyangar 2764 Nuova Systems 2765 2600 San Tomas Expressway 2766 Santa Clara, CA 95051 2767 USA 2769 Email: arthi@nuovasystems.com 2771 Eiji Oki 2772 NTT 2773 Midori 3-9-11 2774 Musashino, Tokyo, 180-8585 2775 JAPAN 2777 Email: oki.eiji@lab.ntt.co.jp 2779 Alia Atlas 2780 Google 2781 1600 Amphitheatre Parkway 2782 Montain View, CA 94043 2783 USA 2785 Email: akatlas@alum.mit.edu 2787 Andrew Dolganow 2788 Alcatel 2789 600 March Road 2790 Ottawa, ON K2K 2E6 2791 CANADA 2793 Email: andrew.dolganow@alcatel.com 2795 Yuichi Ikejiri 2796 NTT Communications Corporation 2797 1-1-6 Uchisaiwai-cho, Chiyoda-ku 2798 Tokyo, 100-819 2799 JAPAN 2801 Email: y.ikejiri@ntt.com 2803 Kenji Kumaki 2804 KDDI Corporation 2805 Garden Air Tower Iidabashi, Chiyoda-ku, 2806 Tokyo, 102-8460 2807 JAPAN 2809 Email: ke-kumaki@kddi.com 2811 13. Acknowledgements 2813 The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash, 2814 Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard 2815 Douville and Jon Parker for their very valuable input. Special thank 2816 to Adrian Farrel for his very valuable suggestions. 2818 14. References 2819 14.1. Normative References 2821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2822 Requirement Levels", BCP 14, RFC 2119, March 1997. 2824 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2825 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2826 Functional Specification", RFC 2205, September 1997. 2828 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2829 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2830 Tunnels", RFC 3209, December 2001. 2832 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2833 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2834 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2836 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 2837 in Resource ReSerVation Protocol - Traffic Engineering 2838 (RSVP-TE)", RFC 3477, January 2003. 2840 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 2841 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 2842 May 2005. 2844 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 2845 Element (PCE)-Based Architecture", RFC 4655, August 2006. 2847 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 2848 Communication Protocol Generic Requirements", RFC 4657, 2849 September 2006. 2851 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 2852 (PCE) Discovery", RFC 4674, October 2006. 2854 14.2. Informative References 2856 [I-D.ietf-ccamp-inter-domain-rsvp-te] 2857 Ayyangar, A., "Inter domain Multiprotocol Label Switching 2858 (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - 2859 RSVP-TE extensions", 2860 draft-ietf-ccamp-inter-domain-rsvp-te-05 (work in 2861 progress), March 2007. 2863 [I-D.ietf-pce-disco-proto-isis] 2864 Roux, J., "IS-IS protocol extensions for Path Computation 2865 Element (PCE) Discovery", 2866 draft-ietf-pce-disco-proto-isis-02 (work in progress), 2867 February 2007. 2869 [I-D.ietf-pce-disco-proto-ospf] 2870 Roux, J., "OSPF protocol extensions for Path Computation 2871 Element (PCE) Discovery", 2872 draft-ietf-pce-disco-proto-ospf-02 (work in progress), 2873 February 2007. 2875 [I-D.ietf-pce-inter-layer-req] 2876 Oki, E., "PCC-PCE Communication Requirements for Inter- 2877 Layer Traffic Engineering", 2878 draft-ietf-pce-inter-layer-req-03 (work in progress), 2879 October 2006. 2881 [I-D.ietf-pce-interas-pcecp-reqs] 2882 Bitar, N., "Inter-AS Requirements for the Path Computation 2883 Element Communication Protocol (PCECP)", 2884 draft-ietf-pce-interas-pcecp-reqs-01 (work in progress), 2885 October 2006. 2887 [I-D.ietf-pce-manageability-requirements] 2888 Farrel, A., "Inclusion of Manageability Sections in PCE 2889 Working Group Drafts", 2890 draft-ietf-pce-manageability-requirements-01 (work in 2891 progress), March 2007. 2893 [I-D.ietf-pce-pcecp-interarea-reqs] 2894 Roux, J., "PCE Communication Protocol (PCECP) Specific 2895 Requirements for Inter-Area Multi Protocol Label 2896 Switching (MPLS) and Generalized MPLS (GMPLS) Traffic 2897 Engineering", draft-ietf-pce-pcecp-interarea-reqs-05 (work 2898 in progress), December 2006. 2900 [I-D.ietf-rpsec-bgpsecrec] 2901 Christian, B. and T. Tauber, "BGP Security Requirements", 2902 draft-ietf-rpsec-bgpsecrec-07 (work in progress), 2903 February 2007. 2905 [I-D.kkoushik-pce-pcep-mib] 2906 Stephan, E. and K. Koushik, "PCE communication 2907 protocol(PCEP) Management Information Base", 2908 draft-kkoushik-pce-pcep-mib-00 (work in progress), 2909 February 2007. 2911 [I-D.vasseur-pce-monitoring] 2912 Roux, J. and J. Vasseur, "A set of monitoring tools for 2913 Path Computation Element based Architecture", 2914 draft-vasseur-pce-monitoring-02 (work in progress), 2915 March 2007. 2917 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2918 April 1992. 2920 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 2921 Signature Option", RFC 2385, August 1998. 2923 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 2924 Payload (ESP)", RFC 2406, November 1998. 2926 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2927 B. Thomas, "LDP Specification", RFC 3036, January 2001. 2929 [RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and 2930 T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric 2931 as a second MPLS Traffic Engineering (TE) Metric", BCP 87, 2932 RFC 3785, May 2004. 2934 [RFC4022] Raghunarayan, R., "Management Information Base for the 2935 Transmission Control Protocol (TCP)", RFC 4022, 2936 March 2005. 2938 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 2939 June 2005. 2941 [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A. 2942 Ayyangar, "Encoding of Attributes for Multiprotocol Label 2943 Switching (MPLS) Label Switched Path (LSP) Establishment 2944 Using Resource ReserVation Protocol-Traffic Engineering 2945 (RSVP-TE)", RFC 4420, February 2006. 2947 Appendix A. Compliance with the PCECP Requirement Document 2949 The aim of this section is to list the set of requirements set forth 2950 in [RFC4657] that are not satisfied by the current revision of this 2951 document. This only concerns the requirements listed as MUST 2952 according to [RFC2119]. 2954 Here is the list of currently unsatisfied requirements: 2956 o Allow to select/prefer from advertised list of standard objective 2957 functions/options 2959 o Allow to customize objective function/options 2960 o Support "unsynchronized" & "synchronized" objective functions 2962 PCEP is a flexible protocol allowing for the addition of new message 2963 and objects type. With regards to the requirement liste above, the 2964 Working Group has decided to cover those requirements in a separate 2965 document. 2967 Appendix B. PCEP Variables 2969 PCEP defines the following configurable variables: 2971 KeepAlive timer: minimum period of time between the sending of PCEP 2972 messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A 2973 suggested value for the Keepalive timer is 30 seconds. 2975 DeadTimer: period of timer after the expiration of which a PCEP peer 2976 declared the session down if no PCEP message has been received. 2978 SyncTimer: the SYNC timer is used in the case of synchronized path 2979 computation request using the SVEC object defined in Section 7.12.3. 2980 Consider the case where a PCReq message is received by a PCE that 2981 contains the SVEC object referring to M synchronized path computation 2982 requests. If after the expiration of the SYNC timer all the M path 2983 computation requests have not been received, a protocol error is 2984 triggered and the PCE MUST cancel the whole set of path computation 2985 requests. A RECOMMENDED value for the SYNC timer is 60 seconds. 2987 Authors' Addresses 2989 JP Vasseur (editor) 2990 Cisco Systems 2991 1414 Massachusetts Avenue 2992 Boxborough, MA 01719 2993 USA 2995 Email: jpv@cisco.com 2997 JL Le Roux (editor) 2998 France Telecom 2999 2, Avenue Pierre-Marzin 3000 Lannion, 22307 3001 FRANCE 3003 Email: jeanlouis.leroux@orange-ftgroup.com 3005 Full Copyright Statement 3007 Copyright (C) The IETF Trust (2007). 3009 This document is subject to the rights, licenses and restrictions 3010 contained in BCP 78, and except as set forth therein, the authors 3011 retain all their rights. 3013 This document and the information contained herein are provided on an 3014 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3015 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3016 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3017 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3018 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3019 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3021 Intellectual Property 3023 The IETF takes no position regarding the validity or scope of any 3024 Intellectual Property Rights or other rights that might be claimed to 3025 pertain to the implementation or use of the technology described in 3026 this document or the extent to which any license under such rights 3027 might or might not be available; nor does it represent that it has 3028 made any independent effort to identify any such rights. Information 3029 on the procedures with respect to rights in RFC documents can be 3030 found in BCP 78 and BCP 79. 3032 Copies of IPR disclosures made to the IETF Secretariat and any 3033 assurances of licenses to be made available, or the result of an 3034 attempt made to obtain a general license or permission for the use of 3035 such proprietary rights by implementers or users of this 3036 specification can be obtained from the IETF on-line IPR repository at 3037 http://www.ietf.org/ipr. 3039 The IETF invites any interested party to bring to its attention any 3040 copyrights, patents or patent applications, or other proprietary 3041 rights that may cover technology that may be required to implement 3042 this standard. Please address the information to the IETF at 3043 ietf-ipr@ietf.org. 3045 Acknowledgment 3047 Funding for the RFC Editor function is provided by the IETF 3048 Administrative Support Activity (IASA).