tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 8231

Proposed STD
Pages: 57
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PCE

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

Part 1 of 4, p. 1 to 10
None       Next Section

 


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