]> ETRI

byyun@etri.re.kr

woori-net

young@woori-net.com

IPPM Working Group performance monitoring collection YANG This document specifies a YANG data model for the collection of Performance Monitoring (PM) data, based on the collection requirements of the performance management function defined in ITU-T G.7710. The model processes raw performance data sampled at a network node and produces structured data that can be retrieved by clients via pull-based mechanisms or delivered via push-based mechanisms such as YANG-Push. This document does not define new performance metrics; the base metrics are those of the IPPM framework, and the model specifies the collection and exposure of the operationally important subset. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Performance Monitoring (PM) data generated by a Network Element (NE) undergoes a systematic processing pipeline that transforms raw observations into actionable operational insights. Traditionally, PM data has been managed through pull-based mechanisms such as SNMP polling, but the increasing scale and dynamic nature of modern networks require a more efficient, streaming-oriented approach. This document distinguishes three functional stages of the PM processing pipeline -- Sampling, Collection, and Reporting -- and defines a YANG data model for the Collection stage, referred to in this document as the PM collection model. The Collection-stage data and notifications defined in this model can be retrieved by clients via pull-based mechanisms (e.g., NETCONF get-data operations) or delivered via push-based subscription mechanisms. When push-based delivery is used, the IETF subscribed- notifications framework , its YANG Push extension for datastore updates , and the NETCONF binding for dynamic subscriptions are applicable. These three specifications together are referred to in the remainder of this document as the push-based subscription mechanisms.

PM Processing Pipeline in a Network Element The PM processing pipeline considered in this document comprises the following three stages, as illustrated in . Stage 2 (Collection) is the scope of this document.

PM Processing Pipeline | 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 , TWAMP , and STAMP inject synthetic probe packets to measure one-way or round-trip delay, packet loss, and delay variation, while In-situ OAM (IOAM) 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 . Active methods such as OWAMP , TWAMP , and STAMP generate and inject synthetic test traffic. Hybrid methods such as IOAM 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 . 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 , with the high-capacity variants in . 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 (, , ). 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 .

Network Architecture for PM Collection

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 .

Relationship to the IETF Performance Metric Framework The three-stage pipeline described above aligns with the framework for performance metric development given in . The Collection stage modelled in this document corresponds to the Computed Performance Metrics described in Section 5.3 of : the Counts and Tidemarks collection types are temporal aggregations (Section 5.3.1 of ) 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 and the IPPM framework . summarises how the three collection types map onto the result organization of the IPPM framework.

Collection types mapped to RFC 6390 Computed Performance Metrics and the RFC 2330 result organization 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 . 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 , are determined by the parameter profiles defined in this document, rather than being fixed by the YANG model itself. Except where 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.

Motivation and Scope The legacy SNMP-based collection conventions 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 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 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 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 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 (, , ) 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.

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 when, and only when, they appear in all capitals, as shown here.

PM parameters

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

Parameter Identities This module defines the base identity performance-parameter. The key of each pm-parameter entry is an identityref whose base is this identity. Specific parameters are defined as identities derived from it in other modules; parameters of specific network technologies are defined in the same way in other documents, by the relevant standards body. Identity-based typing lets a server validate the parameters a client configures and lets clients interpret collected values consistently across vendors.

Profiles

Parameter Profile Subtree

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.

Naming Parameter profiles are named to reflect their operational purpose, origin, applicable network domain, and, optionally, the primary collection interval. This naming structure supports clarity, modularity, and automation across diverse network and service layers. The naming follows this format: --[-] ]]> Where:

• <source>: Standards body or organization
  • Examples: itu, ieee, ietf, example, vendorX
• <network>: Network domain or layer
  • Examples: transport, access, core, ip, mpls, ethernet, otn, wdm, flexo
• <purpose>: Intended use or function
  • Examples: maintenance, qos, availability, sla, compliance, analytics
• <characteristic> (optional): Optional qualifying information
  • Examples: 15min, 24hr, high-priority

Examples:

• example-ip-qos-15min
• example-ip-qos-24hr
• example-mobile-availability-24hr
• vendorx-otn-sla

Note: profile names that begin with ietf- are reserved for profiles that IETF actually defines; placeholder examples in this document use example- to avoid implying IETF endorsement of profiles not yet specified. The 15-minute interval provides granular, real-time monitoring, allowing network operators to quickly detect and address short-term issues such as spikes in latency or packet loss. It is particularly useful for ensuring compliance with Service-Level Agreements (SLAs) and for managing highly dynamic networks where rapid changes can occur. In contrast, the 24-hour interval is used for long-term performance monitoring and trend analysis, helping operators understand overall network health, detect slow-developing issues, and plan for future capacity needs. This longer interval offers a broader view of the network's performance over a full day, making it ideal for strategic planning and infrastructure maintenance. Together, these intervals enable both immediate responses to network conditions and long-term network optimization.

Measurement Method Metadata Each pm-parameter entry MAY carry an optional measurement-method leaf that records the IPPM measurement method 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 .

measurement-method leaf within pm-parameter

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

Periodic Collection

Interval Timing

Sampling and Collection Intervals Subtree

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

Use Cases The hierarchical design of the ietf-pm-collection YANG module, where a performance parameter can be associated with one or more sampling intervals and each sampling interval can be associated with multiple collection intervals and collection types, supports a wide range of operational objectives. A key benefit of this structure is that, even when the sampling interval is fixed, different collection intervals can be used to derive distinct operational views of the same parameter. The collection type is selected to match the semantics of the monitored parameter: counts for cumulative event parameters, tidemarks for varying parameters where extremes are operationally significant, and snapshot for point-in-time operating state. In a Network Operations Center (NOC), the number of lost packets can be sampled every second and processed with multiple collection intervals using the counts collection type. A 1-minute collection interval supports rapid fault indication, enabling fast recognition of service degradation. A 15-minute collection interval supports routine maintenance monitoring and aligns with established operational practice. A 24-hour collection interval supports daily QoS reporting and provides a broader view of service quality over time. For latency monitoring in a NOC, a parameter may be sampled every 500 milliseconds and processed using the tidemarks collection type. A 1-minute collection interval helps detect short-lived delay spikes. A 30-minute collection interval helps identify recurring burst patterns that affect path stability. A 24-hour collection interval provides a daily worst-case view of path quality, supporting operational assessment of persistent delay behavior. For digital twin applications, packet delay variation (PDV) may be sampled every 100 milliseconds and processed using the tidemarks collection type. A 1-minute collection interval provides a synchronization stability envelope that helps the digital twin remain closely aligned with the physical network. A 5-minute collection interval supports feedback-loop tuning by capturing short-term variation patterns that influence control adjustments. A 1-hour collection interval supports model calibration by providing longer-span information about the range of delay variation observed in operation. Environmental monitoring also benefits from the same hierarchical timing structure. For example, temperature may be sampled every 10 seconds and processed using the snapshot collection type. A 1-minute collection interval supports a current operating state check. A 15-minute collection interval supports periodic baseline comparison. A 24-hour collection interval supports daily fleet-wide correlation at a common observation point, helping operators compare equipment behavior across systems and sites. Similar timing structures can also support AI/ML pipelines, where short, medium, and long collection intervals applied to the same sampled parameter provide feature sets for anomaly detection, trend analysis, and model training within a single analytics application. These examples show that the same sampling interval can support multiple operational purposes when paired with different collection intervals, and that the collection type should match the semantics of the monitored parameter. The hierarchical list structure, where parameters contain multiple sampling intervals and each sampling interval defines one or more collection intervals and collection types, supports operational flexibility, avoids configuration duplication, and enables fine-grained control of measurement strategies. The use cases summarized in are consistent with the collection types defined in , where counts represent cumulative event occurrences, snapshot represents point-in-time values, and tidemarks represent interval extremes. Use cases by sampling interval, collection interval, and collection type

Client (param)	Samp.	Coll. interval	Type	Purpose
NOC (loss)	1s	1min	counts	Rapid fault alert
	1s	15min	counts	Maintenance
	1s	24hr	counts	Daily QoS report
NOC (latency)	500ms	1min	tidemarks	Delay spike detect
	500ms	30min	tidemarks	Burst pattern obs.
	500ms	24hr	tidemarks	Daily worst-case
Digital Twin	100ms	1min	tidemarks	Sync stability
(PDV)	100ms	5min	tidemarks	Feedback tuning
	100ms	1hr	tidemarks	Model calibration
NOC (temp)	10s	1min	snapshot	State check
	10s	15min	snapshot	Periodic baseline
	10s	24hr	snapshot	Fleet-wide daily

Collection Types

Collection Types Subtree

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 , the three collection types correspond to the following operations, as summarised in . Collection Types Mapped to RFC 6390

Collection type	operation	Note
counts	Temporal aggregation (Section 5.3.1): cumulative sum over the collection interval	Resets at the end of each interval
snapshot	Sampled value at a uniform time within the interval	Organised as a singleton (Section 5.6 of ; )
tidemarks	Temporal aggregation (Section 5.3.1): minimum and maximum over the interval	High and low values retained per interval

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

Counts The counts collection type in network performance monitoring tracks the cumulative occurrences of specific events over a defined collection interval, such as 15 minutes or 24 hours. This method captures how frequently certain network activities, like errors or transmission issues, occur, providing a historical view of recurring problems. Counts reset at the end of each interval, ensuring that every period starts with a fresh count for accurate monitoring. The primary purpose of counts is to identify trends and patterns in network behavior over time, helping operators detect anomalies or areas where issues frequently arise. This collection type is particularly useful for long-term analysis, enabling preventive maintenance and optimizing network performance. Unlike instantaneous values, counts focus on aggregation over time, making it easier to understand the persistence or recurrence of faults. The data gathered through counts helps in fault management and planning by highlighting repeated errors, congestion, or performance degradation that may affect service delivery. As a result, counts provide network operators with actionable insights for troubleshooting and capacity planning, ensuring smooth operation and reliability across the network.

Snapshot Snapshot is an instantaneous value taken at a specific point in time. It captures the instantaneous value of specific performance parameters at a regular, predefined point (uniform time) within each time interval. Snapshot provides a "momentary view" of network conditions, allowing operators to observe the network's status at specific intervals. The data from these uniform-time snapshots is then aggregated and analyzed to understand the immediate state across the entire network. By taking snapshots simultaneously across all network elements, operators can correlate data between different parts of the network. Snapshots are collected at pre-determined uniform times within fixed collection intervals. The uniform time and fixed intervals can be configured based on the needs of the network.

Tidemarks The tidemarks collection type records the maximum (high tidemarks) and minimum (low tidemarks) values that a performance parameter reaches during a specified collection interval. This approach captures the extreme values and performance fluctuations, highlighting the best and worst conditions that occur within the monitoring period. Tidemarks provide deeper insights by capturing performance spikes or drops that may go unnoticed in average or cumulative data, enabling precise troubleshooting of intermittent or extreme conditions. For instance, while the average error rate over a period may appear acceptable, a high tidemark could reveal intermittent spikes in errors that require attention. Conversely, a low tidemark may expose periods of severely degraded signal quality or throughput.

Collection Interval Data Validity The collection types above summarise the samples that were available during a collection interval. When some of the expected Stage 1 samples are missing -- because of telemetry loss, partial node support, a state reset, an equipment restart, a change of interval timing, or suspension of collection -- the summarised value is still a valid number, but it does not carry the same meaning as a value computed over a complete interval. In particular, a numeric zero computed from no valid samples must not be mistaken for a measured zero. This section defines the metadata that lets a client tell these cases apart. The metadata is part of the Collection stage rather than of any delivery mechanism, so it applies identically to pull-based retrieval and to push-based delivery.

Interval Data Status Subtree

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.

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.

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.

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.

Thresholding

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

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.

Data Access Clients can access PM parameter values produced by the counts, snapshot, and tidemarks collection types using either pull-based retrieval or push-based subscription mechanisms. This section provides practical examples for both access patterns. This document does not define any new retrieval operation or subscription mechanism; the examples below use only standard NETCONF operations and YANG-Push RPCs and notifications. The data retrieved or delivered is used for maintenance and Quality of Service (QoS) monitoring in networks.

Example Module The examples in this document use the example module shown in . 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 and used with the snapshot and tidemarks collection types. Parameters of specific network technologies are defined in other documents in the same way.

Example Module Used in the Examples

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 and . The YANG data model defined here provides equivalent data structures accessible via NETCONF <get-data> operations against the operational datastore , 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. shows a NETCONF <get-data> request that retrieves the current count of the ex:lost-packets parameter (see ) 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.

Pull-Based Polling Request Example (NETCONF get-data) ds:operational example-ip-qos-15min ex:lost-packets 1s 15min ]]>

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.

Pull-Based Polling Reply Example (NETCONF get-data) example-ip-qos-15min ex:lost-packets 1s 15min 7 ]]>

Periodic Events The YANG-Push subscription model, as defined in , 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. shows a periodic subscription 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.

Periodic Event Subscription Example ds:operational /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'] encode-xml 90000 2026-07-01T00:00:00Z ]]>

shows the resulting "push-update" notification 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.

Periodic Update Notification Example (push-update) 2026-07-01T00:15:00Z 39 example-ip-qos-15min ex:lost-packets 1s 15min 15 minute false complete 10 ]]>

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 , rather than by a YANG-Push datastore subscription .

Periodic Threshold Events

Periodic Threshold Events Subtree

When a performance parameter exceeds or falls below configured thresholds for the periodic collection types of counts, snapshot, and tidemarks, the network element generates event-driven notifications containing the threshold crossing event type and occurrence time (parameter values at the time of the event can be read from the operational datastore if needed). This mechanism supports four types of threshold events, reported in the "counts-transient", "counts-standing", "snapshot", and "tidemarks" containers: transient threshold crossings of counts, standing threshold reports (TR and RTR) of counts, and out-of-range crossings of snapshot and tidemarks values. These events enable rapid response to network performance degradation and automated fault management. The threshold event subscription complements periodic subscriptions by providing real-time alerts for critical performance issues that require immediate attention. shows an example of the NETCONF request to subscribe to all pm-threshold-events notifications in the ietf-pm-collection model on the "NETCONF" event stream. No datastore and no period are given, because event notifications are sent when the events occur.

Threshold Event Subscription Example NETCONF /pm-co:pm-threshold-events encode-xml ]]>

reports a high-OOR-event threshold crossing for the tidemarks collection type of the ex:one-way-delay parameter in the example-ip-qos-15min profile, with 1-second sampling and 15-minute collection interval. It shows the event type, occurrence, and timestamp as defined in the YANG model.

Threshold Event Notification Example 2026-07-01T00:05:23Z example-ip-qos-15min ex:one-way-delay 1s 1 second 15min 15 minute High-OOR-event true 2026-07-01T00:05:23Z ]]>

Non-Periodic Threshold Events

Non-Periodic Threshold Events Subtree

Non-periodic threshold event subscriptions provide immediate notifications for critical network availability and error conditions that occur independently of regular collection intervals. These subscriptions monitor for specific events such as BUT, EUT, and CSES that indicate significant network performance degradation or service interruptions. When these events occur, the network element generates immediate notifications containing event details, timing information, and duration data. This subscription type enables proactive network management by providing real-time awareness of critical network conditions that require immediate operator attention or automated intervention. Non-periodic threshold events complement periodic monitoring by capturing exceptional conditions that may not be detected through regular interval-based collection.

YANG Data Model The YANG module for PM collection is defined below. It imports ietf-yang-types . Editor: Bin Yeong Yoon "; description "This YANG module defines a data model for the collection of performance monitoring (PM) data in network equipment, based on ITU-T G.7710. It specifies three core collection types: counts (cumulative events), snapshot (instantaneous values), and tidemarks (extreme values). The module enables proactive network monitoring through configurable sampling and collection intervals, supporting both high-frequency real-time monitoring and long-term trend analysis. It provides threshold event notifications for both periodic collection and non-periodic events (BUT, EUT, CSES). The module defines the base identity 'performance-parameter' from which the identities of specific performance parameters are derived in other modules, and the 'collection-type' typedef used by other modules to refer to the three collection types. The collected data can be retrieved by clients via pull-based mechanisms (e.g., NETCONF get-data) or delivered via push-based subscription mechanisms (e.g., YANG-Push). The design supports AI-driven applications, network digital twins, and dynamic network environments by enabling multiple simultaneous views of the same performance parameter with different temporal resolutions. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2026-10-29 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for Performance Monitoring (PM) Collection"; } /* * TYPEDEFs */ typedef profile-names { type string { pattern '[a-zA-Z][a-zA-Z0-9_-]*-[a-zA-Z][a-zA-Z0-9_-]*-' + '[a-zA-Z][a-zA-Z0-9_-]*(-[a-zA-Z][a-zA-Z0-9_-]*)?'; } description "Parameter profile name following the format: --[-] Where: - : Standards body or organization (e.g., itu, ieee, ietf) - : Network domain or layer (e.g., transport, access, core) - : Intended use or function (e.g., maintenance, qos, availability) - : Optional qualifying information (e.g., 15min, 24hr, high-priority) Examples: - example-ip-qos-15min - example-ip-qos-24hr - example-mobile-availability-24hr"; } typedef time-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 "Units for expressing time intervals."; } typedef collection-type { type enumeration { enum counts { description "Counts collection type: cumulative number of events over the collection interval."; } enum snapshot { description "Snapshot collection type: instantaneous value taken at the uniform time within the collection interval."; } enum tidemarks { description "Tidemarks collection type: maximum and minimum values reached during the collection interval."; } } description "The three collection types. Used by other modules, for example to advertise which collection types a server supports for a parameter."; reference "ITU-T G.7710"; } typedef interval-status { type enumeration { enum complete { description "The collection interval is complete: all expected samples for the interval were available, so the collected value represents a fully measured interval."; } enum partial { description "The collection interval is partial: some expected samples were missing (e.g., telemetry loss or partial node support), but at least one valid sample was collected. A partial 'counts' value is a lower bound on the true count for the interval."; } enum unavailable { description "The collection interval is unavailable: no valid sample was collected for the interval. In this case the corresponding collection-value leaf is not instantiated, so a reported value is never mistaken for a measured zero."; } } description "Validity status of a collection interval. It distinguishes a fully measured interval from one computed over an incomplete set of samples, so that a client can interpret the collected value correctly."; } /* * FEATURES */ feature coverage-counters { description "Indicates that the server reports per-interval sample coverage counters (expected-sample-count and received-sample-count) within interval-data-status."; } /* * PERFORMANCE PARAMETER IDENTITY */ identity performance-parameter { description "Base identity for performance monitoring parameters. The key of each pm-parameter entry is an identity derived from this base. Specific parameters are defined as derived identities in other modules, for example modules that define the parameters of specific network technologies."; } /* * EVENT IDENTITIES */ identity periodic-events { description "Base identity for periodic event notifications."; } identity counts-transient { base periodic-events; description "Notification for transient threshold events of the counts collection type."; } identity counts-standing { base periodic-events; description "Notification for standing threshold events of the counts collection type."; } identity snapshot { base periodic-events; description "Notification for threshold events of the snapshot collection type."; } identity tidemarks { base periodic-events; description "Notification for threshold events of the tidemarks collection type."; } identity non-periodic-events { description "Base identity for non-periodic event notifications."; } identity but { base non-periodic-events; description "Notification for Begin Unavailable Time (BUT) events."; } identity eut { base non-periodic-events; description "Notification for End Unavailable Time (EUT) events."; } identity cses { base non-periodic-events; description "Notification for Consecutive Severely Errored Seconds (CSES) events."; } /* * MEASUREMENT METHOD IDENTITIES (RFC 7799) */ identity measurement-method { description "Base identity for the IPPM measurement method (RFC 7799) by which the Stage 1 samples of a performance parameter are produced."; reference "RFC 7799: Active and Passive Metrics and Methods (with Hybrid Types In-Between)"; } identity active { base measurement-method; description "Active measurement method: dedicated synthetic test traffic is generated and injected to observe network behaviour, e.g., OWAMP (RFC 4656), TWAMP (RFC 5357), STAMP (RFC 8762)."; reference "RFC 7799, Section 3.4"; } identity passive { base measurement-method; description "Passive measurement method: observation relies solely on traffic and signals already present, e.g., reading protocol counters or observing physical-layer signals, without generating test packets."; reference "RFC 7799, Section 3.6"; } identity hybrid { base measurement-method; description "Hybrid measurement method: existing user traffic is augmented or observed in transit to obtain measurements, e.g., IOAM (RFC 9197)."; reference "RFC 7799, Section 3.8"; } /* * SUSPECT-REASON IDENTITIES */ identity suspect-reason { description "Base identity for the reason a collection interval is marked suspect (see suspect-interval-flag)."; reference "ITU-T G.7710"; } identity telemetry-loss { base suspect-reason; description "One or more expected samples were lost in transit from the Stage 1 sampling source."; } identity partial-node-support { base suspect-reason; description "Some nodes or resources contributing to the parameter did not report samples for the interval."; } identity state-reset { base suspect-reason; description "Collection state was reset during the interval, so the accumulated result does not cover the whole interval."; } identity restart { base suspect-reason; description "The equipment or collection function restarted during the interval."; } identity time-adjustment { base suspect-reason; description "Interval timing changed during the interval, for example due to a change of the sampling interval, reconfiguration, or a clock adjustment, so the interval does not contain the expected number of samples."; } identity measurement-suspended { base suspect-reason; description "Data collection was intentionally suspended for part or all of the interval, so the interval does not cover continuous measurement. This corresponds to the case in which the interval belongs to a period during which the measurement is suspended or resumed, for example administrative disabling of the PM function, a planned maintenance window, or reconfiguration of the measurement. It denotes an intentional pause of collection, as distinct from unintended sample loss (telemetry-loss), a counter reset (state-reset), or an equipment or function restart (restart)."; reference "ITU-T G.7710: suspect interval flag set when the measurement is suspended or resumed"; } identity measurement-boundary { base suspect-reason; description "The interval is the first or last interval of the measurement and does not cover the full nominal period, because the measurement did not start or stop on an interval boundary. The value is otherwise valid, but the interval is partial."; reference "ITU-T G.7710: suspect interval flag set for the first or last interval of the measurement"; } identity outage { base suspect-reason; description "A fault or outage condition (e.g., equipment or power failure, or resource unavailability) prevented the measurement from being performed for part or all of the interval, so a snapshot or tidemark may contain no data or the periodical gauge measurements were not possible. This is distinct from telemetry-loss, in which the measurement was performed but samples were lost in transit."; reference "ITU-T G.7710: suspect interval flag set when a snapshot or tidemark contains no data due to outage conditions"; } /* * COMMON GROUPINGS */ grouping threshold-config { description "Common threshold configuration for the snapshot and tidemarks collection types (high and low thresholds)."; leaf high-threshold { type uint32; description "High threshold that triggers alerts when exceeded."; } leaf low-threshold { type uint32; description "Low threshold that triggers alerts when performance falls below acceptable levels."; } } grouping transient-threshold-config { description "Threshold configuration for transient conditions. Transient thresholds only support high threshold crossings and report immediately when the count value reaches or crosses the configured transient threshold value. Transient thresholds do not support low threshold (underflow) conditions, unlike the snapshot and tidemarks collection types, which support both high and low thresholds."; leaf transient-threshold { type uint32; description "Transient threshold that triggers alerts when exceeded. Transient thresholds report immediately when the count value reaches or crosses this threshold value."; } } grouping event-state-info { description "Common event state information for all event types."; leaf event-occurred { type boolean; description "Indicates whether a threshold crossing or performance event has occurred."; } leaf event-time { type yang:date-and-time; description "Precise timestamp of when the event occurred."; } } grouping oor-event-type { description "Common out-of-range event type definition."; leaf event-type { type enumeration { enum High-OOR-event { description "High OOR threshold exceeded."; } enum Low-OOR-event { description "Low OOR threshold crossed."; } } description "Specifies whether the high or low OOR threshold was crossed."; } } grouping triggered-oor-event-info { description "Combined threshold event type and event information."; uses oor-event-type; uses event-state-info; } grouping count-transient-event-type { description "Transient threshold event type definition for the counts collection type. Transient thresholds report immediately when the count value reaches or crosses a configured threshold value."; leaf event-type { type enumeration { enum Threshold-Crossed-Event { description "Threshold crossing event generated when count value reaches or crosses the configured threshold value."; } } description "Specifies that a threshold crossing event occurred."; } } grouping triggered-count-transient-event-info { description "Combined transient threshold event type and event information for the counts collection type. Transient thresholds are independent threshold mechanisms that report immediately when count values cross configured threshold values."; uses count-transient-event-type; uses event-state-info; } grouping time-interval-config { description "Common time interval configuration."; leaf interval-value { type uint32; description "Numeric value for the interval."; } leaf unit { type time-interval-unit; description "Time unit for the interval value."; } } grouping interval-data-status { description "Validity and coverage metadata for a collection interval, aligned with the suspect interval flag. It lets a client tell a fully measured interval from an incomplete one, and a measured zero from an absent value."; reference "ITU-T G.7710"; leaf suspect-interval-flag { type boolean; default false; description "Set to 'false' at the start of a collection interval and set to 'true' when the data stored for the interval may be unreliable, for example when periodic samples are missing, when collection state is reset, when the equipment restarts, when interval timing changes, or when collection is suspended. For the snapshot collection type the initialization is inverted: G.7710 initializes the flag to 'true' at the start of the interval to indicate that no snapshot has yet been taken, and clears it to 'false' once the single snapshot has been taken at the uniform time."; reference "ITU-T G.7710"; } leaf interval-status { type interval-status; description "Validity status of the interval (complete, partial, or unavailable). When this leaf is not 'complete', the suspect-interval-flag is 'true'."; } leaf-list suspect-reason { type identityref { base suspect-reason; } description "Zero or more reasons the interval is suspect. Present only when known."; } leaf expected-sample-count { if-feature coverage-counters; type uint64; description "Number of Stage 1 samples expected during the collection interval, i.e., the number a complete interval would collect for the configured sampling interval (for periodically sampled parameters, approximately the collection interval divided by the sampling interval). This is a sample-based coverage indicator that applies to any sampled parameter and is most meaningful for periodically sampled (gauge) parameters such as tidemarks. It is not defined by ITU-T G.7710, which indicates counter coverage through 'elapsed-time' and marks incompleteness with the suspect-interval-flag; the sample counts generalize that notion for this model."; } leaf received-sample-count { if-feature coverage-counters; type uint64; description "Number of valid Stage 1 samples actually collected during the collection interval. Together with expected-sample-count it gives the interval coverage: a value equal to expected-sample-count indicates full coverage, a smaller value a partial interval, and zero an unavailable interval (no valid sample)."; } leaf elapsed-time { type uint32; units "seconds"; description "Elapsed time since the start of the current collection interval. This is the number of seconds of the interval that have been processed by the measurement, not the sum of available time; it advances during unavailable time as well and falls short of the nominal interval only when the measurement itself could not run (e.g., a boundary interval, a clock adjustment, or an outage)."; } leaf interval-start-time { type yang:date-and-time; description "Timestamp marking the start of the collection interval to which this status applies."; } leaf interval-end-time { type yang:date-and-time; description "Timestamp marking the end of the collection interval to which the reported values apply. This is the end-of-interval timestamp. It is the authoritative measurement time for the interval and should be used for correlation in preference to the notification envelope eventTime, which reflects when the notification was generated rather than the measurement interval boundary. It is present once the interval has completed."; reference "ITU-T G.7710"; } } /* * COLLECTION TYPE GROUPINGS * * Each collection type is a presence container. The presence * of the 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. This lets a profile select, for example, the * counts collection type only. */ grouping count-collection-gr { description "Counts collection type for cumulative event tracking over a collection interval. Supports transient and standing threshold reporting."; container counts { presence "Enables the counts collection type for this collection interval."; description "Contains counts collection values and configuration."; container transient-condition-config { description "Configuration for transient threshold conditions. Transient thresholds report immediately when the count value reaches or crosses the configured transient threshold value. Transient thresholds do not support low threshold (underflow) conditions, unlike the snapshot and tidemarks collection types, which support both high and low thresholds."; uses transient-threshold-config; } container standing-condition-config { must "not(standing-threshold and reset-threshold) or " + "standing-threshold >= reset-threshold" { error-message "Standing threshold must be >= reset threshold."; } description "Configuration for standing condition monitoring. When both thresholds are set, standing-threshold must be greater than or equal to reset-threshold (hysteresis)."; leaf standing-threshold { type uint32; description "Threshold value that triggers standing condition alerts."; } leaf reset-threshold { type uint32; description "Reset threshold value that clears standing conditions."; } } leaf collection-value { type uint32; config false; description "Current cumulative count value for the collection interval."; } } } grouping snapshot-collection-gr { description "Snapshot collection type for instantaneous values at the uniform time within each collection interval. Supports high/low OOR threshold reporting."; container snapshot { presence "Enables the snapshot collection type for this collection interval."; description "Contains snapshot configuration and values."; container uniform-time-config { description "Configuration of the uniform time: the fixed offset from the start of the collection interval at which the single snapshot is taken. Taking snapshots at the same uniform time across network elements lets their values be correlated."; leaf offset-value { type uint32; description "Numeric value of the offset, measured from the start of the collection interval, at which the snapshot is taken."; } leaf unit { type time-interval-unit; description "Time unit for the uniform-time offset."; } } container threshold-config { description "Configuration for snapshot threshold monitoring."; uses threshold-config; } leaf collection-value { type uint32; config false; description "Current instantaneous snapshot value."; } } } grouping tidemarks-collection-gr { description "Tidemarks collection type for maximum and minimum values over the collection interval. Supports high/low OOR threshold reporting."; container tidemarks { presence "Enables the tidemarks collection type for this collection interval."; description "Contains tidemarks values and threshold configuration."; container threshold-config { description "Configuration for tidemarks threshold monitoring."; uses threshold-config; } leaf high-collection-value { type uint32; config false; description "Current maximum value recorded during the collection interval."; } leaf low-collection-value { type uint32; config false; description "Current minimum value recorded during the collection interval."; } } } grouping collection-types-gr { description "Grouping for the three core collection types (counts, snapshot, tidemarks)."; container collection-types { description "Container for the counts, snapshot, and tidemarks collection types. Each collection type is a presence container; a collection type is collected for this collection interval only when its container is present."; uses count-collection-gr; uses snapshot-collection-gr; uses tidemarks-collection-gr; } } /* * EVENT GROUPINGS */ grouping counts-transient-event-gr { description "Transient threshold events for the counts collection type. Transient thresholds are independent threshold mechanisms that report immediately when count values cross configured threshold values."; container counts-transient { description "Contains information about transient threshold events for counts."; uses triggered-count-transient-event-info; } } grouping counts-standing-event-gr { description "Standing condition events for the counts collection type."; container counts-standing { description "Contains information about standing threshold events for counts."; leaf event-type { type enumeration { enum Threshold-Report { description "Threshold Report (TR) generated when the count value reaches or exceeds the standing-threshold configured in standing-condition-config."; } enum Reset-Threshold-Report { description "Reset Threshold Report (RTR) generated at the end of the period when the count value is at or below the reset-threshold (G.7710 standing condition clear). An RTR is not generated for an interval whose suspect-interval-flag is set (equivalent to the G.7710 'no unavailable time' condition)."; } } description "Specifies the type of standing threshold event that occurred. A Threshold-Report (TR) is generated when the collection-value reaches or exceeds the standing-threshold. A Reset-Threshold-Report (RTR) is generated at the end of the period when the collection-value is at or below the reset-threshold."; } uses event-state-info; } } grouping snapshot-events-gr { description "Threshold events for the snapshot collection type."; container snapshot { description "Contains snapshot threshold event information."; uses triggered-oor-event-info; } } grouping tidemarks-events-gr { description "Threshold events for the tidemarks collection type."; container tidemarks { description "Contains tidemarks threshold event information."; uses triggered-oor-event-info; } } /* * COLLECTION INTERVAL STRUCTURES */ grouping periodic-collection-intervals { description "Hierarchical structure for periodic collection timing and collection types."; list sampling-interval { key "id"; description "List of sampling intervals defining data collection frequency."; leaf id { type string; description "Unique identifier for this sampling interval configuration."; } leaf interval-value { type uint32 { range "1..max"; } default 1; description "Numeric value for the sampling interval."; } leaf unit { type time-interval-unit; default second; description "Time unit for the sampling interval value."; } list collection-interval { key "id"; description "List of collection intervals defining aggregation periods."; leaf id { type string; description "Unique identifier for this collection interval configuration."; } leaf interval-value { type uint32 { range "1..max"; } default 15; description "Numeric value for the collection interval."; } leaf unit { type time-interval-unit; default minute; description "Time unit for the collection interval value."; } container interval-data-status { config false; description "Operational validity and coverage status of this collection interval (see the interval-data-status grouping). In push-based delivery this status accompanies each streamed record; in pull-based retrieval it is read alongside the collection value."; uses interval-data-status; } uses collection-types-gr; } } } grouping non-periodic-events-gr { description "Grouping for non-periodic performance event parameters (BUT, EUT, CSES)."; container BUT-event { description "Begin Unavailable Time (BUT) event."; uses event-state-info; } container EUT-event { description "End Unavailable Time (EUT) event."; uses event-state-info; leaf duration { type uint32; units "seconds"; description "Total duration of unavailability in seconds."; } } container CSES-event { description "Consecutive Severely Errored Seconds (CSES) event."; leaf event-occurred { type boolean; description "Indicates whether a CSES event was generated."; } leaf start { type yang:date-and-time; description "Timestamp indicating when the CSES period began."; } leaf end { type yang:date-and-time; description "Timestamp indicating when the CSES period ended."; } leaf duration { type uint32; units "seconds"; description "Duration of the CSES period in seconds."; } leaf error-count { type uint32; description "Number of errors during the CSES period."; } } } grouping pm-periodic-collection-gr { description "Hierarchical structure for periodic PM collection."; list parameter-profile { key "name"; description "List of performance parameter profiles."; leaf name { type profile-names; description "Name of the parameter profile."; } list pm-parameter { key "name"; description "List of PM parameters within the parameter profile."; leaf name { type identityref { base performance-parameter; } description "Identity of the performance parameter being collected, derived from the performance-parameter base identity."; } leaf measurement-method { type identityref { base measurement-method; } description "IPPM measurement method (RFC 7799) by which this parameter's Stage 1 samples are produced. This leaf is optional; when absent, the measurement method is unspecified. It carries interpretation metadata only and does not affect Collection-stage behaviour. Some parameters (e.g., environmental sensor readings) are not classified by this axis."; reference "RFC 7799: Active and Passive Metrics and Methods (with Hybrid Types In-Between); RFC 6390, Section 5.4.4: method of measurement metadata"; } uses periodic-collection-intervals; } } } /* * MAIN CONTAINER */ container pm-periodic-collection { description "Main container for periodic PM collection."; uses pm-periodic-collection-gr; } /* * NOTIFICATIONS */ notification pm-threshold-events { description "Notification for periodic threshold crossing events and non-periodic performance events (BUT, EUT, CSES)."; container periodic-events { description "Container for periodic threshold events."; list parameter-profile { key "name"; description "List of performance parameter profiles for event monitoring."; leaf name { type profile-names; description "Name of the parameter profile."; } list pm-parameter { key "name"; description "List of PM parameters within the parameter profile."; leaf name { type identityref { base performance-parameter; } description "Identity of the performance parameter being monitored, derived from the performance-parameter base identity."; } list sampling-interval { key "id"; description "List of sampling intervals for event monitoring."; leaf id { type string; description "Unique identifier for this sampling interval configuration."; } uses time-interval-config; list collection-interval { key "id"; description "List of collection intervals for event aggregation."; leaf id { type string; description "Unique identifier for this collection interval configuration."; } uses time-interval-config; container event-types { description "Container for different threshold event types."; uses counts-transient-event-gr; uses counts-standing-event-gr; uses snapshot-events-gr; uses tidemarks-events-gr; } } } } } } container non-periodic-events { description "Container for non-periodic performance events (BUT, EUT, CSES)."; uses non-periodic-events-gr; } } } ]]>

YANG Data Trees

Tree Diagram of the ietf-pm-collection Module

Manageability Considerations This section discusses operational aspects of deploying the model defined in this document.

Capability discovery before configuration:

A server is not required to support every sampling interval, collection interval, or collection type for every parameter, and it rejects a configuration that it does not support. How a client discovers the supported combinations before configuration is outside the scope of this document.

Configuration and operational state:

Profiles, intervals, collection types, and thresholds are configuration and are held in the running configuration datastore. Collected values, interval status, and validity metadata are operational state and are read from the operational state datastore . A server may provide profiles as system-defined configuration, which then appear in the operational state datastore without client configuration.

Scaling and load:

The processing load on a network element grows with the number of configured "pm-parameter" and interval entries, with shorter sampling intervals, and with the number of monitored objects. The delivery load grows with the number of concurrent YANG-Push subscriptions and with shorter subscription periods. Operators should choose profiles, intervals, and subscription periods with these costs in mind. A periodic subscription period that matches the collection interval delivers each completed result once, without redundant updates. A server MAY limit the number of entries or subscriptions it accepts, and MAY reject a subscription it cannot serve, as permitted by and .

Time synchronization:

Collection interval boundaries are derived from the clock of the network element. For results to be comparable across network elements, operators should synchronize those clocks, for example with NTP or PTP. An interval in which the clock was adjusted, or in which data was otherwise incomplete, is marked by the suspect interval flag (see ).

Data validity:

A client SHOULD check "interval-data-status" before using a collected value. A value from an interval whose suspect interval flag is set should not be treated as equivalent to a value from a complete interval, for example in SLA reporting. A value of zero is interpreted according to the interval status, as described in .

Retention:

A server is not required to retain completed intervals. When it does not, a client that needs a complete history must obtain each result as its interval ends, either by subscription or by polling close to the interval boundary.

Threshold events and fault management:

Threshold events (see ) indicate performance degradation. They are not equipment alarms, but an operator may feed them into existing fault management workflows. Thresholds set too low can produce a large number of notifications. The standing condition method, with its reset threshold, can be used to limit repeated reports for a persistent condition.

Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., "config true", which is the default). All writable data nodes are under the "/pm-periodic-collection" container. These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:

"/pm-periodic-collection/parameter-profile", including its

"pm-parameter", "sampling-interval", and "collection-interval"

entries:

An attacker who can create entries, or shorten sampling intervals, could raise the processing and memory load on the network element and degrade its other functions. An attacker who can delete or modify entries could stop or alter the collection of performance data, hiding service degradation from the operator and corrupting the data used for SLA verification.

".../collection-types/counts", ".../snapshot", and ".../tidemarks":

These presence containers enable collection types. Removing them silently stops the corresponding collection and threshold reporting.

".../transient-condition-config", ".../standing-condition-config",

".../threshold-config", and ".../uniform-time-config":

Raising thresholds or the reset threshold could suppress threshold reports and hide performance degradation. Lowering them could cause a flood of notifications towards clients. Changing the uniform time offset changes when snapshots are taken, which can make results inconsistent across network elements.

"measurement-method":

Changing this leaf could cause clients to misinterpret how the collected values were obtained.

Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:

"collection-value", "high-collection-value", "low-collection-value",

and "interval-data-status":

These nodes reveal error performance, unavailability periods, and the quality of service delivered on monitored connections. This information can expose weak points in the network and indicate when and where an attack is likely to have an effect. It can also reveal commercially sensitive information, such as SLA compliance. The configuration nodes can reveal which resources and parameters an operator monitors and at which thresholds.

The "pm-threshold-events" notification carries the same kind of information as the readable nodes, including the times of unavailability (BUT and EUT events) and of consecutive severely errored seconds (CSES events). Access to it SHOULD be restricted in the same way, using NACM and the security mechanisms of the subscription framework . This YANG module defines no RPC operations or actions.

IANA Considerations This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" : URI: urn:ietf:params:xml:ns:yang:ietf-pm-collection Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document also requests IANA to register the following YANG module in the "YANG Module Names" registry : Name: ietf-pm-collection Namespace: urn:ietf:params:xml:ns:yang:ietf-pm-collection Prefix: pm-co Reference: RFC XXXX

References Normative References This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. ITU-T This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Informative References This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge. The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK] The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK] This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss. In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals. This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK] This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. [STANDARDS-TRACK] This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols. These metrics can be used to characterize traffic on live networks and services. This memo documents an Internet Best Current Practice. The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. This document extends the Network Configuration Protocol (NETCONF) defined in RFC 6241 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document updates RFCs 6241 and 7950. The update to RFC 6241 adds new and operations and augments existing,, and operations. The update to RFC 7950 requires the usage of the YANG library (described in RFC 8525) by NETCONF servers implementing the NMDA. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.

Contributors KT

kwangkoog.lee@kt.com

SK Telecom

jongyoon.shin@sk.com

LGU+

sy.nam@lguplus.co.kr