PCE Working Group JP Vasseur Cisco System Inc. IETF Internet Draft JL Le Roux France Telecom Arthi Ayyangar Juniper Networks Eiji Oki NTT Alia Atlas Avici Systems, Inc Proposed Status: Standard Expires: November 2005 May 2005 Path Computation Element (PCE) Communication Protocol (PCEP) - Version 1 - draft-vasseur-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. Abstract Vasseur et al. [Page 1] Internet Draft draft-vasseur-pce-pcep-00 May 2005 This document specifies a communication protocol named PCEP (Path Computation Element (PCE) Communication Protocol) for supporting the interactions 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 MPLS 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. PCEP overview.........................................5 6. PCEP Finite State Machine (FSM).......................6 7. PCEP messages.........................................6 7.1. Common header.......................................6 7.2. Path Computation Request (PCReq) message............7 7.3. Path Computation Reply (PCRep) message..............8 7.4. Notification (PCNtf) message........................10 7.5. Error (PCErr) message...............................10 8. Object Formats........................................11 8.1. Common object header................................11 8.2. REQUEST-ID Object...................................12 8.3. END-POINTS object...................................14 8.4. BANDWIDTH object....................................15 8.5. DELAY Object........................................16 8.6. IRO Object..........................................16 8.7. CVEC Object.........................................17 8.8. NOTIFICATION object.................................18 8.9. PCEP-ERROR object...................................21 8.10. Reuse of existing RSVP objects.....................23 9. Path computation requests bundling....................24 9.1. Motivations.........................................25 9.1.1. Independent requests..............................25 9.1.2. Correlated request................................25 9.2. CVEC object.........................................26 9.3. Bundling of response within a PCRep message.........26 10. Elements of procedure................................26 10.1. REQUEST-ID message.................................26 10.2. BANDWITH Object....................................27 10.3. DELAY Object.......................................27 10.4. XRO Object.........................................27 Vasseur et al. [Page 2] Internet Draft draft-vasseur-pce-pcep-00 May 2005 10.5. IRO Object........................................27 10.6. CVEC object.......................................28 10.7. SESSION-ATTRIBUTE object..........................28 11. Manageability.......................................28 12. IANA considerations.................................28 12.1. TCP port..........................................28 12.2. PCEP Objects......................................28 12.3. Notification......................................30 12.4. PCEP Error........................................30 13. Security Considerations.............................31 14. Intellectual Property Statement.....................31 15. Acknowledgment......................................32 16. References..........................................32 16.1. Normative references..............................32 16.2. Informative References............................32 17. AuthorsÆ Address....................................33 1. Terminology Terminology used in this document CSPF: Constraint-based Shortest Path First. IGP Area: OSPF Area or IS-IS level Intra-domain TE LSP: TE LSP whose path does not transit across domains where a domain can either be an IGP area, an Autonomous System or a sub-AS (BGP confederations). Inter-domain TE LSP: A TE LSP whose path transits across at least two different IGP domains where a domain can either be an IGP area, an Autonomous System or a sub-AS (BGP confederations). Link State Advertisement: An OSPF LSA or IS-IS LSP LSDB: Link State Database. LSP: Label Switched Path. LSR: Label Switch Router. PCC: Path Computation Client: any client application requesting a path computation to be performed by the 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 (see further description in section 3). Vasseur et al. [Page 3] Internet Draft draft-vasseur-pce-pcep-00 May 2005 PCEP: PCE Communication Protocol. 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. TE LSP: Traffic Engineering Label Switched Path. TE LSP head-end: Head/source of the TE LSP. TE LSP tail-end: Tail/destination of the TE LSP. 2. Introduction There are several motivations for the adoption of a PCE based architecture to perform TE LSP path computation: (1) Limitation of the PCC: - Partial visibility (e.g. in the case of inter-domain TE LSPs), - Absence of the TED or use of Non-TE-Enabled IGP, - Network element lacks control plane or routing capability, (2) Requirement for sophisticated path computation not available on the PCC: - CPU-intensive path computation, - Backup path computation for bandwidth protection where more sophisticated backup tunnel path computations are required to minimize the required amount of backup capacity, - Multi-Layer traffic engineering. A more detailed description of the motivations listed above can be found in [PCE-ARCH] and this list does not mean to be exhaustive. Further, [PCE-ARCH] defines the building blocks for the PCE architecture (not repeated in this document), an element of which is the PCC-PCE/PCE-PCE communication protocol. The aim of this document is to specify such communication protocol with the objective to be compliant with the set of generic requirements specified in [PCE-COM- GEN-REQ] produced by the PCE Working Group. 3. Assumptions [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. Vasseur et al. [Page 4] Internet Draft draft-vasseur-pce-pcep-00 May 2005 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 it(s) request(s) to. For the sake of reference [PCE-DISC-REQ] defines a list of requirements for dynamic PCE discovery. 4. Transport protocol Reliable messaging and flow control are two key requirements specified in [PCE-COM-GEN-REQ] for PCEP. Consequently, TCP has been chosen as the transport protocol of choice and meet such requirements. The PCEP protocol will use a well-known TCP port to be assigned by IANA. An implementation may either decide to keep the TCP session alive for a unlimited time, should it have to send a new request later on (in which case the TCP session will already be in place); conversely, in some other circumstances, it may be desirable to systematically open and close the TCP session for each PCEP request (this is for instance the case if the sending of PCEP message is a rare event). 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 notified by the PCE when advertising its capability or manually configured on the PCE/PCC. Furthermore, another option would consist of negotiating the desired mode upon PCEP connection set up. Such aspect will be detailed in further revision of this document based on Working Group comments. 5. PCEP overview The PCE Working Group has produced a set of requirements for the PCE communication protocols ([PCE-COM-GEN-REQ]) which served as input to the design of the PCEP protocol and will not be repeated here in their entirety. A set of chief objectives of the PCEP protocol are: - To rely on a transport protocol that provides reliable data delivery, flow control and security, - To design a flexible protocol that could easily be extended to meet further requirements, - To ensure that the same protocol could be used between a PCC and a PCE as well as between two PCEs, - When appropriate, try to re-use objects already defined to encode TE LSP constraints (e.g. some RSVP ([RSVP]), RSVP-TE ([RSVP-TE] and [G-RSVP]) objects), - To design a scalable protocol capable of coping with situations which may require extensive protocol exchanges. Vasseur et al. [Page 5] Internet Draft draft-vasseur-pce-pcep-00 May 2005 Note on terminology: in the rest of this document we use the PCC terminology to refer to an entity that sends a request to a PCE, should it be a regular PCC or a PCE itself acting as a PCC. 6. PCEP Finite State Machine (FSM) PCE Working Group feed-backs will be requested on the following items: - Is there a need for "open" and "close" messages? - Is there a requirement for PCEP hello message that could be used for faster PCC/PCE liveness detection? (If yes, the hello frequency could be negotiated upon PCEP connection setup (via open messages) - Is there a requirement for detailed capability discovery upon PCEP connection set up? Based on Working Groups feed-backs, the appropriate sections and the detailed FSM will be added. 7. PCEP messages A PCEP message consists of a common header followed by a variable length body made of a set of objects which can either be mandatory or optional. For each PCEP message type a set of rules is defined which specifies the set of possible objects that it can carry. We use the Backus-Naur Form (BNF) to specify such rules. Square brackets refer to optional sub-sequences. Note that although BNF implies a specific object order, a specific order is recommended but not imposed by PCEP. In other words, an implementation SHOULD form the PCEP messages using the recommended order but SHOULD accept a message with an arbitrary order. Conversely, if a mandatory object is missing in a PCEP message as defined in this document, this MUST trigger a protocol error condition. 7.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-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver (Version): 4 bits PCEP protocol version number. The current version is version 1 Flags: 12 bits No Flag is currently defined Vasseur et al. [Page 6] Internet Draft draft-vasseur-pce-pcep-00 May 2005 Message Length: 16 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: 1: Path Computation Request 2: Path Computation Reply 3: Notification 4: Error 7.2. 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 TE LSP path computation. The Message-Type field of the PCEP common header is set to 1. There are several mandatory objects that MUST be included within a PCReq message: the REQUEST-ID, the END-POINTS and the SESSION- ATTRIBUTE objects (see section 7). If one of these objects is missing, the receiving PCE MUST return an error message to the sender as specified in section 9. Other objects are optional. The IP source address of the PCReq message is any IP address of the sending PCC and MUST not be changed for a specific path computation request, should multiple PCReq messages be sent that all relate to same request. Furthermore, the requesting PCC MUST ensure that such IP address is reachable and present in the Routing Information Based (RIB). It is RECOMMENDED for the sending PCC to make use of the same IP address for all of its requests (unless such IP address becomes unreachable) in order to ease statistic computations on the PCE: for instance, if the PCC sends multiple path computation requests during a specific period of time, it is RECOMMENDED to systematically use the same source IP address. This way, some statistics can be maintained by the PCE to track the number of received path computation requests per PCC. If the PCCÆs address becomes unreachable, the PCE MUST not conclude of a PCC failure. The state of the TCP Connection dictates the PCC liveness. The format of a PCReq message is as follows: ::= [] [] [] Vasseur et al. [Page 7] Internet Draft draft-vasseur-pce-pcep-00 May 2005 [] [] [] [] [] When used with the CVEC object (see section 7) the PCReq message has the following form: ::= ::= [] [] [] [] [] [] [] [] Definition of the objects listed above: Objects name Reference Section 7 of this document [RSVP-TE] [G-RSVP] [G-RECV-E2E-SIG]. [DS-TE-PROTO] [XRO] 7.3. 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 Vasseur et al. [Page 8] Internet Draft draft-vasseur-pce-pcep-00 May 2005 previously received PCReq message. The Message-Type field of the PCEP common header is set to 2. The PCRep message MUST comprise a REQUEST-ID object with a Request- ID-number identical to the one received in the REQUEST-ID object carried in the corresponding PCReq message (see section 7 for the definition of the REQUEST-ID object). The IP destination address of the PCRep message MUST be equal to the IP source address present in the corresponding PCReq message. 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 PCReq message. Such a situation where multiple computed paths are provided in a PCRep message is discussed in detail in section 8. In some circumstances (further discussed in section 7), the requesting PCC has the ability to specify in its path computation requests its interest in less-constrained path, should no path fully satisfying the set of requested constraints be found. If the path computation request cannot be (fully) satisfied and if the requesting PCC notified its interest to receive less-constrained paths then the PCE may insert in its reply a less-constrained computed path along with the corresponding attributes. The format of a PCRep message is as follows: ::= [ à ] [] [] [] [] [] [] [] When used with the CVEC object, the PCRep message has the following form: ::= path-list:== [ à ] [] [] [] [] Vasseur et al. [Page 9] Internet Draft draft-vasseur-pce-pcep-00 May 2005 [] [] [] 7.4. 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 3. The PCNtf message MUST carry at least one NOTIFICATION object and may comprise several NOTIFICATION objects, should the PCE or the PCC intent to notify of multiple events. The NOTIFICATION object is defined in section 7. The PCNtf message may also comprise a REQUEST- ID 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 expected procedure upon the reception of a PCNtf message is defined in section 9. 7.5. 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 4. 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 REQUEST-ID objects related to the pending path computation request(s) which triggered the protocol error condition. In the later case (unsolicited), no REQUEST-ID is inserted within the PCErr message. 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: ::= [ à ] Vasseur et al. [Page 10] Internet Draft draft-vasseur-pce-pcep-00 May 2005 The expected procedure upon the reception of a PCErr message is defined in section 9. 8. Object Formats 8.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 | Object-Type | Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OS|PR| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object contents) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - Common PCEP object header Object-Class (to be managed by IANA) 8-bit field that identifies the PCEP object class Object-Type (to be managed by IANA) 8-bit field that identifies the PCEP object type Object Length 16-bit field containing the total object length in bytes. Must always be a multiple of 4, and at least 8. OS (Object-Semantic) 2-bit flag that specifies the nature of the object carried within the object body. When set to 0, the object body carries a native PCEP object. When set to 1, the object body carries an RSVP object. PR (Processing-Rule) 2-bit flag which specifies whether the object is mandatory or optional. When set to 0, the object is mandatory. When set to 1, the object is optional. The maximum object content length is 65528 bytes. The Object-Class and Object-Type fields uniquely identify each PCEP object. Vasseur et al. [Page 11] Internet Draft draft-vasseur-pce-pcep-00 May 2005 The PR flag is used to determine what action a node should take if it does not recognize the Object-Class of a PCEP object: there are two possible ways that a PCEP implementation can react to a received PCEP object with an unknown Object-Class. This choice is determined by the PR flag, as follows. If PR flag=0 (Mandatory object) The entire PCEP message should be rejected and an "Unknown Object- Class" error returned in a PCErr message. If PR flag=1 (Optional object) The node should ignore the object and process the PCEP message if possible. In that case, the PCE should send a PCNtf message prior to sending its PCRep message containing the computed path(s) so as to notify the requesting PCC of the list of objects that were ignored during path computation because not recognized (see section XX). If not possible, a PCErr message must be sent to the requesting entity with a "Unknown Object-Class" error. 8.2. REQUEST-ID Object The REQUEST-ID object MUST be carried within every PCReq and PCRep messages and MAY be carried within PCNtf and PCErr messages. REQUEST-ID Object-Class is to be assigned by IANA REQUEST-ID Object-Type is to be assigned by IANA (recommended value=1) The PR flag of the REQUEST-ID object MUST be set to 0. Consequently, as described in section 7.1, a PCE receiving a PCEP message that does not support the REQUEST-ID object MUST trigger a protocol error and return a PCErr message to the requesting PCC. The format of the REQUEST-ID 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 |P|C|B|R|N|L| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - REQUEST-ID object body format The REQUEST-ID object has a variable length and may contain additional TLVs. No TLV is currently defined. Vasseur et al. [Page 12] Internet Draft draft-vasseur-pce-pcep-00 May 2005 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. In particular, the priority may or may not be correlated to the TE LSP priority used for setup. For example, a path computation request related to the computation of a TE LSP path of priority n which is in a down state may have a higher priority than the path computation request for the reoptimization of a TE LSP of priority n-1. Furthermore, the use of the path computation request priority by the PCE by its 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 REQUEST-ID object. If the PCE does not take into account the request priority, it is RECOMMENDED to set the priority field to 0 in the REQUEST-ID object carried within the corresponding PCRep message, regardless of the priority value contained in the REQUEST-ID 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 way across the various PCC(s). The ability of a PCE to support requests prioritization may be dynamically discovered by the PCC(s) by means of PCE capability discovery. Conversely, 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 REQUEST-ID object received in the PCRep message. L (Less-constrained path) bit: when set in the PCReq message, the requesting PCC indicates to the PCE that a less-constrained path is of interest, should no path satisfying the full set of constraints be found by the PCE. If set in a PCRep message, this indicates that the requesting PCC has expressed an interest in less-constrained path and that the PCE was capable of computing less-constrained path(s) provided in the PCRep message. Note that further extensions of the PCEP protocol may allow for the support of hierarchical constraints relaxation policy whereby the requesting PCC may be able to indicate a preference order in which constraints may be relaxed in its path computation request. N (No path) bit: The N bit is exclusively used in PCRep message to indicate the status of the path computation response for a specific path computation request identified by the REQUEST-ID object. When cleared, the path computation request has been Vasseur et al. [Page 13] Internet Draft draft-vasseur-pce-pcep-00 May 2005 (fully or partially) satisfied and the corresponding path(s) is/are provided in the PCRep message. When set, that means that no path could be found by the PCE (thus no path is provided in the PCRep message). 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. B (Bi-directional) bit: when set, the PCC specifies that the path computation request relates to a bidirectional TE LSP. 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. P (Partial): When cleared in a PCReq message this indicates to the PCE that a path exclusively made of strict hops (set of directly connected LSRs) is required, and otherwise (the P bit is set to 1), a path with strict or loose route, or a mix of the two, is acceptable. In a PCRep message, when the P bit is cleared this indicates that the returned path is a strict route, otherwise (the P bit is set to 1), the returned path is partial (comprises loose hops). Request-ID-number: 32 bits This value (combined with the source IP address of the PCC) uniquely identifies the Path Computation Request context and is 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 sent to different PCEs. The path computation reply is unambiguously identified by the IP source address of the replying PCE. 8.3. 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 END-POINTS Object-Type is to be assigned by IANA (recommended value=1) The PR flag of the END-POINTS object MUST be set to 0. Consequently, as described in section 7.1, a PCE receiving a PCEP message that does Vasseur et al. [Page 14] Internet Draft draft-vasseur-pce-pcep-00 May 2005 not support the END-POINTS object MUST trigger a protocol error and return a PCErr message to the requesting PCC. The format of the END-POINTS object body for IPv4 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 3 - END-POINTS object body format for IPv4 The format of the END-POINTS object for IPv6 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 4 - END-POINTS object body format for IPv6 8.4. 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. BANDWIDTH Object-Class is to be assigned by IANA BANDWIDTH Object-Type is to be assigned by IANA (recommended value=1) The PR flag of the BANDWIDTH object MUST be set to 1. 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 Vasseur et al. [Page 15] Internet Draft draft-vasseur-pce-pcep-00 May 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BANDWIDTH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 - - 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. 8.5. DELAY Object The DELAY object is optional and can be used to specify a strict delay constraint for the TE LSP. 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). The requested delay 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, the DELAY object indicates the delays of the computed path(s). DELAY Object-Class is to be assigned by IANA DELAY Object-Type is to be assigned by IANA (recommended value=1) The PR flag of the DELAY object MUST be set to 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 6 - - DELAY object body format Delay: 32 bits. The requested delay constraint is encoded in 32 bits in IEEE floating point format, expressed in milliseconds. 8.6. 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 element (abstract node). The IRO object may be carried within PCReq and PCRep messages. IRO Object-Class is to be assigned by IANA Vasseur et al. [Page 16] Internet Draft draft-vasseur-pce-pcep-00 May 2005 IRO Object-Type is to be assigned by IANA (recommended value=1) The PR flag of the IRO object MUST be set to 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Ï IRO object body format Subobjects The IRO object is made of sub-object identical to the ones defined in [RSVP-TE] and [G-RSVP] 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 Note that the L bit of such sub-object has no meaning within an IRO object. Note also that 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 TE LSP path. 8.7. CVEC Object Section 8 details the circumstances where it may be desirable and/or required to correlate several path computation requests. This leads to the specification of a new PCEP object named the CVEC object (Correlation VECtor). The CVEC object is optional. The aim of the CVEC object carried within a PCReq message is to specify the correlation of M path computation requests. The CVEC object is a variable length object that lists the set of M requests the computation of which MUST be correlated. Each path computation request is uniquely identified by the Request-ID-number carried within the respective REQUEST-ID object. The CVEC object also contains a set of flags that specify the correlation type. The CVEC object is carried within PCReq messages. CVEC Object-Class is to be assigned by IANA Vasseur et al. [Page 17] Internet Draft draft-vasseur-pce-pcep-00 May 2005 CVEC Object-Type is to be assigned by IANA The PR flag of the CVEC object MUST be set to 0. One Object-Type is defined for this object to be assigned by IANA with a recommended value of 1. The format of the CVEC 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 |S|N|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | REQUEST-ID Object #1 | | | // // | REQUEST-ID Object #M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 - - CVEC body object format Flags Defines the correlation 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 REQUEST-ID 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 REQUEST-ID 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 REQUEST-ID objects MUST not share any SRLG (Shared Risk Link Group). The flags defined above are not exclusive. 8.8. 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 NOTIFICATION Object-Type is to be assigned by IANA (recommended value=1) Vasseur et al. [Page 18] Internet Draft draft-vasseur-pce-pcep-00 May 2005 The PR flag of the NOTIFICATION object MUST be set to 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 - - 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 flag is 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 its desire to cancel 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 PCE. A NOTIFICATION object with Notification-type=1, Notification-value=1 is exclusively carried within a PCNtf message sent from the PCC to the PCE. In that Vasseur et al. [Page 19] Internet Draft draft-vasseur-pce-pcep-00 May 2005 case, the REQUEST-ID object MUST also be present in the PCNtf message. Note that multiple REQUEST-ID objects may be carried within the PCNtf message in which case the notification applies to all of them. 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 its desire to cancel 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 correlated path computation requests are missing. A NOTIFICATION object with Notification- type=1, Notification-value=2 is exclusively carried within a PCNtf message sent by a PCE. In that case, the REQUEST-ID object MUST also be present in the PCNtf message. Note that multiple REQUEST-ID objects may be comprised within the PCNtf message in which case the notification applies to all of them. 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 REQUEST-ID 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 REQUEST-ID 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 REQUEST-ID object(s). 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 can be considered as no longer 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. TYPE: To be assigned by IANA LENGTH: 4 VALUE: estimated congestion duration in seconds Vasseur et al. [Page 20] Internet Draft draft-vasseur-pce-pcep-00 May 2005 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- value=1) has been sent unless a CONGESTION-DURATION TLV had been included in the corresponding message and the PCE wishes to wait for the expiration of that time before receiving new requests. If the PCE detects that a PCC to which such notification has been sent is in down state (TCP connection released), the PCE should delay the sending of such PCNtf message with Notification-type=2 and Notification-value=2 until the connection is re-established. 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. 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 a dual- thresholds mechanism triggering the sending of congestion notifications and releases. Further, 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. Notification-type=3: Reception by the PCE of a PCEP object with an unrecognized ææObject-Class ÆÆ Notification-value=1 A Notification-type=3, Notification-value=1 indicates to the PCC(s) that the PCE has received a path computation request comprising an optional PCEP object (PR flag set to 1) with an unrecognized Object- Class but that the PCE managed to compute a set of path(s) by ignoring the object. In that case, the PCE should send a PCNtf message prior to sending its PCRep message containing the computed path(s) so as to notify the requesting PCC of the list of objects that were ignored during path computation because they were not recognized. In such situation, the PCNtf message MUST comprise the list of ignored PCEP objects. 8.9. 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. Vasseur et al. [Page 21] Internet Draft draft-vasseur-pce-pcep-00 May 2005 PCEP-ERROR Object-Class is to be assigned by IANA PCEP-ERROR Object-Type is to be assigned by IANA The PR flag of the PCEP-ERROR object MUST be set to 0. 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 10 - PCEP-ERROR object body format A PCEP-ERROR object is used to report a PCEP protocol error and is characterized by an Error-Type which specifies the type of error and an Error-value that provides additional information about the error 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 and includes 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. Note that optionally the PCErr message may contain additional TLV so as to provide further information about the encountered error. No TLV is currently defined. Furthermore, a single PCErr message may contain multiple PCEP-ERROR objects. Vasseur et al. [Page 22] Internet Draft draft-vasseur-pce-pcep-00 May 2005 For each PCEP protocol error, an Error type and value is defined. Error-Type Meaning 1 Capability not supported 2 Unknown Object-Class 3 Not supported object 4 Policy violation 5 Required Object missing 6 Correlated path computation request missing 7 Unknown request reference In case of the Error-Type 2, 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 not recognized by the PCE (PR flag=0) or not supported, then the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=2 and 3 respectively). The corresponding path computation MUST be cancelled. If a PCEP message is received that relates to a request 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 PCEP path computation request is received that does not comprise a required object, the PCE MUST send a PCErr message with a PCEP- ERROR object (Error-Type=5). The corresponding path computation MUST be cancelled. If a PCC sends a correlated path computation request to a PCE and the PCE does not receive all the correlated path computation requests listed within the corresponding CVEC object, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=6). The corresponding correlated 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). 8.10. Reuse of existing RSVP objects Several RSVP objects have been defined in [RSVP], [RSVP-TE], [G-RSVP] and [DS-TE-PROTO] that specify TE LSP constraints which are used during TE LSP signaling. Although the PCEP protocol is not used for the purpose of signaling a TE LSP, there are several constraints which are provided by a requesting PCC to a PCE to perform path computation. Hence, when appropriate, objects already in the Vasseur et al. [Page 23] Internet Draft draft-vasseur-pce-pcep-00 May 2005 documents referenced above can be reused to pass constraint(s) or results to the computing PCE or provide results to the requesting PCC. A non-exhaustive list of such objects follows: 1) Explicit Route Object (ERO): The ERO object is defined in [RSVP- TE] and is used to specify an explicit route. An explicit route is described as a list of groups of nodes along the explicit route. In addition to the ability to identify specific nodes along the path, an explicit route can identify a group of nodes that must be traversed along the path. See [RSVP-TE] for the detailed object format description. 2) SESSION-ATTRIBUTE object: The SESSION-ATTRIBUTE object is defined in [RSVP-TE]. The Session Attribute Class is 207. Two C-Types are defined, LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1. The SESSION-ATTRIBUTE object with C-Type = 1 includes several TE LSP constraints: the set up and holding priorities, a set of flags used for various purposes which characterise TE LSP properties related for instance to protection (and in particular various attributes used by MPLS Traffic Engineering Fast Reroute (see [FRR])), the SE style, session name and so on. The SESSION-ATTRIBUTE object with C-Type =1 includes the same set of fields and additionally carries resource affinity information. 3) GENERALIZED LABEL REQUEST The GENERALIZED LABEL REQUEST object is defined in [G-RSVP] and is used to specify GMPLS TEP LSP constraints: LSP Encoding type, switching type, and G-PID parameter. See [G-RSVP] for the detailed object format. 4) PROTECTION The PROTECTION object is defined in [G-RECV-E2E-SIG]. LSP (Protection Type) Flags indicates the desired end-to-end LSP recovery type. Link Flags indicates the desired link protection type. The Notification (N) bit and Operational (O) bit has no meaning within an PROTECTION Object. See [G-RECV-E2E-SIG] for the detailed object format. When LSP When an LSP recovery type indicates "1+1 Bi-directional Protection", "1:N Protection with Extra-Traffic","1:N Protection with Extra- Traffic" or "Re-routing without Extra-Traffic", the CVEC Object is used to correlate more than one request in PCReq. When a LSP indicates "(Full) Re-routing" or "Unprotected", a correlated request is not necessary. An RSVP object may be carried within a PCEP object. In this case, the OS flag of the PCP common header MUST be set to 1. 9. Path computation requests bundling Vasseur et al. [Page 24] Internet Draft draft-vasseur-pce-pcep-00 May 2005 There are various circumstances where bundling multiple path computation requests is desirable or required. 9.1. Motivations 9.1.1. Independent requests When an LSR has to signal a set of N TE LSPs for which it needs to send path computation requests to a PCE so as to obtain their respective paths, the first solution consists of sending N independent PCReq messages to the selected PCE. 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