Network Working Group M. Boucadair (Ed.)
P. Morand (Ed.)
Internet Draft France Telecom R&D
Document: draft-boucadair-pce-comm-proto-00.txt May 2005
Category: Standards Track
Inter PCE Communication protocol
draft-boucadair-pce-comm-proto-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 November 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.
Table of Contents
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 1]
Internet Draft PCE Communication protocol May 2005
1. Contributors................................................2
2. Changes since last version:.................................2
3. Terminology.................................................3
4. Introduction................................................3
5. Conventions used in this document...........................4
6. Overview of overall service approach........................4
7. PCE to PCE communication....................................5
8. PCP messages................................................6
8.1. Common header...............................................6
8.2. OPEN message................................................7
8.3. ACCEPT message..............................................7
8.4. CLOSE message...............................................8
8.5. REQUEST message.............................................8
8.6. RESPONSE-PATH message......................................11
8.7. PATH-ERROR message.........................................12
8.8. CANCEL message.............................................13
8.9. ACKNOWLEDGE message........................................14
8.10. KEEPALIVE message (KA)......................................14
9. Exchange of PCP messages...................................14
9.1. Communication..............................................14
9.2. OPEN (OPN).................................................15
9.3. ACCEPT (ACP)...............................................15
9.4. CLOSE (CLO)................................................15
9.5. REQUEST (REQ)..............................................15
9.6. RESPONSE (RSP).............................................18
9.7. ACKNOWLEDGE (ACK)..........................................19
9.8. CANCEL (CCL)...............................................19
10. Security Considerations....................................20
11. References.................................................20
12. Acknowledgments............................................21
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)
o Thibaut Coadic (France Telecom)
2. Changes since last version:
The main changes occurred in this version are:
o Add new contributor;
o Rewording of several sections of the draft;
o Correction of some typos.
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 2]
Internet Draft PCE Communication protocol May 2005
3. 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 paths for establishing
LSPs. This entity can simultaneously act as client and a server.
Several PCEs could be deployed in a given AS.
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 in
order to satisfy 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 management entity is responsible for SLS-
related activities, including pSLS ordering (i.e establishing
contracts between peers) and SLS 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.
4. Introduction
Nowadays, services are deployed on the same infrastructure (best-
effort shared IP network) on which more elaborate functionalities
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.
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 3]
Internet Draft PCE Communication protocol May 2005
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.
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.
5. 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].
6. 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
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 4]
Internet Draft PCE Communication protocol May 2005
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
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 upstream
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 upstream 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.
7. 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 | || |
| || | | | || |
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 5]
Internet Draft PCE Communication protocol May 2005
| +--\/--+ | | | +--\/--+ |
| | PCS | | \---------------|->| PCS | |
| | | | | | | |
| +------+ | | +------+ |
+------------+ +------------+
PCP protocol is used for communication between a PCC and a PCS.
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
PCEs.
o In its first version, PCP does not provide any message level
security for authentication, message replay protection, and
integrity. However, PCP can reuse existing protocols for
security such as IPSEC [RFC2401] or TLS [RFC2246] to
authenticate and secure the channel between two PCEs.
o The current PCP protocol provides the service for supporting
only a basic path computation function. In particular it does
not support additional path computation constraints, or provide
enhanced reporting features in the case of path computation
failure.
8. PCP messages
This section discusses the PCP message formats and objects exchanged
between PCE entities.
8.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 |
+--------------+--------------+--------------+--------------+
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 6]
Internet Draft PCE Communication protocol May 2005
Global note: //// implies field is reserved, set to 0.
The fields in the header are:
Version: 8 bits. PCP version. Current version is 1.
Op Code: 8 bits. The current defined PCP operations are:
1 = OPEN (OPN)
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.
8.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.
8.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
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 7]
Internet Draft PCE Communication protocol May 2005
entities. The range of finite timeouts is 1 to 65535 seconds
represented as an unsigned two-octet integer. The value of zero
implies infinity.
8.4. CLOSE message
The close message contains an error code indicating the reason of the
close of the session.
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
8.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 |
+-------------+-------------+-------//----+-------------+
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 8]
Internet Draft PCE Communication protocol May 2005
| 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 |
+-------------+-------------+-------------+-------------+
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
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 9]
Internet Draft PCE Communication protocol May 2005
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.
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 length in bytes 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
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 10]
Internet Draft PCE Communication protocol May 2005
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
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.
8.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 |
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 11]
Internet Draft PCE Communication protocol May 2005
+-------------+-------------+-------------+-------------+
| QOS-INFO-CODE + QOS-INFO-SUB-CODE |
+-------------+-------------+-------------+-------------+
| QOS-INFO-VALUE |
+-------------+-------------+-------------+-------------+
| QOS-INFO-CODE + QOS-INFO-SUB-CODE |
+-------------+-------------+-------------+-------------+
| QOS-INFO-VALUE |
+-------------+-------------+-------------+-------------+
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 PCE domain and the
tail-end of the path.
8.7. PATH-ERROR message
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 12]
Internet Draft PCE Communication protocol May 2005
This message is sent back when a path could not be computed.
+-------------+-------------+
2 bytes| L1 |
+-------------+-------------+-------//----+-------------+
| PATH-COMPUTATION-ID |
|-----------------------------------//------------------|
2 bytes| REQ-REFERENCE-ID |
|-----------------------------------//------------------|
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
8.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.
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 13]
Internet Draft PCE Communication protocol May 2005
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.
8.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 REQUEST messages 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.
8.10. KEEPALIVE message (KA)
Message exchanged between two PCEs to maintain TCP session when no
other messages are exchanged.
This message has no argument.
9. Exchange of PCP messages
9.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
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 14]
Internet Draft PCE Communication protocol May 2005
boot via the SLS management block. PCE can have crossed
communication; some are acting as a client role, others as a server
role.
9.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
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.
9.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 KA-timer value object
indicating the maximum acceptable intermediate time between the
generation of messages by the PCEs. The KA-timer value is determined
by the PCS and is specified in seconds.
If the PCS refuses the PCC open message, it will instead issue a
CLOSE message.
9.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 cancelled in order to free as much as
possible all pending resources reservations that could have been
established. PATH-ERROR or CANCEL message must be sent depending on
requests' state.
9.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:
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 15]
Internet Draft PCE Communication protocol May 2005
(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.
(1) It checks if the PATH-COMPUTATION-ID of the received REQ is
already associated to a pre-contract or contract for the same
requester. 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 concerning the same requester. 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. If resources are available, the PCS pre-reserves the
corresponding resources near the management plane.
(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
creates a context, 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 REQ-REFERENCE-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
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 16]
Internet Draft PCE Communication protocol May 2005
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.
(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 if 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 REQ-REFERENCE-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
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 17]
Internet Draft PCE Communication protocol May 2005
the next 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.
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.
9.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 be 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 as 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.
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 18]
Internet Draft PCE Communication protocol May 2005
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.
9.7. ACKNOWLEDGE (ACK)
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 and REQ-REFERENCE-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.
9.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 request
identified by the PATH-COMPUTATION-ID and REQ-REFERENCE-ID indicated
in the message. If the PCE has no pending request concerning this
PATH-COMPUTATION-ID and REQ-REFERENCE-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
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 19]
Internet Draft PCE Communication protocol May 2005
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.
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
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 Inter-Area MPLS Traffic Engineering ",
draft-ietf-tewg-interarea-mpls-te-req-03.txt, November 2004
[INTERAS-REQ] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS
Traffic Engineering requirements ", draft-ietf-tewg-interas-mpls-
te-req-09.txt, September 2004
[PCE-ARCH] Ash, J., Farrel, A., Vasseur, JP., "Path Computation
Element (PCE) Architecture", draft-ietf-pce-architecture-00.txt,
March 2005
[PCE-FWK] Farrel, A., Vasseur, JP., Ayyangar, A., "A Framework for
Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter-
domain-framework-01.txt, February 2005
[INTERAS-PCE] Boucadair, M., Morand, P., "A Solution for providing
inter-AS QoS tunnels", draft-boucadair-pce-interas-01.txt, May
2005
[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-boucadair-pce-discovery-01.txt, May 2005
[RFC2401] Atkinson R., "Security Architecture for the Internet
Protocol", RFC 2401, August 1998.
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 20]
Internet Draft PCE Communication protocol May 2005
[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.
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
Boucadair (Ed.) Standards Track - Expires November 2005 [Page 21]
Internet Draft PCE Communication protocol May 2005
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 (2005). 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 November 2005 [Page 22]