Network Working Group M. Boucadair (Ed.) P. Morand (Ed.) Internet Draft France Telecom R&D Document: draft-boucadair-pcp-interas-00.txt October 2004 Category: Standards Track Inter-AS PCE Communication protocol draft-boucadair-pcp-interas-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667 [RFC3667]. 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 become aware will be disclosed, in accordance with RFC 3668 [RFC3668]. 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 April 2005. Abstract This draft describes a new protocol allowing communication between two Path Computation Elements (PCEs) located in different domains in order to compute inter-domain paths satisfying a set of QoS constraints. This protocol could also be used for intra-domain purposes. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 1] Internet Draft PCE Communication protocol October 2004 Table of Contents 1. Contributors................................................2 2. Terminology.................................................2 3. Introduction................................................3 4. Conventions used in this document...........................4 5. Overview of overall service approach........................4 6. PCE to PCE communication....................................5 7. PCP messages................................................6 7.1. Common header...............................................6 7.2. OPEN message................................................7 7.3. ACCEPT message..............................................7 7.4. CLOSE message...............................................7 7.5. REQUEST message.............................................8 7.6. RESPONSE-PATH message......................................11 7.7. PATH-ERROR message.........................................12 7.8. CANCEL message.............................................13 7.9. ACKNOWLEDGE message........................................14 7.10. KEEPALIVE message (KA)......................................14 8. Exchange of PCP messages...................................14 8.1. Communication..............................................14 8.2. OPEN (OPN).................................................14 8.3. ACCEPT (ACP)...............................................15 8.4. CLOSE (CLO)................................................15 8.5. REQUEST (REQ)..............................................15 8.6. RESPONSE (RSP).............................................18 8.7. ACKNOWLEDGE (ACK)..........................................18 8.8. CANCEL (CCL)...............................................19 9. State diagram..............................................19 10. Security Considerations....................................19 11. References.................................................20 12. Acknowledgments............................................20 13. Author's Addresses.........................................21 1. Contributors o Hamid Asgari (Thales Research and Technology) o Panagiotis Georgatsos (Algonet) o David Griffin (University College London) o Micheal Howarth (University of Surrey) 2. Terminology This memo makes use of the following terms: o Path Computation Element (PCE): an entity that is responsible for computing/finding inter/intra domain LSPs. This entity can simultaneously act as client and a server. Several PCEs can be deployed in a given AS. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 2] Internet Draft PCE Communication protocol October 2004 o Path Computation Client (PCC): a PCE acting as a client. This entity is responsible for issuing path computation requests that fulfill the Service Management constraints for the establishment of inter/intra domain LSPs. o Path Computation Server (PCS): a PCE acting as a server. This entity is responsible for handling path computation requests including neighboring PCC constraints. o High-level service: is the service using a PCE-based system as an underlying infrastructure (an inter-domain QoS VPNs service for instance) o High-level service customer: is a customer that subscribes to a High-level service. o pSLS: A provider SLS is an SLS established between two Internet Network Providers (INP) with the purpose of extending the geographical span of their service offers. o SLS Management: this includes service ordering (i.e establishing contracts between peers) and invocation (i.e committing resources before traffic can be admitted) o Q-BGP: QoS-inferred BGP. A modified BGP protocol that takes into account QoS information as input to for its route selection process. o Domain: within this draft it denotes an Autonomous system. 3. Introduction Nowadays, services are deployed on a same basic infrastructure (best- effort shared IP network) on which more elaborate functionalities (MPLS for instance) rely for providing enhanced network services. Especially those intended for specific corporate customers or providers needs. These extra functionalities were introduced because the basic IP approach failed to support those added-value services or was not considered to be efficient enough. MPLS is a technical solution that has been successfully deployed by a large number of providers for supporting connection-oriented services such as IP VPN services for which traffic isolation is an important criterion. Then, the solution evolved to encompass QoS issues, and Traffic engineering functions were then progressively introduced. Up to now, some providers have deployed MPLS TE but only within their own domains. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 3] Internet Draft PCE Communication protocol October 2004 Extending the scope of offered intra-domain services (like QoS-based services), using MPLS as infrastructure, to the Internet scale is conditioned by the cooperation between service providers. Several proposals have been proposed within the IETF in order to deal with this issue but only from inter-AS point of view (see for example [INTERAREA-REQ], [INTERAS-REQ], [PCE-ARCH] and [PCE-FWK]). Inter-provider issues need to be studied further in order to build a complete end-to-end solution. Draft [INTERAS-PCE] describes a solution that could be implemented in order to offer end-to-end services. This solution requires a close cooperation between distinct Path Computation Elements (PCE) that are located in distinct domains. This draft describes a protocol to use for communication between two Path computation Elements. The structure of this draft is as follows: o Section 5 presents an overview of the overall service approach;. o Section 6 lists characteristics of the PCP protocol;. o Sections 7 and 8 detail the PCP messages and operations. 4. 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 [RFC2119]. 5. Overview of overall service approach Neighboring domains establish pSLSs between themselves. An inter- domain routing protocol runs between the domains. This inter-domain routing protocol is used to announce PCE unique identifiers [PCE- DISCOVERY] across the Internet in order for other PCEs to be able to discover possible paths towards every AS having a PCE. Therefore, when an AS wants to establish an LSP between 2 addresses, its PCE forms a path computation request containing the HEAD-END-ADDRESS and the TAIL-END-ADDRESS defining the future LSP. In addition to the IP address of the head and the tail of the LSP, each X-END-ADRESS contains also the PCE unique identifier of the AS these IP addresses belong to. Using information reported by BGP the PCE identifies possible paths that reach the target AS identified by its PCE unique identifier. It then selects one of these paths and forms a new request, which is sent to the neighboring PCE it selected along that path. The path computation request is propagated downstream to the appropriate PCEs and is repeated until the request reaches the Boucadair (Ed.) Standards Track - Expires April 2005 [Page 4] Internet Draft PCE Communication protocol October 2004 destination PCE. Each PCE along the path ensures that the constraints expressed by the request are satisfied. Each PCE is responsible for computing both the intra- and inter-domain sub-path and to ensure that resources are available and will remain available until the LSP is effectively created. If for some reasons the path computation aborts, all resources must be relaxed. After authenticating the identity of LSP requester (originating) PCE, the destination PCE sends a reply message back to the downstream domain's PCE accepting the request. The LSP sub-path (from the ingress ASBR and the final destination) is inserted in the message. The next downstream domain's PCE does the same adding its own relevant sub-path to the overall loose or strict path. At the end of the chain, the originating PCE does also the same. An end-to-end path has thus been computed. The originating PCE is now in a position to provide the service request handler with appropriate information (end-to-end inter-domain path) allowing an RSVP reservation to be issued for the establishment of the LSP. At the service/application level, when an originating AS wants to establish an LSP towards a destination ASs, there MUST exist a preliminary agreement between the two ASs (Service providers owning these PCEs). This agreement specifies both the tail-end and head-end address of the LSP, together with the PCE unique identifier of the originating and destination AS. This allows only agreed LSP to be established. 6. PCE to PCE communication A PCE can act as a client (PCC) or a server (PCS). A PCC is responsible for issuing requests. PCS is responsible for handling requests received from PCCs. +------------+ +------------+ | PCE | | PCE | | | | | | +------+ | | +------+ | | | PCC | | | | PCC | | | | |<-|-------\ | | | | | +--/\--+ | | | +--/\--+ | | || | |PCP | || | | || | | | || | | +--\/--+ | | | +--\/--+ | | | PCS | | \---------------|->| PCS | | | | | | | | | | | +------+ | | +------+ | +------------+ +------------+ PCP protocol is used for communication between a PCC and a PCS. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 5] Internet Draft PCE Communication protocol October 2004 PCP is a simple query and response protocol that can be used between PCE entities to collaborate for computing an inter-domain QoS constrained path. The main characteristics of the PCP protocol include: o The protocol employs a client/server model in which a PCE can both act as a client and/or a server at the same time. A PCE Client (PCC) sends requests, cancellation and receives responses. o The protocol uses TCP as its transport protocol for reliable exchange of messages between PCE. Therefore, no additional mechanisms are necessary for reliable communication between two PCE. o In this first version, PCP does not provide any encryption mechanism, replay protection, and message integrity. But PCP can reuse existing protocols for security such as IPSEC [RFC2401] or TLS [RFC2246] to authenticate and secure the channel between two PCE. o The PCP protocol described below supports only a basic path computation service. In particular it doesn't support additional path computation constraints, nor enhanced reporting features in case of path computation failure. 7. PCP messages This section discusses the PCP message formats and objects exchanged between PCE entities. 7.1. Common header Each PCP message consists of the PCP header followed by a number of arguments depending on the nature of the operation. 0 1 2 3 +--------------+--------------+--------------+--------------+ | Version | Op Code | Message Length | +--------------+--------------+--------------+--------------+ Global note: //// implies field is reserved, set to 0. The fields in the header are: Version: 8 bits. PCP version number. Current version is 1. Op Code: 8 bits. The PCP operations are: 1 = OPEN (OPN) Boucadair (Ed.) Standards Track - Expires April 2005 [Page 6] Internet Draft PCE Communication protocol October 2004 2 = ACCEPT (ACP) 3 = CLOSE (CLO) 4 = REQUEST (REQ) 5 = RESPONSE (RSP) 6 = PATH-ERROR (ERR) 7 = CANCEL (CCL) 8 = ACKNOWLEDGE (ACK) 9 = KEEP-ALIVE (KA) Message Length: 16 bits This is the size of the message in octets, which includes the standard PCP header and all encapsulated objects. Messages MUST be aligned on 4 octet intervals. 7.2. OPEN message 0 1 2 3 +-------------+-------------+-------------+-------------+ | | | PCSID | | | | | +-------------+-------------+-------------+-------------+ The message contains only one argument. This PCSID is propagated by BGP between the domains. This is a routable IPv4 or IPv6 address identifying a PCS of a domain. This PCSID must be inserted by the PCE opening a PCP session. The size of the PCSID is 4 or 16 bytes. 7.3. ACCEPT message 0 1 2 3 +-------------+-------------+-------------+-------------+ | KA-Timer |///////////////////////////| +-------------+-------------+-------------+-------------+ o KA-Timer (Keep-Alive Timer): The argument of the accept message is a 2 octets integer value which represents a timer value expressed in units of seconds. This timer value is treated as a delta. KA-Timer is used to specify the maximum time interval over which a PCP message MUST be sent by the two communication entities. The range of finite timeouts is 1 to 65535 seconds represented as an unsigned two-octet integer. The value of zero implies infinity. 7.4. CLOSE message The close message contains an error code indicating the reason of the close of the session. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 7] Internet Draft PCE Communication protocol October 2004 0 1 2 3 +--------------+--------------+--------------+--------------+ | Error-Code | ////////////////////////////| +--------------+--------------+--------------+--------------+ Error-Code: 1 = Shutting Down 2 = Bad Message Format 3 = Incorrect identifier 4 = Unable to process 5 = Protocol error 7.5. REQUEST message The Request message is sent by the PCC for computing and inter-domain path. +-------------+ 1 byte | TTL | +-------------+ 1 byte | L0 | +-------------+-------------+-------------+-------------+ 2 bytes| AS-NUMBER | +-------------+-------------+-------------+-------------+ // // +-------------+-------------+-------------+-------------+ 2 bytes| AS-NUMBER | +-------------+-------------+-------------+-------------+ 2 bytes| L1 | +-------------+-------------+-------//----+-------------+ | PATH-COMPUTATION-ID | |-----------------------------------//------------------| 2 bytes| L2 | +-------------+-------------+-------//----+-------------+ | PATH-REFERENCE-ID | +-------------+-------------+-------//----+-------------+ 2 bytes| REQ-REFERENCE-ID | +-------------+-------------+-------------+-------------+ 1 byte | ADD-TYPE | +-------------+-------------+-------//----+-------------+ | HEAD-END-ADDRESS | +-------------+-------------+-------//----+-------------+ | TAIL-END-ADDRESS | +-------------+-------------+-------//----+-------------+ 1 byte | NUMBER-OF-QC-CONSTRAINT + +-------------+-------------+ 2 bytes| QC-CONSTRAINT-LENGTH + +-------------+-------------+ 1 byte | QOS-CLASS-IDENTIFIER + +-------------+-------------+---------------------------+ 1 byte | QOS-INFO-CODE + QOS-INFO-SUB-CODE | Boucadair (Ed.) Standards Track - Expires April 2005 [Page 8] Internet Draft PCE Communication protocol October 2004 +-------------+-------------+-------------+-------------+ 2 bytes| QOS-INFO-VALUE | +-------------+-------------+-------------+-------------+ | QOS-INFO-CODE + QOS-INFO-SUB-CODE | +-------------+-------------+-------------+-------------+ | QOS-INFO-VALUE | +-------------+-------------+-------------+-------------+ | QOS-INFO-CODE + QOS-INFO-SUB-CODE | +-------------+-------------+-------------+-------------+ | QOS-INFO-VALUE | +-------------+-------------+-------------+-------------+ o TTL: is the maximum number of ASs that can be crossed by the path. This field is decremented by one each time a PCS issues a request. o L0: is a 1-byte length field. It represents the number of ASs that have already been crossed. o AS-NUMBER: is a 2 bytes length field representing an AS number. The first AS-NUMBER value of the list is the AS-NUMBER of the PCC that initialized a path computation. o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of this field is 2 bytes. o PATH-COMPUTATION-ID: is a globally unique value that identifies a path computation occurrence. It is a variable-length field. It is suggested, at least in this first specification, that this identifier is computed using the PCSID of the domain, concatenated with the date and an identifier that will be computed by the first requesting PCC each time a request will have to be issued. Across PCC reboots, this identifier must be unique. This PATH-COMPUTATION-ID will be replicated in all subsequent request initiated by the PCEs along the path. o L2: is the length in bytes of the PATH-REFERENCE-ID. Size of this field is 2 bytes. o PATH-REFERENCE-ID: is a variable-length field. It is an identifier that represents a pre-agreement between the head and the tail-end domain that allows the PCS from the terminating domain to accept or reject the path computation request. o REQ-REFERENCE-ID: is a 2 bytes length field representing an unsigned integer. This field is used to identify the REQUEST. It allows making the difference between several REQ issued for different path computation (but same PATH-COMPUTATION-ID) between two neighbor ASs interconnected via multiple links. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 9] Internet Draft PCE Communication protocol October 2004 o ADD-TYPE: indicates the nature of the IP addresses of the tail- end and head-end termination: o 1 = IPv4 o 2 = IPv6 o HEAD-END-ADDRESS: is the head-end address of the future LSP represented in the form HEAD-END@PCSID. This is a couple of IPv4 or IPv6 address. The first address of the couple identifies a loopback or an interface address of a network element, the second element is the PCSID of the domain owning the previous address. o TAIL-END-ADDRESS: is the tail-end address of the LSP represented in the form TAIL-END@PCSID. This is a couple of IPv4 or IPv6 address. The first address of the couple identifies a loopback or an interface address of a network element, the second element is the PCSID of the domain owning the previous address. These above parameters MUST be present in each REQUEST and in the same order. o NUMBER-OF-QC-CONSTRAINT: represents the number of QoS class constraints the PCS must take into account when computing a path. A QoS class constraint contains a QoS-Class-Identifier (like a DSCP value) followed by additional constraints. The size of this filed is 1 byte. This field in not really necessary in this first version of the specification but it could become useful if additional path constraints were included in the request. o QC-CONSTRAINT-LENGTH: is the number in byte of the QoS-Class- Constraint that follows. The size of this field is 2 bytes. o QOS-CLASS-IDENTIFIER: identifies a particular QoS-class. The size of the field is 1 byte. o QOS-INFO-CODE: this field identifies the type of QoS information. The size of this field is 4 bits. This code could be: o (0) Reserved o (1) Packet rate o (2) One-way delay metric o (3) Inter-packet delay variation o QOS-INFO-SUB-CODE: this field carries the sub-type of the QoS information. The following sub-types have been identified. The size of this field is 4 bits. o (0) None o (1) Reserved rate o (2) Available rate Boucadair (Ed.) Standards Track - Expires April 2005 [Page 10] Internet Draft PCE Communication protocol October 2004 o (3) Loss rate o (4) Minimum one-way delay o (5) Maximum one-way delay o (6) Average one-way delay o QOS-INFO-VALUE: this field indicates the value of the QoS information. These are the constraints that the PCE should respect. The corresponding units depend on the instantiation of the QoS information code. 7.6. RESPONSE-PATH message This message is sent back when a path has been successfully computed. +-------------+-------------+ 2 bytes| L1 | +-------------+-------------+-------//----+-------------+ | PATH-COMPUTATION-ID | |-----------------------------------//------------------| 2 bytes| REQ-REFERENCE-ID | |-----------------------------------//------------------| 1 bytes| PATH-LENGTH | +-------------+ 1 byte | ADD-TYPE | +-------------+-------------+-------//----+-------------+ | NEXT-HOP | +-------------+-------------+-------//----+-------------+ // // +-------------+-------------+-------//----+-------------+ | NEXT-HOP | +-------------+-------------+-------//----+-------------+ 8 bytes| VALIDITY-DATE + +-------------+-------------+ 1 byte | NUMBER-OF-QC-CONSTRAINT + +-------------+-------------+ 2 bytes| QC-CONSTRAINT-LENGTH + +-------------+-------------+ 1 byte | QOS-CLASS-IDENTIFIER + +-------------+-------------+---------------------------+ 1 byte | QOS-INFO-CODE + QOS-INFO-SUB-CODE | +-------------+-------------+-------------+-------------+ 2 bytes| QOS-INFO-VALUE | +-------------+-------------+-------------+-------------+ | QOS-INFO-CODE + QOS-INFO-SUB-CODE | +-------------+-------------+-------------+-------------+ | QOS-INFO-VALUE | +-------------+-------------+-------------+-------------+ | QOS-INFO-CODE + QOS-INFO-SUB-CODE | +-------------+-------------+-------------+-------------+ | QOS-INFO-VALUE | +-------------+-------------+-------------+-------------+ Boucadair (Ed.) Standards Track - Expires April 2005 [Page 11] Internet Draft PCE Communication protocol October 2004 o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of this field is 2 bytes. o PATH-COMPUTATION-ID: is a globally unique value that identifies a path computation occurrence. It is a variable-length field. This value of this identifier MUST be the same as the one provided by the REQUEST. o REQ-REFERENCE-ID: is a 2 bytes length field representing an unsigned integer. This field is used to reference the initial REQUEST. o PATH-LENGTH: indicates the number of next hops that form the path. The size of this filed is 1 byte. o ADD-TYPE: indicates the nature of the IP addresses in the PATH. The size of this filed is 1 byte. o 1 = IPv4 o 2 = IPv6 o NEXT-HOP: IP address of a next hop that is part of the computed path. Size of this field depends on the nature of the IP address. o VALIDITY-DATE: represents the GMT date after which the computed path returned will not be valid. The size of this field is 8 bytes. These above parameters MUST be present in each RESPONSE and in the same order. The other parameters have the same meaning than for the REQUEST except: o QOS-INFO-VALUE: represents the QoS guarantees of the path, for this particular QoS-INFO-CODE parameter (delay, jitter,à) between the ingress ASBR of the responding PCS domain and the tail-end of the path. 7.7. PATH-ERROR message This message is sent back when a path could not be computed. +-------------+-------------+ 2 bytes| L1 | +-------------+-------------+-------//----+-------------+ | PATH-COMPUTATION-ID | |-----------------------------------//------------------| 2 bytes| REQ-REFERENCE-ID | |-----------------------------------//------------------| Boucadair (Ed.) Standards Track - Expires April 2005 [Page 12] Internet Draft PCE Communication protocol October 2004 1 bytes| REASON-CODE | +-------------+-------------+ o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of this field is 2 bytes. o PATH-COMPUTATION-ID: is a globally unique value that identifies a path computation occurrence. It is a variable-length field. This identifier MUST be the same as the one provided by the REQUEST. o REQ-REFERENCE-ID: is a 2 bytes length field representing an unsigned integer. This field is used to reference the initial REQUEST. o REASON-CODE: indicate the reason of the failure. Identified failure are: 1 = No resource available 2 = Path reference error 3 = Abnormal termination 4 = PATH-COMPUTATION-ID already used 5 = TTL expired 6 = Loop detected 7 = Request already handled 7.8. CANCEL message This message is sent by a PCC or a PCS when a path computation must be cancelled. +-------------+-------------+ 2 bytes| L1 | +-------------+-------------+-------//----+-------------+ | PATH-COMPUTATION-ID | |-----------------------------------//------------------| 2 bytes| REQ-REFERENCE-ID | |-------------------------------------------------------| o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of this field is 2 bytes. o PATH-COMPUTATION-ID: is a globally unique value that identifies a path computation occurrence. It is a variable-length field. This identifier MUST be the same as the one provided by the REQUEST. o REQ-REFERENCE-ID: is a 2 bytes length field representing an unsigned integer. This field is used to reference the initial REQUEST. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 13] Internet Draft PCE Communication protocol October 2004 7.9. ACKNOWLEDGE message This message is sent by a PCC to a PCS to confirm the reservation of the path. This feature is particularly used when a PCC launches multiple REQUESTs during its path computation phase. +-------------+-------------+ 2 bytes| L1 | +-------------+-------------+-------//----+-------------+ | PATH-COMPUTATION-ID | |-----------------------------------//------------------| 2 bytes| REQ-REFERENCE-ID | |-------------------------------------------------------| o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of this field is 2 bytes. o PATH-COMPUTATION-ID: is globally unique value that identifies a path computation occurrence. It is a variable-length field. This identifier MUST be the same as the one provided by the REQUEST. o REQ-REFERENCE-ID: is a 2 bytes length field representing an unsigned integer. This field is used to reference the initial REQUEST. 7.10. KEEPALIVE message (KA) Message exchanged between two PCEs to maintain TCP session when no other messages are exchanged. This message has no argument. 8. Exchange of PCP messages 8.1. Communication The PCP protocol uses a single persistent TCP connection between a PCC and a remote PCS. One PCE server implementation per server MUST listen on a well-known TCP port number (to be defined). The PCC is responsible for initiating the TCP connection to the PCS. The location of the remote PCS is deduced and retrieved from the management plane blocks during the path computation process or at PCS boot via the SLS management block. PCE can have crossed communication; some are acting as a client role, others as a server role. 8.2. OPEN (OPN) An OPN message MUST be sent before any other message exchange. As part of the open message, the PCC provide its PCSID, which allows the server to identify the client. It can also use this information to Boucadair (Ed.) Standards Track - Expires April 2005 [Page 14] Internet Draft PCE Communication protocol October 2004 retrieve the client context near its management plane. Only one OPN message can be issued at a time. If the PCS receives malformed message it MUST close the session using the appropriate error code. 8.3. ACCEPT (ACP) The ACP message is used to positively respond to the OPN message from the PCC. This message will return to the PCC a timer value object indicating the maximum time interval between keep-alive messages. If the PCS refuses the PCC open message, it will instead issue a CLOSE message. The KA-Timer corresponds to maximum acceptable intermediate time between the generation of messages by the PCEs. The timer value is determined by the PCS and is specified in seconds. 8.4. CLOSE (CLO) The CLOSE message can be issued by either the PCC or the PCS to notify the other that it is no longer available. The Error code is included to describe the reason for the close. When issuing a CLOSE both the PCC and the PCS MUST delete all the internal states related to this PCP session. Additionally, all pending requests MUST be explicitly cancelled using a CCL message in order to free as much as possible all pending resources reservations and/or pre-contracts that could have been established. 8.5. REQUEST (REQ) A request is issued by a PCC when it has found a potential path toward the target final destination. This request can be issued as a consequence of a request received from another domain it has agreement with or from its own service management plane. When the service request comes from a remote PCC, the server achieves the following tasks: (0) If the receiving TTL is zero the PCS MUST discard the request. The receiving PCS, decrements by one the received TTL value. If the TTL is equal to zero, the request is rejected if the PCS is not the last PCS in the chain. In addition the PCS examines the AS-PATH included in the received REQ and reject it if it finds its own AS number in the list. This mechanism allows avoiding possible loops when a limited set of QoS constraints are provided in the request. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 15] Internet Draft PCE Communication protocol October 2004 (1) It checks if the PATH-COMPUTATION-ID of the received REQ is already associated to a pre-contract or contract. If this is the case, it returns a PATH-ERROR message with a reason-code = 4. It checks if the PATH-COMPUTATION-ID and the REQ-REFERENCE-ID of the received REQ are already associated to a pre-reservation record. If a pre-reservation is found, it returns a PATH-ERROR message with a reason-code = 4. (2) It considers the HEAD-END-ADDRESS and the TAIL-END-ADDRESS parameters present in the request. The HEAD-END-ADDRESS MUST indicate a valid entry point in its domain. If not, the PCS returns a PATH-ERROR with an appropriate reason value. (3) Then it extracts the PCSID from the TAIL-END-ADDRESS and parses the QoS constraints provided at part of the request message. It has thus identified all QoS-class required together with their associated QoS constraints. (4) The PCS achieves some policing and verifies that the request constraints will not exceed the resources negotiated in the pSLS. If resources are exceeded, the PCS returns a PATH-ERROR message. (5) If the PCS recognizes its own PCSID in the TAIL-END-ADDRESS, it considers the PATH-REFERENCE-ID otherwise it jumps to step (6). If this identifier is known from its management plane, the request is accepted and processing continues on (51). Otherwise the PCS returns a PATH-ERROR message with a reason-code = 2. (51) The PCS computes an intra-domain path and verifies the availability of the resources along this internal path. If available, the PCS interacts with its management plane and create a contract, which triggers the administrative reservation of the resources. When interacting with the management blocks, the PCS MUST provide all information necessary to identify the sub-path it selected. In particular it MUST provide the PATH- COMPUTATION-ID, the ingress point ASBR address used in its domain and the termination point in its domain. The PCS sends a RESPONSE-PATH message back to the requesting PCC. If resources are not available a PATH-ERROR message is generated. (6) It then queries the dynamic inter-domain traffic-engineering block with the retrieved PCSID and the list of requested QoS- classes. The dynamic inter-domain TE block returns the available BGP announcements. The PCS then verifies whether it can find a next-hop ASBR, which announces the PCSID within the requested QoS-class. If cannot find it the procedure stops and a PATH- ERROR message is returned back to the requesting entity with an appropriate reason-code value. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 16] Internet Draft PCE Communication protocol October 2004 (7) If one or several next-hops are found, the PCS examines the QoS performance guarantees of the announcements and compare the values with those requested in the request. If it doesn't understand one of the requested QoS constraints, PATH-ERROR message is sent back. Otherwise, QoS constraints are successively compared to those received from q-BGP. All next- hops propagating the set of announcements satisfying the required QoS constraints are kept. The others are left on side. (8) For each possible next hop ASBR the PCS checks is there are enough available resources available at the domain boundaries. In particular if some bandwidth guarantees are required the PCS checks if the administrative maximum bandwidth agreed during the pSLS negotiation phase will not be exceeded. If resources are not available the ASBR is left on side and the next ASBR in the list is considered. If resources are available, the PCS pre-reserves the corresponding resources near the management plane. At this stage, the management plane doesn't create any contract since we are not sure that an end-to-end path exists. This pre- reservation can be taken into account by the PCS for subsequent requests. It can use it as a lock and delay the incoming requests or introduce the pre-reservations in its resource availability computation according to the local policy enforced. When interacting with the management blocks, the PCS must provide all information necessary to identify the sub-path it selected. In particular it must provide the PATH-COMPUTATION-ID, the ingress point address of its domain and the ingress point address of the next domain. This latter information can be used by the management plane to identify the upstream and downstream involved domains. o (81) The PCS computes an intra-domain path and verifies the availability of the resources along this internal path. If resources are available, the sub-path is valid and the PCE forms a new REQUEST message which is sent to the PCS of the remote domain owning the next-hop ASBR. It adds its own AS number to the existing list. If internal resources are not available, the PCS discard the pre-reservation and considers the next hop ASBR in the list. When building the request the PCC keeps the PATH-COMPUTATION-ID, the PATH-REFERENCE-ID, the TAIL-END-ADDRESS unchanged. The initial HEAD-END-ADDRESS is replaced by the address of the ingress next-hop ASBR identified during the path computation. The QoS constraints characteristics are modified in order to take into account the QoS performance guarantees provided by the domain. (9) If QoS constraints cannot be satisfied for any of the ASBR, the PCS returns a PATH-ERROR message. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 17] Internet Draft PCE Communication protocol October 2004 Note that it is quite possible that several next hops ASBR can satisfy the requested constraints. In such a case the PCS can process one next-hop ASBR at a time or several in parallel. For one incoming request, there can be multiple simultaneous outgoing requests towards different PCS. If several requests are sent toward the same neighbor, for a same PATH-COMPUTATION-ID, the REQ-REFERENCE-ID must be different. Nevertheless, this feature can lead to scalability issues and needs further investigations. 8.6. RESPONSE (RSP) A RESPONSE message is sent by a PCS in response to a request issued by a PCC. RSP messages are sent back when a valid end-to-end path has been computed. The RSP message MUST initiated by the tail-end domain. When a valid end-to-end path has been computed, the PCS of the last domain on the path, forms a RSP message. It first inserts the original PATH-COMPUTATION-ID. Then its forms a path argument that MUST contains the IP address of the tail-end LSP and the IP address interface of the ingress ASBR supporting that path. It MAY insert between these two extremities, the IP address of additional hops. It MAY also indicates the date after which the path will not be valid anymore because administratively reserved resources will have been relaxed. Then, it MUST indicate QoS guarantees it provides between the ingress ASBR and the tail-end address of the LSP. The RSP message is then sent to the requesting PCC. On receipt, the PCC adds its own intra-domain sub-path to the list. It does not indicate the next-hop ASBR since this latter has already been inserted by the downstream PCS. This sub-path can be a strict or loose description. It also modifies the QoS guarantee parameters so that they reflect the QoS guarantees it can provide for its part of the path. This is achieved in the same way than for the request, but it is an "addition" operation if we consider the delay, for example. The VALIDITY-DATE MUST modified so that the value indicates now the smaller date between the date received in the RSP message and the date reported by the management plane. If the PCC sent multiple REQUEST messages in parallel, it MAY wait for a RSP or ERR message for all the requests it sent. If the PCC got multiple RSP messages it MUST select only one and inform the un- selected PCS that they can cancel their reservation. It forms CANCEL messages, sends them to the appropriate PCS and cancels its own pre- reservation for the corresponding requests. If the PCC doesn't whish to wait for a reply, it can send a CANCEL message at any time. The PCS can send the consolidated RES message to the requesting PCC after sending ACK message to the PCS it decided to keep in the path. 8.7. ACKNOWLEDGE (ACK) Boucadair (Ed.) Standards Track - Expires April 2005 [Page 18] Internet Draft PCE Communication protocol October 2004 The ACK message is used by PCS to confirm to its management plane that the resources needed for the path referenced by PATH- COMPUTATION-ID present in the message need to be reserved. It allows the management plane to create a contract based on information previously stores by the PCS during the computation phase. If no ACK is received, no contract is created and the negotiation at the management level will fail. If for some reasons, no ACK were received, the VALIDITY-DATE would be used and the administrative pre- reservation automatically removed for that path. ACK messages are only accepted if they arrive after the server has issued a RSP otherwise they are ignored. 8.8. CANCEL (CCL) A CANCEL message can be sent by PCC and PCS. CCL messages can be generated during the normal path computation cycle but also in case of an abnormal termination of a PCE to PCE communication. If a PCE, acting as a server for the PCP session, received a CCL message from the PCC, it MUST form new CCL messages and forward a CCL message to each PCS to which it sent a REQ for which it did not received any positive or negative reply. Once this has been achieved it MUST delete all its internal states referencing the PATH- COMPUTATION-ID indicated in the message. If the PCE has no pending request concerning this PATH-COMPUTATION-ID, it can optionally query its management plane to retrieve a possible existing contract referenced by this PATH-COMPUTATION-ID and delete it. Just before deleting this contract, it can form a new CCL message and forward it to the next PCS in the path. If it does not, the VALIDITY-DATE will be applied. The same procedure applies if the PCE server detects a communication problem with one of its PCC. In that case, the PCS issues CCL messages for all pending request received from this PCC. When a PCE, acting as a client for the PCP session, received a CCL message from a PCE server, this indicates that a PCS along the path towards the target destination has experienced communication problems leading to close a PCP communication. In such a case, each PCC cancels all the internal states referencing this PATH-COMPUTATION-ID and forward this indication to the upstream client PCS up to the initial requestor. 9. State diagram TBD. 10. Security Considerations PCP is a communication protocol that is used between two PCEs. No security mechanisms are defined in this PCP specification. It is Boucadair (Ed.) Standards Track - Expires April 2005 [Page 19] Internet Draft PCE Communication protocol October 2004 recommended that a security protocol like IPSec or TLS MUST be activated in order to protect PCP sessions. 11. References [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, February 2004 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", RFC 3668, February 2004 [INTERAREA-REQ] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", draft-ietf-tewg- interarea-mpls-te-req-00.txt, March 2004 (work in progress) [INTERAS-REQ] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic Engineering requirements", draft-ietf-tewg-interas-mpls- te-req-06.txt, January 2004 (work in progress). [PCE-ARCH] Ash, J., Farrel, A., Vasseur, JP., " Path Computation Element (PCE) Architecture", draft-ash-pce-architecture-00.txt, September 2004 [PCE-FWK] Farrel, A., Vasseur, JP., Ayyangar, A., "A Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter- domain-framework-00.txt, August 2004 [INTERAS-PCE] Boucadair, M., Morand, P., "A Solution for providing inter-AS QoS tunnels", draft-mescal-pce-interas-00.txt, October 2004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [PCE-DISCOVERY] Boucadair, M., Morand, P., "PCE Discovery via Border Gateway Protocol", draft-mescal-pce-discovery-00.txt, October 2004 [RFC2401] Atkinson R., "Security Architecture for the Internet Protocol", RFC 2401, August 1998. [RFC2246] Dierks T., Allen C., " The TLS Protocol", RFC 2246, January 1999 12. Acknowledgments The authors would also like to thank all the partners of the MESCAL (Management of End-to-End Quality of Service Across the Internet At Large, http://www.mescal.org) project for the fruitful discussions. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 20] Internet Draft PCE Communication protocol October 2004 13. Author's Addresses Mohamed Boucadair France Telecom R & D 42, rue des Coutures BP 6243 14066 Caen Cedex 4 France Phone: +33 2 31 75 92 31 Email: mohamed.boucadair@francetelecom.com Pierrick Morand France Telecom R & D 42, rue des Coutures BP 6243 14066 Caen Cedex 4 France Email: pierick.morand@francetelecom.com 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 Boucadair (Ed.) Standards Track - Expires April 2005 [Page 21] Internet Draft PCE Communication protocol October 2004 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 (2004). 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. Boucadair (Ed.) Standards Track - Expires April 2005 [Page 22]