    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.

    Crabbe, et al.               Standards Track                    [Page 1]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    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.

    Crabbe, et al.               Standards Track                    [Page 2]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    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

    Crabbe, et al.               Standards Track                    [Page 3]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

               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

    Crabbe, et al.               Standards Track                    [Page 4]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    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.

    Crabbe, et al.               Standards Track                    [Page 5]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       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],

    Crabbe, et al.               Standards Track                    [Page 6]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       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.

    Crabbe, et al.               Standards Track                    [Page 7]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       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.

    Crabbe, et al.               Standards Track                    [Page 8]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    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.

    Crabbe, et al.               Standards Track                    [Page 9]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       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.

    5.  Overview of Protocol Extensions

    5.1.  LSP State Ownership

       In PCEP (defined in [RFC5440]), LSP state and operation are under the
       control of a PCC (a PCC may be a Label Switching Router (LSR) or a
       management station).  Attributes received from a PCE are subject to
       PCC's local policy.  The PCEP extensions described in this document
       do not change this behavior.

       An active stateful PCE may have control of a PCC's LSPs that were
       delegated to it, but the LSP state ownership is retained by the PCC.
       In particular, in addition to specifying values for LSP's attributes,
       an active stateful PCE also decides when to make LSP modifications.

       Retaining LSP state ownership on the PCC allows for:

       o  a PCC to interact with both stateless and stateful PCEs at the
          same time

       o  a stateful PCE to only modify a small subset of LSP parameters,
          i.e., to set only a small subset of the overall LSP state; other
          parameters may be set by the operator, for example, through CLI
          commands

       o  a PCC to revert delegated LSP to an operator-defined default or to
          delegate the LSPs to a different PCE, if the PCC gets disconnected
          from a PCE with currently delegated LSPs

    Crabbe, et al.               Standards Track                   [Page 10]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    5.2.  New Messages

       In this document, we define the following new PCEP messages:

       Path Computation State Report (PCRpt):  a PCEP message sent by a PCC
          to a PCE to report the status of one or more LSPs.  Each LSP State
          Report in a PCRpt message MAY contain the actual LSP's path,
          bandwidth, operational and administrative status, etc.  An LSP
          Status Report carried on a PCRpt message is also used in
          delegation or revocation of control of an LSP to/from a PCE.  The
          PCRpt message is described in Section 6.1.

       Path Computation Update Request (PCUpd):  a PCEP message sent by a
          PCE to a PCC to update LSP parameters, on one or more LSPs.  Each
          LSP Update Request on a PCUpd message MUST contain all LSP
          parameters that a PCE wishes to be set for a given LSP.  An LSP
          Update Request carried on a PCUpd message is also used to return
          LSP delegations if at any point PCE no longer desires control of
          an LSP.  The PCUpd message is described in Section 6.2.

       The new functions defined in Section 4 are mapped onto the new
       messages as shown in the following table.

             +----------------------------------------+--------------+
             | Function                               | Message      |
             +----------------------------------------+--------------+
             | Capability Advertisement (E-C,C-E)     | Open         |
             | State Synchronization (C-E)            | PCRpt        |
             | LSP State Report (C-E)                 | PCRpt        |
             | LSP Control Delegation (C-E,E-C)       | PCRpt, PCUpd |
             | LSP Update Request (E-C)               | PCUpd        |
             +----------------------------------------+--------------+

                     Table 1: New Function to Message Mapping

    5.3.  Error Reporting

       Error reporting is done using the procedures defined in [RFC5440] and
       reusing the applicable error types and error values of [RFC5440]
       wherever appropriate.  The current document defines new error values
       for several error types to cover failures specific to stateful PCE.

    5.4.  Capability Advertisement

       During the PCEP initialization phase, PCEP speakers (PCE or PCC)
       advertise their support of PCEP Stateful PCE extensions.  A PCEP
       speaker includes the "STATEFUL-PCE-CAPABILITY TLV", described in
       Section 7.1.1, in the OPEN object to advertise its support for PCEP

    Crabbe, et al.               Standards Track                   [Page 11]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       Stateful PCE extensions.  The STATEFUL-PCE-CAPABILITY TLV includes
       the 'LSP Update' flag that indicates whether the PCEP speaker
       supports LSP parameter updates.

       The presence of the STATEFUL-PCE-CAPABILITY TLV in PCC's OPEN object
       indicates that the PCC is willing to send LSP State Reports whenever
       LSP parameters or operational status changes.

       The presence of the STATEFUL-PCE-CAPABILITY TLV in PCE's OPEN message
       indicates that the PCE is interested in receiving LSP State Reports
       whenever LSP parameters or operational status changes.

       The PCEP extensions for stateful PCEs MUST NOT be used if one or both
       PCEP speakers have not included the STATEFUL-PCE-CAPABILITY TLV in
       their respective OPEN message.  If the PCEP speaker on the PCC
       supports the extensions of this specification but did not advertise
       this capability, then upon receipt of a PCUpd message from the PCE,
       it MUST generate a PCEP Error (PCErr) with Error-type=19 (Invalid
       Operation) and error-value 2 (Attempted LSP Update Request if the
       stateful PCE capability was not advertised)(see Section 8.5), and it
       SHOULD terminate the PCEP session.  If the PCEP Speaker on the PCE
       supports the extensions of this specification but did not advertise
       this capability, then upon receipt of a PCRpt message from the PCC,
       it MUST generate a PCErr with Error-type=19 (Invalid Operation) and
       error-value 5 (Attempted LSP State Report if stateful PCE capability
       was not advertised) (see Section 8.5), and it SHOULD terminate the
       PCEP session.

       LSP delegation and LSP Update operations defined in this document may
       only be used if both PCEP speakers set the LSP-UPDATE-CAPABILITY flag
       in the STATEFUL-PCE-CAPABILITY TLV to 'Updates Allowed (U flag = 1)'.
       If this is not the case and LSP delegation or LSP Update operations
       are attempted, then a PCErr with Error-type=19 (Invalid Operation)
       and error-value 1 (Attempted LSP Update Request for a non-delegated
       LSP) (see Section 8.5) MUST be generated.  Note that, even if one of
       the PCEP speakers does not set the LSP-UPDATE-CAPABILITY flag in its
       STATEFUL-PCE-CAPABILITY TLV, a PCE can still operate as a passive
       stateful PCE by accepting LSP State Reports from the PCC in order to
       build and maintain an up-to-date view of the state of the PCC's LSPs.

    5.5.  IGP Extensions for Stateful PCE Capabilities Advertisement

       When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs
       are either LSRs or servers also participating in the IGP, an
       effective mechanism for PCE discovery within an IGP routing domain
       consists of utilizing IGP advertisements.  Extensions for the
       advertisement of PCE Discovery Information are defined for OSPF and
       for IS-IS in [RFC5088] and [RFC5089], respectively.

    Crabbe, et al.               Standards Track                   [Page 12]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional
       sub-TLV used to advertise PCE capabilities.  It MAY be present within
       the PCE Discovery (PCED) sub-TLV carried by OSPF or IS-IS.  [RFC5088]
       and [RFC5089] provide the description and processing rules for this
       sub-TLV when carried within OSPF and IS-IS, respectively.

       The format of the PCE-CAP-FLAGS sub-TLV is included below for easy
       reference:

       Type:  5

       Length:  Multiple of 4.

       Value:  This contains an array of units of 32-bit flags with the most
          significant bit as 0.  Each bit represents one PCE capability.

       PCE capability bits are defined in [RFC5088].  This document defines
       new capability bits for the stateful PCE as follows:

                      Bit    Capability
                      ---    -------------------------------
                      11     Active stateful PCE capability
                      12     Passive stateful PCE capability

       Note that while active and passive stateful PCE capabilities may be
       advertised during discovery, PCEP speakers that wish to use stateful
       PCEP MUST negotiate stateful PCEP capabilities during PCEP session
       setup, as specified in the current document.  A PCC MAY initiate
       stateful PCEP capability negotiation at PCEP session setup even if it
       did not receive any IGP PCE capability advertisements.

    5.6.  State Synchronization

       The purpose of State Synchronization is to provide a
       checkpoint-in-time state replica of a PCC's LSP state in a PCE.
       State Synchronization is performed immediately after the
       initialization phase [RFC5440].

       During State Synchronization, a PCC first takes a snapshot of the
       state of its LSPs, then it sends the snapshot to a PCE in a sequence
       of LSP State Reports.  Each LSP State Report sent during State
       Synchronization has the SYNC flag in the LSP object set to 1.  The
       set of LSPs for which state is synchronized with a PCE is determined
       by the PCC's local configuration (see more details in Section 9.1)
       and MAY also be determined by stateful PCEP capabilities defined in
       other documents, such as [RFC8232].

    Crabbe, et al.               Standards Track                   [Page 13]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       The end of the synchronization marker is a PCRpt message with the
       SYNC flag set to 0 for an LSP object with PLSP-ID equal to the
       reserved value 0 (see Section 7.3).  In this case, the LSP object
       SHOULD NOT include the SYMBOLIC-PATH-NAME TLV and SHOULD include the
       LSP-IDENTIFIERS TLV with the special value of all zeroes.  The PCRpt
       message MUST include an empty Explicit Route Object (ERO) as its
       intended path and SHOULD NOT include the optional Record Route Object
       (RRO) for its actual path.  If the PCC has no state to synchronize,
       it SHOULD only send the end of the synchronization marker.

       A PCE SHOULD NOT send PCUpd messages to a PCC before State
       Synchronization is complete.  A PCC SHOULD NOT send PCReq messages to
       a PCE before State Synchronization is complete.  This is to allow the
       PCE to get the best possible view of the network before it starts
       computing new paths.

       Either the PCE or the PCC MAY terminate the session using the PCEP
       session termination procedures during the synchronization phase.  If
       the session is terminated, the PCE MUST clean up the state it
       received from this PCC.  The session re-establishment MUST be
       re-attempted per the procedures defined in [RFC5440], including use
       of a backoff timer.

       If the PCC encounters a problem that prevents it from completing the
       LSP State Synchronization, it MUST send a PCErr message with
       error-type 20 (LSP State Synchronization Error) and error-value 5
       (indicating an internal PCC error) to the PCE and terminate the
       session.

       The PCE does not send positive acknowledgments for properly received
       synchronization messages.  It MUST respond with a PCErr message with
       Error-type=20 (LSP State Synchronization Error) and error-value 1
       (indicating an error in processing the PCRpt) (see Section 8.5) if it
       encounters a problem with the LSP State Report it received from the
       PCC, and it MUST terminate the session.

       A PCE implementing a limit on the resources a single PCC can occupy
       MUST send a PCEP Notify (PCNtf) message with Notification Type 4
       (Stateful PCE resource limit exceeded) and Notification Value 1
       (Entering resource limit exceeded state) in response to the PCRpt
       message triggering this condition in the synchronization phase and
       MUST terminate the session.

       The successful State Synchronization sequence is shown in Figure 1.

    Crabbe, et al.               Standards Track                   [Page 14]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

                         +-+-+                    +-+-+
                         |PCC|                    |PCE|
                         +-+-+                    +-+-+
                           |                        |
                           |-----PCRpt, SYNC=1----->| (Sync start)
                           |                        |
                           |-----PCRpt, SYNC=1----->|
                           |            .           |
                           |            .           |
                           |            .           |
                           |-----PCRpt, SYNC=1----->|
                           |            .           |
                           |            .           |
                           |            .           |
                           |                        |
                           |-----PCRpt, SYNC=0----->| (End of sync marker
                           |                        |  LSP State Report
                           |                        |  for PLSP-ID=0)
                           |                        | (Sync done)

                    Figure 1: Successful State Synchronization

       The sequence where the PCE fails during the State Synchronization
       phase is shown in Figure 2.

                         +-+-+                    +-+-+
                         |PCC|                    |PCE|
                         +-+-+                    +-+-+
                           |                        |
                           |-----PCRpt, SYNC=1----->|
                           |                        |
                           |-----PCRpt, SYNC=1----->|
                           |            .           |
                           |            .           |
                           |            .           |
                           |-----PCRpt, SYNC=1----->|
                           |                        |
                           |-PCRpt, SYNC=1          |
                           |         \    ,-PCErr   |
                           |          \  /          |
                           |           \/           |
                           |           /\           |
                           |          /   `-------->| (Ignored)
                           |<--------`              |

               Figure 2: Failed State Synchronization (PCE Failure)

    Crabbe, et al.               Standards Track                   [Page 15]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       The sequence where the PCC fails during the State Synchronization
       phase is shown in Figure 3.

                         +-+-+                    +-+-+
                         |PCC|                    |PCE|
                         +-+-+                    +-+-+
                           |                        |
                           |-----PCRpt, SYNC=1----->|
                           |                        |
                           |-----PCRpt, SYNC=1----->|
                           |            .           |
                           |            .           |
                           |            .           |
                           |-------- PCErr=? ------>|
                           |                        |

               Figure 3: Failed State Synchronization (PCC Failure)

       Optimizations to the synchronization procedures and alternate
       mechanisms of providing the synchronization function are outside the
       scope of this document and are discussed elsewhere (see [RFC8232]).

    5.7.  LSP Delegation

       If during capability advertisement both the PCE and the PCC have
       indicated that they support LSP Update, then the PCC may choose to
       grant the PCE a temporary right to update (a subset of) LSP
       attributes on one or more LSPs.  This is called "LSP delegation", and
       it MAY be performed at any time after the initialization phase,
       including during the State Synchronization phase.

       A PCE MAY return an LSP delegation at any time if it no longer wishes
       to update the LSP's state.  A PCC MAY revoke an LSP delegation at any
       time.  Delegation, Revocation, and Return are done individually for
       each LSP.

       In the event of a delegation being rejected or returned by a PCE, the
       PCC SHOULD react based on local policy.  It can, for example, either
       retry delegating to the same PCE using an exponentially increasing
       timer or delegate to an alternate PCE.

    5.7.1.  Delegating an LSP

       A PCC delegates an LSP to a PCE by setting the Delegate flag in the
       LSP State Report to 1.  If the PCE does not accept the LSP
       delegation, it MUST immediately respond with an empty LSP Update
       Request that has the Delegate flag set to 0.  If the PCE accepts the
       LSP delegation, it MUST set the Delegate flag to 1 when it sends an

    Crabbe, et al.               Standards Track                   [Page 16]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       LSP Update Request for the delegated LSP (note that this may occur at
       a later time).  The PCE MAY also immediately acknowledge a delegation
       by sending an empty LSP Update Request that has the Delegate flag set
       to 1.

       The delegation sequence is shown in Figure 4.

                         +-+-+                    +-+-+
                         |PCC|                    |PCE|
                         +-+-+                    +-+-+
                           |                        |
                           |---PCRpt, Delegate=1--->| LSP delegated
                           |                        |
                           |---PCRpt, Delegate=1--->|
                           |            .           |
                           |            .           |
                           |            .           |
                           |<--(PCUpd,Delegate=1)---| Delegation confirmed
                           |                        |
                           |---PCRpt, Delegate=1--->|
                           |                        |

                            Figure 4: Delegating an LSP

       Note that for an LSP to remain delegated to a PCE, the PCC MUST set
       the Delegate flag to 1 on each LSP State Report sent to the PCE.

    5.7.2.  Revoking a Delegation

    5.7.2.1.  Explicit Revocation

       When a PCC decides that a PCE is no longer permitted to modify an
       LSP, it revokes that LSP's delegation to the PCE.  A PCC may revoke
       an LSP delegation at any time during the LSP's lifetime.  A PCC
       revoking an LSP delegation MAY immediately remove the updated
       parameters provided by the PCE and revert to the operator-defined
       parameters, but to avoid traffic loss, it SHOULD do so in a
       make-before-break fashion.  If the PCC has received but not yet acted
       on PCUpd messages from the PCE for the LSP whose delegation is being
       revoked, then it SHOULD ignore these PCUpd messages when processing
       the message queue.  All effects of all messages for which processing
       started before the revocation took place MUST be allowed to complete,
       and the result MUST be given the same treatment as any LSP that had
       been previously delegated to the PCE (e.g., the state MAY immediately
       revert to the operator-defined parameters).

    Crabbe, et al.               Standards Track                   [Page 17]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       If a PCEP session with the PCE to which the LSP is delegated exists
       in the UP state during the revocation, the PCC MUST notify that PCE
       by sending an LSP State Report with the Delegate flag set to 0, as
       shown in Figure 5.

                         +-+-+                    +-+-+
                         |PCC|                    |PCE|
                         +-+-+                    +-+-+
                           |                        |
                           |---PCRpt, Delegate=1--->|
                           |                        |
                           |<--(PCUpd,Delegate=1)---| Delegation confirmed
                           |            .           |
                           |            .           |
                           |            .           |
                           |---PCRpt, Delegate=0--->| PCC revokes delegation
                           |                        |

                          Figure 5: Revoking a Delegation

       After an LSP delegation has been revoked, a PCE can no longer update
       an LSP's parameters; an attempt to update parameters of a
       non-delegated LSP will result in the PCC sending a PCErr message with
       Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP
       Update Request for a non-delegated LSP) (see Section 8.5).

    5.7.2.2.  Revocation on Redelegation Timeout

       When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC
       MUST wait the time interval specified in the Redelegation Timeout
       Interval before revoking LSP delegations to that PCE and attempting
       to redelegate LSPs to an alternate PCE.  If a PCEP session with the
       original PCE can be re-established before the Redelegation Timeout
       Interval timer expires, LSP delegations to the PCE remain intact.

       Likewise, when a PCC's PCEP session with a PCE terminates
       unexpectedly, and the PCC does not succeed in redelegating its LSPs,
       the PCC MUST wait for the State Timeout Interval before flushing any
       LSP state associated with that PCE.  Note that the State Timeout
       Interval timer may expire before the PCC has redelegated the LSPs to
       another PCE, for example, if a PCC is not connected to any active
       stateful PCE or if no connected active stateful PCE accepts the
       delegation.  In this case, the PCC MUST flush any LSP state set by
       the PCE upon expiration of the State Timeout Interval and revert to
       operator-defined default parameters or behaviors.  This operation
       SHOULD be done in a make-before-break fashion.

    Crabbe, et al.               Standards Track                   [Page 18]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       The State Timeout Interval MUST be greater than or equal to the
       Redelegation Timeout Interval and MAY be set to infinity (meaning
       that until the PCC specifically takes action to change the parameters
       set by the PCE, they will remain intact).

    5.7.3.  Returning a Delegation

       In order to keep a delegation, a PCE MUST set the Delegate flag to 1
       on each LSP Update Request sent to the PCC.  A PCE that no longer
       wishes to update an LSP's parameters SHOULD return the LSP delegation
       back to the PCC by sending an empty LSP Update Request that has the
       Delegate flag set to 0.  If a PCC receives an LSP Update Request with
       the Delegate flag set to 0 (whether the LSP Update Request is empty
       or not), it MUST treat this as a delegation return.

                         +-+-+                    +-+-+
                         |PCC|                    |PCE|
                         +-+-+                    +-+-+
                           |                        |
                           |---PCRpt, Delegate=1--->| LSP delegated
                           |            .           |
                           |            .           |
                           |            .           |
                           |<--PCUpd, Delegate=0----| Delegation returned
                           |                        |
                           |---PCRpt, Delegate=0--->| No delegation for LSP
                           |                        |

                         Figure 6: Returning a Delegation

       If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is
       not connected to any active stateful PCE or if no connected active
       stateful PCE accepts the delegation), the LSP delegation on the PCC
       will timeout within a configurable Redelegation Timeout Interval, and
       the PCC MUST flush any LSP state set by a PCE at the expiration of
       the State Timeout Interval and revert to operator-defined default
       parameters or behaviors.

    5.7.4.  Redundant Stateful PCEs

       In a redundant configuration where one PCE is backing up another PCE,
       the backup PCE may have only a subset of the LSPs in the network
       delegated to it.  The backup PCE does not update any LSPs that are
       not delegated to it.  In order to allow the backup to operate in a
       hot-standby mode and avoid the need for State Synchronization in case
       the primary fails, the backup receives all LSP State Reports from a
       PCC.  When the primary PCE for a given LSP set fails, after expiry of
       the Redelegation Timeout Interval, the PCC SHOULD delegate to the

    Crabbe, et al.               Standards Track                   [Page 19]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       redundant PCE all LSPs that had been previously delegated to the
       failed PCE.  Assuming that the State Timeout Interval had been
       configured to be greater than the Redelegation Timeout Interval (as
       MANDATORY), and assuming that the primary and redundant PCEs take
       similar decisions, this delegation change will not cause any changes
       to the LSP parameters.

    5.7.5.  Redelegation on PCE Failure

       On failure, the goal is to: 1) avoid any traffic loss on the LSPs
       that were updated by the PCE that crashed, 2) minimize the churn in
       the network in terms of ownership of the LSPs, 3) not leave any
       "orphan" (undelegated) LSPs, and 4) be able to control when the state
       that was set by the PCE can be changed or purged.  The values chosen
       for the Redelegation Timeout and State Timeout values affect the
       ability to accomplish these goals.

       This section summarizes the behavior with regards to LSP delegation
       and LSP state on a PCE failure.

       If the PCE crashes but recovers within the Redelegation Timeout, both
       the delegation state and the LSP state are kept intact.

       If the PCE crashes but does not recover within the Redelegation
       Timeout, the delegation state is returned to the PCC.  If the PCC can
       redelegate the LSPs to another PCE, and that PCE accepts the
       delegations, there will be no change in LSP state.  If the PCC cannot
       redelegate the LSPs to another PCE, then upon expiration of the State
       Timeout Interval, the state set by the PCE is removed and the LSP
       reverts to operator-defined parameters, which may cause a change in
       the LSP state.  Note that an operator may choose to use an infinite
       State Timeout Interval if he wishes to maintain the PCE state
       indefinitely.  Note also that flushing the state should be
       implemented using make-before-break to avoid traffic loss.

       If there is a standby PCE, the Redelegation Timeout may be set to 0
       through policy on the PCC, causing the LSPs to be redelegated
       immediately to the PCC, which can delegate them immediately to the
       standby PCE.  Assuming that the PCC can redelegate the LSP to the
       standby PCE within the State Timeout Interval, and assuming the
       standby PCE takes similar decisions as the failed PCE, the LSP state
       will be kept intact.

    Crabbe, et al.               Standards Track                   [Page 20]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    5.8.  LSP Operations

    5.8.1.  Passive Stateful PCE Path Computation Request/Response

                         +-+-+                    +-+-+
                         |PCC|                    |PCE|
                         +-+-+                    +-+-+
                           |                        |
       1) Path computation |----- PCReq message --->|
          request sent to  |                        |2) Path computation
          PCE              |                        |   request received,
                           |                        |   path computed
                           |                        |
                           |<---- PCRep message ----|3) Computed paths
                           |     (Positive reply)   |   sent to the PCC
                           |     (Negative reply)   |
       4) LSP state change |                        |
          event            |                        |
                           |                        |
       5) LSP State Report |----- PCRpt message --->|
          sent to all      |            .           |
          stateful PCEs    |            .           |
                           |            .           |
       6) Repeat for each  |----- PCRpt message --->|
          LSP state change |                        |
                           |                        |

         Figure 7: Passive Stateful PCE Path Computation Request/Response

       Once a PCC has successfully established a PCEP session with a passive
       stateful PCE and the PCC's LSP state is synchronized with the PCE
       (i.e., the PCE knows about all of the PCC's existing LSPs), if an
       event is triggered that requires the computation of a set of paths,
       the PCC sends a path computation request to the PCE ([RFC5440],
       Section 4.2.3).  The PCReq message MAY contain the LSP object to
       identify the LSP for which the path computation is requested.

       Upon receiving a path computation request from a PCC, the PCE
       triggers a path computation and returns either a positive or a
       negative reply to the PCC ([RFC5440], Section 4.2.4).

       Upon receiving a positive path computation reply, the PCC receives a
       set of computed paths and starts to set up the LSPs.  For each LSP,
       it MAY send an LSP State Report carried on a PCRpt message to the
       PCE, indicating that the LSP's status is "Going-up".

    Crabbe, et al.               Standards Track                   [Page 21]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       Once an LSP is up or active, the PCC MUST send an LSP State Report
       carried on a PCRpt message to the PCE, indicating that the LSP's
       status is 'Up' or 'Active', respectively.  If the LSP could not be
       set up, the PCC MUST send an LSP State Report indicating that the LSP
       is 'Down' and stating the cause of the failure.  Note that due to
       timing constraints, the LSP status may change from 'Going-up' to 'Up'
       (or 'Down') before the PCC has had a chance to send an LSP State
       Report indicating that the status is 'Going-up'.  In such cases, the
       PCC MAY choose to only send the PCRpt indicating the latest status
       ('Active', 'Up', or 'Down').

       Upon receiving a negative reply from a PCE, a PCC MAY resend a
       modified request or take any other appropriate action.  For each
       requested LSP, it SHOULD also send an LSP State Report carried on a
       PCRpt message to the PCE, indicating that the LSP's status is 'Down'.

       There is no direct correlation between PCRep and PCRpt messages.  For
       a given LSP, multiple LSP State Reports will follow a single PCRep
       message, as a PCC notifies a PCE of the LSP's state changes.

       A PCC MUST send each LSP State Report to each stateful PCE that is
       connected to the PCC.

       Note that a single PCRpt message MAY contain multiple LSP State
       Reports.

       The passive stateful model for stateful PCEs is described in
       [RFC4655], Section 6.8.

    5.8.2.  Switching from Passive Stateful to Active Stateful

       This section deals with the scenario of an LSP transitioning from a
       passive stateful to an active stateful mode of operation.  When the
       LSP has no working path, prior to delegating the LSP, the PCC MUST
       first use the procedure defined in Section 5.8.1 to request the
       initial path from the PCE.  This is required because the action of
       delegating the LSP to a PCE using a PCRpt message is not an explicit
       request to the PCE to compute a path for the LSP.  The only explicit
       way for a PCC to request a path from the PCE is to send a PCReq
       message.  The PCRpt message MUST NOT be used by the PCC to attempt to
       request a path from the PCE.

       When the LSP is delegated after its setup, it may be useful for the
       PCC to communicate to the PCE the locally configured intended
       configuration parameters, so that the PCE may reuse them in its
       computations.  Such parameters MAY be acquired through an out-of-band
       channel, or MAY be communicated in the PCRpt message delegating the
       LSPs, by including them as part of the intended-attribute-list as

    Crabbe, et al.               Standards Track                   [Page 22]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       explained in Section 6.1.  An implementation MAY allow policies on
       the PCC to determine the configuration parameters to be sent to the
       PCE.

    5.8.3.  Active Stateful PCE LSP Update

                         +-+-+                    +-+-+
                         |PCC|                    |PCE|
                         +-+-+                    +-+-+
                           |                        |
       1) LSP State        |-- PCRpt, Delegate=1 -->|
          Synchronization  |            .           |
                           |            .           |2) PCE decides to
                           |            .           |   update the LSP
                           |                        |
                           |<---- PCUpd message ----|3) PCUpd message sent
                           |                        |   to the PCC
                           |                        |
                           |                        |
       4) LSP State Report |---- PCRpt message ---->|
          sent(->Going-up) |            .           |
                           |            .           |
                           |            .           |
       5) LSP State Report |---- PCRpt message ---->|
          sent (->Up|Down) |                        |
                           |                        |

                           Figure 8: Active Stateful PCE

       Once a PCC has successfully established a PCEP session with an active
       stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e.,
       the PCE knows about all of the PCC's existing LSPs).  After LSPs have
       been delegated to the PCE, the PCE can modify LSP parameters of
       delegated LSPs.

       To update an LSP, a PCE MUST send the PCC an LSP Update Request using
       a PCUpd message.  The LSP Update Request contains a variety of
       objects that specify the set of constraints and attributes for the
       LSP's path.  Each LSP Update Request MUST have a unique identifier,
       the SRP-ID-number, carried in the SRP object described in
       Section 7.2.  The SRP-ID-number is used to correlate errors and state
       reports to LSP Update Requests.  A single PCUpd message MAY contain
       multiple LSP Update Requests.

       Upon receiving a PCUpd message, the PCC starts to set up LSPs
       specified in LSP Update Requests carried in the message.  For each
       LSP, it MAY send an LSP State Report carried on a PCRpt message to
       the PCE, indicating that the LSP's status is 'Going-up'.  If the PCC

    Crabbe, et al.               Standards Track                   [Page 23]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       decides that the LSP parameters proposed in the PCUpd message are
       unacceptable, it MUST report this error by including the
       LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable
       parameters" in the LSP object in the PCRpt message to the PCE.  Based
       on local policy, it MAY react further to this error by revoking the
       delegation.  If the PCC receives a PCUpd message for an LSP object
       identified with a PLSP-ID that does not exist on the PCC, it MUST
       generate a PCErr with Error-type=19 (Invalid Operation), error-value
       3, (Attempted LSP Update Request for an LSP identified by an unknown
       PSP-ID) (see Section 8.5).

       Once an LSP is up, the PCC MUST send an LSP State Report (PCRpt
       message) to the PCE, indicating that the LSP's status is 'Up'.  If
       the LSP could not be set up, the PCC MUST send an LSP State Report
       indicating that the LSP is 'Down' and stating the cause of the
       failure.  A PCC MAY compress LSP State Reports to only reflect the
       most up to date state, as discussed in the previous section.

       A PCC MUST send each LSP State Report to each stateful PCE that is
       connected to the PCC.

       PCErr and PCRpt messages triggered as a result of a PCUpd message
       MUST include the SRP-ID-number from the PCUpd.  This provides
       correlation of requests and errors and acknowledgement of state
       processing.  The PCC MAY compress the state when processing PCUpd.
       In this case, receipt of a higher SRP-ID-number implicitly
       acknowledges processing all the updates with a lower SRP-ID-number
       for the specific LSP (as per Section 7.2).

       A PCC MUST NOT send to any PCE a path computation request for a
       delegated LSP.  Should the PCC decide it wants to issue a Path
       Computation Request on a delegated LSP, it MUST perform the
       Delegation Revocation procedure first.

    5.9.  LSP Protection

       LSP protection and interaction with stateful PCE, as well as the
       extensions necessary to implement this functionality, will be
       discussed in a separate document.

    5.10.  PCEP Sessions

       A permanent PCEP session MUST be established between a stateful PCE
       and the PCC.  In the case of session failure, session
       re-establishment MUST be re-attempted per the procedures defined in
       [RFC5440].

    Crabbe, et al.               Standards Track                   [Page 24]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    6.  PCEP Messages

       As defined in [RFC5440], a PCEP message consists of a common header
       followed by a variable-length body made of a set of objects.  For
       each PCEP message type, a set of rules is defined that specifies the
       set of objects that the message can carry.

    6.1.  The PCRpt Message

       A Path Computation LSP State Report message (also referred to as a
       PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
       current state of an LSP.  A PCRpt message can carry more than one LSP
       State Reports.  A PCC can send an LSP State Report either in response
       to an LSP Update Request from a PCE or asynchronously when the state
       of an LSP changes.  The Message-Type field of the PCEP common header
       for the PCRpt message is 10.

       The format of the PCRpt message is as follows:

          <PCRpt Message> ::= <Common Header>
                              <state-report-list>
       Where:

          <state-report-list> ::= <state-report>[<state-report-list>]

          <state-report> ::= [<SRP>]
                             <LSP>
                             <path>
        Where:
          <path>::= <intended-path>
                    [<actual-attribute-list><actual-path>]
                    <intended-attribute-list>

          <actual-attribute-list>::=[<BANDWIDTH>]
                                    [<metric-list>]

       Where:
          <intended-path> is represented by the ERO object defined in
          Section 7.9 of [RFC5440].

          <actual-attribute-list> consists of the actual computed and
          signaled values of the <BANDWIDTH> and <metric-lists> objects
          defined in [RFC5440].

          <actual-path> is represented by the RRO object defined in
          Section 7.10 of [RFC5440].

    Crabbe, et al.               Standards Track                   [Page 25]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

          <intended-attribute-list> is the attribute-list defined in
          Section 6.5 of [RFC5440] and extended by PCEP extensions.

       The SRP object (see Section 7.2) is OPTIONAL.  If the PCRpt message
       is not in response to a PCupd message, the SRP object MAY be omitted.

       When the PCC does not include the SRP object, the PCE MUST treat this
       as an SRP object with an SRP-ID-number equal to the reserved value
       0x00000000.  The reserved value 0x00000000 indicates that the state
       reported is not a result of processing a PCUpd message.

       If the PCRpt message is in response to a PCUpd message, the SRP
       object MUST be included and the value of the SRP-ID-number in the SRP
       object MUST be the same as that sent in the PCUpd message that
       triggered the state that is reported.  If the PCC compressed several
       PCUpd messages for the same LSP by only processing the one with the
       highest number, then it should use the SRP-ID-number of that request.
       No state compression is allowed for state reporting, e.g., PCRpt
       messages MUST NOT be pruned from the PCC's egress queue even if
       subsequent operations on the same LSP have been completed before the
       PCRpt message has been sent to the TCP stack.  The PCC MUST
       explicitly report state changes (including removal) for paths it
       manages.

       The LSP object (see Section 7.3) is REQUIRED, and it MUST be included
       in each LSP State Report on the PCRpt message.  If the LSP object is
       missing, the receiving PCE MUST send a PCErr message with
       Error-type=6 (Mandatory Object missing) and Error-value 8 (LSP object
       missing).

       If the LSP transitioned to non-operational state, the PCC SHOULD
       include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
       Code to report the error to the PCE.

       The intended path, represented by the ERO object, is REQUIRED.  If
       the ERO object is missing, the receiving PCE MUST send a PCErr
       message with Error-type=6 (Mandatory Object missing) and Error-value
       9 (ERO object missing).  The ERO may be empty if the PCE does not
       have a path for a delegated LSP.

       The actual path, represented by the RRO object, SHOULD be included in
       a PCRpt by the PCC when the path is up or active, but it MAY be
       omitted if the path is down due to a signaling error or another
       failure.

       The intended-attribute-list maps to the attribute-list in Section 6.5
       of [RFC5440] and is used to convey the requested parameters of the
       LSP path.  This is needed in order to support the switch from passive

    Crabbe, et al.               Standards Track                   [Page 26]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       to active stateful PCE as described in Section 5.8.2.  When included
       as part of the intended-attribute-list, the meaning of the BANDWIDTH
       object is the requested bandwidth as intended by the operator.  In
       this case, the BANDWIDTH Object-Type of 1 SHOULD be used.  Similarly,
       to indicate a limiting constraint, the METRIC object SHOULD be
       included as part of the intended-attribute-list with the B flag set
       and with a specific metric value.  To indicate the optimization
       metric, the METRIC object SHOULD be included as part of the
       intended-attribute-list with the B flag unset and the metric value
       set to zero.  Note that the intended-attribute-list is optional and
       thus may be omitted.  In this case, the PCE MAY use the values in the
       actual-attribute-list as the requested parameters for the path.

       The actual-attribute-list consists of the actual computed and
       signaled values of the BANDWIDTH and METRIC objects defined in
       [RFC5440].  When included as part of the actual-attribute-list,
       Object-Type 2 [RFC5440] SHOULD be used for the BANDWIDTH object, and
       the C flag SHOULD be set in the METRIC object [RFC5440].

       Note that the ordering of intended-path, actual-attribute-list,
       actual-path, and intended-attribute-list is chosen to retain
       compatibility with implementations of an earlier version of this
       standard.

       A PCE may choose to implement a limit on the resources a single PCC
       can occupy.  If a PCRpt is received that causes the PCE to exceed
       this limit, the PCE MUST notify the PCC using a PCNtf message with
       Notification Type 4 (Stateful PCE resource limit exceeded) and
       Notification Value 1 (Entering resource limit exceeded state), and it
       MUST terminate the session.

    6.2.  The PCUpd Message

       A Path Computation LSP Update Request message (also referred to as
       PCUpd message) is a PCEP message sent by a PCE to a PCC to update
       attributes of an LSP.  A PCUpd message can carry more than one LSP
       Update Request.  The Message-Type field of the PCEP common header for
       the PCUpd message is 11.

    Crabbe, et al.               Standards Track                   [Page 27]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       The format of a PCUpd message is as follows:

          <PCUpd Message> ::= <Common Header>
                              <update-request-list>
       Where:

          <update-request-list> ::= <update-request>[<update-request-list>]

          <update-request> ::= <SRP>
                               <LSP>
                               <path>
       Where:
          <path>::= <intended-path><intended-attribute-list>

       Where:
          <intended-path> is represented by the ERO object defined in
          Section 7.9 of [RFC5440].

          <intended-attribute-list> is the attribute-list defined in
          [RFC5440] and extended by PCEP extensions.

       There are three mandatory objects that MUST be included within each
       LSP Update Request in the PCUpd message: the SRP object (see
       Section 7.2), the LSP object (see Section 7.3) and the ERO object (as
       defined in [RFC5440], which represents the intended path.  If the SRP
       object is missing, the receiving PCC MUST send a PCErr message with
       Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP
       object missing).  If the LSP object is missing, the receiving PCC
       MUST send a PCErr message with Error-type=6 (Mandatory Object
       missing) and Error-value=8 (LSP object missing).  If the ERO object
       is missing, the receiving PCC MUST send a PCErr message with
       Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO object
       missing).

       The ERO in the PCUpd may be empty if the PCE cannot find a valid path
       for a delegated LSP.  One typical situation resulting in this empty
       ERO carried in the PCUpd message is that a PCE can no longer find a
       strict SRLG-disjoint path for a delegated LSP after a link failure.
       The PCC SHOULD implement a local policy to decide the appropriate
       action to be taken: either tear down the LSP or revoke the delegation
       and use a locally computed path, or keep the existing LSP.

       A PCC only acts on an LSP Update Request if permitted by the local
       policy configured by the network manager.  Each LSP Update Request
       that the PCC acts on results in an LSP setup operation.  An LSP
       Update Request MUST contain all LSP parameters that a PCE wishes to

    Crabbe, et al.               Standards Track                   [Page 28]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       be set for the LSP.  A PCC MAY set missing parameters from locally
       configured defaults.  If the LSP specified in the Update Request is
       already up, it will be re-signaled.

       The PCC SHOULD minimize the traffic interruption and MAY use the
       make-before-break procedures described in [RFC3209] in order to
       achieve this goal.  If the make-before-break procedures are used, two
       paths will briefly coexist.  The PCC MUST send separate PCRpt
       messages for each, identified by the LSP-IDENTIFIERS TLV.  When the
       old path is torn down after the head end switches over the traffic,
       this event MUST be reported by sending a PCRpt message with the
       LSP-IDENTIFIERS-TLV of the old path and the R bit set.  The
       SRP-ID-number that the PCC associates with this PCRpt MUST be
       0x00000000.  Thus, a make-before-break operation will typically
       result in at least two PCRpt messages, one for the new path and one
       for the removal of the old path (more messages may be possible if
       intermediate states are reported).

       If the path setup fails due to an RSVP signaling error, the error is
       reported to the PCE.  The PCC will not attempt to re-signal the path
       until it is prompted again by the PCE with a subsequent PCUpd
       message.

       A PCC MUST respond with an LSP State Report to each LSP Update
       Request it processed to indicate the resulting state of the LSP in
       the network (even if this processing did not result in changing the
       state of the LSP).  The SRP-ID-number included in the PCRpt MUST
       match that in the PCUpd.  A PCC MAY respond with multiple LSP State
       Reports to report LSP setup progress of a single LSP.  In that case,
       the SRP-ID-number MUST be included for the first message; for
       subsequent messages, the reserved value 0x00000000 SHOULD be used.

       Note that a PCC MUST process all LSP Update Requests -- for example,
       an LSP Update Request is sent when a PCE returns delegation or puts
       an LSP into non-operational state.  The protocol relies on TCP for
       message-level flow control.

       If the rate of PCUpd messages sent to a PCC for the same target LSP
       exceeds the rate at which the PCC can signal LSPs into the network,
       the PCC MAY perform state compression on its ingress queue.  The
       compression algorithm is based on the fact that each PCUpd request
       contains the complete LSP state the PCE wishes to be set and works as
       follows: when the PCC starts processing a PCUpd message at the head
       of its ingress queue, it may search the queue forward for more recent
       PCUpd messages pertaining to that particular LSP, prune all but the
       latest one from the queue, and process only the last one as that
       request contains the most up-to-date desired state for the LSP.  The
       PCC MUST NOT send PCRpt nor PCErr messages for requests that were

    Crabbe, et al.               Standards Track                   [Page 29]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       pruned from the queue in this way.  This compression step may be
       performed only while the LSP is not being signaled, e.g., if two
       PCUpd arrive for the same LSP in quick succession and the PCC started
       the signaling of the changes relevant to the first PCUpd, then it
       MUST wait until the signaling finishes (and report the new state via
       a PCRpt) before attempting to apply the changes indicated in the
       second PCUpd.

       Note also that it is up to the PCE to handle inter-LSP dependencies;
       for example, if ordering of LSP setups is required, the PCE has to
       wait for an LSP State Report for a previous LSP before starting the
       update of the next LSP.

       If the PCUpd cannot be satisfied (for example, due to an unsupported
       object or a TLV), the PCC MUST respond with a PCErr message
       indicating the failure (see Section 7.3.3).

    6.3.  The PCErr Message

       If the stateful PCE capability has been advertised on the PCEP
       session, the PCErr message MAY include the SRP object.  If the error
       reported is the result of an LSP Update Request, then the
       SRP-ID-number MUST be the one from the PCUpd that triggered the
       error.  If the error is unsolicited, the SRP object MAY be omitted.
       This is equivalent to including an SRP object with the SRP-ID-number
       equal to the reserved value 0x00000000.

       The format of a PCErr message from [RFC5440] is extended as follows:

          <PCErr Message> ::= <Common Header>
                            ( <error-obj-list> [<Open>] ) | <error>
                            [<error-list>]

          <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]

          <error>::=[<request-id-list> | <stateful-request-id-list>]
                     <error-obj-list>

          <request-id-list>::=<RP>[<request-id-list>]

          <stateful-request-id-list>::=<SRP>[<stateful-request-id-list>]

          <error-list>::=<error>[<error-list>]

    Crabbe, et al.               Standards Track                   [Page 30]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    6.4.  The PCReq Message

       A PCC MAY include the LSP object in the PCReq message (see
       Section 7.3) if the stateful PCE capability has been negotiated on a
       PCEP session between the PCC and a PCE.

       The definition of the PCReq message from [RFC5440] is extended to
       optionally include the LSP object after the END-POINTS object.  The
       encoding from [RFC5440] will become:

          <PCReq Message>::= <Common Header>
                             [<svec-list>]
                             <request-list>
       Where:

             <svec-list>::=<SVEC>[<svec-list>]
             <request-list>::=<request>[<request-list>]

             <request>::= <RP>
                          <END-POINTS>
                          [<LSP>]
                          [<LSPA>]
                          [<BANDWIDTH>]
                          [<metric-list>]
                          [<RRO>[<BANDWIDTH>]]
                          [<IRO>]
                          [<LOAD-BALANCING>]

    6.5.  The PCRep Message

       A PCE MAY include the LSP object in the PCRep message (see
       Section 7.3) if the stateful PCE capability has been negotiated on a
       PCEP session between the PCC, and the PCE and the LSP object were
       included in the corresponding PCReq message from the PCC.

       The definition of the PCRep message from [RFC5440] is extended to
       optionally include the LSP object after the Request Parameter (RP)
       object.  The encoding from [RFC5440] will become:

          <PCRep Message> ::= <Common Header>
                              <response-list>

    Crabbe, et al.               Standards Track                   [Page 31]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       Where:

             <response-list>::=<response>[<response-list>]

             <response>::=<RP>
                         [<LSP>]
                         [<NO-PATH>]
                         [<attribute-list>]
                         [<path-list>]

    7.  Object Formats

       The PCEP objects defined in this document are compliant with the PCEP
       object format defined in [RFC5440].  The P and I flags of the PCEP
       objects defined in the current document MUST be set to 0 on
       transmission and SHOULD be ignored on receipt since they are
       exclusively related to path computation requests.

    7.1.  OPEN Object

       This document defines one new optional TLV for use in the OPEN
       object.

    7.1.1.  STATEFUL-PCE-CAPABILITY TLV

       The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the
       OPEN object for stateful PCE capability advertisement.  Its format is
       shown in the following figure:

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |               Type=16         |            Length=4           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                             Flags                           |U|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 9: STATEFUL-PCE-CAPABILITY TLV Format

       The type (16 bits) of the TLV is 16.  The length field is 16 bits
       long and has a fixed value of 4.

       The value comprises a single field -- Flags (32 bits):

       U (LSP-UPDATE-CAPABILITY - 1 bit):  if set to 1 by a PCC, the U flag
          indicates that the PCC allows modification of LSP parameters; if
          set to 1 by a PCE, the U flag indicates that the PCE is capable of

    Crabbe, et al.               Standards Track                   [Page 32]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

          updating LSP parameters.  The LSP-UPDATE-CAPABILITY flag must be
          advertised by both a PCC and a PCE for PCUpd messages to be
          allowed on a PCEP session.

       Unassigned bits are considered reserved.  They MUST be set to 0 on
       transmission and MUST be ignored on receipt.

       A PCEP speaker operating in passive stateful PCE mode advertises the
       stateful PCE capability with the U flag set to 0.  A PCEP speaker
       operating in active stateful PCE mode advertises the stateful PCE
       capability with the U flag set to 1.

       Advertisement of the stateful PCE capability implies support of LSPs
       that are signaled via RSVP, as well as the objects, TLVs, and
       procedures defined in this document.

    7.2.  SRP Object

       The SRP (Stateful PCE Request Parameters) object MUST be carried
       within PCUpd messages and MAY be carried within PCRpt and PCErr
       messages.  The SRP object is used to correlate between update
       requests sent by the PCE and the error reports and state reports sent
       by the PCC.

       SRP Object-Class is 33.

       SRP Object-Type is 1.

       The format of the SRP object body is shown in Figure 10:

           0                   1                   2                   3
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                          Flags                                |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                        SRP-ID-number                          |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                                                               |
          //                      Optional TLVs                          //
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 10: The SRP Object Format

       The SRP object body has a variable length and may contain additional
       TLVs.

    Crabbe, et al.               Standards Track                   [Page 33]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       Flags (32 bits): None defined yet.

       SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the
       current PCEP session uniquely identifies the operation that the PCE
       has requested the PCC to perform on a given LSP.  The SRP-ID-number
       is incremented each time a new request is sent to the PCC, and it may
       wrap around.

       The values 0x00000000 and 0xFFFFFFFF are reserved.

       Optional TLVs MAY be included within the SRP object body.  The
       specification of such TLVs is outside the scope of this document.

       Every request to update an LSP receives a new SRP-ID-number.  This
       number is unique per PCEP session and is incremented each time an
       operation is requested from the PCE.  Thus, for a given LSP, there
       may be more than one SRP-ID-number unacknowledged at a given time.
       The value of the SRP-ID-number is echoed back by the PCC in PCErr and
       PCRpt messages to allow for correlation between requests made by the
       PCE and errors or state reports generated by the PCC.  If the error
       or report was not a result of a PCE operation (for example, in the
       case of a link down event), the reserved value of 0x00000000 is used
       for the SRP-ID-number.  The absence of the SRP object is equivalent
       to an SRP object with the reserved value of 0x00000000.  An
       SRP-ID-number is considered unacknowledged and cannot be reused until
       a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for
       the same LSP.  In case of SRP-ID-number wrapping, the last
       SRP-ID-number before the wrapping MUST be explicitly acknowledged, to
       avoid a situation where SRP-ID-numbers remain unacknowledged after
       the wrap.  This means that the PCC may need to issue two PCUpd
       messages on detecting a wrap.

    7.3.  LSP Object

       The LSP object MUST be present within PCRpt and PCUpd messages.  The
       LSP object MAY be carried within PCReq and PCRep messages if the
       stateful PCE capability has been negotiated on the session.  The LSP
       object contains a set of fields used to specify the target LSP, the
       operation to be performed on the LSP, and LSP delegation.  It also
       contains a flag indicating to a PCE that the LSP State
       Synchronization is in progress.  This document focuses on LSPs that
       are signaled with RSVP; many of the TLVs used with the LSP object
       mirror RSVP state.

       LSP Object-Class is 32.

       LSP Object-Type is 1.

    Crabbe, et al.               Standards Track                   [Page 34]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       The format of the LSP object body is shown in Figure 11:

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                PLSP-ID                |    Flag |  O  |A|R|S|D|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         //                        TLVs                                 //
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 11: The LSP Object Format

       PLSP-ID (20 bits): A PCEP-specific identifier for the LSP.  A PCC
       creates a unique PLSP-ID for each LSP that is constant for the
       lifetime of a PCEP session.  The PCC will advertise the same PLSP-ID
       on all PCEP sessions it maintains at a given time.  The mapping of
       the symbolic path name to PLSP-ID is communicated to the PCE by
       sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV.  All
       subsequent PCEP messages then address the LSP by the PLSP-ID.  The
       values of 0 and 0xFFFFF are reserved.  Note that the PLSP-ID is a
       value that is constant for the lifetime of the PCEP session, during
       which time for an RSVP-signaled LSP there might be different RSVP
       identifiers (LSP-id, tunnel-id) allocated to it.

       Flags (12 bits), starting from the least significant bit:

       D (Delegate - 1 bit):  On a PCRpt message, the D flag set to 1
          indicates that the PCC is delegating the LSP to the PCE.  On a
          PCUpd message, the D flag set to 1 indicates that the PCE is
          confirming the LSP delegation.  To keep an LSP delegated to the
          PCE, the PCC must set the D flag to 1 on each PCRpt message for
          the duration of the delegation -- the first PCRpt with the D flag
          set to 0 revokes the delegation.  To keep the delegation, the PCE
          must set the D flag to 1 on each PCUpd message for the duration of
          the delegation -- the first PCUpd with the D flag set to 0 returns
          the delegation.

       S (SYNC - 1 bit):  The S flag MUST be set to 1 on each PCRpt sent
          from a PCC during State Synchronization.  The S flag MUST be set
          to 0 in other messages sent from the PCC.  When sending a PCUpd
          message, the PCE MUST set the S flag to 0.

       R (Remove - 1 bit):  On PCRpt messages, the R flag indicates that the
          LSP has been removed from the PCC and the PCE SHOULD remove all
          state from its database.  Upon receiving an LSP State Report with
          the R flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD
          remove all state for the path identified by the LSP-IDENTIFIERS

    Crabbe, et al.               Standards Track                   [Page 35]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

          TLV from its database.  When the all-zeros LSP-IDENTIFIERS TLV is
          used, the PCE SHOULD remove all state for the PLSP-ID from its
          database.  When sending a PCUpd message, the PCE MUST set the R
          flag to 0.

       A (Administrative - 1 bit):  On PCRpt messages, the A flag indicates
          the PCC's target operational status for this LSP.  On PCUpd
          messages, the A flag indicates the LSP status that the PCE desires
          for this LSP.  In both cases, a value of '1' means that the
          desired operational state is active, and a value of '0' means that
          the desired operational state is inactive.  A PCC ignores the A
          flag on a PCUpd message unless the operator's policy allows the
          PCE to control the corresponding LSP's administrative state.

       O (Operational - 3 bits):  On PCRpt messages, the O field represents
          the operational status of the LSP.

          The following values are defined:

          0 - DOWN:         not active.

          1 - UP:           signaled.

          2 - ACTIVE:       up and carrying traffic.

          3 - GOING-DOWN:   LSP is being torn down, and resources are being
                            released.

          4 - GOING-UP:     LSP is being signaled.

          5-7 - Reserved:   these values are reserved for future use.

       Unassigned bits are reserved for future uses.  They MUST be set to 0
       on transmission and MUST be ignored on receipt.  When sending a PCUpd
       message, the PCE MUST set the O field to 0.

       TLVs that may be included in the LSP object are described in the
       following sections.  Other optional TLVs, that are not defined in
       this document, MAY also be included within the LSP object body.

    7.3.1.  LSP-IDENTIFIERS TLVs

       The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt
       messages for RSVP-signaled LSPs.  If the TLV is missing, the PCE will
       generate an error with Error-type=6 (Mandatory Object missing) and
       error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session.
       The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd
       messages for RSVP-signaled LSPs.  The special value of all zeros for

    Crabbe, et al.               Standards Track                   [Page 36]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       this TLV is used to refer to all paths pertaining to a particular
       PLSP-ID.  There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one
       for IPv6.

       It is the responsibility of the PCC to send to the PCE the
       identifiers for each RSVP incarnation of the tunnel.  For example, in
       a make-before-break scenario, the PCC MUST send a separate PCRpt for
       the old and reoptimized paths and explicitly report removal of any of
       these paths using the R bit in the LSP object.

       The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following
       figure:

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Type=18             |           Length=16           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                   IPv4 Tunnel Sender Address                  |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |             LSP ID            |           Tunnel ID           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        Extended Tunnel ID                     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                   IPv4 Tunnel Endpoint Address                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 12: IPV4-LSP-IDENTIFIERS TLV Format

       The type (16 bits) of the TLV is 18.  The length field is 16 bits
       long and has a fixed value of 16.  The value contains the following
       fields:

       IPv4 Tunnel Sender Address:  contains the sender node's IPv4 address,
          as defined in [RFC3209], Section 4.6.2.1, for the LSP_TUNNEL_IPv4
          Sender Template Object.

       LSP ID:  contains the 16-bit 'LSP ID' identifier defined in
          [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template
          Object.  A value of 0 MUST be used if the LSP is not yet signaled.

       Tunnel ID:  contains the 16-bit 'Tunnel ID' identifier defined in
          [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.

       Extended Tunnel ID:  contains the 32-bit 'Extended Tunnel ID'
          identifier defined in [RFC3209], Section 4.6.1.1 for the
          LSP_TUNNEL_IPv4 Session Object.

    Crabbe, et al.               Standards Track                   [Page 37]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       IPv4 Tunnel Endpoint Address:  contains the egress node's IPv4
          address, as defined in [RFC3209], Section 4.6.1.1, for the
          LSP_TUNNEL_IPv4 Sender Template Object.

       The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following
       figure:

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Type=19             |           Length=52           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +                                                               +
         |                  IPv6 Tunnel Sender Address                   |
         +                          (16 octets)                          +
         |                                                               |
         +                                                               +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |             LSP ID            |           Tunnel ID           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +                                                               +
         |                       Extended Tunnel ID                      |
         +                          (16 octets)                          +
         |                                                               |
         +                                                               +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +                                                               +
         |                  IPv6 Tunnel Endpoint Address                 |
         +                          (16 octets)                          +
         |                                                               |
         +                                                               +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 13: IPV6-LSP-IDENTIFIERS TLV Format

       The type (16 bits) of the TLV is 19.  The length field is 16 bits
       long and has a fixed value of 52.  The value contains the following
       fields:

       IPv6 Tunnel Sender Address:  contains the sender node's IPv6 address,
          as defined in [RFC3209], Section 4.6.2.2, for the LSP_TUNNEL_IPv6
          Sender Template Object.

    Crabbe, et al.               Standards Track                   [Page 38]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       LSP ID:  contains the 16-bit 'LSP ID' identifier defined in
          [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template
          Object.  A value of 0 MUST be used if the LSP is not yet signaled.

       Tunnel ID:  contains the 16-bit 'Tunnel ID' identifier defined in
          [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.

       Extended Tunnel ID:  contains the 128-bit 'Extended Tunnel ID'
          identifier defined in [RFC3209], Section 4.6.1.2 for the
          LSP_TUNNEL_IPv6 Session Object.

       IPv6 Tunnel Endpoint Address:  contains the egress node's IPv6
          address, as defined in [RFC3209], Section 4.6.1.2, for the
          LSP_TUNNEL_IPv6 Session Object.

       The Tunnel ID remains constant over the lifetime of a tunnel.

    7.3.2.  Symbolic Path Name TLV

       Each LSP MUST have a symbolic path name that is unique in the PCC.
       The symbolic path name is a human-readable string that identifies an
       LSP in the network.  The symbolic path name MUST remain constant
       throughout an LSP's lifetime, which may span across multiple
       consecutive PCEP sessions and/or PCC restarts.  The symbolic path
       name MAY be specified by an operator in a PCC's configuration.  If
       the operator does not specify a unique symbolic name for an LSP, then
       the PCC MUST auto-generate one.

       The PCE uses the symbolic path name as a stable identifier for the
       LSP.  If the PCEP session restarts, or the PCC restarts, or the PCC
       re-delegates the LSP to a different PCE, the symbolic path name for
       the LSP remains constant and can be used to correlate across the PCEP
       session instances.

       The other protocol identifiers for the LSP cannot reliably be used to
       identify the LSP across multiple PCEP sessions, for the following
       reasons.

       o  The PLSP-ID is unique only within the scope of a single PCEP
          session.

       o  The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs
          that are signaled with RSVP-TE, and it may change during the
          lifetime of the LSP.

       The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the
       LSP State Report (PCRpt) message when during a given PCEP session an
       LSP is first reported to a PCE.  A PCC sends to a PCE the first LSP

    Crabbe, et al.               Standards Track                   [Page 39]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       State Report either during State Synchronization or when a new LSP is
       configured at the PCC.

       The initial PCRpt creates a binding between the symbolic path name
       and the PLSP-ID for the LSP that lasts for the duration of the PCEP
       session.  The PCC MAY omit the symbolic path name from subsequent LSP
       State Reports for that LSP on that PCEP session, and just use the
       PLSP-ID.

       The format of the SYMBOLIC-PATH-NAME TLV is shown in the following
       figure:

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Type=17             |       Length (variable)       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         //                      Symbolic Path Name                     //
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 14: SYMBOLIC-PATH-NAME TLV Format

       Type (16 bits): the type is 17.

       Length (16 bits): indicates the total length of the TLV in octets and
       MUST be greater than 0.  The TLV MUST be zero-padded so that the TLV
       is 4-octet aligned.

       Symbolic Path Name (variable): symbolic name for the LSP, unique in
       the PCC.  It SHOULD be a string of printable ASCII characters,
       without a NULL terminator.

    7.3.3.  LSP Error Code TLV

       The LSP Error Code TLV is an optional TLV for use in the LSP object
       to convey error information.  When an LSP Update Request fails, an
       LSP State Report MUST be sent to report the current state of the LSP,
       and it SHOULD contain the LSP-ERROR-CODE TLV indicating the reason
       for the failure.  Similarly, when a PCRpt is sent as a result of an
       LSP transitioning to non-operational state, the LSP-ERROR-CODE TLV
       SHOULD be included to indicate the reason for the transition.

    Crabbe, et al.               Standards Track                   [Page 40]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       The format of the LSP-ERROR-CODE TLV is shown in the following
       figure:

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Type=20             |            Length=4           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                          LSP Error Code                       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 15: LSP-ERROR-CODE TLV Format

       The type (16 bits) of the TLV is 20.  The length field is 16 bits
       long and has a fixed value of 4.  The value contains an error code
       that indicates the cause of the failure.

       The following LSP Error Codes are currently defined:

                   Value      Description
                   -----      -------------------------------------
                     1        Unknown reason
                     2        Limit reached for PCE-controlled LSPs
                     3        Too many pending LSP Update Requests
                     4        Unacceptable parameters
                     5        Internal error
                     6        LSP administratively brought down
                     7        LSP preempted
                     8        RSVP signaling error

    7.3.4.  RSVP Error Spec TLV

       The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object
       to carry RSVP error information.  It includes the RSVP ERROR_SPEC or
       USER_ERROR_SPEC object ([RFC2205] and [RFC5284]), which were returned
       to the PCC from a downstream node.  If the setup of an LSP fails at a
       downstream node that returned an ERROR_SPEC to the PCC, the PCC
       SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with
       LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV
       with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC object.

    Crabbe, et al.               Standards Track                   [Page 41]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       The format of the RSVP-ERROR-SPEC TLV is shown in the following
       figure:

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           Type=21             |            Length (variable)  |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +                RSVP ERROR_SPEC or USER_ERROR_SPEC Object      +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 16: RSVP-ERROR-SPEC TLV Format

       Type (16 bits): the type is 21.

       Length (16 bits): indicates the total length of the TLV in octets.
       The TLV MUST be zero-padded so that the TLV is 4-octet aligned.

       Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC
       object, as specified in [RFC2205] and [RFC5284], including the object
       header.

    8.  IANA Considerations

       The code points described below have been allocated for the protocol
       elements defined in this document.

    8.1.  PCE Capabilities in IGP Advertisements

       The following bits have been registered in the "Path Computation
       Element (PCE) Capability Flags" subregistry of the "Open Shortest
       Path First (OSPF) Parameters" registry:

               Bit   Description                        Reference
               ---   -------------------------------    -------------
                11   Active stateful PCE capability     This document
                12   Passive stateful PCE capability    This document

    Crabbe, et al.               Standards Track                   [Page 42]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    8.2.  PCEP Messages

       The following message types have been allocated within the "PCEP
       Messages" subregistry of the "Path Computation Element Protocol
       (PCEP) Numbers" registry:

                        Value  Description    Reference
                        -----  ------------   -------------
                          10   Report         This document
                          11   Update         This document

    8.3.  PCEP Objects

       The following object-class values and object types have been
       allocated within the "PCEP Objects" subregistry of the "Path
       Computation Element Protocol (PCEP) Numbers" registry:

              Object-Class Value  Name                  Reference
              ------------------  ----------------      -------------
                      32          LSP                   This document
                                  Object-Type
                                  0: Reserved
                                  1: LSP

                      33          SRP                   This document
                                  Object-Type
                                  0: Reserved
                                  1: SRP

    Crabbe, et al.               Standards Track                   [Page 43]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    8.4.  LSP Object

       A new subregistry, named "LSP Object Flag Field", has been created
       within the "Path Computation Element Protocol (PCEP) Numbers"
       registry to manage the Flag field of the LSP object.  New values are
       assigned by Standards Action [RFC8126].  Each bit should be tracked
       with the following qualities:

       o  Bit number (counting from bit 0 as the most significant bit)

       o  Capability description

       o  Defining RFC

       The following values are defined in this document:

                     Bit     Description           Reference
                     ---     --------------------  -------------
                     0-4     Unassigned            This document
                     5-7     Operational (3 bits)  This document
                      8      Administrative        This document
                      9      Remove                This document
                      10     SYNC                  This document
                      11     Delegate              This document

    Crabbe, et al.               Standards Track                   [Page 44]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    8.5.  PCEP-Error Object

       The following error types and error values have been registered
       within the "PCEP-ERROR Object Error Types and Values" subregistry of
       the "Path Computation Element Protocol (PCEP) Numbers" registry:

       Error-Type  Meaning
       ----------  -------------------------------------------------------
          6        Mandatory Object missing

                    Error-value
                    8:   LSP object missing
                    9:   ERO object missing
                    10:  SRP object missing
                    11:  LSP-IDENTIFIERS TLV missing

          19       Invalid Operation

                    Error-value
                    1:   Attempted LSP Update Request for a non-delegated
                         LSP.  The PCEP-ERROR object is followed by the LSP
                         object that identifies the LSP.
                    2:   Attempted LSP Update Request if the stateful PCE
                         capability was not advertised.
                    3:   Attempted LSP Update Request for an LSP identified
                         by an unknown PLSP-ID.
                    5:   Attempted LSP State Report if stateful PCE
                         capability was not advertised.

          20       LSP State Synchronization Error

                    Error-value
                    1:   A PCE indicates to a PCC that it cannot process (an
                         otherwise valid) LSP State Report.  The PCEP-ERROR
                         object is followed by the LSP object that
                         identifies the LSP.
                    5:   A PCC indicates to a PCE that it cannot complete
                         the State Synchronization.

    Crabbe, et al.               Standards Track                   [Page 45]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    8.6.  Notification Object

       The following Notification Types and Notification Values have been
       allocated within the "Notification Object" subregistry of the "Path
       Computation Element Protocol (PCEP) Numbers" registry:

       Notification-Type  Name
       4     Stateful PCE resource limit exceeded

                 Notification-value
                 1:   Entering resource limit exceeded state
                 2:   Deprecated

       Note that the early allocation included an additional Notification
       Value 2 for "Exiting resource limit exceeded state".  This
       Notification Value is no longer required and has been marked as
       "Deprecated".

    8.7.  PCEP TLV Type Indicators

       The following TLV Type Indicator values have been registered within
       the "PCEP TLV Type Indicators" subregistry of the "Path Computation
       Element Protocol (PCEP) Numbers" registry:

                  Value     Description                 Reference
                  -----     -----------------------     -------------
                    16      STATEFUL-PCE-CAPABILITY     This document
                    17      SYMBOLIC-PATH-NAME          This document
                    18      IPV4-LSP-IDENTIFIERS        This document
                    19      IPV6-LSP-IDENTIFIERS        This document
                    20      LSP-ERROR-CODE              This document
                    21      RSVP-ERROR-SPEC             This document

    Crabbe, et al.               Standards Track                   [Page 46]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    8.8.  STATEFUL-PCE-CAPABILITY TLV

       A new subregistry, named "STATEFUL-PCE-CAPABILITY TLV Flag Field",
       has been created within the "Path Computation Element Protocol (PCEP)
       Numbers" registry to manage the Flag field in the STATEFUL-PCE-
       CAPABILITY TLV of the PCEP OPEN object (class = 1).  New values are
       assigned by Standards Action [RFC8126].  Each bit should be tracked
       with the following qualities:

       o  Bit number (counting from bit 0 as the most significant bit)

       o  Capability description

       o  Defining RFC

       The following values are defined in this document:

                   Value  Description              Reference
                   -----  ---------------------    -------------
                     31   LSP-UPDATE-CAPABILITY    This document

    8.9.  LSP-ERROR-CODE TLV

       A new subregistry, named "LSP-ERROR-CODE TLV Error Code Field", has
       been created within the "Path Computation Element Protocol (PCEP)
       Numbers" registry to manage the LSP Error Code field of the LSP-
       ERROR-CODE TLV.  This field specifies the reason for failure to
       update the LSP.

       New values are assigned by Standards Action [RFC8126].  Each value
       should be tracked with the following qualities: value, meaning, and
       defining RFC.  The following values are defined in this document:

                   Value      Meaning
                    ---       -------------------------------------
                     0        Reserved
                     1        Unknown reason
                     2        Limit reached for PCE-controlled LSPs
                     3        Too many pending LSP Update Requests
                     4        Unacceptable parameters
                     5        Internal error
                     6        LSP administratively brought down
                     7        LSP preempted
                     8        RSVP signaling error

    Crabbe, et al.               Standards Track                   [Page 47]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    9.  Manageability Considerations

       All manageability requirements and considerations listed in [RFC5440]
       apply to the PCEP extensions defined in this document.  In addition,
       requirements and considerations listed in this section apply.

    9.1.  Control Function and Policy

       In addition to configuring specific PCEP session parameters, as
       specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST
       allow configuring the stateful PCEP capability and the LSP Update
       capability.  A PCC implementation SHOULD allow the operator to
       specify multiple candidate PCEs for and a delegation preference for
       each candidate PCE.  A PCC SHOULD allow the operator to specify an
       LSP delegation policy where LSPs are delegated to the most-preferred
       online PCE.  A PCC MAY allow the operator to specify different LSP
       delegation policies.

       A PCC implementation that allows concurrent connections to multiple
       PCEs SHOULD allow the operator to group the PCEs by administrative
       domains, and it MUST NOT advertise LSP existence and state to a PCE
       if the LSP is delegated to a PCE in a different group.

       A PCC implementation SHOULD allow the operator to specify whether the
       PCC will advertise LSP existence and state for LSPs that are not
       controlled by any PCE (for example, LSPs that are statically
       configured at the PCC).

       A PCC implementation SHOULD allow the operator to specify both the
       Redelegation Timeout Interval and the State Timeout Interval.  The
       default value of the Redelegation Timeout Interval SHOULD be set to
       30 seconds.  An operator MAY also configure a policy that will
       dynamically adjust the Redelegation Timeout Interval, for example
       setting it to zero when the PCC has an established session to a
       backup PCE.  The default value for the State Timeout Interval SHOULD
       be set to 60 seconds.

       After the expiration of the State Timeout Interval, the LSP reverts
       to operator-defined default parameters.  A PCC implementation MUST
       allow the operator to specify the default LSP parameters.  To achieve
       a behavior where the LSP retains the parameters set by the PCE until
       such time that the PCC makes a change to them, a State Timeout
       Interval of infinity SHOULD be used.  Any changes to LSP parameters
       SHOULD be done in a make-before-break fashion.

       LSP delegation is controlled by operator-defined policies on a PCC.
       LSPs are delegated individually -- different LSPs may be delegated to
       different PCEs.  An LSP is delegated to at most one PCE at any given

    Crabbe, et al.               Standards Track                   [Page 48]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       point in time.  A PCC implementation SHOULD support the delegation
       policy, when all PCC's LSPs are delegated to a single PCE at any
       given time.  Conversely, the policy revoking the delegation for all
       PCC's LSPs SHOULD also be supported.

       A PCC implementation SHOULD allow the operator to specify delegation
       priority for PCEs.  This effectively defines the primary PCE and one
       or more backup PCEs to which a primary PCE's LSPs can be delegated
       when the primary PCE fails.

       Policies defined for stateful PCEs and PCCs should eventually fit in
       the policy-enabled path computation framework defined in [RFC5394],
       and the framework should be extended to support stateful PCEs.

    9.2.  Information and Data Models

       The PCEP YANG module [PCEP-YANG] should include:

       o  advertised stateful capabilities and synchronization status per
          PCEP session.

       o  the delegation status of each configured LSP.

       The PCEP MIB [RFC7420] could also be updated to include this
       information.

    9.3.  Liveness Detection and Monitoring

       PCEP extensions defined in this document do not require any new
       mechanisms beyond those already defined in [RFC5440], Section 8.3.

    9.4.  Verifying Correct Operation

       Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP
       extensions defined in this document.  In addition to monitoring
       parameters defined in [RFC5440], a stateful PCC-side PCEP
       implementation SHOULD provide the following parameters:

       o  Total number of LSP Updates

       o  Number of successful LSP Updates

       o  Number of dropped LSP Updates

       o  Number of LSP Updates where LSP setup failed

       A PCC implementation SHOULD provide a command to show for each LSP
       whether it is delegated, and if so, to which PCE.

    Crabbe, et al.               Standards Track                   [Page 49]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       A PCC implementation SHOULD allow the operator to manually revoke LSP
       delegation.

    9.5.  Requirements on Other Protocols and Functional Components

       PCEP extensions defined in this document do not put new requirements
       on other protocols.

    9.6.  Impact on Network Operation

       Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP
       extensions defined in this document.

       Additionally, a PCEP implementation SHOULD allow a limit to be placed
       on the number of LSPs delegated to the PCE and on the rate of PCUpd
       and PCRpt messages sent by a PCEP speaker and processed from a peer.
       It SHOULD also allow sending a notification when a rate threshold is
       reached.

       A PCC implementation SHOULD allow a limit to be placed on the rate of
       LSP Updates to the same LSP to avoid signaling overload discussed in
       Section 10.3.

    10.  Security Considerations

    10.1.  Vulnerability

       This document defines extensions to PCEP to enable stateful PCEs.
       The nature of these extensions and the delegation of path control to
       PCEs results in more information being available for a hypothetical
       adversary and a number of additional attack surfaces that must be
       protected.

       The security provisions described in [RFC5440] remain applicable to
       these extensions.  However, because the protocol modifications
       outlined in this document allow the PCE to control path computation
       timing and sequence, the PCE defense mechanisms described in
       [RFC5440], Section 7.2 are also now applicable to PCC security.

       As a general precaution, it is RECOMMENDED that these PCEP extensions
       only be activated on authenticated and encrypted sessions across PCEs
       and PCCs belonging to the same administrative authority, using
       Transport Layer Security (TLS) [PCEPS], as per the recommendations
       and best current practices in [RFC7525].

    Crabbe, et al.               Standards Track                   [Page 50]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       The following sections identify specific security concerns that may
       result from the PCEP extensions outlined in this document along with
       recommended mechanisms to protect PCEP infrastructure against related
       attacks.

    10.2.  LSP State Snooping

       The stateful nature of this extension explicitly requires LSP status
       updates to be sent from PCC to PCE.  While this gives the PCE the
       ability to provide more optimal computations to the PCC, it also
       provides an adversary with the opportunity to eavesdrop on decisions
       made by network systems external to PCE.  This is especially true if
       the PCC delegates LSPs to multiple PCEs simultaneously.

       Adversaries may gain access to this information by eavesdropping on
       unsecured PCEP sessions and might then use this information in
       various ways to target or optimize attacks on network infrastructure,
       for example, by flexibly countering anti-DDoS measures being taken to
       protect the network or by determining choke points in the network
       where the greatest harm might be caused.

       PCC implementations that allow concurrent connections to multiple
       PCEs SHOULD allow the operator to group the PCEs by administrative
       domains, and they MUST NOT advertise LSP existence and state to a PCE
       if the LSP is delegated to a PCE in a different group.

    10.3.  Malicious PCE

       The LSP delegation mechanism described in this document allows a PCC
       to grant effective control of an LSP to the PCE for the duration of a
       PCEP session.  While this enables PCE control of the timing and
       sequence of path computations within and across PCEP sessions, it
       also introduces a new attack vector: an attacker may flood the PCC
       with PCUpd messages at a rate that exceeds either the PCC's ability
       to process them or the network's ability to signal the changes, by
       either spoofing messages or compromising the PCE itself.

       A PCC is free to revoke an LSP delegation at any time without needing
       any justification.  A defending PCC can do this by enqueueing the
       appropriate PCRpt message.  As soon as that message is enqueued in
       the session, the PCC is free to drop any incoming PCUpd messages
       without additional processing.

    Crabbe, et al.               Standards Track                   [Page 51]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    10.4.  Malicious PCC

       A stateful session also results in an increased attack surface by
       placing a requirement for the PCE to keep an LSP state replica for
       each PCC.  It is RECOMMENDED that PCE implementations provide a limit
       on resources a single PCC can occupy.  A PCE implementing such a
       limit MUST send a PCNtf message with notification-type 4 (Stateful
       PCE resource limit exceeded) and notification-value 1 (Entering
       resource limit exceeded state) upon receiving an LSP State Report
       causing it to exceed this threshold.

       Delegation of LSPs can create further strain on PCE resources and a
       PCE implementation MAY preemptively give back delegations if it finds
       itself lacking the resources needed to effectively manage the
       delegation.  Since the delegation state is ultimately controlled by
       the PCC, PCE implementations SHOULD provide throttling mechanisms to
       prevent strain created by flaps of either a PCEP session or an LSP
       delegation.

    11.  References

    11.1.  Normative References

       [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119,
                  DOI 10.17487/RFC2119, March 1997,
                  <https://www.rfc-editor.org/info/rfc2119>.

       [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
                  Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
                  Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
                  September 1997, <https://www.rfc-editor.org/info/rfc2205>.

       [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
                  and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                  Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
                  <https://www.rfc-editor.org/info/rfc3209>.

       [RFC5088]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
                  Zhang, "OSPF Protocol Extensions for Path Computation
                  Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
                  January 2008, <https://www.rfc-editor.org/info/rfc5088>.

       [RFC5089]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
                  Zhang, "IS-IS Protocol Extensions for Path Computation
                  Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
                  January 2008, <https://www.rfc-editor.org/info/rfc5089>.

    Crabbe, et al.               Standards Track                   [Page 52]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       [RFC5284]  Swallow, G. and A. Farrel, "User-Defined Errors for RSVP",
                  RFC 5284, DOI 10.17487/RFC5284, August 2008,
                  <https://www.rfc-editor.org/info/rfc5284>.

       [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
                  Element (PCE) Communication Protocol (PCEP)", RFC 5440,
                  DOI 10.17487/RFC5440, March 2009,
                  <https://www.rfc-editor.org/info/rfc5440>.

       [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
                  Used to Form Encoding Rules in Various Routing Protocol
                  Specifications", RFC 5511, DOI 10.17487/RFC5511, April
                  2009, <https://www.rfc-editor.org/info/rfc5511>.

       [RFC8051]  Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
                  Stateful Path Computation Element (PCE)", RFC 8051,
                  DOI 10.17487/RFC8051, January 2017,
                  <https://www.rfc-editor.org/info/rfc8051>.

       [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                  2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                  May 2017, <https://www.rfc-editor.org/info/rfc8174>.

    11.2.  Informative References

       [MPLS-PC]  Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
                  LSP Path Computation using Preemption", Global
                  Information Infrastructure Symposium,
                  DOI 10.1109/GIIS.2007.4404195, July 2007.

       [MXMN-TE]  Danna, E., Mandal, S., and A. Singh, "A practical
                  algorithm for balancing the max-min fairness and
                  throughput objectives in traffic engineering", INFOCOM,
                  2012 Proceedings IEEE, pp. 846-854,
                  DOI 10.1109/INFCOM.2012.6195833, March 2012.

       [PCE-Init-LSP]
                  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
                  Extensions for PCE-initiated LSP Setup in a Stateful PCE
                  Model", Work in Progress,
                  draft-ietf-pce-pce-initiated-lsp-10, June 2017.

       [PCEP-GMPLS]
                  Margaria, C., de Dios, O., and F. Zhang, "PCEP extensions
                  for GMPLS", Work in Progress,
                  draft-ietf-pce-gmpls-pcep-extensions-11, October 2015.

    Crabbe, et al.               Standards Track                   [Page 53]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       [PCEP-YANG]
                  Dhody, D., Hardwick, J., Beeram, V., and j.
                  jefftant@gmail.com, "A YANG Data Model for Path
                  Computation Element Communications Protocol (PCEP)", Work
                  in Progress, draft-ietf-pce-pcep-yang-05, June 2017.

       [PCEPS]    Lopez, D., de Dios, O., Wu, Q., and D. Dhody, "Secure
                  Transport for PCEP", Work in Progress,
                  draft-ietf-pce-pceps-18, September 2017.

       [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
                  McManus, "Requirements for Traffic Engineering Over MPLS",
                  RFC 2702, DOI 10.17487/RFC2702, September 1999,
                  <https://www.rfc-editor.org/info/rfc2702>.

       [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
                  Label Switching Architecture", RFC 3031,
                  DOI 10.17487/RFC3031, January 2001,
                  <https://www.rfc-editor.org/info/rfc3031>.

       [RFC3346]  Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,
                  Christian, B., and W. Lai, "Applicability Statement for
                  Traffic Engineering with MPLS", RFC 3346,
                  DOI 10.17487/RFC3346, August 2002,
                  <https://www.rfc-editor.org/info/rfc3346>.

       [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
                  (TE) Extensions to OSPF Version 2", RFC 3630,
                  DOI 10.17487/RFC3630, September 2003,
                  <https://www.rfc-editor.org/info/rfc3630>.

       [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
                  Element (PCE)-Based Architecture", RFC 4655,
                  DOI 10.17487/RFC4655, August 2006,
                  <https://www.rfc-editor.org/info/rfc4655>.

       [RFC4657]  Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
                  Element (PCE) Communication Protocol Generic
                  Requirements", RFC 4657, DOI 10.17487/RFC4657, September
                  2006, <https://www.rfc-editor.org/info/rfc4657>.

       [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
                  Engineering", RFC 5305, DOI 10.17487/RFC5305, October
                  2008, <https://www.rfc-editor.org/info/rfc5305>.

    Crabbe, et al.               Standards Track                   [Page 54]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

       [RFC5394]  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
                  "Policy-Enabled Path Computation Framework", RFC 5394,
                  DOI 10.17487/RFC5394, December 2008,
                  <https://www.rfc-editor.org/info/rfc5394>.

       [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
                  Hardwick, "Path Computation Element Communication Protocol
                  (PCEP) Management Information Base (MIB) Module",
                  RFC 7420, DOI 10.17487/RFC7420, December 2014,
                  <https://www.rfc-editor.org/info/rfc7420>.

       [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
                  "Recommendations for Secure Use of Transport Layer
                  Security (TLS) and Datagram Transport Layer Security
                  (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
                  2015, <https://www.rfc-editor.org/info/rfc7525>.

       [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                  Writing an IANA Considerations Section in RFCs", BCP 26,
                  RFC 8126, DOI 10.17487/RFC8126, June 2017,
                  <https://www.rfc-editor.org/info/rfc8126>.

       [RFC8232]  Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
                  and D. Dhody, "Optimizations of Label Switched Path State
                  Synchronization Procedures for a Stateful PCE", RFC 8232,
                  DOI 10.17487/RFC8232, September 2017,
                  <http://www.rfc-editor.org/info/rfc8232>.

    Acknowledgements

       We would like to thank Adrian Farrel, Cyril Margaria, and Ramon
       Casellas for their contributions to this document.

       We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto,
       Paul Schultz, and Raveendra Torvi for their comments and suggestions.
       Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga,
       Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky,
       Ambrose Kwong, Ashwin Sampath, Calvin Ying, Mustapha Aissaoui,
       Stephane Litkowski, and Olivier Dugeon for helpful comments and
       discussions.

    Crabbe, et al.               Standards Track                   [Page 55]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    Contributors

       The following people contributed substantially to the content of this
       document and should be considered coauthors:

       Xian Zhang
       Huawei Technology
       F3-5-B R&D Center
       Huawei Industrial Base, Bantian, Longgang District
       Shenzhen, Guangdong 518129
       China
       Email: zhang.xian@huawei.com

       Dhruv Dhody
       Huawei Technology
       Leela Palace
       Bangalore, Karnataka 560008
       INDIA
       Email: dhruv.dhody@huawei.com

       Siva Sivabalan
       Cisco Systems, Inc.
       2000 Innovation Drive
       Kanata, Ontario K2K 3E8
       Canada
       Email: msiva@cisco.com

    Crabbe, et al.               Standards Track                   [Page 56]

    RFC 8231            PCEP Extensions for Stateful PCE      September 2017

    Authors' Addresses

       Edward Crabbe
       Oracle
       1501 4th Ave, suite 1800
       Seattle, WA  98101
       United States of America

       Email: edward.crabbe@oracle.com

       Ina Minei
       Google, Inc.
       1600 Amphitheatre Parkway
       Mountain View, CA  94043
       United States of America

       Email: inaminei@google.com

       Jan Medved
       Cisco Systems, Inc.
       170 West Tasman Dr.
       San Jose, CA  95134
       United States of America

       Email: jmedved@cisco.com

       Robert Varga
       Pantheon Technologies SRO
       Mlynske Nivy 56
       Bratislava  821 05
       Slovakia

       Email: robert.varga@pantheon.tech

    Crabbe, et al.               Standards Track                   [Page 57]