Skip to main content

Path Computation Based on Precision Availability Metrics
draft-contreras-pce-pam-06

Document Type Active Internet-Draft (individual)
Authors Luis M. Contreras , Fernando Agraz , Salvatore Spadaro , Quan Xiong
Last updated 2025-10-20
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-contreras-pce-pam-06
PCE                                                      L. M. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                                  F. Agraz
Expires: 23 April 2026                                        S. Spadaro
                                    Universitat Politecnica de Catalunya
                                                                Q. Xiong
                                                         ZTE Corporation
                                                         20 October 2025

        Path Computation Based on Precision Availability Metrics
                       draft-contreras-pce-pam-06

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 23 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Contreras, et al.         Expires 23 April 2026                 [Page 1]
Internet-Draft                PAM-based PCE                 October 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
     3.4.  Calculation or selection of the path  . . . . . . . . . .   6
   4.  PRECISION METRIC Object . . . . . . . . . . . . . . . . . . .   6
     4.1.  Motivation for a new object to express precision
           metrics . . . . . . . . . . . . . . . . . . . . . . . . .   7
     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. . .  13
       4.4.1.  PRECISION METRIC coding examples  . . . . . . . . . .  13
       4.4.2.  PRECISION METRIC operation examples . . . . . . . . .  15
     4.5.  Interaction between precision metric object and the metric
           object  . . . . . . . . . . . . . . . . . . . . . . . . .  16
   5.  PCEP message extensions . . . . . . . . . . . . . . . . . . .  16
     5.1.  The PCReq Message . . . . . . . . . . . . . . . . . . . .  16
     5.2.  The PCRep Message . . . . . . . . . . . . . . . . . . . .  17
     5.3.  The PCRpt Message . . . . . . . . . . . . . . . . . . . .  18
   6.  Security and operational considerations . . . . . . . . . . .  19
     6.1.  Security considerations . . . . . . . . . . . . . . . . .  19
     6.2.  Operational considerations  . . . . . . . . . . . . . . .  19
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Appendix A.  Path Histogram Composition . . . . . . . . . . . . .  21
     A.1.  Additive Metrics  . . . . . . . . . . . . . . . . . . . .  22
     A.2.  Multiplicative Metrics  . . . . . . . . . . . . . . . . .  22
     A.3.  Maximization / Minimization Metrics (Bottleneck
           Metrics)  . . . . . . . . . . . . . . . . . . . . . . . .  22
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

Contreras, et al.         Expires 23 April 2026                 [Page 2]
Internet-Draft                PAM-based PCE                 October 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 23 April 2026                 [Page 3]
Internet-Draft                PAM-based PCE                 October 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 23 April 2026                 [Page 4]
Internet-Draft                PAM-based PCE                 October 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 order to support precision metrics, the TED could be extended to
   support e.g. time-series storage and processing capabilities (e.g.,
   to derive histograms from them, as described for instance in
   Appendix A).  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 23 April 2026                 [Page 5]
Internet-Draft                PAM-based PCE                 October 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.

3.4.  Calculation or selection of the path

   For a given metric, i.e. metric X, it is defined a frequency of
   values per bin for such a metric (e.g., if the metric refers to
   latency, a way of expressing it could be to consider the latency
   below 20 ms the 90% of the time, and below 25 ms the 99% of the
   time).  Thus, the calculation or selection of a path for such a
   metric X will consist on the comparison of the frequency of the
   metric values per bin, so that the intended path behaves equal or
   better than the intended path.  For that purpose, the statistical
   behavior of the path is characterized e.g. as described in
   Appendix A.

4.  PRECISION METRIC Object

Contreras, et al.         Expires 23 April 2026                 [Page 6]
Internet-Draft                PAM-based PCE                 October 2025

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 precision metrics instead of forcing the
   augmentation of the existing METRIC object:

   *  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.  Then 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 existing metric in
      the METRIC object, and can be implemented simultaneously or
      separately.

   The former limitations make preferable 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.

Contreras, et al.         Expires 23 April 2026                 [Page 7]
Internet-Draft                PAM-based PCE                 October 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|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.

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

Contreras, et al.         Expires 23 April 2026                 [Page 8]
Internet-Draft                PAM-based PCE                 October 2025

      (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:

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

Contreras, et al.         Expires 23 April 2026                 [Page 9]
Internet-Draft                PAM-based PCE                 October 2025

   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.

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

Contreras, et al.         Expires 23 April 2026                [Page 10]
Internet-Draft                PAM-based PCE                 October 2025

   *  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                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              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:

Contreras, et al.         Expires 23 April 2026                [Page 11]
Internet-Draft                PAM-based PCE                 October 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      | 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 23 April 2026                [Page 12]
Internet-Draft                PAM-based PCE                 October 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 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 described as:

Contreras, et al.         Expires 23 April 2026                [Page 13]
Internet-Draft                PAM-based PCE                 October 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 23 April 2026                [Page 14]
Internet-Draft                PAM-based PCE                 October 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 METRIC 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 23 April 2026                [Page 15]
Internet-Draft                PAM-based PCE                 October 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 23 April 2026                [Page 16]
Internet-Draft                PAM-based PCE                 October 2025

      <PCReq Message> ::= <Common Header>
                           [<svec-list>]
                           <request-list>
      where:
           <svec-list> ::= <SVEC>
                           [<OF>]
                           [<metric-list>]
                           [<precision-metric-list>]
                           [<svec-list>]

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

           <request> ::= <RP>
                         <END-POINTS>
                         [<LSP>]
                         [<LSPA>]
                         [<BANDWIDTH>]
                         [<bu-list>]
                         [<metric-list>]
                         [<precision-metric-list>]
                         [<OF>]
                         [<RRO>[<BANDWIDTH>]]
                         [<IRO>]
                         [<LOAD-BALANCING>]

      and where:
           <precision-metric-list> ::= <PRECISION-METRIC>[<precision-metric-list>]

                       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 23 April 2026                [Page 17]
Internet-Draft                PAM-based PCE                 October 2025

      <PCRep Message> ::= <Common Header>
                          [<svec-list>]
                          <response-list>

      where:

            <svec-list> ::= <SVEC>
                            [<OF>]
                            [<metric-list>]
                            [<precision-metric-list>]
                            [<svec-list>]

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

           <response> ::= <RP>
                          [<LSP>]
                          [<NO-PATH>]
                          [<attribute-list>]
                          [<path-list>]

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

           <path> ::= <ERO>
                      <attribute-list>

      and where:

           <attribute-list> ::= [<OF>]
                                [<LSPA>]
                                [<BANDWIDTH>]
                                [<bu-list>]
                                [<metric-list>]
                                [<precision-metric-list>]
                                [<IRO>]

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

                       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 23 April 2026                [Page 18]
Internet-Draft                PAM-based PCE                 October 2025

6.  Security and operational considerations

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

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

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

Contreras, et al.         Expires 23 April 2026                [Page 19]
Internet-Draft                PAM-based PCE                 October 2025

   Additional IANA considerations required by this extension will be
   documented in future document versions (for instance, in respect to
   precision metric types).

8.  References

8.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,
              <https://www.rfc-editor.org/info/rfc5541>.

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

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

8.2.  Informative References

   [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-06, 12 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
              network-incident-yang-06>.

   [IANA_METRIC_Object]
              "METRIC Object T Field", n.d.,
              <https://www.iana.org/assignments/pcep/pcep.xhtml#metric-
              object-ni-field>.

   [IEEE.754.2019]
              "754-2019 - IEEE Standard for Floating-Point Arithmetic",
              22 July 2019,
              <https://ieeexplore.ieee.org/document/8766229>.

Contreras, et al.         Expires 23 April 2026                [Page 20]
Internet-Draft                PAM-based PCE                 October 2025

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC8578]  Grossman, E., Ed., "Deterministic Networking Use Cases",
              RFC 8578, DOI 10.17487/RFC8578, May 2019,
              <https://www.rfc-editor.org/info/rfc8578>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [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,
              <https://www.rfc-editor.org/info/rfc9543>.

   [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,
              <https://www.rfc-editor.org/info/rfc9544>.

Appendix A.  Path Histogram Composition

   In order to obtain the statistical distribution of a metric over a
   complete path from the corresponding distributions of its constituent
   segments (e.g., hops) it is necessary to consider the class of the
   metric under evaluation, i.e., if the metric is additive,
   multiplicative, or maximal/minimal.

Contreras, et al.         Expires 23 April 2026                [Page 21]
Internet-Draft                PAM-based PCE                 October 2025

A.1.  Additive Metrics

   Additive metrics are those that sum along the path, such as delay or
   IGP cost [RFC4655], [RFC8233].  To generate a path histogram from
   segment histograms, the total path value can be obtained by summing
   the individual segment values along a period, and then forming the
   histogram.

   Alternatively, considering that a histogram is divided into discrete
   bins representing value ranges, it is possible to perform a bin-by-
   bin summation.  The histogram for the path is then obtained by
   summing the bin values across the segments.

A.2.  Multiplicative Metrics

   Multiplicative metrics, for example link availability or success
   probability [RFC8233], combine along a path by multiplying segment
   (e.g., per hop) values.  The path histogram can be obtained by
   combining the segment values and computing the product for each
   combination.

   Alternatively, logarithmic transformation can be applied to convert
   multiplicative aggregation into additive form, enabling reuse of
   additive histogram composition techniques.  In this method, the
   values of each histogram bin are transformed by taking the logarithm,
   effectively converting multiplication into addition.  The histograms
   can then be combined by summing the log-transformed bin values across
   segments, using the values of each bin per segment to calculate the
   resulting distribution.  After aggregating the histograms in the log
   domain, the path histogram can be transformed back to the original
   metric domain by applying the exponential function, yielding the
   final probabilities for the multiplicative path values.

A.3.  Maximization / Minimization Metrics (Bottleneck Metrics)

   Bottleneck metrics are defined by taking the maximum or minimum value
   along the path, such as bandwidth, MTU, etc [RFC4655].  To construct
   a path histogram, the values of each segment are considered to build
   the cumulative distribution function (CDF) of the path.

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

Contreras, et al.         Expires 23 April 2026                [Page 22]
Internet-Draft                PAM-based PCE                 October 2025

   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
   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 23 April 2026                [Page 23]