idnits 2.17.1 draft-ietf-pce-pcep-02.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 27. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2641. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 60 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: L (Link diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST not have any link in common. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: N (Node diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST not have any node in common. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: S (SRLG diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST not share any SRLG (Shared Risk Link Group). -- 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 (June 22, 2006) is 6511 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 2418, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ccamp-inter-domain-rsvp-te' is defined on line 2440, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-pcecp-interarea-reqs' is defined on line 2473, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rpsec-bgpsecrec' is defined on line 2479, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-03 == Outdated reference: A later version (-07) exists of draft-ietf-pce-comm-protocol-gen-reqs-06 == Outdated reference: A later version (-02) exists of draft-ietf-pce-disco-proto-igp-01 == Outdated reference: A later version (-15) exists of draft-ietf-pce-inter-layer-req-01 == Outdated reference: A later version (-05) exists of draft-ietf-pce-pcecp-interarea-reqs-01 == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-06 -- 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) Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems, Inc 3 Expires: December 24, 2006 JL. Le Roux 4 France Telecom 5 A. Ayyangar 6 Juniper Networks 7 E. Oki 8 NTT 9 A. Atlas 10 Google 11 A. Dolganow 12 Alcatel 13 Y. Ikejiri 14 NTT Communications Corporation 15 K. Kumaki 16 KDDI Corporation 17 June 22, 2006 19 Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 20 draft-ietf-pce-pcep-02.txt 22 Status of this Memo 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware 26 have been or will be disclosed, and any of which he or she becomes 27 aware will be disclosed, in accordance with Section 6 of BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on December 24, 2006. 47 Copyright Notice 48 Copyright (C) The Internet Society (2006). 50 Abstract 52 This document specifies the Path Computation Element communication 53 Protocol (PCEP) for communications between a Path Computation Client 54 (PCC) and a Path Computation Element (PCE), or between two PCEs. 55 Such interactions include path computation requests and path 56 computation replies as well as notifications of specific states 57 related to the use of a PCE in the context of MPLS and GMPLS Traffic 58 Engineering. The PCEP protocol is designed to be flexible and 59 extensible so as to easily allow for the addition of further messages 60 and objects, should further requirements be expressed in the future. 62 Requirements Language 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119 [RFC2119]. 68 Table of Contents 70 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Transport protocol . . . . . . . . . . . . . . . . . . . . . . 6 74 5. Architectural Protocol Overview (Model) . . . . . . . . . . . 7 75 5.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 5.2. Architectural Protocol Overview . . . . . . . . . . . . . 7 77 5.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 8 78 5.2.2. Path computation request sent by a PCC to a PCE . . . 9 79 5.2.3. Path computation reply sent by the PCE to a PCC . . . 10 80 5.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 12 81 5.2.5. Termination of the PCEP Session . . . . . . . . . . . 13 82 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 83 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 14 84 6.2. Open message . . . . . . . . . . . . . . . . . . . . . . . 15 85 6.3. Keepalive message . . . . . . . . . . . . . . . . . . . . 16 86 6.4. Path Computation Request (PCReq) message . . . . . . . . . 17 87 6.5. Path Computation Reply (PCRep) message . . . . . . . . . . 18 88 6.6. Notification (PCNtf) message . . . . . . . . . . . . . . . 19 89 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 20 90 6.8. Close message . . . . . . . . . . . . . . . . . . . . . . 21 91 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 21 92 7.1. Common object header . . . . . . . . . . . . . . . . . . . 21 93 7.2. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 23 94 7.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 24 95 7.3.1. Object definition . . . . . . . . . . . . . . . . . . 24 96 7.3.2. Handling of the RP object . . . . . . . . . . . . . . 26 97 7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 27 98 7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 28 99 7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 29 100 7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 30 101 7.8. ERO Object . . . . . . . . . . . . . . . . . . . . . . . . 32 102 7.9. RRO Object . . . . . . . . . . . . . . . . . . . . . . . . 33 103 7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 33 104 7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 35 105 7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 36 106 7.12.1. Independent versus synchronized path computation 107 requests . . . . . . . . . . . . . . . . . . . . . . . 36 108 7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 37 109 7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 38 110 7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 39 111 7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 42 112 7.15. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 44 113 8. Manageability Considerations . . . . . . . . . . . . . . . . . 45 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 115 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 45 116 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 45 117 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 46 118 9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 47 119 9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 48 120 10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 49 121 11. Security Considerations . . . . . . . . . . . . . . . . . . . 54 122 11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 55 123 11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 55 124 11.3. Protection against Denial of Service attacks . . . . . . . 55 125 11.4. Request input shaping/policing . . . . . . . . . . . . . . 56 126 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 127 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 128 13.1. Normative References . . . . . . . . . . . . . . . . . . . 56 129 13.2. Informative References . . . . . . . . . . . . . . . . . . 57 130 Appendix A. Proposed Status and Discussion [To Be Removed 131 Upon Publication] . . . . . . . . . . . . . . . . . . 58 132 Appendix B. Compliance with the PCECP Requirement Document . . . 58 133 Appendix C. PCEP Variables . . . . . . . . . . . . . . . . . . . 59 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 135 Intellectual Property and Copyright Statements . . . . . . . . . . 62 137 1. Terminology 139 Terminology used in this document 141 Explicit path: full explicit path from start to destination made of a 142 list of strict hops where a hop may be an abstract node such as an 143 AS. 145 IGP Area: OSPF Area or IS-IS level. 147 Inter-domain TE LSP: A TE LSP whose path transits across at least two 148 different domains where a domain can either be an IGP area, an 149 Autonomous System or a sub-AS (BGP confederations). 151 PCC: Path Computation Client: any client application requesting a 152 path computation to be performed by a Path Computation Element. 154 PCE: Path Computation Element: an entity (component, application or 155 network node) that is capable of computing a network path or route 156 based on a network graph and applying computational constraints. 158 PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the 159 PCE). 161 TED: Traffic Engineering Database which contains the topology and 162 resource information of the domain. The TED may be fed by IGP 163 extensions or potentially by other means. 165 TE LSP: Traffic Engineering Label Switched Path. 167 Strict/loose path: mix of strict and loose hops comprising of at 168 least one loose hop representing the destination where a hop may be 169 an abstract node such as an AS. 171 Within this document, when PCE-PCE communications are being 172 described, the requesting PCE fills the role of a PCC. This provides 173 a saving in documentation without loss of function. 175 2. Introduction 177 [I-D.ietf-pce-architecture]describes the motivations and architecture 178 for a PCE-based model for the computation of MPLS and GMPLS TE LSPs. 179 The model allows the separation of PCE from PCC, and allows 180 cooperation between PCEs. This necessitates a communication protocol 181 between PCC and PCE, and between PCEs. 183 [I-D.ietf-pce-comm-protocol-gen-reqs] states the generic requirements 184 for such a protocol including the requirement for using the same 185 protocol between PCC and PCE, and between PCEs. Additional 186 application-specific requirements (for scenarios such as inter-area, 187 inter-AS, etc.) are not included in [I-D.ietf-pce-comm-protocol-gen- 188 reqs], but there is a requirement that any solution protocol must be 189 easily extensible to handle other requirements as they are introduced 190 in application-specific requirements documents. Examples of such 191 application-specific requirements are [I-D.ietf-pce-pcecp-interarea- 192 reqs]and [I-D.ietf-pce-inter-layer-req]. 194 This document specifies the Path Computation Element communication 195 Protocol (PCEP) for communications between Path Computation Client 196 (PCC) and a Path Computation Element (PCE),or between two PCEs. Such 197 interactions include path computation requests and path computation 198 replies as well as notifications of specific states related to the 199 use of a PCE in the context of MPLS and GMPLS Traffic Engineering. 200 The PCEP protocol is designed to be flexible and extensible so as to 201 easily allow for the addition of further messages and objects, should 202 further requirements be expressed in the future. 204 3. Assumptions 206 [I-D.ietf-pce-architecture] describes various types of PCE. PCEP 207 does not make any assumption and thus does not impose any constraint 208 on the nature of the PCE. 210 Moreover, it is assumed that the PCE gets the required information so 211 as to perform TE LSP path computation which usually requires network 212 topology and resource information that can be gathered by routing 213 protocols or by some other means. The retrieval of such information 214 is out of the scope of this document. 216 Similarly, no assumption is made on the discovery method used by a 217 PCC to discover a set of PCEs (e.g. via static configuration or 218 dynamic discovery) and on the PCE decision selection process. For 219 the sake of reference [I-D.ietf-pce-discovery-reqs] defines a list of 220 requirements for dynamic PCE discovery and IGP-based solution for 221 such PCE discovery are specified in [I-D.ietf-pce-disco-proto-igp]. 223 4. Transport protocol 225 PCEP operates over TCP using a well-known TCP port (to be assigned by 226 IANA). This allows the requirements of reliable messaging and flow 227 control to be met without further protocol work. 229 An implementation may decide to keep the TCP session alive for an 230 unlimited time (this may for instance be appropriate when path 231 computation requests are sent on a frequent basis so as to avoid to 232 open a TCP session each time a path computation request is needed). 233 Conversely, in some other circumstances, it may be desirable to 234 systematically open and close the TCP connection for each PCEP 235 request (for instance when sending of path computation request is a 236 rare event). 238 5. Architectural Protocol Overview (Model) 240 The aim of this section is to describe the PCEP protocol model in the 241 spirit of [RFC4101]. An architecture protocol overview (the big 242 picture of the protocol) is provided in this section. Protocol 243 details can be found in further sections. 245 5.1. Problem 247 The PCE-based architecture used for the computation of MPLS and GMPLS 248 TE LSP paths is described in [I-D.ietf-pce-architecture]. When the 249 PCC and the PCE are not collocated, a communication protocol between 250 the PCC and the PCE is required. PCEP is such a protocol designed 251 specifically for communications between a PCC and a PCE or between 252 two PCEs: a PCC may use PCEP to send a path computation request for 253 one or more TE LSP(s) to a PCE and such a PCE may reply with a set of 254 computed path(s) if one or more path(s) obeying the set of 255 constraints can be found. 257 5.2. Architectural Protocol Overview 259 PCEP operates over TCP, which allows the requirements of reliable 260 messaging and flow control to be met without further protocol work. 262 Several PCEP messages are defined: 264 - Open and Keepalive messages are used to initiate and maintain a 265 PCEP session respectively. 267 - PCReq: a PCEP message sent by a PCC to a PCE to request a path 268 computation. 270 - PCRep: a PCEP message sent by a PCE to a PCC in reply to a path 271 computation request. A PCRep message can either contain a set of 272 computed path(s) if the request could be satisfied or a negative 273 reply otherwise. 275 - PCNtf: a PCEP notification message either sent by a PCC to a PCE or 276 a PCE to a PCC to notify of specific event. 278 - PCErr: a PCEP message sent upon the occurrence of a protocol error 279 condition. 281 - Close message: a message used to close a PCEP session. 283 The set of available PCE(s) may be either statically configured on a 284 PCC or dynamically discovered (the mechanism for that discovery is 285 out of the scope of this document). Note that the PCE selection 286 algorithm is out of the scope of this document. 288 A PCC may have PCEP sessions with more than one PCE and similarly a 289 PCE may have PCEP sessions with multiple PCCs. 291 A PCEP session establishment is always triggered by the PCC. 293 5.2.1. Initialization Phase 295 The initialization phase consists of two successive steps (described 296 in a schematic form in Figure 1): 298 1) Establishment of a TCP connection (3-way handshake) between the 299 PCC and the PCE. 301 2) Establishment of a PCEP session over the TCP connection. 303 Once the TCP connection is established, the PCC and the PCE (also 304 referred to as "PCEP peers") initiate a PCEP session establishment 305 during which various session parameters are negotiated. These 306 parameters are carried within Open messages and include the keepalive 307 timer and, potentially, other detailed capabilities and policy rules 308 that specify the conditions under which path computation requests may 309 be sent to the PCE. If the PCEP session establishment phase fails 310 because the PCEP peers disagree on the exchanged parameters or one of 311 the PCEP peers does not answer after the expiration of the 312 establishment timer, the TCP connection is immediately closed. 313 Successive retries are permitted but an implementation SHOULD make 314 use of exponential back-off. 316 Keepalive messages are used to acknowledge Open messages and once the 317 PCEP session has been successfully established, Keepalive messages 318 are exchanged between PCEP peers to ensure the liveness of the PCEP 319 session. 321 Details about the Open message and the Keepalive messages can be 322 found in . (Section 6.2) and Section 6.3respectively. 324 +-+-+ +-+-+ 325 |PCC| |PCE| 326 +-+-+ +-+-+ 327 | | 328 |---- Open message --->| 329 | | 330 |<--- Open message ----| 331 | | 332 | | 333 | | 334 |<--- Keepalive -------| 335 | | 336 |---- Keepalive ------>| 338 Figure 1: PCEP Initialization phase (triggered by a PCC) 340 5.2.2. Path computation request sent by a PCC to a PCE 342 +-+-+ +-+-+ 343 |PCC| |PCE| 344 +-+-+ +-+-+ 345 1)Path computation | | 346 event | | 347 2)PCE Selection | | 348 3)Path computation |---- PCReq message--->| 349 request sent to | | 350 the selected PCE | | 352 Figure 2: Path computation request 354 Once a PCC (or a PCE) has successfully established a PCEP session 355 with one or more PCEs, if an event is triggered that requires the 356 computation of a set of path(s), the PCC first selects one of more 357 PCE(s) to send the request to. Note that the PCE selection decision 358 process may have taken place prior to the PCEP session establishment. 360 Once the PCC has selected a PCE, it sends a path computation request 361 to the PCE (PCReq message) that contains a variety of objects that 362 specify the set of constraints and attributes for the path to be 363 computed. For example "Compute a TE LSP path with source IP 364 address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=X 365 Mbit/s, Priority=Y, ...". Additionally, the PCC may desire to 366 specify the urgency of such request by assigning a request priority. 367 Each request is uniquely identified by a request-id number and the 368 PCC-PCE addresses pair. The process is shown in a schematic form in 369 figure 2. 371 Details about the PCReq message can be found in Section 6.4 373 5.2.3. Path computation reply sent by the PCE to a PCC 374 +-+-+ +-+-+ 375 |PCC| |PCE| 376 +-+-+ +-+-+ 377 | | 378 |---- PCReq message--->| 379 | |1) Path computation 380 | |request received 381 | | 382 | |2)Path successfully 383 | |computed 384 | | 385 | |3) Computed path(s) sent 386 | |to the PCC 387 |<--- PCRep message ---| 388 | (Positive reply) | 390 Figure 3a: Path computation request with successful path computation 392 +-+-+ +-+-+ 393 |PCC| |PCE| 394 +-+-+ +-+-+ 395 | | 396 | | 397 |---- PCReq message--->| 398 | |1) Path computation 399 | |request received 400 | | 401 | |2) No Path found that 402 | |satisfies the request 403 | | 404 | |3) Negative reply sent to 405 | |the PCC (optionally with 406 | |various additional 407 | |information) 408 |<--- PCRep message ---| 409 | (Negative reply) | 411 Figure 3b: Path computation request with unsuccessful path computation 412 Upon receiving a path computation request from a PCC, the PCE 413 triggers a path computation, the result of which can either be: 415 - Positive (Figure 3-a): the PCE manages to compute a path satisfying 416 the set of required constraints. The PCE returns the set of computed 417 path(s) to the requesting PCC. Note that PCEP supports the 418 capability to send a single request which refers to the computation 419 of multiple paths: for example, compute two link-diverse paths. 421 - Negative (Figure 3-b): no path could be found that satisfies the 422 set of constraints. In this case, a PCE may provide the set of 423 constraints that led to the path computation failure. Upon receiving 424 a negative reply, a PCC may decide to resend a modified request or 425 take any other appropriate action. 427 Details about the PCRep message can be found in Section 6.5. 429 5.2.4. Notification 431 There are several circumstances whereby a PCE may want to notify a 432 PCC of a specific event. For example, suppose that the PCE suddenly 433 experiences some congestion that would lead to unacceptable response 434 times. The PCE may want to notify one or more PCCs that some of 435 their requests (listed in the notification) will not be satisfied or 436 may experience unacceptable delays. Such notification may 437 potentially result in path computation redirections on the PCC 438 towards another PCE, if an alternate PCE is available. Similarly, a 439 PCC may desire to notify a PCE of particular event such as the 440 cancellation of pending request(s). 442 +-+-+ +-+-+ 443 |PCC| |PCE| 444 +-+-+ +-+-+ 445 1)Path computation | | 446 event | | 447 2)PCE Selection | | 448 3)Path computation |---- PCReq message--->| 449 request X sent to | |4) Path computation 450 the selected PCE | |triggered 451 | | 452 | | 453 5) Path computation| | 454 request X cancelled| | 455 |---- PCNtf message -->| 456 | |6) Path computation 457 | |request X cancelled 459 Figure 4: Example of PCC notification (request cancellation) sent to a PCE 461 +-+-+ +-+-+ 462 |PCC| |PCE| 463 +-+-+ +-+-+ 464 1)Path computation | | 465 event | | 466 2)PCE Selection | | 467 3)Path computation |---- PCReq message--->| 468 request X sent to | |4) Path computation 469 the selected PCE | |triggered 470 | | 471 | | 472 | |5) PCE experiencing 473 | |congestion 474 | | 475 | |6) Path computation 476 | |request X cancelled 477 | | 478 |<--- PCNtf message----| 480 Figure 5: Example of PCE notification (request(s) cancellation) sent to a PCC 482 Details about the PCNtf message can be found in Section 6.6. 484 5.2.5. Termination of the PCEP Session 486 When one of the PCEP peers desires to terminate a PCEP session it 487 first sends a PCEP Close message and then close the TCP connection. 489 If the PCEP session is terminated by the PCE, the PCC clears all the 490 states related to pending requests sent to the PCE. Similarly, if 491 the PCC terminates a PCEP session the PCE clears all pending path 492 computation requests sent by the PCC in question as well as the 493 related states. A Close message can only be sent to terminate a PCEP 494 session if the PCEP session has previously been established. 496 In case of TCP connection failure, the PCEP session SHOULD be 497 maintained for a period of time equal to the Deadtimer. 499 Details about the Close message can be found in Section 6.8. 501 6. PCEP Messages 503 A PCEP message consists of a common header followed by a variable 504 length body made of a set of objects that can either be mandatory or 505 optional. In the context of this document, an object is said to be 506 mandatory in a PCEP message when the object must be included in such 507 message for the message to be considered as valid. Thus a missing 508 mandatory object in a PCEP message MUST be considered as a malformed 509 message and such condition MUST trigger an Error message. 510 Conversely, if an object is optional, the object may or may not be 511 present. 513 A flag referred to as the P flag is defined in the common header of 514 each PCEP object (see Section 7.1) that can be set by a PCEP peer to 515 enforce a PCE to take into account the related information during the 516 path computation. For example, the COST object allows a PCC to 517 specify a bounded acceptable path cost. The COST object is optional 518 but a PCC may set a flag to ensure that such constraint is taken into 519 account. Similarly to the previous case, if such constraint cannot 520 be taken into account by the PCE, this should trigger an Error 521 message. 523 For each PCEP message type a set of rules is defined which specifies 524 the set of possible objects that the message can carry. We use the 525 Backus-Naur Form (BNF) to specify such rules. Square brackets refer 526 to optional sub-sequences. An implementation MUST form the PCEP 527 messages using the order specified in this document. 529 6.1. Common header 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Ver | Flags | Message-Type | Reserved | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Message-Lenght | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 6: PCEP message common header 539 Ver (Version - 4 bits): PCEP protocol version number. Current 540 version is version 1. 542 Flags (8 bits): no flags are currently defined. 544 Message-Type (8 bits): 546 The following message types are currently defined (to be confirmed by 547 IANA). 548 Value Meaning 549 1 Open 550 2 Keepalive 551 3 Path Computation Request 552 4 Path Computation Reply 553 5 Notification 554 6 Error 555 7 Close 556 Message Length (32 bits): total length of the PCEP message expressed 557 in bytes including the common header. 559 6.2. Open message 561 The Open message is a PCEP message sent by a PCC to a PCE in order to 562 establish a PCEP session. The Message-Type field of the PCEP common 563 header for the Open message is set to 1 (To be confirmed by IANA). 565 Once the TCP connection has been successfully established, the first 566 message sent by the PCC to the PCE or by the PCE to the PCC MUST be 567 an Open message. Any message received prior to an OPEN message MUST 568 trigger a protocol error condition and the PCEP session MUST be 569 terminated. The Open message is used to establish a PCEP session 570 between the PCEP peers. During that phase the PCEP peers exchange 571 several session characteristics. If both parties agree on such 572 characteristics the PCEP session is successfully established. 574 Open message 575 ::= 576 577 The Open message MUST contain exactly one OPEN object (see 578 Section 7.2). Various session characteristics are specified within 579 the OPEN object. 581 Once an Open message has been sent to a PCEP peer, the sender MUST 582 start an initialization timer called InitOpen after the expiration of 583 which a similar Open message MUST be resent if no reply has been 584 received from the PCEP peer. The InitOpen timer has a fixed value of 585 1 minute. The maximum number of Open messages named MaxRetryOpen 586 that can be sent without any response from the PCEP peer is equal to 587 3. 589 Upon the receipt of an Open message, the receiving PCEP peer MUST 590 determine whether the suggested PCEP session characteristics are 591 acceptable. If at least one of the characteristic(s) is not 592 acceptable by the receiving peer, it MUST send an Error message. The 593 Error message SHOULD also contain the related Open object: for each 594 unacceptable session parameter, an acceptable parameter value SHOULD 595 be proposed in the appropriate field of the Open object in place of 596 the originally proposed value. The PCEP peer MAY decide to resend an 597 Open message with different session characteristics. If a second 598 Open message is received with the same set of parameters or with 599 parameters that are still unacceptable, the receiving peer MUST send 600 an Error message and it MUST immediately close the TCP connection. 601 Details about error message can be found in Section 7.14. 603 If the PCEP session characteristics are acceptable, the receiving 604 PCEP peer MUST consequently send a Keepalive message (defined in 605 Section 6.3) that would serve as acknowledgment. 607 The PCEP session is considered as established once both PCEP peers 608 have received a Keepalive message from their peer. 610 6.3. Keepalive message 612 A Keepalive message is a PCEP message sent by a PCC or a PCE in order 613 to keep the session in active state. The Message-Type field of the 614 PCEP common header for the Keepalive message is set to 2 (To be 615 confirmed by IANA). The Keepalive message does not contain any 616 object. 618 Keepalive: PCEP has its own keepalive mechanism used to ensure of the 619 liveness of the PCEP session. This requires the determination of the 620 frequency at which each PCEP peer sends keepalive messages. 621 Asymmetric values may be chosen; thus there is no constraints 622 mandating the use of identical keepalive frequencies by both PCEP 623 peers. The DeadTimer is defined as the period of time after the 624 expiration of which a PCEP peer declares the session down if no PCEP 625 message has been received (keepalive or any other PCEP message: thus, 626 any PCEP message acts as a keepalive message). Similarly, there is 627 no constraints mandating the use of identical DeadTimers by both PCEP 628 peers. The minimum KeepAliveTimer value is 1 second. 630 Keepalive messages are used either to acknowledge an Open message if 631 the receiving PCEP peer agrees on the session characteristics and to 632 ensure the liveness of the PCEP session. Keepalive messages are sent 633 at the frequency specified in the OPEN object carried within an Open 634 message. Because any PCEP message may serve as Keepalive an 635 implementation may either decide to send Keepalive messages at the 636 same frequency regardless on whether other PCEP messages might have 637 been sent since the last sent Keepalive message or may decide to 638 differ the sending of the next Keepalive message based on the time at 639 which the last PCEP message (other than Keepalive) was sent. 641 Keepalive message 642 ::= 644 6.4. Path Computation Request (PCReq) message 646 A Path Computation Request message (also referred to as a PCReq 647 message) is a PCEP message sent by a PCC to a PCE so as to request a 648 path computation. The Message-Type field of the PCEP common header 649 for the PCReq message is set to 3 (To be confirmed by IANA). 651 There are two mandatory objects that MUST be included within a PCReq 652 message: the RP and the END-POINTS objects (see section 7). If one 653 of these objects is missing, the receiving PCE MUST send an error 654 message to the requester. Other objects are optional. 656 The format of a PCReq message is as follows: 657 ::= 658 [] 659 661 where: 662 ::=[] 663 ::=[] 665 ::= 666 [] 667 [] 668 [] 669 [] 670 [] 671 [] 672 [] 673 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, and IRO 674 objects are defined in Section 7. The special case of two BANDWIDTH 675 objects in details inSection 7.6. 677 6.5. Path Computation Reply (PCRep) message 679 The PCEP Path Computation Reply message (also referred to as a PCRep 680 message) is a PCEP message sent by a PCE to a requesting PCC in 681 response to a previously received PCReq message. The Message-Type 682 field of the PCEP common header is set to 4 (To be confirmed by 683 IANA). 685 The PCRep message MUST contain at least one RP object. For each 686 reply that is bundled into a single PCReq message, an RP object MUST 687 be included that contains a Request-ID-number identical to the one 688 specified in the RP object carried in the corresponding PCReq message 689 (see Section 7.3for the definition of the RP object). 691 A PCRep may comprise multiple computed path(s) corresponding to 692 multiple path computation requests originated by a common requesting 693 PCC and/or to multiple acceptable paths corresponding to the same 694 request. The bundling of multiple responses within a single PCRep 695 message is supported by the PCEP protocol. If a PCE receives non- 696 synchronized path computation requests by means of one or more PCReq 697 messages from a requesting PCC it may decide to bundle the computed 698 paths within a single PCRep message so as to reduce the control plane 699 load. Note that the counter side of such an approach is the 700 introduction of additional delays for some path computation requests 701 of the set. Conversely, a PCE that receives multiple requests within 702 the same PCReq message, may decide to reply each path in separate 703 PCRep messages. 705 If the path computation request can be successfully satisfied (the 706 PCE manages to compute a set of path(s) that obey the requested 707 constraint(s)), the set of computed path(s) specified by means of ERO 708 object(s) is inserted in the PCRep message. The ERO object is 709 defined in Section 7.8. Such a situation where multiple computed 710 paths are provided in a PCRep message is discussed in detail in 711 Section 7.12. 713 If the path computation request cannot be satisfied, the PCRep 714 message MUST include a NO-PATH object. The NO-PATH object (further 715 described in Section 7.4) may also comprise other information (e.g 716 reasons for the path computation failure). 718 The format of a PCRep message is as follows: 719 ::= 720 [] 721 723 where: 724 ::=[] 725 ::=[] 727 ::= 728 [] 729 [] 731 ::=[] 733 ::= 734 [] 735 [] 736 [] 737 [] 739 6.6. Notification (PCNtf) message 741 The PCEP Notification message (also referred to as the PCNtf message) 742 can either be sent by a PCE to a PCC or by a PCC to a PCE so as to 743 notify of a specific event. The Message-Type field of the PCEP 744 common header is set to 5 (To be Confirmed by IANA). 746 The PCNtf message MUST carry at least one NOTIFICATION object and may 747 contain several NOTIFICATION objects should the PCE or the PCC intend 748 to notify of multiple events. The NOTIFICATION object is defined in 749 Section 7.13. The PCNtf message may also contain an RP object (see 750 Section 7.3when the notification refers to a particular path 751 computation request. 753 The PCNtf message may be sent by a PCC or a PCE in response to a 754 request or in an unsolicited manner. 756 The format of a PCNtf message is as follows: 757 ::= 758 760 ::= [] 762 ::= [] 763 765 :== 767 := 769 6.7. Error (PCErr) Message 771 The PCEP Error message (also referred to as a PCErr message) is sent 772 when a protocol error condition is met. The Message-Type field of 773 the PCEP common header is set to 6. 775 The PCErr message may be sent by a PCC or a PCE in response to a 776 request or in an unsolicited manner. In the former case, the PCErr 777 message MUST include the set of RP objects related to the pending 778 path computation request(s) which triggered the protocol error 779 condition. In the later case (unsolicited), no RP object is inserted 780 within the PCErr message. No RP object is inserted in a PCErr when 781 the error condition occurred during the initialization phase. A 782 PCErr message MUST comprise a PCEP-ERROR object specifying the PCEP 783 error condition. The PCEP-ERROR object is defined in section 784 Section 7.14. 786 The format of a PCErr message is as follows: 787 ::= 788 789 [] 791 :==[] 792 ::=[] 793 795 :==[] 797 :==[] 798 The procedure upon the reception of a PCErr message is defined in 799 Section 7.14. 801 6.8. Close message 803 The Close message is a PCEP message sent by either a PCC to a PCE or 804 by a PCE to a PCC in order to close a PCEP session. The Message-Type 805 field of the PCEP common header for the Open message is set to 7 (To 806 be confirmed by IANA). 808 Close message 809 ::= 810 811 The Close message MUST contain exactly one CLOSE object (see 812 Section 6.8). 814 Upon the receipt of a Close message, the receiving PCEP peer MUST 815 cancel all pending requests and MUST close the TCP connection. 817 7. Object Formats 819 7.1. Common object header 820 A PCEP object carried within a PCEP message consists of one or more 821 32-bit words with a common header which has the following format: 822 0 1 2 3 823 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 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Object-Class | OT |Res|P|I| Object Length (bytes) | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | | 828 // (Object body) // 829 | | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Figure 8: PCEP common object header 834 Object-Class (8 bits): identifies the PCEP object class. 836 OT (Object-Type - 4 bits): identifies the PCEP object type. 838 The Object-Class and Object-Type are managed by IANA. 840 The Object-Class and Object-Type fields uniquely identify each PCEP 841 object. 843 Res (3 bits): Reserved. 845 P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify 846 in a PCReq message sent to a PCE whether the object must be taken 847 into account by the PCE during path computation or is just optional. 848 When the P flag is set, the object MUST be taken into account by the 849 PCE. Conversely, when the P flag is cleared, the object is optional 850 and the PCE is free to ignore it if not supported. 852 I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep 853 message to indicate to a PCC whether or not an optional object was 854 processed. The PCE MAY include the ignored optional object in its 855 reply and set the I flag to indicate that the optional object was 856 ignored during path computation. When the I flag is cleared, the PCE 857 indicates that the optional object was processed during the path 858 computation. The setting of the I flag for optional objects is 859 purely indicative and optional. The I flag MUST be cleared if the P 860 flag is set. 862 If the PCE does not understand an object with the P Flag set or 863 understands the object but decides to ignore the object, the entire 864 PCEP message MUST be rejected and the PCE MUST send a PCErr message 865 with Error-Type="Unknown Object" or "Not supported Object". 867 Res flags (2 bits). Reserved field (MUST be set to 0). 869 Object Length (16 bits). Specifies the total object length including 870 the header, in bytes. The Object Length field MUST always be a 871 multiple of 4, and at least 4. The maximum object content length is 872 65528 bytes. 874 7.2. OPEN object 876 The OPEN object MUST be present in each Open message and may be 877 present in PCErr message. There MUST be only one OPEN object per 878 Open or PCErr message. 880 The OPEN object contains a set of fields used to specify the PCEP 881 protocol version, Keepalive frequency, PCEP session ID along with 882 various flags. The OPEN object may also contain a set of TLVs used 883 to convey various session characteristics such as the detailed PCE 884 capabilities, policy rules and so on. No such TLV is currently 885 defined. 887 OPEN Object-Class is to be assigned by IANA (recommended value=1) 889 OPEN Object-Type is to be assigned by IANA (recommended value=1) 891 The format of the OPEN object body is as follows: 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Ver | Keepalive | Deadtimer | SID | Flags | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | | 898 // Optional TLV(s) // 899 | | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 Figure 9: OPEN Object format 903 Ver (Ver - 3 bits): PCEP version. Current version is 1. 905 Keepalive (8 bits): minimum period of time (in seconds) between the 906 sending of PCEP messages that the sender of the Open message will 907 send Keepalive messages. The minimum value for the Keepalive is 1 908 second. When set to 0, once the session is established, no further 909 keepalives need to be sent to the remote peer. A RECOMMENDED value 910 for the keepalive frequency is 30 seconds. 912 DeadTimer (8 bits): specifies the amount of time after the expiration 913 of which a PCEP peer declares the session with the sender of the Open 914 message down if no PCEP message has been received. The DeadTimer 915 MUST be set to 0 if the Keepalive is set to 0. A RECOMMENDED value 916 for the DeadTimer is 4 times the value of the Keepalive. 918 SID (PCEP session-ID - 8 bits): specifies a 2 octet unsigned PCEP 919 session number that identifies the current session. The SID MUST be 920 incremented each time a new PCEP session is established and is mainly 921 used for logging and troubleshooting purposes. 923 Flags (5 bits): No Flags are currently defined. 925 Optional TLVs may be included within the OPEN object body to specify 926 PCC or PCE characteristics. The specification of such TLVs is 927 outside the scope of this document. 929 When present in an Open message, the OPEN object specifies the 930 proposed PCEP session characteristics. Upon receiving unacceptable 931 PCEP session characteristics during the PCEP session initialization 932 phase, the receiving PCEP peer (PCE), may include a PCEP object 933 within the PCErr message so as to propose alternative session 934 characteristic values. 936 7.3. RP Object 938 The RP (Request Parameters) object MUST be carried within each PCReq 939 and PCRep messages and MAY be carried within PCNtf and PCErr 940 messages. The P flag of the RP object MUST be set. The RP object is 941 used to specify various characteristics of the path computation 942 request. 944 7.3.1. Object definition 946 RP Object-Class is to be assigned by IANA (recommended value=2) 948 RP Object-Type is to be assigned by IANA (recommended value=1) 949 The format of the RP object body is as follows: 950 0 1 2 3 951 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 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Reserved | Flags |N|O|B|R| Pri | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Request-ID-number | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | | 958 // Optional TLV(s) // 959 | | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 Figure 10: RP object body format 964 The RP object body has a variable length and may contain additional 965 TLVs. No TLV is currently defined. 967 Flags: 18 bits - The following flags are currently defined: 969 Pri (Priority - 3 bits): the Priority field may be used by the 970 requesting PCC to specify to the PCE the request's priority from 1 to 971 7. The decision of which priority should be used for a specific 972 request is of a local matter and MUST be set to 0 when unused. 973 Furthermore, the use of the path computation request priority by the 974 PCE's requests scheduler is implementation specific and out of the 975 scope of this document. Note that it is not required for a PCE to 976 support the priority field: in that case, the priority field 977 RECOMMENDED be set to 0 by the PCC in the RP object. If the PCE does 978 not take into account the request priority, it is RECOMMENDED to set 979 the priority field to 0 in the RP object carried within the 980 corresponding PCRep message, regardless of the priority value 981 contained in the RP object carried within the corresponding PCReq 982 message. A higher numerical value of the priority field reflects a 983 higher priority. Note that it is the responsibility of the network 984 administrator to make use of the priority values in a consistent 985 manner across the various PCC(s). The ability of a PCE to support 986 requests prioritization may be dynamically discovered by the PCC(s) 987 by means of PCE capability discovery. If not advertised by the PCE, 988 a PCC may decide to set the request priority and will learn the 989 ability of the PCE the support request prioritization by observing 990 the Priority field of the RP object received in the PCRep message. 991 If the value of the Pri field is set to 0, this means that the PCE 992 does not support the handling of request priorities: in other words, 993 the path computation request has been honoured but without taking the 994 request priority into account. 996 R (Reoptimization - 1 bit): when set, the requesting PCC specifies 997 that the PCReq message relates to the reoptimization of an existing 998 TE LSP in which case the path of the existing TE LSP to be 999 reoptimized MUST be provided in the PCReq (except of 0-bandwidth TE 1000 LSP) message by means of an RRO object defined in Section 7.9. 1002 B (Bi-directional - 1 bit): when set, the PCC specifies that the path 1003 computation request relates to a bidirectional TE LSP that has the 1004 same traffic engineering requirements including fate sharing, 1005 protection and restoration, LSRs, and resource requirements (e.g. 1006 latency and jitter) in each direction. When cleared, the TE LSP is 1007 unidirectional. 1009 O (strict/lOose - 1 bit): when set, in a PCReq message, this 1010 indicates that a strict/loose path is acceptable. Otherwise, when 1011 cleared, this indicates to the PCE that an explicit path is required. 1012 In a PCRep message, when the O bit is set this indicates that the 1013 returned path is strict/loose, otherwise (the O bit is cleared), the 1014 returned path is explicit. 1016 F (new - 1 bit): when set, the requesting PCC requires the 1017 computation of a new path for a TE LSP that has failed in which case 1018 the path of the existing TE LSP MUST be provided in the PCReq (except 1019 of 0-bandwidth TE LSP) message by means of an RRO object defined in 1020 Section 7.9. This is to avoid double bandwidth booking should the 1021 TED not be yet updated or the corresponding resources not be yet 1022 released. 1024 Request-ID-number (32 bits). The Request-ID-number value combined 1025 with the source IP address of the PCC and the PCE address uniquely 1026 identify the path computation request context. The Request-ID-number 1027 MUST be incremented each time a new request is sent to the PCE. If 1028 no path computation reply is received from the PCE, and the PCC 1029 wishes to resend its request, the same Request-ID-number MUST be 1030 used. Conversely, different Request-ID-number MUST be used for 1031 different requests sent to a PCE. The same Request-ID-number may be 1032 used for path computation requests sent to different PCEs. The path 1033 computation reply is unambiguously identified by the IP source 1034 address of the replying PCE. 1036 7.3.2. Handling of the RP object 1038 If a PCReq message is received without containing an RP object, the 1039 PCE MUST send a PCErr message to the requesting PCC with Error- 1040 type="Required Object missing" and Error-value="RP Object missing". 1042 If the C bit of the RP message carried within a PCReq message is set 1043 and local policy has been configured on the PCE to not provide the 1044 computed path cost, a PCErr message MUST be sent by the PCE to the 1045 requesting PCC and the pending path computation request MUST be 1046 discarded. The Error-type is "Policy Violation" and Error-value is 1047 "C bit set". 1049 If the O bit of the RP message carried within a PCReq message is set 1050 and local policy has been configured on the PCE to not provide 1051 explicit path(s) (for instance, for confidentiality reasons), a PCErr 1052 message MUST be sent by the PCE to the requesting PCC and the pending 1053 path computation request MUST be discarded. The Error-type is 1054 "Policy Violation" and Error-value is "O bit set". 1056 R bit: when the R bit of the RP object is set in a PCReq message, 1057 this indicates that the path computation request relates to the 1058 reoptimization of an existing TE LSP. In this case, the PCC MUST 1059 provide the explicit or strict/loose path by including an RRO object 1060 in the PCReq message so as to avoid double bandwidth counting if and 1061 only if the TE LSP is a non 0-bandwidth TE LSP. If the PCC has 1062 previously requested a non-explicit path (O bit set), a 1063 reoptimization can still be requested by the PCC but this implies for 1064 the PCE to be either stateful (keep track of the previously computed 1065 path with the associated list of strict hops) or to have the ability 1066 to retrieve the complete required path segment. Alternatively the 1067 PCC MUST be able to inform PCE of the working path with associated 1068 list of strict hops in PCReq. The absence of an RRO in the PCReq 1069 message for a non 0-bandwidth TE LSP when the R bit of the RP object 1070 is set MUST trigger the sending of a PCErr message with Error- 1071 type="Required Object Missing" and Error-value="RRO Object missing 1072 for reoptimization". 1074 If the PCC receives a PCRep message that contains a RP object 1075 referring to an unknown Request-ID-Number, the PCC MUST send a PCErr 1076 message with Error-Type="Unknown request reference". 1078 7.4. NO-PATH Object 1080 The No-PATH object is used in PCRep messages in response to a path 1081 computation request that was unsuccessful (the PCE could not find a 1082 path satisfying the set of constraints). When a PCE cannot find a 1083 path satisfying a set of constraints, it MUST include a NO-PATH 1084 object in the PCRep message. In its simplest form, the NO-PATH 1085 object is limited to a set of flags and just reports the 1086 impossibility to find a path that satisfies the set of constraints. 1087 Optionally, if the PCE supports such capability, the PCRep message 1088 MAY also contain a list of objects that specify the set of 1089 constraints that could not be satisfied. The PCE MAY just replicate 1090 the object that was received that was the cause of the unsuccessful 1091 computation or MAY optionally report a suggested value for which a 1092 path could have been found. 1094 NO-PATH Object-Class is to be assigned by IANA (recommended value=3) 1096 NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 1098 The format of the NO-PATH object body is as follows: 1099 0 1 2 3 1100 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 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 |C| Flags | Reserved | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 Figure 11: NO-PATH object format 1106 The NO-PATH object body has a fixed length of 4 octets. 1108 Flags (16 bits). The following flags are currently defined: 1110 C flag (1 bit): when set, the PCE indicates the set of unsatisfied 1111 constraints (reasons why a path could not be found) in the PCRep 1112 message by including the relevant PCEP objects. When cleared, no 1113 reason is specified. 1115 Example: consider the case of a PCC that sends a path computation 1116 request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot 1117 find a path for X MBits/s. In this case, the PCE must include in the 1118 PCRep message a NO-PATH object. Optionally the PCE may also include 1119 the original BANDWIDTH object so as to indicate that the reasons for 1120 the unsuccessful computation is the bandwidth constraint (in this 1121 case, the C flag is set). If the PCE supports such capability it may 1122 alternatively include the BANDWIDTH Object and report a value of Y in 1123 the bandwidth field of the BANDWIDTH object (in this case, the C flag 1124 is set). 1126 When the NO-PATH object is absent from a PCRep message, the path 1127 computation request has been fully satisfied and the corresponding 1128 path(s) is/are provided in the PCRep message. 1130 7.5. END-POINT Object 1132 The END-POINTS object is used in a PCReq message to specify the 1133 source IP address and the destination IP address of the path for 1134 which a path computation is requested. Note that the source and 1135 destination addresses specified in the END-POINTS object may or may 1136 not correspond to the source and destination IP address of the TE LSP 1137 but rather to a path segment. Two END-POINTS objects (for IPv4 and 1138 IPv6) are defined. 1140 END-POINTS Object-Class is to be assigned by IANA (recommended 1141 value=4) 1142 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 1143 for IPv4 and 2 for IPv6) 1145 The format of the END-POINTS object body for IPv4 (Object-Type=1) is 1146 as follows: 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Source IPv4 address | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Destination IPv4 address | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 Figure 12: END-POINTS object body format for IPv4 1158 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 1160 0 1 2 3 1161 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 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | | 1164 | Source IPv6 address (16 bytes) | 1165 | | 1166 | | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | | 1169 | Destination IPv6 address (16 bytes) | 1170 | | 1171 | | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 Figure 13: END-POINTS object body format for IPv6 1176 The END-POINTS object body has a fixed length of 8 octets for IPv4 1177 and 32 octets for IPv6. 1179 7.6. BANDWIDTH Object 1181 The BANDWIDTH object is optional and can be used to specify the 1182 requested bandwidth for a TE LSP. In the case of a non existing TE 1183 LSP, the BANDWIDTH object MUST be included in the PCReq message so as 1184 to specify the required bandwidth for the new TE LSP. In the case of 1185 the reoptimization of an existing TE LSP, the bandwidth of the 1186 existing TE LSP MUST also be included in addition to the requested 1187 bandwidth if and only if the two values differ. Consequently, two 1188 Object-Type are defined that refer to the requested bandwidth and the 1189 bandwidth of a existing TE LSP for which a reoptimization is being 1190 performed. 1192 The BANDWIDTH object may be carried within PCReq and PCRep messages. 1193 The absence of the BANDWIDTH object MUST be interpreted by the PCE as 1194 a path computation request related to a 0 bandwidth TE LSP. 1196 BANDWIDTH Object-Class is to be assigned by IANA (recommended 1197 value=5) 1199 Two Object-Type are defined for the BANDWIDTH object: 1201 o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by 1202 IANA (recommended value=1) 1204 o Bandwidth of an existing TE LSP for which a reoptimization is 1205 performed. BANDWIDTH Object-Type is to be assigned by IANA 1206 (recommended value=2) 1208 The format of the BANDWIDTH object body is as follows: 1209 0 1 2 3 1210 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 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Bandwidth | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 Figure 14: BANDWIDTH object body format 1216 Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in 1217 IEEE floating point format, expressed in bytes per second. 1219 The BANDWIDTH object body has a fixed length of 4 octets. 1221 7.7. METRIC Object 1223 The METRIC object is optional and can be used for several purposes. 1225 In a PCReq message, a PCC MAY insert a METRIC object: 1227 o To indicate the metric that must be optimized by the path 1228 computation algorithm. Currently, two metrics are defined: the 1229 IGP cost and the TE metric (see [RFC3785]). 1231 o To indicate a bound on the path cost than must not be exceeded for 1232 the path to be considered as acceptable by the PCC. 1234 In a PCRep message, the METRIC object MAY be inserted so as to 1235 provide the cost for the computed path. It MAY also be inserted 1236 within a PCRep with the NO-PATH object, to indicate that the metric 1237 constraint could not be satisfied. 1239 The path computation algorithmic aspects used by the PCE to optimize 1240 a path with respect to a specific metric are outside the scope of 1241 this document. 1243 It must be understood that such path metric is only meaningful if 1244 used consistently: for instance, if the delay of a path computation 1245 segment is exchanged between two PCE residing in different domains, 1246 consistent ways of defining the delay must be used. 1248 The absence of the METRIC object MUST be interpreted by the PCE as a 1249 path computation request for which the PCE may choose the metric to 1250 be used. 1252 METRIC Object-Class is to be assigned by IANA (recommended value=6) 1254 METRIC Object-Type is to be assigned by IANA (recommended value=1) 1256 The format of the METRIC object body is as follows: 1257 0 1 2 3 1258 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Reserved | Flags |C|B| T | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | metric-value | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 Figure 15: METRIC object body format 1267 T (Type - 3 bits): Specifies the metric type. Two values are 1268 currently defined: 1270 o T=1: The IGP metric 1272 o T=2: The TE cost 1274 B (Bound - 1 bit): When set in a PCReq message, the metric-value 1275 indicates a bound (a maximum) for the path cost that must not be 1276 exceeded for the PCC to consider the computed path as acceptable. 1277 When the B flag is cleared, the metric-value field MUST be set to 1278 0x0000. In a PCReq message, if the B-flag is cleared, then the 1279 metric-value field MUST be set to 0. The B flag MUST always be 1280 cleared in a PCRep message. 1282 C (Cost - 1 bit): When set in a PECReq message, this indicates that 1283 the PCE MUST provide the computed path cost (should a path satisfying 1284 the constraints be found) in the PCRep message with regards to the 1285 corresponding metric. 1287 Metric-value (32 bits): metric value encoded in 32 bits in IEEE 1288 floating point format. 1290 The METRIC object body has a fixed length of 8 octets. 1292 Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq 1293 message. 1295 In a PCReq message the presence of multiple METRIC object can be used 1296 to specify a multi-parameters (e.g. a metric may be a constraint or a 1297 parameter to minimize/maximize) objective function or multiple bounds 1298 for different constraints. 1300 In a PCRep message, unless not allowed by PCE policy, at least one 1301 METRIC object MUST be present that reports the computed path cost if 1302 the C bit of the RP object was set in the corresponding path 1303 computation request (the B-flag MUST be cleared); optionally the 1304 PCRep message may contain additional METRIC objects that correspond 1305 to bound constraints, in which case the metric-value MUST be equal to 1306 the corresponding path metric cost (the B-flag MUST be set). If no 1307 path satisfying the constraints could be found by the PCE, the METRIC 1308 objects MAY also be present in the PCRep message with the NO-PATH 1309 object, to indicate a constraint metric (B-Flag was set in the path 1310 computation request) that cannot be satisfied. 1312 Example: if a PCC sends a path computation request to a PCE where the 1313 metric to optimize is the IGP metric and the TE metric must not 1314 exceed the value of M, two METRIC object are inserted in the PCReq 1315 message: 1317 o First METRIC Object with B=0, T=1, metric-value=0x0000 1319 o Second METRIC Object with B=1, T=2, metric-value=M 1321 If a path satisfying the set of constraints can be found by the PCE 1322 and no policy preventing to provide the path cost in place, the PCE 1323 inserts one METRIC object with B=0, T=1, metric-value= computed IGP 1324 path cost. Additionally, the PCE may insert a second METRIC object 1325 with B=1, T=2, metric-value= computed TE path cost. 1327 7.8. ERO Object 1329 The ERO object is used to encode a TE LSP. The ERO Object is carried 1330 within a PCRep message to provide the computed TE LSP should have the 1331 path computation been successful. 1333 The contents of this object are identical in encoding to the contents 1334 of the Explicit Route Object defined in [RFC3209], [RFC3473] and 1336 [RFC3477]. That is, the object is constructed from a series of sub- 1337 objects. Any RSVP ERO sub-object already defined or that could be 1338 defined in the future for use in the ERO is acceptable in this 1339 object. 1341 PCEP ERO sub-object types correspond to RSVP ERO sub-object types. 1343 Since the explicit path is available for immediate signaling by the 1344 MPLS or GMPLS control plane, the meanings of all of the sub-objects 1345 and fields in this object are identical to those defined for the ERO. 1347 ERO Object-Class is to be assigned by IANA (recommended value=7) 1349 ERO Object-Type is to be assigned by IANA (recommended value=1) 1351 7.9. RRO Object 1353 The RRO object is used to record the route followed by a TE LSP. The 1354 PCEP RRO object is exclusively carried within a PCReq message so as 1355 to specify the route followed by a TE LSP for which a reoptimization 1356 is desired. 1358 The contents of this object are identical in encoding to the contents 1359 of the Route Record Object defined in [RFC3209], [RFC3473] and 1360 [RFC3477]. That is, the object is constructed from a series of sub- 1361 objects. Any RSVP RRO sub-object already defined or that could be 1362 defined in the future for use in the RRO is acceptable in this 1363 object. 1365 The meanings of all of the sub-objects and fields in this object are 1366 identical to those defined for the RRO. 1368 PCEP RRO sub-object types correspond to RSVP RRO sub-object types. 1370 RRO Object-Class is to be assigned by IANA (recommended value=8) 1372 RRO Object-Type is to be assigned by IANA (recommended value=1) 1374 7.10. LSPA Object 1376 The LSPA object is optional and specifies various TE LSP attributes 1377 to be taken into account by the PCE during path computation. The 1378 LSPA (LSP Attributes) object can either be carried within a PCReq 1379 message or a PCRep message in case of unsuccessful path computation 1380 (in this case, the PCRep message also comprises a NO-PATH object and 1381 the LSPA object is used to indicate the set of constraint(s) that 1382 could not be satisfied). Most of the fields of the LSPA object are 1383 identical to the fields of the SESSION-ATTRIBUTE object defined in 1385 [RFC3209] and [RFC4090]. When absent from the PCReq message, this 1386 means that the Setup and Holding priorities are equal to 0, and there 1387 are no affinity constraints. 1389 LSPA Object-Class is to be assigned by IANA (recommended value=9) 1391 Two Objects-Types are defined for the LSPA object: LSPA without 1392 resource affinity (Object-Type to be assigned by IANA with 1393 recommended value=1) and LSPA with resource affinity (Object-type=2). 1395 The format of the LSPA object body with and without resource affinity 1396 are as follows: 1397 0 1 2 3 1398 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 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Setup Prio | Holding Prio | Flags |L| Reserved | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | | 1403 // Optional TLV(s) // 1404 | | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 Figure 16: LSPA object body format (without resource affinity) 1409 0 1 2 3 1410 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 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | Exclude-any | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | Include-any | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Include-all | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | Setup Prio | Holding Prio | Flags |L| Reserved | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | | 1421 // Optional TLV(s) // 1422 | | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 Figure 17: LSPA object body format (with resource affinity) 1427 Setup Prio (Setup Priority - 8 bits). The priority of the session 1428 with respect to taking resources, in the range of 0 to 7. The value 1429 0 is the highest priority. The Setup Priority is used in deciding 1430 whether this session can preempt another session. 1432 Holding Prio (Holding Priority - 8 bits). The priority of the 1433 session with respect to holding resources, in the range of 0 to 7. 1434 The value 0 is the highest priority. Holding Priority is used in 1435 deciding whether this session can be preempted by another session. 1436 Flags 1438 The flag L corresponds to the "Local protection desired" bit 1439 ([RFC3209]) of the SESSION-ATTRIBUTE Object. 1441 L Flag (Local protection desired). When set, this means that the 1442 computed path must include links protected with Fast Reroute as 1443 defined in [RFC4090]. 1445 7.11. IRO Object 1447 The IRO (Include Route Object) object is optional and can be used to 1448 specify that the computed path must traverse a set of specified 1449 network elements. The IRO object may be carried within PCReq and 1450 PCRep messages. When carried within a PCRep message with the NO-PATH 1451 object, the IRO indicates the set of elements that could not be 1452 included. 1454 IRO Object-Class is to be assigned by IANA (recommended value=10) 1456 IRO Object-Type is to be assigned by IANA (recommended value=1) 1458 0 1 2 3 1459 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 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | | 1462 // (Subobjects) // 1463 | | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 Figure 18: IRO object body format 1467 Subobjects The IRO object is made of sub-object(s) identical to the 1468 ones defined in [RFC3209], [RFC3473] and [RFC3477] for use in EROs. 1470 The following subobject types are supported. 1472 Type Subobject 1473 1 IPv4 prefix 1474 2 IPv6 prefix 1475 4 Unnumbered Interface ID 1476 32 Autonomous system number 1477 The L bit of such sub-object has no meaning within an IRO object. 1479 7.12. SVEC Object 1481 7.12.1. Independent versus synchronized path computation requests 1483 The PCEP protocol allows for the bundling of multiple independent 1484 path computation requests within a single PCRep message. A set of 1485 path computation requests is said to be non synchronized if their 1486 respective treatment (path computations) can be performed by a PCE in 1487 a serialized and independent fashion. 1489 There are various circumstances where the synchronization of a set of 1490 path computations may be beneficial or required. 1492 Consider the case of a set of N TE LSPs for which a PCC needs to send 1493 path computation requests to a PCE. The first solution consists of 1494 sending N separate PCReq messages to the selected PCE. In this case, 1495 the path computation requests are independent. Note that the PCC may 1496 chose to distribute the set of N requests across K PCEs for load 1497 balancing reasons. Considering that M (with M+-+-+-+-+-+-+ | | 2101 | | | KeepWait |----+ | 2102 | +--| |<---+ | 2103 |+-----+-+-+-+-+-+-+ | | 2104 || | | | 2105 || | | | 2106 || V | | 2107 || +->+-+-+-+-+-+-+----+ | 2108 || | | OpenWait |-------+ 2109 || +--| |<------+ 2110 ||+----+-+-+-+-+-+-+<---+ | 2111 ||| | | | 2112 ||| | | | 2113 ||| V | | 2114 ||| +->+-+-+-+-+-+-+ | | 2115 ||| | |TCPPending |----+ | 2116 ||| +--| | | 2117 |||+---+-+-+-+-+-+-+<---+ | 2118 |||| | | | 2119 |||| | | | 2120 |||| V | | 2121 |||+--->+-+-+-+-+ | | 2122 ||+---->| Idle |-------+ | 2123 |+----->| |----------+ 2124 +------>+-+-+-+-+ 2126 Figure 15: PCEP Finite State Machine for the PCC 2128 PCEP defines the following set of variables: 2130 TCPConnect: timer (in seconds) started after having initialized a TCP 2131 connection using the PCEP well-known TCP port. The value of the 2132 TCPConnect timer is 60 seconds. TCPRetry: specifies the number of 2133 times the system has tried to establish a TCP connection with a PCEP 2134 peer without success. TCPMaxRetry: Maximum number of times the 2135 system tries to establish a TCP connection using the PCEP well-known 2136 TCP port before going back to the Idle state. The value of the 2137 TCPMaxRetry is 5. OpenWait: timer (in seconds) that corresponds to 2138 the amount of time a PCEP peer will wait to receive an Open message 2139 from the PCEP peer after the expiration of which the system releases 2140 the PCEP resource and go back to the Idle state. KeepWait: timer (in 2141 seconds) that corresponds to the amount of time a PCEP peer will wait 2142 to receive a KeepAlive or a PCErr message from the PCEP peer after 2143 the expiration of which the system releases the PCEP resource and go 2144 back to the Idle state. OpenRetry: specifies the number of times the 2145 system has received an Open message with unacceptable PCEP session 2146 characteristics. OpenMaxRetry: Maximum number of times the system 2147 can receive an Open message with unacceptable PCEP sessions 2148 characteristics before releasing the PCEP session with that peer and 2149 go back to Idle state. The value of the OpenMaxRetry is 3. The 2150 following two states variable are defined: 2152 RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system 2153 has received an acceptable Open message. LocalOK: the LocalOK 2154 variable is a Boolean set to 1 if the system has received a Keepalive 2155 message acknowledging that the Open message sent to the peer was 2156 valid. 2158 Idle State: 2160 The idle state is the initial PCEP state where PCEP (also referred to 2161 as "the system") waits for an initialization event that can either be 2162 manually triggered by the user (configuration) or automatically 2163 triggered by various events. In Idle state, PCEP resources are 2164 allocated (memory, potential process, ...) but no PCEP messages are 2165 accepted from any PCEP peer. The system listens the well-known PCEP 2166 TCP port. 2168 The following set of variable are initialized: 2170 TCPRetry=0, 2172 LocalOK=0, 2174 RemoteOK=0, 2176 Upon detection of a local initialization event (e.g. user 2177 configuration to establish a PCEP session with a particular PCEP 2178 peer, local event triggering the establishment of a PCEP session with 2179 a PCEP peer, ...), the system: 2181 o Starts the TCPConnect timer, 2183 o Initiates of a TCP connection with the PCEP peer, 2185 o Increments the TCPRetry variable, 2187 o Moves to the TCPPending state. 2189 Upon receiving a TCP connection on the well-known PCEP TCP port, if 2190 the TCP connection establishment succeeds, the system: 2192 o Sends an Open message 2194 o Starts the OpenWait timer 2196 o Moves to the OpenWait state 2198 It is expected that an implementation will use an exponentially 2199 increase timer between automatically generated Initialization events 2200 and between retrials of TCP connection establishments. 2202 TCPPending State 2204 If the TCP connection establishment succeeds, the system: 2206 o Sends an Open message, 2208 o Starts the OpenWait timer, 2210 o Starts the KeepWait timer, 2212 o Moves to the OpenWait state. 2214 If the TCP connection establishement fails (an error is detected 2215 during the TCP connection establishment) or the TCPConnectTimer 2216 expires: 2218 If TCPRetry =TCPMaxRetry the system moves to the Idle State 2220 If TCPRetry variable < TCPMaxRetry the system: 2222 o Starts the TCPConnect timer, 2224 o Initiates of a TCP connection with the PCEP peer, 2226 o Increments the TCPRetry variable. 2228 If the system detects that the PCEP peer tries to simultaneously 2229 establish a TCP connection, it stops the TCP connection establishment 2230 if and only if the PCEP peer has a higher IP address and moves to the 2231 Idle state. This guarantees that in case of "collision" a single TCP 2232 connection is established. 2234 OpenWait State: 2236 In the OpenWait state, the system waits for an Open message from its 2237 PCEP peer. 2239 If the system receives an Open message from the PCEP peer before the 2240 expiration of the OpenWait timer, PCEP checks the PCEP session 2241 attributes (Keepalive frequency, DeadTimer, ...). 2243 If an error is detected (malformed Open message, unsupported PCEP 2244 session characteristics), PCEP generates an error notification, 2245 release the PCEP resources for the PCEP peer, closes the TCP 2246 connection and moves to the Idle state. 2248 If no Open message is received before the expiration of the OpenWait 2249 timer, the system releases the PCEP resources for the PCEP peer, 2250 closes the TCP connection and moves to the Idle state. 2252 If no errors are detected and the session characteristics are 2253 acceptable to the local system, the system: 2255 o Sends a Keepalive message to the PCEP peer, 2257 o Starts the Keepalive timer, 2259 o Sets the RemoteOK variable to 1. 2261 If LocalOK=1 the system moves to the UP state 2263 If LocalOK=0 the system moves to the KeepWait state. 2265 If no errors are detected but there is a disagreement on the session 2266 characteristics (such as the Keepalive frequency or the DeadTimer), a 2267 PCErr message is sent to the peer (reporting the values for which a 2268 disagreement exists). 2270 If OpenRetry=OpenMaxRetry the system releases the PCEP resources for 2271 that peer amd moves back to the Idle state. 2273 If OpenRetry < OpenMaxRetry the system: 2275 o sends a PCErr message containing proposed acceptable session 2276 characteristics, 2278 o Increments the OpenRetry variable. 2280 KeepWait State 2282 In the Keepwait state, the system waits for the receipt of a 2283 Keepalive from its PCEP peer acknowledging its Open message or a 2284 PCErr message in response to unacceptable PCEP session 2285 characteristics proposed in the Open message. 2287 If a Keepalive message is received before the expiration of the 2288 KeepWait timer, LocalOK=1 2290 If RemoteOK=1, the system moves to the UP state. 2292 If RemoteOK=0, the system moves to the OpenWait State. 2294 If a PCErr message is received before the expiration of the KeepWait 2295 timer: 2297 1. If the proposed values are unacceptable, the sytem releases the 2298 PCEP resources for that PCEP peer, closes the TCP connection and 2299 moves to the Idle state. 2301 2. If the proposed values are acceptable, the sytem adjusts its PCEP 2302 session characteristics according to the proposed values received 2303 in the PCErr message restarts the KeepWait timer and sends a new 2304 Open message. If RemoteOK=1, the system stays in the KeepWait 2305 state. If RemoteOK=0, the system moves to the OpenWait state. 2307 If neither a Keepalive nor a PCErr is received after the expiration 2308 of the KeepWait timer, the system releases the PCEP resources for 2309 that PCEP peer, closes the TCP connection and moves to the Idle 2310 State. 2312 UP State 2314 In the UP state, the PCEP peer starts exchanging PCEP messages 2315 according to the session characteristics. 2317 If the Keepalive timer expires, the systens sends a Keepalive 2318 message. 2320 If no Keepalive message is received from the PCEP peer after the 2321 expiration of the DeadTimer, the systems sends a PCEP CLOSE message, 2322 releases the PCEP resources for that PCEP peer, closes the TCP 2323 connection and moves to the Idle State. 2325 In a malformed PCEP message is received or the TCP connection fails, 2326 the systems sends a PCEP CLOSE message, the system releases the PCEP 2327 resources for that PCEP peer, closes the TCP connection and moves to 2328 the Idle State. 2330 11. Security Considerations 2331 The PCEP protocol could be the target of the following attacks: 2333 o Spoofing (PCC or PCE impersonation) 2335 o Snooping (message interception) 2337 o Falsification 2339 o Denial of Service 2341 A PCEP attack may have significant impact, particularly in an 2342 inter-AS context as PCEP facilitates inter-AS path establishment. 2343 Several mechanisms are proposed below, so as to ensure 2344 authentication, integrity and privacy of PCEP Communications, and 2345 also to protect against DoS attacks. 2347 11.1. PCEP Authentication and Integrity 2349 It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to 2350 provide for the authenticity and integrity of PCEP messages. This 2351 will allow protecting against PCE or PCC impersonation and also 2352 against message content falsification. 2354 This requires the maintenance, exchange and configuration of MD-5 2355 keys on PCCs and PCEs. Note that such maintenance may be especially 2356 onerous to the operators as pointed out in [I-D.ietf-rpsec- 2357 bgpsecrec]. Hence it is important to limit the number of keys while 2358 ensuring the required level of security. 2360 MD-5 signature faces some limitations, as per explained in [RFC2385]. 2361 Note that when one digest technique stronger than MD5 is specified 2362 and implemented, PCEP could be easily upgraded to use it. 2364 11.2. PCEP Privacy 2366 Ensuring PCEP communication privacy is of key importance, especially 2367 in an inter-AS context, where PCEP communication end-points do not 2368 reside in the same AS, as an attacker that intercept a PCE message 2369 could obtain sensitive information related to computed paths and 2370 resources. Privacy can be ensured thanks to encryption. To ensure 2371 privacy of PCEP communication, IPSec [RFC2406] tunnels MAY be used 2372 between PCC and PCEs or between PCEs. Note that this could also be 2373 used to ensure Authentication and Integrity, in which case, TCP MD-5 2374 option would not be required. 2376 11.3. Protection against Denial of Service attacks 2378 PCEP can be the target of TCP DoS attacks, such as for instance SYN 2379 attacks, as all protocols running on top of TCP. PCEP can use the 2380 same mechanisms as defined in [RFC3036] to mitigate the threat of 2381 such attacks: 2383 o A PCE should avoid promiscuous TCP listens for PCEP TCP session 2384 establishment. It should use only listens that are specific to 2385 authorized PCCs. 2387 o The use of the MD5 option helps somewhat since it prevents a SYN 2388 from being accepted unless the MD5 segment checksum is valid. 2389 However, the receiver must compute the checksum before it can 2390 decide to discard an otherwise acceptable SYN segment. 2392 o The use of access-list on the PCE so as to restrict access to 2393 authorized PCCs. 2395 11.4. Request input shaping/policing 2397 A PCEP implementation may be subject to Denial Of Service attacks 2398 consisting of sending a very large number of PCEP messages (e.g. 2399 PCReq messages). Thus, especially in multi-Service Providers 2400 environments, a PCE implementation should implement request input 2401 shaping/policing so as to throttle the amount of received PCEP 2402 messages without compromising the implementation behavior. 2404 12. Acknowledgements 2406 The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash, 2407 Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard 2408 Douville for their very valuable input. Special thank to Adrian 2409 Farrel for his very valuable suggestions. 2411 13. References 2413 13.1. Normative References 2415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2416 Requirement Levels", BCP 14, RFC 2119, March 1997. 2418 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2419 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2420 Functional Specification", RFC 2205, September 1997. 2422 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2423 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2424 Tunnels", RFC 3209, December 2001. 2426 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 2427 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 2428 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 2430 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 2431 in Resource ReSerVation Protocol - Traffic Engineering 2432 (RSVP-TE)", RFC 3477, January 2003. 2434 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 2435 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 2436 May 2005. 2438 13.2. Informative References 2440 [I-D.ietf-ccamp-inter-domain-rsvp-te] 2441 Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic 2442 Engineering - RSVP-TE extensions", 2443 draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in 2444 progress), March 2006. 2446 [I-D.ietf-pce-architecture] 2447 Farrel, A., "A Path Computation Element (PCE) Based 2448 Architecture", draft-ietf-pce-architecture-05 (work in 2449 progress), April 2006. 2451 [I-D.ietf-pce-comm-protocol-gen-reqs] 2452 Roux, J. and J. Ash, "PCE Communication Protocol Generic 2453 Requirements", draft-ietf-pce-comm-protocol-gen-reqs-06 2454 (work in progress), May 2006. 2456 [I-D.ietf-pce-disco-proto-igp] 2457 Roux, J., "IGP protocol extensions for Path Computation 2458 Element (PCE) Discovery", 2459 draft-ietf-pce-disco-proto-igp-01 (work in progress), 2460 March 2006. 2462 [I-D.ietf-pce-discovery-reqs] 2463 Roux, J., "Requirements for Path Computation Element (PCE) 2464 Discovery", draft-ietf-pce-discovery-reqs-05 (work in 2465 progress), June 2006. 2467 [I-D.ietf-pce-inter-layer-req] 2468 Oki, E., "PCC-PCE Communication Requirements for Inter- 2469 Layer Traffic Engineering", 2470 draft-ietf-pce-inter-layer-req-01 (work in progress), 2471 March 2006. 2473 [I-D.ietf-pce-pcecp-interarea-reqs] 2474 Roux, J., "PCE Communication Protocol (PCECP) Specific 2475 Requirements for Inter-Area (G)MPLS Traffic Engineering", 2476 draft-ietf-pce-pcecp-interarea-reqs-01 (work in progress), 2477 February 2006. 2479 [I-D.ietf-rpsec-bgpsecrec] 2480 Christian, B. and T. Tauber, "BGP Security Requirements", 2481 draft-ietf-rpsec-bgpsecrec-06 (work in progress), 2482 June 2006. 2484 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2485 April 1992. 2487 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 2488 Signature Option", RFC 2385, August 1998. 2490 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 2491 Payload (ESP)", RFC 2406, November 1998. 2493 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 2494 B. Thomas, "LDP Specification", RFC 3036, January 2001. 2496 [RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and 2497 T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric 2498 as a second MPLS Traffic Engineering (TE) Metric", BCP 87, 2499 RFC 3785, May 2004. 2501 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 2502 June 2005. 2504 Appendix A. Proposed Status and Discussion [To Be Removed Upon 2505 Publication] 2507 This Internet-Draft is being submitted for eventual publication as an 2508 RFC with a proposed status of Standard. Discussion of this proposal 2509 should take place on the following mailing list: pce@ietf.org. 2511 Appendix B. Compliance with the PCECP Requirement Document 2513 The aim of this section is to list the set of requirements set forth 2514 in [I-D.ietf-pce-comm-protocol-gen-reqs] that are not satisfied by 2515 the current revision of this document. This only concerns the 2516 requirements listed as MUST according to [RFC2119]. 2518 Here is the list of currently unsatisfied requirements: 2520 o Allow to select/prefer from advertised list of standard objective 2521 functions/options 2523 o Allow to customize objective function/options 2525 o Allow indicating if load-balancing is allowed 2527 o Support "unsynchronized" & "synchronized" objective functions 2529 o Protocol recovery support resynchronization of information & 2530 requests between sender & receiver. 2532 Appendix C. PCEP Variables 2534 PCEP defines variable that can be configured. The following PCEP 2535 variables are defined. 2537 KeepAlive timer: minimum period of time between the sending of PCEP 2538 messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A 2539 suggested value for the Keepalive timer is 30 seconds. 2541 DeadTimer: period of timer after the expiration of which a PCEP peer 2542 declared the session down if no PCEP message has been received. 2544 SyncTimer: the SYNC timer is used in the case of synchronized path 2545 computation request using the SVEC object defined in Section 7.12.3. 2546 Consider the case where a PCReq message is received by a PCE that 2547 comprises the SVEC object referring to M synchronized path 2548 computation requests. If after the expiration of the SYNC timer all 2549 the M path computation requests have not been received, a protocol 2550 error is triggered and the PCE MUST cancel the whole set of path 2551 computation requests. A RECOMMENDED value for the SYNC timer is 60 2552 seconds. 2554 Authors' Addresses 2556 JP Vasseur (editor) 2557 Cisco Systems, Inc 2558 1414 Massachusetts Avenue 2559 Boxborough, MA 01719 2560 USA 2562 Email: jpv@cisco.com 2564 JL Le Roux 2565 France Telecom 2566 2, Avenue Pierre-Marzin 2567 Lannion, 22307 2568 FRANCE 2570 Email: jeanlouis.leroux@francetelecom.com 2572 Arthi Ayyangar 2573 Juniper Networks 2574 1194 N.Mathilda Avenue 2575 Sunnyvale, CA 94089 2576 USA 2578 Email: arthi@juniper.net 2580 Eiji Oki 2581 NTT 2582 Midori 3-9-11 2583 Musashino, Tokyo, 180-8585 2584 JAPAN 2586 Email: oki.eiji@lab.ntt.co.jp 2588 Alia Atlas 2589 Google 2590 1600 Amphitheatre Parkway 2591 Montain View, CA 94043 2592 USA 2594 Email: akatlas@alum.mit.edu 2595 Andrew Dolganow 2596 Alcatel 2597 600 March Road 2598 Ottawa, ON K2K 2E6 2599 CANADA 2601 Email: andrew.dolganow@alcatel.com 2603 Yuichi Ikejiri 2604 NTT Communications Corporation 2605 1-1-6 Uchisaiwai-cho, Chiyoda-ku 2606 Tokyo, 100-819 2607 JAPAN 2609 Email: y.ikejiri@ntt.com 2611 Kenji Kumaki 2612 KDDI Corporation 2613 Garden Air Tower Iidabashi, Chiyoda-ku, 2614 Tokyo, 102-8460 2615 JAPAN 2617 Email: ke-kumaki@kddi.com 2619 Intellectual Property Statement 2621 The IETF takes no position regarding the validity or scope of any 2622 Intellectual Property Rights or other rights that might be claimed to 2623 pertain to the implementation or use of the technology described in 2624 this document or the extent to which any license under such rights 2625 might or might not be available; nor does it represent that it has 2626 made any independent effort to identify any such rights. Information 2627 on the procedures with respect to rights in RFC documents can be 2628 found in BCP 78 and BCP 79. 2630 Copies of IPR disclosures made to the IETF Secretariat and any 2631 assurances of licenses to be made available, or the result of an 2632 attempt made to obtain a general license or permission for the use of 2633 such proprietary rights by implementers or users of this 2634 specification can be obtained from the IETF on-line IPR repository at 2635 http://www.ietf.org/ipr. 2637 The IETF invites any interested party to bring to its attention any 2638 copyrights, patents or patent applications, or other proprietary 2639 rights that may cover technology that may be required to implement 2640 this standard. Please address the information to the IETF at 2641 ietf-ipr@ietf.org. 2643 Disclaimer of Validity 2645 This document and the information contained herein are provided on an 2646 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2647 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2648 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2649 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2650 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2651 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2653 Copyright Statement 2655 Copyright (C) The Internet Society (2006). This document is subject 2656 to the rights, licenses and restrictions contained in BCP 78, and 2657 except as set forth therein, the authors retain all their rights. 2659 Acknowledgment 2661 Funding for the RFC Editor function is currently provided by the 2662 Internet Society.