Network Working Group JP Vasseur (Editor) Cisco System Inc. IETF Internet Draft JL Le Roux France Telecom Arthi Ayyangar Juniper Networks Eiji Oki Yuichi Ikejiri NTT Alia Atlas Google, Inc Andrew Dolganow Alcatel Proposed Status: Standard Expires: May 2006 November 2005 Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 - draft-ietf-pce-pcep-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Vasseur et al. [Page 1] Internet Draft draft-ietf-pce-pcep-02 November 2005 Abstract This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (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 MPLS and GMPLS Traffic Engineering. The PCEP protocol 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. Conventions used in this document 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. Table of Contents 1. Terminology................................................3 2. Introduction...............................................4 3. Assumptions................................................4 4. Transport protocol.........................................5 5. Architectural Protocol Overview (Model)....................5 5.1. Problem..................................................5 5.2. Architectural Protocol Overview..........................6 5.2.1. Initialization phase...................................6 5.2.2. Path computation request sent by a PCC to a PCE........7 5.2.3. Path computation reply sent by the PCE to a PCC........8 5.2.4. Notifications..........................................9 5.2.5. Termination of the PCEP Session........................10 6. PCEP messages..............................................10 6.1. Common header............................................10 6.2. Open message.............................................11 6.3. Keepalive message........................................13 6.4. Path Computation Request (PCReq) message.................13 6.5. Path Computation Reply (PCRep) message...................14 6.6. Notification (PCNtf) message.............................15 6.7. Error (PCErr) message....................................15 7. Object Formats.............................................16 7.1. Common object header.....................................16 7.2. OPEN Object..............................................18 7.3. RP Object................................................19 7.4. NO-PATH Object...........................................20 7.5. END-POINTS Object........................................21 7.6. BANDWIDTH object.........................................22 7.7. DELAY Object.............................................23 7.8. ERO Object...............................................24 7.9. RRO Object...............................................24 Vasseur et al. [Page 2] Internet Draft draft-ietf-pce-pcep-02 November 2005 7.10. LSPA Object.............................................24 7.11. IRO Object..............................................26 7.12. SVEC Object.............................................27 7.13. NOTIFICATION object.....................................28 7.14. PCEP-ERROR object.......................................31 8. Independent versus synchronized path computation requests..34 9. Elements of procedure......................................35 9.1. Non recognized or non support object received in a PCReq message 9.2. RP object................................................35 9.3. SVEC object..............................................36 10. Manageability Considerations..............................36 11. IANA Considerations.......................................36 11.1. TCP port................................................36 11.2. PCEP Objects............................................36 11.3. Notification............................................39 11.4. PCEP Error..............................................39 12. Security Considerations...................................40 12.1. PCEP Authentication and Integrity.......................40 12.2. PCEP Privacy............................................40 12.3. Protection against Denial of Service attacks............41 13. Intellectual Property Statement...........................41 14. Acknowledgment............................................42 15. References................................................42 15.1. Normative references....................................42 15.2. Informative References..................................43 16. Authors' Address..........................................44 Appendix A: Compliance of PCEP to the set of requirements specified in draft-ietf-pce-comm-protocol-gen-reqs........... 45 1. Terminology Terminology used in this document IGP Area: OSPF Area or IS-IS level Inter-domain TE LSP: A TE LSP whose path transits across at least two different domains where a domain can either be an IGP area, an Autonomous System or a sub-AS (BGP confederations). 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 the PCE). Vasseur et al. [Page 3] Internet Draft draft-ietf-pce-pcep-02 November 2005 PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a Detour LSP. TED: Traffic Engineering Database which contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means. 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. Strict/loose path: mix of strict and loose hops comprising of at least one loose hop representing the destination where a hop may be an abstract node such as an AS. Within this document, when PCE-PCE communications are being described, the requesting PCE fills the role of a PCC. This provides a saving in documentation without loss of function. 2. Introduction [PCE-ARCH] describes the motivations and architecture for a PCE-based model to perform path computation for MPLS and GMPLS TE LSPs. The model allows the separation of PCE from PCC, and allows cooperation between PCEs. This necessitates a communication protocol between PCC and PCE, and between PCEs. [PCE-COM-GEN-REQ] states the generic requirements for such a protocol including a requirement that the same protocol must 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 [PCE-COM-GEN-REQ], 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. This document specifies the Path Computation Element communication Protocol (PCEP) for communications between Path Computation Client (PCC) and a Path Computation Element (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 MPLS and GMPLS Traffic Engineering. The PCEP protocol 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. The compliance of PCEP to the set of requirements stated in [PCE-COM- GEN-REQ] is covered in Appendix A. 3. Assumptions Vasseur et al. [Page 4] Internet Draft draft-ietf-pce-pcep-02 November 2005 [PCE-ARCH] describes various types of PCE: it is important to note that no assumption is made on the nature of the PCE in this document. Moreover, it is assumed that the PCE gets the required information so as to perform TE LSP path computation which usually requires network topology and resource information that can be gathered by routing protocols or by some other means. The retrieval of such information is out of the scope of this document. Similarly, no assumption is made on the discovery method used by a PCC to discover a set of PCEs (e.g. via static configuration or dynamic discovery) and select a PCE to send its path computation request(s) to. For the sake of reference [PCE-DISC-REQ] defines a list of requirements for dynamic PCE discovery. 4. Transport protocol PCEP operates over TCP using the well-known TCP port (TBD by IANA). This allows the requirements of reliable messaging and flow control to be met without further protocol work. An implementation may decide to keep the TCP session alive for an unlimited time (this may for instance be the case should an implementation have to send new requests frequently in which case the TCP session will already be in place). Another motivation for leaving the TCP connection open would be to avoid TCP connection establishment time. This mode is also referred to as the "Permanent mode". Conversely, in some other circumstances, it may be desirable to systematically open and close the TCP connection for each PCEP request (this may for instance be the case if sending of PCEP path computation request is a rare event). This mode is referred to as the "Per-request mode". Since there are circumstances where the TCP connection state is used to detect the PCC/PCE liveness (e.g case of a stateful PCE detecting a PCC failure thanks to the TCP state), the desired mode MUST be known by both the PCC and the PCE and is determined during the initialization phase. 5. Architectural Protocol Overview (Model) The aim of this section is to describe the PCEP protocol model in the spirit of [WP]. An architecture protocol overview (the big picture of the protocol) is provided in this section where details of the protocol can be found in further sections. 5.1. Problem The PCE-based architecture used for the computation of MPLS and GMPLS TE LSP paths is described in [PCE-ARCH]. When the PCC and the PCE are not collocated, a communication protocol between the PCC and the PCE is required. PCEP is such a protocol designed specifically for Vasseur et al. [Page 5] Internet Draft draft-ietf-pce-pcep-02 November 2005 communications between a PCC and a PCE or between two PCEs: a PCC may use PCEP to send a path computation request for one or more TE LSP(s) to a PCE and such a PCE may reply with a set of computed path(s) if one or more path(s) obeying the set of constraints can be found. 5.2. Architectural Protocol Overview PCEP operates over TCP, which allows the requirements of reliable messaging and flow control to be met without further protocol work. Several PCEP messages are defined: - Open and Keepalive messages are used to initiate and maintain a PCEP session respectively. - PCReq: a message sent by a PCC to a PCE to request a path computation. - PCRep: a message sent by a PCE to a PCC in reply to a path computation request. A PCRep message can either contain a set of computed path(s) if the request could be satisfied or a negative reply otherwise. - PCNtf: a notification message either sent by a PCC to a PCE or a PCE to a PCC to notify of specific event. - PCErr: a message related to a protocol error condition. The set of available PCE(s) may be either statically configured on a PCC or dynamically discovered (the mechanism for that discovery is 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. A PCEP session establishment can either be triggered by the PCC or the PCE. 5.2.1 Initialization phase The initialization phase consists of two successive steps: 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 a PCEP session establishment during which various session parameters are advertised. Those parameters are carried within Open messages and include the keepalive timer, the PCEP session mode (per-request or permanent), potential 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 exchanged parameters or one of the peers does not answer, the transport connection is immediately closed. Successive retries are permitted but an implementation SHOULD make use of exponential back-off. Keepalive messages are used to acknowledge Open messages and once the PCEP session is established Keepalive messages Vasseur et al. [Page 6] Internet Draft draft-ietf-pce-pcep-02 November 2005 are exchanged between PCEP peers to ensure the liveness of the PCEP session. +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |---- Open message --->| | | |<--- Open message ----| | | | | | | |<--- Keepalive -------| | | |---- Keepalive ------>| Figure 1: PCEP Initialization phase (triggered by a PCC) 5.2.2. Path computation request sent by a PCC to a PCE Consider the diagram depicted in figure 2. +-+-+ +-+-+ |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 (or a PCE) has successfully established a PCEP session with one or more PCEs, if an event is triggered that requires the computation of a path, the PCC first selects the PCE it desires to send a path computation request to (note that the PCE selection may be performed prior to the PCEP session establishment). Once a 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=X Mbit/s, Priority=Y, ...". Additionally, the PCC may desire to specify the urgency of such request by assigning a request priority. It is worth pointing out that each request is uniquely identified by a request-id number and the PCC-PCE addresses pair. The process is shown in a schematic form in figure 2. Vasseur et al. [Page 7] Internet Draft draft-ietf-pce-pcep-02 November 2005 5.2.3. 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 path(s) sent | |to the PCC |<--- PCRep message ---| | (Positive reply) | Figure 3a: Path computation request with successful computation +-+-+ +-+-+ |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 unsuccessfull computation Upon receiving a path computation request from a PCC, the PCE triggers a path computation, the result of which can either be: - Positive: the PCE manages to compute a path satisfying the set of required constraints and returns the set of computed path(s) (note that the PCEP protocol supports the capability to send a single request which refers to the computation of multiple paths: for example, compute two link diverse paths). This is illustrated in figure 3a. Vasseur et al. [Page 8] Internet Draft draft-ietf-pce-pcep-02 November 2005 - Negative: no path could be computed that satisfies the request. In this case, a PCE may provide the set of constraints that led to path computation failure. Upon receiving a negative reply, a PCC may decide to resend a modified request or take any other appropriate action. This is illustrated in figure 3b. 5.2.4 Notifications There are several circumstances whereby a PCE may want to notify a PCC of a specific event. For example, suppose that the PCE suddenly experiences some congestion that would lead 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, potentially resulting in path computation redirections on the PCC towards another PCE, if an alternate PCE is available. Similarly, a PCC may desire to notify a PCE of particular event such as the cancellation of pending request(s). +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ 1)Path computation | | event | | 2)PCE Selection | | 3)Path computation |---- PCReq message--->| request X sent to | |4) Path computation the selected PCE | |triggered | | | | 5) Path computation| | request X cancelled| | |---- PCNtf message -->| | |6) Path computation | |request X cancelled Figure 4: Example of PCC notification (request cancellation) 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 | |triggered | | | | | |5) PCE experiencing | |congestion Vasseur et al. [Page 9] Internet Draft draft-ietf-pce-pcep-02 November 2005 | | | |6) Path computation | |request X cancelled | | |<--- PCNtf message----| Figure 5: Example of PCEP notification (request(s) cancellation) send to a PCC 5.2.5. Termination of the PCEP Session When one of the PCEP peers desires to terminate a PCEP session it MUST close the TCP connection. If the PCEP session is terminated by the PCE, the PCC MUST clear all the states related to pending requests sent to the PCE. Similarly, if the PCC terminates a PCEP session the PCE MUST clear all pending path computation requests sent by the PCC in question as well as the related states. In case of TCP connection failure, the PCEP session SHOULD be maintained for a period of time equal to the Deadtimer. 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 in such message for the message to be valid. Conversely, an object is said to be optional the object may or may not be present. As specified in section 7.1, a specific flag is also defined in each object that can be set by a PCEP peer to enforce a PCE to take into account the related information during the path computation. For example, the DELAY object allows a PCC to specify in a path computation request a bounded acceptable delay for the computed path. The DELAY object is optional (does not have to be present in each path computation request message) but a PCC may set a flag to ensure that the delay constraint is being taken into account when present in a message. For each PCEP message type a set of rules is defined which specifies the set of possible objects that the message can carry. We use the Backus-Naur Form (BNF) to specify such rules. Square brackets refer to optional sub-sequences. An implementation MUST form the PCEP messages using the order specified in this document. If a mandatory object is missing in a received PCEP message the recipient of the PCEP message MUST trigger a protocol error condition. 6.1. Common header 0 1 2 3 Vasseur et al. [Page 10] Internet Draft draft-ietf-pce-pcep-02 November 2005 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 | Message-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 - PCEP message common header Ver (Version): 3 bits PCEP protocol version number. The current version is version 1 Flags: 8 bits No Flags are currently defined Message Length: 24 bits Total length of the PCEP message expressed in bytes including the common header. 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 6.2. Open message 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. The aim of the Open message is to establish a PCEP session between the PCEP peers. During that phase the PCEP peers exchange several session characteristics. If both parties agree on such characteristics the PCEP session is successfully established. The Message-Type field of the PCEP common header for the Open message is set to 1. ::= The Open message MUST only contain a single OPEN object defined in section 7. The various session characteristics specified within the OPEN object are the keepalive frequency, session mode (permanent or Vasseur et al. [Page 11] Internet Draft draft-ietf-pce-pcep-02 November 2005 per-request) and potentially some optional parameters such as the detailed PCE capabilities and policy rules that specify the conditions under which path computation requests may be sent to the PCE. Details related to PCE capabilities discovery by means of PCEP are out of the scope of this document. Keepalive: PCEP has its own keepalive mechanism used to ensure of the liveness of the PCEP session. This requires the determination of the frequency at which each PCEP peer sends the keepalive messages. Asymmetric values may be chosen; thus there is no constraints 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). The minimum Keepalive value is 1 second and the Deadtimer value is equal to 4 times the Keepalive value. Session mode: PCEP supports two session modes referred to as the "permanent" and "per-request" modes. In the permanent mode, the PCEP peers maintained a permanent PCEP session (and thus the TCP session is also maintained) regardless of the rate at which PCEP messages are exchanged. Such mode would typically be used to speed-up response times. In the permanent mode, a loss of TCP session MUST be interpreted as a communication failure. Conversely, in the "per-request" mode, a PCEP session is established on-demand, when one or more path computation requests are required and then closed by the PCC once those path computation requests are satisfied. Both PCEP peers MUST agree on the session mode; in case of disagreement, the PCEP session establishment fails. Elements of procedure: - Once an Open message has been sent to a PCEP peer, the sender MUST start an initialization timer called INIT-OPEN after the expiration of which a similar Open message MUST be resent if no reply has been received from the PCEP peer. The INIT-OPEN timer has a fixed value of one minute. The maximum number of Open messages that can be sent without any response from the PCEP peer is equal to 3. - Upon the receipt of an Open message, the receiving PCEP peer MUST determine whether the suggested PCEP session characteristics are acceptable. If one or more characteristic(s) is not acceptable by the receiving peer, it MUST send a PCErr message with Error-type=8, Error-value=1. The PCErr message MUST also comprise an Open object: for each unacceptable session parameter, an acceptable parameter value MUST 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. Consecutive retries SHOULD make use of exponential back-off so as to avoid undesirable burden of session initialization. If a second Open message is received with the same set of parameters or with parameters differing from the proposed values, the receiving peer Vasseur et al. [Page 12] Internet Draft draft-ietf-pce-pcep-02 November 2005 MUST send a PCErr message with Error-Type=8, Error-value=2 and it MUST immediately close the TCP connection. If the PCEP session characteristics are acceptable, the receiving PCEP peer MUST immediately send a Keepalive message as an acknowledgment. The PCEP session is considered as operational once both PCEP peers have received a Keepalive message from their peer. 6.3. Keepalive message Keepalive messages are used either to acknowledge an Open message if the receiving PCEP peer agrees on the session characteristics and to ensure the liveness of the PCEP session. Keepalive messages are sent at the frequency specified in the OPEN object carried within an Open message. The Message-Type field of the PCEP common header for the Open message is set to 2. ::= 6.4. Path Computation Request (PCReq) message A Path Computation Request message (also referred to as a PCReq message) is sent by a PCC to a PCE so as to request a path computation. The Message-Type field of the PCEP common header 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 of these objects is missing, the receiving PCE MUST send an error message to the requester (PCErr message). Other objects are optional. The format of a PCReq message is as follows: ::= [] where: ::=[] ::=[] ::= [] [] [] [] [] Vasseur et al. [Page 13] Internet Draft draft-ietf-pce-pcep-02 November 2005 [] The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, DELAY, ERO, XRO and IRO objects are defined in section 7. 6.5. Path Computation Reply (PCRep) message The PCEP Path Computation reply message (also referred to as a PCRep message) is 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 is set to 4. The PCRep message MUST comprise a RP object with a Request-ID-number identical to the one specified in the RP object carried in the corresponding PCReq message (see section 7 for the definition of the RP object). A PCRep may comprise multiple computed path(s) corresponding to multiple path computation requests originated by a common requesting PCC. The bundling of multiple responses within a single PCRep message is supported by the PCEP protocol. 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. If the path computation request can be successfully satisfied (the PCE manages to compute a set of path(s) that obey the requested constraint(s)), the set of computed path(s) specified by means of ERO object(s) is inserted in the PCRep message. Such a situation where multiple computed paths are provided in a PCRep message is discussed in detail in section 8. If the path computation request cannot be satisfied, the PCRep message MUST include a NO-PATH object. The NO-PATH object (further described in section 7) may also comprise other information (e.g reasons for the path computation failure). The format of a PCRep message is as follows: ::= [] where: ::=[] ::=[] ::= [] Vasseur et al. [Page 14] Internet Draft draft-ietf-pce-pcep-02 November 2005 [] [] [] [] [] [] where: :==[ 6.6. Notification (PCNtf) message The PCEP Notification message (also referred to as the PCNtf message) can either be sent by a PCE to a PCC or by a PCC to a PCE so as to notify of a specific event. The Message-Type field of the PCEP common header is set to 5. The PCNtf message MUST carry at least one NOTIFICATION object and may comprise several NOTIFICATION objects should the PCE or the PCC intend to notify of multiple events. The NOTIFICATION object is defined in section 7. The PCNtf message may also comprise an RP object when the notification refers to a particular path computation request. The PCNtf message may be sent by a PCC or a PCE in response to a request or in an unsolicited manner. The format of a PCNtf message is as follows: ::= ::= [] ::= [] :== := The procedure upon the reception of a PCNtf message is defined in section 9. 6.7. Error (PCErr) message The PCEP Error message (also referred to as a PCErr message) is sent when a protocol error condition is met. The Message-Type field of the PCEP common header is set to 6. The PCErr message may be sent by a PCC or a PCE in response to a request or in an unsolicited manner. In the former case, the PCErr message MUST include the set of RP objects related to the pending Vasseur et al. [Page 15] Internet Draft draft-ietf-pce-pcep-02 November 2005 path computation request(s) which triggered the protocol error condition. In the later case (unsolicited), no RP object is inserted within the PCErr message. No RP object is inserted in a PCErr when the error condition occurred during the initialization phase. A PCErr message MUST comprise a PCEP-ERROR object specifying the PCEP error condition. The PCEP-ERROR object is defined in section 7. The format of a PCErr message is as follows: ::= [] :==[] ::=[] :==[] :==[] The procedure upon the reception of a PCErr message is defined in section 9. 7. Object Formats 7.1. Common object header A PCEP object carried within a PCEP message consists of one or more 32-bit words with a common header which 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|I|P| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object body) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 - PCEP common object header Object-Class (to be managed by IANA) 8-bit field that identifies the PCEP object class OT (Object-Type) (to be managed by IANA) 4-bit field that identifies the PCEP object type P flag (Processing-Rule) Vasseur et al. [Page 16] Internet Draft draft-ietf-pce-pcep-02 November 2005 1-bit flag which specifies whether the object must be taken into account by the receiving PCEP peer or is just optional. When the P flag is cleared, the object MUST be taken into account by the receiving entity. If the PCC or the PCE does not understand the object or understands the object but decides to ignore the object, this MUST trigger a protocol error condition as defined in section 7. Conversely, when the P flag is set the object is optional and can be silently ignored. I flag 1-bit flag: the PCE set the I flag when the object is carried within a PCRep message so as to indicate when the constraint was optional and was ignored during path computation. Res flags: 2-bit flag reserved (MUST be set to 0) Object Length 16-bit field containing the total object length 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. The Object-Class and Object-Type fields uniquely identify each PCEP object. The P bit is used to determine what action a node should take if it does not recognize the Object-Class or Object-Type of a PCEP object or decides not to take into account the object: there are two possible ways a PCEP implementation can react. This choice is determined by the P bit, as follows. If P flag=0 The entire PCEP message MUST be rejected and the receiving PCEP peer MUST send a PCErr message with a PCEP-ERROR Object ("Unkown Object" or "Not supported Object"). If P flag=1 The node MAY ignore the object and process the PCEP message if possible. In that case (the message can be processed by ignoring the object in question), the PCE SHOULD include the object in the corresponding PCERep message. The I flag of the common header for this object MUST be set. If the path computation cannot be performed, a PCErr message MUST be sent to the requesting entity with a PCEP- ERROR object (Error-type=2, "Unknown Object"). Vasseur et al. [Page 17] Internet Draft draft-ietf-pce-pcep-02 November 2005 7.2. OPEN Object The OPEN object MUST be present in each Open message. There MUST be only one OPEN object per Open message. The OPEN object contains a set of fields used to specify the PCEP protocol version, Keepalive frequency, 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 capability, policy rules and so on. No TLV is currently defined. OPEN Object-Class is to be assigned by IANA (recommended value=1) OPEN Object-Type is to be assigned by IANA (recommended value=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 | Keepalive | SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 - OPEN Object format Version (Ver): 3 bits - Current version is 1. Keepalive frequency (Keepalive): 16 bits. Specifies the frequency in seconds at which the sender of the Open message will send Keepalive messages. The minimum value for the Keepalive is 1 second. When set to 0, no keepalive is sent to the remote peer. A RECOMMENDED value for the keepalive frequency is 30 seconds. PCEP session-ID (SID): 13 bits. Specifies a 2 octet unsigned PCEP session number that identifies the current session. The SID MUST be incremented each time a new PCEP session is established. Flags One flag is currently defined. R flag: when cleared, this indicates that the sending PCEP peer requires the establishment of a PCEP session in permanent mode. When set, a per-request mode is requested. Vasseur et al. [Page 18] Internet Draft draft-ietf-pce-pcep-02 November 2005 Optional TLVs may be included within the Open message body to specify PCC or PCE characteristics. 7.3. RP Object The RP (Request Parameters) object MUST be carried within every PCReq and PCRep messages and MAY be carried within PCNtf and PCErr messages. RP Object-Class is to be assigned by IANA (recommended value=2) RP Object-Type is to be assigned by IANA (recommended value=1) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |O|C|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 - RP object body format The RP object has a variable length and may contain additional TLVs. No TLV is currently defined. Flags: 18 bits - The following flags are currently defined: Pri (Priority) field (3 bits) This field may be used by the requesting PCC to specify to the PCE the request's priority. The decision of which priority should be used for a specific request is of a local matter and MUST be set to 0 when unused. Furthermore, the use of the path computation request priority by the PCE's requests 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 that case, the priority field SHOULD be set to 0 by the PCC 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 PCC(s). The ability of a PCE to support requests prioritization may be dynamically discovered by Vasseur et al. [Page 19] Internet Draft draft-ietf-pce-pcep-02 November 2005 the PCC(s) 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 the 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 the Pri field: in other words, the path computation request has been honoured but without taking the request priority into account. R (Reoptimization) bit: when set, the requesting PCC specifies that the PCReq message relates to the reoptimization of an existing TE LSP in which case the path of the existing TE LSP to be reoptimized MUST be provided in the PCReq message by means of an RRO object defined in section 7. B (Bi-directional) bit: when set, the PCC specifies that the path computation request relates to a bidirectional TE LSP (LSPs that have the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, and resource requirements (e.g., latency and jitter) in each direction). When cleared, the TE LSP is unidirectional. C (Cost) bit: when set, the PCE MUST provide the cost of the computed path in the PCRep message. O (strict/lOose): In a PCReq message, when set, this means that a strict/loose path is acceptable. Otherwise, when cleared, this indicates to the PCE that an explicit path is required. In a PCRep message, when the O bit is set this indicates that the returned path is strict/loose, otherwise (the O bit is cleared), the returned path is explicit. Request-ID-number: 32 bits This value (combined with the source IP address of the PCC) uniquely identifies the path computation request context and MUST be incremented each time a new request is sent to the PCE. If no path computation reply is received from the PCE, and the PCC wishes to resend its request, the same Request-ID-number MUST be used. Conversely, different Request-ID-number 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. NO-PATH Object When a PCE cannot find a path satisfying a set of constraints, it MUST include a NO-PATH object in the corresponding PCRep message. In its simplest form, the NO-PATH object is limited to a set of flags and just reports the impossibility to find a path that satisfies the set of constraints. Optionally, if the PCE supports such capability, Vasseur et al. [Page 20] Internet Draft draft-ietf-pce-pcep-02 November 2005 the PCRep message MAY also comprise a list of objects that specify the set of constraints that could not be satisfied. When an object specifies a variety of constraints, the set of unsatisfied constraints can be unambiguously determined by the PCC after a simple comparison with the original requested constraints. NO-PATH Object-Class is to be assigned by IANA (recommended value=3) NO-PATH Object-Type is to be assigned by IANA (recommended value=1) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|S| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 - NO-PATH object format The NO-PATH object has a fixed length of 4 octets. Flags: 16 bits - The following flags are currently defined: C bit: when set, this indicates that the set of unsatisfied constraints (reasons why a path could not be found) is specified in the PCRep message by means of the relevant PCEP objects. When cleared, no reason is specified. For example, consider the case of a PCC that sends a path computation request to a PCE for a TE LSP of X MBits/s. Suppose that PCE cannot find a path for X MBits/s. In this case, the PCE includes in its path computation reply a NO-PATH object with the C flag set. In addition, the PCRep message carries the BANDWIDTH object and the bandwidth field value is equal to X. When the NO-PATH object is absent from a PCRep message, the path computation request has been fully satisfied and the corresponding path(s) is/are provided in the PCRep message. 7.5. 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 TE LSP for which a path computation is requested. Two END-POINTS objects (for IPv4 and IPv6) are defined. END-POINTS Object-Class is to be assigned by IANA (recommended value=4) END-POINTS Object-Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 for IPv6) Vasseur et al. [Page 21] Internet Draft draft-ietf-pce-pcep-02 November 2005 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 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 7.6. BANDWIDTH object The BANDWIDTH object is optional and can be used to specify the requested bandwidth and may be carried within PCReq and PCRep messages. The absence of the BANDWIDTH object MUST be interpreted by the PCE as a path computation request related to a 0 bandwidth TE LSP. When carried within a PCReq message, the BANDWIDTH object specifies a bandwidth constraint that must be satisfied by the computed path(s) if P flag is cleared and MAY be ignored if the P flag is set. In a PCRep message, the BANDWIDTH object indicates that the bandwidth belong to the set of one or more constraint(s) that could be not satisfied. When absent from the PCRep message that means that the computed path satisfies the requested bandwidth constraint. BANDWIDTH Object-Class is to be assigned by IANA (recommended value=5) BANDWIDTH Object-Type is to be assigned by IANA (recommended value=1) Vasseur et al. [Page 22] Internet Draft draft-ietf-pce-pcep-02 November 2005 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, expressed in bytes per second. 7.7. DELAY Object The DELAY object can be used to specify a strict delay constraint for the TE LSP. The delay constraint MUST be taken into account during path computation if P flag is cleared and MAY be ignored if the P flag is set. Note that the mechanism used by the PCE to retrieve the delays of each link is outside of the scope of this document (for the sake of illustration the link delay could be the IGP metric or a Service Provider may choose to use the TE metric to represent link delays). It must be understood that such path metric is only meaningful if used consistently: for instance, if the delay of a path computation segment is exchanged between two PCE residing in different domains, consistent ways of defining the delay must be used. The delay metric may be carried within PCReq and PCRep messages. The absence of the DELAY object MUST be interpreted by the PCE as a path computation request without delay constraint. When carried within a PCReq message, the DELAY object specifies a delay constraint that must be satisfied by the computed path(s). In a PCRep message and when the path computation was successful, the DELAY object indicates the delay(s) of the computed path(s). When the path computation was unsuccessful and the delay constraint was one of the mandatory constraints that could be satisfied the DELAY object MUST be present in the PCRep message. DELAY Object-Class is to be assigned by IANA (recommended value=6) DELAY Object-Type is to be assigned by IANA (recommended value=1) The format of the DELAY 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15 - DELAY object body format Vasseur et al. [Page 23] Internet Draft draft-ietf-pce-pcep-02 November 2005 Delay: 32 bits. The requested delay constraint is encoded in 32 bits in IEEE floating point format, expressed in milliseconds. 7.8. ERO Object The ERO object is used to encode a TE LSP path. If can either be carried within a PCReq message to specify the existing path of a TE LSP to be reoptimize or within a PCRep message to provide a computed TE LSP. The contents of this object are identical in encoding to the contents of the Explicit Route Object defined in [RSPV-TE], [GRSVP] and [RSVP- UNNUM]. That is, the object is constructed from a series of sub- objects. Any RSVP ERO sub-object already defined or that could be defined in the future for use in the ERO is acceptable in this object. PCEP ERO sub-object types correspond to RSVP 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 to be assigned by IANA (recommended value=7) ERO Object-Type is to be assigned by IANA (recommended value=1) 7.9. RRO Object The RRO object is used to record the route followed by a TE LSP. The PCEP RRO object is exclusively carried within a PCReq message so as to specify 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 [RSPV-TE], [G-RSVP] and [RSVP- UNNUM]. That is, the object is constructed from a series of sub- objects. Any RSVP RRO sub-object already defined or that could be defined in the future for use in the 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 RRO. PCEP RRO sub-object types correspond to RSVP RRO sub-object types. RRO Object-Class is to be assigned by IANA (recommended value=8) RRO Object-Type is to be assigned by IANA (recommended value=1) 7.10. LSPA Object The LSPA object specifies various TE LSP attributes to be taken into account by the PCE during path computation. The LSPA (LSP Attributes) Vasseur et al. [Page 24] Internet Draft draft-ietf-pce-pcep-02 November 2005 object can either be carried within a PCReq message or a PCRep message in case of unsuccessful path computation (in this case, the PCReq message also comprises a NO-PATH object and the LSPA object is used to indicate the set of constraint(s) that could not be satisfied). Most of the fields of the LSPA object are identical to the fields of the SESSION-ATTRIBUTE object defined in [RSVP-TE] and [FRR]. LSPA Object-Class is to be assigned by IANA (recommended value=9) Two Objects-Types are defined for the LSPA object: LSPA without resource affinity (Object-Type to be assigned by IANA with recommended value=1) and LSPA with resource affinity (Object-type=2). The format of the LSPA object body with and without resource affinity are 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags |N|B|L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16 - LSPA object body format (without resource affinity) 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 |N|B|L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17 - LSPA object body format (with resource affinity) Setup Priority (8 bits) The priority of the session 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 Vasseur et al. [Page 25] Internet Draft draft-ietf-pce-pcep-02 November 2005 preempt another session. Holding Priority The priority of the session 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 The flags L, B and N correspond to the "Local protection desired" bit ([RSVP-TE]), "Bandwidth protection desired" bit ([FRR]) and the "Node protection desired" bit ([FRR]) of the SESSION-ATTRIBUTE Object respectively. L Flag (Local protection desired) When set, this means that the computed path MUST included links protected with Fast Reroute as defined in [FRR]. B Flag (Bandwidth protection desired) When set, this means that the computed path MUST included links protected with Fast Reroute as defined in [FRR] and that benefit from bandwidth protection. The B flag MUST only be set if the L flag is set. N Flag (Node protection desired) When set, this means that the computed path MUST included links protected with Fast Reroute as defined in [FRR] and that such links MUST be protected with NNOP (Next-next hop backup tunnel). The N flag MUST only be set of the L flag is set. Note that the B flag and N flag are not exclusive. 7.11. IRO Object The IRO (Include Route Object) object is optional and can be used to specify that the computed path must traverse a set of specified network elements. The IRO object may be carried within PCReq and PCRep messages. IRO Object-Class is to be assigned by IANA (recommended value=10) IRO Object-Type is to be assigned by IANA (recommended value=1) 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (subobjects) | Vasseur et al. [Page 26] Internet Draft draft-ietf-pce-pcep-02 November 2005 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18 - IRO objet body format Subobjects The IRO object is made of sub-object(s) identical to the ones defined in [RSVP-TE], [G-MPLS] and [RSVP-UNNUM] for use in EROs. The following subobject types are supported: Type Subobject 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 object. The ERO object carried within a PCReq message is exclusively used in the context of a reoptimization path computation request, thus the need to define a new object (IRO) to specify the inclusion of specified network element(s) in a path. 7.12. SVEC Object Section 8 details the circumstances under which it may be desirable and/or required to correlate several path computation requests. This leads to the specification of the SVEC object (Synchronization VECtor). The SVEC object is optional in a PCEP message. The aim of the SVEC object carried within a PCReq message is to specify the correlation of M path computation requests. The SVEC object is a variable length object that lists the set of M requests the computation of which MUST be synchronized. Each path computation request is uniquely identified by the Request-ID-number carried within the respective RP object. The SVEC object also contains a set of flags that specify the synchronization type. The SVEC object is carried within PCReq messages. SVEC Object-Class is to be assigned by IANA (recommended value=11) SVEC Object-Type is to be assigned by IANA (recommended value=1) One Object-Type is defined for this object to be assigned by IANA with a recommended value of 1. The format of the SVEC 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vasseur et al. [Page 27] Internet Draft draft-ietf-pce-pcep-02 November 2005 | Reserved | Flags |S|N|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP Object #1 | | | // // | RP Object #M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19 - SVEC body object format Flags Defines the synchronization type between multiple path computation requests. L (Link diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST not have any link in common. N (Node diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST not have any node in common. S (SRLG diverse) bit: when set, this indicates that the computed paths corresponding to the requests specified by the following RP objects MUST not share any SRLG (Shared Risk Link Group). The flags defined above are not exclusive. 7.13. NOTIFICATION object The NOTIFICATION object is exclusively carried within a PCNtf message and can either be used in a message sent by a PCC to a PCE or by a PCE to a PCC so as to notify of an event. NOTIFICATION Object-Class is to be assigned by IANA (recommended value=12) NOTIFICATION Object-Type is to be assigned by IANA (recommended value=1) One Object-Type is defined for this object to be assigned by IANA with a recommended value of 1. The format of the NOTIFICATION body object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Flags | Notification- | Notification- | | | | type | value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Vasseur et al. [Page 28] Internet Draft draft-ietf-pce-pcep-02 November 2005 // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20 - NOTIFICATION body object format Length The Length contains the total length of the object in bytes and includes the Type and Length fields. This length must be a multiple of 4 and must be at least 12. Flags No flags are currently defined A NOTIFICATION object is characterized by a Notification-type that specifies the class of notification and the Notification-value that provides additional information related to the nature of the notification. Both the Notification-type and Notification-value should be managed by IANA (see IANA section). The following Notification-type and Notification-value values are currently defined: Notification-type=1: Pending Request cancelled Notification-value=1: PCC cancels a set of pending request(s) A Notification-type=1, Notification-value=1 indicates that the PCC wants to inform a PCE of the cancellation of a set of pending request(s). Such event could be triggered because of external conditions such as the receipt of a positive reply from another PCE (should the PCC have sent multiple requests to a set of PCEs for the same path computation request), a network event such as a network failure rendering the request obsolete or any other event(s) local to the PCC. A NOTIFICATION object with Notification-type=1, Notification-value=1 is exclusively carried within a PCNtf message sent by the PCC to the PCE. The RP object MUST also be present in the PCNtf message. Multiple RP objects may be carried within the PCNtf message in which case the notification applies to all of them. If such notification is received by a PCC from a PCE, the PCC MUST silently ignore the notification and no errors should be generated. Notification-value=2: PCE cancels a set of pending request(s) A Notification-type=1, Notification-value=2 indicates that the PCE wants to inform a PCC of the cancellation of a set of pending request(s). Such event could be triggered because of some PCE congested state or because of some path computation requests that are part the set of synchronized path computation Vasseur et al. [Page 29] Internet Draft draft-ietf-pce-pcep-02 November 2005 requests are missing. A NOTIFICATION object with Notification- type=1, Notification-value=2 is exclusively carried within a PCNtf message sent by a PCE to a PCC. The RP object MUST also be present in the PCNtf message. Multiple RP objects may be comprised within the PCNtf message in which case the notification applies to all of them. If such notification is received by a PCE from a PCC, the PCE MUST silently ignore the notification and no errors should be generated. Notification-type=2: PCE congestion Notification-value=1 A Notification-type=2, Notification-value=1 indicates to the PCC(s) that the PCE is currently in a congested state. If no RP objects are comprised in the PCNtf message, this indicates that no other requests SHOULD be sent to that PCE until the congested state is cleared: the pending requests are not affected and will be served. If some pending requests cannot be served due to the congested state, the PCE MUST also include a set of RP object(s) that identifies the set of pending requests which will not be honored and which will be cancelled by the PCE. In this case, the PCE does not have to send an additional PCNtf message with Notification-type=1 and Notification-value=2 since the list of cancelled requests is specified by including the corresponding set of RP object(s). If such notification is received by a PCE from a PCC, the PCE MUST silently ignore the notification and no errors should be generated. Optionally, a TLV named CONGESTION-DURATION may be included in the NOTIFICATION object that specifies the duration during which no further request should be sent to the PCE. Once this period has expired the PCE should no longer be considered in congested state. The CONGESTION-DURATION TLV is composed of 1 octet for the type, 1 octet specifying the number of bytes in the value field followed by a fix length value field of 4 octets specifying the estimated PCE congestion duration in seconds. The CONGESTION- DURATION TLV is padded to eight-octet alignment TYPE: To be assigned by IANA LENGTH: 4 VALUE: estimated congestion duration in seconds Notification-value=2 A Notification-type=2, Notification-value=2 indicates that the PCE is no longer in congested state and is available to process new path computation requests. An implementation MUST make sure that a PCE sends such notification to every PCC to which a Notification message (with Notification-type=2, Notification- Vasseur et al. [Page 30] Internet Draft draft-ietf-pce-pcep-02 November 2005 value=1) has been sent unless a CONGESTION-DURATION TLV has been included in the corresponding message and the PCE wishes to wait for the expiration of that period of time before receiving new requests. An implementation may decide to cancel such notification if the PCC is in down state for a specific period. A RECOMMENDED value for such delay is 1 hour. If such notification is received by a PCE from a PCC, the PCE MUST silently ignore the notification and no errors should be generated. It is RECOMMENDED to support some dampening notification procedure on the PCE so as to avoid too frequent congestion notifications and releases. For example, an implementation could make use of an hysteresis approach using a dual-thresholds mechanism triggering the sending of congestion notifications and releases. Furthermore, in case of high instabilities of the PCE resources, an additional dampening mechanism SHOULD be used (linear or exponential) to pace the notification frequency and avoid path computation requests oscillation. 7.14. PCEP-ERROR object The PCEP-ERROR object is exclusively carried within a PCErr message and can either be used in a message sent by a PCC to a PCE or by a PCE to a PCC to notify of a PCEP protocol error. PCEP-ERROR Object-Class is to be assigned by IANA (recommended value=13) PCEP-ERROR Object-Type is to be assigned by IANA (recommended value=1) One Object-Type is defined for this object to be assigned by IANA with a recommended value of 1. The format of the PCEP-ERROR 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Flags | Error-Type | Error-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21 - PCEP-ERROR object body format A PCEP-ERROR object is used to report a PCEP protocol error and is characterized by an Error-Type that specifies the type of error and an Error-value that provides additional information about the error Vasseur et al. [Page 31] Internet Draft draft-ietf-pce-pcep-02 November 2005 type. Both the Error-Type and the Error-Value should be managed by IANA (see the IANA section). Length (8 bits) The Length contains the total length of the object in bytes including the Type and Length fields. This length must be a multiple of 4 and must be at least 8. Flags (8 bits) No flag is currently defined. Error-type (8 bits) The Error-type defines the class of error. Error-value (8 bits) Provides additional details about the error. Optionally the PCErr message may contain additional TLV so as to provide further information about the encountered error. No TLV is currently defined. A single PCErr message may contain multiple PCEP-ERROR objects. For each PCEP protocol error, an Error type and value is defined. Error-Type Meaning 1 Capability not supported 2 Unknown Object Error-value=1: Unrecognized object class Error-value=2: Unrecognized object Type 3 Not supported object Error-value=1: Not supported object class Error-value=2: Not supported object Type 4 Policy violation Error-value=1: C bit set (request rejected) Error-value=2: O bit set (request rejected) 5 Required Object missing Error-value=1: RP object missing Error-value=2: RRO object missing for a reoptimization request (R bit of the RP object set) Error-value=3: END-POINTS object missing 6 Synchronized path computation request missing 7 Unknown request reference 8 Unacceptable PCEP session characteristics Error-value=1: parameter negotiation Error-value=2: parameters negotiation failed 9 Deadtimer expired Vasseur et al. [Page 32] Internet Draft draft-ietf-pce-pcep-02 November 2005 In case of the Error-Type 1, the PCE indicates that the path computation request cannot be completed because it does not support one or more required capability. The corresponding path computation request MUST then be cancelled. If a PCEP message is received that carries a mandatory PCEP object (P flag cleared) not recognized by the PCEP peer or recognized but not supported, then the PCEP peer MUST send a PCErr message with a PCEP- ERROR object (Error-Type=2 and 3 respectively). The corresponding path computation request MUST be cancelled by the PCE without further notification. If a path computation request is received which is not compliant with an agreed policy between the PCC and the PCE, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=4). The corresponding path computation MUST be cancelled. If a path computation request is received that does not contain a required object, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=5). If there are multiple mandatory objects missing, the PCErr message MUST contain one PCEP-ERROR object per missing object. The corresponding path computation MUST be cancelled. If a PCC sends a synchronized path computation request to a PCE and the PCE does not receive all the synchronized path computation requests listed within the corresponding SVEC object during a configurable period of time, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=6). The corresponding synchronized path computation MUST be cancelled. If a PCC receives a PCRep message related to an unknown path computation request, the PCC MUST send a PCErr message with a PCEP- ERROR object (Error-Type=6). In addition, the PCC MUST include in the PCErr message the unknown RP object. If one or more characteristic(s) is not acceptable by the receiving peer, it MUST send a PCErr message with Error-type=8, Error-value=1. The PCErr message MUST also comprise an Open object: for each unacceptable session parameter, an acceptable parameter value MUST be proposed in the appropriate field of the Open object in place of the originally proposed value. If a second Open message is received with the same set of parameters or with parameters differing from the proposed values, the receiving peer MUST send a PCErr message with Error-Type=8, Error-value=2 and it MUST immediately close the TCP connection. If a PCEP peer does not receive any PCEP message (Keepalive, PCReq, PCRep, PCNtf) during the Deadtimer period (equal to four times the Keepalive value advertised in the OPEN object) the PCEP peer MUST send a PCErr message with a PCEP-ERROR object (Error-type=9, Error- value=1). Additionally, the PCEP session MUST be terminated and the TCP connection MUST be closed. Vasseur et al. [Page 33] Internet Draft draft-ietf-pce-pcep-02 November 2005 8. Independent versus synchronized path computation requests The PCEP protocol permits the bundling of multiple independent path computation requests within a single PCRep message. 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 so as to obtain their respective paths. The first solution consists of sending N separate PCReq messages to the selected PCE. In this case, the path computation requests are independent. Note that the PCC may chose to distribute the set of N requests across K PCEs for load balancing reasons. Considering that M (with M