Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5440

Path Computation Element (PCE) Communication Protocol (PCEP)

Pages: 87
Proposed Standard
Errata
Updated by:  7896825383569488
Part 1 of 4 – Pages 1 to 15
None   None   Next

Top   ToC   RFC5440 - 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.
Top   ToC   RFC5440 - 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   ToC   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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   RFC5440 - 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 Section