tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5440

 Errata 
Proposed STD
Pages: 87
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PCE

Path Computation Element (PCE) Communication Protocol (PCEP)

Part 1 of 4, p. 1 to 15
None       Next RFC Part

Updated by:    7896


Top       ToC       Page 1 
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.

Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
      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

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
   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

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
               +-+-+                 +-+-+
               |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).

Top      ToC       Page 10 
   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.

Top      ToC       Page 11 
   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

Top      ToC       Page 12 

                 +-+-+                  +-+-+
                 |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,

Top      ToC       Page 13 
   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.

Top      ToC       Page 14 
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.

Top      ToC       Page 15 
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)

Next RFC Part