PCEP Extensions for Performance Measurement for SR-TE and MPLS-TE LSPs with Stateful PCE
draft-gandhi-pce-pm-14
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Rakesh Gandhi , Bin Wen , Colby Barth , Dhruv Dhody , Andrew Stone | ||
| Last updated | 2026-07-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gandhi-pce-pm-14
PCE Working Group R. Gandhi
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track B. Wen
Expires: 24 January 2027 Comcast
C. Barth
HPE
D. Dhody
Huawei Technologies
A. Stone
Nokia
23 July 2026
PCEP Extensions for Performance Measurement for SR-TE and MPLS-TE LSPs
with Stateful PCE
draft-gandhi-pce-pm-14
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
notifying end-to-end performance measurement including 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 January 2027 [Page 1]
Internet-Draft PCEP for LSP Performance Measurement July 2026
This Internet-Draft will expire on 24 January 2027.
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. Notify Thresholds . . . . . . . . . . . . . . . . . . . . 8
4. Sub-TLVs for Measurement Attributes . . . . . . . . . . . . . 9
4.1. Measurement-Enable sub-TLV . . . . . . . . . . . . . . . 9
4.2. Transmit-Interval sub-TLV . . . . . . . . . . . . . . . . 10
4.3. Measurement-Protocol sub-TLV . . . . . . . . . . . . . . 10
4.4. Measurement-Interval sub-TLV . . . . . . . . . . . . . . 11
4.5. Notify-Threshold sub-TLV . . . . . . . . . . . . . . . . 12
4.6. Notify-Threshold-Percentage sub-TLV . . . . . . . . . . . 12
4.7. Notify-Interval sub-TLV . . . . . . . . . . . . . . . . . 13
4.8. Notify-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 . . . . . . . . . . 15
5.2. DELAY-MEASUREMENT-ATTRIBUTES TLV . . . . . . . . . . . . 16
5.2.1. Delay Measurement Enable . . . . . . . . . . . . . . 17
5.2.2. Delay Measurement Protocol . . . . . . . . . . . . . 17
5.2.3. Delay Measurement Transmit Interval . . . . . . . . . 17
5.2.4. Delay Measurement Interval . . . . . . . . . . . . . 18
5.2.5. Delay Measurement Notify Threshold . . . . . . . . . 18
5.2.6. Delay Measurement Notify Threshold Percentage . . . . 18
5.2.7. Delay Measurement Notify Interval . . . . . . . . . . 18
5.2.8. Delay Measurement Upper Bound and Lower Bound . . . . 18
5.3. DELAY-MEASUREMENT Object . . . . . . . . . . . . . . . . 18
Gandhi, et al. Expires 24 January 2027 [Page 2]
Internet-Draft PCEP for LSP Performance Measurement July 2026
6. PCEP Extensions for Loss Measurement . . . . . . . . . . . . 21
6.1. Loss Measurement Capability Advertisement . . . . . . . . 21
6.1.1. LOSS-MEASUREMENT-CAPABILITY TLV . . . . . . . . . . . 22
6.2. LOSS-MEASUREMENT-ATTRIBUTES TLV . . . . . . . . . . . . . 23
6.2.1. Loss Measurement Enable . . . . . . . . . . . . . . . 24
6.2.2. Loss Measurement Protocol . . . . . . . . . . . . . . 25
6.2.3. Loss Measurement Transmit Interval . . . . . . . . . 25
6.2.4. Loss Measurement Interval . . . . . . . . . . . . . . 25
6.2.5. Loss Measurement Notify Threshold . . . . . . . . . . 25
6.2.6. Loss Measurement Notify Threshold Percentage . . . . 25
6.2.7. Loss Measurement Notify Interval . . . . . . . . . . 26
6.2.8. Loss Measurement Upper Bound and Lower Bound . . . . 26
6.3. LOSS-MEASUREMENT Object . . . . . . . . . . . . . . . . . 26
7. PCEP Extensions for Bandwidth Utilization . . . . . . . . . . 28
7.1. Bandwidth Utilization Capability Advertisement . . . . . 28
7.1.1. BANDWIDTH-UTILIZATION-CAPABILITY TLV . . . . . . . . 29
7.2. BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV . . . . . . . . 29
7.2.1. Bandwidth Utilization Measurement Enable . . . . . . 30
7.2.2. Bandwidth Utilization Measurement Interval . . . . . 31
7.2.3. Bandwidth Utilization Notify Threshold . . . . . . . 31
7.2.4. Bandwidth Utilization Notify Threshold Percentage . . 31
7.2.5. Bandwidth Utilization Notify Interval . . . . . . . . 31
7.2.6. Bandwidth Utilization Upper Bound and Lower Bound . . 31
7.3. BANDWIDTH Object For Notification . . . . . . . . . . . . 31
8. PCEP Extensions for Liveness Detection Using PM . . . . . . . 32
8.1. Liveness Detection Using PM . . . . . . . . . . . . . . . 32
8.1.1. LIVENESS-DETECTION-CAPABILITY TLV . . . . . . . . . . 33
8.2. LIVENESS-DETECTION-ATTRIBUTES TLV . . . . . . . . . . . . 33
8.2.1. Liveness Detection Enable . . . . . . . . . . . . . . 34
8.2.2. Liveness Detection Protocol . . . . . . . . . . . . . 35
8.2.3. Liveness Detection Transmit Interval . . . . . . . . 35
8.2.4. Liveness Detection Interval . . . . . . . . . . . . . 35
8.3. LIVENESS-DETECTION Object . . . . . . . . . . . . . . . . 35
9. PCEP Procedures . . . . . . . . . . . . . . . . . . . . . . . 36
9.1. MEASUREMENT-ATTRIBUTES TLVs in LSPA Object . . . . . . . 36
9.1.1. Measurement Attributes Sub-TLVs Applicability . . . . 37
9.2. LSP Measurement Notification Using MEASUREMENT Objects . 38
10. Scaling Considerations . . . . . . . . . . . . . . . . . . . 40
10.1. Notification for Overwhelmed State . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
12. Operational Considerations . . . . . . . . . . . . . . . . . 41
12.1. Control of Function and Policy . . . . . . . . . . . . . 41
12.2. Information and Data Models . . . . . . . . . . . . . . 41
12.3. Verify Correct Operations . . . . . . . . . . . . . . . 41
12.4. Requirements on Other Protocols . . . . . . . . . . . . 41
12.5. Impact on Network Operations . . . . . . . . . . . . . . 42
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
13.1. Measurement Capability TLV Type Indicators . . . . . . . 42
Gandhi, et al. Expires 24 January 2027 [Page 3]
Internet-Draft PCEP for LSP Performance Measurement July 2026
13.2. Flag Fields for MEASUREMENT-CAPABILITY TLVs . . . . . . 42
13.2.1. Flag Fields for DELAY-MEASUREMENT-CAPABILITY TLV . . 43
13.2.2. Flag Fields for LOSS-MEASUREMENT-CAPABILITY TLV . . 43
13.3. MEASUREMENT-ATTRIBUTES TLV Indicators . . . . . . . . . 44
13.3.1. The Sub-TLVs for MEASUREMENT-ATTRIBUTES TLVs . . . . 44
13.3.2. Flag Fields in Measurement-Enable sub-TLV . . . . . 45
13.4. Measurement Object-Class . . . . . . . . . . . . . . . . 46
13.4.1. DELAY-MEASUREMENT Object-Types . . . . . . . . . . . 47
13.4.2. LOSS-MEASUREMENT Object-Types . . . . . . . . . . . 47
13.4.3. BANDWIDTH Object-Type . . . . . . . . . . . . . . . 48
13.5. PCE Error Codes . . . . . . . . . . . . . . . . . . . . 48
13.6. Notification Object Types . . . . . . . . . . . . . . . 49
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
14.1. Normative References . . . . . . . . . . . . . . . . . . 50
14.2. Informative References . . . . . . . . . . . . . . . . . 51
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
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 January 2027 [Page 4]
Internet-Draft PCEP for LSP Performance Measurement July 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 (PM) of an LSP.
This document describes PCEP extensions for enabling and notifying
end-to-end PM such as packet loss, delay, delay variation, bandwidth
utilization, including 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 notified 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. This document defines PCEP
extensions for sending the measured bandwidth values to a Stateful
PCE for implementing auto-bandwidth on the PCE, which was considered
out of scope in [RFC8733].
[RFC8733] describes the PCEP extensions for auto-bandwidth, where the
PCC computes the requested bandwidth for the LSP and notifies 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 bandwidth
utilization notification 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,
Gandhi, et al. Expires 24 January 2027 [Page 5]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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
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 notification defined
in this document can be used by the PCE to perform 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], [RFC7471], [RFC8231], [RFC8281], [RFC8408], and [RFC8570].
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 January 2027 [Page 6]
Internet-Draft PCEP for LSP Performance Measurement July 2026
3. Overview of the PCEP Extensions
The high-level overview of the PCEP extensions defined in this
document for requesting and notifying end-to-end PM that includes
bandwidth utilization, and liveness detection of LSPs for SR-TE over
MPLS and IPv6 data planes as well as for 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 for both PCE-Initiated and PCC-Initiated LSPs defined in
this document:
* The Stateful PCE and PCC (head-end of the LSP) advertise their
capability to support 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, for PCE-
Initiated LSPs.
Gandhi, et al. Expires 24 January 2027 [Page 7]
Internet-Draft PCEP for LSP Performance Measurement July 2026
* The PCC notifies the measured metrics of the enabled feature to
the Stateful PCE at the end of the specified interval or when
measured values cross a specified threshold. Periodic
notification 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.
* The optional periodic notification of the measurements may be
disabled to avoid processing load on the PCE and only an upper
bound threshold may be 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 when entering and clearing the
overwhelmed state when operating at high LSP scale.
3.1. Notify Thresholds
When explicitly configured, a notify threshold (absolute or
percentage) parameter is used to trigger an immediate notification of
the delay and loss metrics as well as bandwidth utilization,
bypassing the periodic notify interval. A threshold is used to
detect a sudden change in the PM 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 notified value.
If the change (increase or decrease) in the value is above the
threshold (absolute or percentage), the measurement from the current
interval is notified 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
notified 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 notification 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 notified if the value crosses both the
percentage threshold and the minimum-threshold parameters.
The metrics are still notified at the end of the notify interval even
if they were notified due to the threshold crossing. Refer to
[RFC7471], Section 5, for additional considerations.
Gandhi, et al. Expires 24 January 2027 [Page 8]
Internet-Draft PCEP for LSP Performance Measurement July 2026
4. Sub-TLVs for Measurement Attributes
This section specifies the generic sub-TLVs that provide various
configurable parameters for PM notification to a Stateful PCE. These
sub-TLVs are carried in various measurement attributes TLVs defined
in this document.
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 | 4 | Notify-Threshold sub-TLV |
+------+--------+-------------------------------------+
| 6 | 8 | Notify-Threshold-Percentage sub-TLV |
+------+--------+-------------------------------------+
| 7 | 4 | Notify-Interval sub-TLV |
+------+--------+-------------------------------------+
| 8 | 8 | Notify-Upper-Lower-Bound sub-TLV |
+------+--------+-------------------------------------+
Table 1: Measurement Attribute Sub-TLV Types
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.
Gandhi, et al. Expires 24 January 2027 [Page 9]
Internet-Draft PCEP for LSP Performance Measurement July 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=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 PM
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.
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 Notify-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.
Gandhi, et al. Expires 24 January 2027 [Page 10]
Internet-Draft PCEP for LSP Performance Measurement July 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=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 PM.
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, as defined in [I-D.ietf-spring-stamp-srpm-srv6] and
[I-D.ietf-spring-stamp-srpm-mpls] for the STAMP protocol, that also
applies to the TWAMP protocol and [RFC6374] for the MPLS-PM protocol.
The PM 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 PM
procedures using MPLS-PM defined in [RFC9779] can be used for SR-MPLS
LSPs and [RFC6374] 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
Gandhi, et al. Expires 24 January 2027 [Page 11]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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 Notify-Interval.
4.5. Notify-Threshold sub-TLV
The Notify-Threshold sub-TLV specifies the threshold value used to
trigger an immediate notification of the measurements bypassing the
notify-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notify-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Notify-Threshold sub-TLV Format
The Type is 5, Length is 4 bytes, and the value comprises:
* Notify-Threshold: 32-bit absolute threshold value. By default,
notify-threshold is not set and threshold-based notification is
disabled.
4.6. Notify-Threshold-Percentage sub-TLV
The Notify-Threshold-Percentage sub-TLV specifies the threshold value
used to trigger an immediate notification of the measurements
bypassing the notify-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: Notify-Threshold-Percentage sub-TLV Format
The Type is 6, Length is 8 bytes, and the value comprises:
Gandhi, et al. Expires 24 January 2027 [Page 12]
Internet-Draft PCEP for LSP Performance Measurement July 2026
* Percentage: 7-bit threshold value, encoded in percentage as an
integer from 1 to 100.
By default, notify-threshold-percentage is not set and threshold-
based notification 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. Notify-Interval sub-TLV
The Notify-Interval sub-TLV specifies the time interval in seconds
when the measured values are to be notified periodically without
checking any threshold crossing. The format of this sub-TLV is shown
in Figure 8.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notify-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Notify-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 notification of the measurements.
4.8. Notify-Upper-Lower-Bound sub-TLV
The Notify-Upper-Lower-Bound sub-TLV specifies the upper bound value
and lower bound value used to trigger an immediate notification 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 notified measurement when the
upper bound threshold is crossed in the up direction and set to false
in the notified measurement when the lower bound threshold is crossed
in the down direction.
Gandhi, et al. Expires 24 January 2027 [Page 13]
Internet-Draft PCEP for LSP Performance Measurement July 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=8 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notify-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Notify-Lower-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Notify-Upper-Lower-Bound sub-TLV Format
The Type is 8, Length is 8 bytes, and the value comprises:
* Notify-Upper-Bound: 32-bit absolute value.
By default, upper bound is not set.
* Notify-Lower-Bound: 32-bit absolute value.
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 messages.
* 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.
Gandhi, et al. Expires 24 January 2027 [Page 14]
Internet-Draft PCEP for LSP Performance Measurement July 2026
* 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.
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 notification 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. One-Way delay is also referred to as "Unidrectional
Delay" in [RFC7471] and [RFC8570]. One-Way delay metric is
computed as forward one-way delay using timestamps as defined in
[RFC6374].
Gandhi, et al. Expires 24 January 2027 [Page 15]
Internet-Draft PCEP for LSP Performance Measurement July 2026
* T (Two-Way Delay Metric - 1 bit): if set to 1 by a PCC, the T Flag
indicates that the PCC allows notification 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. Two-Way delay metric is computed as two-way channel
delay using timestamps as defined in [RFC6374].
* L (Loopback Delay Metric - 1 bit): if set to 1 by a PCC, the L
Flag indicates that the PCC allows notification 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. Loopback delay metric is computed as
round-trip delay using timestamps as defined in [RFC6374].
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.
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:
Gandhi, et al. Expires 24 January 2027 [Page 16]
Internet-Draft PCEP for LSP Performance Measurement July 2026
+======+==============================+
| Type | Name |
+======+==============================+
| TBD5 | DELAY-MEASUREMENT-ATTRIBUTES |
+------+------------------------------+
Table 2: Delay Measurement
Attributes TLV Type
Length: The Length field defines the length of the value portion in
bytes, as per [RFC5440].
Value: Comprises 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 |
+-----+-------------------------------+
Table 3: Delay Measurement Enable Bits
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 January 2027 [Page 17]
Internet-Draft PCEP for LSP Performance Measurement July 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 Notify Threshold
The Notify-Threshold sub-TLV specifies the threshold value used to
trigger an immediate notification of the delay metrics bypassing the
notify-interval.
* Notify-Threshold: Delay in microseconds, encoded as a 24-bit
integer, as defined in [RFC7471].
The same notify-threshold is used for all delay metric values.
5.2.6. Delay Measurement Notify Threshold Percentage
The Notify-Threshold-Percentage sub-TLV specifies the threshold value
used to trigger an immediate notification of the metrics bypassing
the notify-interval.
The same notify-threshold-percentage is used for all delay metric
values.
5.2.7. Delay Measurement Notify Interval
The Notify-Interval sub-TLV specifies the time interval in seconds
when measured delay values are to be notified.
5.2.8. Delay Measurement Upper Bound and Lower Bound
The Notify-Upper-Lower-Bound sub-TLV specifies the upper bound (for
the upward direction) and lower bound (for the downward direction)
delay values in microseconds, and is used to trigger an immediate
notification 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 notify the delay measurement of an LSP.
The format of this object is shown in Figure 12.
Gandhi, et al. Expires 24 January 2027 [Page 18]
Internet-Draft PCEP for LSP Performance Measurement July 2026
When the LSP is enabled with the delay measurement feature, the PCC
SHOULD include the DELAY-MEASUREMENT object to notify the measured
delay values to the PCE. The PCC SHOULD notify average delay, min/
max delay, and delay variations to the PCE, and indicate 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 |
+-------------+--------+---------------------------------------+
Table 4: Delay Measurement Object Types
Gandhi, et al. Expires 24 January 2027 [Page 19]
Internet-Draft PCEP for LSP Performance Measurement July 2026
All delay values are notified 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.
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 loopback delay of the LSP.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gandhi, et al. Expires 24 January 2027 [Page 20]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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.
* Loopback Delay Value Minimum/Maximum: Minimum and Maximum values
of the loopback delay of the LSP.
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
loopback delay measurements of the LSP.
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 messages.
Gandhi, et al. Expires 24 January 2027 [Page 21]
Internet-Draft PCEP for LSP Performance Measurement July 2026
* 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
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):
Gandhi, et al. Expires 24 January 2027 [Page 22]
Internet-Draft PCEP for LSP Performance Measurement July 2026
* O (One-Way Metric - 1 bit): if set to 1 by a PCC, the O Flag
indicates that the PCC allows notification 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. Onw-Way loss metric is defined as transmit loss in
[RFC6374].
* T (Two-Way Metric - 1 bit): if set to 1 by a PCC, the T Flag
indicates that the PCC allows notification 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. Two-way loss metric is defined as transmit + receive
loss in [RFC6374].
* L (Loopback Metric - 1 bit): if set to 1 by a PCC, the L Flag
indicates that the PCC allows notification 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. Loopback loss metric is transmiti loss in loopback mode
defined in [RFC6374].
* I (Inferred Loss Measurement Mode - 1 bit): if set to 1 by a PCC,
the I Flag indicates that the PCC allows notification 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 loss
measurement mode information from the PCC. Inferred loss
measurement mode is defined in [RFC6374].
* N (Direct Loss Measurement Mode - 1 bit): if set to 1 by a PCC,
the N Flag indicates that the PCC allows notification 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 loss
measurement mode information from the PCC. Direct loss
measurement mode is defined in [RFC6374].
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.
Gandhi, et al. Expires 24 January 2027 [Page 23]
Internet-Draft PCEP for LSP Performance Measurement July 2026
The format of the LOSS-MEASUREMENT-ATTRIBUTES TLV is shown in
Figure 18.
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 |
+------+-----------------------------+
Table 5: Loss Measurement
Attributes TLV Type
Length: The Length field defines the length of the value portion in
bytes, as per [RFC5440].
Value: Comprises 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:
Gandhi, et al. Expires 24 January 2027 [Page 24]
Internet-Draft PCEP for LSP Performance Measurement July 2026
+=====+==============================+
| 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 |
+-----+------------------------------+
Table 6: Loss Measurement Enable Bits
6.2.2. Loss Measurement Protocol
The Measurement-Protocol sub-TLV specifies that the given protocol
type and mode are enabled for loss measurement.
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 Notify Threshold
The Notify-Threshold sub-TLV specifies the threshold value used to
trigger an immediate notification of the loss metrics bypassing the
notify-interval.
* Notify-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 notify-threshold is used for all loss metric values.
6.2.6. Loss Measurement Notify Threshold Percentage
The Notify-Threshold-Percentage sub-TLV specifies the threshold value
used to trigger an immediate notification of the loss metrics
bypassing the notify-interval.
Gandhi, et al. Expires 24 January 2027 [Page 25]
Internet-Draft PCEP for LSP Performance Measurement July 2026
The same notify-threshold-percentage is used for all loss metric
values.
6.2.7. Loss Measurement Notify Interval
The Notify-Interval sub-TLV specifies the time interval in seconds
when measured loss values are to be notified.
6.2.8. Loss Measurement Upper Bound and Lower Bound
The Notify-Upper-Lower-Bound sub-TLV specifies the upper bound (for
the upward direction) and lower bound (for the downward direction)
values in percentage packet loss, and is used to trigger an immediate
notification of the packet loss values when crossed. This may also
result in the PCC taking an immediate local action on the LSP.
6.3. LOSS-MEASUREMENT Object
The LOSS-MEASUREMENT object with Object-Class (Value TBD10) is
defined in this document to notify 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 notify the measured
packet loss to the PCE, and indicate 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:
Gandhi, et al. Expires 24 January 2027 [Page 26]
Internet-Draft PCEP for LSP Performance Measurement July 2026
+=============+========+=============================+
| 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 |
+-------------+--------+-----------------------------+
Table 7: Loss Measurement Object Types
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.
* 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.
Gandhi, et al. Expires 24 January 2027 [Page 27]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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
7.1. Bandwidth Utilization Capability Advertisement
During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
advertise their support for bandwidth utilization notification. 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
notification 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
messages.
* 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
Gandhi, et al. Expires 24 January 2027 [Page 28]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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 notification 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.
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 notification, 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.
Gandhi, et al. Expires 24 January 2027 [Page 29]
Internet-Draft PCEP for LSP Performance Measurement July 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=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 |
+------+---------------------------------------+
Table 8: Bandwidth Utilization Measurement
Attributes TLV Type
Length: The Length field defines the length of the value portion in
bytes, as per [RFC5440].
Value: Comprises one or more sub-TLVs as described in Section 4 of
this document.
For bandwidth utilization notification, the last notified MaxSampleBw
(see [RFC8733]) value is compared with the MaxSampleBW from the
current interval to detect the threshold crossing.
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 notification is enabled using the following flag:
Gandhi, et al. Expires 24 January 2027 [Page 30]
Internet-Draft PCEP for LSP Performance Measurement July 2026
+=====+============================================+
| Bit | Description |
+=====+============================================+
| 23 | Bandwidth Utilization Notification Enabled |
+-----+--------------------------------------------+
Table 9: Bandwidth Utilization Enable Bits
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 Notify Threshold
The Notify-Threshold sub-TLV is used to decide if the bandwidth
samples collected so far should be immediately notified bypassing the
notify-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 Notify Threshold Percentage
The Notify-Threshold-Percentage sub-TLV is used to decide if the
bandwidth samples collected so far should be immediately notified
bypassing the notify-interval.
7.2.5. Bandwidth Utilization Notify Interval
The Notify-Interval sub-TLV specifies a time interval in seconds when
the collected bandwidth samples are notified to the PCE. The number
of bandwidth samples in the notify interval is computed using the
measurement interval.
7.2.6. Bandwidth Utilization Upper Bound and Lower Bound
The Notify-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 notification when crossed. This may
also result in the PCC taking an immediate local action on the LSP.
7.3. BANDWIDTH Object For Notification
A new object-type for the existing BANDWIDTH object (Object-Class 5)
is defined to notify the bandwidth utilization of an LSP.
Gandhi, et al. Expires 24 January 2027 [Page 31]
Internet-Draft PCEP for LSP Performance Measurement July 2026
When the LSP is enabled with the bandwidth utilization notification,
the PCC SHOULD include the BANDWIDTH-UTILIZATION object to notify 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 Bandwidth
Notification
* 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 messages.
Gandhi, et al. Expires 24 January 2027 [Page 32]
Internet-Draft PCEP for LSP Performance Measurement July 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 January 2027 [Page 33]
Internet-Draft PCEP for LSP Performance Measurement July 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 |
+------+-------------------------------+
Table 10: Liveness Detection
Attributes TLV Type
Length: The Length field defines the length of the value portion in
bytes, as per [RFC5440].
Value: Comprises 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 |
+-----+----------------------------+
Table 11: Liveness Detection
Enable Bits
Gandhi, et al. Expires 24 January 2027 [Page 34]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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.
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 notify 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 notify 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:
Gandhi, et al. Expires 24 January 2027 [Page 35]
Internet-Draft PCEP for LSP Performance Measurement July 2026
+=============+========+================+
| Object-Type | Length | Name |
+=============+========+================+
| 1 | 8 | Liveness State |
+-------------+--------+----------------+
Table 12: Liveness Detection Object Types
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
* 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 that notify PM.
9.1. MEASUREMENT-ATTRIBUTES TLVs in LSPA Object
* For a PCE-Initiated LSP [RFC8281] with notification 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 notification 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 Notify-
Interval.
* For a PCC-Initiated LSP with notification 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.
Gandhi, et al. Expires 24 January 2027 [Page 36]
Internet-Draft PCEP for LSP Performance Measurement July 2026
* The various MEASUREMENT-ATTRIBUTES TLVs are encoded in all PCEP
messages for the LSP with notification features enabled, the
absence of the corresponding MEASUREMENT-ATTRIBUTES TLV indicates
that the PCEP speaker wishes to disable the feature.
9.1.1. Measurement Attributes Sub-TLVs Applicability
+==============+===========+==============+==============+==========+
| Sub-TLV Type |Delay (TLV | Loss (TLV | BW (TLV |Liveness |
| |Type: TBD5)| Type: TBD6) | Type: TBD7) |(TLV Type:|
| | | | |TBD8) |
+==============+===========+==============+==============+==========+
| Measurement- |31: One-Way| 28: One-Way | 23: |22: |
| Enable Flags |Delay | Loss | Bandwidth |Liveness |
| (bit- |Measurement| Measurement | Utilization |Detection |
| position, |Enabled | Enabled; | Notification |Enabled |
| mandatory |30: Two-Way| 27: Two-Way | Enabled | |
| sub-TLV) |Delay | Loss | | |
| |Measurement| Measurement | | |
| |Enabled | Enabled; | | |
| |29: | 26: | | |
| |Loopback | Loopback | | |
| |Delay | Loss | | |
| |Measurement| Measurement | | |
| |Enabled | Enabled; | | |
| | | 25: | | |
| | | Inferred | | |
| | | Loss | | |
| | | Measurement | | |
| | | Enabled; | | |
| | | 24: Direct | | |
| | | Loss | | |
| | | Measurement | | |
| | | Enabled | | |
+--------------+-----------+--------------+--------------+----------+
| Transmit- |Applicable | Applicable | Not |Applicable|
| Interval | | | applicable | |
+--------------+-----------+--------------+--------------+----------+
| Measurement- |Applicable | Applicable | Not |Applicable|
| Protocol | | | applicable | |
+--------------+-----------+--------------+--------------+----------+
| Measurement- |Applicable | Applicable | Applicable |Applicable|
| Interval | | | |(Detection|
| | | | |Interval) |
+--------------+-----------+--------------+--------------+----------+
| Notify- |Applicable | Applicable | Applicable |Not |
| Threshold | | | |applicable|
+--------------+-----------+--------------+--------------+----------+
Gandhi, et al. Expires 24 January 2027 [Page 37]
Internet-Draft PCEP for LSP Performance Measurement July 2026
| Notify- |Applicable | Applicable | Applicable |Not |
| Threshold- | | | |applicable|
| percentage, | | | | |
| minimum- | | | | |
| threshold | | | | |
+--------------+-----------+--------------+--------------+----------+
| Notify- |Applicable | Applicable | Applicable |Not |
| Interval | | | |applicable|
+--------------+-----------+--------------+--------------+----------+
| Notify- |Applicable | Applicable | Applicable |Not |
| Upper-Lower- | | | |applicable|
| bound | | | | |
+--------------+-----------+--------------+--------------+----------+
Table 13: Measurement Attributes Sub-TLVs Applicability
9.2. LSP Measurement Notification Using MEASUREMENT Objects
When an LSP is enabled with a PM notification feature, the PCC SHOULD
include the corresponding MEASUREMENT object to notify the measured
values to the PCE.
[RFC5440] defines request-notification procedures. This message is
extended for LSP Measurement Notification (type TBD13). It carries
one or more LSPs, and each LSP may contain path information for one
or more paths if multipath [I-D.ietf-pce-multipath] capability has
been exchanged between the PCEP speakers. Each path carries
individual PM data.
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 to PCUpd.
The RBNF format of the LSP Measurement Notification message (PCNtf)
(type TBD13) is defined as follows:
Gandhi, et al. Expires 24 January 2027 [Page 38]
Internet-Draft PCEP for LSP Performance Measurement July 2026
<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>]
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.
Gandhi, et al. Expires 24 January 2027 [Page 39]
Internet-Draft PCEP for LSP Performance Measurement July 2026
10. Scaling Considerations
It should be noted that when the PM notification is deployed under
LSP scaling, it can lead to frequent notification updates to the PCE.
Operators are advised to set the values of various PM notification
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 notification 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 PM notification. If a PCEP message related to PM
notification 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 notification, 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).
11. Security Considerations
This document defines new MEASUREMENT-ATTRIBUTES TLVs, CAPABILITY
TLVs and MEASUREMENT objects for notification of loss and delay
measurements, bandwidth utilization, and liveness detection, that do
not add additional security concerns beyond those discussed in
[RFC5440], [RFC8231], [RFC8281] and [RFC8664].
Gandhi, et al. Expires 24 January 2027 [Page 40]
Internet-Draft PCEP for LSP Performance Measurement July 2026
Some deployments may find notification of the PM 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 PM notification SHOULD be controlled on a per-LSP basis (at the
PCC or PCE) and the values for feature attributes e.g. measurement-
interval, notify-interval, notify-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 PM
notification 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.
12.4. Requirements on Other Protocols
Mechanisms defined in this document do not add any new requirements
on other protocols.
Gandhi, et al. Expires 24 January 2027 [Page 41]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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 PM notification feature. An
implementation MAY allow a limit to be placed on the rate of PM
notification 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 Type Indicators
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] |
+------+----------------------------------+-----------------+
Table 14: Measurement Capability TLV Type Indicators
13.2. Flag Fields for MEASUREMENT-CAPABILITY TLVs
IANA is requested to create 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 January 2027 [Page 42]
Internet-Draft PCEP for LSP Performance Measurement July 2026
13.2.1. Flag Fields for DELAY-MEASUREMENT-CAPABILITY TLV
IANA is requested to create a registry with name "Delay Measurement
Capability Flags" 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] |
+-----+----------------------------+-----------------+
Table 15: Delay Measurement Capability Flags
13.2.2. Flag Fields for LOSS-MEASUREMENT-CAPABILITY TLV
IANA is requested to create a registry with name "Loss Measurement
Capability Flags" 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] |
+-----+--------------------------------+-----------------+
Table 16: Loss Measurement Capability Flags
Gandhi, et al. Expires 24 January 2027 [Page 43]
Internet-Draft PCEP for LSP Performance Measurement July 2026
13.3. MEASUREMENT-ATTRIBUTES TLV Indicators
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] |
+------+---------------------------------------+-----------------+
Table 17: MEASUREMENT-ATTRIBUTES TLV Indicators
13.3.1. The Sub-TLVs for MEASUREMENT-ATTRIBUTES TLVs
IANA is requested to create a new "Measurement-Attribute 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:
Gandhi, et al. Expires 24 January 2027 [Page 44]
Internet-Draft PCEP for LSP Performance Measurement July 2026
+=========+=====================================+=================+
| 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 | Notify-Threshold sub-TLV | [This document] |
+---------+-------------------------------------+-----------------+
| 6 | Notify-Threshold-Percentage sub-TLV | [This document] |
+---------+-------------------------------------+-----------------+
| 7 | Notify-Interval sub-TLV | [This document] |
+---------+-------------------------------------+-----------------+
| 8 | Notify-Upper-Lower-Bound sub-TLV | [This document] |
+---------+-------------------------------------+-----------------+
| 9-65535 | Unassigned | [This document] |
+---------+-------------------------------------+-----------------+
Table 18: Measurement-Attribute Types
13.3.2. Flag Fields in Measurement-Enable sub-TLV
IANA is requested to create a registry with name "Measurement-Enable
Flags" 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 January 2027 [Page 45]
Internet-Draft PCEP for LSP Performance Measurement July 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 Notification | [This document] |
| | Enabled | |
+-----+------------------------------------+-----------------+
| 22 | Liveness Detection Enabled | [This document] |
+-----+------------------------------------+-----------------+
Table 19: Measurement-Enable Flags
13.4. Measurement Object-Class
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] |
+--------------+---------------------------+-----------------+
Table 20: Measurement Object-Class
Gandhi, et al. Expires 24 January 2027 [Page 46]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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:
+=============+=================================+=================+
| 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/ | [This document] |
| | Max Values | |
+-------------+---------------------------------+-----------------+
| 4 | One-Way Delay Variation | [This document] |
| | Measurement Value | |
+-------------+---------------------------------+-----------------+
| 5 | Two-Way Delay Measurement Value | [This document] |
+-------------+---------------------------------+-----------------+
| 6 | Two-Way Delay Measurement Min/ | [This document] |
| | Max Values | |
+-------------+---------------------------------+-----------------+
| 7 | Two-Way Delay Variation | [This document] |
| | Measurement Value | |
+-------------+---------------------------------+-----------------+
| 8 | Loopback Delay Measurement | [This document] |
| | Value | |
+-------------+---------------------------------+-----------------+
| 9 | Loopback Delay Measurement Min/ | [This document] |
| | Max Values | |
+-------------+---------------------------------+-----------------+
| 10 | Loopback Delay Variation | [This document] |
| | Measurement Value | |
+-------------+---------------------------------+-----------------+
Table 21: DELAY-MEASUREMENT Object-Types
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:
Gandhi, et al. Expires 24 January 2027 [Page 47]
Internet-Draft PCEP for LSP Performance Measurement July 2026
+=============+=============================+=================+
| 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] |
+-------------+-----------------------------+-----------------+
Table 22: LOSS-MEASUREMENT Object-Types
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] |
+-------------+------------------------------+-----------------+
Table 23: BANDWIDTH Object-Type
13.5. PCE Error Codes
This document defines new error-values for PCErr with error-code 19
(Invalid Operation). IANA is requested to make the following
allocations.
Gandhi, et al. Expires 24 January 2027 [Page 48]
Internet-Draft PCEP for LSP Performance Measurement July 2026
+=============+================================+===========+
| Error-Value | Name | Reference |
+=============+================================+===========+
| TBD21 | Delay-Measurement capability | [This |
| | was not advertised | document] |
+-------------+--------------------------------+-----------+
| TBD22 | Loss-Measurement capability | [This |
| | was not advertised | document] |
+-------------+--------------------------------+-----------+
| TBD23 | Two-Way Measurement capability | [This |
| | was not advertised | document] |
+-------------+--------------------------------+-----------+
| TBD24 | One-Way Measurement capability | [This |
| | was not advertised | document] |
+-------------+--------------------------------+-----------+
| TBD25 | Loopback Measurement | [This |
| | capability was not advertised | document] |
+-------------+--------------------------------+-----------+
| TBD26 | Inferred Mode Loss Measurement | [This |
| | capability was not advertised | document] |
+-------------+--------------------------------+-----------+
| TBD27 | Direct Mode Loss Measurement | [This |
| | capability was not advertised | document] |
+-------------+--------------------------------+-----------+
| TBD28 | Bandwidth Utilization | [This |
| | capability was not advertised | document] |
+-------------+--------------------------------+-----------+
| TBD29 | Liveness Detection capability | [This |
| | was not advertised | document] |
+-------------+--------------------------------+-----------+
Table 24: PCE Error Codes
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:
Gandhi, et al. Expires 24 January 2027 [Page 49]
Internet-Draft PCEP for LSP Performance Measurement July 2026
+===================+===================================+===========+
| Notification-type | Name | Reference |
+===================+===================================+===========+
| TBD13 | LSP Measurement Notification | [This |
| | | document] |
+-------------------+-----------------------------------+-----------+
| TBD14 | PM Overwhelm State | [This |
| | (Notification-value=1: | document] |
| | Entering PM overwhelm state; | |
| | Notification-value=2: | |
| | Clearing PM overwhelm state) | |
+-------------------+-----------------------------------+-----------+
Table 25: Notification Object Types
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-29, 23 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
multipath-29>.
[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>.
Gandhi, et al. Expires 24 January 2027 [Page 50]
Internet-Draft PCEP for LSP Performance Measurement July 2026
[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
over the MPLS Data Plane", Work in Progress, Internet-
Draft, draft-ietf-spring-stamp-srpm-mpls-03, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
stamp-srpm-mpls-03>.
[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-02, 6
July 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-spring-stamp-srpm-srv6-02>.
[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>.
Gandhi, et al. Expires 24 January 2027 [Page 51]
Internet-Draft PCEP for LSP Performance Measurement July 2026
[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>.
[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>.
Gandhi, et al. Expires 24 January 2027 [Page 52]
Internet-Draft PCEP for LSP Performance Measurement July 2026
[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)
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>.
Gandhi, et al. Expires 24 January 2027 [Page 53]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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 and capable of receiving and processing streaming
telemetry of PM metrics and may interact with the PCC and PCE for 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
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 notify 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 notify interval should be set to 0 to disable notifications to
the PCE. Only the upper bound threshold should be set.
Use case 2: PCC Notifies PM Metrics to the PCE, PCE Takes Action
PCE <----- PCC
In this use case, the PCC notifies 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 -
Gandhi, et al. Expires 24 January 2027 [Page 54]
Internet-Draft PCEP for LSP Performance Measurement July 2026
* 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 notifies the PM
metrics to the PCE when the upper bound is crossed. Otherwise,
the PCC notifies the PM metrics to the PCE every notify-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 notifications 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 notified before the crossing of the upper bound as
opposed to a reactive action that the PCC could make.
* The notify interval should be set to enable notifications 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
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 notifies 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 notify interval should be set to 0 to disable notifications to
the PCE. The other PM attributes may be set and used for
streaming telemetry.
Gandhi, et al. Expires 24 January 2027 [Page 55]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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 notifies 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 notifies 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 PCEP extensions defined in this document are not used in this
use case.
Acknowledgments
The authors would also like to thank Christian Schmutzer, Quan Xiong,
and Li Zhang for reviewing this document and providing useful
comments and suggestions.
Authors' Addresses
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Bin Wen
Comcast
Gandhi, et al. Expires 24 January 2027 [Page 56]
Internet-Draft PCEP for LSP Performance Measurement July 2026
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 January 2027 [Page 57]