RFC 8231
Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
Internet Engineering Task Force (IETF) E. Crabbe Request for Comments: 8231 Oracle Category: Standards Track I. Minei ISSN: 2070-1721 Google, Inc. J. Medved Cisco Systems, Inc. R. Varga Pantheon Technologies SRO September 2017 Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCEAbstract
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 https://www.rfc-editor.org/info/rfc8231.
Copyright Notice 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.
Table of Contents
1. Introduction ....................................................5 1.1. Requirements Language ......................................5 2. Terminology .....................................................5 3. Motivation and Objectives for Stateful PCE ......................6 3.1. Motivation .................................................6 3.1.1. Background ..........................................6 3.1.2. Why a Stateful PCE? .................................7 3.1.3. Protocol vs. Configuration ..........................8 3.2. Objectives .................................................9 4. New Functions to Support Stateful PCEs ..........................9 5. Overview of Protocol Extensions ................................10 5.1. LSP State Ownership .......................................10 5.2. New Messages ..............................................11 5.3. Error Reporting ...........................................11 5.4. Capability Advertisement ..................................11 5.5. IGP Extensions for Stateful PCE Capabilities Advertisement .............................................12 5.6. State Synchronization .....................................13 5.7. LSP Delegation ............................................16 5.7.1. Delegating an LSP ..................................16 5.7.2. Revoking a Delegation ..............................17 5.7.3. Returning a Delegation .............................19 5.7.4. Redundant Stateful PCEs ............................19 5.7.5. Redelegation on PCE Failure ........................20 5.8. LSP Operations ............................................21 5.8.1. Passive Stateful PCE Path Computation Request/Response ...................................21 5.8.2. Switching from Passive Stateful to Active Stateful ...........................................22 5.8.3. Active Stateful PCE LSP Update .....................23 5.9. LSP Protection ............................................24 5.10. PCEP Sessions ............................................24 6. PCEP Messages ..................................................25 6.1. The PCRpt Message .........................................25 6.2. The PCUpd Message .........................................27 6.3. The PCErr Message .........................................30 6.4. The PCReq Message .........................................31 6.5. The PCRep Message .........................................31 7. Object Formats .................................................32 7.1. OPEN Object ...............................................32 7.1.1. STATEFUL-PCE-CAPABILITY TLV ........................32 7.2. SRP Object ................................................33 7.3. LSP Object ................................................34 7.3.1. LSP-IDENTIFIERS TLVs ...............................36 7.3.2. Symbolic Path Name TLV .............................39 7.3.3. LSP Error Code TLV .................................40
7.3.4. RSVP Error Spec TLV ................................41
8. IANA Considerations ............................................42
8.1. PCE Capabilities in IGP Advertisements ....................42
8.2. PCEP Messages .............................................43
8.3. PCEP Objects ..............................................43
8.4. LSP Object ................................................44
8.5. PCEP-Error Object .........................................45
8.6. Notification Object .......................................46
8.7. PCEP TLV Type Indicators ..................................46
8.8. STATEFUL-PCE-CAPABILITY TLV ...............................47
8.9. LSP-ERROR-CODE TLV ........................................47
9. Manageability Considerations ...................................48
9.1. Control Function and Policy ...............................48
9.2. Information and Data Models ...............................49
9.3. Liveness Detection and Monitoring .........................49
9.4. Verifying Correct Operation ...............................49
9.5. Requirements on Other Protocols and Functional
Components ................................................50
9.6. Impact on Network Operation ...............................50
10. Security Considerations .......................................50
10.1. Vulnerability ............................................50
10.2. LSP State Snooping .......................................51
10.3. Malicious PCE ............................................51
10.4. Malicious PCC ............................................52
11. References ....................................................52
11.1. Normative References .....................................52
11.2. Informative References ...................................53
Acknowledgements ..................................................55
Contributors ......................................................56
Authors' Addresses ................................................57
1. Introduction
[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.2. Terminology
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 State Database. 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
policy.
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,
as usual.
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
3.1. Motivation
[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.
3.1.1. Background
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 control-plane overhead o Out-of-band TED synchronization would be complex and prone to race conditions o Path calculations incorporating total network state would be highly complex 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 overhead.
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 classes. 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 capacity. 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.
3.2. Objectives
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 revocation. * 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 PCEs.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.
(page 10 continued on part 2)
