Network Working Group JP Vasseur (Editor) Cisco System Inc. IETF Internet Draft JL Le Roux France Telecom Arthi Ayyangar Juniper Networks Eiji Oki NTT Alia Atlas Google, Inc Proposed Status: Standard Expires: January 2006 July 2005 Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 draft-vasseur-pce-pcep-01.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-vasseur-pce-pcep-01 July 2005 Abstract 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. 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...............................5 5.2.1. Initiation phase............................................7 5.2.2. Parameter negotiation.......................................7 5.2.3. Path computation request sent by a PCC to a PCE.............7 5.2.4. Path computation reply sent by the PCE to a PCC.............7 5.2.5. Notifications...............................................8 6. PCEP messages...................................................9 6.1. Common header.................................................9 6.2. Path Computation Request (PCReq) message.....................10 6.3. Path Computation Reply (PCRep) message.......................11 6.4. Notification (PCNtf) message.................................12 6.5. Error (PCErr) message........................................13 7. Object Formats.................................................13 7.1. Common object header.........................................13 7.2. REQUEST-ID Object............................................15 7.3. NO-PATH Object...............................................17 7.4. END-POINTS Object............................................18 7.5. BANDWIDTH object.............................................19 7.6. DELAY Object.................................................20 7.7. IRO Object...................................................21 7.8. CVEC Object..................................................22 7.9. NOTIFICATION object..........................................23 7.10. PCEP-ERROR object...........................................26 7.11. Carrying other protocol objects in PCEP message using the.. ENCAP object..................................................... 28 8. Independent versus correlated path computation requests........30 Vasseur et al. [Page 2] Internet Draft draft-vasseur-pce-pcep-01 July 2005 9. Elements of procedure..........................................32 9.1. REQUEST-ID object............................................32 9.2. BANDWDITH object.............................................32 9.3. DELAY object.................................................33 9.4. XRO object...................................................33 9.5. IRO object...................................................33 9.6. CVEC object..................................................33 10. Open issues...................................................34 11. Manageability Considerations..................................35 12. IANA Considerations...........................................35 12.1. TCP port....................................................35 12.2. PCEP Objects................................................35 12.3. Notification................................................37 12.4. PCEP Error..................................................37 13. Security Considerations.......................................38 13.1. PCEP Authentication and Integrity...........................38 13.2. PCEP Privacy................................................38 13.3. Protection against Denial of Service attacks................39 14. Intellectual Property Statement...............................39 15. Acknowledgment................................................40 16. References....................................................40 16.1. Normative references........................................40 16.2. Informative References......................................41 17. Authors' Addresses............................................42 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. 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. Vasseur et al. [Page 3] Internet Draft draft-vasseur-pce-pcep-01 July 2005 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 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 communications 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 PCEP protocol meets the requirements stated in [PCE-COM-GEN-REQ]. 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. 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 Vasseur et al. [Page 4] Internet Draft draft-vasseur-pce-pcep-01 July 2005 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 either decide to keep the TCP session alive for an unlimited time, should it have to send a new requests later on (in which case the TCP session will already be in place). 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 session for each PCEP request (this is for instance the case if the sending of PCEP message 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. PCE Working Group feedbacks are requested to determine whether PCEP should support the two modes or just the 'permanent mode': see the 'open issues' section. 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 has been described in [PCE-ARCH]. When the PCC and the PCE are not collocated, this requires a communication protocol between the PCC and the PCE. PCEP is such a protocol specified for 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 PCE may reply with a set of computed path(s) if one or more path(s) obeying the set of constraints or less-constrained path(s) 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: Vasseur et al. [Page 5] Internet Draft draft-vasseur-pce-pcep-01 July 2005 - PCReq: message sent by a PCC to a PCE to request a path computation. - PCRep: 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 successfully satisfied or a negative reply otherwise, potentially with a set of less-constrained path(s). - PCNtf: notification message either sent by a PCC to a PCE or a PCE to a PCC to notify of specific event. - PCErr: message related to a protocol error condition. +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ 1)Path computation | | requested | | 2)PCE Selection | | 3)Path computation |---- PCReq message--->| request sent to | |4) Path computation the selected PCE | |triggered | | | |Path successfully computed | | | |5) Computed path(s) sent | |to the PCC |<--- PCRep message ---| | (Positive reply) | Figure 1: Path computation request with successful computation +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ 1)Path computation | | requested | | 2)PCE Selection | | 3)Path computation |---- PCReq message--->| request sent to | |4) Path computation the selected PCE | |triggered | | | |No Path found that | |satisfies the request | | | |5) Negative reply sent to | |the PCC (optionally with | |various additional | |information including |<--- PCRep message ---|less-constrained path) | (Negative reply) | Figure 2: Path computation request with unsuccessfully computation Vasseur et al. [Page 6] Internet Draft draft-vasseur-pce-pcep-01 July 2005 5.2.1 Initiation phase The Initiation phase consists of establishing the TCP session (3-way handshake) between the PCC and the PCE, initialized by the PCC or the PCE. As already pointed out, the set of available PCE(s) may be either statically configured on a PCC or dynamically discovered. Note that 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.2 Parameter negotiation The Working Group has been polled to get some input on the need for a parameters negotiation phase. See the 'Open Issues' section. 5.2.3 Path computation request sent by a PCC to a PCE Consider the diagram depicted in figure 1. Once a PCC (or a PCE) has established a TCP session using the well-known TCP port 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. Once a PCC has selected a PCE, the PCC 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, whether the PCC is interested in a less-constrained path (should no path satisfying all the constraint be found by the PCE) and so on. It is worth pointing out that each request is uniquely identified by a request-id number and the PCC-PCE address pair. The process is shown in a schematic form in figure 1. 5.2.4 Path computation reply sent by the PCE to a PCC 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). - Negative: no path could be computed that satisfies the request. In this case, the protocol allows a PCC to specify its desire to receive a less-constrained path. If supported by the PCE, such less- constrained computed path may be included in the negative reply along with the corresponding path attributes. Upon receiving a negative reply, a PCC may decide to resend a modified request or take any other appropriate action. Vasseur et al. [Page 7] Internet Draft draft-vasseur-pce-pcep-01 July 2005 5.2.5. 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 PCC 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 present. 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 | | requested | | 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 3: Example of PCC notification (request cancellation) sent to a PCE +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ 1)Path computation | | requested | | 2)PCE Selection | | 3)Path computation |---- PCReq message--->| request X sent to | |4) Path computation the selected PCE | |triggered | | | | | |5) PCE experiencing | |congestion | | | |6) Path computation | |request X cancelled | | |<--- PCNtf message----| Vasseur et al. [Page 8] Internet Draft draft-vasseur-pce-pcep-01 July 2005 Figure 4: Example of PCEP notification (request(s) cancellation) send to a PCC 6. 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. An implementation MUST form the PCEP messages using the order specified in this document. If a mandatory object is missing in a PCEP message as defined in this document a protocol error condition MUST be triggered by the recipient of the PCEP message. 6.1. Common header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Flags | Message-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: PCEP message common header Ver (Version): 4 bits PCEP protocol version number. The current version is version 1 Flags: 4 bits No Flag is 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: 1: Path Computation Request 2: Path Computation Reply 3: Notification 4: Error Vasseur et al. [Page 9] Internet Draft draft-vasseur-pce-pcep-01 July 2005 6.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 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, the BANDWIDTH 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 requester (PCErr message). Other objects are optional. The format of a PCReq message is as follows: ::= [] where: ::=[] ::=[] ::= [] [] [] [] [] [] [] [] Definition of the objects listed above: Objects name Reference Section 7 of this document Note that the following objects are RSVP objects encapsulated in the PCEP ENCAP object defined in section 7.11. For the sake of clarity, the PCEP ENCAP object that carries an RSVP object X is simply Vasseur et al. [Page 10] Internet Draft draft-vasseur-pce-pcep-01 July 2005 referred to as the PCEP object X. For example, when the PROTECTION object is carried within the ENCAP object, the PCEP object is simply called PROTECTION object. [RSVP-TE] [G-RSVP] [G-RECV-E2E-SIG]. [DS-TE-PROTO] [XRO] 6.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 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 specified in the REQUEST-ID object carried in the corresponding PCReq message (see section 7 for the definition of the REQUEST-ID 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 permitted by the PCEP protocol. If a PCE receives non correlated 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 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.3) may also comprise other information (e.g reasons for the path computation failure, suggested constraints values for which a path could be found). In some circumstances (further discussed in section 7), the requesting PCC has the ability to specify in its path computation Vasseur et al. [Page 11] Internet Draft draft-vasseur-pce-pcep-01 July 2005 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: ::= [] where: ::=[] ::=[] ::= [] [] [] [] [] [] [] [] where: :==[ 6.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 intend 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: ::= Vasseur et al. [Page 12] Internet Draft draft-vasseur-pce-pcep-01 July 2005 ::= [] ::= [] :== := The procedure upon the reception of a PCNtf message is defined in section 9. 6.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: ::= :==[] ::=[] :==[] :==[] 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 Vasseur et al. [Page 13] Internet Draft draft-vasseur-pce-pcep-01 July 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object-Class | Object-Type |PR | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Length (bytes) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object contents) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: PCEP common 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 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. 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 8. The maximum object content length is 65528 bytes. The Object-Class and Object-Type fields uniquely identify each PCEP object. 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 Vasseur et al. [Page 14] Internet Draft draft-vasseur-pce-pcep-01 July 2005 during path computation because they were not recognized. If the path computation cannot be performed, a PCErr message must be sent to the requesting entity with an 'Unknown Object-Class' error. 7.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 (recommended value=1) 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 |O|C|B|R|L| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: REQUEST-ID object body format The REQUEST-ID 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. 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 path computation priority than the path computation request for the reoptimization of a TE LSP of priority n-1 (although a higher numerical value of the TE LSP priority reflect a lower priority). Furthermore, the use of the path computation request priority by the PCE's requests scheduler is Vasseur et al. [Page 15] Internet Draft draft-vasseur-pce-pcep-01 July 2005 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 manner 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. 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. 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 into account any priority. 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. This is discussed in the 'Open issues' section. 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 as defined in [RSVP-TE]. 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 path in the PCRep message as computed by the PCE. Vasseur et al. [Page 16] Internet Draft draft-vasseur-pce-pcep-01 July 2005 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 set to 1), 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 sent to different PCEs. The path computation reply is unambiguously identified by the IP source address of the replying PCE. 7.3. 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 constraint. If the PCC has expressed an interest in less-constraint path and the PCE has such capability, the PCRep message MAY also comprise a list of objects that specify the set of unsatisfied constraints along with suggested values (if supported by the PCE) and corresponding less constrained path(s). When an object specifies a variety of constraints, the set of unsatisfied constraints (along with their potentially suggested values) 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=2) NO-PATH Object-Type is to be assigned by IANA (recommended value=1) The PR flag of the NO-PATH object MUST be set to 0. Consequently, as described in section 7.1, a PCC receiving a PCEP message that does not support the NO-PATH object MUST trigger a protocol error and return a PCErr message to the sending PCE. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vasseur et al. [Page 17] Internet Draft draft-vasseur-pce-pcep-01 July 2005 Figure 8: 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. S bit: when set, this indicates that the PCE supports the ability to suggest values for the set of unsatisfied constraint(s) and provides such information in its reply. In this case, the PCRep message contains a set of objects that specifies the list of unsatisfied constraints with suggested values. When cleared, the PCE just specifies the set of unsatisfied constraints with no suggested values. The S bit MUST be cleared if the L bit of the received REQUEST-ID object is cleared. The S bit MUST be set if and only if the C bit is also set. Additionally, the less-constrained computed path is also included in the PCRep message. For example, consider the case of a PCC that sends a path computation request to a PCE for a TE LSP path of X MBits/s and indicates its interest in less-constrained path, should the request not be satisfied. Suppose that PCE cannot find a path for X MBits/s but a path for Y Mbits/s (with Y