A YANG Data Model for Performance Monitoring (PM) Collection

1.1. PM Processing Pipeline in a Network Element

The PM processing pipeline considered in this document comprises the following three stages, as illustrated in Figure 1. Stage 2 (Collection) is the scope of this document.¶

  +----------------+    +==================+    +----------------+
  |    Stage 1     |    |     Stage 2      |    |    Stage 3     |
  |    Sampling    |--->|    Collection    |--->|   Reporting    |
  |                |    | (this document)  |    |                |
  | - Physical     |    | - Counts         |    | - YANG-Push    |
  |   layer        |    | - Snapshot       |    |   RFC 8639/    |
  | - OWAMP/TWAMP/ |    | - Tidemarks      |    |   8640/8641    |
  |   STAMP/IOAM   |    | - Thresholding   |    | - OS/NDT/      |
  | - Sensors      |    |                  |    |   AI APP       |
  |                |    |                  |    |                |
  +----------------+    +==================+    +----------------+

  raw samples           processed PM data          delivery

Stage 1 -- Sampling. This stage observes signals or protocol behaviours to produce raw samples. It encompasses direct observation of physical-layer signals as well as various OAM-based techniques. As examples of active measurement protocols that may be used in this stage, OWAMP [RFC4656], TWAMP [RFC5357], and STAMP [RFC8762] inject synthetic probe packets to measure one-way or round-trip delay, packet loss, and delay variation, while In-situ OAM (IOAM) [RFC9197] records performance data directly within user packets as they traverse the network.¶

The Stage 1 sampling techniques above fall into the measurement method categories defined by the IPPM framework [RFC7799]. Active methods such as OWAMP [RFC4656], TWAMP [RFC5357], and STAMP [RFC8762] generate and inject synthetic test traffic. Hybrid methods such as IOAM [RFC9197] augment or observe existing user traffic in transit. Passive methods, such as direct observation of physical-layer signals and the reading of protocol counters (for example interface packet counters), draw solely from traffic and signals already present, without generating test packets. Environmental sensor readings (for example temperature or voltage) are not classified by this axis, because no packet or signal observation is involved.¶

The Collection stage defined in this document is method-agnostic: the counts, snapshot, and tidemarks collection types apply identically to samples produced by any of these methods, and the model neither performs nor prescribes the Stage 1 measurement. However, because the operational meaning of a value depends on how it was measured -- for example, an active delay measurement reflects the experience of synthetic probes, whereas a hybrid measurement reflects that of real user traffic -- the measurement method is retained as metadata so that a client can interpret, filter, and aggregate collected values correctly. How this metadata is modelled is described in Section 2.3.¶

Stage 2 -- Collection. This stage processes raw samples into summarised statistics over defined intervals and manages their retention. Historically, PM collection mechanisms based on SNMP MIBs used the performance-history textual conventions defined in [RFC3593], with the high-capacity variants in [RFC3705]. The Collection stage modelled in this document follows the common equipment management function requirements of ITU-T G.7710 and supports three collection types -- Counts, Snapshot, and Tidemarks -- together with threshold evaluation and the associated periodic and non-periodic events.¶

Stage 3 -- Reporting. This stage delivers Collection-stage data and notifications to external management systems or controllers. While traditional pull-based retrieval remains available, this document assumes the push-based subscription mechanisms introduced above ([RFC8639], [RFC8641], [RFC8640]). The role of the Collection-stage models defined here is to provide the data structures that those mechanisms carry. Typical clients of this Reporting stage include operations systems (OS), network digital twins (NDT), and AI-driven applications (AI APP), as illustrated in Figure 2.¶

   +------+  +-----+     +--------+
   |  OS  |  | NDT | ... | AI APP |
   +---+--+  +--+--+     +----+---+
       |        |             |
       |   PM data and notifications
       |   via YANG-Push (RFC 8639/8640/8641)
       |        |             |
   +---+--------+-------------+---+
   |            NE                |
   |  +-----------------------+   |
   |  |  EMF / Collection     |   |
   |  |  (this document)      |   |
   |  +-----------------------+   |
   +------------------------------+

   OS:  Operations System
   NDT: Network Digital Twins
   APP: Application

The YANG data model specified in this document is implemented within the Equipment Management Function (EMF) of an NE, as defined in ITU-T G.7710. It is exposed at the NE's management interface and is consumed by remote clients such as operations systems (OS), Physical Network Controllers (PNCs), network digital twins (NDT), and AI-driven applications. Throughout this document the term "client" refers to any such consumer of the PM collection interface, regardless of whether it acts as a controller, an analytics engine, or an operator-facing management system.¶

The tree diagrams in this document use the notation defined in [RFC8340].¶

1.2. Relationship to the IETF Performance Metric Framework

The three-stage pipeline described above aligns with the framework for performance metric development given in [RFC6390]. The Collection stage modelled in this document corresponds to the Computed Performance Metrics described in Section 5.3 of [RFC6390]: the Counts and Tidemarks collection types are temporal aggregations (Section 5.3.1 of [RFC6390]) of base metrics over a collection interval, while the Snapshot collection type is a sampled value organised as a singleton in the sense of Section 5.6 of [RFC6390] and the IPPM framework [RFC2330].¶

Figure 3 summarises how the three collection types map onto the result organization of the IPPM framework.¶

+--------------------------------------------------------------------+
| Collection:  counts | snapshot | tidemarks                         |
|                                                                    |
|  +--------------+   +-------------------------------------------+  |
|  |  Snapshot    |   | Computed Performance Metrics              |  |
|  |              |   | (RFC 6390 Sec 5.3 / 5.3.1 aggregation)    |  |
|  | singleton    |   |                                           |  |
|  |              |   |   +---------------+    +----------------+ |  |
|  | (directly    |   |   |   Counts      |    |  Tidemarks     | |  |
|  |  sampled)    |   |   | statistic     |    |  statistic     | |  |
|  |              |   |   |    (sum)      |    | (min / max)    | |  |
|  |              |   |   |               |    |                | |  |
|  +--------------+   |   +---------------+    +----------------+ |  |
|                     +-------------------------------------------+  |
|                                                                    |
+--------------------------------------------------------------------+

RFC 2330 Sec 11 / RFC 6390 Sec 5.6 organize results as:
  singleton = elementary "atomic" value        -> Snapshot
  sample    = a set of singletons (one interval)
  statistic = value computed from a sample      -> Counts, Tidemarks

The base metrics aggregated by this model are produced in Stage 1 (Sampling) and are expected to be specified following the Performance Metric Specification of Section 5.4 of [RFC6390]. This document does not define or redefine those base metrics, nor does it introduce new performance metrics or parameters; it identifies the operationally important subset (counts, snapshot, and tidemarks) and defines the YANG structures that compute, retain, and expose their aggregated values over the configured collection intervals. The acceptable ranges of sampling and collection intervals, and the required timing accuracy called for in Section 5.4.2 of [RFC6390], are determined by the parameter profiles defined in this document, rather than being fixed by the YANG model itself.¶

Except where [RFC6390] is explicitly referenced, this document uses the term "Sampling" for the Stage 1 activity described above and "Collection" for the Stage 2 activity. A collection interval (YANG node collection-interval) is the window over which sampled values are aggregated within the Collection stage; it is distinct from the sampling interval at which raw values are produced.¶

1.3. Motivation and Scope

The legacy SNMP-based collection conventions [RFC3593] [RFC3705] and the associated pull-based polling architecture limit real-time visibility and flexible interval design at the scale of modern networks. The push-based subscription mechanisms [RFC8639] [RFC8640] [RFC8641] provide an efficient and scalable alternative for streaming management data, but those specifications define only the subscription and notification mechanisms themselves and do not prescribe the structure of the PM data being carried. A standardised YANG data model is therefore needed at the Collection stage to bridge low-level measurement data and high-level streaming subscriptions, since existing YANG models tend to focus on static configuration or simple state data and do not offer the structures required to express counts, snapshot, and tidemarks collection together with profile-based parameter grouping and threshold semantics.¶

A further motivation concerns which performance information to collect and in what form. The IETF performance metric framework [RFC6390] provides methods for defining and computing metrics, but the space of possible computed metrics is effectively unbounded (for example, averages, variances, or percentiles could all be derived). ITU-T G.7710 [G7710] instead reflects several decades of operational experience by fixing a deliberately small set of collection forms and parameters: gauge measurements are limited to snapshots (an instantaneous value) and tidemarks (the maximum and minimum), and counts to a simple accumulation, rather than general statistical aggregations; and the collected parameters are confined to an operational set such as ES, SES, BBE, BBC, and UAS for maintenance and quality-of-service purposes. The collection types are themselves defined as the form in which results are stored, independent of the collection interval. This document adopts that operationally-validated minimal set, rather than attempting to enumerate all statistically possible metrics, so that the resulting YANG model expresses what network operators actually need to retain and expose for fault management, maintenance, and SLA evaluation. This is also why the model is parameter-agnostic in structure: it standardises the collection forms (counts, snapshot, tidemarks) and leaves the specific parameters to be referenced from [G7710] and related Recommendations.¶

The scope of this document is therefore limited to the Collection stage. Within that scope, this document specifies YANG data models that enable: (a) flexible processing of performance metrics beyond simple counts, including Snapshot and Tidemarks; (b) configurable sampling and collection intervals that are not restricted to the legacy 15-minute or 24-hour windows; and (c) data and notification structure that supports flexible delivery of processed PM data to management systems, compatible with both pull-based retrieval and push-based subscription mechanisms.¶

The Collection-stage data and notifications defined here are compatible with the existing YANG-Push framework ([RFC8639], [RFC8640], [RFC8641]) for push-based delivery as well as with traditional pull-based retrieval via NETCONF or RESTCONF; this document does not define any new subscription or notification mechanism, only the pm-threshold-events notification content, carried over those existing mechanisms.¶

1.4. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.1. Types

Performance monitoring (PM) in networks encompasses a wide variety of parameters that reflect operational health, service quality, reliability, and environmental conditions. These parameters are used across many technologies, network layers, and functional domains to enable fault management, SLA compliance, trend analysis, predictive maintenance, and operational optimization.¶

PM parameter types include but are not limited to:¶

• Classical transport and packet layer metrics: such as errored seconds (ES), severely errored seconds (SES), unavailable seconds (UAS), background block errors (BBE), background block counts (BBC), delay, jitter, and packet loss, as defined in standards like ITU-T G.7710, and others.¶

• Layer-specific metrics:¶

  • Physical layer: optical power levels, laser bias current, loss of signal¶

  • Data link layer: Ethernet frame errors, FCS errors¶

  • Network layer: dropped packets, route flaps¶

  • Transport/Service layers: MPLS LSP statistics, OTN TCM/BIP counters¶

• Network environment parameters: including temperature, humidity, fan speed, voltage, and airflow. These are essential for equipment safety, energy management, and predictive failure analysis.¶

• Energy and sustainability metrics: such as power consumption, energy efficiency indicators, and cooling utilization, aligned with emerging sustainability standards and operational efficiency goals.¶

• Security and integrity parameters: such as pointer justification events (PJE), synchronization loss, or intrusion anomaly flags.¶

• Application-aware or SLA metrics: such as service availability, throughput consistency, and application-layer latency.¶

• Mobile network-specific metrics: including radio link failures, handover success/failure rates, RRC connection setup time, PDCP discard rate, and throughput per bearer. These metrics are critical for monitoring the performance of RAN, core, and edge network components in 4G/5G mobile environments.¶

These parameters may be grouped flexibly within the YANG model using parameter profiles that reflect shared characteristics, purpose, or applicable network domains. The architecture supports extension through identity-based typing to accommodate future parameter definitions introduced by standard bodies like ITU-T, IEEE, IETF, MEF, and TM Forum.¶

The data model defined in this document is parameter-agnostic: it specifies how performance parameters are collected, aggregated, and exposed, rather than defining the parameters themselves. Each performance parameter is expected to be specified following the Performance Metric Specification template of Section 5.4.4 of [RFC6390] (metric name, description, method of measurement or calculation, units, measurement point, and measurement timing). The parameters listed above are illustrative and are not themselves defined by this document; the specification of any such parameter is left to the relevant standards body.¶

2.2. Profiles

+--rw parameter-profile* [name]
   +--rw name              profile-names
   +--rw pm-parameter* [name]
      +--rw name           identityref

The YANG model defines the concept of a parameter profile to logically group performance parameters that are commonly measured together for a specific operational purpose. Each parameter profile is represented as a list entry keyed by a name of type profile-names (a string conforming to the format defined in the model). These profiles serve as named collections of performance parameters and are intended to facilitate streamlined configuration, management, and reporting of measurement data across network elements and management systems.¶

The use of parameter profiles improves operational efficiency by allowing operators, applications, and controllers to activate or reference a coherent set of parameters using a single profile identifier. For example, a maintenance profile may group the error counters of an interface that are monitored together for fault detection, and a QoS profile may group delay, jitter, and loss parameters used in service quality reporting. Parameter profiles support role-based access control, operational alignment, and measurement policy abstraction, enabling network operators and analytics systems to tailor data collection and reporting according to the needs of different users and services.¶

By modeling profiles as list entries keyed by a structured name (profile-names type), the YANG design ensures extensibility and vendor interoperability, allowing future profiles to be defined without changes to the core data structures. This approach promotes consistent configuration and integration across multi-vendor environments and supports dynamic service assurance use cases where parameter sets may vary by service type, SLA, or operational context.¶

<source>-<network>-<purpose>[-<characteristic>]

2.3. Measurement Method Metadata

Each pm-parameter entry MAY carry an optional measurement-method leaf that records the IPPM measurement method [RFC7799] by which the parameter's Stage 1 samples are produced. The leaf is an identityref whose base identity is measurement-method, with the derived identities active, passive, and hybrid corresponding to the categories of [RFC7799].¶

+--rw pm-parameter* [name]
   +--rw name                 identityref
   +--rw measurement-method?  identityref
   +--rw sampling-interval* [id]
      ...

The leaf is optional for three reasons. First, it preserves backward compatibility with servers and configurations that do not populate it. Second, some parameters (for example environmental sensor values such as temperature or voltage) are not meaningfully classified by the active/passive/hybrid axis. Third, the Collection stage operates independently of the measurement method, so the leaf conveys interpretation metadata rather than affecting collection behaviour.¶

The measurement method corresponds to the "method of measurement or calculation" element of the Performance Metric Specification template in Section 5.4.4 of [RFC6390]. Carrying it alongside the collected value lets a client (a) interpret the value in the correct operational context, (b) keep homogeneous data sets when comparing or aggregating values across network elements, and (c) reason about the intrusiveness of the measurement, since active methods inject synthetic traffic while passive methods do not.¶

Because the leaf resides within pm-parameter, the method information is inherited by every sampling interval, collection interval, and collection type beneath that parameter, and is therefore associated with the corresponding value both in pull-based retrieval and in push-based notifications, without requiring any per-notification tag.¶

3.1. Interval Timing

+--rw sampling-interval* [id]
   +--rw id                  string
   +--rw interval-value?     uint32
   +--rw unit?               time-interval-unit
   +--rw collection-interval* [id]
      +--rw id                string
      +--rw interval-value?   uint32
      +--rw unit?             time-interval-unit

Interval timing parameters are key components of network performance monitoring, offering standardized definitions for the time-related aspects of sampling, collection, and reporting performance data. These parameters apply to the three main collection types for network equipment: counts, snapshot, and tidemarks. They include the sampling interval, collection interval, and uniform time, all of which support consistent, accurate, and systematic performance monitoring and management.¶

Sampling interval defines the period at which network performance data is collected at consistent, predetermined time points. It ensures the continuous and timely capture of performance metrics, enabling accurate assessments of network conditions. The sampled values are the input of the Collection stage, so collection is always performed on the samples of a sampling interval: in the model, a collection interval exists only within a sampling interval entry.¶

Collection interval specifies the duration over which sampled performance data is aggregated or statistically processed. It helps manage large volumes of data by summarizing it into meaningful indicators for analysis, anomaly detection, and resource management. Both interval values are positive.¶

Uniform time is a fixed, predefined point within each collection interval at which a snapshot is taken. It enables a consistent and instantaneous view of network performance across intervals, without requiring data aggregation. This approach facilitates quick diagnostics and synchronization across monitoring systems.¶

The acceptable ranges of sampling and collection intervals, and the timing accuracy required for a given parameter, are not fixed by this YANG model. As noted in Section 5.4.2 of [RFC6390], these constraints are part of the specification of each performance metric; in this document they are determined by the parameter profile in use, and a server advertises the intervals it supports as part of its capabilities.¶

3.2. Collection Types

+--rw collection-types
   +--rw counts!
   |  +--rw transient-condition-config
   |  |  +--rw transient-threshold?   uint32
   |  +--rw standing-condition-config
   |  |  +--rw standing-threshold?    uint32
   |  |  +--rw reset-threshold?       uint32
   |  +--ro collection-value?        uint32
   +--rw snapshot!
   |  +--rw uniform-time-config
   |  |  +--rw offset-value?          uint32
   |  |  +--rw unit?                  time-interval-unit
   |  +--rw threshold-config
   |  |  +--rw high-threshold?        uint32
   |  |  +--rw low-threshold?         uint32
   |  +--ro collection-value?        uint32
   +--rw tidemarks!
      +--rw threshold-config
      |  +--rw high-threshold?        uint32
      |  +--rw low-threshold?         uint32
      +--ro high-collection-value?   uint32
      +--ro low-collection-value?    uint32

The collection types establish a focused and efficient framework for network performance monitoring by specifying three core collection types: counts, snapshot, and tidemarks.¶

Each collection type is a presence container. The presence of the counts, snapshot, or tidemarks container in a collection-interval entry indicates that the server collects that collection type for the parameter over that interval; its absence indicates that it does not. A client therefore selects the collection types of a parameter by creating the corresponding containers, and a profile can restrict a parameter to a subset of the three types (for example, counts only for a QoS profile).¶

This intentional limitation supports key objectives such as implementation simplicity, operational efficiency, and cross-vendor interoperability. It emphasizes real-time network monitoring, favoring instantaneous or interval-based metrics over complex statistical calculations. The counts and snapshot collection types provide immediate operational data without incurring the processing overhead associated with metrics like averages and variances. These statistical measures require significant aggregation logic, which can vary across implementations and devices. By keeping computation within network elements minimal, the approach reduces both processing and memory overhead, maintaining lightweight implementations. It establishes a clear separation between raw data collection (handled by network elements) and deeper analysis (delegated to external management systems). This separation not only simplifies device requirements but also enables more consistent and flexible analytics in centralized systems, which are better equipped to apply standardized analytical frameworks.¶

Limiting collection types also contributes to energy efficiency by reducing the operational burden on Network Elements (NEs), while offloading data analysis to external management applications. Despite the simplicity, the selected collection types offer sufficient expressiveness to support comprehensive performance monitoring without excessive resource use. They are specifically optimized for the NE-to-client interface -- referred to as the Southbound Interface (SBI) from a controller perspective (e.g., between a Physical Network Controller (PNC) and an NE), or equivalently as the northbound management interface from the NE's perspective -- to ensure as follows:¶

• Lightweight to implement¶

• Consistently supported across vendors¶

• Efficient for transport and storage in network management systems¶

The collection types are applicable to a wide range of monitored objects, including both network topology elements (e.g., links, tunnels) and physical equipment parameters (e.g., temperature, voltage).¶

In terms of the performance metric framework of [RFC6390], the three collection types correspond to the following operations, as summarised in Table 2.¶

The counts and tidemarks types are computed (aggregated) metrics in the sense of Section 5.3 of [RFC6390], whereas the snapshot type is a directly sampled value rather than an aggregation.¶

4.1. Suspect Interval Flag

The suspect-interval-flag follows the suspect interval flag of ITU-T G.7710. It is initialised to "false" at the start of each collection interval and is set to "true" whenever the data stored for the interval may be unreliable: when one or more periodic samples are missing, when collection state is reset, when the equipment restarts during the interval, when interval timing is changed, or when collection is suspended. A client that reads or receives a value together with a suspect flag of "true" knows that the value should be treated with caution.¶

For the snapshot collection type the initialisation is inverted: the flag is set to "true" at the start of the interval to indicate that no snapshot has yet been taken, and is cleared to "false" once the single snapshot has been taken at the uniform time.¶

4.2. Interval Status and the Meaning of Zero

The optional interval-status leaf refines the boolean flag into three cases: "complete" (all expected samples were available), "partial" (some samples were missing but at least one valid sample was collected), and "unavailable" (no valid sample was collected). Whenever interval-status is not "complete", the suspect-interval-flag is "true". The optional suspect-reason leaf-list carries zero or more reasons, when known, drawn from an extensible set of identities (telemetry loss, partial node support, state reset, restart, time adjustment, measurement suspension, measurement boundary, and outage).¶

To remove the ambiguity between a measured zero and an absent value, a server MUST NOT instantiate the collection-value leaf (the collection-value of counts and snapshot, or the high and low collection values of tidemarks) for an interval whose interval-status is "unavailable". Because these leaves are optional, their absence is the natural encoding of "no data", and a collection-value that is present and zero is therefore always a measured zero. For a "partial" interval the value is reported together with the coverage counters described below, and a partial counts value is interpreted as a lower bound on the true count for the interval.¶

4.3. Coverage, Elapsed Time, and Interval Timestamps

When the server implements the coverage-counters feature, the expected-sample-count and received-sample-count leaves report how many Stage 1 samples were expected (for a complete interval, approximately the collection interval divided by the sampling interval) and how many valid samples were actually collected, so that a client can gauge the coverage of a partial interval. These sample counts apply to any sampled parameter and are most meaningful for periodically sampled (gauge) parameters such as tidemarks; they are not defined by ITU-T G.7710 and generalize its coverage notion for this model. The elapsed-time leaf gives the number of seconds of the interval that have been processed by the measurement -- not the sum of available time, since it advances during unavailable time as well. The interval-start-time and interval-end-time leaves record when the interval began and ended; interval-end-time is the end-of-interval timestamp and is the authoritative measurement time, to be used for correlation in preference to the notification envelope eventTime.¶

4.4. Retained Interval Data

This model distinguishes the current interval from retained intervals. The current interval is the interval in progress; its value (the collection-value of counts and snapshot, or the high and low values of tidemarks) and its interval-data-status are always available and are read or delivered as the interval advances. A retained interval is a completed interval whose result the server keeps for a bounded time after the interval ends.¶

This model does not require a server to retain completed intervals. When results are delivered as each interval ends, retention of past results is a client-side concern. When a server does retain completed intervals, the number it keeps bounds both how many completed intervals a client may read back and how long a reporting period may be.¶

The validity metadata that describes an interval -- the suspect flag, the sample coverage, the elapsed time, and the start and end timestamps -- is carried in interval-data-status and accompanies the value whether the interval is the current interval or a retained one, so it is independent of how the data is delivered.¶

5.1. Periodic Thresholding

Periodic threshold events are triggered when the counts or gauge value reaches a pre-defined threshold during periodic collection of the counts, snapshot, and tidemarks collection types for performance parameters.¶

The counts collection type has two types of threshold reporting methods: transient and standing condition methods. The transient condition method treats each collection interval separately. As soon as a threshold is reached or crossed in a collection interval for a given performance parameter, a threshold report (TR) is generated. The standing condition method is optional. The standing condition is raised, and a TR (Threshold Report) is generated, when the set threshold is reached or crossed. The standing condition is cleared, and a reset threshold report (RTR) is generated at the end of the period when the current value is below or equal to the reset threshold, provided that there was no unavailable time during that period. In the terms of Section 4, this "no unavailable time" condition is expressed by the suspect-interval-flag: an RTR is not generated for an interval whose suspect-interval-flag is set.¶

For the gauge collection types ("snapshot" and "tidemarks"), an overflow condition is determined and an out-of-range report is generated as soon as the gauge value reaches or crosses the high threshold. An underflow condition is determined and an out-of-range report is generated as soon as the gauge value is at or below the low threshold.¶

5.2. Non-Periodic Thresholding

Non-periodic threshold events are triggered regardless of the collection types (counts, snapshot, or tidemarks). The following parameters are used for non-periodic events.¶

• BUT (Begin Unavailable Time): The event marking the start of a period when a network element or connection is unavailable.¶

• EUT (End Unavailable Time): The event marking the end of a period when a network element or connection was unavailable.¶

• CSES (Consecutive Severely Errored Seconds): A sequence of severely errored seconds (SES) detected consecutively within a specified time interval. The reporting metrics include BUT, EUT, and the count of errors during that period.¶

6.1. Example Module

The examples in this document use the example module shown in Figure 9. It defines two example parameters: "ex:lost-packets", an event parameter used with the counts collection type, and "ex:one-way-delay", a gauge parameter measured with IOAM [RFC9197] and used with the snapshot and tidemarks collection types. Parameters of specific network technologies are defined in other documents in the same way.¶

module example-pm-parameters {
  yang-version 1.1;
  namespace "urn:example:pm-parameters";
  prefix ex;

  import ietf-pm-collection {
    prefix pm-co;
    reference
      "RFC XXXX: A YANG Data Model for Performance Monitoring (PM)
       Collection";
  }

  organization
    "Example organization";
  contact
    "Example contact";
  description
    "This module defines example performance parameters, derived
     from the performance-parameter base identity of
     ietf-pm-collection, for use in the examples of this
     document only.  It is not intended for implementation.
     Parameters of specific network technologies are defined in
     other documents in the same way.";

  revision 2026-10-29 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: A YANG Data Model for Performance Monitoring (PM)
       Collection";
  }

  identity lost-packets {
    base pm-co:performance-parameter;
    description
      "Example event parameter: the number of packets lost in
       each sampling interval.  It is used with the counts
       collection type.";
  }

  identity one-way-delay {
    base pm-co:performance-parameter;
    description
      "Example gauge parameter: the mean one-way delay, in
       microseconds, of the packets measured with In situ OAM
       (IOAM) in each sampling interval.  It is used with the
       snapshot and tidemarks collection types.";
    reference
      "RFC 9197: Data Fields for In Situ Operations,
       Administration, and Maintenance (IOAM)";
  }
}

6.2. Pull-Based Polling

The operational state data defined in this document can be retrieved by clients using standard NETCONF or RESTCONF operations, providing a pull-based access pattern analogous to traditional SNMP polling.¶

In traditional SNMP-based PM collection, a management system periodically issues GET or GET-BULK requests to retrieve counter values from the agent's MIB, such as the performance-history MIBs defined in [RFC3593] and [RFC3705]. The YANG data model defined here provides equivalent data structures accessible via NETCONF <get-data> operations [RFC8526] against the operational datastore [RFC8342], or via RESTCONF HTTP GET requests, at any polling interval chosen by the client.¶

The collection-value leaf (config false) in the counts collection type, and the corresponding value leaves in snapshot and tidemarks, are read-only operational state nodes that reflect the current accumulated or instantaneous PM values within the active collection interval. These leaves are the YANG equivalents of SNMP counter and gauge objects in classical PM MIBs.¶

Figure 10 shows a NETCONF <get-data> request that retrieves the current count of the ex:lost-packets parameter (see Section 6.1) in the example-ip-qos-15min profile, sampled every second over a 15-minute collection interval. A client may issue this request at any time to read the in-progress counter value, or at the end of each collection interval to collect the final result, replicating the behavior of a traditional SNMP polling cycle.¶

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id="401">
  <get-data
      xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
      xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
    <datastore>ds:operational</datastore>
    <subtree-filter>
      <pm-periodic-collection
          xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
          xmlns:ex="urn:example:pm-parameters">
        <parameter-profile>
          <name>example-ip-qos-15min</name>
          <pm-parameter>
            <name>ex:lost-packets</name>
            <sampling-interval>
              <id>1s</id>
              <collection-interval>
                <id>15min</id>
                <collection-types>
                  <counts>
                    <collection-value/>
                  </counts>
                </collection-types>
              </collection-interval>
            </sampling-interval>
          </pm-parameter>
        </parameter-profile>
      </pm-periodic-collection>
    </subtree-filter>
  </get-data>
</rpc>

Figure 11 shows the corresponding reply, in which the server returns the current count of 7 accumulated during the collection interval in progress. This is equivalent to the value that a classical SNMP GET would retrieve from a performance-history MIB object.¶

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
           message-id="401">
  <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
    <pm-periodic-collection
        xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
        xmlns:ex="urn:example:pm-parameters">
      <parameter-profile>
        <name>example-ip-qos-15min</name>
        <pm-parameter>
          <name>ex:lost-packets</name>
          <sampling-interval>
            <id>1s</id>
            <collection-interval>
              <id>15min</id>
              <collection-types>
                <counts>
                  <collection-value>7</collection-value>
                </counts>
              </collection-types>
            </collection-interval>
          </sampling-interval>
        </pm-parameter>
      </parameter-profile>
    </pm-periodic-collection>
  </data>
</rpc-reply>

6.3. Periodic Events

The YANG-Push subscription model, as defined in [RFC8641], enables clients to subscribe to periodically collected PM data from network elements. This model supports dynamic subscription establishment, modification, and termination for real-time streaming of PM data. Clients can specify subscription parameters including the target datastore (operational), encoding format (XML/JSON), and filtering criteria to receive only relevant performance metrics. The subscription mechanism allows for configurable update periods, enabling both high-frequency monitoring and long-term trend analysis (e.g., 24-hour intervals). Network elements generate periodic event notifications containing the requested PM data, which clients can process for real-time monitoring, historical analysis, or triggering automated responses based on performance thresholds.¶

Figure 12 shows a periodic subscription [RFC8641] to the operational datastore for the ex:lost-packets parameter in the example-ip-qos-15min profile. The XPath filter selects the 15-minute collection interval entry, sampled every second, including its collection values and interval data status. The period is expressed in centiseconds: 90000 (900 seconds), so that an update is sent once per collection interval.¶

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id="101">
  <establish-subscription
      xmlns=
        "urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
      xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"
      xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
    <yp:datastore>ds:operational</yp:datastore>
    <yp:datastore-xpath-filter
        xmlns:pm-co="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
        xmlns:ex="urn:example:pm-parameters">
      /pm-co:pm-periodic-collection/
        parameter-profile[name='example-ip-qos-15min']/
        pm-parameter[name='ex:lost-packets']/
        sampling-interval[id='1s']/
        collection-interval[id='15min']
    </yp:datastore-xpath-filter>
    <encoding>encode-xml</encoding>
    <yp:periodic>
      <yp:period>90000</yp:period>
      <yp:anchor-time>2026-07-01T00:00:00Z</yp:anchor-time>
    </yp:periodic>
  </establish-subscription>
</rpc>

Figure 13 shows the resulting "push-update" notification [RFC8641] for the subscription, whose identifier returned by the server is 39. It reports the counts collection value of the ex:lost-packets parameter in the example-ip-qos-15min profile, sampled every second and aggregated over a 15-minute interval. The collected value (10) represents the total number of lost packets in that period. The accompanying interval-data-status shows that the interval is complete and not suspect, so the value is a fully measured result.¶

<notification
    xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2026-07-01T00:15:00Z</eventTime>
  <push-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
    <id>39</id>
    <datastore-contents>
      <pm-periodic-collection
          xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
          xmlns:ex="urn:example:pm-parameters">
        <parameter-profile>
          <name>example-ip-qos-15min</name>
          <pm-parameter>
            <name>ex:lost-packets</name>
            <sampling-interval>
              <id>1s</id>
              <collection-interval>
                <id>15min</id>
                <interval-value>15</interval-value>
                <unit>minute</unit>
                <interval-data-status>
                  <suspect-interval-flag
                    >false</suspect-interval-flag>
                  <interval-status>complete</interval-status>
                </interval-data-status>
                <collection-types>
                  <counts>
                    <collection-value>10</collection-value>
                  </counts>
                </collection-types>
              </collection-interval>
            </sampling-interval>
          </pm-parameter>
        </parameter-profile>
      </pm-periodic-collection>
    </datastore-contents>
  </push-update>
</notification>

6.4. Threshold Events

Threshold event subscriptions enable clients to receive immediate notifications when performance metrics cross predefined thresholds, providing proactive monitoring capabilities. The threshold events defined in this document are carried in the "pm-threshold-events" YANG notification; they are events, not datastore data. A client therefore receives them by subscribing to an event stream, such as the "NETCONF" event stream, using subscribed notifications [RFC8639], rather than by a YANG-Push datastore subscription [RFC8641].¶

+--ro counts-transient
|  +--ro event-type?       enumeration
|  +--ro event-occurred?   boolean
|  +--ro event-time?       yang:date-and-time
+--ro counts-standing
|  +--ro event-type?       enumeration
|  +--ro event-occurred?   boolean
|  +--ro event-time?       yang:date-and-time
+--ro snapshot
|  +--ro event-type?       enumeration
|  +--ro event-occurred?   boolean
|  +--ro event-time?       yang:date-and-time
+--ro tidemarks
   +--ro event-type?       enumeration
   +--ro event-occurred?   boolean
   +--ro event-time?       yang:date-and-time

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id="202">
  <establish-subscription
      xmlns=
        "urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
    <stream>NETCONF</stream>
    <stream-xpath-filter
        xmlns:pm-co="urn:ietf:params:xml:ns:yang:ietf-pm-collection">
      /pm-co:pm-threshold-events
    </stream-xpath-filter>
    <encoding>encode-xml</encoding>
  </establish-subscription>
</rpc>

<notification
    xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2026-07-01T00:05:23Z</eventTime>
  <pm-threshold-events
      xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-collection"
      xmlns:ex="urn:example:pm-parameters">
    <periodic-events>
      <parameter-profile>
        <name>example-ip-qos-15min</name>
        <pm-parameter>
          <name>ex:one-way-delay</name>
          <sampling-interval>
            <id>1s</id>
            <interval-value>1</interval-value>
            <unit>second</unit>
            <collection-interval>
              <id>15min</id>
              <interval-value>15</interval-value>
              <unit>minute</unit>
              <event-types>
                <tidemarks>
                  <event-type>High-OOR-event</event-type>
                  <event-occurred>true</event-occurred>
                  <event-time>2026-07-01T00:05:23Z</event-time>
                </tidemarks>
              </event-types>
            </collection-interval>
          </sampling-interval>
        </pm-parameter>
      </parameter-profile>
    </periodic-events>
  </pm-threshold-events>
</notification>

+--ro non-periodic-events
   +--ro BUT-event
   |  +--ro event-occurred?   boolean
   |  +--ro event-time?       yang:date-and-time
   +--ro EUT-event
   |  +--ro event-occurred?   boolean
   |  +--ro event-time?       yang:date-and-time
   |  +--ro duration?         uint32
   +--ro CSES-event
      +--ro event-occurred?   boolean
      +--ro start?            yang:date-and-time
      +--ro end?              yang:date-and-time
      +--ro duration?         uint32
      +--ro error-count?      uint32

12.1. Normative References

[G7710]

ITU-T, "Common Equipment Management Function Requirements", ITU-T Recommendation G.7710, November 2025, <https://www.itu.int/rec/T-REC-G.7710>.

[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/rfc/rfc2119>.

[RFC6020]

Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/rfc/rfc6020>.

[RFC6241]

Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/rfc/rfc6241>.

[RFC6242]

Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/rfc/rfc6242>.

[RFC6991]

Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/rfc/rfc6991>.

[RFC7950]

Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/rfc/rfc7950>.

[RFC8040]

Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/rfc/rfc8040>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8340]

Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/rfc/rfc8340>.

[RFC8341]

Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/rfc/rfc8341>.

[RFC8342]

Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/rfc/rfc8342>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8639]

Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/rfc/rfc8639>.

[RFC8640]

Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Dynamic Subscription to YANG Events and Datastores over NETCONF", RFC 8640, DOI 10.17487/RFC8640, September 2019, <https://www.rfc-editor.org/rfc/rfc8640>.

[RFC8641]

Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/rfc/rfc8641>.

12.2. Informative References

[RFC2330]

Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/rfc/rfc2330>.

[RFC3593]

Tesink, K., Ed., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, DOI 10.17487/RFC3593, September 2003, <https://www.rfc-editor.org/rfc/rfc3593>.

[RFC3688]

Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/rfc/rfc3688>.

[RFC3705]

Ray, B. and R. Abbi, "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3705, DOI 10.17487/RFC3705, February 2004, <https://www.rfc-editor.org/rfc/rfc3705>.

[RFC4656]

Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/rfc/rfc4656>.

[RFC5357]

Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/rfc/rfc5357>.

[RFC6390]

Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <https://www.rfc-editor.org/rfc/rfc6390>.

[RFC7799]

Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/rfc/rfc7799>.

[RFC8526]

Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "NETCONF Extensions to Support the Network Management Datastore Architecture", RFC 8526, DOI 10.17487/RFC8526, March 2019, <https://www.rfc-editor.org/rfc/rfc8526>.

[RFC8762]

Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/rfc/rfc8762>.

[RFC9197]

Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, <https://www.rfc-editor.org/rfc/rfc9197>.