Path Computation Element (PCE) Communication Protocol (PCEP) :: RFC5440
Network Working Group JP. Vasseur, Ed.
Request for Comments: 5440 Cisco Systems
Category: Standards Track JL. Le Roux, Ed.
France Telecom
March 2009
Path Computation Element (PCE) Communication Protocol (PCEP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Vasseur & Le Roux Standards Track [Page 1]
RFC 5440 PCEP March 2009
Abstract
This document specifies the Path Computation Element (PCE)
Communication Protocol (PCEP) for communications between a Path
Computation Client (PCC) and a PCE, or between two PCEs. Such
interactions include path computation requests and path computation
replies as well as notifications of specific states related to the
use of a PCE in the context of Multiprotocol Label Switching (MPLS)
and Generalized MPLS (GMPLS) Traffic Engineering. PCEP 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.
Vasseur & Le Roux Standards Track [Page 2]
RFC 5440 PCEP March 2009
Table of Contents
1. Introduction ....................................................5
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Assumptions .....................................................6
4. Architectural Protocol Overview (Model) .........................7
4.1. Problem ....................................................7
4.2. Architectural Protocol Overview ............................7
4.2.1. Initialization Phase ................................8
4.2.2. Session Keepalive ...................................9
4.2.3. Path Computation Request Sent by a PCC to a PCE ....10
4.2.4. Path Computation Reply Sent by The PCE to a PCC ....11
4.2.5. Notification .......................................12
4.2.6. Error ..............................................14
4.2.7. Termination of the PCEP Session ....................14
4.2.8. Intermittent versus Permanent PCEP Session .........15
5. Transport Protocol .............................................15
6. PCEP Messages ..................................................15
6.1. Common Header .............................................16
6.2. Open Message ..............................................16
6.3. Keepalive Message .........................................18
6.4. Path Computation Request (PCReq) Message ..................19
6.5. Path Computation Reply (PCRep) Message ....................20
6.6. Notification (PCNtf) Message ..............................21
6.7. Error (PCErr) Message .....................................22
6.8. Close Message .............................................23
6.9. Reception of Unknown Messages .............................23
7. Object Formats .................................................23
7.1. PCEP TLV Format ...........................................24
7.2. Common Object Header ......................................24
7.3. OPEN Object ...............................................25
7.4. RP Object .................................................27
7.4.1. Object Definition ..................................27
7.4.2. Handling of the RP Object ..........................30
7.5. NO-PATH Object ............................................31
7.6. END-POINTS Object .........................................34
7.7. BANDWIDTH Object ..........................................35
7.8. METRIC Object .............................................36
7.9. Explicit Route Object .....................................39
7.10. Reported Route Object ....................................39
7.11. LSPA Object ..............................................40
7.12. Include Route Object .....................................42
7.13. SVEC Object ..............................................42
7.13.1. Notion of Dependent and Synchronized Path
Computation Requests ..............................42
7.13.2. SVEC Object .......................................44
7.13.3. Handling of the SVEC Object .......................45
Vasseur & Le Roux Standards Track [Page 3]
RFC 5440 PCEP March 2009
7.14. NOTIFICATION Object ......................................46
7.15. PCEP-ERROR Object ........................................49
7.16. LOAD-BALANCING Object ....................................54
7.17. CLOSE Object .............................................55
8. Manageability Considerations ...................................56
8.1. Control of Function and Policy ............................56
8.2. Information and Data Models ...............................57
8.3. Liveness Detection and Monitoring .........................57
8.4. Verifying Correct Operation ...............................58
8.5. Requirements on Other Protocols and Functional
Components ................................................58
8.6. Impact on Network Operation ...............................58
9. IANA Considerations ............................................59
9.1. TCP Port ..................................................59
9.2. PCEP Messages .............................................59
9.3. PCEP Object ...............................................59
9.4. PCEP Message Common Header ................................61
9.5. Open Object Flag Field ....................................61
9.6. RP Object .................................................61
9.7. NO-PATH Object Flag Field .................................62
9.8. METRIC Object .............................................63
9.9. LSPA Object Flag Field ....................................63
9.10. SVEC Object Flag Field ...................................64
9.11. NOTIFICATION Object ......................................64
9.12. PCEP-ERROR Object ........................................65
9.13. LOAD-BALANCING Object Flag Field .........................67
9.14. CLOSE Object .............................................67
9.15. PCEP TLV Type Indicators .................................68
9.16. NO-PATH-VECTOR TLV .......................................68
10. Security Considerations .......................................69
10.1. Vulnerability ............................................69
10.2. TCP Security Techniques ..................................70
10.3. PCEP Authentication and Integrity ........................70
10.4. PCEP Privacy .............................................71
10.5. Key Configuration and Exchange ...........................71
10.6. Access Policy ............................................73
10.7. Protection against Denial-of-Service Attacks .............73
10.7.1. Protection against TCP DoS Attacks ................73
10.7.2. Request Input Shaping/Policing ....................74
11. Acknowledgments ...............................................75
12. References ....................................................75
12.1. Normative References .....................................75
12.2. Informative References ...................................76
Appendix A. PCEP Finite State Machine (FSM) ......................79
Appendix B. PCEP Variables .......................................85
Appendix C. Contributors .........................................86
Vasseur & Le Roux Standards Track [Page 4]
RFC 5440 PCEP March 2009
1. Introduction
[RFC4655] describes the motivations and architecture for a Path
Computation Element (PCE) based model for the computation of
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering Label Switched Paths (TE LSPs). The model allows
for the separation of PCE from Path Computation Client (PCC), and
allows for the cooperation between PCEs. This necessitates a
communication protocol between PCC and PCE, and between PCEs.
[RFC4657] states the generic requirements for such a protocol
including that the same protocol be used between PCC and PCE, and
between PCEs. Additional application-specific requirements (for
scenarios such as inter-area, inter-AS, etc.) are not included in
[RFC4657], 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 [RFC4927], [RFC5376],
and [INTER-LAYER].
This document specifies the Path Computation Element Protocol (PCEP)
for communications between a PCC and a PCE, or between two PCEs, in
compliance with [RFC4657]. 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.
PCEP 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.
1.1. 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].
2. Terminology
The following terminology is used in this document.
AS: Autonomous System.
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.
Vasseur & Le Roux Standards Track [Page 5]
RFC 5440 PCEP March 2009
Inter-domain TE LSP: A TE LSP whose path transits at least two
different domains where a domain can be an IGP area, an Autonomous
System, or a sub-AS (BGP confederation).
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 a
PCE).
TED: Traffic Engineering Database that 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: A mix of strict and loose hops comprising at
least one loose hop representing the destination where a hop may
be an abstract node such as an AS.
Within this document, when describing PCE-PCE communications, the
requesting PCE fills the role of a PCC. This provides a saving in
documentation without loss of function.
The message formats in this document are specified using Backus-Naur
Format (BNF) encoding as specified in [RBNF].
3. Assumptions
[RFC4655] describes various types of PCE. PCEP does not make any
assumption about, and thus does not impose any constraint on, the
nature of the PCE.
Moreover, it is assumed that the PCE has the required information
(usually including network topology and resource information) so as
to perform the computation of a path for a TE LSP. Such information
can be gathered by routing protocols or by some other means. The way
in which the information is gathered is out of the scope of this
document.
Similarly, no assumption is made about the discovery method used by a
PCC to discover a set of PCEs (e.g., via static configuration or
dynamic discovery) and on the algorithm used to select a PCE. For
Vasseur & Le Roux Standards Track [Page 6]
RFC 5440 PCEP March 2009
reference, [RFC4674] defines a list of requirements for dynamic PCE
discovery and IGP-based solutions for such PCE discovery are
specified in [RFC5088] and [RFC5089].
4. Architectural Protocol Overview (Model)
The aim of this section is to describe the PCEP model in the spirit
of [RFC4101]. An architectural protocol overview (the big picture of
the protocol) is provided in this section. Protocol details can be
found in further sections.
4.1. Problem
The PCE-based architecture used for the computation of paths for MPLS
and GMPLS TE LSPs is described in [RFC4655]. When the PCC and the
PCE are not collocated, a communication protocol between the PCC and
the PCE is needed. PCEP is such a protocol designed specifically for
communications between a PCC and a PCE or between two PCEs in
compliance with [RFC4657]: a PCC may use PCEP to send a path
computation request for one or more TE LSPs to a PCE, and the PCE may
reply with a set of computed paths if one or more paths can be found
that satisfies the set of constraints.
4.2. Architectural Protocol Overview
PCEP operates over TCP, which fulfills the requirements for reliable
messaging and flow control without further protocol work.
Several PCEP messages are defined:
o Open and Keepalive messages are used to initiate and maintain a
PCEP session, respectively.
o PCReq: a PCEP message sent by a PCC to a PCE to request a path
computation.
o PCRep: a PCEP message sent by a PCE to a PCC in reply to a path
computation request. A PCRep message can contain either a set of
computed paths if the request can be satisfied, or a negative
reply if not. The negative reply may indicate the reason why no
path could be found.
o PCNtf: a PCEP notification message either sent by a PCC to a PCE
or sent by a PCE to a PCC to notify of a specific event.
o PCErr: a PCEP message sent upon the occurrence of a protocol error
condition.
Vasseur & Le Roux Standards Track [Page 7]
RFC 5440 PCEP March 2009
o Close message: a message used to close a PCEP session.
The set of available PCEs may be either statically configured on a
PCC or dynamically discovered. The mechanisms used to discover one
or more PCEs and to select a PCE are 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.
Each PCEP message is regarded as a single transmission unit and parts
of messages MUST NOT be interleaved. So, for example, a PCC sending
a PCReq and wishing to close the session, must complete sending the
request message before starting to send a Close message.
4.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 PCEP session establishment
during which various session parameters are negotiated. These
parameters are carried within Open messages and include the Keepalive
timer, the DeadTimer, 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 session 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 an exponential back-off session establishment retry procedure.
Keepalive messages are used to acknowledge Open messages, and are
used once the PCEP session has been successfully established.
Only one PCEP session can exist between a pair of PCEP peers at any
one time. Only one TCP connection on the PCEP port can exist between
a pair of PCEP peers at any one time.
Details about the Open message and the Keepalive message can be found
in Sections 6.2 and 6.3, respectively.
Vasseur & Le Roux Standards Track [Page 8]
RFC 5440 PCEP March 2009
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| Open msg |
|-------- |
| \ Open msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ Keepalive|
| --------|
|Keepalive / |
|-------- / |
| \/ |
| /\ |
|<------ ---------->|
| |
Figure 1: PCEP Initialization Phase (Initiated by a PCC)
(Note that once the PCEP session is established, the exchange of
Keepalive messages is optional.)
4.2.2. Session Keepalive
Once a session has been established, a PCE or PCC may want to know
that its PCEP peer is still available for use.
It can rely on TCP for this information, but it is possible that the
remote PCEP function has failed without disturbing the TCP
connection. It is also possible to rely on the mechanisms built into
the TCP implementations, but these might not provide failure
notifications that are sufficiently timely. Lastly, a PCC could wait
until it has a path computation request to send and could use its
failed transmission or the failure to receive a response as evidence
that the session has failed, but this is clearly inefficient.
In order to handle this situation, PCEP includes a keepalive
mechanism based on a Keepalive timer, a DeadTimer, and a Keepalive
message.
Each end of a PCEP session runs a Keepalive timer. It restarts the
timer every time it sends a message on the session. When the timer
expires, it sends a Keepalive message. Other traffic may serve as
Keepalive (see Section 6.3).
Vasseur & Le Roux Standards Track [Page 9]
RFC 5440 PCEP March 2009
The ends of the PCEP session also run DeadTimers, and they restart
the timers whenever a message is received on the session. If one end
of the session receives no message before the DeadTimer expires, it
declares the session dead.
Note that this means that the Keepalive message is unresponded and
does not form part of a two-way keepalive handshake as used in some
protocols. Also note that the mechanism is designed to reduce to a
minimum the amount of keepalive traffic on the session.
The keepalive traffic on the session may be unbalanced according to
the requirements of the session ends. Each end of the session can
specify (on an Open message) the Keepalive timer that it will use
(i.e., how often it will transmit a Keepalive message if there is no
other traffic) and a DeadTimer that it recommends its peer to use
(i.e., how long the peer should wait before declaring the session
dead if it receives no traffic). The session ends may use different
Keepalive timer values.
The minimum value of the Keepalive timer is 1 second, and it is
specified in units of 1 second. The recommended default value is 30
seconds. The timer may be disabled by setting it to zero.
The recommended default for the DeadTimer is 4 times the value of the
Keepalive timer used by the remote peer. This means that there is
never any risk of congesting TCP with excessive Keepalive messages.
4.2.3. 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 has successfully established a PCEP session with one or
more PCEs, if an event is triggered that requires the computation of
a set of paths, the PCC first selects one or more PCEs. Note that
the PCE selection decision process may have taken place prior to the
PCEP session establishment.
Vasseur & Le Roux Standards Track [Page 10]
RFC 5440 PCEP March 2009
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=B
Mbit/s, Setup/Holding priority=P, ...". 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 address pair. The process is shown in a schematic
form in Figure 2.
Note that multiple path computation requests may be outstanding from
a PCC to a PCE at any time.
Details about the PCReq message can be found in Section 6.4.
4.2.4. Path Computation Reply Sent by The PCE to a PCC
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---- PCReq message--->|
| |1) Path computation
| | request received
| |
| |2) Path successfully
| | computed
| |
| |3) Computed paths
| | sent to the PCC
| |
|<--- PCRep message ---|
| (Positive reply) |
Figure 3a: Path Computation Request With Successful
Path Computation
Vasseur & Le Roux Standards Track [Page 11]
RFC 5440 PCEP March 2009
+-+-+ +-+-+
|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 be either:
o Positive (Figure 3a): the PCE manages to compute a path that
satisfies the set of required constraints. In this case, the PCE
returns the set of computed paths to the requesting PCC. Note
that PCEP supports the capability to send a single request that
requires the computation of more than one path (e.g., computation
of a set of link-diverse paths).
o Negative (Figure 3b): no path could be found that satisfies the
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.
4.2.5. Notification
There are several circumstances in which a PCE may want to notify a
PCC of a specific event. For example, suppose that the PCE suddenly
gets overloaded, potentially leading 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. Upon receiving such notification,
Vasseur & Le Roux Standards Track [Page 12]
RFC 5440 PCEP March 2009
the PCC may decide to redirect its path computation requests to
another PCE should an alternate PCE be available. Similarly, a PCC
may desire to notify a PCE of a particular event such as the
cancellation of pending requests.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |
5) Path computation | |
request X cancelled| |
|---- PCNtf message -->|
| |6) Path computation
| | request X cancelled
Figure 4: Example of PCC Notification (Cancellation Notification)
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 | | request queued
| |
| |
| |5) PCE gets overloaded
| |
| |
| |6) Path computation
| | request X cancelled
| |
|<--- PCNtf message----|
Figure 5: Example of PCE Notification (Cancellation Notification)
Sent to a PCC
Details about the PCNtf message can be found in Section 6.6.
Vasseur & Le Roux Standards Track [Page 13]
RFC 5440 PCEP March 2009
4.2.6. Error
The PCEP Error message (also referred to as a PCErr message) is sent
in several situations: when a protocol error condition is met or when
the request is not compliant with the PCEP specification (e.g.,
capability not supported, reception of a message with a mandatory
missing object, policy violation, unexpected message, unknown request
reference).
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Reception of a
the selected PCE | | malformed object
| |
| |5) Request discarded
| |
|<-- PCErr message ---|
| |
Figure 6: Example of Error Message Sent by a PCE to a PCC
in Reply to the Reception of a Malformed Object
Details about the PCErr message can be found in Section 6.7.
4.2.7. 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 closes the TCP connection.
If the PCEP session is terminated by the PCE, the PCC clears all the
states related to pending requests previously 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 is immediately
terminated.
Details about the Close message can be found in Section 6.8.
Vasseur & Le Roux Standards Track [Page 14]
RFC 5440 PCEP March 2009
4.2.8. Intermittent versus Permanent PCEP Session
An implementation may decide to keep the PCEP session alive (and thus
the corresponding TCP connection) for an unlimited time. (For
instance, this may be appropriate when path computation requests are
sent on a frequent basis so as to avoid opening a TCP connection each
time a path computation request is needed, which would incur
additional processing delays.) Conversely, in some other
circumstances, it may be desirable to systematically open and close a
PCEP session for each PCEP request (for instance, when sending a path
computation request is a rare event).
5. Transport Protocol
PCEP operates over TCP using a registered TCP port (4189). This
allows the requirements of reliable messaging and flow control to be
met without further protocol work. All PCEP messages MUST be sent
using the registered TCP port for the source and destination TCP
port.
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 for the
message to be considered valid. A PCEP message with a missing
mandatory object MUST trigger an Error message (see Section 7.15).
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.2). When this flag is set in an
object in a PCReq, the PCE MUST take the information carried in the
object into account during the path computation. For example, the
METRIC object defined in Section 7.8 allows a PCC to specify a
bounded acceptable path cost. The METRIC object is optional, but a
PCC may set a flag to ensure that the constraint is taken into
account. In this case, if the constraint cannot be taken into
account by the PCE, the PCE MUST trigger an Error message.
For each PCEP message type, rules are defined that specify the set of
objects that the message can carry. We use the Backus-Naur Form
(BNF) (see [RBNF]) to specify such rules. Square brackets refer to
optional sub-sequences. An implementation MUST form the PCEP
messages using the object ordering specified in this document.
Vasseur & Le Roux Standards Track [Page 15]
RFC 5440 PCEP March 2009
6.1. Common Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: PCEP Message Common Header
Ver (Version - 3 bits): PCEP version number. Current version is
version 1.
Flags (5 bits): No flags are currently defined. Unassigned bits are
considered as reserved. They MUST be set to zero on transmission
and MUST be ignored on receipt.
Message-Type (8 bits): The following message types are currently
defined:
Value Meaning
1 Open
2 Keepalive
3 Path Computation Request
4 Path Computation Reply
5 Notification
6 Error
7 Close
Message-Length (16 bits): total length of the PCEP message including
the common header, expressed in bytes.
6.2. Open Message
The Open message is a PCEP message sent by a PCC to a PCE and by a
PCE to a PCC in order to establish a PCEP session. The Message-Type
field of the PCEP common header for the Open message is set to 1.
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 as specified in Appendix A.
Any message received prior to an Open message MUST trigger a protocol
error condition causing a PCErr message to be sent with Error-Type
"PCEP session establishment failure" and Error-value "reception of an
invalid Open message or a non Open message" and the PCEP session
establishment attempt MUST be terminated by closing the TCP
connection.
Vasseur & Le Roux Standards Track [Page 16]
RFC 5440 PCEP March 2009
The Open message is used to establish a PCEP session between the PCEP
peers. During the establishment phase, the PCEP peers exchange
several session characteristics. If both parties agree on such
characteristics, the PCEP session is successfully established.
The format of an Open message is as follows:
::=
The Open message MUST contain exactly one OPEN object (see
Section 7.3).
Various session characteristics are specified within the OPEN object.
Once the TCP connection has been successfully established, the sender
MUST start an initialization timer called OpenWait after the
expiration of which, if no Open message has been received, it sends a
PCErr message and releases the TCP connection (see Appendix A for
details).
Once an Open message has been sent to a PCEP peer, the sender MUST
start an initialization timer called KeepWait after the expiration of
which, if neither a Keepalive message has been received nor a PCErr
message in case of disagreement of the session characteristics, a
PCErr message MUST be sent and the TCP connection MUST be released
(see Appendix A for details).
The OpenWait and KeepWait timers have a fixed value of 1 minute.
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 characteristics is not acceptable
to the receiving peer, it MUST send an Error message. The Error
message SHOULD also contain the related OPEN object and, 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 messages can be found in Section 7.15.
Successive retries are permitted, but an implementation SHOULD make
use of an exponential back-off session establishment retry procedure.
If the PCEP session characteristics are acceptable, the receiving
PCEP peer MUST send a Keepalive message (defined in Section 6.3) that
serves as an acknowledgment.
Vasseur & Le Roux Standards Track [Page 17]
RFC 5440 PCEP March 2009
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 Keepalive message is also
used in response to an Open message to acknowledge that an Open
message has been received and that the PCEP session characteristics
are acceptable. The Message-Type field of the PCEP common header for
the Keepalive message is set to 2. The Keepalive message does not
contain any object.
PCEP has its own keepalive mechanism used to ensure 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 constraint 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 are no constraints mandating
the use of identical DeadTimers by both PCEP peers. The minimum
Keepalive timer value is 1 second. Deployments SHOULD consider
carefully the impact of using low values for the Keepalive timer as
these might not give rise to the expected results in periods of
temporary network instability.
Keepalive messages are sent at the frequency specified in the OPEN
object carried within an Open message according to the rules
specified in Section 7.3. Because any PCEP message may serve as
Keepalive, an implementation may either decide to send Keepalive
messages at fixed intervals regardless of 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.
Note that sending Keepalive messages to keep the session alive is
optional, and PCEP peers may decide not to send Keepalive messages
once the PCEP session is established; in which case, the peer that
does not receive Keepalive messages does not expect to receive them
and MUST NOT declare the session as inactive.
The format of a Keepalive message is as follows:
::=
Vasseur & Le Roux Standards Track [Page 18]
RFC 5440 PCEP March 2009
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 to request a path
computation. A PCReq message may carry more than one path
computation request. The Message-Type field of the PCEP common
header for the PCReq message is set to 3.
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
or both of these objects is missing, the receiving PCE MUST send an
error message to the requesting PCC. Other objects are optional.
The format of a PCReq message is as follows:
::=
[]
where:
::=[]
::=[]
::=
RFC, FYI, BCP
