| Internet-Draft | PCEP for LSP Performance Measurement | November 2025 |
| Gandhi, et al. | Expires 7 May 2026 | [Page] |
In certain networks, network performance data such as packet loss, delay and delay variation as well as bandwidth utilization is a critical measure for Traffic Engineering (TE). This data provides operators the characteristics of their networks for performance evaluation that is required to ensure the Service Level Agreements (SLAs).¶
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs') requests. The Stateful PCE extensions allow Stateful control of Traffic Engineering Paths using PCEP for both RSVP and Segment Routing (SR).¶
This document describes PCEP extensions for enabling and reporting end-to-end performance measurements for both PCE-Initiated and PCC-Initiated LSPs for both RSVP-TE and SR-TE (for MPLS and IPv6 Data planes) to an Active Stateful PCE.¶
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."¶
This Internet-Draft will expire on 7 May 2026.¶
Copyright (c) 2025 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.¶
[RFC5440] describes the Path Computation Element Protocol (PCEP) as a communication mechanism between a Path Computation Client (PCC) and a Path Control 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 TE LSPs. 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 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 constraint(s) and optimization criteria for Segment Routing. [RFC9603] extends PCEP for Segment Routing for IPv6 data plane. As specified in [RFC8664], an LSP can be RSVP-TE LSP or SR-TE LSP based on the path setup type. As specified in [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 SRv6 path setup type.¶
In certain networks, such as financial information networks, network performance data (e.g. packet loss, delay and delay variation, and bandwidth utilization) is a critical measure for traffic engineering. The protocol extensions have been defined to advertise link performance metrics, see [RFC7471], [RFC8570], [RFC7823] and [RFC8571]. This data provides operators the characteristics of their networks for performance evaluation that is required to ensure the Service Level Agreements (SLAs).¶
[RFC8233] defines the PCEP extensions for TE 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 a TE LSP may be very different from the path computation results due to many factors, such as queuing, etc. There is a need to verify and monitor that the traffic sent over the established TE LSPs does not exceed the requested metric bounds (e.g. total end-to-end delay/loss). The Stateful PCE may need to take some action (such as teardown or re-optimize the LSP) when the performance requirement is not met. [RFC8762] defines protocol extensions needed for measuring packet loss, delay and delay variation and can be used for end-to-end performance measurement of TE LSPs. In the case of SR-TE LSPs, SR Paths include Segment Lists, Candidate-Paths, and SR Policies.¶
This document describes PCEP extensions for enabling and reporting end-to-end performance measurements (PM) such as packet loss, delay, delay variation and bandwidth utilization for both PCE-Initiated and PCC-Initiated LSPs for RSVP-TE and SR-TE (for MPLS and IPv6 Data planes) to an Active Stateful PCE.¶
This section describes a non-exhaustive list of deployment use cases of PM for TE LSPs when deployed in a network with PCE. A Network Management System (NMS) may also be deployed in the network capable of receiving and processing "streaming telemetry" of PM metrics and may interact with PCC and PCE for the PM as described in use cases 3, 4 and 5.¶
Use case 1: PCE Enables PM on PCC and PCC Takes Action¶
PCE -----> PCC¶
In this use case, the PCE sets the upper-bound threshold condition for TE 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 PCE-initiated LSPs including 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, actions could be to bring down the LSP, trigger protection switch-over, remove tunnel from IGP for some prefixes, or request a new path from PCE (based on local policies which may be set by the PCE). PCC may take these actions even when LSPs are delegated to PCE as the upper-bound is set by the PCE.¶
PCC does not report the PM metrics to PCE.¶
PCC may install the new LSP in the routing table only if the PM metric is below the upper-bound, otherwise, the PCC may reject the LSP request and send an error to the PCE.¶
The report interval should be set to 0 to disable reporting to PCE. Only the upper-bound threshold should be set.¶
Use case 2: PCC Reports PM Metrics to PCE, PCE Takes Action¶
PCE <----- PCC¶
In this use case, the PCC reports the PM metrics and parameters to the PCE and the PCE may take an immediate local (reactive) action based on the PM metrics. The steps involved are -¶
PCC sends the PM metrics and parameters to PCE using the PCEP extensions defined in this document and PCE takes an action; actions could be to correlate faults, invalidate LSP path, send new LSP path to PCC (trigger re-optimization), etc.¶
If an upper-bound threshold is set, PCC only reports the PM metrics to PCE when the upper-bound is crossed. Otherwise the PCC reports the PM metrics to PCE every report-interval.¶
Optionally, PCC may take an immediate local (reactive) action such as trigger a path protection switch-over when PM metrics exceed the upper-bound.¶
PCE has a global view due to PM metric reports received from various PCCs and hence can make a better decision about LSP placement in the network.¶
PCE can make proactive decisions based on PM metrics when metrics are reported before crossing of the upper-bound as opposed to a reactive action that the PCC could make.¶
The report interval should be set to enable reporting by the PCC. Optionally, the upper-bound threshold may also be set.¶
Use case 3: PCE Enables PM on 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 reports the PM metrics to the NMS via "streaming telemetry".¶
The NMS may request the PCE to take an action based on the PM metrics.¶
The report interval should be set to 0 to disable reporting to PCE. The other PM attributes may be set and used for "streaming telemetry".¶
Use case 4: NMS Enables PM on PCC, PCC Sends PM Metrics to PCE¶
PCE <----- PCC <----- NMS¶
The steps involved are -¶
The NMS enables PM on PCC using a non-PCEP channel.¶
The PCC then reports the PM metrics to the PCE using the PCEP extensions defined in this document.¶
The PCE may take an action based on the PM metrics received from the PCC.¶
Use case 5: NMS Enables PM on PCC, PCC Sends PM Metrics to NMS¶
PCE ----> PCC <-----> NMS -----> PCE¶
The steps involved are -¶
Note that the specification of the use of the reported packet loss, delay, delay variation and bandwidth utilization measurements by a Stateful PCE is outside the scope of this document.¶
The auto-Bandwidth feature allows a head-end LSR (PCC) to automatically adjust the LSP bandwidth reservation based on the traffic demand of a TE LSP. Auto-bandwidth requested bandwidth computation can be implemented on a PCC or a Stateful PCE.¶
[RFC8733] describes the PCEP extensions for auto- bandwidth, where the requested bandwidth for the LSP is computed by the PCC and reported to the Stateful PCE. There is a benefit in pushing the responsibility for deciding when auto-bandwidth adjustments are needed to the PCC as this distributes the load of monitoring the bandwidth utilization of the LSPs down to the PCCs and frees up the PCE for path computations. In addition, it reduces the load on PCEP communications for reporting the bandwidth utilization of the LSP.¶
However, exactly when to adjust an LSP bandwidth could be better left to a Stateful PCE. That is, a PCE could be flexible in its interpretation of thresholds enabling it to trigger auto-bandwidth adjustment early if it believes there is a good reason (for example, doing 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 reporting defined in this document can be used by the PCE to do computations to determine whether auto-bandwidth adjustments are needed and/or desirable before performing the path computations.¶
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.¶
The reader is assumed to be familiar with the terminology defined in [RFC5440] and [RFC7471].¶
The measurement unit for delay value is defined in [RFC7471], Section 4.1.5.¶
The measurement unit for 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 (see [IEEE.754.1985]).¶
All average values are calculated as rolling averages.¶
The high-level overview of the PCEP extensions defined in this document for requesting and reporting end-to-end performance measurements and bandwidth utilization for TE LSPs is shown in Figure 1.¶
---------
| |
| PCE |
| |
---------
| ^
MEASUREMENT CAPABILITY | | MEASUREMENT CAPABILITY
| |
MEASUREMENT ATTRIBUTES | | MEASUREMENT ATTRIBUTES
| | (For delegated LSPs)
| |
| | MEASUREMENT REPORTS
v |
---------
| |
| PCC |
| |
---------
The following steps describe the PCEP extensions for reporting performance measurements and bandwidth utilization of TE LSPs:¶
The Stateful PCE and PCC (head-end of the LSP) advertise the capability of their support for the delay, loss and bandwidth- utilization measurements and reporting in the PCEP Open message (in the OPEN Object).¶
The Stateful PCE enables a measurement of a feature and sends and updates the configuration parameters of the feature using the LSPA object to PCC in PCInitiate and PCUpd messages respectively.¶
The PCC reports the measured values of the feature to the Stateful PCE at the end of the specified report-interval or when measured values cross the specified report-threshold. The periodic reporting can be used at the PCE to monitor the TE LSP metrics whereas report-threshold can be used to trigger an immediate action at the PCE on the TE LSP.¶
In some cases, the periodic reporting of the measurements may be disabled and only an upper-bound threshold is set, which when exceeded, a local or PCE-set action may be taken.¶
The PCE and PCC notify each other of their entering and clearing the overwhelmed state when operating under high LSP scale.¶
When explicitly configured, a report threshold (absolute or percentage) parameter (along with the configured number of counts) is used to trigger an immediate reporting of the delay and loss measurements and bandwidth utilization, bypassing the report interval. A threshold is used to detect a sudden change in the performance measurement metric of a TE LSP. In order to detect that a measured value has crossed the threshold, the measured (delay/loss) metric is compared with the last reported value. If the change (increase or decrease) in the value is above the threshold (absolute or percentage) consecutively for the given number of counts, the measurement from the current interval is reported immediately. In case of bandwidth utilization, the last reported MaxSampleBw (see [RFC8733]) value is compared with the MaxSampleBW from the the current interval to detect the threshold crossing. The delay and loss measurements are still reported at the end of the report interval even if they were reported due to the crossing of the threshold. Refer to [RFC7471], Section 5, for additional considerations.¶
All thresholds in this document could be represented in both absolute values and percentages, and could be used together. This is provided to accommodate the cases where the metric values may become very large or very small over time. For example, an operator may use the percentage threshold to handle small to large metric values and absolute values to handle very large metric values. The metrics are reported when either one of the two thresholds, the absolute or the percentage, is crossed.¶
When using the percentage threshold, if the metric changes rapidly at very low values, it may trigger frequent reporting due to the crossing of the percentage threshold. This can lead to unnecessary scale issues in the network. This is suppressed by setting the minimum-threshold parameter along with the percentage threshold. The metric value is only reported if the value crosses both the percentage threshold and the minimum-threshold parameters.¶
This section specifies the generic sub-TLVs that provide various configurable parameters for reporting measurements 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 8 Report-Threshold sub-TLV 6 8 Report-Threshold-Percentage sub-TLV 7 4 Report-Interval sub-TLV 8 8 Report-Upper-Bound sub-TLV¶
The Measurement-Enable sub-TLV MUST be added to the LSPA Object when the measurement feature is enabled for the LSP. All other sub-TLVs are optional and any unrecognized sub-TLV MUST be silently ignored. If a sub-TLV of the same type appears more than once, only the first occurrence is processed and all others MUST be ignored. If sub-TLVs are not present, the default values based on the local policy are assumed.¶
The Measurement-Enable sub-TLV specifies that the given measurement feature is enabled.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measurement-Enable sub-TLV Format
¶
The Type is 1, Length is 4 bytes, and the value comprises of flags (32 bits) for enabling various measurement features.¶
Unassigned flags are considered reserved, they MUST be set to 0 when sent and MUST be ignored when received. The flags define various performance measurement types in this document.¶
The Transmit-Interval sub-TLV specifies a time interval in milli-seconds for the test packet transmission.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transmit-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transmit-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 1 to 604800, in milli-seconds. The default value is 1 second. The Transmit-Interval MUST NOT be greater than the Measurement-Interval and Report-Interval.¶
The Measurement-Protocol sub-TLV specifies that the given measurement protocol type and measurement mode are enabled.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement-Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measurement-Protocol sub-TLV Format
¶
The Type is 8, Length is 8 bytes, and the value comprises of protocol type and measurement mode for performance measurement.¶
Measurement protocol type value can be set to: (1) STAMP protocol defined in [RFC8762], or (2) TWAMP protocol defined in [RFC5357], or (3) MPLS-PM protocol defined in [RFC6374].¶
Measurement mode value can be set to: (1) one-way, or (2) two-way, or (3) loopback mode.¶
The Measurement-Interval sub-TLV specifies a time interval in seconds for the measurement.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measurement-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measurement-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 seconds. The default value is 300 seconds. The Measurement-Interval MUST NOT be greater than Report-Interval.¶
The Report-Threshold sub-TLV specifies the threshold value used to trigger an immediate reporting of the measurements bypassing the report-interval.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report-Threshold sub-TLV Format
¶
The Type is 3, Length is 8 bytes, and the value comprises of - o Report-Threshold: 32-bit absolute threshold value.¶
Count: 8-bit integer counter. The number of consecutive measurement values MUST be above the threshold before reporting the measurement. The value 0 is considered to be invalid. By default, report-threshold is not set and threshold check based reporting is disabled.¶
RESERVED: It MUST be set to zero when sent and MUST be ignored when received.¶
The Report-Threshold-Percentage sub-TLV specifies the threshold value used to trigger an immediate reporting of the measurements bypassing the report-interval.¶
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=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Percentage | RESERVED | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report-Threshold-Percentage sub-TLV Format
¶
The Type is 4, Length is 8 bytes, and the value comprises of -¶
Percentage: 7-bit threshold value, encoded in percentage (an integer from 1 to 100).¶
Count: 8-bit integer counter. The number of consecutive measurement values MUST be above the threshold before reporting the measurement. The value 0 is considered to be invalid. By default, report-threshold-percentage is not set and threshold check based reporting is disabled.¶
RESERVED: It MUST be set to zero when sent and MUST be ignored when received.¶
Minimum-Threshold: The 32-bit absolute Minimum-Threshold value. The increase or decrease should be at least or above this value.¶
The Report-Interval sub-TLV specifies the time interval in seconds when measured values are to be reported.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=5 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report-Interval sub-TLV Format
¶
The Type is 5, Length is 4 bytes, and the value comprises a 4-byte time interval, the valid range is from 0 to 604800, in seconds. The default value is 3600 seconds. The value 0 is used to disable the periodic reporting of the measurements.¶
The Report-Upper-Bound sub-TLV specifies the upper-bound value used to trigger an immediate reporting of the measurements when crossed. This may also result in PCC taking an immediate local action on the LSP. Anomaly flag is set to true in the reported measurement when the upper-bound threshold is crossed.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESERVED | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report-Upper-Bound |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report-Upper-Bound sub-TLV Format
¶
The Type is 6, Length is 8 bytes, and the value comprises of -¶
Report-Upper-Bound: 32-bit absolute value.¶
Count: 8-bit integer counter. The number of consecutive measurement values MUST be above the upper-bound before reporting the measurement. The value 0 is considered to be invalid. By default, upper-bound is not set.¶
RESERVED: It MUST be set to zero when sent and MUST be ignored when received.¶
During 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 procedure is defined as following:¶
The PCEP protocol extensions for Delay Measurement MUST NOT be used if one or both PCEP Speakers have not included the DELAY- MEASUREMENT-CAPABILITY TLV in their respective Open message.¶
If the PCEP speaker that supports the extensions of this document but did not advertise this capability, then upon receipt of DELAY- MEASUREMENT-ATTRIBUTES TLV in the LSPA object, it SHOULD generate a PCErr with error-type 19 (Invalid Operation), error-value TBD7 (Delay-Measurement capability was not advertised) and it will terminate the PCEP session.¶
Similarly, the PCEP speaker SHOULD generate error-value TBD9 (Bidirectional Measurement capability was not advertised) and TBD10 (Unidirectional Measurement capability was not advertised) upon receipt of DELAY-MEASUREMENT-ATTRIBUTES TLV in the LSPA object with two-way measurement request and one-way measurement request, respectively, when it did not advertise this capability.¶
If the PCEP speaker that supports the extensions of this document but did not advertise this capability, then upon receipt of DELAY- MEASUREMENT object, it SHOULD generate a PCErr with error-type 19 (Invalid Operation), error-value TBD7 (Delay-Measurement capability was not advertised) and it will terminate the PCEP session.¶
The DELAY-MEASUREMENT-CAPABILITY TLV is an optional TLV for use in the OPEN Object for Delay Measurement via PCEP capability advertisement. Its format is shown in the following figure:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD1 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |T|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Measurement - 1 bit): if set to 1 by a PCC, the O Flag indicates that the PCC allows reporting of one-way delay measurement information; if set to 1 by a PCE, the O Flag indicates that the PCE is capable of receiving one-way delay measurement information from the PCC.¶
T (Two-way Delay Measurement - 1 bit): if set to 1 by a PCC, the T Flag indicates that the PCC allows reporting of two-way delay measurement information; if set to 1 by a PCE, the T Flag indicates that the PCE is capable of receiving two-way delay measurement information from the PCC.¶
Unassigned bits are considered reserved. They MUST be set to 0 when sent and MUST be ignored when received.¶
Advertisement of the DELAY-MEASUREMENT-CAPABILITY TLV implies support for delay measurement, as well as the objects, TLVs and procedures defined in this document. Either the O or T flag MUST be set in the 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 the following figure:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCEP TLV Type=TBD4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// sub-TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DELAY-MEASUREMENT-ATTRIBUTES TLV Format
¶
PCEP TLV Type is defined as following:¶
Type Name ---------------------------------------------------------- TBD4 DELAY-MEASUREMENT-ATTRIBUTES¶
Length: The Length field defines the length of the value portion in bytes as per [RFC5440].¶
Value: Comprises of one or more sub-TLVs as described in Section 4 of this document.¶
The following sub-sections describe the parameters that are currently defined to be carried within this TLV.¶
The Measurement-Enable sub-TLV specifies the delay measurement mode enabled using the following flags:¶
Bit Description ---------------------------------------------------------------- 31 One-Way Delay Measurement Enabled 30 Two-Way Delay Measurement Enabled 29 Loopback Delay Measurement Enabled¶
The Measurement-Interval sub-TLV specifies a time interval in seconds for the delay measurement.¶
The Report-Threshold sub-TLV specifies the threshold value used to trigger an immediate reporting of the delay measurements bypassing the report-interval.¶
The same report-threshold is used for all delay measurement values.¶
The Report-Threshold-Percentage sub-TLV specifies the threshold value used to trigger an immediate reporting of the measurements bypassing the report-interval.¶
The same report-threshold-percentage is used for all delay measurement values.¶
The Report-Interval sub-TLV specifies the time interval in seconds when measured delay values are to be reported.¶
The Report-Upper-Bound sub-TLV specifies the upper-bound value in microseconds, and is used to trigger an immediate reporting of the delay values when crossed. This may also result in PCC taking an immediate local action on the LSP.¶
The DELAY-MEASUREMENT Object with Object-Class (Value TBD16) is defined in this document to report the delay measurement of a TE LSP.¶
When the LSP is enabled with the delay measurement feature, the PCC SHOULD include the DELAY-MEASUREMENT Object to report the measured delay values to the PCE in the PCRpt message. The PCC SHOULD report (either one-way or two-way) average delay, min/max delay and delay variations to the PCE in the PCRpt message, as well as 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=TBD16 | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Measurement Value 3 12 One-Way Delay Measurement Min/Max Values 4 8 One-Way Delay Variation Measurement Value 5 8 Two-Way Delay Measurement Value 6 12 Two-Way Delay Measurement Min/Max Values 7 8 Two-Way Delay Variation Measurement Value 8 8 Loopback Delay Measurement Value 9 12 Loopback Delay Measurement Min/Max Values 10 8 Loopback Delay Variation Measurement Value¶
All delay values are reported in microseconds, encoded as a 24-bit integer, as defined in [RFC7471]. When set to the maximum value 16,777,215 (16.777215 sec), the delay is at least that value and may be larger.¶
The object body formats are defined as following:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DELAY-MEASUREMENT Object Body Format (Delay Measurement Status)¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DELAY-MEASUREMENT Object Body Format (One-Way, Two-Way and Loopback)¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DELAY-MEASUREMENT Object Body Format (One-Way, Two-Way and Loopback)¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DELAY-MEASUREMENT Object Body Format (One-Way, Two-Way and Loopback)¶
One-way Delay Measurement Value: Average Delay of the LSP in one (forward) direction.¶
One-way Delay Measurement Variation Value: Average Delay Variation of the LSP in one (forward) direction.¶
One-Way Delay Measurement Value Minimum/Maximum: Minimum and Maximum values of the Delay of the LSP in one (forward) direction.¶
Two-way Delay Measurement Value: Average Delay of the LSP in both (forward and reverse) directions.¶
Two-way Delay Measurement Variation Value: Average Delay Variation of the LSP in both (forward and reverse) directions.¶
Two-Way Delay Measurement Value Minimum/Maximum: Minimum and Maximum values of the Delay of the LSP in both (forward and reverse) directions.¶
Loopback Delay Measurement Value: Average Delay of the LSP in both (forward and reverse) directions.¶
Loopback Delay Measurement Variation Value: Average Delay Variation of the LSP in both (forward and reverse) directions.¶
Loopback Delay Measurement Value Minimum/Maximum: Minimum and Maximum values of the Delay of the LSP in both (forward and reverse) directions.¶
RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.¶
Delay Measurement Status: Indicates the Status of Delay Measurement as: (1) Active, (2) Failed, (3) Errored.¶
During 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 procedure is defined as following:¶
The PCEP protocol extensions for Loss Measurement MUST NOT be used if one or both PCEP Speakers have not included the LOSS- MEASUREMENT-CAPABILITY TLV in their respective Open message.¶
If the PCEP speaker that supports the extensions of this document but did not advertise this capability, then upon receipt of LOSS- MEASUREMENT-ATTRIBUTES TLV in the LSPA object, it SHOULD generate a PCErr with error-type 19 (Invalid Operation), error-value TBD8 (Loss-Measurement capability was not advertised) and it will terminate the PCEP session.¶
Similarly, the PCEP speaker SHOULD generate error-value TBD9 (Bidirectional Measurement capability was not advertised) and TBD10 (Unidirectional Measurement capability was not advertised) upon receipt of LOSS-MEASUREMENT-ATTRIBUTES TLV in the LSPA object with two-way measurement request and one-way measurement request, respectively, when it did not advertise this capability.¶
Further, the PCEP speaker SHOULD generate error-value TBD11 (Inferred Mode Loss Measurement capability was not advertised) and TBD12 (Direct Mode Loss Measurement capability was not advertised) upon receipt of 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 the PCEP speaker that supports the extensions of this document but did not advertise this capability, then upon receipt of LOSS- MEASUREMENT object, it SHOULD generate a PCErr with error-type 19 (Invalid Operation), error-value TBD8 (Loss-Measurement capability was not advertised) and it will terminate the PCEP session.¶
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 the following figure:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD2 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |N|I|B|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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):¶
U (Unidirectional Measurement - 1 bit): if set to 1 by a PCC, the U Flag indicates that the PCC allows reporting of unidirectional loss measurement information; if set to 1 by a PCE, the U Flag indicates that the PCE is capable of receiving unidirectional loss measurement information from the PCC.¶
B (Bidirectional Measurement - 1 bit): if set to 1 by a PCC, the B Flag indicates that the PCC allows reporting of bidirectional loss measurement information; if set to 1 by a PCE, the B Flag indicates that the PCE is capable of receiving bidirectional loss measurement information from the PCC. Bidirectional measurement is only applicable to the bidirectional LSPs.¶
I (Inferred Loss Measurement Mode - 1 bit): if set to 1 by a PCC, the I Flag indicates that the PCC allows reporting of inferred mode loss measurement information; if set to 1 by a PCE, the I Flag indicates that the PCE is capable of receiving inferred mode loss measurement information from the PCC.¶
N (Direct Loss Measurement Mode - 1 bit): if set to 1 by a PCC, the N Flag indicates that the PCC allows reporting of direct mode loss measurement information; if set to 1 by a PCE, the N Flag indicates that the PCE is capable of receiving direct mode loss measurement information from the PCC.¶
Unassigned bits are considered reserved. They MUST be set to 0 when sent and MUST be ignored when received.¶
Advertisement of the LOSS-MEASUREMENT-CAPABILITY TLV implies support for loss measurement, as well as the objects, TLVs and procedures defined in this document. Either the U or B flag MUST be set in the TLV. Similarly, either the I or N flag MUST be set in the TLV.¶
The LOSS-MEASUREMENT-ATTRIBUTES TLV provides the configurable parameters of the loss measurement feature.¶
The format of the LOSS-MEASUREMENT-ATTRIBUTES TLV is shown in the following figure:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCEP TLV Type=TBD5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// sub-TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LOSS-MEASUREMENT-ATTRIBUTES TLV Format
¶
PCEP TLV Type is defined as following:¶
Type Name ---------------------------------------------------------- TBD5 LOSS-MEASUREMENT-ATTRIBUTES¶
Length: The Length field defines the length of the value portion in bytes as per [RFC5440].¶
Value: Comprises of one or more sub-TLVs as described in Section 4 of this document.¶
The following sub-sections describe the parameters that are currently defined to be carried within this TLV.¶
The Measurement-Enable sub-TLV specifies the loss measurement mode enabled using the following flags:¶
Bit Description ----------------------------------------------------------------- 28 Unidirectional Loss Measurement Enabled 27 Bidirectional Loss Measurement Enabled 26 Inferred Loss Measurement Enabled¶
The Measurement-Interval sub-TLV specifies a time interval in seconds for the loss measurement.¶
The Report-Threshold sub-TLV specifies the threshold value used to trigger an immediate reporting of the loss measurements bypassing the report-interval.¶
Report-Threshold: This 24-bit field identifies the packet loss as a percentage of the total packets sent or received. The encoding is as per [RFC7471].¶
The same report-threshold is used for all loss measurement values.¶
The Report-Threshold-Percentage sub-TLV specifies the threshold value used to trigger an immediate reporting of the loss measurements bypassing the report-interval.¶
The same report-threshold-percentage is used for all loss measurement values.¶
The Report-Interval sub-TLV specifies the time interval in seconds when measured loss values are to be reported.¶
The Report-Upper-Bound sub-TLV specifies the upper-bound value in percentage packet loss, and is used to trigger an immediate reporting of the packet loss values when crossed. This may also result in PCC taking an immediate local action on the LSP.¶
The LOSS-MEASUREMENT Object with Object-Class (Value TBD17) is defined in this document to report the packet loss measurement of a TE LSP.¶
When the LSP is enabled with the loss measurement feature, the PCC SHOULD include the LOSS-MEASUREMENT Object to report the measured packet loss to the PCE in the PCRpt message, as well as 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=TBD17 | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LOSS-MEASUREMENT Object Format
¶
Object Length (16 bits): Specifies the total object length including the header, in bytes [RFC5440].¶
Object-Types (OT) are defined as following:¶
Object-Type Length Name ------------------------------------------------------------- 1 8 Loss Measurement Status 2 8 Tx Packets-Lost 3 8 Rx Packets-Lost 4 12 Total Packets-Sent-Received¶
The object body format for Loss Measurement Status is defined as following:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LOSS-MEASUREMENT Object Body Format (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 defined as following:¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LOSS-MEASUREMENT Object Body Format (Lost Tx and Rx)
¶
Packets-Lost: This 24-bit field identifies the packet loss as a percentage of the total packets sent or received, encoded as per [RFC7471].¶
RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.¶
The Packets-Lost in the Rx direction is reported when bidirectional loss measurement is enabled.¶
The object body format for Total Packets is defined as following:¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LOSS-MEASUREMENT Object Body Format (Total Tx and Rx)
¶
During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) advertise their support for bandwidth utilization reporting. A PCEP Speaker includes the "BANDWIDTH-UTILIZATION-CAPABILITY" TLV, in the OPEN Object to advertise its support for PCEP extensions. The presence of the "BANDWIDTH-UTILIZATION-CAPABILITY" TLV in the OPEN Object (in the Open message) indicates that the bandwidth utilization reporting is supported as described in this document. Additional procedure is defined as following:¶
The PCEP protocol extensions for bandwidth utilization MUST NOT be used if one or both PCEP Speakers have not included the "BANDWIDTH-UTILIZATION-CAPABILITY" TLV in their respective Open message.¶
If the PCEP speaker that supports the extensions of this document but did not advertise this capability, then upon receipt of BANDWIDTH-UTILIZATION-ATTRIBUTES TLV in the LSPA object, it SHOULD generate a PCErr with error-type 19 (Invalid Operation), error- value TBD13 (Bandwidth utilization capability was not advertised) and it will terminate the PCEP session.¶
If the PCEP speaker that supports the extensions of this document but did not advertise this capability, then upon receipt of BANDWIDTH-UTILIZATION object of type TBD14, it SHOULD generate a PCErr with error-type 19 (Invalid Operation), error-value TBD13 (Bandwidth utilization capability was not advertised) and it will terminate the PCEP session.¶
The BANDWIDTH-UTILIZATION-CAPABILITY TLV is an optional TLV for use in the OPEN Object for Bandwidth Utilization reporting via PCEP capability advertisement. Its format is shown in the following figure:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD3 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 reporting, as well as the objects, TLVs and procedures defined in this document.¶
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 the following figure:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCEP TLV Type=TBD6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// sub-TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BW-UTILIZATION-MEASUREMENT-ATTRIBUTES TLV Format
¶
PCEP TLV Type is defined as following:¶
Type Name ---------------------------------------------------------- TBD6 BW-UTILIZATION-MEASUREMENT-ATTRIBUTES¶
Length: The Length field defines the length of the value portion in bytes as per [RFC5440].¶
Value: Comprises of one or more sub-TLVs as described in Section 4 of this document.¶
The following sub-sections describe the parameters that are currently defined to be carried within this TLV.¶
The Measurement-Enable sub-TLV specifies that the bandwidth utilization reporting is enabled using the following flag:¶
Bit Description ------------------------------------------------------------------ 25 Bandwidth Utilization Reporting Enabled¶
The Measurement-Interval sub-TLV specifies a time interval in seconds for the bandwidth samples collection interval.¶
The Report-Threshold sub-TLV is used to decide if the bandwidth samples collected so far should be immediately reported bypassing the report-interval.¶
Threshold: The absolute threshold bandwidth value in 32-bits, encoded in IEEE floating-point format (see [IEEE.754.1985]), expressed in bytes per second.¶
The Report-Threshold-Percentage sub-TLV is used to decide if the bandwidth samples collected so far should be immediately reported bypassing the report-interval.¶
The Report-Interval sub-TLV specifies a time interval in seconds when the collected bandwidth samples are to be reported to PCE.¶
The Report-Upper-Bound sub-TLV specifies the upper-bound bandwidth encoded in IEEE floating-point format (see [IEEE.754.1985]), expressed in bytes per second, and is used to trigger an immediate reporting when crossed. This may also result in PCC taking an immediate local action on the LSP.¶
A new object-type for the existing BANDWIDTH Object (Object-Class 5) is defined to report the bandwidth utilization of a TE LSP.¶
When the TE LSP is enabled with the bandwidth utilization reporting, the PCC SHOULD include the BANDWIDTH-UTILIZATION Object to report the bandwidth utilization of the TE LSP to the PCE in the PCRpt message.¶
The object-type is TBD14, the object length is variable with multiples of 4 bytes.¶
The object body format is defined as following:¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BANDWIDTH-UTILIZATION Object Body Format
¶
BwSample: The utilized bandwidth, (the average BwSample collected at the end of each measurement-interval) encoded in IEEE floating-point format (see [IEEE.754.1985]), expressed in bytes per second.¶
The following procedure is defined for the extensions to different PCEP messages for reporting performance measurements.¶
For a PCE-Initiated LSP [RFC8281] with reporting features enabled, the corresponding MEASUREMENT-ATTRIBUTES TLV for each measurement MUST be included in the LSPA Object with the PCInitiate message.¶
For a PCE-Initiated LSP [RFC8281] with reporting features enabled, the corresponding MEASUREMENT-ATTRIBUTES TLV for each measurement is carried in the PCUpd message in the LSPA Object in order to make updates to the attributes such as Report-Interval.¶
For a PCC-Initiated LSP with reporting features enabled, when the LSP is delegated to the PCE, the corresponding MEASUREMENT- ATTRIBUTES TLV for each measurement MUST be included in the LSPA Object of the PCRpt message.¶
The various MEASUREMENT-ATTRIBUTES TLVs are encoded in all PCEP messages for the LSP with reporting features enabled, the absence of the corresponding MEASUREMENT-ATTRIBUTES TLV indicates that the PCEP speaker wishes to disable the feature.¶
When a TE LSP is enabled with a measurement reporting feature, the PCC SHOULD include the corresponding MEASUREMENT Object to report the measured values to the PCE in the PCRpt message [RFC8231].¶
The format of the "actual_attribute-list" in the PCRpt message is modified as following:¶
<actual_attribute-list>::=[<BANDWIDTH>]
[<DELAY-MEASUREMENT>]
[<LOSS-MEASUREMENT>]
[<metric-list>]
¶
It should be noted that when measurement reporting is deployed under LSP scaling, it can lead to frequent reporting updates to the PCE. Operators are advised to set the values of various measurement reporting parameters appropriate for the deployed LSP scaling.¶
If a PCE gets overwhelmed, it can notify the PCC to temporarily suspend the reporting of the measurements as described below.¶
As per [RFC5440], the PCEP Notification message (PCNtf) can be sent by a PCEP speaker to notify its peer of a specific event. A PCEP speaker SHOULD notify its PCEP peer that it is overwhelmed, and on receipt of such notification the peer SHOULD NOT send any PCEP messages related to measurement reporting. If a PCEP message related to measurement reporting is received, it MUST be silently ignored.¶
When a PCEP speaker is overwhelmed, it SHOULD notify its peer by sending a PCNtf message with Notification Type = TBD15 (PM Overwhelm State) and Notification Value = 1 (Entering PM overwhelm state).¶
Optionally, OVERLOADED-DURATION TLV [RFC5440] MAY be included that specifies the time period during which no further PCEP messages related to PM should be sent.¶
When the PCEP speaker is no longer in the overwhelmed state and is available to process the PM reporting, it SHOULD notify its peer by sending a PCNtf message with Notification Type = TBD15 (PM Overwhelm State) and Notification Value = 2 (Clearing PM overwhelm state).¶
This document defines new MEASUREMENT-ATTRIBUTES TLVs, CAPABILITY TLVs and MEASUREMENT Objects for reporting loss, delay measurements and bandwidth utilization that do not add additional security concerns beyond those discussed in [RFC5440], [RFC8231], [RFC8281] and [RFC8664].¶
Some deployments may find the reporting of the performance measurement and bandwidth utilization information as extra sensitive as it could be used to influence LSP path computation and LSP setup with 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 TCP Authentication Option (TCP-AO) [RFC5925] or Transport Layer Security [RFC8253].¶
The performance measurement reporting SHOULD be controlled per TE tunnel (at PCC or PCE) and the values for feature attributes e.g. measurement-interval, report-interval, report-threshold SHOULD be configurable by an operator.¶
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 support for performance measurement reporting feature. Support for various configuration knobs as well as for counters of messages sent/received containing the TLVs (defined in this document) SHOULD be added.¶
Mechanisms defined in this document do not imply any new operational verification requirements in addition to those already listed in [RFC5440].¶
Mechanisms defined in this document do not add any new requirements on other protocols.¶
In order to avoid any unacceptable impact on network operations, an implementation SHOULD allow a limit to be placed on the number of LSPs that can be enabled with the performance measurement reporting feature. An implementation MAY allow a limit to be placed on the rate of measurement reporting messages sent by a PCEP speaker and received by a peer. An implementation MAY also allow sending a notification when a PCEP speaker is overwhelmed or the rate of messages reaches a threshold.¶
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]¶
IANA is requested to create a registry to manage the Flag field of the DELAY-MEASUREMENT-CAPABILITY TLV, LOSS-MEASUREMENT-CAPABILITY TLV and BANDWIDTH-UTILIZATION-CAPABILITY TLV.¶
New bit numbers are allocated only by an IETF Review action [RFC8126]. Each bit should be tracked with the following qualities:¶
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]¶
LOSS-MEASUREMENT-CAPABILITY TLV:¶
Bit Description Reference ---------------------------------------------------------------- 31 Unidirectional Loss Measurement [This document] 30 Bidirectional Loss Measurement [This document] 29 Inferred Loss Measurement Mode [This document] 28 Direct Loss Measurement Mode [This document]¶
This document defines the following new PCEP TLV Types; IANA is requested to make the following TLV type allocations from the "PCEP TLV Type Indicators" registry. http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators¶
Type Name Reference ----------------------------------------------------------------- TBD4 DELAY-MEASUREMENT-ATTRIBUTES [This document] TBD5 LOSS-MEASUREMENT-ATTRIBUTES [This document] TBD6 BW-UTILIZATION-MEASUREMENT-ATTRIBUTES [This document]¶
IANA is requested to create a "MEASUREMENT-ATTRIBUTES Sub-TLV Types" sub-registry in the "PCEP TLV Type Indicators" registry. New sub-TLVs are allocated only by an IETF Review action [RFC8126].¶
This document defines the following sub-TLV types:¶
Type Name Reference ------------------------------------------------------------- 0 Reserved [This document] 1 Measurement-Enable sub-TLV [This document] 2 Transmit-Interval sub-TLV [This document] 3 Measurement-Protocol sub-TLV [This document] 4 Measurement-Interval sub-TLV [This document] 5 Report-Threshold sub-TLV [This document] 6 Report-Threshold-Percentage sub-TLV [This document] 7 Report-Interval sub-TLV [This document] 8 Report-Upper-Bound sub-TLV [This document] 9- Unassigned [This document] 65535¶
IANA is requested to create a registry to manage the Flag field of the Measurement-Enable sub-TLV.¶
New bit numbers are allocated only by an IETF Review action [RFC8126]. Each bit should be tracked with the following qualities:¶
The following value are defined in this document for the Flag field.¶
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 Unidirectional Loss Measurement Enabled [This document] 27 Bidirectional Loss Measurement Enabled [This document] 26 Inferred Loss Measurement Enabled [This document] 25 Bandwidth Utilization Reporting Enabled [This document]¶
This document defines Object-Class for the following Objects; IANA is requested to make the following allocations from the "PCEP Objects" registry. http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects¶
Object-Class Name Reference -------------------------------------------------------------- TBD16 DELAY-MEASUREMENT Object [This document] TBD17 LOSS-MEASUREMENT Object [This document]¶
IANA is requested to create a "DELAY-MEASUREMENT Object-Types" sub-registry for DELAY-MEASUREMENT Object (Object-class TBD16).¶
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/Max Values [This document] 4 One-Way Delay Variation Measurement Value [This document] 5 Two-Way Delay Measurement Value [This document] 6 Two-Way Delay Measurement Min/Max Values [This document] 7 Two-Way Delay Variation Measurement Value [This document] 8 Loopback Delay Measurement Value [This document] 9 Loopback Delay Measurement Min/Max Values [This document] 10 Loopback Delay Variation Measurement Value [This document]¶
IANA is requested to create a "LOSS-MEASUREMENT Object-Types" sub-registry for LOSS-MEASUREMENT Object (Object-class TBD17).¶
This document defines the following object-types:¶
Object-Type Name Reference -------------------------------------------------------------- 0 Reserved [This document] 1 Loss Measurement Status [This document] 2 Tx Packets-Lost [This document] 3 Rx Packets-Lost [This document] 4 Total Packets-Sent-Received [This document]¶
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 -------------------------------------------------------------- TBD14 BANDWIDTH-UTILIZATION Object [This document]¶
This document defines two new error-values for PCErr with error-code 19 (Invalid Operation). IANA is requested to make the following allocations.¶
Error-Value Name Reference
-------------------------------------------------------------------
TBD7 Delay-Measurement capability
was not advertised [This document]
TBD8 Loss-Measurement capability
was not advertised [This document]
TBD9 Bidirectional Measurement capability
was not advertised [This document]
TBD10 Unidirectional Measurement capability
was not advertised [This document]
TBD11 Inferred Mode Loss Measurement capability
was not advertised [This document]
TBD12 Direct Mode Loss Measurement capability
was not advertised [This document]
TBD13 Bandwidth Utilization capability
was not advertised [This document]
¶
IANA is requested to allocate new Notification Types and Notification Values within the "Notification Object" sub-registry of the PCEP Numbers registry, as follows:¶
Type Meaning Reference
-----------------------------------------------------------------
TBD15 PM Overwhelm State [This document]
Notification-value=1: Entering PM overwhelm state
Notification-value=2: Clearing PM overwhelm state
¶
TBA.¶