A YANG Data Model of Performance Management Streaming

1.1. PM Processing Pipeline in a Network Element

The PM processing pipeline considered in this document comprises the following three stages.¶

Stage 1 -- Measurement. This stage observes signals or protocol behaviours to produce raw measurement values. 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.¶

Stage 2 -- Collection. This stage processes raw measurement data 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 1.¶

   +------+  +-----+     +--------+
   |  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 Section 6.2. 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 streaming interface, regardless of whether it acts as a controller, an analytics engine, or an operator-facing management system.¶

1.2. 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 aligned with ITU-T G.7710.¶

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, as defined in ITU-T G.7710; (b) configurable sampling and measurement intervals that are not restricted to the legacy 15-minute or 24-hour windows, together with a capability-discovery mechanism in ietf-pm-interval-capabilities that lets clients learn which intervals a given server supports; and (c) data and notification structure designed to be carried by the push-based subscription mechanisms identified above for real-time, proactive delivery of processed PM data to management systems.¶

The data model defined in this document realizes the Collection-stage functions described in [G7710], in particular performance-monitoring data, collection types, and threshold reporting.¶

The Collection-stage data and notifications defined here are intended to be carried by the existing YANG-Push framework ([RFC8639], [RFC8640], [RFC8641]); this document does not define any new subscription or notification.¶

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

2.2. Profiles

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

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, the itu-transport-maintenance-15min profile may include parameters such as errored seconds (ES), severely errored seconds (SES), and unavailable seconds (UAS), which are typically monitored together for network maintenance and fault detection purposes. Similarly, the example-ip-qos-24hr profile may include 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. The profile abstraction also aligns with ITU-T G.7710, which identifies multiple classes of performance monitoring (e.g., maintenance, service-level, and compliance monitoring), each requiring specific sets of performance parameters.¶

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. Transport Common PM Parameters

Metric values of PM parameters are measured for maintenance and QoS monitoring over networks. Quality of Service (QoS) parameters are designed to assess the network's long-term ability to consistently deliver agreed-upon service quality to customers. They primarily verify performance against contractual obligations defined in service-level agreements (SLAs) over longer intervals (24 hours, monthly periods). By simultaneously measuring both directions of a bidirectional connection, QoS parameters provide a holistic view of the sustained quality experienced by users, ensuring stability and predictability.¶

Maintenance parameters focus on short-term monitoring and detailed analysis for operational reliability. Maintenance parameters, over intervals such as 15 minutes or 24 hours, facilitate swift responses to intermittent faults, bursts of errors, and subtle performance changes. Maintenance parameters typically involve unidirectional analysis, where each direction of transmission is monitored independently. This unidirectional approach helps network operators precisely pinpoint faults, troubleshoot intermittent issues, and perform preventive maintenance effectively.¶

Key PM parameters focused on circuit networks such as OTN are listed as follows. Additional parameters will be needed for packet networks.¶

• ES Errored Seconds¶

• SES Severely Errored Seconds¶

• BBE Background Block Errors¶

• BBC Background Block Count¶

• UAS Unavailable Seconds¶

• SEP Severely Errored Period¶

• PJE Pointer Justification Events¶

According to collection types, purposes, and time intervals, different parameters are used. The following three transport profiles provide comprehensive coverage for maintenance and QoS monitoring across different temporal resolutions.¶

3.1. Measurement Timing

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

Measurement timing parameters are key components of network performance management, offering standardized definitions for the time-related aspects of sampling, measuring, 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, measurement 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.¶

Measurement 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.¶

Uniform time is a fixed, predefined point within each measurement interval at which a snapshot measurement 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.¶

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 measurement-value?        uint32
   +--rw snapshot
   |  +--rw uniform-time-config
   |  |  +--rw interval-value?        uint32
   |  |  +--rw unit?                  time-interval-unit
   |  +--rw threshold-config
   |  |  +--rw high-threshold?        uint32
   |  |  +--rw low-threshold?         uint32
   |  +--ro measurement-value?        uint32
   +--rw tidemarks
      +--rw threshold-config
      |  +--rw high-threshold?        uint32
      |  +--rw low-threshold?         uint32
      +--ro high-measurement-value?   uint32
      +--ro low-measurement-value?    uint32

The collection types defined based on ITU-T G.7710 establish a focused and efficient framework for network performance monitoring by specifying three core collection types: counts, snapshot, and tidemarks.¶

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).¶

4.1. Periodic Thresholding

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

The counts measurement has two types of threshold reporting methods: transient and standing condition methods. The transient condition method treats each measurement period separately. As soon as a threshold is reached or crossed in a measurement interval for a given performance measurement, 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.¶

For gauge measurements ("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.¶

4.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.¶

5.1. Periodic Events

The YANG-Push subscription model, as defined in [RFC8641], enables clients to subscribe to periodic performance measurement 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 5 shows a subscription request for the ES parameter in the itu-transport-maintenance-15min profile. It requests counts measurement data sampled every second and aggregated over a 15-minute interval. The reporting period is set to 900 seconds, so a notification is sent at the end of each measurement interval.¶

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:sn=
       "urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
     xmlns:pm-coll=
       "urn:ietf:params:xml:ns:yang:ietf-pm-collection"
     message-id="101">
  <sn:establish-subscription>
    <sn:stream>YANG-PUSH</sn:stream>
    <sn:encoding>encode-xml</sn:encoding>
    <sn:filter>
      <sn:datastore>operational</sn:datastore>
      <sn:xpath-filter>
        /pm-coll:pm-periodic-measurement/
          parameter-profile[name='itu-transport-maintenance-15min']/
          pm-parameter[name='es']/
          sampling-interval[id='1s']/
          measurement-interval[id='15min']/
          collection-types/counts/measurement-value
      </sn:xpath-filter>
    </sn:filter>
    <sn:period>900</sn:period>
    <sn:anchor-time>2024-07-01T00:00:00Z</sn:anchor-time>
  </sn:establish-subscription>
</rpc>

Figure 6 shows a notification for the ES parameter in the itu-transport-maintenance-15min profile. It reports the counts measurement value sampled every second and aggregated over a 15-minute interval. The measured value (10) represents the total errored seconds in that period.¶

<notification
    xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"
    xmlns:pm-coll=
      "urn:ietf:params:xml:ns:yang:ietf-pm-collection">
  <eventTime>2024-07-01T00:15:00Z</eventTime>
  <pm-coll:pm-periodic-measurement>
    <parameter-profile>
      <name>itu-transport-maintenance-15min</name>
      <pm-parameter>
        <name>es</name>
        <sampling-interval>
          <id>1s</id>
          <interval-value>1</interval-value>
          <unit>second</unit>
          <measurement-interval>
            <id>15min</id>
            <interval-value>15</interval-value>
            <unit>minute</unit>
            <collection-types>
              <counts>
                <measurement-value>10</measurement-value>
              </counts>
            </collection-types>
          </measurement-interval>
        </sampling-interval>
      </pm-parameter>
    </parameter-profile>
  </pm-coll:pm-periodic-measurement>
</notification>

5.2. Threshold Events

Threshold event subscriptions enable clients to receive immediate notifications when performance metrics cross predefined thresholds, providing proactive monitoring capabilities. This subscription type uses standard YANG-Push [RFC8639] [RFC8641] datastore change notifications to deliver the threshold events defined in this document.¶

+--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"
     xmlns:sn=
       "urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
     xmlns:pm-coll=
       "urn:ietf:params:xml:ns:yang:ietf-pm-collection"
     message-id="202">
  <sn:establish-subscription>
    <sn:stream>YANG-PUSH</sn:stream>
    <sn:encoding>encode-xml</sn:encoding>
    <sn:filter>
      <sn:datastore>operational</sn:datastore>
      <sn:xpath-filter>
        /pm-coll:pm-threshold-events
      </sn:xpath-filter>
    </sn:filter>
    <sn:period>1</sn:period>
    <sn:anchor-time>2024-07-01T00:00:00Z</sn:anchor-time>
  </sn:establish-subscription>
</rpc>

<notification
    xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"
    xmlns:pm-coll=
      "urn:ietf:params:xml:ns:yang:ietf-pm-collection">
  <eventTime>2024-07-01T00:05:23Z</eventTime>
  <pm-coll:pm-threshold-events>
    <periodic-events>
      <parameter-profile>
        <name>itu-transport-maintenance-15min</name>
        <pm-parameter>
          <name>es</name>
          <sampling-interval>
            <id>1s</id>
            <interval-value>1</interval-value>
            <unit>second</unit>
            <measurement-interval>
              <id>15min</id>
              <interval-value>15</interval-value>
              <unit>minute</unit>
              <event-types>
                <snapshot>
                  <event-type>High-OOR-event</event-type>
                  <event-occurred>true</event-occurred>
                  <event-time>2024-07-01T00:05:23Z</event-time>
                </snapshot>
              </event-types>
            </measurement-interval>
          </sampling-interval>
        </pm-parameter>
      </parameter-profile>
    </periodic-events>
  </pm-coll: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

8.1. Motivation

ITU-T G.7710 does not currently include a clause that explicitly mandates a capability-discovery mechanism for configurable measurement timing parameters. However, the configurability of sampling and measurement intervals defined in ITU-T G.7710, together with the streaming model defined therein, requires that clients know in advance which intervals a given server can support, so that subscription requests can be constructed without violating implementation constraints. This module provides that capability advertisement.¶

The need for interval capabilities discovery arises from several critical factors that affect the configuration and operation of performance monitoring systems. Different types of performance parameters inherently require different sampling and measurement intervals based on their characteristics and measurement objectives. For example, error-based parameters such as errored seconds (ES) may require frequent sampling to capture transient events, while availability metrics might be adequately monitored with longer intervals. Similarly, latency measurements often need high-frequency sampling to detect microsecond-level variations, whereas throughput statistics can be effectively captured with less frequent sampling.¶

Vendor dependencies represent another significant factor necessitating interval capabilities discovery. Network equipment manufacturers implement different hardware architectures, processing capabilities, and measurement engines, resulting in varying support for sampling and measurement intervals. Some vendors may support very fine-grained intervals (e.g., millisecond-level sampling) for high-precision applications, while others may be optimized for longer intervals suitable for operational monitoring. Additionally, different vendors may have different constraints on the relationship between sampling and measurement intervals, with some supporting only specific multiples or ranges.¶

The complexity of modern network environments further underscores the importance of interval capabilities discovery. Multi-vendor networks require clients to adapt their monitoring strategies based on the specific capabilities of each network element. Without proper capability discovery, clients risk configuring unsupported intervals, leading to configuration failures, suboptimal monitoring, or even system instability. The interval capabilities framework addresses these challenges by providing a standardized mechanism for discovering and understanding the temporal resolution capabilities of network elements, enabling clients to make informed decisions about interval configuration and ensuring interoperability across diverse network environments.¶

The interval capabilities module follows a hierarchical structure that mirrors the measurement configuration model, ensuring consistency between capability discovery and actual measurement configuration. The architecture consists of three levels: Parameter Profiles (collections of related performance parameters such as itu-transport-maintenance-15min), PM Parameters (individual performance parameters within profiles such as es, ses, bbe), and Interval Capabilities (sampling and measurement interval capabilities for each parameter).¶

The module defines a critical relationship between sampling and measurement intervals: measurement intervals must be multiples of their corresponding sampling intervals. This constraint ensures that measurement aggregation periods align with data collection frequency, preventing configuration errors and ensuring accurate performance monitoring. For example, if a device supports a 5-second sampling interval, valid measurement intervals would be 5s, 10s, 15s, 30s, 60s, etc. This relationship is enforced through the hierarchical structure where measurement intervals are defined within their corresponding sampling intervals.¶

8.2. Capability Discovery and Configuration Workflow

A NETCONF client can discover the sampling and measurement interval capabilities of a server by following the standard IETF procedures for capability and module discovery. This process involves multiple steps, beginning with the session establishment and extending to operational data retrieval.¶

Upon initiating a session, the client receives the server's <hello> message as defined in [RFC6241]. This message includes a list of capability URIs, indicating the supported YANG modules and protocol extensions. If the server includes entries for both ietf-pm-collection and ietf-pm-interval-capabilities, the client infers that the server supports performance measurement with parameter-specific intervals, and also advertises its supported interval values.¶

To confirm module support and retrieve metadata such as revision dates and feature availability, the client queries the YANG Library as defined in [RFC8525]. This step allows the client to verify that both the measurement model and the interval capability model are implemented and discoverable.¶

The client then queries the pm-interval-capabilities container, which is defined with config false and thus resides in the operational datastore per the Network Management Datastore Architecture (NMDA) described in [RFC8342]. By querying this container, the client can retrieve a list of supported sampling and measurement intervals for each performance parameter and profile. The structure includes constraints such as minimum and maximum values, allowed time units, and granularity. This live runtime exposure of capability information follows the model described in [RFC9196] for advertising telemetry and notification capabilities in operational state.¶

Alternatively, the same interval capabilities may be published as static data files using the format defined in [RFC9195]. This allows vendors or standards bodies to document the supported measurement intervals of a device or profile without requiring a live connection to the system.¶

At this point, the client uses the retrieved interval capabilities to configure a performance measurement subscription using the pm-collection model. This configuration is made in alignment with the update intervals supported by the server, ensuring compatibility and preventing errors such as period-unsupported, as outlined in [RFC8641].¶

This end-to-end process ensures that performance measurement configurations are both valid and optimized for the server's capabilities, leveraging both static publication and runtime introspection using standardized models and procedures.¶

8.3. Interval Capabilities Example

The following example demonstrates how a client can discover interval capabilities for the ES parameter in the itu-transport-maintenance-15min profile, specifically requesting 1-second sampling with 15-minute measurement intervals.¶

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:pm-int-cap=
       "urn:ietf:params:xml:ns:yang:ietf-pm-interval-capabilities"
     message-id="301">
  <get>
    <filter>
      <pm-int-cap:pm-interval-capabilities>
        <parameter-profile>
          <name>itu-transport-maintenance-15min</name>
          <pm-parameter>
            <name>es</name>
            <interval-relationships>
              <sampling-interval>
                <id>1s</id>
                <min-value>1</min-value>
                <max-value>1</max-value>
                <units>second</units>
                <default-value>1</default-value>
                <default-unit>second</default-unit>
                <granularity>1</granularity>
                <measurement-interval>
                  <id>measurement-range</id>
                  <min-value>5</min-value>
                  <max-value>1440</max-value>
                  <units>minute</units>
                  <default-value>15</default-value>
                  <default-unit>minute</default-unit>
                  <granularity>5</granularity>
                </measurement-interval>
              </sampling-interval>
            </interval-relationships>
          </pm-parameter>
        </parameter-profile>
      </pm-int-cap:pm-interval-capabilities>
    </filter>
  </get>
</rpc>

This example shows how a client can discover that the network element supports 1-second sampling with a flexible measurement interval range (5-1440 minutes) with 5-minute granularity. The response confirms unit support for seconds in sampling and minutes in measurement intervals, with a default recommendation of 15 minutes, enabling the client to choose any appropriate measurement duration within the supported range for their PM monitoring requirements.¶

8.4. YANG Data Model

<CODE BEGINS> file "ietf-pm-interval-capabilities@2026-05-02.yang"

module ietf-pm-interval-capabilities {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-pm-interval-capabilities";
  prefix ipc;

  import ietf-pm-collection {
    prefix pm-coll;
    reference "draft-ietf-ccamp-pm-measurements-yang";
  }

  organization
    "IETF Common Control and Measurement Plane (ccamp)
     Working Group";
  contact
    "WG Web: <https://datatracker.ietf.org/wg/ccamp/>
     Editor: Bin Yeong Yoon <mailto:byyun@etri.re.kr>";
  description
    "This YANG module defines a data model for discovering and
     expressing performance management (PM) interval capabilities
     in network equipment. The module enables clients to discover
     what sampling and measurement intervals a server can support
     for different performance parameters within various
     parameter profiles.

     This module provides hierarchical interval capability
     discovery where measurement intervals must be multiples of
     their corresponding sampling intervals, and each parameter
     can have different interval capabilities within parameter
     profiles.

     This module is designed to work with ietf-pm-collection for
     complete PM streaming solutions and supports both real-time
     monitoring and long-term trend analysis.";

  revision 2026-05-02 {
    description
      "Companion module ietf-pm-collection replaces measurement
       methods with collection types (counts, snapshot,
       tidemarks) and renames the grouping and container to
       collection-types per ITU-T G.7710; this module continues
       to describe interval capabilities for that design.";
    reference
      "RFC XXXX: A YANG Data Model of Performance Management
       Streaming";
  }

  /*
   * TYPEDEFs
   */
  typedef interval-unit {
    type enumeration {
      enum millisecond {
        description "Time interval in milliseconds.";
      }
      enum second {
        description "Time interval in seconds.";
      }
      enum minute {
        description "Time interval in minutes.";
      }
      enum hour {
        description "Time interval in hours.";
      }
      enum day {
        description "Time interval in days.";
      }
    }
    description "Supported units for expressing time intervals.";
  }

  /*
   * IDENTITIES
   */
  identity interval-capability-type {
    description
      "Base identity for different types of interval
       capabilities.";
  }

  identity sampling-interval-capability {
    base interval-capability-type;
    description
      "Capability for sampling intervals - how frequently data
       is collected.";
  }

  identity measurement-interval-capability {
    base interval-capability-type;
    description
      "Capability for measurement intervals - how long
       measurements are aggregated.";
  }

  /*
   * GROUPINGS
   */
  grouping interval-constraints {
    description
      "Constraints for supported intervals including min/max
       values and supported units. This grouping defines the
       capability constraints for both sampling and measurement
       intervals, allowing devices to express their supported
       interval ranges, units, and granularity.";
    leaf min-value {
      type uint32;
      description
        "Minimum supported value for this interval type.";
    }
    leaf max-value {
      type uint32;
      description
        "Maximum supported value for this interval type.";
    }
    leaf-list units {
      type interval-unit;
      description
        "List of supported time units for this interval type.";
    }
    leaf default-value {
      type uint32;
      description
        "Default value recommended for this interval type.";
    }
    leaf default-unit {
      type interval-unit;
      description
        "Default unit recommended for this interval type.";
    }
    leaf granularity {
      type uint32;
      description
        "Granularity step for interval values. For example, if
         granularity is 5, then only values that are multiples
         of 5 are supported.";
    }
  }

  grouping parameter-interval-capabilities {
    description
      "Interval capabilities for a specific parameter within a
       profile. This grouping defines the complete interval
       capability information for a single performance
       parameter, including its name and hierarchical interval
       relationships. The structure uses mapping-based discovery
       where all interval information is contained within the
       sampling-interval structure.";
    leaf name {
      type string;
      description
        "Name of the performance parameter (e.g., es, ses,
         bbe).";
    }
    container interval-relationships {
      description
        "Defines hierarchical relationships between sampling and
         measurement intervals for this parameter. Measurement
         intervals must be multiples of their corresponding
         sampling intervals.";
      list sampling-interval {
        key "id";
        description
          "Maps sampling intervals to their compatible
           measurement intervals with complete capability
           information.";
        leaf id {
          type string;
          description
            "Unique identifier for this sampling interval
             capability.";
        }
        uses interval-constraints;
        list measurement-interval {
          key "id";
          description
            "Detailed information for each compatible
             measurement interval within the sampling interval
             structure.";
          leaf id {
            type string;
            description
              "Unique identifier for this measurement interval
               capability.";
          }
          uses interval-constraints;
        }
      }
    }
  }

  grouping profile-parameter-capabilities {
    description
      "Capabilities for all parameters within a specific
       parameter profile. This grouping defines the complete
       capability information for a parameter profile, including
       the profile name and all performance parameters with
       their respective interval capabilities.";
    leaf name {
      type pm-coll:profile-names;
      description
        "Name of the parameter profile (e.g.,
         itu-transport-maintenance-15min).";
    }
    list pm-parameter {
      key "name";
      description
        "List of parameters with their specific interval
         capabilities within this profile.";
      uses parameter-interval-capabilities;
    }
  }

  /*
   * MAIN CONTAINER
   */
  container pm-interval-capabilities {
    description
      "Main container for hierarchical PM interval capabilities.
       This container provides comprehensive information about
       the sampling and measurement intervals that a server can
       support for different parameters within different
       parameter profiles.";
    config false;

    list parameter-profile {
      key "name";
      description
        "List of parameter profiles with their parameter-
         specific interval capabilities. Each profile represents
         a collection of parameters that share common
         measurement requirements but may have different
         interval capabilities.";
      uses profile-parameter-capabilities;
    }
  }
}

<CODE ENDS>

8.5. YANG Data Trees

module: ietf-pm-interval-capabilities
  +--ro pm-interval-capabilities
     +--ro parameter-profile* [name]
        +--ro name              pm-coll:profile-names
        +--ro pm-parameter* [name]
           +--ro name                   string
           +--ro interval-relationships
              +--ro sampling-interval* [id]
                 +--ro id              string
                 +--ro min-value?      uint32
                 +--ro max-value?      uint32
                 +--ro units*          interval-unit
                 +--ro default-value?  uint32
                 +--ro default-unit?   interval-unit
                 +--ro granularity?    uint32
                 +--ro measurement-interval* [id]
                    +--ro id              string
                    +--ro min-value?      uint32
                    +--ro max-value?      uint32
                    +--ro units*          interval-unit
                    +--ro default-value?  uint32
                    +--ro default-unit?   interval-unit
                    +--ro granularity?    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>.

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

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

[RFC8525]

Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/rfc/rfc8525>.

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

[RFC9196]

Lengyel, B., Clemm, A., and B. Claise, "YANG Modules Describing Capabilities for Systems and Datastore Update Notifications", RFC 9196, DOI 10.17487/RFC9196, February 2022, <https://www.rfc-editor.org/rfc/rfc9196>.

12.2. Informative References

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

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

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

[RFC9195]

Lengyel, B. and B. Claise, "A File Format for YANG Instance Data", RFC 9195, DOI 10.17487/RFC9195, February 2022, <https://www.rfc-editor.org/rfc/rfc9195>.

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