Network Working Group JP. Vasseur, Ed. Request for Comments: 5440 Cisco Systems Category: Standards Track JL. Le Roux, Ed. France Telecom March 2009 Path Computation Element (PCE) Communication Protocol (PCEP) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Vasseur & Le Roux Standards Track [Page 1] RFC 5440 PCEP March 2009 Abstract This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. Vasseur & Le Roux Standards Track [Page 2] RFC 5440 PCEP March 2009 Table of Contents 1. Introduction ....................................................5 1.1. Requirements Language ......................................5 2. Terminology .....................................................5 3. Assumptions .....................................................6 4. Architectural Protocol Overview (Model) .........................7 4.1. Problem ....................................................7 4.2. Architectural Protocol Overview ............................7 4.2.1. Initialization Phase ................................8 4.2.2. Session Keepalive ...................................9 4.2.3. Path Computation Request Sent by a PCC to a PCE ....10 4.2.4. Path Computation Reply Sent by The PCE to a PCC ....11 4.2.5. Notification .......................................12 4.2.6. Error ..............................................14 4.2.7. Termination of the PCEP Session ....................14 4.2.8. Intermittent versus Permanent PCEP Session .........15 5. Transport Protocol .............................................15 6. PCEP Messages ..................................................15 6.1. Common Header .............................................16 6.2. Open Message ..............................................16 6.3. Keepalive Message .........................................18 6.4. Path Computation Request (PCReq) Message ..................19 6.5. Path Computation Reply (PCRep) Message ....................20 6.6. Notification (PCNtf) Message ..............................21 6.7. Error (PCErr) Message .....................................22 6.8. Close Message .............................................23 6.9. Reception of Unknown Messages .............................23 7. Object Formats .................................................23 7.1. PCEP TLV Format ...........................................24 7.2. Common Object Header ......................................24 7.3. OPEN Object ...............................................25 7.4. RP Object .................................................27 7.4.1. Object Definition ..................................27 7.4.2. Handling of the RP Object ..........................30 7.5. NO-PATH Object ............................................31 7.6. END-POINTS Object .........................................34 7.7. BANDWIDTH Object ..........................................35 7.8. METRIC Object .............................................36 7.9. Explicit Route Object .....................................39 7.10. Reported Route Object ....................................39 7.11. LSPA Object ..............................................40 7.12. Include Route Object .....................................42 7.13. SVEC Object ..............................................42 7.13.1. Notion of Dependent and Synchronized Path Computation Requests ..............................42 7.13.2. SVEC Object .......................................44 7.13.3. Handling of the SVEC Object .......................45 Vasseur & Le Roux Standards Track [Page 3] RFC 5440 PCEP March 2009 7.14. NOTIFICATION Object ......................................46 7.15. PCEP-ERROR Object ........................................49 7.16. LOAD-BALANCING Object ....................................54 7.17. CLOSE Object .............................................55 8. Manageability Considerations ...................................56 8.1. Control of Function and Policy ............................56 8.2. Information and Data Models ...............................57 8.3. Liveness Detection and Monitoring .........................57 8.4. Verifying Correct Operation ...............................58 8.5. Requirements on Other Protocols and Functional Components ................................................58 8.6. Impact on Network Operation ...............................58 9. IANA Considerations ............................................59 9.1. TCP Port ..................................................59 9.2. PCEP Messages .............................................59 9.3. PCEP Object ...............................................59 9.4. PCEP Message Common Header ................................61 9.5. Open Object Flag Field ....................................61 9.6. RP Object .................................................61 9.7. NO-PATH Object Flag Field .................................62 9.8. METRIC Object .............................................63 9.9. LSPA Object Flag Field ....................................63 9.10. SVEC Object Flag Field ...................................64 9.11. NOTIFICATION Object ......................................64 9.12. PCEP-ERROR Object ........................................65 9.13. LOAD-BALANCING Object Flag Field .........................67 9.14. CLOSE Object .............................................67 9.15. PCEP TLV Type Indicators .................................68 9.16. NO-PATH-VECTOR TLV .......................................68 10. Security Considerations .......................................69 10.1. Vulnerability ............................................69 10.2. TCP Security Techniques ..................................70 10.3. PCEP Authentication and Integrity ........................70 10.4. PCEP Privacy .............................................71 10.5. Key Configuration and Exchange ...........................71 10.6. Access Policy ............................................73 10.7. Protection against Denial-of-Service Attacks .............73 10.7.1. Protection against TCP DoS Attacks ................73 10.7.2. Request Input Shaping/Policing ....................74 11. Acknowledgments ...............................................75 12. References ....................................................75 12.1. Normative References .....................................75 12.2. Informative References ...................................76 Appendix A. PCEP Finite State Machine (FSM) ......................79 Appendix B. PCEP Variables .......................................85 Appendix C. Contributors .........................................86 Vasseur & Le Roux Standards Track [Page 4] RFC 5440 PCEP March 2009 1. Introduction [RFC4655] describes the motivations and architecture for a Path Computation Element (PCE) based model for the computation of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). The model allows for the separation of PCE from Path Computation Client (PCC), and allows for the cooperation between PCEs. This necessitates a communication protocol between PCC and PCE, and between PCEs. [RFC4657] states the generic requirements for such a protocol including that the same protocol be used between PCC and PCE, and between PCEs. Additional application-specific requirements (for scenarios such as inter-area, inter-AS, etc.) are not included in [RFC4657], but there is a requirement that any solution protocol must be easily extensible to handle other requirements as they are introduced in application-specific requirements documents. Examples of such application-specific requirements are [RFC4927], [RFC5376], and [INTER-LAYER]. This document specifies the Path Computation Element Protocol (PCEP) for communications between a PCC and a PCE, or between two PCEs, in compliance with [RFC4657]. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of MPLS and GMPLS Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Terminology The following terminology is used in this document. AS: Autonomous System. Explicit path: Full explicit path from start to destination; made of a list of strict hops where a hop may be an abstract node such as an AS. IGP area: OSPF area or IS-IS level. Vasseur & Le Roux Standards Track [Page 5] RFC 5440 PCEP March 2009 Inter-domain TE LSP: A TE LSP whose path transits at least two different domains where a domain can be an IGP area, an Autonomous System, or a sub-AS (BGP confederation). PCC: Path Computation Client; any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element; an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. PCEP Peer: An element involved in a PCEP session (i.e., a PCC or a PCE). TED: Traffic Engineering Database that contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means. TE LSP: Traffic Engineering Label Switched Path. Strict/loose path: A mix of strict and loose hops comprising at least one loose hop representing the destination where a hop may be an abstract node such as an AS. Within this document, when describing PCE-PCE communications, the requesting PCE fills the role of a PCC. This provides a saving in documentation without loss of function. The message formats in this document are specified using Backus-Naur Format (BNF) encoding as specified in [RBNF]. 3. Assumptions [RFC4655] describes various types of PCE. PCEP does not make any assumption about, and thus does not impose any constraint on, the nature of the PCE. Moreover, it is assumed that the PCE has the required information (usually including network topology and resource information) so as to perform the computation of a path for a TE LSP. Such information can be gathered by routing protocols or by some other means. The way in which the information is gathered is out of the scope of this document. Similarly, no assumption is made about the discovery method used by a PCC to discover a set of PCEs (e.g., via static configuration or dynamic discovery) and on the algorithm used to select a PCE. For Vasseur & Le Roux Standards Track [Page 6] RFC 5440 PCEP March 2009 reference, [RFC4674] defines a list of requirements for dynamic PCE discovery and IGP-based solutions for such PCE discovery are specified in [RFC5088] and [RFC5089]. 4. Architectural Protocol Overview (Model) The aim of this section is to describe the PCEP model in the spirit of [RFC4101]. An architectural protocol overview (the big picture of the protocol) is provided in this section. Protocol details can be found in further sections. 4.1. Problem The PCE-based architecture used for the computation of paths for MPLS and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the PCE are not collocated, a communication protocol between the PCC and the PCE is needed. PCEP is such a protocol designed specifically for communications between a PCC and a PCE or between two PCEs in compliance with [RFC4657]: a PCC may use PCEP to send a path computation request for one or more TE LSPs to a PCE, and the PCE may reply with a set of computed paths if one or more paths can be found that satisfies the set of constraints. 4.2. Architectural Protocol Overview PCEP operates over TCP, which fulfills the requirements for reliable messaging and flow control without further protocol work. Several PCEP messages are defined: o Open and Keepalive messages are used to initiate and maintain a PCEP session, respectively. o PCReq: a PCEP message sent by a PCC to a PCE to request a path computation. o PCRep: a PCEP message sent by a PCE to a PCC in reply to a path computation request. A PCRep message can contain either a set of computed paths if the request can be satisfied, or a negative reply if not. The negative reply may indicate the reason why no path could be found. o PCNtf: a PCEP notification message either sent by a PCC to a PCE or sent by a PCE to a PCC to notify of a specific event. o PCErr: a PCEP message sent upon the occurrence of a protocol error condition. Vasseur & Le Roux Standards Track [Page 7] RFC 5440 PCEP March 2009 o Close message: a message used to close a PCEP session. The set of available PCEs may be either statically configured on a PCC or dynamically discovered. The mechanisms used to discover one or more PCEs and to select a PCE are out of the scope of this document. A PCC may have PCEP sessions with more than one PCE, and similarly a PCE may have PCEP sessions with multiple PCCs. Each PCEP message is regarded as a single transmission unit and parts of messages MUST NOT be interleaved. So, for example, a PCC sending a PCReq and wishing to close the session, must complete sending the request message before starting to send a Close message. 4.2.1. Initialization Phase The initialization phase consists of two successive steps (described in a schematic form in Figure 1): 1) Establishment of a TCP connection (3-way handshake) between the PCC and the PCE. 2) Establishment of a PCEP session over the TCP connection. Once the TCP connection is established, the PCC and the PCE (also referred to as "PCEP peers") initiate PCEP session establishment during which various session parameters are negotiated. These parameters are carried within Open messages and include the Keepalive timer, the DeadTimer, and potentially other detailed capabilities and policy rules that specify the conditions under which path computation requests may be sent to the PCE. If the PCEP session establishment phase fails because the PCEP peers disagree on the session parameters or one of the PCEP peers does not answer after the expiration of the establishment timer, the TCP connection is immediately closed. Successive retries are permitted but an implementation should make use of an exponential back-off session establishment retry procedure. Keepalive messages are used to acknowledge Open messages, and are used once the PCEP session has been successfully established. Only one PCEP session can exist between a pair of PCEP peers at any one time. Only one TCP connection on the PCEP port can exist between a pair of PCEP peers at any one time. Details about the Open message and the Keepalive message can be found in Sections 6.2 and 6.3, respectively. Vasseur & Le Roux Standards Track [Page 8] RFC 5440 PCEP March 2009 +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | | Open msg | |-------- | | \ Open msg | | \ ---------| | \/ | | /\ | | / -------->| | / | |<------ Keepalive| | --------| |Keepalive / | |-------- / | | \/ | | /\ | |<------ ---------->| | | Figure 1: PCEP Initialization Phase (Initiated by a PCC) (Note that once the PCEP session is established, the exchange of Keepalive messages is optional.) 4.2.2. Session Keepalive Once a session has been established, a PCE or PCC may want to know that its PCEP peer is still available for use. It can rely on TCP for this information, but it is possible that the remote PCEP function has failed without disturbing the TCP connection. It is also possible to rely on the mechanisms built into the TCP implementations, but these might not provide failure notifications that are sufficiently timely. Lastly, a PCC could wait until it has a path computation request to send and could use its failed transmission or the failure to receive a response as evidence that the session has failed, but this is clearly inefficient. In order to handle this situation, PCEP includes a keepalive mechanism based on a Keepalive timer, a DeadTimer, and a Keepalive message. Each end of a PCEP session runs a Keepalive timer. It restarts the timer every time it sends a message on the session. When the timer expires, it sends a Keepalive message. Other traffic may serve as Keepalive (see Section 6.3). Vasseur & Le Roux Standards Track [Page 9] RFC 5440 PCEP March 2009 The ends of the PCEP session also run DeadTimers, and they restart the timers whenever a message is received on the session. If one end of the session receives no message before the DeadTimer expires, it declares the session dead. Note that this means that the Keepalive message is unresponded and does not form part of a two-way keepalive handshake as used in some protocols. Also note that the mechanism is designed to reduce to a minimum the amount of keepalive traffic on the session. The keepalive traffic on the session may be unbalanced according to the requirements of the session ends. Each end of the session can specify (on an Open message) the Keepalive timer that it will use (i.e., how often it will transmit a Keepalive message if there is no other traffic) and a DeadTimer that it recommends its peer to use (i.e., how long the peer should wait before declaring the session dead if it receives no traffic). The session ends may use different Keepalive timer values. The minimum value of the Keepalive timer is 1 second, and it is specified in units of 1 second. The recommended default value is 30 seconds. The timer may be disabled by setting it to zero. The recommended default for the DeadTimer is 4 times the value of the Keepalive timer used by the remote peer. This means that there is never any risk of congesting TCP with excessive Keepalive messages. 4.2.3. Path Computation Request Sent by a PCC to a PCE +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ 1) Path computation | | event | | 2) PCE Selection | | 3) Path computation |---- PCReq message--->| request sent to | | the selected PCE | | Figure 2: Path Computation Request Once a PCC has successfully established a PCEP session with one or more PCEs, if an event is triggered that requires the computation of a set of paths, the PCC first selects one or more PCEs. Note that the PCE selection decision process may have taken place prior to the PCEP session establishment. Vasseur & Le Roux Standards Track [Page 10] RFC 5440 PCEP March 2009 Once the PCC has selected a PCE, it sends a path computation request to the PCE (PCReq message) that contains a variety of objects that specify the set of constraints and attributes for the path to be computed. For example, "Compute a TE LSP path with source IP address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B Mbit/s, Setup/Holding priority=P, ...". Additionally, the PCC may desire to specify the urgency of such request by assigning a request priority. Each request is uniquely identified by a request-id number and the PCC-PCE address pair. The process is shown in a schematic form in Figure 2. Note that multiple path computation requests may be outstanding from a PCC to a PCE at any time. Details about the PCReq message can be found in Section 6.4. 4.2.4. Path Computation Reply Sent by The PCE to a PCC +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |---- PCReq message--->| | |1) Path computation | | request received | | | |2) Path successfully | | computed | | | |3) Computed paths | | sent to the PCC | | |<--- PCRep message ---| | (Positive reply) | Figure 3a: Path Computation Request With Successful Path Computation Vasseur & Le Roux Standards Track [Page 11] RFC 5440 PCEP March 2009 +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | | | |---- PCReq message--->| | |1) Path computation | | request received | | | |2) No Path found that | | satisfies the request | | | |3) Negative reply sent to | | the PCC (optionally with | | various additional | | information) |<--- PCRep message ---| | (Negative reply) | Figure 3b: Path Computation Request With Unsuccessful Path Computation Upon receiving a path computation request from a PCC, the PCE triggers a path computation, the result of which can be either: o Positive (Figure 3a): the PCE manages to compute a path that satisfies the set of required constraints. In this case, the PCE returns the set of computed paths to the requesting PCC. Note that PCEP supports the capability to send a single request that requires the computation of more than one path (e.g., computation of a set of link-diverse paths). o Negative (Figure 3b): no path could be found that satisfies the set of constraints. In this case, a PCE may provide the set of constraints that led to the path computation failure. Upon receiving a negative reply, a PCC may decide to resend a modified request or take any other appropriate action. Details about the PCRep message can be found in Section 6.5. 4.2.5. Notification There are several circumstances in which a PCE may want to notify a PCC of a specific event. For example, suppose that the PCE suddenly gets overloaded, potentially leading to unacceptable response times. The PCE may want to notify one or more PCCs that some of their requests (listed in the notification) will not be satisfied or may experience unacceptable delays. Upon receiving such notification, Vasseur & Le Roux Standards Track [Page 12] RFC 5440 PCEP March 2009 the PCC may decide to redirect its path computation requests to another PCE should an alternate PCE be available. Similarly, a PCC may desire to notify a PCE of a particular event such as the cancellation of pending requests. +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ 1) Path computation | | event | | 2) PCE Selection | | 3) Path computation |---- PCReq message--->| request X sent to | |4) Path computation the selected PCE | | request queued | | | | 5) Path computation | | request X cancelled| | |---- PCNtf message -->| | |6) Path computation | | request X cancelled Figure 4: Example of PCC Notification (Cancellation Notification) Sent to a PCE +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ 1) Path computation | | event | | 2) PCE Selection | | 3) Path computation |---- PCReq message--->| request X sent to | |4) Path computation the selected PCE | | request queued | | | | | |5) PCE gets overloaded | | | | | |6) Path computation | | request X cancelled | | |<--- PCNtf message----| Figure 5: Example of PCE Notification (Cancellation Notification) Sent to a PCC Details about the PCNtf message can be found in Section 6.6. Vasseur & Le Roux Standards Track [Page 13] RFC 5440 PCEP March 2009 4.2.6. Error The PCEP Error message (also referred to as a PCErr message) is sent in several situations: when a protocol error condition is met or when the request is not compliant with the PCEP specification (e.g., capability not supported, reception of a message with a mandatory missing object, policy violation, unexpected message, unknown request reference). +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ 1) Path computation | | event | | 2) PCE Selection | | 3) Path computation |---- PCReq message--->| request X sent to | |4) Reception of a the selected PCE | | malformed object | | | |5) Request discarded | | |<-- PCErr message ---| | | Figure 6: Example of Error Message Sent by a PCE to a PCC in Reply to the Reception of a Malformed Object Details about the PCErr message can be found in Section 6.7. 4.2.7. Termination of the PCEP Session When one of the PCEP peers desires to terminate a PCEP session it first sends a PCEP Close message and then closes the TCP connection. If the PCEP session is terminated by the PCE, the PCC clears all the states related to pending requests previously sent to the PCE. Similarly, if the PCC terminates a PCEP session, the PCE clears all pending path computation requests sent by the PCC in question as well as the related states. A Close message can only be sent to terminate a PCEP session if the PCEP session has previously been established. In case of TCP connection failure, the PCEP session is immediately terminated. Details about the Close message can be found in Section 6.8. Vasseur & Le Roux Standards Track [Page 14] RFC 5440 PCEP March 2009 4.2.8. Intermittent versus Permanent PCEP Session An implementation may decide to keep the PCEP session alive (and thus the corresponding TCP connection) for an unlimited time. (For instance, this may be appropriate when path computation requests are sent on a frequent basis so as to avoid opening a TCP connection each time a path computation request is needed, which would incur additional processing delays.) Conversely, in some other circumstances, it may be desirable to systematically open and close a PCEP session for each PCEP request (for instance, when sending a path computation request is a rare event). 5. Transport Protocol PCEP operates over TCP using a registered TCP port (4189). This allows the requirements of reliable messaging and flow control to be met without further protocol work. All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port. 6. PCEP Messages A PCEP message consists of a common header followed by a variable- length body made of a set of objects that can either be mandatory or optional. In the context of this document, an object is said to be mandatory in a PCEP message when the object MUST be included for the message to be considered valid. A PCEP message with a missing mandatory object MUST trigger an Error message (see Section 7.15). Conversely, if an object is optional, the object may or may not be present. A flag referred to as the P flag is defined in the common header of each PCEP object (see Section 7.2). When this flag is set in an object in a PCReq, the PCE MUST take the information carried in the object into account during the path computation. For example, the METRIC object defined in Section 7.8 allows a PCC to specify a bounded acceptable path cost. The METRIC object is optional, but a PCC may set a flag to ensure that the constraint is taken into account. In this case, if the constraint cannot be taken into account by the PCE, the PCE MUST trigger an Error message. For each PCEP message type, rules are defined that specify the set of objects that the message can carry. We use the Backus-Naur Form (BNF) (see [RBNF]) to specify such rules. Square brackets refer to optional sub-sequences. An implementation MUST form the PCEP messages using the object ordering specified in this document. Vasseur & Le Roux Standards Track [Page 15] RFC 5440 PCEP March 2009 6.1. Common Header 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Flags | Message-Type | Message-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: PCEP Message Common Header Ver (Version - 3 bits): PCEP version number. Current version is version 1. Flags (5 bits): No flags are currently defined. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. Message-Type (8 bits): The following message types are currently defined: Value Meaning 1 Open 2 Keepalive 3 Path Computation Request 4 Path Computation Reply 5 Notification 6 Error 7 Close Message-Length (16 bits): total length of the PCEP message including the common header, expressed in bytes. 6.2. Open Message The Open message is a PCEP message sent by a PCC to a PCE and by a PCE to a PCC in order to establish a PCEP session. The Message-Type field of the PCEP common header for the Open message is set to 1. Once the TCP connection has been successfully established, the first message sent by the PCC to the PCE or by the PCE to the PCC MUST be an Open message as specified in Appendix A. Any message received prior to an Open message MUST trigger a protocol error condition causing a PCErr message to be sent with Error-Type "PCEP session establishment failure" and Error-value "reception of an invalid Open message or a non Open message" and the PCEP session establishment attempt MUST be terminated by closing the TCP connection. Vasseur & Le Roux Standards Track [Page 16] RFC 5440 PCEP March 2009 The Open message is used to establish a PCEP session between the PCEP peers. During the establishment phase, the PCEP peers exchange several session characteristics. If both parties agree on such characteristics, the PCEP session is successfully established. The format of an Open message is as follows: ::= The Open message MUST contain exactly one OPEN object (see Section 7.3). Various session characteristics are specified within the OPEN object. Once the TCP connection has been successfully established, the sender MUST start an initialization timer called OpenWait after the expiration of which, if no Open message has been received, it sends a PCErr message and releases the TCP connection (see Appendix A for details). Once an Open message has been sent to a PCEP peer, the sender MUST start an initialization timer called KeepWait after the expiration of which, if neither a Keepalive message has been received nor a PCErr message in case of disagreement of the session characteristics, a PCErr message MUST be sent and the TCP connection MUST be released (see Appendix A for details). The OpenWait and KeepWait timers have a fixed value of 1 minute. Upon the receipt of an Open message, the receiving PCEP peer MUST determine whether the suggested PCEP session characteristics are acceptable. If at least one of the characteristics is not acceptable to the receiving peer, it MUST send an Error message. The Error message SHOULD also contain the related OPEN object and, for each unacceptable session parameter, an acceptable parameter value SHOULD be proposed in the appropriate field of the OPEN object in place of the originally proposed value. The PCEP peer MAY decide to resend an Open message with different session characteristics. If a second Open message is received with the same set of parameters or with parameters that are still unacceptable, the receiving peer MUST send an Error message and it MUST immediately close the TCP connection. Details about error messages can be found in Section 7.15. Successive retries are permitted, but an implementation SHOULD make use of an exponential back-off session establishment retry procedure. If the PCEP session characteristics are acceptable, the receiving PCEP peer MUST send a Keepalive message (defined in Section 6.3) that serves as an acknowledgment. Vasseur & Le Roux Standards Track [Page 17] RFC 5440 PCEP March 2009 The PCEP session is considered as established once both PCEP peers have received a Keepalive message from their peer. 6.3. Keepalive Message A Keepalive message is a PCEP message sent by a PCC or a PCE in order to keep the session in active state. The Keepalive message is also used in response to an Open message to acknowledge that an Open message has been received and that the PCEP session characteristics are acceptable. The Message-Type field of the PCEP common header for the Keepalive message is set to 2. The Keepalive message does not contain any object. PCEP has its own keepalive mechanism used to ensure the liveness of the PCEP session. This requires the determination of the frequency at which each PCEP peer sends Keepalive messages. Asymmetric values may be chosen; thus, there is no constraint mandating the use of identical keepalive frequencies by both PCEP peers. The DeadTimer is defined as the period of time after the expiration of which a PCEP peer declares the session down if no PCEP message has been received (Keepalive or any other PCEP message); thus, any PCEP message acts as a Keepalive message. Similarly, there are no constraints mandating the use of identical DeadTimers by both PCEP peers. The minimum Keepalive timer value is 1 second. Deployments SHOULD consider carefully the impact of using low values for the Keepalive timer as these might not give rise to the expected results in periods of temporary network instability. Keepalive messages are sent at the frequency specified in the OPEN object carried within an Open message according to the rules specified in Section 7.3. Because any PCEP message may serve as Keepalive, an implementation may either decide to send Keepalive messages at fixed intervals regardless of whether other PCEP messages might have been sent since the last sent Keepalive message, or may decide to differ the sending of the next Keepalive message based on the time at which the last PCEP message (other than Keepalive) was sent. Note that sending Keepalive messages to keep the session alive is optional, and PCEP peers may decide not to send Keepalive messages once the PCEP session is established; in which case, the peer that does not receive Keepalive messages does not expect to receive them and MUST NOT declare the session as inactive. The format of a Keepalive message is as follows: ::= Vasseur & Le Roux Standards Track [Page 18] RFC 5440 PCEP March 2009 6.4. Path Computation Request (PCReq) Message A Path Computation Request message (also referred to as a PCReq message) is a PCEP message sent by a PCC to a PCE to request a path computation. A PCReq message may carry more than one path computation request. The Message-Type field of the PCEP common header for the PCReq message is set to 3. There are two mandatory objects that MUST be included within a PCReq message: the RP and the END-POINTS objects (see Section 7). If one or both of these objects is missing, the receiving PCE MUST send an error message to the requesting PCC. Other objects are optional. The format of a PCReq message is as follows: ::= [] where: ::=[] ::=[] ::= [] [] [] [[]] [] [] where: ::=[] The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO, and LOAD-BALANCING objects are defined in Section 7. The special case of two BANDWIDTH objects is discussed in detail in Section 7.7. A PCEP implementation is free to process received requests in any order. For example, the requests may be processed in the order they are received, reordered and assigned priority according to local policy, reordered according to the priority encoded in the RP object (Section 7.4.1), or processed in parallel. Vasseur & Le Roux Standards Track [Page 19] RFC 5440 PCEP March 2009 6.5. Path Computation Reply (PCRep) Message The PCEP Path Computation Reply message (also referred to as a PCRep message) is a PCEP message sent by a PCE to a requesting PCC in response to a previously received PCReq message. The Message-Type field of the PCEP common header for the PCRep message is set to 4. The bundling of multiple replies to a set of path computation requests within a single PCRep message is supported by PCEP. If a PCE receives non-synchronized path computation requests by means of one or more PCReq messages from a requesting PCC, it MAY decide to bundle the computed paths within a single PCRep message so as to reduce the control plane load. Note that the counter side of such an approach is the introduction of additional delays for some path computation requests of the set. Conversely, a PCE that receives multiple requests within the same PCReq message MAY decide to provide each computed path in separate PCRep messages or within the same PCRep message. A PCRep message may contain positive and negative replies. A PCRep message may contain a set of computed paths corresponding to either a single path computation request with load-balancing (see Section 7.16) or multiple path computation requests originated by a requesting PCC. The PCRep message may also contain multiple acceptable paths corresponding to the same request. The PCRep message MUST contain at least one RP object. For each reply that is bundled into a single PCReq message, an RP object MUST be included that contains a Request-ID-number identical to the one specified in the RP object carried in the corresponding PCReq message (see Section 7.4 for the definition of the RP object). If the path computation request can be satisfied (i.e., the PCE finds a set of paths that satisfy the set of constraints), the set of computed paths specified by means of Explicit Route Objects (EROs) is inserted in the PCRep message. The ERO is defined in Section 7.9. The situation where multiple computed paths are provided in a PCRep message is discussed in detail in Section 7.13. Furthermore, when a PCC requests the computation of a set of paths for a total amount of bandwidth by means of a LOAD-BALANCING object carried within a PCReq message, the ERO of each computed path may be followed by a BANDWIDTH object as discussed in section Section 7.16. If the path computation request cannot be satisfied, the PCRep message MUST include a NO-PATH object. The NO-PATH object (described in Section 7.5) may also contain other information (e.g, reasons for the path computation failure). Vasseur & Le Roux Standards Track [Page 20] RFC 5440 PCEP March 2009 The format of a PCRep message is as follows: ::= where: ::=[] ::= [] [] [] ::=[] ::= where: ::=[] [] [] [] ::=[] 6.6. Notification (PCNtf) Message The PCEP Notification message (also referred to as the PCNtf message) can be sent either by a PCE to a PCC, or by a PCC to a PCE, to notify of a specific event. The Message-Type field of the PCEP common header for the PCNtf message is set to 5. The PCNtf message MUST carry at least one NOTIFICATION object and MAY contain several NOTIFICATION objects should the PCE or the PCC intend to notify of multiple events. The NOTIFICATION object is defined in Section 7.14. The PCNtf message MAY also contain RP objects (see Section 7.4) when the notification refers to particular path computation requests. The PCNtf message may be sent by a PCC or a PCE in response to a request or in an unsolicited manner. Vasseur & Le Roux Standards Track [Page 21] RFC 5440 PCEP March 2009 The format of a PCNtf message is as follows: ::= ::= [] ::= [] ::=[] ::=[] 6.7. Error (PCErr) Message The PCEP Error message (also referred to as a PCErr message) is sent in several situations: when a protocol error condition is met or when the request is not compliant with the PCEP specification (e.g., reception of a malformed message, reception of a message with a mandatory missing object, policy violation, unexpected message, unknown request reference). The Message-Type field of the PCEP common header for the PCErr message is set to 6. The PCErr message is sent by a PCC or a PCE in response to a request or in an unsolicited manner. If the PCErr message is sent in response to a request, the PCErr message MUST include the set of RP objects related to the pending path computation requests that triggered the error condition. In the latter case (unsolicited), no RP object is inserted in the PCErr message. For example, no RP object is inserted in a PCErr when the error condition occurred during the initialization phase. A PCErr message MUST contain a PCEP-ERROR object specifying the PCEP error condition. The PCEP- ERROR object is defined in Section 7.15. The format of a PCErr message is as follows: ::= ( [] ) | [] ::=[] ::=[] ::=[] Vasseur & Le Roux Standards Track [Page 22] RFC 5440 PCEP March 2009 ::=[] The procedure upon the receipt of a PCErr message is defined in Section 7.15. 6.8. Close Message The Close message is a PCEP message that is either sent by a PCC to a PCE or by a PCE to a PCC in order to close an established PCEP session. The Message-Type field of the PCEP common header for the Close message is set to 7. The format of a Close message is as follows: ::= The Close message MUST contain exactly one CLOSE object (see Section 6.8). If more than one CLOSE object is present, the first MUST be processed and subsequent objects ignored. Upon the receipt of a valid Close message, the receiving PCEP peer MUST cancel all pending requests, it MUST close the TCP connection and MUST NOT send any further PCEP messages on the PCEP session. 6.9. Reception of Unknown Messages A PCEP implementation that receives an unrecognized PCEP message MUST send a PCErr message with Error-value=2 (capability not supported). If a PCC/PCE receives unrecognized messages at a rate equal or greater than MAX-UNKNOWN-MESSAGES unknown message requests per minute, the PCC/PCE MUST send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown PCEP message". A RECOMMENDED value for MAX-UNKNOWN-MESSAGES is 5. The PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP messages on the PCEP session. 7. Object Formats PCEP objects have a common format. They begin with a common object header (see Section 7.2). This is followed by object-specific fields defined for each different object. The object may also include one or more type-length-value (TLV) encoded data sets. Each TLV has the same structure as described in Section 7.1. Vasseur & Le Roux Standards Track [Page 23] RFC 5440 PCEP March 2009 7.1. PCEP TLV Format A PCEP object may include a set of one or more optional TLVs. All PCEP TLVs have the following format: Type: 2 bytes Length: 2 bytes Value: variable A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes specifying the TLV length, and a value field. The Length field defines the length of the value portion in bytes. The TLV is padded to 4-bytes alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes). Unrecognized TLVs MUST be ignored. IANA management of the PCEP Object TLV type identifier codespace is described in Section 9. 7.2. Common Object Header A PCEP object carried within a PCEP message consists of one or more 32-bit words with a common header that has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object-Class | OT |Res|P|I| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object body) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: PCEP Common Object Header Object-Class (8 bits): identifies the PCEP object class. OT (Object-Type - 4 bits): identifies the PCEP object type. The Object-Class and Object-Type fields are managed by IANA. The Object-Class and Object-Type fields uniquely identify each PCEP object. Vasseur & Le Roux Standards Track [Page 24] RFC 5440 PCEP March 2009 Res flags (2 bits): Reserved field. This field MUST be set to zero on transmission and MUST be ignored on receipt. P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify in a PCReq message sent to a PCE whether the object must be taken into account by the PCE during path computation or is just optional. When the P flag is set, the object MUST be taken into account by the PCE. Conversely, when the P flag is cleared, the object is optional and the PCE is free to ignore it. I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep message to indicate to a PCC whether or not an optional object was processed. The PCE MAY include the ignored optional object in its reply and set the I flag to indicate that the optional object was ignored during path computation. When the I flag is cleared, the PCE indicates that the optional object was processed during the path computation. The setting of the I flag for optional objects is purely indicative and optional. The I flag has no meaning in a PCRep message when the P flag has been set in the corresponding PCReq message. If the PCE does not understand an object with the P flag set or understands the object but decides to ignore the object, the entire PCEP message MUST be rejected and the PCE MUST send a PCErr message with Error-Type="Unknown Object" or "Not supported Object" along with the corresponding RP object. Note that if a PCReq includes multiple requests, only requests for which an object with the P flag set is unknown/unrecognized MUST be rejected. Object Length (16 bits): Specifies the total object length including the header, in bytes. The Object Length field MUST always be a multiple of 4, and at least 4. The maximum object content length is 65528 bytes. 7.3. OPEN Object The OPEN object MUST be present in each Open message and MAY be present in a PCErr message. There MUST be only one OPEN object per Open or PCErr message. The OPEN object contains a set of fields used to specify the PCEP version, Keepalive frequency, DeadTimer, and PCEP session ID, along with various flags. The OPEN object may also contain a set of TLVs used to convey various session characteristics such as the detailed PCE capabilities, policy rules, and so on. No TLVs are currently defined. Vasseur & Le Roux Standards Track [Page 25] RFC 5440 PCEP March 2009 OPEN Object-Class is 1. OPEN Object-Type is 1. The format of the OPEN object body is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Flags | Keepalive | DeadTimer | SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: OPEN Object Format Ver (3 bits): PCEP version. Current version is 1. Flags (5 bits): No flags are currently defined. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. Keepalive (8 bits): maximum period of time (in seconds) between two consecutive PCEP messages sent by the sender of this message. The minimum value for the Keepalive is 1 second. When set to 0, once the session is established, no further Keepalive messages are sent to the remote peer. A RECOMMENDED value for the keepalive frequency is 30 seconds. DeadTimer (8 bits): specifies the amount of time after the expiration of which the PCEP peer can declare the session with the sender of the Open message to be down if no PCEP message has been received. The DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value of the Keepalive. Example: A sends an Open message to B with Keepalive=10 seconds and DeadTimer=40 seconds. This means that A sends Keepalive messages (or any other PCEP message) to B every 10 seconds and B can declare the PCEP session with A down if no PCEP message has been received from A within any 40-second period. Vasseur & Le Roux Standards Track [Page 26] RFC 5440 PCEP March 2009 SID (PCEP session ID - 8 bits): unsigned PCEP session number that identifies the current session. The SID MUST be incremented each time a new PCEP session is established. It is used for logging and troubleshooting purposes. Each increment SHOULD have a value of 1 and may cause a wrap back to zero. The SID is used to disambiguate instances of sessions to the same peer. A PCEP implementation could use a single source of SIDs across all peers, or one source for each peer. The former might constrain the implementation to only 256 concurrent sessions. The latter potentially requires more states. There is one SID number in each direction. Optional TLVs may be included within the OPEN object body to specify PCC or PCE characteristics. The specification of such TLVs is outside the scope of this document. When present in an Open message, the OPEN object specifies the proposed PCEP session characteristics. Upon receiving unacceptable PCEP session characteristics during the PCEP session initialization phase, the receiving PCEP peer (PCE) MAY include an OPEN object within the PCErr message so as to propose alternative acceptable session characteristic values. 7.4. RP Object The RP (Request Parameters) object MUST be carried within each PCReq and PCRep messages and MAY be carried within PCNtf and PCErr messages. The RP object is used to specify various characteristics of the path computation request. The P flag of the RP object MUST be set in PCReq and PCRep messages and MUST be cleared in PCNtf and PCErr messages. If the RP object is received with the P flag set incorrectly according to the rules stated above, the receiving peer MUST send a PCErr message with Error-Type=10 and Error-value=1. The corresponding path computation request MUST be cancelled by the PCE without further notification. 7.4.1. Object Definition RP Object-Class is 2. RP Object-Type is 1. Vasseur & Le Roux Standards Track [Page 27] RFC 5440 PCEP March 2009 The format of the RP object body is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: RP Object Body Format The RP object body has a variable length and may contain additional TLVs. No TLVs are currently defined. Flags (32 bits) The following flags are currently defined: o Pri (Priority - 3 bits): the Priority field may be used by the requesting PCC to specify to the PCE the request's priority from 1 to 7. The decision of which priority should be used for a specific request is a local matter; it MUST be set to 0 when unused. Furthermore, the use of the path computation request priority by the PCE's scheduler is implementation specific and out of the scope of this document. Note that it is not required for a PCE to support the priority field: in this case, it is RECOMMENDED that the PCC set the priority field to 0 in the RP object. If the PCE does not take into account the request priority, it is RECOMMENDED to set the priority field to 0 in the RP object carried within the corresponding PCRep message, regardless of the priority value contained in the RP object carried within the corresponding PCReq message. A higher numerical value of the priority field reflects a higher priority. Note that it is the responsibility of the network administrator to make use of the priority values in a consistent manner across the various PCCs. The ability of a PCE to support request prioritization MAY be dynamically discovered by the PCCs by means of PCE capability discovery. If not advertised by the PCE, a PCC may decide to set the request priority and will learn the ability of the PCE to support request prioritization by observing the Priority field of the RP object received in the PCRep message. If the value of the Pri field is set to 0, this means that the PCE does not support Vasseur & Le Roux Standards Track [Page 28] RFC 5440 PCEP March 2009 the handling of request priorities: in other words, the path computation request has been honored but without taking the request priority into account. o R (Reoptimization - 1 bit): when set, the requesting PCC specifies that the PCReq message relates to the reoptimization of an existing TE LSP. For all TE LSPs except zero-bandwidth LSPs, when the R bit is set, an RRO (see Section 7.10) MUST be included in the PCReq message to show the path of the existing TE LSP. Also, for all TE LSPs except zero-bandwidth LSPs, when the R bit is set, the existing bandwidth of the TE LSP to be reoptimized MUST be supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH object is in addition to the instance of that object used to describe the desired bandwidth of the reoptimized LSP. For zero- bandwidth LSPs, the RRO and BANDWIDTH objects that report the characteristics of the existing TE LSP are optional. o B (Bi-directional - 1 bit): when set, the PCC specifies that the path computation request relates to a bi-directional TE LSP that has the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, TE links, and resource requirements (e.g., latency and jitter) in each direction. When cleared, the TE LSP is unidirectional. o O (strict/loose - 1 bit): when set, in a PCReq message, this indicates that a loose path is acceptable. Otherwise, when cleared, this indicates to the PCE that a path exclusively made of strict hops is required. In a PCRep message, when the O bit is set this indicates that the returned path is a loose path; otherwise (when the O bit is cleared), the returned path is made of strict hops. Unassigned bits are considered reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. Request-ID-number (32 bits): The Request-ID-number value combined with the source IP address of the PCC and the PCE address uniquely identify the path computation request context. The Request-ID- number is used for disambiguation between pending requests, and thus it MUST be changed (such as by incrementing it) each time a new request is sent to the PCE, and may wrap. The value 0x00000000 is considered invalid. If no path computation reply is received from the PCE (e.g., the request is dropped by the PCE because of memory overflow), and the PCC wishes to resend its request, the same Request-ID-number MUST be used. Upon receiving a path computation request from a PCC Vasseur & Le Roux Standards Track [Page 29] RFC 5440 PCEP March 2009 with the same Request-ID-number, the PCE SHOULD treat the request as a new request. An implementation MAY choose to cache path computation replies in order to quickly handle retransmission without having to process a path computation request twice (in the case that the first request was dropped or lost). Upon receiving a path computation reply from a PCE with the same Request-ID- number, the PCC SHOULD silently discard the path computation reply. Conversely, different Request-ID-numbers MUST be used for different requests sent to a PCE. The same Request-ID-number MAY be used for path computation requests sent to different PCEs. The path computation reply is unambiguously identified by the IP source address of the replying PCE. 7.4.2. Handling of the RP Object If a PCReq message is received that does not contain an RP object, the PCE MUST send a PCErr message to the requesting PCC with Error- Type="Required Object missing" and Error-value="RP Object missing". If the O bit of the RP message carried within a PCReq message is cleared and local policy has been configured on the PCE to not provide explicit paths (for instance, for confidentiality reasons), a PCErr message MUST be sent by the PCE to the requesting PCC and the pending path computation request MUST be discarded. The Error-Type is "Policy Violation" and Error-value is "O bit cleared". When the R bit of the RP object is set in a PCReq message, this indicates that the path computation request relates to the reoptimization of an existing TE LSP. In this case, the PCC MUST also provide the strict/loose path by including an RRO object in the PCReq message so as to avoid/limit double-bandwidth counting if and only if the TE LSP is a non-zero-bandwidth TE LSP. If the PCC has not requested a strict path (O bit set), a reoptimization can still be requested by the PCC, but this requires that the PCE either be stateful (keep track of the previously computed path with the associated list of strict hops), or have the ability to retrieve the complete required path segment. Alternatively, the PCC MUST inform the PCE about the working path and the associated list of strict hops in PCReq. The absence of an RRO in the PCReq message for a non-zero- bandwidth TE LSP (when the R bit of the RP object is set) MUST trigger the sending of a PCErr message with Error-Type="Required Object Missing" and Error-value="RRO Object missing for reoptimization". Vasseur & Le Roux Standards Track [Page 30] RFC 5440 PCEP March 2009 If a PCC/PCE receives a PCRep/PCReq message that contains an RP object referring to an unknown Request-ID-number, the PCC/PCE MUST send a PCErr message with Error-Type="Unknown request reference". This is used for debugging purposes. If a PCC/PCE receives PCRep/ PCReq messages with unknown requests at a rate equal or greater than MAX-UNKNOWN-REQUESTS unknown requests per minute, the PCC/PCE MUST send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown requests/replies". A RECOMMENDED value for MAX-UNKNOWN-REQUESTS is 5. The PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP messages on the PCEP session. The reception of a PCEP message that contains an RP object referring to a Request-ID-number=0x00000000 MUST be treated in similar manner as an unknown request. 7.5. NO-PATH Object The NO-PATH object is used in PCRep messages in response to an unsuccessful path computation request (the PCE could not find a path satisfying the set of constraints). When a PCE cannot find a path satisfying a set of constraints, it MUST include a NO-PATH object in the PCRep message. There are several categories of issue that can lead to a negative reply. For example, the PCE chain might be broken (should there be more than one PCE involved in the path computation) or no path obeying the set constraints could be found. The "NI (Nature of Issue)" field in the NO-PATH object is used to report the error category. Optionally, if the PCE supports such capability, the NO-PATH object MAY contain an optional NO-PATH-VECTOR TLV defined below and used to provide more information on the reasons that led to a negative reply. The PCRep message MAY also contain a list of objects that specify the set of constraints that could not be satisfied. The PCE MAY just replicate the set of objects that was received that was the cause of the unsuccessful computation or MAY optionally report a suggested value for which a path could have been found (in which case, the value differs from the value in the original request). NO-PATH Object-Class is 3. NO-PATH Object-Type is 1. Vasseur & Le Roux Standards Track [Page 31] RFC 5440 PCEP March 2009 The format of the NO-PATH object body is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Nature of Issue|C| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: NO-PATH Object Format NI - Nature of Issue (8 bits): The NI field is used to report the nature of the issue that led to a negative reply. Two values are currently defined: 0: No path satisfying the set of constraints could be found 1: PCE chain broken The Nature of Issue field value can be used by the PCC for various purposes: * Constraint adjustment before reissuing a new path computation request, * Explicit selection of a new PCE chain, * Logging of the error type for further action by the network administrator. IANA management of the NI field codespace is described in Section 9. Flags (16 bits). The following flag is currently defined: o C flag (1 bit): when set, the PCE indicates the set of unsatisfied constraints (reasons why a path could not be found) in the PCRep message by including the relevant PCEP objects. When cleared, no failing constraints are specified. The C flag has no meaning and is ignored unless the NI field is set to 0x00. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. Vasseur & Le Roux Standards Track [Page 32] RFC 5440 PCEP March 2009 Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt. The NO-PATH object body has a variable length and may contain additional TLVs. The only TLV currently defined is the NO-PATH- VECTOR TLV defined below. Example: consider the case of a PCC that sends a path computation request to a PCE for a TE LSP of X Mbit/s. Suppose that PCE cannot find a path for X Mbit/s. In this case, the PCE must include in the PCRep message a NO-PATH object. Optionally, the PCE may also include the original BANDWIDTH object so as to indicate that the reason for the unsuccessful computation is the bandwidth constraint (in this case, the NI field value is 0x00 and C flag is set). If the PCE supports such capability, it may alternatively include the BANDWIDTH object and report a value of Y in the bandwidth field of the BANDWIDTH object (in this case, the C flag is set) where Y refers to the bandwidth for which a TE LSP with the same other characteristics (such as Setup/Holding priorities, TE LSP attribute, local protection, etc.) could have been computed. When the NO-PATH object is absent from a PCRep message, the path computation request has been fully satisfied and the corresponding paths are provided in the PCRep message. An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH object in order to provide more information on the reasons that led to a negative reply. The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in Section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the TLV length (length of the value portion in bytes) followed by a fixed-length 32-bit flags field. Type: 1 Length: 4 bytes Value: 32-bit flags field IANA manages the space of flags carried in the NO-PATH-VECTOR TLV (see Section 9). The following flags are currently defined: o Bit number: 31 - PCE currently unavailable o Bit number: 30 - Unknown destination o Bit number: 29 - Unknown source Vasseur & Le Roux Standards Track [Page 33] RFC 5440 PCEP March 2009 7.6. END-POINTS Object The END-POINTS object is used in a PCReq message to specify the source IP address and the destination IP address of the path for which a path computation is requested. The P flag of the END-POINTS object MUST be set. If the END-POINTS object is received with the P flag cleared, the receiving peer MUST send a PCErr message with Error-Type=10 and Error-value=1. The corresponding path computation request MUST be cancelled by the PCE without further notification. Note that the source and destination addresses specified in the END- POINTS object may correspond to the source and destination IP address of the TE LSP or to those of a path segment. Two END-POINTS objects (for IPv4 and IPv6) are defined. END-POINTS Object-Class is 4. END-POINTS Object-Type is 1 for IPv4 and 2 for IPv6. The format of the END-POINTS object body for IPv4 (Object-Type=1) is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: END-POINTS Object Body Format for IPv4 Vasseur & Le Roux Standards Track [Page 34] RFC 5440 PCEP March 2009 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source IPv6 address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: END-POINTS Object Body Format for IPv6 The END-POINTS object body has a fixed length of 8 bytes for IPv4 and 32 bytes for IPv6. If more than one END-POINTS object is present, the first MUST be processed and subsequent objects ignored. 7.7. BANDWIDTH Object The BANDWIDTH object is used to specify the requested bandwidth for a TE LSP. The notion of bandwidth is similar to the one used for RSVP signaling in [RFC2205], [RFC3209], and [RFC3473]. If the requested bandwidth is equal to 0, the BANDWIDTH object is optional. Conversely, if the requested bandwidth is not equal to 0, the PCReq message MUST contain a BANDWIDTH object. In the case of the reoptimization of a TE LSP, the bandwidth of the existing TE LSP MUST also be included in addition to the requested bandwidth if and only if the two values differ. Consequently, two Object-Type values are defined that refer to the requested bandwidth and the bandwidth of the TE LSP for which a reoptimization is being performed. The BANDWIDTH object may be carried within PCReq and PCRep messages. BANDWIDTH Object-Class is 5. Vasseur & Le Roux Standards Track [Page 35] RFC 5440 PCEP March 2009 Two Object-Type values are defined for the BANDWIDTH object: o Requested bandwidth: BANDWIDTH Object-Type is 1. o Bandwidth of an existing TE LSP for which a reoptimization is requested. BANDWIDTH Object-Type is 2. The format of the BANDWIDTH object body is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: BANDWIDTH Object Body Format Bandwidth (32 bits): The requested bandwidth is encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values. The BANDWIDTH object body has a fixed length of 4 bytes. 7.8. METRIC Object The METRIC object is optional and can be used for several purposes. In a PCReq message, a PCC MAY insert one or more METRIC objects: o To indicate the metric that MUST be optimized by the path computation algorithm (IGP metric, TE metric, hop counts). Currently, three metrics are defined: the IGP cost, the TE metric (see [RFC3785]), and the number of hops traversed by a TE LSP. o To indicate a bound on the path cost that MUST NOT be exceeded for the path to be considered as acceptable by the PCC. In a PCRep message, the METRIC object MAY be inserted so as to provide the cost for the computed path. It MAY also be inserted within a PCRep with the NO-PATH object to indicate that the metric constraint could not be satisfied. The path computation algorithmic aspects used by the PCE to optimize a path with respect to a specific metric are outside the scope of this document. Vasseur & Le Roux Standards Track [Page 36] RFC 5440 PCEP March 2009 It must be understood that such path metrics are only meaningful if used consistently: for instance, if the delay of a computed path segment is exchanged between two PCEs residing in different domains, consistent ways of defining the delay must be used. The absence of the METRIC object MUST be interpreted by the PCE as a path computation request for which no constraints need be applied to any of the metrics. METRIC Object-Class is 6. METRIC Object-Type is 1. The format of the METRIC object body is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |C|B| T | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | metric-value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: METRIC Object Body Format The METRIC object body has a fixed length of 8 bytes. Reserved (16 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt. T (Type - 8 bits): Specifies the metric type. Three values are currently defined: * T=1: IGP metric * T=2: TE metric * T=3: Hop Counts Flags (8 bits): Two flags are currently defined: * B (Bound - 1 bit): When set in a PCReq message, the metric- value indicates a bound (a maximum) for the path metric that must not be exceeded for the PCC to consider the computed path as acceptable. The path metric must be less than or equal to the value specified in the metric-value field. When the B flag is cleared, the metric-value field is not used to reflect a bound constraint. Vasseur & Le Roux Standards Track [Page 37] RFC 5440 PCEP March 2009 * C (Computed Metric - 1 bit): When set in a PCReq message, this indicates that the PCE MUST provide the computed path metric value (should a path satisfying the constraints be found) in the PCRep message for the corresponding metric. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. Metric-value (32 bits): metric value encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]). Multiple METRIC objects MAY be inserted in a PCRep or a PCReq message for a given request (i.e., for a given RP). For a given request, there MUST be at most one instance of the METRIC object for each metric type with the same B flag value. If, for a given request, two or more instances of a METRIC object with the same B flag value are present for a metric type, only the first instance MUST be considered and other instances MUST be ignored. For a given request, the presence of two METRIC objects of the same type with a different value of the B flag is allowed. Furthermore, it is also allowed to insert, for a given request, two METRIC objects with different types that have both their B flag cleared: in this case, an objective function must be used by the PCE to solve a multi- parameter optimization problem. A METRIC object used to indicate the metric to optimize during the path computation MUST have the B flag cleared and the C flag set to the appropriate value. When the path computation relates to the reoptimization of an exiting TE LSP (in which case, the R flag of the RP object is set), an implementation MAY decide to set the metric- value field to the computed value of the metric of the TE LSP to be reoptimized with regards to a specific metric type. A METRIC object used to reflect a bound MUST have the B flag set, and the C flag and metric-value field set to the appropriate values. In a PCRep message, unless not allowed by PCE policy, at least one METRIC object MUST be present that reports the computed path metric if the C flag of the METRIC object was set in the corresponding path computation request (the B flag MUST be cleared). The C flag has no meaning in a PCRep message. Optionally, the PCRep message MAY contain additional METRIC objects that correspond to bound constraints; in which case, the metric-value MUST be equal to the corresponding computed path metric (the B flag MUST be set). If no path satisfying the constraints could be found by the PCE, the METRIC objects MAY also be present in the PCRep message with the NO-PATH object to indicate the constraint metric that could be satisfied. Vasseur & Le Roux Standards Track [Page 38] RFC 5440 PCEP March 2009 Example: if a PCC sends a path computation request to a PCE where the metric to optimize is the IGP metric and the TE metric must not exceed the value of M, two METRIC objects are inserted in the PCReq message: o First METRIC object with B=0, T=1, C=1, metric-value=0x0000 o Second METRIC object with B=1, T=2, metric-value=M If a path satisfying the set of constraints can be found by the PCE and there is no policy that prevents the return of the computed metric, the PCE inserts one METRIC object with B=0, T=1, metric- value= computed IGP path cost. Additionally, the PCE may insert a second METRIC object with B=1, T=2, metric-value= computed TE path cost. 7.9. Explicit Route Object The ERO is used to encode the path of a TE LSP through the network. The ERO is carried within a PCRep message to provide the computed TE LSP if the path computation was successful. The contents of this object are identical in encoding to the contents of the Resource Reservation Protocol Traffic Engineering Extensions (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473], and [RFC3477]. That is, the object is constructed from a series of sub-objects. Any RSVP-TE ERO sub-object already defined or that could be defined in the future for use in the RSVP-TE ERO is acceptable in this object. PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types. Since the explicit path is available for immediate signaling by the MPLS or GMPLS control plane, the meanings of all of the sub-objects and fields in this object are identical to those defined for the ERO. ERO Object-Class is 7. ERO Object-Type is 1. 7.10. Reported Route Object The RRO is exclusively carried within a PCReq message so as to report the route followed by a TE LSP for which a reoptimization is desired. The contents of this object are identical in encoding to the contents of the Route Record Object defined in [RFC3209], [RFC3473], and [RFC3477]. That is, the object is constructed from a series of sub- Vasseur & Le Roux Standards Track [Page 39] RFC 5440 PCEP March 2009 objects. Any RSVP-TE RRO sub-object already defined or that could be defined in the future for use in the RSVP-TE RRO is acceptable in this object. The meanings of all of the sub-objects and fields in this object are identical to those defined for the RSVP-TE RRO. PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types. RRO Object-Class is 8. RRO Object-Type is 1. 7.11. LSPA Object The LSPA (LSP Attributes) object is optional and specifies various TE LSP attributes to be taken into account by the PCE during path computation. The LSPA object can be carried within a PCReq message, or a PCRep message in case of unsuccessful path computation (in this case, the PCRep message also contains a NO-PATH object, and the LSPA object is used to indicate the set of constraints that could not be satisfied). Most of the fields of the LSPA object are identical to the fields of the SESSION-ATTRIBUTE object (C-Type = 7) defined in [RFC3209] and [RFC4090]. When absent from the PCReq message, this means that the Setup and Holding priorities are equal to 0, and there are no affinity constraints. See Section 4.7.4 of [RFC3209] for a detailed description of the use of resource affinities. LSPA Object-Class is 9. LSPA Object-Types is 1. Vasseur & Le Roux Standards Track [Page 40] RFC 5440 PCEP March 2009 The format of the LSPA object body is: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclude-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-all | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags |L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: LSPA Object Body Format Setup Prio (Setup Priority - 8 bits): The priority of the TE LSP with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session. Holding Prio (Holding Priority - 8 bits): The priority of the TE LSP with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session. Flags (8 bits) L flag: Corresponds to the "Local Protection Desired" bit ([RFC3209]) of the SESSION-ATTRIBUTE Object. When set, this means that the computed path must include links protected with Fast Reroute as defined in [RFC4090]. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt. Note that optional TLVs may be defined in the future to carry additional TE LSP attributes such as those defined in [RFC5420]. Vasseur & Le Roux Standards Track [Page 41] RFC 5440 PCEP March 2009 7.12. Include Route Object The IRO (Include Route Object) is optional and can be used to specify that the computed path MUST traverse a set of specified network elements. The IRO MAY be carried within PCReq and PCRep messages. When carried within a PCRep message with the NO-PATH object, the IRO indicates the set of elements that cause the PCE to fail to find a path. IRO Object-Class is 10. IRO Object-Type is 1. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Sub-objects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: IRO Body Format Sub-objects: The IRO is made of sub-objects identical to the ones defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO sub- object type is identical to the sub-object type defined in the related documents. The following sub-object types are supported. Type Sub-object 1 IPv4 prefix 2 IPv6 prefix 4 Unnumbered Interface ID 32 Autonomous system number The L bit of such sub-object has no meaning within an IRO. 7.13. SVEC Object 7.13.1. Notion of Dependent and Synchronized Path Computation Requests Independent versus dependent path computation requests: path computation requests are said to be independent if they are not related to each other. Conversely, a set of dependent path computation requests is such that their computations cannot be performed independently of each other (a typical example of dependent requests is the computation of a set of diverse paths). Vasseur & Le Roux Standards Track [Page 42] RFC 5440 PCEP March 2009 Synchronized versus non-synchronized path computation requests: a set of path computation requests is said to be non-synchronized if their respective treatment (path computations) can be performed by a PCE in a serialized and independent fashion. There are various circumstances where the synchronization of a set of path computations may be beneficial or required. Consider the case of a set of N TE LSPs for which a PCC needs to send path computation requests to a PCE. The first solution consists of sending N separate PCReq messages to the selected PCE. In this case, the path computation requests are non-synchronized. Note that the PCC may chose to distribute the set of N requests across K PCEs for load balancing purposes. Considering that M (with M+-+-+-+-+-+-+ | | | | | KeepWait |----+ | | +--| |<---+ | |+-----+-+-+-+-+-+-+ | | || | | | || | | | || V | | || +->+-+-+-+-+-+-+----+ | || | | OpenWait |-------+ || +--| |<------+ ||+----+-+-+-+-+-+-+<---+ | ||| | | | ||| | | | ||| V | | ||| +->+-+-+-+-+-+-+ | | ||| | |TCPPending |----+ | ||| +--| | | |||+---+-+-+-+-+-+-+<---+ | |||| | | | |||| | | | |||| V | | |||+--->+-+-+-+-+ | | ||+---->| Idle |-------+ | |+----->| |----------+ +------>+-+-+-+-+ Figure 23: PCEP Finite State Machine for the PCC PCEP defines the following set of variables: Connect: the timer (in seconds) started after having initialized a TCP connection using the PCEP-registered TCP port. The value of the Connect timer is 60 seconds. ConnectRetry: the number of times the system has tried to establish a TCP connection with a PCEP peer without success. Vasseur & Le Roux Standards Track [Page 79] RFC 5440 PCEP March 2009 ConnectMaxRetry: the maximum number of times the system tries to establish a TCP connection using the PCEP-registered TCP port before going back to the Idle state. The value of the ConnectMaxRetry is 5. OpenWait: the timer that corresponds to the amount of time a PCEP peer will wait to receive an Open message from the PCEP peer after the expiration of which the system releases the PCEP resource and goes back to the Idle state. The OpenWait timer has a fixed value of 60 seconds. KeepWait: the timer that corresponds to the amount of time a PCEP peer will wait to receive a Keepalive or a PCErr message from the PCEP peer after the expiration of which the system releases the PCEP resource and goes back to the Idle state. The KeepWait timer has a fixed value of 60 seconds. OpenRetry: the number of times the system has received an Open message with unacceptable PCEP session characteristics. The following two state variables are defined: RemoteOK: a boolean that is set to 1 if the system has received an acceptable Open message. LocalOK: a boolean that is set to 1 if the system has received a Keepalive message acknowledging that the Open message sent to the peer was valid. Idle State: The idle state is the initial PCEP state where the PCEP (also referred to as "the system") waits for an initialization event that can either be manually triggered by the user (configuration) or automatically triggered by various events. In Idle state, PCEP resources are allocated (memory, potential process, etc.) but no PCEP messages are accepted from any PCEP peer. The system listens to the PCEP-registered TCP port. The following set of variables are initialized: TCPRetry=0, LocalOK=0, RemoteOK=0, OpenRetry=0. Vasseur & Le Roux Standards Track [Page 80] RFC 5440 PCEP March 2009 Upon detection of a local initialization event (e.g., user configuration to establish a PCEP session with a particular PCEP peer, local event triggering the establishment of a PCEP session with a PCEP peer such as the automatic detection of a PCEP peer), the system: o Initiates a TCP connection with the PCEP peer, o Starts the Connect timer, o Moves to the TCPPending state. Upon receiving a TCP connection on the PCEP-registered TCP port, if the TCP connection establishment succeeds, the system: o Sends an Open message, o Starts the OpenWait timer, o Moves to the OpenWait state. If the connection establishment fails, the system remains in the Idle state. Any other event received in the Idle state is ignored. It is expected that an implementation will use an exponentially increasing timer between automatically generated Initialization events and between retries of TCP connection establishment. TCPPending State: If the TCP connection establishment succeeds, the system: o Sends an Open message, o Starts the OpenWait timer, o Moves to the OpenWait state. If the TCP connection establishment fails (an error is detected during the TCP connection establishment) or the Connect timer expires: o If ConnectRetry = ConnectMaxRetry, the system moves to the Idle State. Vasseur & Le Roux Standards Track [Page 81] RFC 5440 PCEP March 2009 o If ConnectRetry < ConnectMaxRetry, the system: 1. Initiates of a TCP connection with the PCEP peer, 2. Increments the ConnectRetry variable, 3. Restarts the Connect timer, 4. Stays in the TCPPending state. In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state. OpenWait State: In the OpenWait state, the system waits for an Open message from its PCEP peer. If the system receives an Open message from the PCEP peer before the expiration of the OpenWait timer, the system first examines all of its sessions that are in the OpenWait or KeepWait state. If another session with the same PCEP peer already exists (same IP address), then the system performs the following collision-resolution procedure: o If the system has initiated the current session and it has a lower IP address than the PCEP peer, the system closes the TCP connection, releases the PCEP resources for the pending session, and moves back to the Idle state. o If the session was initiated by the PCEP peer and the system has a higher IP address that the PCEP peer, the system closes the TCP connection, releases the PCEP resources for the pending session, and moves back to the Idle state. o Otherwise, the system checks the PCEP session attributes (Keepalive frequency, DeadTimer, etc.). If an error is detected (e.g., malformed Open message, reception of a message that is not an Open message, presence of two OPEN objects), PCEP generates an error notification, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=1. The system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state. Vasseur & Le Roux Standards Track [Page 82] RFC 5440 PCEP March 2009 If no errors are detected, OpenRetry=1, and the session characteristics are unacceptable, the PCEP peer sends a PCErr with Error-Type=1 and Error-value=5, and the system releases the PCEP resources for that peer and moves back to the Idle state. If no errors are detected, and the session characteristics are acceptable to the local system, the system: o Sends a Keepalive message to the PCEP peer, o Starts the Keepalive timer, o Sets the RemoteOK variable to 1. If LocalOK=1, the system clears the OpenWait timer and moves to the UP state. If LocalOK=0, the system clears the OpenWait timer, starts the KeepWait timer, and moves to the KeepWait state. If no errors are detected, but the session characteristics are unacceptable and non-negotiable, the PCEP peer sends a PCErr with Error-Type=1 and Error-value=3, and the system releases the PCEP resources for that peer and moves back to the Idle state. If no errors are detected, and OpenRetry is 0, and the session characteristics are unacceptable but negotiable (such as, the Keepalive period or the DeadTimer), then the system: o Increments the OpenRetry variable, o Sends a PCErr message with Error-Type=1 and Error-value=4 that contains proposed acceptable session characteristics, o If LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait state. o If LocalOK=0, the system clears the OpenWait timer, starts the KeepWait timer, and moves to the KeepWait state. If no Open message is received before the expiration of the OpenWait timer, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=2, the system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state. In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state. Vasseur & Le Roux Standards Track [Page 83] RFC 5440 PCEP March 2009 KeepWait State: In the Keepwait state, the system waits for the receipt of a Keepalive from its PCEP peer acknowledging its Open message or a PCErr message in response to unacceptable PCEP session characteristics proposed in the Open message. If an error is detected (e.g., malformed Keepalive message), PCEP generates an error notification, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=1. The system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state. If a Keepalive message is received before the expiration of the KeepWait timer, then the system sets LocalOK=1 and: o If RemoteOK=1, the system clears the KeepWait timer and moves to the UP state. o If RemoteOK=0, the system clears the KeepWait timer, starts the OpenWait timer, and moves to the OpenWait State. If a PCErr message is received before the expiration of the KeepWait timer: 1. If the proposed values are unacceptable, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=6, and the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle state. 2. If the proposed values are acceptable, the system adjusts its PCEP session characteristics according to the proposed values received in the PCErr message, restarts the KeepWait timer, and sends a new Open message. If RemoteOK=1, the system restarts the KeepWait timer and stays in the KeepWait state. If RemoteOK=0, the system clears the KeepWait timer, starts the OpenWait timer, and moves to the OpenWait state. If neither a Keepalive nor a PCErr is received after the expiration of the KeepWait timer, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=7, and the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State. In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state. Vasseur & Le Roux Standards Track [Page 84] RFC 5440 PCEP March 2009 UP State: In the UP state, the PCEP peer starts exchanging PCEP messages according to the session characteristics. If the Keepalive timer expires, the system restarts the Keepalive timer and sends a Keepalive message. If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from the PCEP peer before the expiration of the DeadTimer, the system terminates the PCEP session according to the procedure defined in Section 6.8, releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State. If a malformed message is received, the system terminates the PCEP session according to the procedure defined in Section 6.8, releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle State. If the system detects that the PCEP peer tries to set up a second TCP connection, it stops the TCP connection establishment and sends a PCErr with Error-Type=9. If the TCP connection fails, the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State. Appendix B. PCEP Variables PCEP defines the following configurable variables: Keepalive timer: minimum period of time between the sending of PCEP messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A suggested value for the Keepalive timer is 30 seconds. DeadTimer: period of timer after the expiration of which a PCEP peer declares the session down if no PCEP message has been received. SyncTimer: timer used in the case of synchronized path computation request using the SVEC object defined in Section 7.13.3. Consider the case where a PCReq message is received by a PCE that contains the SVEC object referring to M synchronized path computation requests. If after the expiration of the SyncTimer all the M path computation requests have not been received, a protocol error is triggered and the PCE MUST cancel the whole set of path computation requests. The aim of the SyncTimer is to avoid the storage of unused synchronized requests should one of them get lost for some reason (e.g., a misbehaving PCC). Thus, the value Vasseur & Le Roux Standards Track [Page 85] RFC 5440 PCEP March 2009 of the SyncTimer must be large enough to avoid the expiration of the timer under normal circumstances. A RECOMMENDED value for the SyncTimer is 60 seconds. MAX-UNKNOWN-REQUESTS: A RECOMMENDED value is 5. MAX-UNKNOWN-MESSAGES: A RECOMMENDED value is 5. Appendix C. Contributors The content of this document was contributed by those listed below and the editors listed at the end of the document. Arthi Ayyangar Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA EMail: arthi@juniper.net Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo, 180-8585 JAPAN EMail: oki.eiji@lab.ntt.co.jp Alia Atlas British Telecom EMail: akatlas@alum.mit.edu Vasseur & Le Roux Standards Track [Page 86] RFC 5440 PCEP March 2009 Andrew Dolganow Alcatel 600 March Road Ottawa, ON K2K 2E6 CANADA EMail: andrew.dolganow@alcatel.com Yuichi Ikejiri NTT Communications Corporation 1-1-6 Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-819 JAPAN EMail: y.ikejiri@ntt.com Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460 JAPAN EMail: ke-kumaki@kddi.com Authors' Addresses JP Vasseur (editor) Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com JL Le Roux (editor) France Telecom 2, Avenue Pierre-Marzin Lannion 22307 FRANCE EMail: jeanlouis.leroux@orange-ftgroup.com Vasseur & Le Roux Standards Track [Page 87]