



PCE Working Group                                              R. Gandhi
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                                  B. Wen
Expires: 24 October 2026                                         Comcast
                                                                C. Barth
                                                                     HPE
                                                                D. Dhody
                                                     Huawei Technologies
                                                                A. Stone
                                                                   Nokia
                                                           22 April 2026


 PCEP Extensions for Performance Measurement for SR-TE and MPLS-TE LSPs
                           with Stateful PCE
                         draft-gandhi-pce-pm-12

Abstract

   In certain networks, network performance data such as packet loss,
   delay, and delay variation, as well as bandwidth utilization, are
   critical measures for Traffic Engineering (TE).  These data provide
   operators with the characteristics of their networks for the
   performance evaluation required to provide Service-Level Agreements
   (SLAs).

   Stateful Path Computation Element Communication Protocol (PCEP)
   extensions have been defined for TE LSPs for Segment Routing (SR) and
   RSVP.  This document describes the PCEP extensions for enabling and
   reporting end-to-end performance measurement and liveness detection
   for both PCE-Initiated and PCC-Initiated LSPs for SR-TE over MPLS and
   IPv6 data planes, and MPLS-TE using RSVP to an Active Stateful PCE.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Gandhi, et al.           Expires 24 October 2026                [Page 1]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   This Internet-Draft will expire on 24 October 2026.

Copyright Notice

   Copyright (c) 2026 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Auto-bandwidth Considerations . . . . . . . . . . . . . .   5
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   6
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Measurement Units . . . . . . . . . . . . . . . . . . . .   6
   3.  Overview of the PCEP Extensions . . . . . . . . . . . . . . .   7
     3.1.  Report Thresholds . . . . . . . . . . . . . . . . . . . .   8
   4.  Sub-TLVs for Measurement Attributes . . . . . . . . . . . . .   8
     4.1.  Measurement-Enable sub-TLV  . . . . . . . . . . . . . . .   9
     4.2.  Transmit-Interval sub-TLV . . . . . . . . . . . . . . . .   9
     4.3.  Measurement-Protocol sub-TLV  . . . . . . . . . . . . . .  10
     4.4.  Measurement-Interval sub-TLV  . . . . . . . . . . . . . .  11
     4.5.  Report-Threshold sub-TLV  . . . . . . . . . . . . . . . .  11
     4.6.  Report-Threshold-Percentage sub-TLV . . . . . . . . . . .  12
     4.7.  Report-Interval sub-TLV . . . . . . . . . . . . . . . . .  12
     4.8.  Report-Upper-Lower-Bound sub-TLV  . . . . . . . . . . . .  13
   5.  PCEP Extensions for Delay Measurement . . . . . . . . . . . .  14
     5.1.  Delay Measurement Capability Advertisement  . . . . . . .  14
       5.1.1.  DELAY-MEASUREMENT-CAPABILITY TLV  . . . . . . . . . .  14
     5.2.  DELAY-MEASUREMENT-ATTRIBUTES TLV  . . . . . . . . . . . .  15
       5.2.1.  Delay Measurement Enable  . . . . . . . . . . . . . .  16
       5.2.2.  Delay Measurement Protocol  . . . . . . . . . . . . .  16
       5.2.3.  Delay Measurement Transmit Interval . . . . . . . . .  16
       5.2.4.  Delay Measurement Interval  . . . . . . . . . . . . .  17
       5.2.5.  Delay Measurement Report Threshold  . . . . . . . . .  17
       5.2.6.  Delay Measurement Report Threshold Percentage . . . .  17
       5.2.7.  Delay Measurement Report Interval . . . . . . . . . .  17
       5.2.8.  Delay Measurement Upper Bound and Lower Bound . . . .  17
     5.3.  DELAY-MEASUREMENT Object  . . . . . . . . . . . . . . . .  17



Gandhi, et al.           Expires 24 October 2026                [Page 2]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   6.  PCEP Extensions for Loss Measurement  . . . . . . . . . . . .  20
     6.1.  Loss Measurement Capability Advertisement . . . . . . . .  20
       6.1.1.  LOSS-MEASUREMENT-CAPABILITY TLV . . . . . . . . . . .  21
     6.2.  LOSS-MEASUREMENT-ATTRIBUTES TLV . . . . . . . . . . . . .  22
       6.2.1.  Loss Measurement Enable . . . . . . . . . . . . . . .  23
       6.2.2.  Loss Measurement Protocol . . . . . . . . . . . . . .  23
       6.2.3.  Loss Measurement Transmit Interval  . . . . . . . . .  24
       6.2.4.  Loss Measurement Interval . . . . . . . . . . . . . .  24
       6.2.5.  Loss Measurement Report Threshold . . . . . . . . . .  24
       6.2.6.  Loss Measurement Report Threshold Percentage  . . . .  24
       6.2.7.  Loss Measurement Report Interval  . . . . . . . . . .  24
       6.2.8.  Loss Measurement Upper Bound and Lower Bound  . . . .  24
     6.3.  LOSS-MEASUREMENT Object . . . . . . . . . . . . . . . . .  25
   7.  PCEP Extensions for Bandwidth Utilization . . . . . . . . . .  26
     7.1.  Bandwidth Utilization Capability Advertisement  . . . . .  27
       7.1.1.  BANDWIDTH-UTILIZATION-CAPABILITY TLV  . . . . . . . .  27
     7.2.  BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV . . . . . . . .  28
       7.2.1.  Bandwidth Utilization Measurement Enable  . . . . . .  29
       7.2.2.  Bandwidth Utilization Measurement Interval  . . . . .  29
       7.2.3.  Bandwidth Utilization Report Threshold  . . . . . . .  29
       7.2.4.  Bandwidth Utilization Report Threshold Percentage . .  29
       7.2.5.  Bandwidth Utilization Report Interval . . . . . . . .  29
       7.2.6.  Bandwidth Utilization Upper Bound and Lower Bound . .  29
     7.3.  BANDWIDTH Object For Reporting  . . . . . . . . . . . . .  30
   8.  PCEP Extensions for Liveness Detection Using PM . . . . . . .  30
     8.1.  Liveness Detection Using PM . . . . . . . . . . . . . . .  30
       8.1.1.  LIVENESS-DETECTION-CAPABILITY TLV . . . . . . . . . .  31
     8.2.  LIVENESS-DETECTION-ATTRIBUTES TLV . . . . . . . . . . . .  31
       8.2.1.  Liveness Detection Enable . . . . . . . . . . . . . .  32
       8.2.2.  Liveness Detection Protocol . . . . . . . . . . . . .  32
       8.2.3.  Liveness Detection Transmit Interval  . . . . . . . .  32
       8.2.4.  Liveness Detection Interval . . . . . . . . . . . . .  33
     8.3.  LIVENESS-DETECTION Object . . . . . . . . . . . . . . . .  33
   9.  PCEP Procedures . . . . . . . . . . . . . . . . . . . . . . .  34
     9.1.  MEASUREMENT-ATTRIBUTES TLVs in LSPA Object  . . . . . . .  34
     9.2.  LSP Measurement Notification Using MEASUREMENT Objects  .  34
   10. Scaling Considerations  . . . . . . . . . . . . . . . . . . .  36
     10.1.  Notification for Overwhelmed State . . . . . . . . . . .  36
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  37
   12. Operational Considerations  . . . . . . . . . . . . . . . . .  37
     12.1.  Control of Function and Policy . . . . . . . . . . . . .  37
     12.2.  Information and Data Models  . . . . . . . . . . . . . .  37
     12.3.  Verify Correct Operations  . . . . . . . . . . . . . . .  37
     12.4.  Requirements on Other Protocols  . . . . . . . . . . . .  38
     12.5.  Impact on Network Operations . . . . . . . . . . . . . .  38
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  38
     13.1.  Measurement Capability TLV Types . . . . . . . . . . . .  38
     13.2.  Flag Fields for MEASUREMENT-CAPABILITY TLVs  . . . . . .  38



Gandhi, et al.           Expires 24 October 2026                [Page 3]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


       13.2.1.  Flag Fields for DELAY-MEASUREMENT-CAPABILITY TLV . .  39
       13.2.2.  Flag Fields for LOSS-MEASUREMENT-CAPABILITY TLV  . .  39
     13.3.  MEASUREMENT-ATTRIBUTES TLVs  . . . . . . . . . . . . . .  39
       13.3.1.  The Sub-TLVs for MEASUREMENT-ATTRIBUTES TLVs . . . .  40
       13.3.2.  Flag Fields in Measurement-Enable sub-TLV  . . . . .  40
     13.4.  Measurement Object-Class . . . . . . . . . . . . . . . .  41
       13.4.1.  DELAY-MEASUREMENT Object-Types . . . . . . . . . . .  41
       13.4.2.  LOSS-MEASUREMENT Object-Types  . . . . . . . . . . .  42
       13.4.3.  BANDWIDTH Object-Type  . . . . . . . . . . . . . . .  42
     13.5.  PCE Error Codes  . . . . . . . . . . . . . . . . . . . .  42
     13.6.  Notification Object Types  . . . . . . . . . . . . . . .  43
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  43
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  43
     14.2.  Informative References . . . . . . . . . . . . . . . . .  44
   Appendix A.  Example Use Cases  . . . . . . . . . . . . . . . . .  47
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  50
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  50

1.  Introduction

   [RFC5440] describes the Path Computation Element Protocol (PCEP) as a
   communication mechanism between a Path Computation Client (PCC) and a
   Path Computation Element (PCE), or between PCE and PCE, that enables
   computation of Traffic Engineering Label Switched Paths (TE LSPs).

   [RFC8231] specifies extensions to PCEP to enable stateful control of
   an LSP.  It describes two modes of operation - Passive Stateful PCE
   and Active Stateful PCE.  Further, [RFC8281] describes the setup,
   maintenance, and teardown of PCE-Initiated LSPs for the Stateful PCE
   model.  In this document, the focus is on the Active Stateful PCE
   where the LSPs are controlled by the PCE, for both PCE-Initiated and
   PCC-Initiated LSPs.

   PCEP Extensions for Segment Routing (SR) [RFC8664] specifies
   extensions to the Path Computation Element Protocol (PCEP) that allow
   a stateful PCE to compute and initiate Traffic Engineering (TE)
   paths, as well as a PCC to request a path subject to certain
   constraints and optimization criteria for Segment Routing.  [RFC9603]
   extends PCEP for Segment Routing for the IPv6 data plane.

   In certain networks, such as financial information networks, network
   performance data such as packet loss, delay, and delay variation, and
   bandwidth utilization are critical measures for traffic engineering.
   The protocol extensions have been defined to advertise link
   performance metrics; see [RFC7471], [RFC8570], [RFC7823] and
   [RFC8571].  These data provide operators with the characteristics of
   their networks for performance evaluation that is required to ensure
   the Service-Level Agreements (SLAs).



Gandhi, et al.           Expires 24 October 2026                [Page 4]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   [RFC8233] defines the PCEP extensions for LSP path computation using
   packet loss, delay, and delay variation as path selection metrics.
   Such path computations use link metrics for packet loss and delay and
   do not provide end-to-end metrics of the TE LSPs.  The end-to-end
   metrics of an LSP may be very different from the path computation
   results due to many factors, such as queuing, etc.  There is a need
   to monitor whether the traffic sent over the established LSPs exceeds
   the requested metric bounds such as end-to-end delay and loss.  The
   Stateful PCE may need to take some action (such as tearing down or
   re-optimizing the LSP) when the performance requirement is not met.
   [RFC8762] defines protocol extensions needed for measuring packet
   loss, delay, and delay variation and can be used for end-to-end
   performance measurement of an LSP.

   This document describes PCEP extensions for enabling and reporting
   end-to-end performance measurement (PM) such as packet loss, delay,
   delay variation, bandwidth utilization, as well as liveness detection
   for both PCE-Initiated and PCC-Initiated LSPs for SR-TE over MPLS and
   IPv6 data planes and MPLS-TE using RSVP to an Active Stateful PCE.

   Note that the specification of the use of the reported packet loss,
   delay, and delay variation measurements, bandwidth utilization, and
   liveness detection by a Stateful PCE is outside the scope of this
   document.

1.1.  Auto-bandwidth Considerations

   The auto-bandwidth feature allows a head-end LSR PCC to automatically
   adjust the LSP bandwidth reservation based on the traffic demand of
   an LSP.  The auto-bandwidth requested bandwidth computation can be
   implemented on a PCC or a Stateful PCE.

   [RFC8733] describes the PCEP extensions for auto-bandwidth, where the
   requested bandwidth for the LSP is computed by the PCC and reported
   to the Stateful PCE.  There is a benefit in pushing the
   responsibility for deciding when auto-bandwidth adjustments are
   needed to the PCC as this distributes the load of monitoring the
   bandwidth utilization of the LSPs down to the PCCs and frees up the
   PCE for path computations.  In addition, it reduces the load on PCEP
   communications for reporting the bandwidth utilization of the LSP.

   However, exactly when to adjust an LSP bandwidth could be better left
   to a Stateful PCE.  That is, a PCE could be flexible in its
   interpretation of thresholds enabling it to trigger auto-bandwidth
   adjustment early if it believes there is a good reason (for example,
   performing a set of parallel path recomputations) or late (for
   example, when it knows that an adjustment would be disruptive to the
   network).  When the auto-bandwidth computation is delegated to the



Gandhi, et al.           Expires 24 October 2026                [Page 5]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   PCC, the PCC cannot see the impact on other LSPs in the network, and
   the PCE cannot tell whether the request to adjust the LSP bandwidth
   is critical or not.  The bandwidth utilization reporting defined in
   this document can be used by the PCE to do computations to determine
   whether auto-bandwidth adjustments are needed or desirable before
   performing the path computations.

2.  Conventions Used in This Document

2.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.2.  Terminology

   The reader is assumed to be familiar with the terminology defined in
   [RFC5440], [RFC8231], [RFC8281], [RFC8408], and [RFC7471].

   This document extends the following term defined in [RFC3031]: Label
   Switched Path (LSP), while the base PCEP specification [RFC4655]
   originally defined the PCE architecture for MPLS and GMPLS networks
   with LSPs instantiated using the RSVP-TE signaling protocol.  As
   specified in the Terminology Section of [RFC9603], the term "LSP"
   used in the PCEP specifications would be equivalent to an SRv6 path
   (represented as a list of SRv6 segments) in the context of supporting
   SRv6 in PCEP using the SRv6 Path Setup Type.

2.3.  Measurement Units

   The measurement unit for the delay value is defined in [RFC7471],
   Section 4.1.5.

   The measurement unit for the loss value is defined in [RFC7471],
   Section 4.4.5.

   The utilized bandwidth [RFC7471] is encoded in IEEE floating-point
   format in bytes per second as described in [IEEE.754.1985].

   All average values are calculated as rolling averages.








Gandhi, et al.           Expires 24 October 2026                [Page 6]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


3.  Overview of the PCEP Extensions

   The high-level overview of the PCEP extensions defined in this
   document for requesting and reporting end-to-end performance
   measurement, bandwidth utilization, and liveness detection of the
   LSPs for SR-TE over MPLS and IPv6 data planes as well as MPLS-TE
   using RSVP is shown in Figure 1.

                           ---------
                          |         |
                          | Stateful|
                          |   PCE   |
                          |         |
                           ---------
                             |    ^
     MEASUREMENT CAPABILITY  |    |  MEASUREMENT CAPABILITY
                             |    |
     MEASUREMENT ATTRIBUTES  |    |  MEASUREMENT ATTRIBUTES
                             |    |  (For delegated LSPs)
                             |    |
                             |    |  MEASUREMENT REPORTS
                             v    |     (Optional)
                           ---------
                          |         |
                          |   PCC   |
                          |         |
                           ---------

                 Figure 1: Overview of the PCEP Extensions

   The following list provides the high-level overview of the PCEP
   extensions defined in this document:

   *  The Stateful PCE and PCC (head-end of the LSP) advertise the
      capability of their support for the delay and loss measurements,
      bandwidth-utilization, and liveness detection in the PCEP Open
      message (in the OPEN Object).

   *  The Stateful PCE enables measurement of a feature and sends or
      updates the attributes of the feature using the LSPA object to the
      PCC in PCInitiate and PCUpd messages, respectively.

   *  The PCC reports the measured metrics of the feature to the
      Stateful PCE at the end of the specified interval or when measured
      values cross a specified threshold.  Periodic reporting can be
      used by the PCE to monitor the LSP metrics, whereas a threshold
      can be used to trigger an immediate action by the PCE on the LSP.




Gandhi, et al.           Expires 24 October 2026                [Page 7]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   *  The optional periodic reporting of the measurements may be
      disabled to avoid processing load on the PCE and only an upper
      bound threshold is used to detect an anomaly, which when exceeded,
      a local or PCE-set action may be taken on the PCC.

   *  The PCE and PCC notify each other of their entering and clearing
      the overwhelmed state when operating under high LSP scale.

3.1.  Report Thresholds

   When explicitly configured, a report threshold (absolute or
   percentage) parameter is used to trigger an immediate reporting of
   the delay and loss metrics and bandwidth utilization, bypassing the
   periodic report interval.  A threshold is used to detect a sudden
   change in the performance measurement metric of an LSP.  In order to
   detect that a measured value has crossed the threshold, the measured
   (delay/loss) metric is compared with the previously reported value.
   If the change (increase or decrease) in the value is above the
   threshold (absolute or percentage), the measurement from the current
   interval is reported immediately.

   All thresholds in this document could be represented in both absolute
   values and percentages, and could be used together.  This is provided
   to accommodate the cases where the metric values may become very
   large or very small over time.  For example, an operator may use the
   percentage threshold to handle small to large metric values and
   absolute values to handle very large metric values.  The metrics are
   reported when either one of the two thresholds, the absolute or the
   percentage, is crossed.

   When using the percentage threshold, if the metric changes rapidly at
   very low values, it may trigger frequent reporting due to the
   crossing of the percentage threshold.  This can lead to unnecessary
   scale issues in the network.  This is suppressed by setting the
   minimum-threshold parameter along with the percentage threshold.  The
   metric value is only reported if the value crosses both the
   percentage threshold and the minimum-threshold parameters.

   The metrics are still reported at the end of the report interval even
   if they were reported due to the threshold crossing.  Refer to
   [RFC7471], Section 5, for additional considerations.

4.  Sub-TLVs for Measurement Attributes

   This section specifies the generic sub-TLVs that provide various
   configurable parameters for reporting measurement to a Stateful PCE.
   These sub-TLVs are carried in various measurement attributes TLVs
   defined in this document.



Gandhi, et al.           Expires 24 October 2026                [Page 8]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   The following sub-TLVs are defined:

    Type   Length   Name
    -------------------------------------------------------
    1      4        Measurement-Enable sub-TLV
    2      4        Transmit-Interval sub-TLV
    3      8        Measurement-Protocol sub-TLV
    4      4        Measurement-Interval sub-TLV
    5      8        Report-Threshold sub-TLV
    6      8        Report-Threshold-Percentage sub-TLV
    7      4        Report-Interval sub-TLV
    8      8        Report-Upper-Lower-Bound sub-TLV

   The Measurement-Enable sub-TLV MUST be added to the LSPA Object when
   the measurement feature is enabled for the LSP.  All other sub-TLVs
   are optional and any unrecognized sub-TLV MUST be silently ignored.
   If a sub-TLV of the same type appears more than once, only the first
   occurrence is processed and all others MUST be ignored.  If sub-TLVs
   are not present, the default values based on the local policy are
   assumed.

4.1.  Measurement-Enable sub-TLV

   The Measurement-Enable sub-TLV specifies that the given measurement
   feature is enabled.  The format of this sub-TLV is shown in Figure 2.

     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=1              |           Length=4            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Flags                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: Measurement-Enable sub-TLV Format

   The Type is 1, Length is 4 bytes, and the value comprises flags (32
   bits) for enabling various measurement features.

   Unassigned flags are considered reserved, they MUST be set to 0 when
   sent and MUST be ignored when received.  The flags define various
   performance measurement types in this document.

4.2.  Transmit-Interval sub-TLV

   The Transmit-Interval sub-TLV specifies a time interval in
   milliseconds for the test packet transmission.  The format of this
   sub-TLV is shown in Figure 3.



Gandhi, et al.           Expires 24 October 2026                [Page 9]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


     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=2              |           Length=4            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Transmit-Interval                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: Transmit-Interval sub-TLV Format

   The Type is 2, Length is 4 bytes, and the value comprises a 4-byte
   time interval, the valid range is from 1 to 604800, in milliseconds.
   The default value is 1 second.  The Transmit-Interval MUST NOT be
   greater than the Measurement-Interval and the Report-Interval.

4.3.  Measurement-Protocol sub-TLV

   The Measurement-Protocol sub-TLV specifies that the given measurement
   protocol type and mode are enabled.  The format of this sub-TLV is
   shown in Figure 4.

     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=3              |           Length=8            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Measurement-Protocol                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Measurement-Mode                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: Measurement-Protocol sub-TLV Format

   The Type is 3, Length is 8 bytes, and the value comprises the
   protocol type and mode for performance measurement.

   The measurement protocol type value can be set to: (1) STAMP protocol
   [RFC8762], or (2) TWAMP protocol [RFC5357], or (3) MPLS-PM protocol
   [RFC6374].

   Measurement mode can be set to: (1) One-Way, or (2) Two-Way, or (3)
   Loopback.









Gandhi, et al.           Expires 24 October 2026               [Page 10]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   The performance measurement procedures using STAMP defined in
   [I-D.ietf-spring-stamp-srpm-srv6] and
   [I-D.ietf-spring-stamp-srpm-mpls] can be used for SR LSPs for the
   IPv6 and MPLS data planes, respectively.  Similarly, the performance
   measurement procedures using MPLS-PM defined in [RFC9779] can be used
   for MPLS LSPs.

4.4.  Measurement-Interval sub-TLV

   The Measurement-Interval sub-TLV specifies a time interval in seconds
   for the measurement.  The format of this sub-TLV is shown in
   Figure 5.

     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=4              |           Length=4            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Measurement-Interval                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 5: Measurement-Interval sub-TLV Format

   The Type is 4, Length is 4 bytes, and the value comprises a 4-byte
   time interval, the valid range is from 1 to 604800, in seconds.  The
   default value is 300 seconds.  The Measurement-Interval MUST NOT be
   greater than the Report-Interval.

4.5.  Report-Threshold sub-TLV

   The Report-Threshold sub-TLV specifies the threshold value used to
   trigger an immediate reporting of the measurements bypassing the
   report-interval.  The format of this sub-TLV is shown in Figure 6.

     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=5              |           Length=4            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Report-Threshold                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 6: Report-Threshold sub-TLV Format

   The Type is 5, Length is 8 bytes, and the value comprises:






Gandhi, et al.           Expires 24 October 2026               [Page 11]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   *  Report-Threshold: 32-bit absolute threshold value.  By default,
      report-threshold is not set and threshold check based reporting is
      disabled.

4.6.  Report-Threshold-Percentage sub-TLV

   The Report-Threshold-Percentage sub-TLV specifies the threshold value
   used to trigger an immediate reporting of the measurements bypassing
   the report-interval.  The format of this sub-TLV is shown in
   Figure 7.

     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=6              |           Length=8            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Percentage |          RESERVED                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Minimum-Threshold                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 7: Report-Threshold-Percentage sub-TLV Format

   The Type is 6, Length is 8 bytes, and the value comprises:

   *  Percentage: 7-bit threshold value, encoded in percentage as an
      integer from 1 to 100.

      By default, report-threshold-percentage is not set and threshold
      check based reporting is disabled.

   *  RESERVED: It MUST be set to zero when sent and MUST be ignored
      when received.

   *  Minimum-Threshold: The 32-bit absolute Minimum-Threshold value.
      The increase or decrease should be at least or above this value.

4.7.  Report-Interval sub-TLV

   The Report-Interval sub-TLV specifies the time interval in seconds
   when measured values are to be reported.  The format of this sub-TLV
   is shown in Figure 8.









Gandhi, et al.           Expires 24 October 2026               [Page 12]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


     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=7              |           Length=4            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Report-Interval                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 8: Report-Interval sub-TLV Format

   The Type is 7, Length is 4 bytes, and the value comprises a 4-byte
   time interval, the valid range is from 0 to 604800, in seconds.  The
   default value is 3600 seconds.  The value 0 is used to disable the
   periodic reporting of the measurements.

4.8.  Report-Upper-Lower-Bound sub-TLV

   The Report-Upper-Lower-Bound sub-TLV specifies the upper bound value
   and lower bound value used to trigger an immediate reporting of the
   measurements when crossed.  This may also result in the PCC taking an
   immediate local action on the LSP.  The format of this sub-TLV is
   shown in Figure 9.

   The anomaly flag is set to true in the reported measurement when the
   upper bound threshold is crossed in the up direction and set to false
   in the reported measurement when the lower bound threshold is crossed
   in the down direction.

     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=8              |           Length=8            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Report-Upper-Bound                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Report-Lower-Bound                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 9: Report-Upper-Lower-Bound sub-TLV Format

   The Type is 8, Length is 8 bytes, and the value comprises:

   *  Report-Upper-Bound: 32-bit absolute value.

      By default, upper bound is not set.

   *  Report-Lower-Bound: 32-bit absolute value.




Gandhi, et al.           Expires 24 October 2026               [Page 13]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


      By default, lower bound is not set.  The lower bound value MUST be
      less than the upper bound value.

5.  PCEP Extensions for Delay Measurement

5.1.  Delay Measurement Capability Advertisement

   During the PCEP Initialization phase, PCEP Speakers (PCE or PCC)
   advertise their support for DELAY-MEASUREMENT.  A PCEP Speaker (PCE
   or PCC) includes the DELAY-MEASUREMENT-CAPABILITY TLV in the OPEN
   Object to advertise its support for PCEP Delay-Measurement
   extensions.  The presence of the DELAY-MEASUREMENT-CAPABILITY TLV in
   the OPEN Object (in the Open message) indicates that the Delay
   Measurement capability is supported as described in this document.
   Additional procedures are defined as follows:

   *  The PCEP protocol extensions for Delay Measurement MUST NOT be
      used if one or both PCEP Speakers have not included the DELAY-
      MEASUREMENT-CAPABILITY TLV in their respective Open message.

   *  If a PCEP speaker supports the extensions of this document but did
      not advertise this capability, then upon receipt of the DELAY-
      MEASUREMENT-ATTRIBUTES TLV in the LSPA object, it SHOULD generate
      a PCErr with error-type 19 (Invalid Operation), error-value TBD21
      (Delay-Measurement capability was not advertised) and terminate
      the PCEP session.

   *  Similarly, the PCEP speaker SHOULD generate error-value TBD23
      (Two-Way Measurement capability was not advertised), TBD24 (One-
      Way Measurement capability was not advertised) and TBD25 (Loopback
      Measurement capability was not advertised) upon receipt of the
      DELAY-MEASUREMENT-ATTRIBUTES TLV in the LSPA object with Two-Way,
      One-Way, and Loopback request, respectively, when it did not
      advertise this capability.

   *  If a PCEP speaker supports the extensions of this document but did
      not advertise this capability, then upon receipt of the DELAY-
      MEASUREMENT object, it SHOULD generate a PCErr with error-type 19
      (Invalid Operation), error-value TBD21 (Delay-Measurement
      capability was not advertised) and terminate the PCEP session.

5.1.1.  DELAY-MEASUREMENT-CAPABILITY TLV

   The DELAY-MEASUREMENT-CAPABILITY TLV is an optional TLV for use in
   the OPEN Object for Delay Measurement via PCEP capability
   advertisement.  The format of this TLV is shown in Figure 10.





Gandhi, et al.           Expires 24 October 2026               [Page 14]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       PCEP TLV Type=TBD1      |           Length=4            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Flags                       |L|T|O|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 10: DELAY-MEASUREMENT-CAPABILITY TLV Format

   The Type of the TLV is TBD1 and it has a fixed length of 4 bytes.

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

   *  O (One-way Delay Metric - 1 bit): if set to 1 by a PCC, the O Flag
      indicates that the PCC allows reporting of one-way delay metric
      information; if set to 1 by a PCE, the O Flag indicates that the
      PCE is capable of receiving one-way delay metric information from
      the PCC.

   *  T (Two-way Delay Metric - 1 bit): if set to 1 by a PCC, the T Flag
      indicates that the PCC allows reporting of two-way delay metric
      information; if set to 1 by a PCE, the T Flag indicates that the
      PCE is capable of receiving two-way delay metric information from
      the PCC.

   *  L (Loopback Delay Metric - 1 bit): if set to 1 by a PCC, the L
      Flag indicates that the PCC allows reporting of loopback delay
      metric information; if set to 1 by a PCE, the L Flag indicates
      that the PCE is capable of receiving loopback delay metric
      information from the PCC.

   Unassigned bits are considered reserved.  They MUST be set to 0 when
   sent and MUST be ignored when received.

   Advertisement of the DELAY-MEASUREMENT-CAPABILITY TLV implies support
   for delay measurement, as well as the objects, TLVs and procedures
   defined in this document.  Either the O, T or L flag MUST be set to 1
   in the TLV.

5.2.  DELAY-MEASUREMENT-ATTRIBUTES TLV

   The DELAY-MEASUREMENT-ATTRIBUTES TLV provides the configurable
   parameters of the delay measurement feature.

   The format of the DELAY-MEASUREMENT-ATTRIBUTES TLV is shown in
   Figure 11.




Gandhi, et al.           Expires 24 October 2026               [Page 15]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       PCEP TLV Type=TBD5      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                           sub-TLVs                          //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 11: DELAY-MEASUREMENT-ATTRIBUTES TLV Format

   PCEP TLV Type is defined as follows:

    Type      Name
    ----------------------------------------------------------
    TBD5      DELAY-MEASUREMENT-ATTRIBUTES

   Length: The Length field defines the length of the value portion in
   bytes, as per [RFC5440].

   Value: Comprises of one or more sub-TLVs as described in Section 4 of
   this document.

   The following sub-sections describe the parameters that are currently
   defined to be carried within this TLV.  Any other parameters not
   defined for this TLV MUST be ignored.

5.2.1.  Delay Measurement Enable

   The Measurement-Enable sub-TLV specifies the delay metric mode
   enabled using the following flags:

    Bit     Description
    ----------------------------------------------------------------
    31      One-Way Delay Metric Enabled
    30      Two-Way Delay Metric Enabled
    29      Loopback Delay Metric Enabled

5.2.2.  Delay Measurement Protocol

   The Measurement-Protocol sub-TLV specifies that the given protocol
   type and mode are enabled for delay measurement.

5.2.3.  Delay Measurement Transmit Interval

   The Transmit-Interval sub-TLV specifies a time interval in
   milliseconds for the delay measurement test packet transmission.



Gandhi, et al.           Expires 24 October 2026               [Page 16]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


5.2.4.  Delay Measurement Interval

   The Measurement-Interval sub-TLV specifies a time interval in seconds
   for the delay metrics computation for the LSP.

5.2.5.  Delay Measurement Report Threshold

   The Report-Threshold sub-TLV specifies the threshold value used to
   trigger an immediate reporting of the delay metrics bypassing the
   report-interval.

   *  Report-Threshold: Delay in microseconds, encoded as a 24-bit
      integer, as defined in [RFC7471].

   The same report-threshold is used for all delay metric values.

5.2.6.  Delay Measurement Report Threshold Percentage

   The Report-Threshold-Percentage sub-TLV specifies the threshold value
   used to trigger an immediate reporting of the metrics bypassing the
   report-interval.

   The same report-threshold-percentage is used for all delay metric
   values.

5.2.7.  Delay Measurement Report Interval

   The Report-Interval sub-TLV specifies the time interval in seconds
   when measured delay values are to be reported.

5.2.8.  Delay Measurement Upper Bound and Lower Bound

   The Report-Upper-Lower-Bound sub-TLV specifies the upper bound (for
   going up direction) and lower bound (for going down direction) delay
   values in microseconds, and is used to trigger an immediate reporting
   of the delay values when crossed.  This may also result in the PCC
   taking an immediate local action on the LSP.

5.3.  DELAY-MEASUREMENT Object

   The DELAY-MEASUREMENT Object with Object-Class (Value TBD9) is
   defined in this document to report the delay measurement of an LSP.
   The format of this Object is shown in Figure 12.








Gandhi, et al.           Expires 24 October 2026               [Page 17]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   When the LSP is enabled with the delay measurement feature, the PCC
   SHOULD include the DELAY-MEASUREMENT Object to report the measured
   delay values to the PCE.  The PCC SHOULD report average delay, min/
   max delay, and delay variations to the PCE, as well as the anomaly
   state in the Anomaly (A) flag based on the attributes signaled.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Class=TBD9    |   OT  |Res|P|I|   Object Length (bytes)       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                        (Object body)                        //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 12: DELAY-MEASUREMENT Object Format

   Object Length (16 bits): Specifies the total object length including
   the header, in bytes, as per [RFC5440].

   Object-Types (OT) are defined as follows:

    Object-Type  Length   Name
    ----------------------------------------------------------------
    1            8        Delay Measurement Status
    2            8        One-Way Delay Metric Value
    3            12       One-Way Delay Metric Min/Max Values
    4            8        One-Way Delay Variation Metric Value
    5            8        Two-Way Delay Metric Value
    6            12       Two-Way Delay Metric Min/Max Values
    7            8        Two-Way Delay Variation Metric Value
    8            8        Loopback Delay Metric Value
    9            12       Loopback Delay Metric Min/Max Values
    10           8        Loopback Delay Variation Metric Value

   All delay values are reported in microseconds, encoded as a 24-bit
   integer, as defined in [RFC7471].  When set to the maximum value
   16,777,215 (16.777215 sec), the delay is at least that value and may
   be larger.

   The object body formats are defined as shown in Figure 13, Figure 14,
   Figure 15, and Figure 16.








Gandhi, et al.           Expires 24 October 2026               [Page 18]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     RESERVED                                  |  Status       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 13: DELAY-MEASUREMENT Object For Delay Measurement Status

   *  Delay Measurement Status: Indicates the Status of Delay
      Measurement as: (1) Active, (2) Failed, (3) Errored.

   *  RESERVED: This field is reserved for future use.  It MUST be set
      to 0 when sent and MUST be ignored when received.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|   RESERVED  |            Delay Value Average                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 14: DELAY-MEASUREMENT Object For One-Way, Two-Way and
                              Loopback Average

   *  One-way Delay Value Average: Average Delay of the LSP in one
      (forward) direction.

   *  Two-way Delay Value Average: Average Delay of the LSP in both
      forward and reverse directions.

   *  Loopback Delay Value Average: Average Delay of the LSP in both
      forward and reverse directions.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|   RESERVED  |            Delay Value Minimum                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|   RESERVED  |            Delay Value Maximum                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 15: DELAY-MEASUREMENT Object For One-Way, Two-Way and
                              Loopback Min/Max

   *  One-Way Delay Value Minimum/Maximum: Minimum and Maximum values of
      the Delay of the LSP in one (forward) direction.

   *  Two-Way Delay Value Minimum/Maximum: Minimum and Maximum values of
      the Delay of the LSP in both forward and reverse directions.



Gandhi, et al.           Expires 24 October 2026               [Page 19]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   *  Loopback Delay Value Minimum/Maximum: Minimum and Maximum values
      of the Delay of the LSP in both forward and reverse directions.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|   RESERVED  |            Delay Variation Value              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 16: DELAY-MEASUREMENT Object For One-Way, Two-Way and
                             Loopback Variation

   *  One-way Delay Variation Value: Average Delay Variation of the LSP
      in the forward direction.

   *  Two-way Delay Variation Value: Average Delay Variation of the LSP
      in both forward and reverse directions.

   *  Loopback Delay Variation Value: Average Delay Variation of the LSP
      in both forward and reverse directions.

6.  PCEP Extensions for Loss Measurement

6.1.  Loss Measurement Capability Advertisement

   During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
   advertise their support for LOSS-MEASUREMENT.  A PCEP Speaker
   includes the LOSS-MEASUREMENT-CAPABILITY TLV in the OPEN Object to
   advertise its support for PCEP Loss-Measurement extensions.  The
   presence of the LOSS-MEASUREMENT-CAPABILITY TLV in the OPEN Object
   (in the Open message) indicates that the Loss Measurement capability
   is supported as described in this document.  Additional procedures
   are defined as follows:

   *  The PCEP protocol extensions for Loss Measurement MUST NOT be used
      if one or both PCEP Speakers have not included the LOSS-
      MEASUREMENT-CAPABILITY TLV in their respective Open message.

   *  If a PCEP speaker supports the extensions of this document but did
      not advertise this capability, then upon receipt of the LOSS-
      MEASUREMENT-ATTRIBUTES TLV in the LSPA object, it SHOULD generate
      a PCErr with error-type 19 (Invalid Operation), error-value TBD22
      (Loss-Measurement capability was not advertised) and terminate the
      PCEP session.

   *  Similarly, the PCEP speaker SHOULD generate error-value TBD23
      (Two-Way Measurement capability was not advertised), TBD24 (One-
      Way Measurement capability was not advertised) and TBD25 (Loopback



Gandhi, et al.           Expires 24 October 2026               [Page 20]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


      Measurement capability was not advertised) upon receipt of the
      LOSS-MEASUREMENT-ATTRIBUTES TLV in the LSPA object with two-way,
      one-way and loopback measurement request, respectively, when it
      did not advertise this capability.

   *  Further, the PCEP speaker SHOULD generate error-value TBD26
      (Inferred Mode Loss Measurement capability was not advertised) and
      TBD27 (Direct Mode Loss Measurement capability was not advertised)
      upon receipt of the LOSS-MEASUREMENT-ATTRIBUTES TLV in the LSPA
      object with Inferred Mode loss measurement request and Direct Mode
      loss measurement request, respectively, when it did not advertise
      this capability.

   *  If a PCEP speaker supports the extensions of this document but did
      not advertise this capability, then upon receipt of the LOSS-
      MEASUREMENT object, it SHOULD generate a PCErr with error-type 19
      (Invalid Operation), error-value TBD22 (Loss-Measurement
      capability was not advertised) and terminate the PCEP session.

6.1.1.  LOSS-MEASUREMENT-CAPABILITY TLV

   The LOSS-MEASUREMENT-CAPABILITY TLV is an optional TLV for use in the
   OPEN Object for Loss Measurement via PCEP capability advertisement.
   Its format is shown in Figure 17.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       PCEP TLV Type=TBD2      |           Length=4            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Flags                   |N|I|L|T|O|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 17: LOSS-MEASUREMENT-CAPABILITY TLV Format

   The Type of the TLV is TBD2 and it has a fixed length of 4 bytes.

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

   *  O (One-Way Metric - 1 bit): if set to 1 by a PCC, the O Flag
      indicates that the PCC allows reporting of one-way loss metric
      information; if set to 1 by a PCE, the O Flag indicates that the
      PCE is capable of receiving one-way loss metric information from
      the PCC.







Gandhi, et al.           Expires 24 October 2026               [Page 21]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   *  T (Two-Way Metric - 1 bit): if set to 1 by a PCC, the T Flag
      indicates that the PCC allows reporting of two-way loss metric
      information; if set to 1 by a PCE, the T Flag indicates that the
      PCE is capable of receiving two-way loss metric information from
      the PCC.

   *  L (Loopback Metric - 1 bit): if set to 1 by a PCC, the L Flag
      indicates that the PCC allows reporting of loopback loss metric
      information; if set to 1 by a PCE, the L Flag indicates that the
      PCE is capable of receiving loopback loss metric information from
      the PCC.

   *  I (Inferred Loss Measurement Mode - 1 bit): if set to 1 by a PCC,
      the I Flag indicates that the PCC allows reporting of inferred
      mode loss measurement information; if set to 1 by a PCE, the I
      Flag indicates that the PCE is capable of receiving inferred mode
      loss measurement information from the PCC.

   *  N (Direct Loss Measurement Mode - 1 bit): if set to 1 by a PCC,
      the N Flag indicates that the PCC allows reporting of direct mode
      loss measurement information; if set to 1 by a PCE, the N Flag
      indicates that the PCE is capable of receiving direct mode loss
      measurement information from the PCC.

   Unassigned bits are considered reserved.  They MUST be set to 0 when
   sent and MUST be ignored when received.

   Advertisement of the LOSS-MEASUREMENT-CAPABILITY TLV implies support
   for loss measurement, as well as the objects, TLVs and procedures
   defined in this document.  Either the O, T or L flag MUST be set to 1
   in the TLV.  Similarly, either the I or N flag MUST be set to 1 in
   the TLV.

6.2.  LOSS-MEASUREMENT-ATTRIBUTES TLV

   The LOSS-MEASUREMENT-ATTRIBUTES TLV provides the configurable
   parameters of the loss measurement feature.

   The format of the LOSS-MEASUREMENT-ATTRIBUTES TLV is shown in
   Figure 18.











Gandhi, et al.           Expires 24 October 2026               [Page 22]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       PCEP TLV Type=TBD6      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                           sub-TLVs                          //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 18: LOSS-MEASUREMENT-ATTRIBUTES TLV Format

   PCEP TLV Type is defined as follows:

    Type      Name
    ----------------------------------------------------------
    TBD6      LOSS-MEASUREMENT-ATTRIBUTES

   Length: The Length field defines the length of the value portion in
   bytes, as per [RFC5440].

   Value: Comprises of one or more sub-TLVs as described in Section 4 of
   this document.

   The following sub-sections describe the parameters that are currently
   defined to be carried within this TLV.  Any other parameters not
   defined for this TLV MUST be ignored.

6.2.1.  Loss Measurement Enable

   The Measurement-Enable sub-TLV specifies the loss metric mode enabled
   using the following flags:

    Bit      Description
    -----------------------------------------------------------------
    28       One-Way Loss Metric Enabled
    27       Two-Way Loss Metric Enabled
    26       Loopback Loss Metric Enabled
    25       Inferred Loss Metric Enabled
    24       Direct Loss Metric Enabled

6.2.2.  Loss Measurement Protocol

   The Measurement-Protocol sub-TLV specifies that the given protocol
   type and mode are enabled for loss measurement.






Gandhi, et al.           Expires 24 October 2026               [Page 23]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


6.2.3.  Loss Measurement Transmit Interval

   The Transmit-Interval sub-TLV specifies a time interval in
   milliseconds for the loss measurement test packet transmission.

6.2.4.  Loss Measurement Interval

   The Measurement-Interval sub-TLV specifies a time interval in seconds
   for the loss metric computation for the LSP.

6.2.5.  Loss Measurement Report Threshold

   The Report-Threshold sub-TLV specifies the threshold value used to
   trigger an immediate reporting of the loss metrics bypassing the
   report-interval.

   *  Report-Threshold: This 24-bit field identifies the packet loss as
      a percentage of the total packets sent or received.  The encoding
      is as per [RFC7471].

   The same report-threshold is used for all loss metric values.

6.2.6.  Loss Measurement Report Threshold Percentage

   The Report-Threshold-Percentage sub-TLV specifies the threshold value
   used to trigger an immediate reporting of the loss metrics bypassing
   the report-interval.

   The same report-threshold-percentage is used for all loss metric
   values.

6.2.7.  Loss Measurement Report Interval

   The Report-Interval sub-TLV specifies the time interval in seconds
   when measured loss values are to be reported.

6.2.8.  Loss Measurement Upper Bound and Lower Bound

   The Report-Upper-Lower-Bound sub-TLV specifies the upper bound (for
   going up direction) and lower bound (for going down direction) values
   in percentage packet loss, and is used to trigger an immediate
   reporting of the packet loss values when crossed.  This may also
   result in the PCC taking an immediate local action on the LSP.








Gandhi, et al.           Expires 24 October 2026               [Page 24]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


6.3.  LOSS-MEASUREMENT Object

   The LOSS-MEASUREMENT Object with Object-Class (Value TBD10) is
   defined in this document to report the packet loss measurement of an
   LSP.  The format of this Object is shown in Figure 19.

   When the LSP is enabled with the loss measurement feature, the PCC
   SHOULD include the LOSS-MEASUREMENT Object to report the measured
   packet loss to the PCE, as well as the anomaly state in the Anomaly
   (A) flag.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Class=TBD10   |   OT  |Res|P|I|   Object Length (bytes)       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                        (Object body)                        //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 19: LOSS-MEASUREMENT Object Format

   Object Length (16 bits): Specifies the total object length including
   the header in bytes, as per [RFC5440].

   Object-Types (OT) are defined as follows:

    Object-Type  Length   Name
    -------------------------------------------------------------
    1            8        Loss Measurement Status
    2            8        Tx Packets-Lost
    3            8        Rx Packets-Lost
    4            12       Total Packets-Sent-Received

   The object body format for Loss Measurement Status is shown in
   Figure 20.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     RESERVED                                  |  Status       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 20: LOSS-MEASUREMENT Object For Loss Measurement Status

   *  Loss Measurement Status: Indicates the Status of Loss Measurement
      as: (1) Active, (2) Failed, (3) Errored.



Gandhi, et al.           Expires 24 October 2026               [Page 25]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   *  RESERVED: This field is reserved for future use.  It MUST be set
      to 0 when sent and MUST be ignored when received.

   The object body format for Packets-Lost is shown in Figure 21.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|   RESERVED  |            Packets-Lost                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 21: LOSS-MEASUREMENT Object For Packets Lost

   *  Packets-Lost: This 24-bit field identifies the packet loss as a
      percentage of the total packets transmitted, encoded as per
      [RFC7471].

   *  RESERVED: This field is reserved for future use.  It MUST be set
      to 0 when sent and MUST be ignored when received.

   The object body format for Total Packets Sent and Received is shown
   in Figure 22.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Total Packets Sent                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Total Packets Received                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 22: LOSS-MEASUREMENT Object For Total Packets Sent and
                                  Received

   *  Total Packets Sent: This 32-bit field identifies the total packets
      sent.

   *  Total Packets Received: This 32-bit field identifies the total
      packets received.

7.  PCEP Extensions for Bandwidth Utilization










Gandhi, et al.           Expires 24 October 2026               [Page 26]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


7.1.  Bandwidth Utilization Capability Advertisement

   During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
   advertise their support for bandwidth utilization reporting.  A PCEP
   Speaker includes the "BANDWIDTH-UTILIZATION-CAPABILITY" TLV in the
   OPEN Object to advertise its support for PCEP extensions.  The
   presence of the "BANDWIDTH-UTILIZATION-CAPABILITY" TLV in the OPEN
   Object (in the Open message) indicates that the bandwidth utilization
   reporting is supported as described in this document.  Additional
   procedures are defined as follows:

   *  The PCEP protocol extensions for bandwidth utilization MUST NOT be
      used if one or both PCEP Speakers have not included the
      "BANDWIDTH-UTILIZATION-CAPABILITY" TLV in their respective Open
      message.

   *  If a PCEP speaker supports the extensions of this document but did
      not advertise this capability, then upon receipt of the BANDWIDTH-
      UTILIZATION-ATTRIBUTES TLV in the LSPA object, it SHOULD generate
      a PCErr with error-type 19 (Invalid Operation), error- value TBD28
      (Bandwidth utilization capability was not advertised) and
      terminate the PCEP session.

   *  If a PCEP speaker supports the extensions of this document but did
      not advertise this capability, then upon receipt of the BANDWIDTH-
      UTILIZATION object of type TBD12, it SHOULD generate a PCErr with
      error-type 19 (Invalid Operation), error-value TBD28 (Bandwidth
      utilization capability was not advertised) and terminate the PCEP
      session.

7.1.1.  BANDWIDTH-UTILIZATION-CAPABILITY TLV

   The BANDWIDTH-UTILIZATION-CAPABILITY TLV is an optional TLV for use
   in the OPEN Object for Bandwidth Utilization reporting via PCEP
   capability advertisement.  Its format is shown in Figure 23.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       PCEP TLV Type=TBD3      |           Length=4            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Flags                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 23: BANDWIDTH-UTILIZATION-CAPABILITY TLV Format

   The Type of the TLV is TBD3 and it has a fixed length of 4 bytes.




Gandhi, et al.           Expires 24 October 2026               [Page 27]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   The value comprises a single field - Flags (32 bits).  Currently, no
   flags are defined for this TLV.

   Unassigned bits are considered reserved.  They MUST be set to 0 when
   sent and MUST be ignored when received.

   Advertisement of the BANDWIDTH-UTILIZATION-CAPABILITY TLV implies
   support for bandwidth utilization reporting, as well as the objects,
   TLVs and procedures defined in this document.

7.2.  BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV

   The BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV provides the
   configurable parameters of the bandwidth utilization feature.

   The format of the BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV is shown
   in Figure 24.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       PCEP TLV Type=TBD7      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                           sub-TLVs                          //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 24: BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV Format

   PCEP TLV Type is defined as follows:

    Type      Name
    ----------------------------------------------------------
    TBD7      BW-UTILIZATION-MEASUREMENT-ATTRIBUTES

   Length: The Length field defines the length of the value portion in
   bytes, as per [RFC5440].

   Value: Comprises of one or more sub-TLVs as described in Section 4 of
   this document.

   For reporting bandwidth utilization, the last reported MaxSampleBw
   (see [RFC8733]) value is compared with the MaxSampleBW from the
   current interval to detect the threshold crossing.






Gandhi, et al.           Expires 24 October 2026               [Page 28]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   The following sub-sections describe the parameters that are currently
   defined to be carried within this TLV.  Any other parameters not
   defined for this TLV MUST be ignored.

7.2.1.  Bandwidth Utilization Measurement Enable

   The Measurement-Enable sub-TLV specifies that the bandwidth
   utilization reporting is enabled using the following flag:

    Bit     Description
    ------------------------------------------------------------------
    23      Bandwidth Utilization Reporting Enabled

7.2.2.  Bandwidth Utilization Measurement Interval

   The Measurement-Interval sub-TLV specifies a time interval in seconds
   for the bandwidth samples collection for the LSP.

7.2.3.  Bandwidth Utilization Report Threshold

   The Report-Threshold sub-TLV is used to decide if the bandwidth
   samples collected so far should be immediately reported bypassing the
   report-interval.

   *  Threshold: The absolute threshold bandwidth value in 32-bits,
      encoded in IEEE floating-point format as described in
      [IEEE.754.1985], expressed in bytes per second.

7.2.4.  Bandwidth Utilization Report Threshold Percentage

   The Report-Threshold-Percentage sub-TLV is used to decide if the
   bandwidth samples collected so far should be immediately reported
   bypassing the report-interval.

7.2.5.  Bandwidth Utilization Report Interval

   The Report-Interval sub-TLV specifies a time interval in seconds when
   the collected bandwidth samples are to be reported to the PCE.  The
   number of bandwidth samples in the report interval is computed using
   the measurement interval.

7.2.6.  Bandwidth Utilization Upper Bound and Lower Bound

   The Report-Upper-Lower-Bound sub-TLV specifies the upper bound and
   lower bound bandwidth values encoded in IEEE floating-point format as
   described in [IEEE.754.1985], expressed in bytes per second, and is
   used to trigger an immediate reporting when crossed.  This may also
   result in the PCC taking an immediate local action on the LSP.



Gandhi, et al.           Expires 24 October 2026               [Page 29]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


7.3.  BANDWIDTH Object For Reporting

   A new object-type for the existing BANDWIDTH Object (Object-Class 5)
   is defined to report the bandwidth utilization of an LSP.

   When the LSP is enabled with the bandwidth utilization reporting, the
   PCC SHOULD include the BANDWIDTH-UTILIZATION Object to report the
   bandwidth utilization of the LSP to the PCE in the PCRpt message.

   The object-type is TBD12, the object length is variable with
   multiples of 4 bytes.

   The object body format is shown in Figure 25.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        BwSample1                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           ...                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        BwSampleN                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 25: BANDWIDTH-UTILIZATION Object Body Format For Reporting
                                 Bandwidth

   *  BwSample: The utilized bandwidth, (the average BwSample collected
      at the end of each measurement-interval) encoded in IEEE floating-
      point format as described in [IEEE.754.1985], expressed in bytes
      per second.

8.  PCEP Extensions for Liveness Detection Using PM

8.1.  Liveness Detection Using PM

   During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
   advertise their support for LIVENESS-DETECTION.  A PCEP Speaker
   includes the LIVENESS-DETECTION-CAPABILITY TLV in the OPEN Object to
   advertise its support for PCEP Liveness-Detection extensions.  The
   presence of the LIVENESS-DETECTION-CAPABILITY TLV in the OPEN Object
   (in the Open message) indicates that the liveness detection
   capability is supported as described in this document.  Additional
   procedures are defined as follows:

   *  The PCEP protocol extensions for Liveness Detection MUST NOT be
      used if one or both PCEP Speakers have not included the LIVENESS-
      DETECTION-CAPABILITY TLV in their respective Open message.



Gandhi, et al.           Expires 24 October 2026               [Page 30]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   *  If a PCEP speaker supports the extensions of this document but did
      not advertise this capability, then upon receipt of the LIVENESS-
      DETECTION-ATTRIBUTES TLV in the LSPA object, it SHOULD generate a
      PCErr with error-type 19 (Invalid Operation), error-value TBD29
      (Liveness-Detection capability was not advertised) and terminate
      the PCEP session.

8.1.1.  LIVENESS-DETECTION-CAPABILITY TLV

   The LIVENESS-DETECTION-CAPABILITY TLV is an optional TLV for use in
   the OPEN Object for Liveness Detection via PCEP capability
   advertisement.  Its format is shown in Figure 26.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       PCEP TLV Type=TBD4      |           Length=4            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Flags                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 26: LIVENESS-DETECTION-CAPABILITY TLV Format

   The Type of the TLV is TBD4 and it has a fixed length of 4 bytes.

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

   Unassigned bits are considered reserved.  They MUST be set to 0 when
   sent and MUST be ignored when received.

   Advertisement of the LIVENESS-DETECTION-CAPABILITY TLV implies
   support for liveness detection, as well as the objects, TLVs and
   procedures defined in this document.

8.2.  LIVENESS-DETECTION-ATTRIBUTES TLV

   The LIVENESS-DETECTION-ATTRIBUTES TLV provides the configurable
   parameters of the liveness detection feature.

   The format of the LIVENESS-DETECTION-ATTRIBUTES TLV is shown in
   Figure 27.










Gandhi, et al.           Expires 24 October 2026               [Page 31]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       PCEP TLV Type=TBD8      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                           sub-TLVs                          //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 27: LIVENESS-DETECTION-ATTRIBUTES TLV Format

   PCEP TLV Type is defined as follows:

    Type     Name
    ----------------------------------------------------------
    TBD8     LIVENESS-DETECTION-ATTRIBUTES

   Length: The Length field defines the length of the value portion in
   bytes, as per [RFC5440].

   Value: Comprises of one or more sub-TLVs as described in Section 4 of
   this document.

   The following sub-sections describe the parameters that are currently
   defined to be carried within this TLV.  Any other parameters not
   defined for this TLV MUST be ignored.

8.2.1.  Liveness Detection Enable

   The Measurement-Enable sub-TLV specifies the liveness detection
   enabled using the following flags:

    Bit      Description
    -----------------------------------------------------------------
    22       Liveness Detection Enabled

8.2.2.  Liveness Detection Protocol

   The Measurement-Protocol sub-TLV specifies that the given protocol
   type and loopback mode are enabled for liveness detection.

8.2.3.  Liveness Detection Transmit Interval

   The Transmit-Interval sub-TLV specifies a time interval in
   milliseconds for the liveness detection loss test packet
   transmission.




Gandhi, et al.           Expires 24 October 2026               [Page 32]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


8.2.4.  Liveness Detection Interval

   The Measurement-Interval sub-TLV specifies a time interval in seconds
   for the liveness failure detection.  The measurement interval MUST be
   a multiple of transmit interval.

8.3.  LIVENESS-DETECTION Object

   The LIVENESS-DETECTION Object with Object-Class (Value TBD11) is
   defined in this document to report the liveness state of an LSP.  The
   format of this Object is shown in Figure 28.

   When the LSP is enabled with the liveness detection feature, the PCC
   SHOULD include the LIVENESS-DETECTION Object to report the liveness
   state.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Class=TBD11   |   OT  |Res|P|I|   Object Length (bytes)       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                        (Object body)                        //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 28: LIVENESS-DETECTION Object Format

   Object Length (16 bits): Specifies the total object length including
   the header, in bytes [RFC5440].

   Object-Types (OT) are defined as follows:

    Object-Type  Length   Name
    -------------------------------------------------------------
    1            8        Liveness State

   The object body format for Liveness Detection State is shown in
   Figure 29.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     RESERVED                                  |  State        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 29: LIVENESS-DETECTION Object Format For Liveness State




Gandhi, et al.           Expires 24 October 2026               [Page 33]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   *  Liveness Detection State: Indicates the State of Liveness
      Detection as: (1) Up, (2) Down, (3) Errored.

   *  RESERVED: This field is reserved for future use.  It MUST be set
      to 0 when sent and MUST be ignored when received.

9.  PCEP Procedures

   The following procedures are defined for the extensions to different
   PCEP messages for reporting performance measurement and liveness
   detection.

9.1.  MEASUREMENT-ATTRIBUTES TLVs in LSPA Object

   *  For a PCE-Initiated LSP [RFC8281] with reporting features enabled,
      the corresponding MEASUREMENT-ATTRIBUTES TLV for each measurement
      MUST be included in the LSPA Object with the PCInitiate message.

   *  For a PCE-Initiated LSP [RFC8281] with reporting features enabled,
      the corresponding MEASUREMENT-ATTRIBUTES TLV for each measurement
      is carried in the PCUpd message in the LSPA Object in order to
      make updates to the attributes such as the Report-Interval.

   *  For a PCC-Initiated LSP with reporting features enabled, when the
      LSP is delegated to the PCE, the corresponding MEASUREMENT-
      ATTRIBUTES TLV for each measurement MUST be included in the LSPA
      Object of the PCRpt message.

   *  The various MEASUREMENT-ATTRIBUTES TLVs are encoded in all PCEP
      messages for the LSP with reporting features enabled, the absence
      of the corresponding MEASUREMENT-ATTRIBUTES TLV indicates that the
      PCEP speaker wishes to disable the feature.

9.2.  LSP Measurement Notification Using MEASUREMENT Objects

   When an LSP is enabled with a measurement reporting feature, the PCC
   SHOULD include the corresponding MEASUREMENT Object to notify the
   measured values to the PCE.

   [RFC5440] defines request-notification.  This message is extended for
   LSP Measurement Notification (type TBD13).  It carries one or more
   LSPs, and each LSP may contain one or more paths information if
   multipath [I-D.ietf-pce-multipath] capability has been exchanged
   between the PCEP speakers.  Each path carries individual performance
   measurement data.






Gandhi, et al.           Expires 24 October 2026               [Page 34]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   The reception of this message is for informational purposes, and does
   not replace the PcUpd message and MUST NOT manipulate the ERO/RRO
   forwarding hop instructions and MUST NOT be considered as an
   alternative for PcUpd.

   The RBNF format of the LSP Measurement Notification message (PCNtf)
   (type TBD13) is defined as follows:

   <PCNtf Message> ::= <Common Header>
                       <notify-list>

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

   <notify> ::= [<request-id-list>]
                [<lsp-list>]
                <notification-list>

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

   <lsp-list> ::= <LSP> [<path>] [<lsp-list>]

   <notification-list> ::= <NOTIFICATION> [<notification-list>]

   <path> ::= <intended-path> [<actual-path>]

   <intended-path> ::= ( [<ERO>] <attribute-list>   )  |
                       ( <PATH-ATTRIB> [<ERO>] <attribute-list>
                         [<intended-path-multipath>] )

   <intended-path-multipath> ::= ( <PATH-ATTRIB> [<ERO>]
                                   [<intended-path-multipath>] )

   <actual-path> ::= ( [<RRO>] <attribute-list>     )  |
                     ( <PATH-ATTRIB> [<RRO>] <attribute-list>
                       [<actual-path-multipath>]    )

   <actual-path-multipath> ::= ( <PATH-ATTRIB> [<RRO>]
                                 [<actual-path-multipath>] )

   <attribute-list> ::= [<BANDWIDTH>]
                        [<DELAY-MEASUREMENT>]
                        [<LOSS-MEASUREMENT>]
                        [<LIVENESS-DETECTION>]
                        [<metric-list>]

   <metric-list> ::= <METRIC> [<metric-list>]





Gandhi, et al.           Expires 24 October 2026               [Page 35]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   In the case of single ERO/RRO, an implementation MAY omit carrying
   the ERO/RRO in the LSP Measurement Notification when the previous
   message carried it.  An implementation MAY omit carrying the ERO/RRO
   in the LSP Measurement Notification when the PATH ID
   [I-D.ietf-pce-multipath] is carried.

10.  Scaling Considerations

   It should be noted that when the measurement reporting is deployed
   under LSP scaling, it can lead to frequent notification updates to
   the PCE.  Operators are advised to set the values of various
   measurement reporting parameters appropriate for the deployed LSP
   scale.

   As the LSP Measurement Notification may carry measurement information
   for a list of LSPs, an implementation MAY limit the number of LSPs in
   the list to keep the message size small.

   If a PCE gets overwhelmed, it can notify the PCC to temporarily
   suspend the reporting of the measurements as described below.

10.1.  Notification for Overwhelmed State

   As per [RFC5440], the PCEP Notification message (PCNtf) can be sent
   by a PCEP speaker to notify its peer of a specific event.  A PCEP
   speaker SHOULD notify its PCEP peer that it is overwhelmed, and on
   receipt of such notification, the peer SHOULD NOT send any PCEP
   messages related to measurement reporting.  If a PCEP message related
   to measurement reporting is received, it MUST be silently ignored.

   *  When a PCEP speaker is overwhelmed, it SHOULD notify its peer by
      sending a PCNtf message with Notification Type = TBD14 (PM
      Overwhelm State) and Notification Value = 1 (Entering PM overwhelm
      state).

   *  Optionally, the OVERLOADED-DURATION TLV [RFC5440] MAY be included
      that specifies the time period during which no further PCEP
      messages related to PM should be sent.

   *  When the PCEP speaker is no longer in the overwhelmed state and is
      available to process the PM reporting, it SHOULD notify its peer
      by sending a PCNtf message with Notification Type = TBD14 (PM
      Overwhelm State) and Notification Value = 2 (Clearing PM overwhelm
      state).







Gandhi, et al.           Expires 24 October 2026               [Page 36]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


11.  Security Considerations

   This document defines new MEASUREMENT-ATTRIBUTES TLVs, CAPABILITY
   TLVs and MEASUREMENT Objects for reporting loss and delay
   measurements, liveness detection, and bandwidth utilization that do
   not add additional security concerns beyond those discussed in
   [RFC5440], [RFC8231], [RFC8281] and [RFC8664].

   Some deployments may find the reporting of the performance
   measurement, liveness detection, and bandwidth utilization
   information as extra sensitive as it could be used to influence the
   LSP path computation and LSP setup with an adverse effect.
   Additionally, snooping of PCEP messages with such data or using PCEP
   messages for network reconnaissance, may give an attacker sensitive
   information about the operations of the network.  Thus, such
   deployments should employ suitable PCEP security mechanisms like the
   TCP Authentication Option (TCP-AO) [RFC5925] or Transport Layer
   Security [RFC8253].

12.  Operational Considerations

   The manageability requirements and considerations listed in
   [RFC5440], [RFC8231], [RFC8281], and [I-D.ietf-pce-multipath] apply
   to the PCEP protocol extensions defined in this document.  Additional
   operational requirements and considerations are listed in this
   section.

12.1.  Control of Function and Policy

   The performance measurement reporting SHOULD be controlled per LSP
   basis (at the PCC or PCE) and the values for feature attributes e.g.
   measurement-interval, report-interval, report-threshold SHOULD be
   configurable by an operator.

12.2.  Information and Data Models

   A Management Information Base (MIB) module for modeling PCEP is
   described in [RFC7420].  However, one may prefer a mechanism for
   configuration using the PCEP YANG data model [RFC9826].  These SHOULD
   be enhanced to provide controls and indicators for supporting the
   performance measurement reporting feature.  Support for various
   configuration knobs as well as for counters of messages sent/received
   containing the TLVs (defined in this document) SHOULD be added.

12.3.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operational
   verification requirements.



Gandhi, et al.           Expires 24 October 2026               [Page 37]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


12.4.  Requirements on Other Protocols

   Mechanisms defined in this document do not add any new requirements
   on other protocols.

12.5.  Impact on Network Operations

   In order to avoid any unacceptable impact on network operations, an
   implementation SHOULD allow a limit to be placed on the number of
   LSPs that can be enabled with the performance measurement reporting
   feature.  An implementation MAY allow a limit to be placed on the
   rate of measurement reporting messages sent by a PCEP speaker and
   received by a peer.

   An implementation MAY also allow sending a notification when a PCEP
   speaker is overwhelmed or the rate of messages reaches a threshold.

13.  IANA Considerations

13.1.  Measurement Capability TLV Types

   This document defines the following new PCEP TLVs; IANA is requested
   to make the following allocations from the "PCEP TLV Type Indicators"
   registry.  http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-
   type-indicators

    Type      Name                                 Reference
    --------------------------------------------------------------
    TBD1      DELAY-MEASUREMENT-CAPABILITY         [This document]
    TBD2      LOSS-MEASUREMENT-CAPABILITY          [This document]
    TBD3      BANDWIDTH-UTILIZATION-CAPABILITY     [This document]
    TBD4      LIVENESS-DETECTION-CAPABILITY        [This document]

13.2.  Flag Fields for MEASUREMENT-CAPABILITY TLVs

   IANA is requested to create two new registries as defined in this
   section to manage the Flag field of the DELAY-MEASUREMENT-CAPABILITY
   TLV and LOSS-MEASUREMENT-CAPABILITY TLV.

   New bit numbers are allocated only by an IETF Review action
   [RFC8126].  Each bit should be tracked using the following qualities:

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

      -  Capability description

      -  Defining RFC




Gandhi, et al.           Expires 24 October 2026               [Page 38]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


13.2.1.  Flag Fields for DELAY-MEASUREMENT-CAPABILITY TLV

   IANA is requested to create a registry to manage the Flag field of
   the DELAY-MEASUREMENT-CAPABILITY TLV.

   The following values are defined in this document for the Flag field
   for DELAY-MEASUREMENT-CAPABILITY TLV:

    Bit       Description                            Reference
    ----------------------------------------------------------------
    31        One-way Delay Measurement              [This document]
    30        Two-way Delay Measurement              [This document]
    29        Loopback Delay Measurement             [This document]

13.2.2.  Flag Fields for LOSS-MEASUREMENT-CAPABILITY TLV

   IANA is requested to create a registry to manage the Flag field of
   the LOSS-MEASUREMENT-CAPABILITY TLV.

   The following values are defined in this document for the Flag field
   for LOSS-MEASUREMENT-CAPABILITY TLV:

    Bit       Description                            Reference
    ----------------------------------------------------------------
    31        One-Way Loss Measurement               [This document]
    30        Two-Way Loss Measurement               [This document]
    29        Loopback Loss Measurement              [This document]
    28        Inferred Loss Measurement Mode         [This document]
    27        Direct Loss Measurement Mode           [This document]

13.3.  MEASUREMENT-ATTRIBUTES TLVs

   This document defines the following new PCEP TLV Types; IANA is
   requested to make the following TLV type allocations from the "PCEP
   TLV Type Indicators" registry.  http://www.iana.org/assignments/pcep/
   pcep.xhtml#pcep-tlv-type-indicators

    Type      Name                                    Reference
    -----------------------------------------------------------------
    TBD5      DELAY-MEASUREMENT-ATTRIBUTES            [This document]
    TBD6      LOSS-MEASUREMENT-ATTRIBUTES             [This document]
    TBD7      BW-UTILIZATION-MEASUREMENT-ATTRIBUTES   [This document]
    TBD8      LIVENESS-DETECTION-ATTRIBUTES           [This document]








Gandhi, et al.           Expires 24 October 2026               [Page 39]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


13.3.1.  The Sub-TLVs for MEASUREMENT-ATTRIBUTES TLVs

   IANA is requested to create a "MEASUREMENT-ATTRIBUTES Sub-TLV Types"
   sub-registry in the "PCEP TLV Type Indicators" registry.  New sub-
   TLVs are allocated only by an IETF Review action [RFC8126].

   This document defines the following sub-TLV types:

    Type     Name                                 Reference
    -------------------------------------------------------------
    0        Reserved                             [This document]
    1        Measurement-Enable sub-TLV           [This document]
    2        Transmit-Interval sub-TLV            [This document]
    3        Measurement-Protocol sub-TLV         [This document]
    4        Measurement-Interval sub-TLV         [This document]
    5        Report-Threshold sub-TLV             [This document]
    6        Report-Threshold-Percentage sub-TLV  [This document]
    7        Report-Interval sub-TLV              [This document]
    8        Report-Upper-Lower-Bound sub-TLV     [This document]
    9-       Unassigned                           [This document]
    65535

13.3.2.  Flag Fields in Measurement-Enable sub-TLV

   IANA is requested to create a registry to manage the Flag field of
   the Measurement-Enable sub-TLV.

   New bit numbers are allocated only by an IETF Review action
   [RFC8126].  Each bit should be tracked with the following qualities:

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

      -  Capability description

      -  Defining RFC

   The following values are defined in this document for the Flag field.














Gandhi, et al.           Expires 24 October 2026               [Page 40]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


    Bit    Description                              Reference
    ---------------------------------------------------------------
    31     One-Way Delay Measurement Enabled        [This document]
    30     Two-Way Delay Measurement Enabled        [This document]
    29     Loopback Delay Measurement Enabled       [This document]

    28     One-Way Loss Measurement Enabled         [This document]
    27     Two-Way Loss Measurement Enabled         [This document]
    26     Loopback Loss Measurement Enabled        [This document]
    25     Inferred Loss Measurement Enabled        [This document]
    24     Direct Loss Measurement Enabled          [This document]

    23     Bandwidth Utilization Reporting Enabled  [This document]

    22     Liveness Detection Enabled               [This document]

13.4.  Measurement Object-Class

   This document defines Object-Class for the following Objects; IANA is
   requested to make the following allocations from the "PCEP Objects"
   registry.  http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-
   objects

    Object-Class  Name                             Reference
    --------------------------------------------------------------
    TBD9          DELAY-MEASUREMENT Object         [This document]
    TBD10         LOSS-MEASUREMENT Object          [This document]
    TBD11         LIVENESS-DETECTION Object        [This document]

13.4.1.  DELAY-MEASUREMENT Object-Types

   IANA is requested to create a "DELAY-MEASUREMENT Object-Types" sub-
   registry for the DELAY-MEASUREMENT Object (Object-class TBD9).

   This document defines the following object-types:
















Gandhi, et al.           Expires 24 October 2026               [Page 41]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


    Object-Type Name                                    Reference
    -------------------------------------------------------------------
    0        Reserved                                   [This document]
    1        Delay Measurement Status                   [This document]
    2        One-Way Delay Measurement Value            [This document]
    3        One-Way Delay Measurement Min/Max Values   [This document]
    4        One-Way Delay Variation Measurement Value  [This document]
    5        Two-Way Delay Measurement Value            [This document]
    6        Two-Way Delay Measurement Min/Max Values   [This document]
    7        Two-Way Delay Variation Measurement Value  [This document]
    8        Loopback Delay Measurement Value           [This document]
    9        Loopback Delay Measurement Min/Max Values  [This document]
    10       Loopback Delay Variation Measurement Value [This document]

13.4.2.  LOSS-MEASUREMENT Object-Types

   IANA is requested to create a "LOSS-MEASUREMENT Object-Types" sub-
   registry for the LOSS-MEASUREMENT Object (Object-class TBD10).

   This document defines the following object-types:

    Object-Type Name                               Reference
    --------------------------------------------------------------
    0           Reserved                           [This document]
    1           Loss Measurement Status            [This document]
    2           Tx Packets-Lost                    [This document]
    3           Rx Packets-Lost                    [This document]
    4           Total Packets-Sent-Received        [This document]

13.4.3.  BANDWIDTH Object-Type

   This document defines a new Object-Type for the existing BANDWIDTH
   object (Object-Class 5, [RFC5440]); IANA is requested to make the
   following allocation from the "PCEP Objects" registry.
   http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects

    Object-Type Name                               Reference
    --------------------------------------------------------------
    TBD12       BANDWIDTH-UTILIZATION Object       [This document]

13.5.  PCE Error Codes

   This document defines two new error-values for PCErr with error-code
   19 (Invalid Operation).  IANA is requested to make the following
   allocations.






Gandhi, et al.           Expires 24 October 2026               [Page 42]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


    Error-Value  Name                                   Reference
    -------------------------------------------------------------------
    TBD21        Delay-Measurement capability
                                  was not advertised    [This document]
    TBD22        Loss-Measurement capability
                                  was not advertised    [This document]
    TBD23        Two-Way Measurement capability
                                  was not advertised    [This document]
    TBD24        One-Way Measurement capability
                                  was not advertised    [This document]
    TBD25        Loopback Measurement capability
                                  was not advertised    [This document]
    TBD26        Inferred Mode Loss Measurement capability
                                  was not advertised    [This document]
    TBD27        Direct Mode Loss Measurement capability
                                  was not advertised    [This document]
    TBD28        Bandwidth Utilization capability
                                  was not advertised    [This document]
    TBD29        Liveness Detection capability
                                  was not advertised    [This document]

13.6.  Notification Object Types

   IANA is requested to allocate Notification-types and Notification-
   values within the "Notification Object" sub-registry of the PCEP
   Numbers registry, as follows:

    Notification-type   Name                          Reference
    -----------------------------------------------------------------
    TBD13               LSP Measurement Notification  [This document]

    TBD14               PM Overwhelm State            [This document]

                   Notification-value=1:  Entering PM overwhelm state
                   Notification-value=2:  Clearing PM overwhelm state

14.  References

14.1.  Normative References

   [I-D.ietf-pce-multipath]
              Koldychev, M. and S. Sidor, "Path Computation Element
              Communication Protocol (PCEP) Extensions for Signaling
              Multipath Information", Work in Progress, Internet-Draft,
              draft-ietf-pce-multipath-23, 1 April 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              multipath-23>.




Gandhi, et al.           Expires 24 October 2026               [Page 43]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

   [RFC9603]  Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
              and Y. Zhu, "Path Computation Element Communication
              Protocol (PCEP) Extensions for IPv6 Segment Routing",
              RFC 9603, DOI 10.17487/RFC9603, July 2024,
              <https://www.rfc-editor.org/info/rfc9603>.

14.2.  Informative References

   [I-D.ietf-spring-stamp-srpm-mpls]
              Gandhi, R., Filsfils, C., Janssens, B., Chen, M., and R.
              F. Foote, "Performance Measurement Using Simple Two-Way
              Active Measurement Protocol (STAMP) for Segment Routing



Gandhi, et al.           Expires 24 October 2026               [Page 44]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


              over the MPLS Data Plane", Work in Progress, Internet-
              Draft, draft-ietf-spring-stamp-srpm-mpls-01, 2 April 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              stamp-srpm-mpls-01>.

   [I-D.ietf-spring-stamp-srpm-srv6]
              Gandhi, R., Filsfils, C., Janssens, B., Chen, M., and R.
              F. Foote, "Performance Measurement Using Simple Two-Way
              Active Measurement Protocol (STAMP) for Segment Routing
              over the IPv6 (SRv6) Data Plane", Work in Progress,
              Internet-Draft, draft-ietf-spring-stamp-srpm-srv6-01, 2
              April 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-spring-stamp-srpm-srv6-01>.

   [IEEE.754.1985]
              IEEE, "IEEE Standard for Binary Floating-Point
              Arithmetic", IEEE ANSI/IEEE 754-1985,
              DOI 10.1109/IEEESTD.1985.82928, 5 April 2019,
              <https://ieeexplore.ieee.org/document/30711>.

   [RFC4655]  Farrel, A., Vasseur, J.-P., 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>.

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, DOI 10.17487/RFC5357, October 2008,
              <https://www.rfc-editor.org/info/rfc5357>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [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>.







Gandhi, et al.           Expires 24 October 2026               [Page 45]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
              Previdi, "OSPF Traffic Engineering (TE) Metric
              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
              <https://www.rfc-editor.org/info/rfc7471>.

   [RFC7823]  Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
              "Performance-Based Path Selection for Explicitly Routed
              Label Switched Paths (LSPs) Using TE Metric Extensions",
              RFC 7823, DOI 10.17487/RFC7823, May 2016,
              <https://www.rfc-editor.org/info/rfc7823>.

   [RFC8233]  Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
              "Extensions to the Path Computation Element Communication
              Protocol (PCEP) to Compute Service-Aware Label Switched
              Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
              2017, <https://www.rfc-editor.org/info/rfc8233>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC8408]  Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
              Hardwick, "Conveying Path Setup Type in PCE Communication
              Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
              July 2018, <https://www.rfc-editor.org/info/rfc8408>.

   [RFC8570]  Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
              D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
              Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
              2019, <https://www.rfc-editor.org/info/rfc8570>.

   [RFC8571]  Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
              C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
              IGP Traffic Engineering Performance Metric Extensions",
              RFC 8571, DOI 10.17487/RFC8571, March 2019,
              <https://www.rfc-editor.org/info/rfc8571>.

   [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "Path Computation Element Communication
              Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
              DOI 10.17487/RFC8664, December 2019,
              <https://www.rfc-editor.org/info/rfc8664>.

   [RFC8733]  Dhody, D., Ed., Gandhi, R., Ed., Palle, U., Singh, R., and
              L. Fang, "Path Computation Element Communication Protocol
              (PCEP) Extensions for MPLS-TE Label Switched Path (LSP)



Gandhi, et al.           Expires 24 October 2026               [Page 46]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


              Auto-Bandwidth Adjustment with Stateful PCE", RFC 8733,
              DOI 10.17487/RFC8733, February 2020,
              <https://www.rfc-editor.org/info/rfc8733>.

   [RFC8762]  Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
              Two-Way Active Measurement Protocol", RFC 8762,
              DOI 10.17487/RFC8762, March 2020,
              <https://www.rfc-editor.org/info/rfc8762>.

   [RFC9779]  Gandhi, R., Ed., Filsfils, C., Voyer, D., Salsano, S., and
              M. Chen, "Performance Measurement for Segment Routing
              Networks with the MPLS Data Plane", RFC 9779,
              DOI 10.17487/RFC9779, May 2025,
              <https://www.rfc-editor.org/info/rfc9779>.

   [RFC9826]  Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura,
              "A YANG Data Model for the Path Computation Element
              Communication Protocol (PCEP)", RFC 9826,
              DOI 10.17487/RFC9826, September 2025,
              <https://www.rfc-editor.org/info/rfc9826>.

Appendix A.  Example Use Cases

   This section describes a non-exhaustive list of examples of
   deployment use cases of PM for LSPs when deployed in a network with
   the PCE.  A Network Management System (NMS) may also be deployed in
   the network capable of receiving and processing streaming telemetry
   of PM metrics and may interact with the PCC and PCE for the PM as
   described in use cases 3, 4, and 5.

   Use case 1: PCE Enables PM on the PCC and PCC Takes Action

   PCE -----> PCC

   In this use case, the PCE sets the upper bound threshold condition
   for LSPs at the PCC.  The PCC takes a local action when the condition
   is met.  The action could be based on a local policy or a policy set
   by the PCE.  The steps involved are -

   *  PCE sends the PM attributes as part of the PCE-initiated LSPs
      including an upper bound threshold (Section 4.8 in this document)
      for the PM metrics using the PCEP extensions defined in this
      document.

   *  PCC takes actions when PM metrics exceed the upper bound
      threshold.  Such actions could include bringing down the LSP,
      triggering a protection switch-over, removing the LSP from IGP for
      some prefixes, or requesting a new path from the PCE (based on



Gandhi, et al.           Expires 24 October 2026               [Page 47]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


      local policies that may be set by the PCE).  PCC may take these
      actions even when LSPs are delegated to the PCE as the upper bound
      is set by the PCE.

   *  PCC does not report the PM metrics to the PCE.

   *  PCC may install the new LSP in the routing table only if the PM
      metric is below the upper bound; otherwise, the PCC may reject the
      LSP request and send an error to the PCE.

   *  The report interval should be set to 0 to disable reporting to the
      PCE.  Only the upper bound threshold should be set.

   Use case 2: PCC Reports PM Metrics to the PCE, PCE Takes Action

   PCE <----- PCC

   In this use case, the PCC reports the PM metrics and parameters to
   the PCE and the PCE may take an immediate local (reactive) action
   based on the PM metrics.  The steps involved are -

   *  PCC sends the PM metrics and parameters to the PCE using the PCEP
      extensions defined in this document and the PCE takes an action;
      actions could be to correlate faults, invalidate the LSP path,
      send new LSP path to the PCC (trigger re-optimization), etc.

   *  If an upper bound threshold is set, the PCC only reports the PM
      metrics to the PCE when the upper bound is crossed.  Otherwise,
      the PCC reports the PM metrics to the PCE every report-interval.

   *  Optionally, the PCC may take an immediate local (reactive) action
      such as triggering a path protection switch-over when PM metrics
      exceed the upper bound.

   *  The PCE has a global view due to PM metric reports received from
      various PCCs and hence can make a better decision about LSP
      placement in the network.

   *  The PCE can make proactive decisions based on PM metrics when
      metrics are reported before the crossing of the upper bound as
      opposed to a reactive action that the PCC could make.

   *  The report interval should be set to enable reporting by the PCC.
      Optionally, the upper bound threshold may also be set.

   Use case 3: PCE Enables PM on the PCC, PCC Sends PM Metrics to NMS

   PCE -----> PCC -----> NMS



Gandhi, et al.           Expires 24 October 2026               [Page 48]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   The steps involved are -

   *  An NMS may be used in a network that is capable of streaming
      telemetry for receiving data and Yang or XML-based provisioning
      using a non-PCEP channel.  The NMS may interact with a PCE for LSP
      path computation using the PCEP channel.

   *  PCE sends the PM attributes as part of PCE-initiated LSPs using
      the PCEP extensions defined in this document.

   *  PCC reports the PM metrics to the NMS via streaming telemetry.

   *  The NMS may request the PCE to take an action based on the PM
      metrics.

   *  The report interval should be set to 0 to disable reporting to the
      PCE.  The other PM attributes may be set and used for streaming
      telemetry.

   Use case 4: NMS Enables PM on the PCC, PCC Sends PM Metrics to the
   PCE

   PCE <----- PCC <----- NMS

   The steps involved are -

   *  The NMS enables PM on the PCC using a non-PCEP channel.

   *  The PCC then reports the PM metrics to the PCE using the PCEP
      extensions defined in this document.

   *  The PCE may take an action based on the PM metrics received from
      the PCC.

   Use case 5: NMS Enables PM on the PCC, PCC Sends PM Metrics to NMS

   PCE ----> PCC <-----> NMS -----> PCE

   The steps involved are -

   *  The NMS enables PM on the PCC using a non-PCEP channel.

   *  The PCC reports the PM metrics to the NMS via streaming telemetry.

   *  The NMS may request the PCE to take an action based on the PM
      metrics.





Gandhi, et al.           Expires 24 October 2026               [Page 49]

Internet-Draft    PCEP for LSP Performance Measurement        April 2026


   *  The PCEP extensions defined in this document are not used in this
      use case.

Acknowledgments

   TBA.

Authors' Addresses

   Rakesh Gandhi
   Cisco Systems, Inc.
   Canada
   Email: rgandhi@cisco.com


   Bin Wen
   Comcast
   Email: Bin_Wen@cable.comcast.com


   Colby Barth
   HPE
   Email: jonathan.barth@hpe.com


   Dhruv Dhody
   Huawei Technologies
   India
   Email: dhruv.ietf@gmail.com


   Andrew Stone
   Nokia
   Canada
   Email: andrew.stone@nokia.com
















Gandhi, et al.           Expires 24 October 2026               [Page 50]
