Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8231

Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE

Pages: 57
Proposed Standard
Errata
Updated by:  8786
Part 1 of 4 – Pages 1 to 10
None   None   Next

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

Abstract

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

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

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.
Top   ToC   RFC8231 - Page 6
   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],
Top   ToC   RFC8231 - Page 7
   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.
Top   ToC   RFC8231 - Page 8
   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.
Top   ToC   RFC8231 - Page 9

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

Next Section