A YANG Data Model of Performance Management Streaming

Introduction With the rise of AI-driven applications, network digital twins, and increasingly dynamic network environments, there is growing demand for performance management (PM) streaming capabilities. PM streaming enables proactive issue detection, allowing network operators to identify and address potential problems before they affect service. It also helps optimize resource allocation, ensuring efficient use of bandwidth and other network resources. The ITU-T G.7710 standard provides a foundational framework for managing transport network elements, addressing requirements, parameters, and measurement methods for performance management. However, G.7710 does not define YANG data models or specific protocols needed for PM streaming, which are essential for modern network management. To support PM streaming, various IETF documents and protocols (, , , ) can be utilized. This document provides a YANG data model for PM streaming in network equipment based on ITU-T G.7710, demonstrating how to subscribe to the YANG model using the IETF push model.

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

PM streaming telemetry PM streaming is a real-time method for measuring and transmitting data to monitor the performance and health of network devices and systems. It provides valuable insights into key metrics like errored seconds (ES), latency, and packet loss, helping to optimize networks, detect anomalies, and manage faults proactively. Unlike traditional periodic data collection, PM streaming delivers continuous updates, enabling faster, more responsive network adjustments. Using telemetry protocols like YANG Push, PM streaming allows for more frequent and detailed performance monitoring. By integrating this data into AI-driven analytics, it supports preemptive interventions, enhancing overall network reliability. Additionally, it keeps digital twins synchronized with the physical network, offering real-time insights for predictive maintenance, planning, and optimization. The procedures for Performance Management streaming between a network node and clients such as operation systems (OS), AI applications, Network digital twins (NDT) involve continuous measurement of performance metrics on PM parameters using three methods: counts (tracking event occurrences), snapshots (instantaneous metric values), and tidemarks (extreme values over a period). Clients can initiate the process by sending a subscription request specifying the metrics, measurement methods, intervals, and filtering criteria. Once the node confirms the subscription, it collects and aggregates PM data based on the requested metrics and intervals. Notifications with PM data, including timestamps, metrics, and measurement methods, are sent to clients at each interval via protocols like NETCONF or RESTCONF. Clients then process the data, using it for real-time monitoring, historical analysis, or triggering alerts based on thresholds. They can also manage subscriptions by modifying parameters or suspending them as needed.

Measurement Methods The measurement methods defined based on ITU-T G.7710 establish a focused and efficient framework for network performance monitoring by specifying three core modes: count, snapshot, and tidemark. 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. Count and snapshot modes provide immediate operational data without incurring the processing overhead associated with metrics like averages and variances etc. 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 measurement modes 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 measurement modes offer sufficient expressiveness to support comprehensive performance monitoring without excessive resource use. So, they are specifically optimized for Southbound Interface (SBI) between Physical Network Controllers (PNCs) and NEs to ensures as follows:

Lightweight to implement
Consistently supported across vendors
Efficient for transport and storage in network management systems

The measurement methods 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).

Counts Counts measurement in network performance monitoring tracks the cumulative occurrences of specific events over a defined period, 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 type of measurement is particularly useful for long-term analysis, enabling preventive maintenance and optimizing network performance. Unlike instantaneous measurements, 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.

Snapshots Snapshots are instantaneous measurements taken at a specific point in time. They capture the instantaneous value of specific performance parameters at a regular, predefined point (uniform time) within each time interval. Snapshots provide 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 transport network. Snapshots are collected at pre-determined uniform times within fixed intervals (e.g., every 15 minutes, 24 hours). The uniform time and fixed intervals can be configured based on the needs of the network.

Tidemarks Tidemark measurements record the maximum (high tidemark) and minimum (low tidemark) values that a performance parameter reaches during a specified observation window. These extreme values offer insight into the range of performance fluctuations, highlighting the best and worst conditions that occur within the monitoring period. Tidemark measurements 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.

Periodic Subscriptions Clients can receive a streaming of values of the PM parameters (PM data) by the measurement methods of counts, snapshots, and tidemarks with various time intervals, after subscribing to them in equipment. The streaming data measured on the PM parameters are used for maintenance and Quality of Service (QoS) monitoring in networks.

Maintenance and QoS monitoring Performance management data contribute to enhancing overall network reliability. It consists of Maintenance and QoS data generated by maintenance and QoS parameters respectively. These two categories serve different purposes and focus on distinct aspects of network management. By continuously tracking different aspects of network performance, they ensure that the network infrastructure remains robust, capable of meeting operational demands, and able to deliver consistent and high-quality services to users. The Maintenance data is to ensure the overall operational integrity and reliability of the network. It is focused on maintaining the health of the physical network infrastructure, detecting and diagnosing faults, and addressing any issues that could compromise network stability. Maintenance-related performance parameters are typically aimed at identifying physical layer issues, equipment malfunctions, or any performance degradation. These metrics are particularly useful for preventive and corrective maintenance activities. Common maintenance metrics might include error counts, signal degradation measurements, and transmission errors. These types of data help in triggering alarms or initiating repairs to physical network elements, such as optical fiber problems or electrical signal faults. On the other hand, the QoS data is primarily concerned with monitoring and ensuring the quality of services delivered over the network. While maintenance focuses on network health at the infrastructure level, QoS is centered on the performance of data transmission and how effectively the network meets the needs of end-users. QoS data is used to measure the quality of services such as voice, video, and other data applications that require stable and reliable network performance. Metrics for QoS often include latency (the delay in data transmission), jitter (the variation in packet arrival times), packet loss, bandwidth utilization, and throughput. These metrics are crucial in ensuring that the network delivers services at a level that meets or exceeds the expectations outlined in service-level agreements (SLAs). Maintenance data typically deal with the health and status of individual network elements or links. They often involve unidirectional measurements to detect faults or issues in specific components or paths. QoS data often need to be measured in both directions of a communication path to ensure overall service quality. This is because many applications and services rely on two-way communication, and the user experience depends on performance in both directions.

Time intervals In network performance management, periodic time intervals of 15 minutes and 24 hours are commonly used for network nodes to measure and notify performance data of clients. These intervals serve distinct purposes, helping network operators monitor both short-term fluctuations and long-term trends in network performance. 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. In the context of emerging technologies like AI and network digital twins, smaller sampling intervals are becoming increasingly necessary. These technologies demand real-time or near-real-time performance data to function optimally. As these capabilities become more integral to advanced network operations, the shift towards smaller sampling intervals ensures that they can operate efficiently, react to network changes faster, and improve overall network reliability and performance.

PM Parameters Metric value of PM parameters is measured for maintenance and QoS monitoring over networks. Quality of Service (QoS) parameters are designed to assess the network's long-term ability to consistently deliver agreed-upon service quality to customers. They primarily verify performance against contractual obligations defined in service-level agreements (SLAs) over longer intervals (24 hours, monthly periods). By simultaneously measuring both directions of a bidirectional connection, QoS parameters provide a holistic view of the sustained quality experienced by users, ensuring stability and predictability. Maintenance parameters focus on short-term monitoring and detailed analysis for operational reliability. Maintenance parameters, over intervals such as 15 minutes or 24 hours, facilitate swift responses to intermittent faults, bursts of errors, and subtle performance changes. Maintenance parameters typically involve unidirectional analysis, where each direction of transmission is monitored independently. This unidirectional approach helps network operators precisely pinpoint faults, troubleshoot intermittent issues, and perform preventive maintenance effectively. Key PM parameters focused on circuit networks such as OTN are listed as follows. Additional parameters will be needed for packet networks. According to the types of the measurement methods, purposes, and time intervals, different parameters are used.

Maintenance parameters measured with counts, snapshots and tidemarks over 15-minute time interval: ES, SES, BBE, BBC, UAS
Maintenance parameters measured with counts, snapshots and tidemarks over 24-hour time interval: ES, SES, BBE, BBC, UAS, PJE
QoS parameters measured with counts over 24-hour time interval: ES, SES, BBE, BBC, SEP, UAS

Threshold Event Subscriptions Threshold Events are triggered when a metric value reaches or crosses a pre-defined threshold. There are two types of threshold event notifications: periodic and non-periodic event notifications.

Periodic threshold events Periodic events are triggered when the count or gauge value reaches a pre-defined threshold during periodic measurements including counts, snapshots, and tidemarks for performance parameters. [Counter measurement events] Counter measurement ("counts") has two types of threshold reporting methods: transient and standing condition methods. The transient condition method treats each measurement period separately. As soon as a threshold is reached or crossed in a 15-minute/24-hour period for a given performance measurement, a threshold report (TR) is generated. The standing condition method is an option for 15-minute periods. 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. [Gauge measurement events] For gauge measurements ("snapshots" 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. These out-of-range methods are applicable for 15-minute and 24-hour measurements.

Non-Periodic threshold events Non-periodic events are triggered regardless of the measurement methods (counts, snapshots, 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.

YANG Data Model

PM measurements module The pm-measurements module consists of a periodic measurement container and notification of threshold events. The pm-periodic-measurement container aggregates various measurement methods (counts, snapshots, tidemarks) and collects data at regular intervals. It includes mechanisms for continuous count-based tracking, instantaneous snapshot captures, and the recording of peak values over time. This integrated approach enables operators to obtain a complete and detailed view of network performance trends, allowing them to monitor steady behavior, capture transient conditions at specific moments, and identify peak usage or stress periods effectively. Complementing the periodic measurements, the threshold events notification (periodic-threshold-events and non-periodic-threshold-events) incorporates an event detection mechanism that uses threshold criteria to trigger alerts when performance metrics deviate from expected ranges. One aspect focuses on scheduled comparisons where measurements are consistently evaluated against predefined thresholds, while the other captures unexpected or isolated deviations outside of the regular monitoring cycle. This dual-layered strategy not only helps in identifying persistent issues, but also ensures that sudden, anomalous performance events are promptly recognized and addressed. Editor: Bin Yeong Yoon "; description "This YANG module defines a data model for performance management measurements, based on ITU-T G.7710 for equipment. It specifies measurement methods and event notifications."; revision 2025-04-06 { description "Initial version."; reference "draft-ietf-ccamp-pm-measurements-yang"; } /* * TYPEDEFs */ typedef parameter-units { type string; description "Unit of measurement for performance management parameters defined by network elements (servers)."; } typedef parameter-name { type identityref { base pm-param:performance-parameter; } description "Name of the performance parameter being measured."; } /* * GROUPINGS */ grouping out-of-range-config { description "An out-of-range (OOR) event is triggered to indicate an overflow or underflow condition when a measured metric exceeds a configured high threshold or falls below a configured low threshold. These events apply to count (transient), snapshot, and tidemark measurements."; leaf high-oor-threshold { type uint32; description "High out-of-range threshold."; } leaf low-oor-threshold { type uint32; description "Low out-of-range threshold."; } } grouping event-state-info { description "Contains information about the occurrence and timing of an event."; leaf event-occurred { type boolean; description "Indicates whether an event has occurred."; } leaf event-time { type yang:date-and-time; description "Timestamp of when the event occurred."; } } grouping oor-event-type { description "Defines the type of out-of-range event that occurred, indicating whether a high or low threshold was reached."; leaf event-type { type enumeration { enum High-OOR-event { description "High OOR threshold reached"; } enum Low-OOR-event { description "Low OOR threshold reached"; } } description "Indicates whether the high or low OOR threshold was reached."; } } grouping triggered-oor-event-info { description "Combines threshold event type and event details for a triggered OOR event, providing complete information about when and what type of threshold was crossed."; uses oor-event-type; uses event-state-info; } grouping count-measurement-gr { description "Counts are cumulative measurements tracking the total occurrences of specific network events or activities over a time interval (e.g., 15 minutes). Counts are reset at regular intervals to start new measurements."; container count-measurement { description "Contains the count value and its units, as well as configuration for transient and standing out-of-range conditions."; leaf count-value { type uint32; config false; description "Actual count value of the measurement."; } leaf count-units { type parameter-units; config false; description "Units of measurement for the count-value."; } container transient-condition-config { description "Configuration for transient out-of-range conditions, defining thresholds that trigger immediate events when crossed."; uses out-of-range-config; } container standing-condition-config { description "Configuration of the standing condition event for count measurements."; leaf standing-threshold { type uint32; description "Standing threshold value."; } leaf standing-reset-threshold { type uint32; description "Reset threshold value."; } } } } grouping snapshot-measurement-gr { description "Defines the structure for snapshot measurements, which capture instantaneous values of performance parameters at specific points in time. These measurements provide a momentary view of network conditions and are typically collected at uniform intervals."; container snapshot-measurement { description "Snapshots are instantaneous measurements taken at specific points in time, providing a momentary view of network conditions. Snapshots are collected at uniform intervals (e.g., 15 minutes or 24 hours)."; leaf uniform-time { type uint32; units "seconds"; description "Interval between snapshot measurements."; } leaf snapshot-value { type uint32; config false; description "Actual snapshot value of the measurement."; } leaf snapshot-units { type parameter-units; config false; description "Units of measurement for the snapsho."; } uses out-of-range-config; } } grouping tidemark-measurement-gr { description "Tidemarks record the highest (maximum) and lowest (minimum) values of a specific performance metric over a defined period (e.g., 15 minutes or 24 hours). They capture extreme values reflecting significant performance peaks."; container tidemark-measurement { description "Contains the high and low tide values and their units, as well as configuration for out-of-range conditions."; leaf high-tide-value { type uint32; config false; description "Actual high tide value of the measurement."; } leaf high-tide-units { type parameter-units; config false; description "Units of measurement for the high tide value."; } leaf low-tide-value { type uint32; config false; description "Actual low tide value of the measurement."; } leaf low-tide-units { type parameter-units; config false; description "Units of measurement for the low tide value."; } uses out-of-range-config; } } grouping count-transient-event-gr { description "A Threshold Report (TR) is generated for a counter when its value reaches or crosses the configured threshold."; container count-transient-event { description "Contains information about transient threshold events for count measurements, indicating when a count value crosses configured thresholds."; uses triggered-oor-event-info; } } grouping count-standing-event-gr { description "A Threshold Report (TR) is generated when the set threshold is exceeded. A Reset Threshold Report (RTR) is issued at the end of the period if the value falls below or equals the reset threshold."; container count-standing-event { description "Contains information about standing threshold events for count measurements, tracking when values exceed thresholds and when they return below reset thresholds."; leaf event-type { type enumeration { enum Threshold-Report { description "High OOR threshold reached"; } enum Reset-Threshold-Report { description "Low OOR threshold reached"; } } description "Indicates whether a TR or RTR was generated."; } uses event-state-info; } } grouping snapshot-events-gr { description "Groups together event-related information for snapshot measurements, including threshold crossing events and their timing."; container snapshot-event { description "High (or low) snapshot event triggered when the snapshot-value reaches or crosses a high (or low) OOR threshold."; uses triggered-oor-event-info; } } grouping tidemark-events-gr { description "Groups together event-related information for tidemark measurements, including threshold crossing events and their timing."; container tidemark-event { description "High (or low) tidemark event triggered when the tidemark-value reaches or crosses a high (or low) OOR threshold."; uses triggered-oor-event-info; } } grouping event-parameters-gr { description "Groups together various non-periodic event parameters including availability events (BUT, EUT) and error-related events (CSES)."; container BUT-event { description "Begin Unavailable Time (BUT) event marking the start of a period when a network element or connection becomes unavailable."; uses event-state-info; } container EUT-event { description "End Unavailable Time (EUT) event marking the end of a period when a network element or connection was unavailable."; leaf event-occurred { type boolean; description "Indicates whether an EUT event was generated."; } leaf event-time { type yang:date-and-time; description "Timestamp of the EUT event."; } leaf total-unavailable-time { type uint32; units "seconds"; description "Total duration of unavailability."; } } container CSES-event { description "Consecutive Severely Errored Seconds (CSES) event detected within a specified time frame."; leaf event-occurred { type boolean; description "Indicates whether a CSES event was generated."; } leaf begin-time { type yang:date-and-time; description "Timestamp indicating when the CSES period began."; } leaf end-time { 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."; } leaf error-count { type uint32; description "Number of errors during the CSES period."; } } } grouping pm-parameter-entry { description "Defines the basic structure for identifying a performance parameter being measured."; leaf parameter-name { type parameter-name; description "Name of the performance parameter being measured."; } } grouping pm-threshold-events-gr { description "Groups together all threshold-related events for performance parameters, including both periodic and non-periodic threshold events."; container periodic-threshold-events { description "Threshold crossing events for periodic measurements (counts, snapshots, tidemarks)."; list pm-parameter { key "parameter-name"; description "List of performance parameters for which periodic threshold events are reported."; uses pm-parameter-entry; uses count-transient-event-gr; uses count-standing-event-gr; uses snapshot-events-gr { refine "snapshot-event/event-occurred" { description "Indicates whether the snapshot-value reached a high or low OOR threshold."; } refine "snapshot-event/event-time" { description "Timestamp when the snapshot-value crossed the high or low OOR threshold."; } } uses tidemark-events-gr { refine "tidemark-event/event-occurred" { description "Indicates whether the tidemark-value reached a high or low OOR threshold."; } refine "tidemark-event/event-time" { description "Timestamp when the tidemark-value crossed the high or low OOR threshold."; } } } } container non-periodic-threshold-events { description "Contains non-periodic threshold events such as BUT, EUT, and CSES events."; uses event-parameters-gr; } } grouping pm-periodic-measurement-gr { description "Defines the structure for periodic performance measurements, including count, snapshot, and tidemark measurements for various parameters."; list pm-parameter { key "parameter-name"; description "List of performance parameters being measured periodically."; uses pm-parameter-entry; uses count-measurement-gr; uses snapshot-measurement-gr; uses tidemark-measurement-gr; } } /* * MAIN CONTAINER */ container pm-periodic-measurement { description "Contains periodic performance measurements (count, snapshot, tidemark) for maintenance and QoS monitoring. Measurements are typically taken over 15-minute and 24-hour intervals and categorized by purpose (maintenance or QoS)."; uses pm-periodic-measurement-gr; } /* * NOTIFICATIONS */ notification pm-threshold-events { description "Threshold crossing events for performance parameters."; uses pm-threshold-events-gr; } } ]]>

PM parameters module The PM parameter module defines performance management parameters with 15-minute and 24-hour measurement intervals and QoS parameters with a 24-hour measurement interval. It serves as a repository for key measurement settings and operational parameters, enabling consistent configuration and interoperability across diverse network devices and management systems. Editor: Bin Yeong Yoon "; description "This YANG module defines performance management parameters based on ITU-T G.7710."; revision 2025-04-06 { description "Initial version."; reference "draft-ietf-ccamp-pm-parameters-yang"; } // Base identity for all performance parameters identity performance-parameter { description "Base identity for performance monitoring parameters."; } // Parameter identities identity es { base performance-parameter; description "Errored Second. Units: seconds"; } identity ses { base performance-parameter; description "Severely Errored Second. Units: seconds"; } identity bbe { base performance-parameter; description "Background Block Error. Units: errors"; } identity bbc { base performance-parameter; description "Background Block Count. Units: blocks"; } identity uas { base performance-parameter; description "Unavailable Second. Units: seconds"; } identity pje { base performance-parameter; description "Pointer Justification Event. Units: events"; } identity sep { base performance-parameter; description "Severely Errored Period. Units: seconds"; } grouping maintenance-parameters-15min { description "Groups together maintenance-related performance parameters measured over a 15-minute interval, including error and availability metrics."; container maintenance-parameters-15min { description "Parameters for 15-minute maintenance monitoring interval."; leaf es { type uint32; units "seconds"; config false; description "Errored Second."; reference "Corresponds to 'es' identity."; } leaf ses { type uint32; units "seconds"; config false; description "Severely Errored Second."; reference "Corresponds to 'ses' identity."; } leaf bbe { type uint32; units "errors"; config false; description "Background Block Error."; reference "Corresponds to 'bbe' identity."; } leaf bbc { type uint32; units "blocks"; config false; description "Background Block Count."; reference "Corresponds to 'bbc' identity."; } leaf uas { type uint32; units "seconds"; config false; description "Unavailable Second."; reference "Corresponds to 'uas' identity."; } } } grouping maintenance-parameters-24hr { description "Groups together maintenance-related performance parameters measured over a 24-hour interval, including error, availability, and pointer justification metrics."; container maintenance-parameters-24hr { description "Maintenance monitoring parameters with a 24-hour interval."; leaf es { type uint32; units "seconds"; config false; description "Errored Second."; reference "Corresponds to 'es' identity."; } leaf ses { type uint32; units "seconds"; config false; description "Severely Errored Second."; reference "Corresponds to 'ses' identity."; } leaf bbe { type uint32; units "errors"; config false; description "Background Block Error."; reference "Corresponds to 'bbe' identity."; } leaf bbc { type uint32; units "blocks"; config false; description "Background Block Count."; reference "Corresponds to 'bbc' identity."; } leaf uas { type uint32; units "seconds"; config false; description "Unavailable Second."; reference "Corresponds to 'uas' identity."; } leaf pje { type uint32; units "events"; config false; description "Pointer Justification Event."; reference "Corresponds to 'pje' identity."; } } } grouping qos-parameters-24hr { description "Groups together Quality of Service (QoS) related performance parameters measured over a 24-hour interval, including error, availability, and severely errored period metrics."; container qos-parameters-24hr { description "QoS monitoring parameters with a 24-hour interval."; leaf es { type uint32; units "seconds"; config false; description "Errored Second."; reference "Corresponds to 'es' identity."; } leaf ses { type uint32; units "seconds"; config false; description "Severely Errored Second."; reference "Corresponds to 'ses' identity."; } leaf bbe { type uint32; units "errors"; config false; description "Background Block Error."; reference "Corresponds to 'bbe' identity."; } leaf bbc { type uint32; units "blocks"; config false; description "Background Block Count."; reference "Corresponds to 'bbc' identity."; } leaf uas { type uint32; units "seconds"; config false; description "Unavailable Second."; reference "Corresponds to 'uas' identity."; } leaf sep { type uint32; units "periods"; config false; description "Severely Errored Period."; reference "Corresponds to 'sep' identity."; } } } container pm-parameters { description "Container for all performance parameters."; uses maintenance-parameters-15min; uses maintenance-parameters-24hr; uses qos-parameters-24hr; } } ]]>

Relationship between measurement and parameter modules The performance measurements module leverages the imported parameters from the PM parameters module, ensuring that all performance-related settings, such as thresholds and timing information, are defined consistently. By doing so, it promotes uniformity across the system, making sure that the data collected adheres to a common structure and can be easily interpreted by different network components. This modular approach not only streamlines the management of measurement parameters but also facilitates interoperability between different network devices and management systems. As a result, any updates or refinements made to the parameter definitions in the PM parameters module automatically benefit the measurements module, reinforcing the overall flexibility and maintainability of the performance management framework.

YANG Data Tree The YANG data tree structure is as follows:

Tree of pm measurements module

Tree of pm parameters

Subscription Examples Below are practical use cases demonstrating different subscription scenarios. These examples illustrate periodic and non-periodic subscriptions, including notifications triggered by threshold breaches. Each example aligns with IETF YANG Push protocols, showcasing how network elements generate and stream performance data based on subscription parameters.

Periodic Subscription shows an example of the NETCONF request that subscribes to receive periodic notifications by the count measurement on the Errored Second (es) parameter for maintenance with a 15-minute interval.

Periodic Subscription Example YANG-PUSH encode-xml operational

/pm-meas:pm-periodic-measurement/pm-parameter[ parameter-name='pm-param:es' ]/count-measurement/count-value

900

2024-03-19T00:00:00Z

]]> shows an example of the NETCONF notification resulting from the subscription above.

Periodic Notification Example 2024-03-19T00:30:00Z

pm-param:es

]]>

Threshold Event Subscription shows an example of the NETCONF request to subscribe to receive event notifications triggered by threshold events (high-oor-event) for snapshot measurement on the Severely Errored Second (SES) parameter for maintenance with a 15-minute interval.

Threshold Event Subscription Example YANG-PUSH encode-xml operational

/pm-meas:threshold-events/periodic-threshold-events/ pm-parameter[parameter-name='pm-param:ses']/ snapshot-event[event-type='High-OOR-event']

]]> shows an example of the NETCONF notification that would be triggered after the subscription in .

Threshold Event Notification Example 2024-03-19T00:15:00Z

pm-param:ses

High-OOR-event

true

2024-03-19T00:15:00Z

]]>

Security Considerations TBD.

IANA Considerations TBD.