Networking Working Group JP. Vasseur, Ed. Internet-Draft Cisco Systems, Inc Expires: December 24, 2006 JL. Le Roux France Telecom A. Ayyangar Juniper Networks E. Oki NTT A. Atlas Google A. Dolganow Alcatel Y. Ikejiri NTT Communications Corporation K. Kumaki KDDI Corporation June 22, 2006 Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 draft-ietf-pce-pcep-02.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. This Internet-Draft will expire on December 24, 2006. Copyright Notice Vasseur, et al. Expires December 24, 2006 [Page 1] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 Copyright (C) The Internet Society (2006). 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. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Vasseur, et al. Expires December 24, 2006 [Page 2] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Transport protocol . . . . . . . . . . . . . . . . . . . . . . 6 5. Architectural Protocol Overview (Model) . . . . . . . . . . . 7 5.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Architectural Protocol Overview . . . . . . . . . . . . . 7 5.2.1. Initialization Phase . . . . . . . . . . . . . . . . . 8 5.2.2. Path computation request sent by a PCC to a PCE . . . 9 5.2.3. Path computation reply sent by the PCE to a PCC . . . 10 5.2.4. Notification . . . . . . . . . . . . . . . . . . . . . 12 5.2.5. Termination of the PCEP Session . . . . . . . . . . . 13 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Common header . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Open message . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Keepalive message . . . . . . . . . . . . . . . . . . . . 16 6.4. Path Computation Request (PCReq) message . . . . . . . . . 17 6.5. Path Computation Reply (PCRep) message . . . . . . . . . . 18 6.6. Notification (PCNtf) message . . . . . . . . . . . . . . . 19 6.7. Error (PCErr) Message . . . . . . . . . . . . . . . . . . 20 6.8. Close message . . . . . . . . . . . . . . . . . . . . . . 21 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Common object header . . . . . . . . . . . . . . . . . . . 21 7.2. OPEN object . . . . . . . . . . . . . . . . . . . . . . . 23 7.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 24 7.3.1. Object definition . . . . . . . . . . . . . . . . . . 24 7.3.2. Handling of the RP object . . . . . . . . . . . . . . 26 7.4. NO-PATH Object . . . . . . . . . . . . . . . . . . . . . . 27 7.5. END-POINT Object . . . . . . . . . . . . . . . . . . . . . 28 7.6. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 29 7.7. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 30 7.8. ERO Object . . . . . . . . . . . . . . . . . . . . . . . . 32 7.9. RRO Object . . . . . . . . . . . . . . . . . . . . . . . . 33 7.10. LSPA Object . . . . . . . . . . . . . . . . . . . . . . . 33 7.11. IRO Object . . . . . . . . . . . . . . . . . . . . . . . . 35 7.12. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 36 7.12.1. Independent versus synchronized path computation requests . . . . . . . . . . . . . . . . . . . . . . . 36 7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 37 7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 38 7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 39 7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 42 7.15. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 44 8. Manageability Considerations . . . . . . . . . . . . . . . . . 45 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 45 Vasseur, et al. Expires December 24, 2006 [Page 3] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 45 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 46 9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 47 9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 48 10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 49 11. Security Considerations . . . . . . . . . . . . . . . . . . . 54 11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 55 11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 55 11.3. Protection against Denial of Service attacks . . . . . . . 55 11.4. Request input shaping/policing . . . . . . . . . . . . . . 56 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 13.1. Normative References . . . . . . . . . . . . . . . . . . . 56 13.2. Informative References . . . . . . . . . . . . . . . . . . 57 Appendix A. Proposed Status and Discussion [To Be Removed Upon Publication] . . . . . . . . . . . . . . . . . . 58 Appendix B. Compliance with the PCECP Requirement Document . . . 58 Appendix C. PCEP Variables . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Intellectual Property and Copyright Statements . . . . . . . . . . 62 Vasseur, et al. Expires December 24, 2006 [Page 4] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 1. Terminology Terminology used in this document Explicit path: full explicit path from start to destination made of a list of strict hops where a hop may be an abstract node such as an AS. IGP Area: OSPF Area or IS-IS level. 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). 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. 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 [I-D.ietf-pce-architecture]describes the motivations and architecture for a PCE-based model for the computation of 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. [I-D.ietf-pce-comm-protocol-gen-reqs] states the generic requirements Vasseur, et al. Expires December 24, 2006 [Page 5] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 for such a protocol including the requirement for using the same protocol between PCC and PCE, and between PCEs. Additional application-specific requirements (for scenarios such as inter-area, inter-AS, etc.) are not included in [I-D.ietf-pce-comm-protocol-gen- reqs], but there is a requirement that any solution protocol must be easily extensible to handle other requirements as they are introduced in application-specific requirements documents. Examples of such application-specific requirements are [I-D.ietf-pce-pcecp-interarea- reqs]and [I-D.ietf-pce-inter-layer-req]. 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. 3. Assumptions [I-D.ietf-pce-architecture] describes various types of PCE. PCEP does not make any assumption and thus does not impose any constraint on the nature of the PCE. 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 on the PCE decision selection process. For the sake of reference [I-D.ietf-pce-discovery-reqs] defines a list of requirements for dynamic PCE discovery and IGP-based solution for such PCE discovery are specified in [I-D.ietf-pce-disco-proto-igp]. 4. Transport protocol PCEP operates over TCP using a well-known TCP port (to be assigned 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 Vasseur, et al. Expires December 24, 2006 [Page 6] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 unlimited time (this may for instance be appropriate when path computation requests are sent on a frequent basis so as to avoid to open a TCP session each time a path computation request is needed). Conversely, in some other circumstances, it may be desirable to systematically open and close the TCP connection for each PCEP request (for instance when sending of path computation request is a rare event). 5. Architectural Protocol Overview (Model) The aim of this section is to describe the PCEP protocol model in the spirit of [RFC4101]. An architecture protocol overview (the big picture of the protocol) is provided in this section. Protocol details 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 [I-D.ietf-pce-architecture]. 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 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 PCEP message sent by a PCC to a PCE to request a path computation. - PCRep: a PCEP 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 PCEP notification message either sent by a PCC to a PCE or a PCE to a PCC to notify of specific event. Vasseur, et al. Expires December 24, 2006 [Page 7] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 - PCErr: a PCEP message sent upon the occurrence of a protocol error condition. - Close message: a message used to close a PCEP session. 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). Note that the PCE selection algorithm 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 is always triggered by the PCC. 5.2.1. Initialization Phase The initialization phase consists of two successive steps (described in a schematic form in Figure 1): 1) Establishment of a TCP connection (3-way handshake) between the PCC and the PCE. 2) Establishment of a PCEP session over the TCP connection. Once the TCP connection is established, the PCC and the PCE (also referred to as "PCEP peers") initiate a PCEP session establishment during which various session parameters are negotiated. These parameters are carried within Open messages and include the keepalive timer and, potentially, other detailed capabilities and policy rules that specify the conditions under which path computation requests may be sent to the PCE. If the PCEP session establishment phase fails because the PCEP peers disagree on the exchanged parameters or one of the PCEP peers does not answer after the expiration of the establishment timer, the TCP connection is immediately closed. Successive retries are permitted but an implementation SHOULD make use of exponential back-off. Keepalive messages are used to acknowledge Open messages and once the PCEP session has been successfully established, Keepalive messages are exchanged between PCEP peers to ensure the liveness of the PCEP session. Details about the Open message and the Keepalive messages can be found in . (Section 6.2) and Section 6.3respectively. Vasseur, et al. Expires December 24, 2006 [Page 8] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 +-+-+ +-+-+ |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 +-+-+ +-+-+ |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 set of path(s), the PCC first selects one of more PCE(s) to send the request to. Note that the PCE selection decision process may have taken place prior to the PCEP session establishment. Once the PCC has selected a PCE, it sends a path computation request to the PCE (PCReq message) that contains a variety of objects that specify the set of constraints and attributes for the path to be computed. For example "Compute a TE LSP path with source IP address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=X Mbit/s, Priority=Y, ...". Additionally, the PCC may desire to specify the urgency of such request by assigning a request priority. Each request is uniquely identified by a request-id number and the PCC-PCE addresses pair. The process is shown in a schematic form in Vasseur, et al. Expires December 24, 2006 [Page 9] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 figure 2. Details about the PCReq message can be found in Section 6.4 5.2.3. Path computation reply sent by the PCE to a PCC Vasseur, et al. Expires December 24, 2006 [Page 10] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 +-+-+ +-+-+ |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 path 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 unsuccessful path computation Upon receiving a path computation request from a PCC, the PCE triggers a path computation, the result of which can either be: - Positive (Figure 3-a): the PCE manages to compute a path satisfying the set of required constraints. The PCE returns the set of computed path(s) to the requesting PCC. Note that PCEP supports the capability to send a single request which refers to the computation of multiple paths: for example, compute two link-diverse paths. - Negative (Figure 3-b): no path could be found that satisfies the Vasseur, et al. Expires December 24, 2006 [Page 11] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 set of constraints. In this case, a PCE may provide the set of constraints that led to the path computation failure. Upon receiving a negative reply, a PCC may decide to resend a modified request or take any other appropriate action. Details about the PCRep message can be found in Section 6.5. 5.2.4. Notification 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 or may experience unacceptable delays. Such notification may potentially result 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). Vasseur, et al. Expires December 24, 2006 [Page 12] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 +-+-+ +-+-+ |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 | | | |6) Path computation | |request X cancelled | | |<--- PCNtf message----| Figure 5: Example of PCE notification (request(s) cancellation) sent to a PCC Details about the PCNtf message can be found in Section 6.6. 5.2.5. Termination of the PCEP Session When one of the PCEP peers desires to terminate a PCEP session it first sends a PCEP Close message and then close the TCP connection. Vasseur, et al. Expires December 24, 2006 [Page 13] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 If the PCEP session is terminated by the PCE, the PCC clears all the states related to pending requests sent to the PCE. Similarly, if the PCC terminates a PCEP session the PCE clears all pending path computation requests sent by the PCC in question as well as the related states. A Close message can only be sent to terminate a PCEP session if the PCEP session has previously been established. In case of TCP connection failure, the PCEP session SHOULD be maintained for a period of time equal to the Deadtimer. Details about the Close message can be found in Section 6.8. 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 considered as valid. Thus a missing mandatory object in a PCEP message MUST be considered as a malformed message and such condition MUST trigger an Error message. Conversely, if an object is optional, the object may or may not be present. A flag referred to as the P flag is defined in the common header of each PCEP object (see Section 7.1) 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 COST object allows a PCC to specify a bounded acceptable path cost. The COST object is optional but a PCC may set a flag to ensure that such constraint is taken into account. Similarly to the previous case, if such constraint cannot be taken into account by the PCE, this should trigger an Error 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. 6.1. Common header Vasseur, et al. Expires December 24, 2006 [Page 14] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Flags | Message-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message-Lenght | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: PCEP message common header Ver (Version - 4 bits): PCEP protocol version number. Current version is version 1. Flags (8 bits): no flags are currently defined. Message-Type (8 bits): The following message types are currently defined (to be confirmed by IANA). Value Meaning 1 Open 2 Keepalive 3 Path Computation Request 4 Path Computation Reply 5 Notification 6 Error 7 Close Message Length (32 bits): total length of the PCEP message expressed in bytes including the common header. 6.2. Open message The Open message is a PCEP message sent by a PCC to a PCE in order to establish a PCEP session. The Message-Type field of the PCEP common header for the Open message is set to 1 (To be confirmed by IANA). 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. Any message received prior to an OPEN message MUST trigger a protocol error condition and the PCEP session MUST be terminated. The Open message is used 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. Vasseur, et al. Expires December 24, 2006 [Page 15] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 Open message ::= The Open message MUST contain exactly one OPEN object (see Section 7.2). Various session characteristics are specified within the OPEN object. Once an Open message has been sent to a PCEP peer, the sender MUST start an initialization timer called InitOpen after the expiration of which a similar Open message MUST be resent if no reply has been received from the PCEP peer. The InitOpen timer has a fixed value of 1 minute. The maximum number of Open messages named MaxRetryOpen 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 at least one of the characteristic(s) is not acceptable by the receiving peer, it MUST send an Error message. The Error message SHOULD also contain the related Open object: for each unacceptable session parameter, an acceptable parameter value SHOULD be proposed in the appropriate field of the Open object in place of the originally proposed value. The PCEP peer MAY decide to resend an Open message with different session characteristics. If a second Open message is received with the same set of parameters or with parameters that are still unacceptable, the receiving peer MUST send an Error message and it MUST immediately close the TCP connection. Details about error message can be found in Section 7.14. If the PCEP session characteristics are acceptable, the receiving PCEP peer MUST consequently send a Keepalive message (defined in Section 6.3) that would serve as acknowledgment. The PCEP session is considered as established once both PCEP peers have received a Keepalive message from their peer. 6.3. Keepalive message A Keepalive message is a PCEP message sent by a PCC or a PCE in order to keep the session in active state. The Message-Type field of the PCEP common header for the Keepalive message is set to 2 (To be confirmed by IANA). The Keepalive message does not contain any object. 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 keepalive messages. Asymmetric values may be chosen; thus there is no constraints Vasseur, et al. Expires December 24, 2006 [Page 16] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 mandating the use of identical keepalive frequencies by both PCEP peers. The DeadTimer is defined as the period of time after the expiration of which a PCEP peer declares the session down if no PCEP message has been received (keepalive or any other PCEP message: thus, any PCEP message acts as a keepalive message). Similarly, there is no constraints mandating the use of identical DeadTimers by both PCEP peers. The minimum KeepAliveTimer value is 1 second. 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. Because any PCEP message may serve as Keepalive an implementation may either decide to send Keepalive messages at the same frequency regardless on whether other PCEP messages might have been sent since the last sent Keepalive message or may decide to differ the sending of the next Keepalive message based on the time at which the last PCEP message (other than Keepalive) was sent. Keepalive message ::= 6.4. Path Computation Request (PCReq) message A Path Computation Request message (also referred to as a PCReq message) is a PCEP message sent by a PCC to a PCE so as to request a path computation. The Message-Type field of the PCEP common header for the PCReq message is set to 3 (To be confirmed by IANA). 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. Other objects are optional. Vasseur, et al. Expires December 24, 2006 [Page 17] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 The format of a PCReq message is as follows: ::= [] where: ::=[] ::=[] ::= [] [] [] [] [] [] [] The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, and IRO objects are defined in Section 7. The special case of two BANDWIDTH objects in details inSection 7.6. 6.5. Path Computation Reply (PCRep) message The PCEP Path Computation Reply message (also referred to as a PCRep message) is a PCEP message sent by a PCE to a requesting PCC in response to a previously received PCReq message. The Message-Type field of the PCEP common header is set to 4 (To be confirmed by IANA). The PCRep message MUST contain at least one RP object. For each reply that is bundled into a single PCReq message, an RP object MUST be included that contains a Request-ID-number identical to the one specified in the RP object carried in the corresponding PCReq message (see Section 7.3for 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 and/or to multiple acceptable paths corresponding to the same request. 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. Conversely, a PCE that receives multiple requests within the same PCReq message, may decide to reply each path in separate PCRep messages. Vasseur, et al. Expires December 24, 2006 [Page 18] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 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. The ERO object is defined in Section 7.8. Such a situation where multiple computed paths are provided in a PCRep message is discussed in detail in Section 7.12. 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.4) may also comprise other information (e.g reasons for the path computation failure). The format of a PCRep message is as follows: ::= [] 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 (To be Confirmed by IANA). The PCNtf message MUST carry at least one NOTIFICATION object and may contain several NOTIFICATION objects should the PCE or the PCC intend to notify of multiple events. The NOTIFICATION object is defined in Section 7.13. The PCNtf message may also contain an RP object (see Section 7.3when the notification refers to a particular path Vasseur, et al. Expires December 24, 2006 [Page 19] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 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: ::= ::= [] ::= [] :== := 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 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 Section 7.14. Vasseur, et al. Expires December 24, 2006 [Page 20] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 The format of a PCErr message is as follows: ::= [] :==[] ::=[] :==[] :==[] The procedure upon the reception of a PCErr message is defined in Section 7.14. 6.8. Close message The Close message is a PCEP message sent by either a PCC to a PCE or by a PCE to a PCC in order to close a PCEP session. The Message-Type field of the PCEP common header for the Open message is set to 7 (To be confirmed by IANA). Close message ::= The Close message MUST contain exactly one CLOSE object (see Section 6.8). Upon the receipt of a Close message, the receiving PCEP peer MUST cancel all pending requests and MUST close the TCP connection. 7. Object Formats 7.1. Common object header Vasseur, et al. Expires December 24, 2006 [Page 21] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 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|P|I| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object body) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: PCEP common object header Object-Class (8 bits): identifies the PCEP object class. OT (Object-Type - 4 bits): identifies the PCEP object type. The Object-Class and Object-Type are managed by IANA. The Object-Class and Object-Type fields uniquely identify each PCEP object. Res (3 bits): Reserved. P flag (Processing-Rule - 1-bit): the P flag allows a PCC to specify in a PCReq message sent to a PCE whether the object must be taken into account by the PCE during path computation or is just optional. When the P flag is set, the object MUST be taken into account by the PCE. Conversely, when the P flag is cleared, the object is optional and the PCE is free to ignore it if not supported. I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep message to indicate to a PCC whether or not an optional object was processed. The PCE MAY include the ignored optional object in its reply and set the I flag to indicate that the optional object was ignored during path computation. When the I flag is cleared, the PCE indicates that the optional object was processed during the path computation. The setting of the I flag for optional objects is purely indicative and optional. The I flag MUST be cleared if the P flag is set. If the PCE does not understand an object with the P Flag set or understands the object but decides to ignore the object, the entire PCEP message MUST be rejected and the PCE MUST send a PCErr message with Error-Type="Unknown Object" or "Not supported Object". Res flags (2 bits). Reserved field (MUST be set to 0). Vasseur, et al. Expires December 24, 2006 [Page 22] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 Object Length (16 bits). Specifies the total object length including the header, in bytes. The Object Length field MUST always be a multiple of 4, and at least 4. The maximum object content length is 65528 bytes. 7.2. OPEN object The OPEN object MUST be present in each Open message and may be present in PCErr message. There MUST be only one OPEN object per Open or PCErr message. The OPEN object contains a set of fields used to specify the PCEP 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 capabilities, policy rules and so on. No such 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 | Deadtimer | SID | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: OPEN Object format Ver (Ver - 3 bits): PCEP version. Current version is 1. Keepalive (8 bits): minimum period of time (in seconds) between the sending of PCEP messages that the sender of the Open message will send Keepalive messages. The minimum value for the Keepalive is 1 second. When set to 0, once the session is established, no further keepalives need to be sent to the remote peer. A RECOMMENDED value for the keepalive frequency is 30 seconds. DeadTimer (8 bits): specifies the amount of time after the expiration of which a PCEP peer declares the session with the sender of the Open message down if no PCEP message has been received. The DeadTimer MUST be set to 0 if the Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value of the Keepalive. Vasseur, et al. Expires December 24, 2006 [Page 23] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 SID (PCEP session-ID - 8 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 and is mainly used for logging and troubleshooting purposes. Flags (5 bits): No Flags are currently defined. Optional TLVs may be included within the OPEN object body to specify PCC or PCE characteristics. The specification of such TLVs is outside the scope of this document. When present in an Open message, the OPEN object specifies the proposed PCEP session characteristics. Upon receiving unacceptable PCEP session characteristics during the PCEP session initialization phase, the receiving PCEP peer (PCE), may include a PCEP object within the PCErr message so as to propose alternative session characteristic values. 7.3. RP Object The RP (Request Parameters) object MUST be carried within each PCReq and PCRep messages and MAY be carried within PCNtf and PCErr messages. The P flag of the RP object MUST be set. The RP object is used to specify various characteristics of the path computation request. 7.3.1. Object definition RP Object-Class is to be assigned by IANA (recommended value=2) RP Object-Type is to be assigned by IANA (recommended value=1) Vasseur, et al. Expires December 24, 2006 [Page 24] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 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 |N|O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: RP object body format The RP object body 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 - 3 bits): the Priority field may be used by the requesting PCC to specify to the PCE the request's priority from 1 to 7. The decision of which priority should be used for a specific request is 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 RECOMMENDED 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 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 handling of request priorities: in other words, the path computation request has been honoured but without taking the request priority into account. R (Reoptimization - 1 bit): when set, the requesting PCC specifies Vasseur, et al. Expires December 24, 2006 [Page 25] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 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 (except of 0-bandwidth TE LSP) message by means of an RRO object defined in Section 7.9. B (Bi-directional - 1 bit): when set, the PCC specifies that the path computation request relates to a bidirectional TE LSP that has 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. O (strict/lOose - 1 bit): when set, in a PCReq message, this indicates 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. F (new - 1 bit): when set, the requesting PCC requires the computation of a new path for a TE LSP that has failed in which case the path of the existing TE LSP MUST be provided in the PCReq (except of 0-bandwidth TE LSP) message by means of an RRO object defined in Section 7.9. This is to avoid double bandwidth booking should the TED not be yet updated or the corresponding resources not be yet released. Request-ID-number (32 bits). The Request-ID-number value combined with the source IP address of the PCC and the PCE address uniquely identify the path computation request context. The Request-ID-number 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.3.2. Handling of the RP object If a PCReq message is received without containing an RP object, the PCE MUST send a PCErr message to the requesting PCC with Error- type="Required Object missing" and Error-value="RP Object missing". If the C bit of the RP message carried within a PCReq message is set and local policy has been configured on the PCE to not provide the computed path cost, a PCErr message MUST be sent by the PCE to the Vasseur, et al. Expires December 24, 2006 [Page 26] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 requesting PCC and the pending path computation request MUST be discarded. The Error-type is "Policy Violation" and Error-value is "C bit set". If the O bit of the RP message carried within a PCReq message is set and local policy has been configured on the PCE to not provide explicit path(s) (for instance, for confidentiality reasons), a PCErr message MUST be sent by the PCE to the requesting PCC and the pending path computation request MUST be discarded. The Error-type is "Policy Violation" and Error-value is "O bit set". R bit: when the R bit of the RP object is set in a PCReq message, this indicates that the path computation request relates to the reoptimization of an existing TE LSP. In this case, the PCC MUST provide the explicit or strict/loose path by including an RRO object in the PCReq message so as to avoid double bandwidth counting if and only if the TE LSP is a non 0-bandwidth TE LSP. If the PCC has previously requested a non-explicit path (O bit set), a reoptimization can still be requested by the PCC but this implies for the PCE to be either stateful (keep track of the previously computed path with the associated list of strict hops) or to have the ability to retrieve the complete required path segment. Alternatively the PCC MUST be able to inform PCE of the working path with associated list of strict hops in PCReq. The absence of an RRO in the PCReq message for a non 0-bandwidth TE LSP when the R bit of the RP object is set MUST trigger the sending of a PCErr message with Error- type="Required Object Missing" and Error-value="RRO Object missing for reoptimization". If the PCC receives a PCRep message that contains a RP object referring to an unknown Request-ID-Number, the PCC MUST send a PCErr message with Error-Type="Unknown request reference". 7.4. NO-PATH Object The No-PATH object is used in PCRep messages in response to a path computation request that was unsuccessful (the PCE could not find a path satisfying the set of constraints). When a PCE cannot find a path satisfying a set of constraints, it MUST include a NO-PATH object in the PCRep message. 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, the PCRep message MAY also contain a list of objects that specify the set of constraints that could not be satisfied. The PCE MAY just replicate the object that was received that was the cause of the unsuccessful computation or MAY optionally report a suggested value for which a path could have been found. Vasseur, et al. Expires December 24, 2006 [Page 27] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 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| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: NO-PATH object format The NO-PATH object body has a fixed length of 4 octets. Flags (16 bits). The following flags are currently defined: C flag (1 bit): when set, the PCE indicates the set of unsatisfied constraints (reasons why a path could not be found) in the PCRep message by including the relevant PCEP objects. When cleared, no reason is specified. 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 must include in the PCRep message a NO-PATH object. Optionally the PCE may also include the original BANDWIDTH object so as to indicate that the reasons for the unsuccessful computation is the bandwidth constraint (in this case, the C flag is set). If the PCE supports such capability it may alternatively include the BANDWIDTH Object and report a value of Y in the bandwidth field of the BANDWIDTH object (in this case, the C flag is set). 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-POINT Object The END-POINTS object is used in a PCReq message to specify the source IP address and the destination IP address of the path for which a path computation is requested. Note that the source and destination addresses specified in the END-POINTS object may or may not correspond to the source and destination IP address of the TE LSP but rather to a path segment. Two END-POINTS objects (for IPv4 and IPv6) are defined. END-POINTS Object-Class is to be assigned by IANA (recommended value=4) Vasseur, et al. Expires December 24, 2006 [Page 28] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 END-POINTS Object-Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 for IPv6) The format of the END-POINTS object body for IPv4 (Object-Type=1) is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: END-POINTS object body format for IPv4 The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source IPv6 address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: END-POINTS object body format for IPv6 The END-POINTS object body has a fixed length of 8 octets for IPv4 and 32 octets for IPv6. 7.6. BANDWIDTH Object The BANDWIDTH object is optional and can be used to specify the requested bandwidth for a TE LSP. In the case of a non existing TE LSP, the BANDWIDTH object MUST be included in the PCReq message so as to specify the required bandwidth for the new TE LSP. In the case of the reoptimization of an existing TE LSP, the bandwidth of the existing TE LSP MUST also be included in addition to the requested bandwidth if and only if the two values differ. Consequently, two Object-Type are defined that refer to the requested bandwidth and the bandwidth of a existing TE LSP for which a reoptimization is being Vasseur, et al. Expires December 24, 2006 [Page 29] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 performed. The BANDWIDTH object 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 (recommended value=5) Two Object-Type are defined for the BANDWIDTH object: o Requested bandwidth: BANDWIDTH Object-Type is to be assigned by IANA (recommended value=1) o Bandwidth of an existing TE LSP for which a reoptimization is performed. BANDWIDTH Object-Type is to be assigned by IANA (recommended value=2) The format of the BANDWIDTH object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: BANDWIDTH object body format Bandwidth: 32 bits. The requested bandwidth is encoded in 32 bits in IEEE floating point format, expressed in bytes per second. The BANDWIDTH object body has a fixed length of 4 octets. 7.7. METRIC Object The METRIC object is optional and can be used for several purposes. In a PCReq message, a PCC MAY insert a METRIC object: o To indicate the metric that must be optimized by the path computation algorithm. Currently, two metrics are defined: the IGP cost and the TE metric (see [RFC3785]). o To indicate a bound on the path cost than must not be exceeded for the path to be considered as acceptable by the PCC. In a PCRep message, the METRIC object MAY be inserted so as to provide the cost for the computed path. It MAY also be inserted within a PCRep with the NO-PATH object, to indicate that the metric constraint could not be satisfied. Vasseur, et al. Expires December 24, 2006 [Page 30] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 The path computation algorithmic aspects used by the PCE to optimize a path with respect to a specific metric are outside the scope of this document. 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 absence of the METRIC object MUST be interpreted by the PCE as a path computation request for which the PCE may choose the metric to be used. METRIC Object-Class is to be assigned by IANA (recommended value=6) METRIC Object-Type is to be assigned by IANA (recommended value=1) The format of the METRIC object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |C|B| T | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | metric-value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: METRIC object body format T (Type - 3 bits): Specifies the metric type. Two values are currently defined: o T=1: The IGP metric o T=2: The TE cost B (Bound - 1 bit): When set in a PCReq message, the metric-value indicates a bound (a maximum) for the path cost that must not be exceeded for the PCC to consider the computed path as acceptable. When the B flag is cleared, the metric-value field MUST be set to 0x0000. In a PCReq message, if the B-flag is cleared, then the metric-value field MUST be set to 0. The B flag MUST always be cleared in a PCRep message. C (Cost - 1 bit): When set in a PECReq message, this indicates that the PCE MUST provide the computed path cost (should a path satisfying the constraints be found) in the PCRep message with regards to the corresponding metric. Vasseur, et al. Expires December 24, 2006 [Page 31] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 Metric-value (32 bits): metric value encoded in 32 bits in IEEE floating point format. The METRIC object body has a fixed length of 8 octets. Multiple METRIC Objects MAY be inserted in a PCRep or the PCReq message. In a PCReq message the presence of multiple METRIC object can be used to specify a multi-parameters (e.g. a metric may be a constraint or a parameter to minimize/maximize) objective function or multiple bounds for different constraints. In a PCRep message, unless not allowed by PCE policy, at least one METRIC object MUST be present that reports the computed path cost if the C bit of the RP object was set in the corresponding path computation request (the B-flag MUST be cleared); optionally the PCRep message may contain additional METRIC objects that correspond to bound constraints, in which case the metric-value MUST be equal to the corresponding path metric cost (the B-flag MUST be set). If no path satisfying the constraints could be found by the PCE, the METRIC objects MAY also be present in the PCRep message with the NO-PATH object, to indicate a constraint metric (B-Flag was set in the path computation request) that cannot be satisfied. Example: if a PCC sends a path computation request to a PCE where the metric to optimize is the IGP metric and the TE metric must not exceed the value of M, two METRIC object are inserted in the PCReq message: o First METRIC Object with B=0, T=1, metric-value=0x0000 o Second METRIC Object with B=1, T=2, metric-value=M If a path satisfying the set of constraints can be found by the PCE and no policy preventing to provide the path cost in place, the PCE inserts one METRIC object with B=0, T=1, metric-value= computed IGP path cost. Additionally, the PCE may insert a second METRIC object with B=1, T=2, metric-value= computed TE path cost. 7.8. ERO Object The ERO object is used to encode a TE LSP. The ERO Object is carried within a PCRep message to provide the computed TE LSP should have the path computation been successful. The contents of this object are identical in encoding to the contents of the Explicit Route Object defined in [RFC3209], [RFC3473] and Vasseur, et al. Expires December 24, 2006 [Page 32] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 [RFC3477]. 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 [RFC3209], [RFC3473] and [RFC3477]. 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 is optional and specifies various TE LSP attributes to be taken into account by the PCE during path computation. The LSPA (LSP Attributes) object can either be carried within a PCReq message or a PCRep message in case of unsuccessful path computation (in this case, the PCRep 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 Vasseur, et al. Expires December 24, 2006 [Page 33] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 [RFC3209] and [RFC4090]. When absent from the PCReq message, this means that the Setup and Holding priorities are equal to 0, and there are no affinity constraints. 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 |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 |L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: LSPA object body format (with resource affinity) Setup Prio (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 preempt another session. Holding Prio (Holding Priority - 8 bits). The priority of the Vasseur, et al. Expires December 24, 2006 [Page 34] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 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 flag L corresponds to the "Local protection desired" bit ([RFC3209]) of the SESSION-ATTRIBUTE Object. L Flag (Local protection desired). When set, this means that the computed path must include links protected with Fast Reroute as defined in [RFC4090]. 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. When carried within a PCRep message with the NO-PATH object, the IRO indicates the set of elements that could not be included. 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 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 18: IRO object body format Subobjects The IRO object is made of sub-object(s) identical to the ones defined in [RFC3209], [RFC3473] and [RFC3477] 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. Vasseur, et al. Expires December 24, 2006 [Page 35] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 7.12. SVEC Object 7.12.1. Independent versus synchronized path computation requests The PCEP protocol allows for 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. 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+-+-+-+-+-+-+ | | | | | KeepWait |----+ | | +--| |<---+ | |+-----+-+-+-+-+-+-+ | | || | | | || | | | || V | | || +->+-+-+-+-+-+-+----+ | || | | OpenWait |-------+ || +--| |<------+ ||+----+-+-+-+-+-+-+<---+ | ||| | | | ||| | | | ||| V | | ||| +->+-+-+-+-+-+-+ | | ||| | |TCPPending |----+ | ||| +--| | | |||+---+-+-+-+-+-+-+<---+ | |||| | | | |||| | | | |||| V | | |||+--->+-+-+-+-+ | | ||+---->| Idle |-------+ | |+----->| |----------+ +------>+-+-+-+-+ Figure 15: PCEP Finite State Machine for the PCC PCEP defines the following set of variables: TCPConnect: timer (in seconds) started after having initialized a TCP connection using the PCEP well-known TCP port. The value of the TCPConnect timer is 60 seconds. TCPRetry: specifies the number of times the system has tried to establish a TCP connection with a PCEP peer without success. TCPMaxRetry: Maximum number of times the system tries to establish a TCP connection using the PCEP well-known TCP port before going back to the Idle state. The value of the TCPMaxRetry is 5. OpenWait: timer (in seconds) that corresponds to the amount of time a PCEP peer will wait to receive an Open message from the PCEP peer after the expiration of which the system releases the PCEP resource and go back to the Idle state. KeepWait: timer (in Vasseur, et al. Expires December 24, 2006 [Page 50] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 seconds) that corresponds to the amount of time a PCEP peer will wait to receive a KeepAlive or a PCErr message from the PCEP peer after the expiration of which the system releases the PCEP resource and go back to the Idle state. OpenRetry: specifies the number of times the system has received an Open message with unacceptable PCEP session characteristics. OpenMaxRetry: Maximum number of times the system can receive an Open message with unacceptable PCEP sessions characteristics before releasing the PCEP session with that peer and go back to Idle state. The value of the OpenMaxRetry is 3. The following two states variable are defined: RemoteOK: the RemoteOK variable is a Boolean set to 1 if the system has received an acceptable Open message. LocalOK: the LocalOK variable is a Boolean set to 1 if the system has received a Keepalive message acknowledging that the Open message sent to the peer was valid. Idle State: The idle state is the initial PCEP state where PCEP (also referred to as "the system") waits for an initialization event that can either be manually triggered by the user (configuration) or automatically triggered by various events. In Idle state, PCEP resources are allocated (memory, potential process, ...) but no PCEP messages are accepted from any PCEP peer. The system listens the well-known PCEP TCP port. The following set of variable are initialized: TCPRetry=0, LocalOK=0, RemoteOK=0, Upon detection of a local initialization event (e.g. user configuration to establish a PCEP session with a particular PCEP peer, local event triggering the establishment of a PCEP session with a PCEP peer, ...), the system: o Starts the TCPConnect timer, o Initiates of a TCP connection with the PCEP peer, o Increments the TCPRetry variable, o Moves to the TCPPending state. Vasseur, et al. Expires December 24, 2006 [Page 51] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 Upon receiving a TCP connection on the well-known PCEP TCP port, if the TCP connection establishment succeeds, the system: o Sends an Open message o Starts the OpenWait timer o Moves to the OpenWait state It is expected that an implementation will use an exponentially increase timer between automatically generated Initialization events and between retrials of TCP connection establishments. TCPPending State If the TCP connection establishment succeeds, the system: o Sends an Open message, o Starts the OpenWait timer, o Starts the KeepWait timer, o Moves to the OpenWait state. If the TCP connection establishement fails (an error is detected during the TCP connection establishment) or the TCPConnectTimer expires: If TCPRetry =TCPMaxRetry the system moves to the Idle State If TCPRetry variable < TCPMaxRetry the system: o Starts the TCPConnect timer, o Initiates of a TCP connection with the PCEP peer, o Increments the TCPRetry variable. If the system detects that the PCEP peer tries to simultaneously establish a TCP connection, it stops the TCP connection establishment if and only if the PCEP peer has a higher IP address and moves to the Idle state. This guarantees that in case of "collision" a single TCP connection is established. OpenWait State: In the OpenWait state, the system waits for an Open message from its Vasseur, et al. Expires December 24, 2006 [Page 52] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 PCEP peer. If the system receives an Open message from the PCEP peer before the expiration of the OpenWait timer, PCEP checks the PCEP session attributes (Keepalive frequency, DeadTimer, ...). If an error is detected (malformed Open message, unsupported PCEP session characteristics), PCEP generates an error notification, release the PCEP resources for the PCEP peer, closes the TCP connection and moves to the Idle state. If no Open message is received before the expiration of the OpenWait timer, the system releases the PCEP resources for the PCEP peer, closes the TCP connection and moves to the Idle state. If no errors are detected and the session characteristics are acceptable to the local system, the system: o Sends a Keepalive message to the PCEP peer, o Starts the Keepalive timer, o Sets the RemoteOK variable to 1. If LocalOK=1 the system moves to the UP state If LocalOK=0 the system moves to the KeepWait state. If no errors are detected but there is a disagreement on the session characteristics (such as the Keepalive frequency or the DeadTimer), a PCErr message is sent to the peer (reporting the values for which a disagreement exists). If OpenRetry=OpenMaxRetry the system releases the PCEP resources for that peer amd moves back to the Idle state. If OpenRetry < OpenMaxRetry the system: o sends a PCErr message containing proposed acceptable session characteristics, o Increments the OpenRetry variable. KeepWait State In the Keepwait state, the system waits for the receipt of a Keepalive from its PCEP peer acknowledging its Open message or a PCErr message in response to unacceptable PCEP session Vasseur, et al. Expires December 24, 2006 [Page 53] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 characteristics proposed in the Open message. If a Keepalive message is received before the expiration of the KeepWait timer, LocalOK=1 If RemoteOK=1, the system moves to the UP state. If RemoteOK=0, the system moves to the OpenWait State. If a PCErr message is received before the expiration of the KeepWait timer: 1. If the proposed values are unacceptable, the sytem releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle state. 2. If the proposed values are acceptable, the sytem adjusts its PCEP session characteristics according to the proposed values received in the PCErr message restarts the KeepWait timer and sends a new Open message. If RemoteOK=1, the system stays in the KeepWait state. If RemoteOK=0, the system moves to the OpenWait state. If neither a Keepalive nor a PCErr is received after the expiration of the KeepWait timer, the system releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle State. UP State In the UP state, the PCEP peer starts exchanging PCEP messages according to the session characteristics. If the Keepalive timer expires, the systens sends a Keepalive message. If no Keepalive message is received from the PCEP peer after the expiration of the DeadTimer, the systems sends a PCEP CLOSE message, releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle State. In a malformed PCEP message is received or the TCP connection fails, the systems sends a PCEP CLOSE message, the system releases the PCEP resources for that PCEP peer, closes the TCP connection and moves to the Idle State. 11. Security Considerations Vasseur, et al. Expires December 24, 2006 [Page 54] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 The PCEP protocol could be the target of the following attacks: o Spoofing (PCC or PCE impersonation) o Snooping (message interception) o Falsification o Denial of Service A PCEP attack may have significant impact, particularly in an inter-AS context as PCEP facilitates inter-AS path establishment. Several mechanisms are proposed below, so as to ensure authentication, integrity and privacy of PCEP Communications, and also to protect against DoS attacks. 11.1. PCEP Authentication and Integrity It is RECOMMENDED to use TCP-MD5 [RFC1321] signature option to provide for the authenticity and integrity of PCEP messages. This will allow protecting against PCE or PCC impersonation and also against message content falsification. This requires the maintenance, exchange and configuration of MD-5 keys on PCCs and PCEs. Note that such maintenance may be especially onerous to the operators as pointed out in [I-D.ietf-rpsec- bgpsecrec]. Hence it is important to limit the number of keys while ensuring the required level of security. MD-5 signature faces some limitations, as per explained in [RFC2385]. Note that when one digest technique stronger than MD5 is specified and implemented, PCEP could be easily upgraded to use it. 11.2. PCEP Privacy Ensuring PCEP communication privacy is of key importance, especially in an inter-AS context, where PCEP communication end-points do not reside in the same AS, as an attacker that intercept a PCE message could obtain sensitive information related to computed paths and resources. Privacy can be ensured thanks to encryption. To ensure privacy of PCEP communication, IPSec [RFC2406] tunnels MAY be used between PCC and PCEs or between PCEs. Note that this could also be used to ensure Authentication and Integrity, in which case, TCP MD-5 option would not be required. 11.3. Protection against Denial of Service attacks PCEP can be the target of TCP DoS attacks, such as for instance SYN Vasseur, et al. Expires December 24, 2006 [Page 55] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 attacks, as all protocols running on top of TCP. PCEP can use the same mechanisms as defined in [RFC3036] to mitigate the threat of such attacks: o A PCE should avoid promiscuous TCP listens for PCEP TCP session establishment. It should use only listens that are specific to authorized PCCs. o The use of the MD5 option helps somewhat since it prevents a SYN from being accepted unless the MD5 segment checksum is valid. However, the receiver must compute the checksum before it can decide to discard an otherwise acceptable SYN segment. o The use of access-list on the PCE so as to restrict access to authorized PCCs. 11.4. Request input shaping/policing A PCEP implementation may be subject to Denial Of Service attacks consisting of sending a very large number of PCEP messages (e.g. PCReq messages). Thus, especially in multi-Service Providers environments, a PCE implementation should implement request input shaping/policing so as to throttle the amount of received PCEP messages without compromising the implementation behavior. 12. Acknowledgements The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash, Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard Douville for their very valuable input. Special thank to Adrian Farrel for his very valuable suggestions. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Vasseur, et al. Expires December 24, 2006 [Page 56] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 13.2. Informative References [I-D.ietf-ccamp-inter-domain-rsvp-te] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in progress), March 2006. [I-D.ietf-pce-architecture] Farrel, A., "A Path Computation Element (PCE) Based Architecture", draft-ietf-pce-architecture-05 (work in progress), April 2006. [I-D.ietf-pce-comm-protocol-gen-reqs] Roux, J. and J. Ash, "PCE Communication Protocol Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs-06 (work in progress), May 2006. [I-D.ietf-pce-disco-proto-igp] Roux, J., "IGP protocol extensions for Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-proto-igp-01 (work in progress), March 2006. [I-D.ietf-pce-discovery-reqs] Roux, J., "Requirements for Path Computation Element (PCE) Discovery", draft-ietf-pce-discovery-reqs-05 (work in progress), June 2006. [I-D.ietf-pce-inter-layer-req] Oki, E., "PCC-PCE Communication Requirements for Inter- Layer Traffic Engineering", draft-ietf-pce-inter-layer-req-01 (work in progress), March 2006. [I-D.ietf-pce-pcecp-interarea-reqs] Vasseur, et al. Expires December 24, 2006 [Page 57] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 Roux, J., "PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area (G)MPLS Traffic Engineering", draft-ietf-pce-pcecp-interarea-reqs-01 (work in progress), February 2006. [I-D.ietf-rpsec-bgpsecrec] Christian, B. and T. Tauber, "BGP Security Requirements", draft-ietf-rpsec-bgpsecrec-06 (work in progress), June 2006. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 2004. [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005. Appendix A. Proposed Status and Discussion [To Be Removed Upon Publication] This Internet-Draft is being submitted for eventual publication as an RFC with a proposed status of Standard. Discussion of this proposal should take place on the following mailing list: pce@ietf.org. Appendix B. Compliance with the PCECP Requirement Document The aim of this section is to list the set of requirements set forth in [I-D.ietf-pce-comm-protocol-gen-reqs] that are not satisfied by the current revision of this document. This only concerns the requirements listed as MUST according to [RFC2119]. Here is the list of currently unsatisfied requirements: Vasseur, et al. Expires December 24, 2006 [Page 58] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 o Allow to select/prefer from advertised list of standard objective functions/options o Allow to customize objective function/options o Allow indicating if load-balancing is allowed o Support "unsynchronized" & "synchronized" objective functions o Protocol recovery support resynchronization of information & requests between sender & receiver. Appendix C. PCEP Variables PCEP defines variable that can be configured. The following PCEP variables are defined. KeepAlive timer: minimum period of time between the sending of PCEP messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer. A suggested value for the Keepalive timer is 30 seconds. DeadTimer: period of timer after the expiration of which a PCEP peer declared the session down if no PCEP message has been received. SyncTimer: the SYNC timer is used in the case of synchronized path computation request using the SVEC object defined in Section 7.12.3. Consider the case where a PCReq message is received by a PCE that comprises the SVEC object referring to M synchronized path computation requests. If after the expiration of the SYNC timer all the M path computation requests have not been received, a protocol error is triggered and the PCE MUST cancel the whole set of path computation requests. A RECOMMENDED value for the SYNC timer is 60 seconds. Vasseur, et al. Expires December 24, 2006 [Page 59] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 Authors' Addresses JP Vasseur (editor) Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: jpv@cisco.com JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion, 22307 FRANCE Email: jeanlouis.leroux@francetelecom.com Arthi Ayyangar Juniper Networks 1194 N.Mathilda Avenue Sunnyvale, CA 94089 USA Email: arthi@juniper.net Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo, 180-8585 JAPAN Email: oki.eiji@lab.ntt.co.jp Alia Atlas Google 1600 Amphitheatre Parkway Montain View, CA 94043 USA Email: akatlas@alum.mit.edu Vasseur, et al. Expires December 24, 2006 [Page 60] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 Andrew Dolganow Alcatel 600 March Road Ottawa, ON K2K 2E6 CANADA Email: andrew.dolganow@alcatel.com Yuichi Ikejiri NTT Communications Corporation 1-1-6 Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-819 JAPAN Email: y.ikejiri@ntt.com Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460 JAPAN Email: ke-kumaki@kddi.com Vasseur, et al. Expires December 24, 2006 [Page 61] Internet-Draft draft-ietf-pce-pcep-02.txt June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vasseur, et al. Expires December 24, 2006 [Page 62]