| Internet-Draft | PCEP for LSP Performance Measurement | October 2026 |
| Gandhi, et al. | Expires 16 April 2027 | [Page] |
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 specifies PCEP extensions that enable and notify end-to-end performance measurements, including liveness detection, for PCE-Initiated and PCC-Initiated LSPs. The extensions apply to SR-TE in the MPLS and IPv6 data planes and to MPLS-TE using RSVP, with notification 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 16 April 2027.¶
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.¶
[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. Protocol extensions define mechanisms for advertising link-performance metrics; see [RFC7471], [RFC8570], [RFC7823], and [RFC8571]. These metrics provide operators with the characteristics for evaluating performance against Service-Level Agreements (SLAs).¶
[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 differ significantly from the path computation results because of factors such as queuing. 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 specifies PCEP extensions for enabling and notifying end-to-end PM, such as packet loss, delay, delay variation, and bandwidth utilization, including liveness detection for both PCE-Initiated and PCC-Initiated LSPs over SR-TE in 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.¶
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 specifies PCEP extensions for sending measured bandwidth values to a Stateful PCE, enabling the PCE to implement auto-bandwidth, a function 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. Pushing responsibility for deciding when auto-bandwidth adjustments are needed to the PCC has benefits because it 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, 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.¶
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], [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.¶
In the reference topology shown in Figure 1, there is an LSP to transport data between the head-end node H1 and the tail-end node T1. The head-end node H1 initiates a test packet, and the tail-end node T1 transmits a reply test packet.¶
|<----------- LSP ----------->|
| |
| T1 T2 |
| / \ |
+-------+ Test Packet +-------+
| | - - - - - - - - - ->| |
| H1 |=====================| T1 |
| |<- - - - - - - - - - | |
+-------+ Reply Test Packet +-------+
\ /
T4 T3
Head-End Node (PCC) Tail-End Node
T1 is a transmit timestamp, and T4 is a receive timestamp added by node H1. T2 is a receive timestamp, and T3 is a transmit timestamp added by node T1.¶
This document uses delay metrics defined in [RFC6374], specifically the one-way delay metric defined as (T2 - T1); the two-way delay metric defined as ((T4 - T1) - (T3 - T2)); and the round-trip delay metric defined as (T4 - T1).¶
The one-way delay metric is also referred to as "Unidirectional Delay" in [RFC7471] and [RFC8570].¶
The computation of the one-way delay metric requires the clocks on the H1 and T1 nodes to be synchronized using either PTPv2 or NTPv4.¶
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.¶
The high-level overview of the PCEP extensions specified in this document for requesting and notifying end-to-end PM, including 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 2.¶
+---------+
| |
| Stateful|
| PCE |
| |
+---------+
| ^
MEASUREMENT CAPABILITY | | MEASUREMENT CAPABILITY
| |
MEASUREMENT ATTRIBUTES | | MEASUREMENT ATTRIBUTES
| | (For delegated LSPs)
| |
| | MEASUREMENT NOTIFICATIONS
v | (Optional)
+---------+
| |
| PCC |
| |
+---------+
The following list provides a high-level overview of the PCEP extensions for both PCE-Initiated and PCC-Initiated LSPs specified in this document:¶
The Stateful PCE and PCC (the 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.¶
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.¶
When explicitly configured, a notify-threshold parameter, expressed as an absolute value or a percentage, 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 metric is compared with the previously notified value. If the change (increase or decrease) in the value is greater than or equal to the threshold (absolute or percentage), the measurement from the current interval is notified immediately.¶
The percentage change is calculated as 100 times the absolute difference between the current value and the previously notified value, divided by the previously notified value. When the previously notified value is zero, the percentage threshold is considered crossed if the current value is nonzero; in this case, the Minimum-Threshold condition MUST also be met before notification. If both values are zero, the percentage threshold is not crossed.¶
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 notified only if it crosses both the percentage threshold and the minimum-threshold value.¶
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.¶
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-Mode 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 |
The Measurement-Enable sub-TLV MUST be added to the LSPA object when the measurement feature is enabled for an 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. 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=1 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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 4.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=2 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmit-Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is 2, Length is 4 bytes, and the value comprises a 4-byte time interval. The valid range is 1 to 604800 milliseconds. The default value is 1 second. When periodic notification is enabled (Notify-Interval is greater than 0), the Transmit-Interval MUST NOT be greater than the Measurement-Interval or the Notify-Interval.¶
The Measurement-Protocol-Mode sub-TLV specifies that the given measurement protocol type and mode are enabled. 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=3 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Measurement-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Measurement-Mode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is 3, Length is 8 bytes, and the value comprises the measurement protocol and measurement mode.¶
The measurement protocol type value can be set to: (1) STAMP protocol [RFC8762], or (2) TWAMP protocol [RFC5357], or (3) MPLS-PM protocol [RFC6374].¶
For the STAMP protocol, the measurement mode can be set to: One-Way, Two-Way, or Loopback mode.¶
The measurement modes are defined in [I-D.ietf-spring-stamp-srpm-srv6] for SRv6 and [I-D.ietf-spring-stamp-srpm-mpls] and [RFC9779] for SR-MPLS. For the MPLS-PM protocol, the measurement modes are defined in [RFC6374].¶
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. The PM procedures defined in [RFC6374] can be used for MPLS LSPs.¶
The Measurement-Interval sub-TLV specifies a time interval in seconds for the measurement. 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=4 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Measurement-Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is 4, Length is 4 bytes, and the value comprises a 4-byte time interval. The valid range is 1 to 604800 seconds. The default value is 300 seconds. When periodic notification is enabled (Notify-Interval is greater than 0), the Measurement-Interval MUST NOT be greater than the Notify-Interval.¶
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 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=5 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Notify-Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
For delay measurements, the 24-bit delay value defined in [RFC7471] is carried in the least significant 24 bits; the most significant 8 bits MUST be set to zero when sent and MUST be ignored when received. For loss measurements, the 24-bit loss value defined in [RFC7471] is carried in the least significant 24 bits, with the most significant 8 bits set to zero when sent and ignored when received. For bandwidth utilization, the entire 32-bit value is encoded as IEEE 754 single precision in bytes per second. The same metric-specific encodings apply to the Minimum-Threshold field and the upper and lower bound fields defined in this document.¶
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 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=6 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Percentage | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum-Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is 6, Length is 8 bytes, and the value comprises:¶
Percentage: 7-bit threshold value, encoded in percentage as an integer from 1 to 100.¶
By default, 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 equal to or greater than this value.¶
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 9.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is 7, Length is 4 bytes, and the value comprises a 4-byte time interval. The valid range is 0 to 604800 seconds. The default value is 3600 seconds. The value 0 is used to disable the periodic notification of the measurements.¶
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 10.¶
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.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type is 8, Length is 8 bytes, and the value comprises:¶
Notify-Upper-Bound: 32-bit absolute value.¶
When unset, this field MUST be set to 0xFFFFFFFF.¶
Notify-Lower-Bound: 32-bit absolute value.¶
When unset, this field MUST be set to 0xFFFFFFFF.¶
A receiver MUST recognize 0xFFFFFFFF as the unset sentinel before interpreting either bound according to its metric-specific encoding. This sentinel MUST NOT be used for a configured bound. If both bounds are unset, the Notify-Upper-Lower-Bound sub-TLV MUST be omitted. When both bounds are configured, the lower bound MUST be less than the upper bound.¶
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 defined in this document but has not advertised this capability, then upon receipt of the DELAY-MEASUREMENT-ATTRIBUTES TLV in the LSPA object, it SHOULD generate a PCErr with error-type 19 (Invalid Operation), error-value TBD21 (Delay-Measurement capability was not advertised) and terminate the PCEP session.¶
Similarly, the PCEP speaker SHOULD generate error-value TBD23 (Two-Way Measurement capability was not advertised), TBD24 (One-Way Measurement capability was not advertised) and TBD25 (Round-Trip Measurement capability was not advertised) upon receipt of the DELAY-MEASUREMENT-ATTRIBUTES TLV in the LSPA object with Two-Way, One-Way, and Round-Trip measurement requests, respectively, when it did not advertise this capability.¶
If a PCEP speaker supports the extensions defined in this document but has not advertised 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.¶
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 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=TBD1 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |R|T|O| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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): The O flag indicates support for the One-Way delay Measurement. If set to 1 by a PCC, it indicates that the PCC allows notification of one-way delay metric information; if set to 1 by a PCE, it indicates that the PCE is capable of receiving that information from the PCC. Timestamps T1 and T2 are used to measure the one-way delay metric, defined as (T2 - T1) in Section 2.4 of [RFC6374].¶
T (Two-Way Delay Measurement - 1 bit): The T flag indicates support for the Two-Way delay Measurement. If set to 1 by a PCC, it indicates that the PCC allows notification of two-way delay metric information; if set to 1 by a PCE, it indicates that the PCE is capable of receiving that information from the PCC. All four timestamps T1, T2, T3, and T4 are used to measure the two-way delay metric, defined as ((T4 - T1) - (T3 - T2)) in Section 2.4 of [RFC6374].¶
R (Round-Trip Delay Measurement - 1 bit): The R flag indicates support for the Round-Trip delay Measurement. If set to 1 by a PCC, it indicates that the PCC allows notification of round-trip delay metric information; if set to 1 by a PCE, it indicates that the PCE is capable of receiving that information from the PCC. Timestamps T1 and T4 are used to measure the round-trip delay metric, defined as (T4 - T1) in Section 2.4 of [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 R flag MUST be set to 1 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 Figure 12.¶
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 // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCEP TLV Type is defined as follows:¶
| Type | Name |
|---|---|
| TBD5 | DELAY-MEASUREMENT-ATTRIBUTES |
Length: The Length field defines the length of the value portion in bytes, as per [RFC5440].¶
Value: Comprises 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.¶
The Measurement-Enable sub-TLV specifies the delay measurement using the following flags:¶
| Bit | Description |
|---|---|
| 31 | One-Way Delay Measurement Enabled |
| 30 | Two-Way Delay Measurement Enabled |
| 29 | Round-Trip Delay Measurement Enabled |
The Measurement-Protocol-Mode sub-TLV specifies that the given protocol type and mode are enabled for delay measurement.¶
The Transmit-Interval sub-TLV specifies a time interval in milliseconds for the delay measurement test packet transmission.¶
The Measurement-Interval sub-TLV specifies a time interval in seconds for the delay metrics computation for the LSP.¶
The Notify-Threshold sub-TLV specifies the threshold value used to trigger an immediate notification of the delay metrics bypassing the notify-interval.¶
The same notify-threshold is used for all delay metric values.¶
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.¶
The Notify-Interval sub-TLV specifies the time interval in seconds when measured delay values are to be notified.¶
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.¶
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 13.¶
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 the average delay, minimum and maximum delay values, and delay variation 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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Round-Trip Delay Metric Value |
| 9 | 12 | Round-Trip Delay Metric Min/Max Values |
| 10 | 8 | Round-Trip Delay Variation Metric Value |
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 14, Figure 15, Figure 16, and 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Delay Measurement Status: Indicates the delay-measurement status: (1) active, (2) failed, or (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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
Round-Trip Delay Value Average: Average round-trip 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One-Way Delay Value Minimum/Maximum: Minimum and maximum delay values for the LSP in one (forward) direction.¶
Two-Way Delay Value Minimum/Maximum: Minimum and maximum delay values for the LSP in both forward and reverse directions.¶
Round-Trip Delay Value Minimum/Maximum: Minimum and Maximum values of the round-trip 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
Round-Trip Delay Variation Value: Average delay variation of the round-trip delay measurements of the LSP.¶
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.¶
If a PCEP speaker supports the extensions defined in this document but has not advertised 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 (Round-Trip Measurement capability was not advertised) upon receipt of the LOSS-MEASUREMENT-ATTRIBUTES TLV in the LSPA object with two-way, one-way, and loopback (round-trip) measurement requests, respectively, when it did not advertise this capability.¶
Further, the PCEP speaker SHOULD generate error-value TBD26 (Inferred Loss Measurement capability was not advertised) and TBD27 (Direct 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 defined in this document but has not advertised 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.¶
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 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=TBD2 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |N|I|R|T|O| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the TLV is TBD2 and it has a fixed length of 4 bytes.¶
The value comprises a single field - Flags (32 bits):¶
O (One-Way Loss Measurement - 1 bit): If set to 1 by a PCC, the O flag indicates that the PCC allows notification of one-way loss measurement 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. The one-way loss metric is defined as transmit loss in [RFC6374].¶
T (Two-Way Loss Measurement - 1 bit): If set to 1 by a PCC, the T flag indicates that the PCC allows notification of two-way loss measurement 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. The two-way loss metric is defined as transmit + receive loss in [RFC6374].¶
R (Round-Trip Loss Measurement - 1 bit): If set to 1 by a PCC, the R flag indicates that the PCC allows notification of round-trip loss measurement information; if set to 1 by a PCE, the R flag indicates that the PCE is capable of receiving round-trip loss metric information from the PCC. The round-trip loss metric is transmit loss in loopback mode as defined in [RFC6374].¶
I (Inferred Loss Measurement - 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 - 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 R flag MUST be set to 1 in the TLV. Similarly, either the I or N flag MUST be set to 1 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 Figure 19.¶
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 // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCEP TLV Type is defined as follows:¶
| Type | Name |
|---|---|
| TBD6 | LOSS-MEASUREMENT-ATTRIBUTES |
Length: The Length field defines the length of the value portion in bytes, as per [RFC5440].¶
Value: Comprises 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.¶
The Measurement-Enable sub-TLV specifies the loss measurement using the following flags:¶
| Bit | Description |
|---|---|
| 28 | One-Way Loss Measurement Enabled |
| 27 | Two-Way Loss Measurement Enabled |
| 26 | Round-Trip Loss Measurement Enabled |
| 25 | Inferred Loss Measurement Enabled |
| 24 | Direct Loss Measurement Enabled |
The Measurement-Protocol-Mode sub-TLV specifies that the given protocol type and mode are enabled for loss measurement.¶
The Transmit-Interval sub-TLV specifies a time interval in milliseconds for the loss measurement test packet transmission.¶
The Measurement-Interval sub-TLV specifies a time interval in seconds for the loss metric computation for the LSP.¶
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.¶
The Notify-Threshold-Percentage sub-TLV specifies the threshold value used to trigger an immediate notification of the loss metrics bypassing the notify-interval.¶
The same notify-threshold-percentage is used for all loss metric values.¶
The Notify-Interval sub-TLV specifies the time interval in seconds when measured loss values are to be notified.¶
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.¶
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 20.¶
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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Length (16 bits): Specifies the total object length including the header in bytes, as per [RFC5440].¶
Object-Types (OT) are defined as follows:¶
| Object-Type | Length | Name |
|---|---|---|
| 1 | 8 | Loss Measurement Status |
| 2 | 8 | Tx Packet Loss Percentage |
| 3 | 8 | Rx Packet Loss Percentage |
| 4 | 12 | Total Packets-Sent-Received |
The object body format for Loss Measurement Status 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loss Measurement Status: Indicates the loss-measurement status: (1) active, (2) failed, or (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 Packet Loss Percentage 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| RESERVED | Packet Loss Percentage | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet Loss Percentage: This 24-bit field identifies the packet loss as a percentage of the total number of packets transmitted, encoded as per [RFC7471].¶
RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.¶
The object body format for Total Packets Sent and Received is shown in Figure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Packets Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Packets Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 defined in this document but has not advertised 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 defined in this document but has not advertised this capability, then upon receipt of the BANDWIDTH-UTILIZATION object of type TBD12, it SHOULD generate a PCErr with error-type 19 (Invalid Operation), error-value TBD28 (Bandwidth utilization capability was not advertised) and terminate the PCEP session.¶
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 24.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCEP TLV Type=TBD3 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
The BANDWIDTH-UTILIZATION-ATTRIBUTES TLV provides the configurable parameters of the bandwidth utilization feature.¶
The format of the BANDWIDTH-UTILIZATION-ATTRIBUTES TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCEP TLV Type=TBD7 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // sub-TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCEP TLV Type is defined as follows:¶
| Type | Name |
|---|---|
| TBD7 | BANDWIDTH-UTILIZATION-ATTRIBUTES |
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.¶
The Measurement-Enable sub-TLV specifies that bandwidth utilization measurement is enabled using the following flag:¶
| Bit | Description |
|---|---|
| 23 | Bandwidth Utilization Measurement Enabled |
The Measurement-Interval sub-TLV specifies a time interval in seconds for collecting bandwidth samples for the LSP.¶
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.¶
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.¶
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.¶
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.¶
A new object-type for the existing BANDWIDTH object (Object-Class 5) is defined to notify the bandwidth utilization of an LSP.¶
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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BwSample1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BwSampleN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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.¶
If a PCEP speaker supports the extensions defined in this document but has not advertised 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.¶
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 27.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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 28.¶
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 // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCEP TLV Type is defined as follows:¶
| Type | Name |
|---|---|
| TBD8 | LIVENESS-DETECTION-ATTRIBUTES |
Length: The Length field defines the length of the value portion in bytes, as per [RFC5440].¶
Value: Comprises 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.¶
The Measurement-Enable sub-TLV specifies the liveness detection enabled using the following flags:¶
| Bit | Description |
|---|---|
| 22 | Liveness Detection Enabled |
The Measurement-Protocol-Mode sub-TLV specifies that the given protocol type and loopback mode are enabled for liveness detection.¶
The Transmit-Interval sub-TLV specifies a time interval in milliseconds for the liveness detection loss test packet transmission.¶
The Measurement-Interval sub-TLV specifies the time interval, in seconds, for detecting liveness failures. The measurement interval MUST be a multiple of transmit interval.¶
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 29.¶
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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Length (16 bits): Specifies the total object length including the header, in bytes [RFC5440].¶
Object-Types (OT) are defined as follows:¶
| Object-Type | Length | Name |
|---|---|---|
| 1 | 8 | Liveness State |
The object body format for Liveness Detection State is shown in Figure 30.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following procedures are defined for the extensions to different PCEP messages that notify PM.¶
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.¶
The corresponding MEASUREMENT-ATTRIBUTES TLVs are included in all PCEP messages for an LSP with notification features enabled. Their absence indicates that the PCEP speaker wishes to disable the feature.¶
| Sub-TLV Type | Delay (TLV Type: TBD5) | Loss (TLV Type: TBD6) | BW (TLV Type: TBD7) | Liveness (TLV Type: TBD8) |
|---|---|---|---|---|
| Measurement-Enable Flags (bit-position, mandatory sub-TLV) | 31: One-Way Delay Measurement Enabled 30: Two-Way Delay Measurement Enabled 29: Round-Trip Delay Measurement Enabled |
28: One-Way Loss Measurement Enabled; 27: Two-Way Loss Measurement Enabled; 26: Round-Trip Loss Measurement Enabled; 25: Inferred Loss Measurement Enabled; 24: Direct Loss Measurement Enabled | 23: Bandwidth Utilization Measurement Enabled | 22: Liveness Detection Enabled |
| Transmit-Interval | Applicable | Applicable | Not applicable | Applicable |
| Measurement-Protocol-Mode | Applicable | Applicable | Not applicable | Applicable |
| Measurement-Interval | Applicable | Applicable | Applicable | Applicable (Detection Interval) |
| Notify-Threshold | Applicable | Applicable | Applicable | Not applicable |
| Notify-Threshold-percentage, minimum-threshold | Applicable | Applicable | Applicable | Not applicable |
| Notify-Interval | Applicable | Applicable | Applicable | Not applicable |
| Notify-Upper-Lower-bound | Applicable | Applicable | Applicable | Not applicable |
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 (Notification-type TBD13, Notification-value 1). 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.¶
This message is informational. It does not replace the PCUpd message, MUST NOT alter the ERO/RRO forwarding-hop instructions, and MUST NOT be considered an alternative to PCUpd.¶
The RBNF format of the LSP Measurement Notification message (PCNtf) (type TBD13) is defined as follows:¶
<PCNtf Message> ::= <Common Header>
<notify-list>
<notify-list> ::= <notify> [<notify-list>]
<notify> ::= [<request-id-list>]
[<lsp-list>]
<notification-list>
<request-id-list> ::= <RP> [<request-id-list>]
<lsp-list> ::= <LSP> [<path>] [<lsp-list>]
<notification-list> ::= <NOTIFICATION> [<notification-list>]
<path> ::= <intended-path> [<actual-path>]
<intended-path> ::= ( [<ERO>] <attribute-list> ) |
( <PATH-ATTRIB> [<ERO>] <attribute-list>
[<intended-path-multipath>] )
<intended-path-multipath> ::= ( <PATH-ATTRIB> [<ERO>]
[<intended-path-multipath>] )
<actual-path> ::= ( [<RRO>] <attribute-list> ) |
( <PATH-ATTRIB> [<RRO>] <attribute-list>
[<actual-path-multipath>] )
<actual-path-multipath> ::= ( <PATH-ATTRIB> [<RRO>]
[<actual-path-multipath>] )
<attribute-list> ::= [<BANDWIDTH>]
[<delay-measurement-list>]
[<loss-measurement-list>]
[<LIVENESS-DETECTION>]
[<metric-list>]
<delay-measurement-list> ::= <DELAY-MEASUREMENT>
[<delay-measurement-list>]
<loss-measurement-list> ::= <LOSS-MEASUREMENT>
[<loss-measurement-list>]
<metric-list> ::= <METRIC> [<metric-list>]
¶
A path MAY carry multiple DELAY-MEASUREMENT objects and multiple LOSS-MEASUREMENT objects. Each object carries one Object-Type, and an Object-Type MUST NOT occur more than once for the same path.¶
In the case of a 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.¶
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.¶
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).¶
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].¶
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 on PCEP messages containing 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].¶
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.¶
The PM notification SHOULD be controlled on a per-LSP basis (at the PCC or PCE), and an operator SHOULD be able to configure feature attributes such as the measurement interval, notify interval, and notify threshold.¶
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.¶
Mechanisms defined in this document do not imply any new operational verification requirements.¶
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 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.¶
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] |
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:¶
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 Capability | [This document] |
| 30 | Two-Way Delay Measurement Capability | [This document] |
| 29 | Round-Trip Delay Measurement Capability | [This document] |
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 Capability | [This document] |
| 30 | Two-Way Loss Measurement Capability | [This document] |
| 29 | Round-Trip Loss Measurement Capability | [This document] |
| 28 | Inferred Loss Measurement Capability | [This document] |
| 27 | Direct Loss Measurement Capability | [This document] |
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 | BANDWIDTH-UTILIZATION-ATTRIBUTES | [This document] |
| TBD8 | LIVENESS-DETECTION-ATTRIBUTES | [This document] |
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:¶
| Type | Name | Reference |
|---|---|---|
| 0 | Reserved | [This document] |
| 1 | Measurement-Enable sub-TLV | [This document] |
| 2 | Transmit-Interval sub-TLV | [This document] |
| 3 | Measurement-Protocol-Mode 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] |
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:¶
The following values 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 | Round-Trip Delay Measurement Enabled | [This document] |
| 28 | One-Way Loss Measurement Enabled | [This document] |
| 27 | Two-Way Loss Measurement Enabled | [This document] |
| 26 | Round-Trip Loss Measurement Enabled | [This document] |
| 25 | Inferred Loss Measurement Enabled | [This document] |
| 24 | Direct Loss Measurement Enabled | [This document] |
| 23 | Bandwidth Utilization Measurement Enabled | [This document] |
| 22 | Liveness Detection Enabled | [This document] |
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] |
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 Metric Value | [This document] |
| 3 | One-Way Delay Metric Min/Max Values | [This document] |
| 4 | One-Way Delay Variation Metric Value | [This document] |
| 5 | Two-Way Delay Metric Value | [This document] |
| 6 | Two-Way Delay Metric Min/Max Values | [This document] |
| 7 | Two-Way Delay Variation Metric Value | [This document] |
| 8 | Round-Trip Delay Metric Value | [This document] |
| 9 | Round-Trip Delay Metric Min/Max Values | [This document] |
| 10 | Round-Trip Delay Variation Metric Value | [This document] |
IANA is requested to create a "LOSS-MEASUREMENT Object-Types" sub-registry for the LOSS-MEASUREMENT object (Object-class TBD10).¶
This document defines the following object-types:¶
| Object-Type | Name | Reference |
|---|---|---|
| 0 | Reserved | [This document] |
| 1 | Loss Measurement Status | [This document] |
| 2 | Tx Packet Loss Percentage | [This document] |
| 3 | Rx Packet Loss Percentage | [This document] |
| 4 | Total Packets-Sent-Received | [This document] |
IANA is requested to create a "LIVENESS-DETECTION Object-Types" sub-registry for the LIVENESS-DETECTION object (Object-Class TBD11).¶
This document defines the following object-types:¶
| Object-Type | Name | Reference |
|---|---|---|
| 0 | Reserved | [This document] |
| 1 | Liveness State | [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 |
|---|---|---|
| TBD12 | BANDWIDTH-UTILIZATION Object | [This document] |
This document defines new error-values for PCErr with error-code 19 (Invalid Operation). IANA is requested to make the following allocations.¶
| Error-Value | Name | Reference |
|---|---|---|
| TBD21 | Delay-Measurement capability was not advertised | [This document] |
| TBD22 | Loss-Measurement capability was not advertised | [This document] |
| TBD23 | Two-Way Measurement capability was not advertised | [This document] |
| TBD24 | One-Way Measurement capability was not advertised | [This document] |
| TBD25 | Round-Trip Measurement capability was not advertised | [This document] |
| TBD26 | Inferred Loss Measurement capability was not advertised | [This document] |
| TBD27 | Direct Loss Measurement capability was not advertised | [This document] |
| TBD28 | Bandwidth Utilization capability was not advertised | [This document] |
| TBD29 | Liveness Detection capability was not advertised | [This document] |
IANA is requested to make the following allocations in the "Notification Object" registry of the PCEP Numbers registry.¶
| Notification-type | Name | Notification-value | Reference |
|---|---|---|---|
| TBD13 | LSP Measurement Notification | 0: Unassigned | [This document] |
| 1: LSP Measurement Notification | [This document] | ||
| 2-255: Unassigned | |||
| TBD14 | PM Overwhelm State | 0: Unassigned | [This document] |
| 1: Entering PM overwhelm state | [This document] | ||
| 2: Clearing PM overwhelm state | [This document] | ||
| 3-255: Unassigned |
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. It can receive and process streaming telemetry for 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.¶
The PCC takes action when PM metrics exceed the upper-bound threshold. Possible actions include bringing down the LSP, triggering a protection switchover, or removing the LSP from the 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 periodically notify the PM metrics to the PCE. Threshold-crossing notifications remain enabled when configured.¶
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 periodic 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 -¶
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 periodic notifications to the PCE. Threshold-based notifications may still be triggered if configured. The other PM attributes may be set and used for streaming telemetry.¶
Use case 4: NMS Enables PM on the PCC, PCC Sends PM Metrics to the PCE¶
PCE <----- PCC <----- NMS¶
The steps involved are -¶
The NMS enables PM on the PCC using a non-PCEP channel.¶
The PCC then 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 authors would also like to thank Christian Schmutzer, Quan Xiong, and Li Zhang for reviewing this document and providing useful comments and suggestions.¶