Internet Engineering Task Force (IETF) E. Crabbe
Request for Comments: 8231 Oracle
Category: Standards Track I. Minei
ISSN: 2070-1721 Google, Inc.
Cisco Systems, Inc.
Pantheon Technologies SRO
September 2017 Path Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Client (PCC) requests.
Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for PCE
control of timing and sequence of path computations within and across
PCEP sessions. This document describes a set of extensions to PCEP
to enable stateful control of MPLS-TE and GMPLS Label Switched Paths
(LSPs) via PCEP.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2017 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
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
[RFC5440] describes the Path Computation Element Communication
Protocol (PCEP). PCEP defines the communication between a Path
Computation Client (PCC) and a Path Computation Element (PCE), or
between PCEs, enabling computation of Multiprotocol Label Switching
(MPLS) for Traffic Engineering Label Switched Path (TE LSP)
characteristics. Extensions for support of Generalized MPLS (GMPLS)
in PCEP are defined in [PCEP-GMPLS].
This document specifies a set of extensions to PCEP to enable
stateful control of LSPs within and across PCEP sessions in
compliance with [RFC4657]. It includes mechanisms to effect Label
Switched Path (LSP) State Synchronization between PCCs and PCEs,
delegation of control over LSPs to PCEs, and PCE control of timing
and sequence of path computations within and across PCEP sessions.
Extensions to permit the PCE to drive creation of an LSP are defined
in [PCE-Init-LSP], which specifies PCE-initiated LSP creation.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer, and PCEP speaker.
This document uses the following terms defined in [RFC4655]: Traffic
Engineering Database (TED).
This document uses the following terms defined in [RFC3031]: LSP.
This document uses the following terms defined in [RFC8051]: Stateful
PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, and LSP
The following terms are defined in this document:
Revocation: an operation performed by a PCC on a previously
delegated LSP. Revocation revokes the rights granted to the PCE
in the delegation operation.
Redelegation Timeout Interval: the period of time a PCC waits for,
when a PCEP session is terminated, before revoking LSP delegation
to a PCE and attempting to redelegate LSPs associated with the
terminated PCEP session to an alternate PCE. The Redelegation
Timeout Interval is a PCC-local value that can be either operator
configured or dynamically computed by the PCC based on local
State Timeout Interval: the period of time a PCC waits for, when a
PCEP session is terminated, before flushing LSP state associated
with that PCEP session and reverting to operator-defined default
parameters or behaviors. The State Timeout Interval is a PCC-
local value that can be either operator configured or dynamically
computed by the PCC based on local policy.
LSP State Report: an operation to send LSP state (operational/
administrative status, LSP attributes configured at the PCC and
set by a PCE, etc.) from a PCC to a PCE.
LSP Update Request: an operation where an Active Stateful PCE
requests a PCC to update one or more attributes of an LSP and to
re-signal the LSP with updated attributes.
SRP-ID-number: a number used to correlate errors and LSP State
Reports to LSP Update Requests. It is carried in the Stateful PCE
Request Parameter (SRP) object described in Section 7.2.
Within this document, PCEP communications are described through PCC-
PCE relationships. The PCE architecture also supports PCE-PCE
communication, by having the requesting PCE fill the role of a PCC,
The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
3. Motivation and Objectives for Stateful PCE
[RFC8051] presents several use cases, demonstrating scenarios that
benefit from the deployment of a stateful PCE. The scenarios apply
equally to MPLS-TE and GMPLS deployments.
Traffic engineering has been a goal of the MPLS architecture since
its inception [RFC2702] [RFC3031] [RFC3346]. In the traffic
engineering system provided by [RFC3209], [RFC3630], and [RFC5305],
information about network resources utilization is only available as
total reserved capacity by the traffic class on a per-interface
basis; individual LSP state is available only locally on each Label
Edge Router (LER) for its own LSPs. In most cases, this makes good
sense, as distribution and retention of total LSP state for all LERs
within in the network would be prohibitively costly.
Unfortunately, this visibility in terms of global LSP state may
result in a number of issues for some demand patterns, particularly
within a common setup and hold priority. This issue affects online
traffic engineering systems.
A sufficiently over-provisioned system will by definition have no
issues routing its demand on the shortest path. However, lowering
the degree to which network over-provisioning is required in order to
run a healthy, functioning network is a clear and explicit promise of
MPLS architecture. In particular, it has been a goal of MPLS to
provide mechanisms to alleviate congestion scenarios in which
"traffic streams are inefficiently mapped onto available resources;
causing subsets of network resources to become over-utilized while
others remain underutilized" [RFC2702].
3.1.2. Why a Stateful PCE?
[RFC4655] defines a stateful PCE to be one in which the PCE maintains
"strict synchronization between the PCE and not only the network
states (in term of topology and resource information), but also the
set of computed paths and reserved resources in use in the network."
[RFC4655] also expressed a number of concerns with regard to a
stateful PCE, specifically:
o Any reliable synchronization mechanism would result in significant
o Out-of-band TED synchronization would be complex and prone to race
o Path calculations incorporating total network state would be
In general, stress on the control plane will be directly proportional
to the size of the system being controlled and the tightness of the
control loop and indirectly proportional to the amount of over-
provisioning in terms of both network capacity and reservation
Despite these concerns in terms of implementation complexity and
scalability, several TE algorithms exist today that have been
demonstrated to be extremely effective in large TE systems, providing
both rapid convergence and significant benefits in terms of
optimality of resource usage [MXMN-TE]. All of these systems share
at least two common characteristics: the requirement for both global
visibility of a flow (or in this case, a TE LSP) state and for
ordered control of path reservations across devices within the system
being controlled. While some approaches have been suggested in order
to remove the requirements for ordered control (see [MPLS-PC]), these
approaches are highly dependent on traffic distribution and do not
allow for multiple simultaneous LSP priorities representing Diffserv
The use cases described in [RFC8051] demonstrate a need for
visibility into global inter-PCC LSP state in PCE path computations
and for PCE control of sequence and timing in altering LSP path
characteristics within and across PCEP sessions.
3.1.3. Protocol vs. Configuration
Note that existing configuration tools and protocols can be used to
set LSP state, such as a Command Line Interface (CLI) tool. However,
this solution has several shortcomings:
o Scale & Performance: configuration operations often have
transactional semantics that are typically heavyweight and often
require processing of additional configuration portions beyond the
state being directly acted upon, with corresponding cost in CPU
cycles, negatively impacting both PCC stability LSP Update rate
o Security: when a PCC opens a configuration channel allowing a PCE
to send configuration, a malicious PCE may take advantage of this
ability to take over the PCC. In contrast, the PCEP extensions
described in this document only allow a PCE control over a very
limited set of LSP attributes.
o Interoperability: each vendor has a proprietary information model
for configuring LSP state, which limits interoperability of a
stateful PCE with PCCs from different vendors. The PCEP
extensions described in this document allow for a common
information model for LSP state for all vendors.
o Efficient State Synchronization: configuration channels may be
heavyweight and unidirectional; therefore, efficient State
Synchronization between a PCC and a PCE may be a problem.
The objectives for the protocol extensions to support stateful PCE
described in this document are as follows:
o Allow a single PCC to interact with a mix of stateless and
stateful PCEs simultaneously using the same protocol, i.e., PCEP.
o Support efficient LSP State Synchronization between the PCC and
one or more active or passive stateful PCEs.
o Allow a PCC to delegate control of its LSPs to an active stateful
PCE such that a given LSP is under the control of a single PCE at
any given time.
* A PCC may revoke this delegation at any time during the
lifetime of the LSP. If LSP delegation is revoked while the
PCEP session is up, the PCC MUST notify the PCE about the
* A PCE may return an LSP delegation at any point during the
lifetime of the PCEP session. If LSP delegation is returned by
the PCE while the PCEP session is up, the PCE MUST notify the
PCC about the returned delegation.
o Allow a PCE to control computation timing and update timing across
all LSPs that have been delegated to it.
o Enable uninterrupted operation of a PCC's LSPs in the event of a
PCE failure or while control of LSPs is being transferred between
4. New Functions to Support Stateful PCEs
Several new functions are required in PCEP to support stateful PCEs.
A function can be initiated either from a PCC towards a PCE (C-E) or
from a PCE towards a PCC (E-C). The new functions are:
Capability advertisement (E-C,C-E): both the PCC and the PCE must
announce during PCEP session establishment that they support PCEP
Stateful PCE extensions defined in this document.
LSP State Synchronization (C-E): after the session between the PCC
and a stateful PCE is initialized, the PCE must learn the state of
a PCC's LSPs before it can perform path computations or update LSP
attributes in a PCC.
LSP Update Request (E-C): a PCE requests modification of attributes
on a PCC's LSP.
LSP State Report (C-E): a PCC sends an LSP State Report to a PCE
whenever the state of an LSP changes.
LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to
update LSP attributes on one or more LSPs; the PCE becomes the
authoritative source of the LSP's attributes as long as the
delegation is in effect (see Section 5.7); the PCC may withdraw
the delegation or the PCE may give up the delegation at any time.
Similarly to [RFC5440], 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.