PCE L. M. Contreras Internet-Draft Telefonica Intended status: Informational F. Agraz Expires: 5 January 2026 S. Spadaro Universitat Politecnica de Catalunya Q. Xiong ZTE Corporation 4 July 2025 Path Computation Based on Precision Availability Metrics draft-contreras-pce-pam-05 Abstract The Path Computation Element (PCE) is able of determining paths according to constraints expressed in the form of metrics. The value of the metric can be signaled as a bound or maximum, meaning that path metric must be less than or equal such value. While this can be sufficient for certain services, some others can require the utilization of Precision Availability Metrics (PAM). This document defines a new object, namely the PRECISION METRIC object, to be used for path calculation or selection for networking services with performance requirements expressed as Service Level Objectives (SLO) using PAM. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 January 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Contreras, et al. Expires 5 January 2026 [Page 1] Internet-Draft PAM-based PCE July 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Rationale of the usage of PAM for path calculation . . . . . 4 3.1. Dynamic behavior of performance parameters . . . . . . . 4 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Usage of collected metrics . . . . . . . . . . . . . . . 5 4. PRECISION METRIC Object . . . . . . . . . . . . . . . . . . . 6 4.1. Motivation for a new object to express precision metrics . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Definition of the PRECISION METRIC Object . . . . . . . . 7 4.3. Summary of the PRECISION METRIC Object . . . . . . . . . 11 4.4. Examples on the usage of the PRECISION METRIC Object. . . 12 4.4.1. PRECISION METRIC coding examples . . . . . . . . . . 12 4.4.2. PRECISION METRIC operation examples . . . . . . . . . 14 4.5. Interaction between precision metric object and the metric object . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. PCEP message extensions . . . . . . . . . . . . . . . . . . . 15 5.1. The PCReq Message . . . . . . . . . . . . . . . . . . . . 15 5.2. The PCRep Message . . . . . . . . . . . . . . . . . . . . 16 5.3. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 17 6. Related work . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security and operational considerations . . . . . . . . . . . 18 7.1. Security considerations . . . . . . . . . . . . . . . . . 18 7.2. Operational considerations . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Contreras, et al. Expires 5 January 2026 [Page 2] Internet-Draft PAM-based PCE July 2025 1. Introduction The Path Computation Element (PCE) [RFC4655] is able of determining paths according to constraints expressed in the form of metrics. For that purpose, the METRIC object is defined in [RFC5440]. The value of the metric included in the METRIC object can be signaled as a bound or maximum, meaning that path metric must be less than or equal such value. While this can be sufficient for certain services, some others can require the utilization of Precision Availability Metrics (PAM) [RFC9544]. That is the case of services like Network Slice [RFC9543] or deterministic [RFC8578] [RFC8655] services. These networking services express their performance requirements by means of Service Level Objectives (SLO) with target values for certain metrics. At the time of calculating a path by the PCE, the METRIC object [RFC5440] serves for the purposes of indicating either the metric that MUST be optimized by the path computation algorithm, or a bound on the path cost that MUST NOT be exceeded for the path to be considered as acceptable. The value of the metric refers to the instantaneous observed behavior of that parameter, without a notion of behavior along the preceding time. This cannot be sufficient for certain networking services which require to experience stable behavior along the time according to their SLOs. The precision availability metrics indicate whether or not a given service has been available according to expectations along the time, for whatever SLO considered as constraint. Thus, at the time of computing a path for networking services described by means of SLOs, it is convenient to express the applicable metric constraints according to the definition of precision availability metrics. This permits the PCE to calculate paths showing a behavior compatible to the desired SLOs over a period. This document defines new object, namely the PRECISION METRIC object, using PAM for that purpose. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In addition, the terms defined in [RFC9544] are also used in this document. Contreras, et al. Expires 5 January 2026 [Page 3] Internet-Draft PAM-based PCE July 2025 3. Rationale of the usage of PAM for path calculation 3.1. Dynamic behavior of performance parameters [RFC9544] introduced the concept of intervals for measuring the behavior of measurable performance parameters against some predefined thresholds. Those intervals consider a given time window. Thus, it is possible to define a Violated Interval (VI) as the time interval during which at least one of the performance parameters presents degradation respect to a predefined optimal level threshold. Similarly, when the threshold is defined as critical, the degradation of the performance parameter in a time window generates a Severe Violated Interval (SVI). Taking into account the VIs and SVIs it is feasible to generate availability metrics showing some degree of historic behavior in the form of the following ratios: * Violated Interval Ratio (VIR), defined as the ratio of the summed numbers of VIs and SVIs to the total number of time unit intervals along a predefined availability period. * Severely Violated Interval Ratio (SVIR), defined as the ratio of SVIs to the total number of time unit intervals along a predefined availability period. At the time of provisioning a networking service which requires stable SLOs along the time, it is important to ensure that the selected path has shown such stable behavior in the past. Despite the fact that the past behavior is not a guarantee of future behavior, it can be presumed that those paths with lower VIR and SVIR will better satisfy the SLOs of the networking service. Alternatively, PAM can be used by the path computation entity for fine-grained path computation. Then PAM is a useful criteria for calculating and selecting paths. 3.2. Applicability Three situations of applicability of precision metrics can be identified: * The provision of a path according to the desired behavior along the time. In this scenario different segments of a potential path could be monitored before the path is created. The path calculation can take into consideration the measured characteristics of the segments forming that path for decision. Contreras, et al. Expires 5 January 2026 [Page 4] Internet-Draft PAM-based PCE July 2025 * The selection of a path according to its long-run characteristics. In this scenario, an existing path being monitored along the time can be selected if its behavior is compliant with the long-run behavior expected by the customer. * The triggering of corrective actions for a selected path. It could be the case that a selected path suffers degradation. The precision metrics can assist on the identification of such potential problems, e.g, raising incidents or anomalies to operational groups, as described in [I-D.ietf-nmop-network-incident-yang]. 3.3. Usage of collected metrics The Traffic Engineering Database (TED) defined in [RFC4655] could be considered as the component providing the precision metrics of interest. The TED stores information related to the network topology, including nodes, links, link attributes (e.g., bandwidth, delay), and any constraints relevant for traffic engineering. It is dynamically updated with information received via routing protocols (e.g., OSPF- TE, IS-IS-TE), ensuring the PCE has up-to-date knowledge. It is also possible to define policies like administrative group (coloring), to be used used in constraint-based path computation. In orther to support precision metrics, the TED could be extended to support e.g. time-series storage and processing capabilities (e.g., to derivbe from them histograms). The metrics could be gathered from in-band telemetry, active probing mechanisms, or streaming telemetry via standardized interfaces, as complementary information sources to the information received from routing protocols. Assuming that capability, the PCE queries the TED for compliance with precision constraints. Contreras, et al. Expires 5 January 2026 [Page 5] Internet-Draft PAM-based PCE July 2025 - Topology Path computation request - Single value metrics based on PAM metrics - Precision metrics +-------------+ +-------------+ +-------------+ | Path | | Path | | Traffic | | Computation |<------->| Computation |<------->| Engineering | | Client | | Element | | Database | +-------------+ +-------------+ +-------------+ ^ | v +-------------+ | Data | | Sources | +-------------+ - Link state info - Active Probes - Streaming telemetry - In-band OAM - etc Figure 1: Usage of precision metrics stored in TED The implementation of the TED and its support to the collection, processing and generation of the precision metrics is out of scope of this document. 4. PRECISION METRIC Object 4.1. Motivation for a new object to express precision metrics The existing METRIC object [RFC5440] is used to specify either the metric that the path computation algorithm MUST optimize or a constraint on the path cost (i.e., an upper bound) that MUST NOT be exceeded for the path to be deemed acceptable. A number of metric types to be used in the METRIC object have been already defined in IANA registries [IANA_METRIC_Object]. There are several reasons for proposing the definition of a new object for dealing with precission metrics instead of forcing the augmentation of the existing METRIC object: Contreras, et al. Expires 5 January 2026 [Page 6] Internet-Draft PAM-based PCE July 2025 * The notion of precision metric refers to the fact on how the metric is described, that is, in terms of tiers constituting a statistical distribution of the metric of interest. This implies that the metric type does not change if the metric is expressed as precision metric or not. Them extending the type in the METRIC object for including the notion of precision can create inconsistencies. * Not all the existing metric types currently defined for the METRIC object could (easily) adhere to the notion of precision metrics (e.g., number of layers on a path). * The current structure of the METRIC object is not sufficiently flexible for permitting a clean description of the precision metrics. * The precision metrics can be independent of the exsiting metric in the METRIC object, and can be implemented simultaneously or separately. The former limitations make preferble the introduction of a new object facilitating a lean design for the way of expressing precision metrics at the time of performing path calculations with the PCE. 4.2. Definition of the PRECISION METRIC Object The PRECISION METRIC object is defined according to the following structure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |C|S| Type | Stat Function | Tiers | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AvPeriod | TI_Units | TI_Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Violated Interval Ratio | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Severely Violated Interval Ratio | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Thresholds ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: PRECISION METRIC object The following fields are defined. Contreras, et al. Expires 5 January 2026 [Page 7] Internet-Draft PAM-based PCE July 2025 * From the Flags field, two flags are defined in this document. o S flag (Statistical - 1 bit): determines if the metric follows a statistical distribution function. When S=0, it means that the metric will be assessed against an optimal (for VI) and a critical (for SVI) thresholds. When S=1, it means that the metric will be assessed against a multi-tiered SLO, presenting different thresholds per tier. In case the SLO is defined in N tiers, each tier is associated with a threshold. Following the example in [RFC9544], a latency metric defined in this way could be expressed in the form of + not to exceed 30 ms for any packet; + to not exceed 25 ms for 99.999% of packets; + to not exceed 20 ms for 99% of packets. o C (Computed Metric - 1 bit), with similar meaning and implications to the C flag defined on the METRIC object in [RFC5440]. That is, when C=1 in a PCReq message it indicates that the PCE MUST provide the computed path precision metric value in the PCRep message. o Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. * Type (8 bits): specifies the metric type. The valid metric type values are those allocated by IANA for the original METRIC object T field. (Note. To check with PCE WG if this is the correct approach, or if alternatively it is convenient to allocate specific values for the PRECISION METRIC object). * Stat Function field (8 bits): in case S=1, this field determines the statistical function for describing the SLO. The following functions are considered: - 0x0: this is a reserved value. - 0x1: histogram - 0x2: cumulative distribution function - 0x3 - 0x255: these are reserved for future use. When S=0, this field SHOULD be ignored. * Tiers (8 bits): determines the number of tiers in which the statistical distribution of the SLO is defined. The following values are considered: Contreras, et al. Expires 5 January 2026 [Page 8] Internet-Draft PAM-based PCE July 2025 - 0x0-0x1: these are invalid values. - 0x2: two tiers, valid for the case S=0. - 0x3- 0x255: multiple tiers, valid for the case S=1. * AvPeriod (Availability Period - 8 bits): specifies the total number of of time unit intervals to be considered for the calculation of VIR and SVIR shown by the path. * TI_Units (Time Interval Units - 8 bits): specifies the units for the definition of the time window of the interval. The following units are considered: - 0x0: this is a reserved value. - 0x1: microsecond - 0x2: millisecond - 0x3: second - 0x4: minute - 0x5: hour - 0x6: day - 0x7: week - 0x8: month - 0x9: year - 0x10 - 0x255: these are reserved for future use. A PRECISION METRIC Object with values 0x0 or 0x1 SHOULD be discarded. A PRECISION METRIC Object with S=0 and Tiers field different than 0x2 SHOULD be discarded. This value implies that the Threshold field will be composed by an Optimal Threshold (for VI) and a Critical Threshold (for SVI). Finally, a PRECISION METRIC Object with S=1 and Tiers field lower than 0x3 SHOULD be discarded. When a generic value of N is provided in this field, it implies that the Threshold field will be compose by N-1 thresholds (for VI per tier) and a Critical Threshold (for SVI corresponding to the highest tier). * TI_Value (Time Interval Value - 16 bits): specifies the numerical value for the definition of the time window of the interval. * Violated Interval Ratio (32 bits): specifies the expected VIR for the path, encoded in 32 bits in IEEE floating point format [IEEE.754.2019]. The VIR of the path calculated by the PCE SHOULD be lower or equal than this value. The way in which the PCE calculates the VIR is out of scope of this document. * Severely Violated Interval Ratio (32 bits): specifies the expected SVIR for the path, encoded in 32 bits in IEEE floating point format [IEEE.754.2019]. The SVIR of the path calculated by the PCE SHOULD be lower or equal than this value. The way in which the PCE calculates the SVIR is out of scope of this document. Contreras, et al. Expires 5 January 2026 [Page 9] Internet-Draft PAM-based PCE July 2025 Regarding the Thresholds field, this will be variable in size depending on the statistical nature of the precision metric. When the metric is defined only according to an optimal and critical thresholds (S=0 case), then only those thresholds are included in the field. However, when the SLO is defined by means of a multi-tiered statistical distribution (S=1 case), then one threshold field is included per tier. In summary, this would be the different possible situations for the Thresholds field: * S=0, meaning that only an optimal and critical thresholds are considered. In this case, the Thresholds field follows the following structure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optimal Threshold Tier Boundary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optimal Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Critical Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Structure of Thresholds field for S=0 The Optimal Threshold Tier Boundary, the Optimal Threshold and the Critical Threshold fields are encoded in 32 bits in IEEE floating point format [IEEE.754.2019]. * S=1, meaning that only an optimal and critical thresholds are considered. In this case, the Thresholds field follows the following structure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tier 1 Boundary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold for Tier 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tier N-1 Boundary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold for Tier N-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Critical Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Contreras, et al. Expires 5 January 2026 [Page 10] Internet-Draft PAM-based PCE July 2025 Figure 4: Structure of Thresholds field for S=1 All the Threshold fields are encoded in 32 bits in IEEE floating point format [IEEE.754.2019]. The way in which the PCE calculates the different thresholds is out of scope of this document. 4.3. Summary of the PRECISION METRIC Object The PRECISION METRIC Object is extended to take into consideration PAMs. The PRECISION METRIC object is defined to accommodate the expression of constraints following the PAM proposition in [RFC9544]. According to the definition before, and depending on the statistical description of the SLO, two different messages can be found. When S=0 the SLO or metric is defined against an optimal and a critical thresholds. In consequence, the message format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |C|0| Type | Stat Function | 0x2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AvPeriod | TI_Units | TI_Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Violated Interval Ratio | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Severely Violated Interval Ratio | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optimal Threshold Tier Boundary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optimal Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Critical Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Complete structure of PRECISION METRIC object for S=0 In this case, the message has a fixed size of 28 bytes. When S=1 the SLO or metric is defined following an statistical distribution with N tiers, representing a total of N-1 optimal thresholds plus a critical one. In consequence, the message format is as follows: Contreras, et al. Expires 5 January 2026 [Page 11] Internet-Draft PAM-based PCE July 2025 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |C|1| Type | Stat Function | 0xN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AvPeriod | TI_Units | TI_Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Violated Interval Ratio | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Severely Violated Interval Ratio | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tier 1 Boundary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold for Tier 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tier N-1 Boundary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold for Tier N-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Critical Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Complete structure of PRECISION METRIC object for S=1 In this case, the message has a variable size determined by (4+(2N- 1))*4 bytes, being N the number of tiers of the SLO statistical distribution. 4.4. Examples on the usage of the PRECISION METRIC Object. 4.4.1. PRECISION METRIC coding examples The following are examples of usage of the PRECISION METRIC Object. Path Delay metric type is used as precision metric in these examples. The first example assumes a a networking service characterized by a SLO defined by means of two tiers with optimal threshold of 20 ms for 99,9% of the packet latency samples, and critical threshold of 25 ms. The availability expectation for this service is to show a VIR of 5% and a SVIR of 0,2%. The availability period considered is one day, while the time interval is considered 1 hour. In these conditions, the extended METRIC Object can be descrined as: Contreras, et al. Expires 5 January 2026 [Page 12] Internet-Draft PAM-based PCE July 2025 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |C|0| Type = 12 | n/a | 0x2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AvPeriod= 24 | TI_Units= sec | TI_Value= 3600 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Violated Interval Ratio= 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Severely Violated Interval Ratio= 0.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optimal Threshold Tier Boundary= 99.9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optimal Threshold= 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Critical Threshold= 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Example of usage of PRECISION METRIC object with a SLO defined by two tiers The second example takes the example of statistical distribution in [RFC9544], where the path delay metric is statistically defined in the form of: - not to exceed 30 ms for any packet; - to not exceed 25 ms for 99.999% of packets; - to not exceed 20 ms for 99% of packets Assuming similar VIR, SVIR, availability period and time interval duration. In these conditions, he extended METRIC Object can be descrined as: Contreras, et al. Expires 5 January 2026 [Page 13] Internet-Draft PAM-based PCE July 2025 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |C|1| Type = 12 | ST= Histogram | 0x3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AvPeriod= 24 | TI_Units= sec | TI_Value= 3600 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Violated Interval Ratio= 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Severely Violated Interval Ratio= 0.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tier 1 Boundary= 99.9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold for Tier 1= 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tier 2 Boundary= 99.999 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Threshold for Tier 1= 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Critical Threshold= 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Example of usage of PRECISION METRIC object with a SLO defined by a statistical distribution Once the PCE processes these PRECISION METRICT Objects, the PCE will calculate the VIR and SVIR of the different path alternatives and check them against the requested VIR and SVIR. How the PCE calculate the VIR and SVIR is out of scope of this document. 4.4.2. PRECISION METRIC operation examples The example considers a PCC sending a path computation request to the PCE, including a PRECISION METRIC object detailing path delay described in terms of SLO, and a METRIC object indicating that the path loss must not exceed the value of M. The two objects are inserted in the PCReq message as follows: o First PRECISION METRIC object coded as in the previous examples, depending on the applicable SLO. o Second METRIC object with B=1, T=14, metric-value=M In case the PRECISION METRIC contains flag C = 1, as per [RFC5440], in case there is a path satisfying the set of constraints and there is no policy that prevents the return of the computed metric, then the PCE inserts in its response one PRECISION METRIC object with T=12 and the corresponding SLO description for that path (i.e., all the Contreras, et al. Expires 5 January 2026 [Page 14] Internet-Draft PAM-based PCE July 2025 fields contained in the definition of the PRECISION METRIC Object). Additionally, the PCE MAY insert a second METRIC object with B=1, T=14, metric-value=computed path loss. 4.5. Interaction between precision metric object and the metric object The precision metric type values in the PRECISION METRIC object are intended to reuse the valid metric type values which are allocated by IANA for the original METRIC object T field. The precision metric object and metric object may be both carried as the constraints for path computing, but they must be set to different type values for valid path requests. It could be the case that a path request could contain both a METRIC and a PRECISION METRIC objects for the same type of metric, for instance, delay. This behavior can be considered anomalous and, as such, the PCE will send back a PCErr message , for example, a Error- Type "Invalid Operation" and Error-Value "Unsupported Metric Object and PAM metric Object with same type". 5. PCEP message extensions Message formats in this document are expressed using Routing Backus- Naur Form (RBNF). This is an initial attempt for defining the proposed extensions to PCEP messages on top of [RFC8233] definitions. Note. Further revision of these formats is needed. Consider them as an initial exercise by now. 5.1. The PCReq Message The extension to the PCReq message would be as follows: * New optional PRECISION METRIC object * New metric types using the optional PRECISION METRIC object The format of the PCReq message (with [RFC5541], [RFC8231] and [RFC8233] as a base) is updated as follows: Contreras, et al. Expires 5 January 2026 [Page 15] Internet-Draft PAM-based PCE July 2025 ::= [] where: ::= [] [] [] [] ::= [] ::= [] [] [] [] [] [] [] [[]] [] [] and where: ::= [] Figure 9: PCReq Message 5.2. The PCRep Message The extension to the PCReq message would be as follows: * New optional PRECISION METRIC object (during unsuccessful path computation based on precision metrics, to indicate the precision metrics requested which are reason for failure) * New metric types using the optional PRECISION METRIC object The format of the PCRep message (with [RFC5541], [RFC8231] and [RFC8233] as a base) is updated as follows: Contreras, et al. Expires 5 January 2026 [Page 16] Internet-Draft PAM-based PCE July 2025 ::= [] where: ::= [] [] [] [] ::= [] ::= [] [] [] [] ::= [] ::= and where: ::= [] [] [] [] [] [] [] ::= [] Figure 10: PCRep Message 5.3. The PCRpt Message The PCRpt message can use the updated attribute-list (as extended in previous section) for the purpose of including the PRECISION-METRIC object. Contreras, et al. Expires 5 January 2026 [Page 17] Internet-Draft PAM-based PCE July 2025 6. Related work In the case of deterministic networking, other documents like [I-D.xiong-pce-detnet-bounded-latency] and [I-D.zhang-pce-enhanced-detnet] propose extensions to PCE adapted to deterministic service capabilities. As part of those capabilities specific metrics are considered. Such metrics could be considered as SLOs that can be handled as PAM. This document presents a generic form of using precision availability metrics in PCEP messages, and then permitting its applicability to broader networking scenarios. Thus, this extension could be used instead of ad-hoc extensions in [I-D.xiong-pce-detnet-bounded-latency] and [I-D.zhang-pce-enhanced-detnet]. Note. To align with [RFC8655] which metrics from DetNet services can be expressed as PAM and what other have strict behavior. 7. Security and operational considerations 7.1. Security considerations Same security and operational considerations as described in [RFC5440] apply also in this document. When a path request could contain both a METRIC and a PRECISION METRIC objects for the same type of metric, the PCE will send back a PCErr message. In order to avoid denial of service attacks, new similar requests could be silently ignored during periods or time, or even requests from the same PCC could be filtered to prevent PCE affection. Other security considerations will be addressed in future versions of the document. 7.2. Operational considerations The work with precision metrics can impose stringent requirements in terms of collection, processing and assessment of metrics of interest. Such capabilities are expected to be supported by external systems, such as the TED, with the role of the PCE being limited to the work with processed information (e.g., histograms) so to assess that the precision metric used as constraint is compliant with the expectation of the PCC. Such external supportive systems are out of scope of this document. Contreras, et al. Expires 5 January 2026 [Page 18] Internet-Draft PAM-based PCE July 2025 8. IANA Considerations This document defines a new object class for the PCEP. IANA is requested to allocate the following codepoint in the PCEP "Objects" registry. Value Description Reference ------ ------------------------------- ------------- TBD1 PRECISION METRIC object This document Furthermore, the following Error-Type and Error-value of the PCEP Error Object are specified Value Description Reference ------ ------------------------------- ------------- TBD2 Error-Type "Invalid Operation" This document TBD3 Error Value "Unsupported Metric This document Object and PAM metric Object with same type" Additional IANA considerations required by this extension will be documented in future document versions (for instance, in respect to precision metric types). 9. References 9.1. Normative References [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, "Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 2017, . 9.2. Informative References Contreras, et al. Expires 5 January 2026 [Page 19] Internet-Draft PAM-based PCE July 2025 [I-D.ietf-nmop-network-incident-yang] Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, "A YANG Data Model for Network Incident Management", Work in Progress, Internet-Draft, draft-ietf-nmop-network- incident-yang-04, 14 June 2025, . [I-D.xiong-pce-detnet-bounded-latency] Xiong, Q., Liu, P., and R. Gandhi, "PCEP Extension for Bounded Latency", Work in Progress, Internet-Draft, draft- xiong-pce-detnet-bounded-latency-05, 21 October 2024, . [I-D.zhang-pce-enhanced-detnet] Zhang, L., Geng, X., and T. Zhou, "PCEP for Enhanced DetNet", Work in Progress, Internet-Draft, draft-zhang- pce-enhanced-detnet-05, 29 June 2024, . [IANA_METRIC_Object] "METRIC Object T Field", n.d., . [IEEE.754.2019] "754-2019 - IEEE Standard for Floating-Point Arithmetic", 22 July 2019, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . Contreras, et al. Expires 5 January 2026 [Page 20] Internet-Draft PAM-based PCE July 2025 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", RFC 8578, DOI 10.17487/RFC8578, May 2019, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . [RFC9544] Mirsky, G., Halpern, J., Min, X., Clemm, A., Strassner, J., and J. François, "Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs)", RFC 9544, DOI 10.17487/RFC9544, March 2024, . Acknowledgements The authors thank Dhruv Dhody, Ruediger Geib and Greg Mirsky for the comments received that helped to improve the document. This work has been partially funded by the European Commission Horizon Europe SNS JU PREDICT-6G project (GA 101095890), and the Spanish Ministry of Economic Affairs and Digital Transformation and the European Union NextGenerationEU UNICO 5G I+D "Towards a smart and efficient telecom infrastructure meeting current and future industry needs" (TIMING) project (TSI-063000-2021-145, -148, -149). Authors' Addresses Luis M. Contreras Telefonica Ronda de la Comunicacion, s/n 28050 Madrid Spain Email: luismiguel.contrerasmurillo@telefonica.com URI: http://lmcontreras.com Fernando Agraz Universitat Politecnica de Catalunya 08034 Barcelona Spain Contreras, et al. Expires 5 January 2026 [Page 21] Internet-Draft PAM-based PCE July 2025 Email: fernando.agraz@upc.edu Salvatore Spadaro Universitat Politecnica de Catalunya 08034 Barcelona Spain Email: salvatore.spadaro@upc.edu Quan Xiong ZTE Corporation China Email: xiong.quan@zte.com.cn Contreras, et al. Expires 5 January 2026 [Page 22]