RFC 5440
Path Computation Element (PCE) Communication Protocol (PCEP)
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.
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.
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
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
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.
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
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.
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.
+-+-+ +-+-+ |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).
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.
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
+-+-+ +-+-+ |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,
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.
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.
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).
(page 15 continued on part 2)
