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 In network performance monitoring, ITU-T G.7710 defines two measurement methods that measures a metric value with periodic intervals such as 15-minute or 24-hour periods: counter measurements ("counts") and gauge measurements ("Snapshots" and "tidemarks"). These complementary methods provide a holistic view of network behavior by capturing both long-term trends and real-time conditions. The counter measurements provide data on the frequency of specific events, enabling long-term analysis of recurring issues. Meanwhile, The gauge measurement involves capturing instantaneous values of performance monitoring metrics at one-second intervals. This high-frequency sampling occurs during defined periodic intervals rather than continuously. They offer real-time insight and capture extreme conditions, helping to identify immediate performance problems or deviations from normal behavior.

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 time 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 value 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 recent 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 technologies 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. Key PM parameters focused on circuit networks 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 (Counts, snapshots and tidemarks for maintenance monitoring with 15minute-time interval): ES, SES, BBE, BBC, UAS
Extended Maintenance Parameters (Counts, snapshots and tidemarks for maintenance monitoring with 24-hour time interval): ES, SES, BBE, BBC, UAS, PJE
QoS Parameters (Counts for QoS monitoring with 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, when at the end of the period 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. The 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 such as counts, snapshots, and tidemarks. The following parameters are used for the 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 amount of error counts.

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

YANG Data Model Editor: Bin Yeong Yoon "; description "This YANG module defines a data model for performance management streaming, based on ITU-T G.7710 for equipment. It specifies measurement types, performance parameters, their streaming subscriptions, and event notifications."; revision 2024-10-10 { description "Initial version"; } /* * TYPEDEFs */ typedef parameter-unit { type string; description "Unit of measurement for performance management parameters defined by network elements (servers)."; } typedef maintenance-parameters { type enumeration { enum es { description "Errored Second"; } enum ses { description "Severely Errored Second"; } enum bbe { description "Background Block Error"; } enum bbc { description "Background Block Count"; } enum uas { description "Unavailable Second"; } } description "Enumeration of performance parameters used for maintenance monitoring with 15 minute time interval."; } typedef maintenance-parameters-extended { type enumeration { enum es { description "Errored Second"; } enum ses { description "Severely Errored Second"; } enum bbe { description "Background Block Error"; } enum bbc { description "Background Block Count"; } enum uas { description "Unavailable Second"; } enum pje { description "Pointer Justification Event"; } } description "Enumeration of performance parameters used for maintenance monitoring with 24 hour time interval."; } typedef qos-parameters { type enumeration { enum es { description "Errored Second"; } enum ses { description "Severely Errored Second"; } enum bbe { description "Background Block Error"; } enum bbc { description "Background Block Count"; } enum uas { description "Unavailable Second"; } enum sep { description "Severely Errored Period"; } } description "Enumeration of performance parameters used for QoS monitoring with 24 hours."; } /* * GROUPINGS */ grouping count-standing-condition-config { container standing-condition-config { description "Optional configuration, applicable only for 15-minute intervals of the count measurements"; leaf standing-threshold { type uint32; description "configuring the standing threshold"; } leaf standing-reset-threshold { type uint32; description "configuring the reset standing threshold"; } } } grouping count-transient-condition-config { container transient-condition-config { uses out-of-range-config; } } grouping count-measurement-15min-gr { description "Counts are cumulative measurements that track the total occurrences of specific network events or activities over 15 minutes. Counts are reset at regular intervals to start fresh measurements."; container count-measurement { leaf count-value { type uint32; config false; description "The cumulative value of the count over the 15-minute interval."; } leaf count-unit { type parameter-unit; config false; description "Unit of measurement for the count-value."; } uses count-transient-condition-config; uses count-standing-condition-config; } } grouping count-measurement-24hr-gr { description "Counts are cumulative measurements that track the total occurrences of specific network events or activities over 24 hours. Counts are reset at regular intervals to start fresh measurements. "; container count-measurement { leaf count-value { type uint32; config false; } leaf count-unit { type parameter-unit; config false; description "Unit of measurement for the counts-value."; } uses count-transient-condition-config; } } grouping snapshot-measurement-gr{ container snapshot-measurement { description "Snapshots are instantaneous measurements taken at a specific point in time. They provide a momentary view of network conditions. Snapshots are collected at pre-determined uniform times within fixed intervals (e.g., every 15 minutes, 24 hours)."; leaf uniform-time { type uint32; units "seconds"; description "Consistent intervals for capturing network performance data."; } leaf snapshot-value { type uint32; config false; } leaf snapshot-unit { type parameter-unit; config false; description "Unit of measurement for the snapshot-value."; } uses out-of-range-config; } } grouping tidemark-measurement-gr{ container tidemark-maintenance { description "Tidemarks record the highest (maximum) or lowest (minimum) values of a specific performance metric over a defined period, such as 15 minutes or 24 hours. They are designed to capture extreme values that reflect significant performance peaks."; leaf high-tide-value { type uint32; config false; } leaf high-tide-unit { type parameter-unit; config false; description "Unit of measurement for the high-tide-value."; } leaf low-tide-value { type uint32; config false; } leaf low-tide-unit { type parameter-unit; config false; description "Unit of measurement for the low-tide-value."; } uses out-of-range-config; } } 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 its high threshold or falls below its low threshold. These events apply to count (transient), snapshot, and tidemark measurements."; leaf high-oor-threshold { type uint32; description "Configuring the high out of range (OOR) report"; } leaf low-oor-threshold { type uint32; description "Configuring the low out of range (OOR) report"; } } grouping event-state-info { leaf event-occurred { type boolean; description "Indicates whether an event occurs or not."; } leaf event-time { type yang:date-and-time; description "A timestamp indicating when the event occurred"; } } grouping triggered-oor-event-info { uses oor-event-type; uses event-state-info; } grouping count-transient-event-gr { description "Threshold report (TR) is generated for the counter measurement when the threshold is reached or is reached or crossed for a given performance measurement"; container count-transient-event { uses triggered-oor-event-info; } } grouping count-standing-event-gr { description "A Threshold Report (TR) is generated when the set threshold is exceeded, and a Reset Threshold Report (RTR) is issued at the end of the period if the value drops below or equals the reset threshold."; container count-standing-event { leaf event-type { description "Indicates whether TR or RTR was generated"; type enumeration { enum Threshold-Report { description "High OOR threshold reached"; } enum Reset-Threshold-Report { description "Low OOR threshold reached"; } } } uses event-state-info; } } grouping snapshot-events-gr{ description "High (or low) snapshot event is triggered as the high (or low) out of range when the snapshot value reaches or crosses the high (or low) threshold."; container snapshot-event{ uses oor-event-type; leaf event-occurred { type boolean; description "Indicates whether the snapshot-value has reached the high(or low)-oor-threshold."; } leaf event-time { type yang:date-and-time; description "A timestamp indicating when the snapshot-value reached the high(or low)-oor-threshold"; } } } grouping oor-event-type { leaf event-type { description "Indicates whether the high or low threshold was reached"; type enumeration { enum High-OOR-event { description "High OOR threshold reached"; } enum Low-OOR-event { description "Low OOR threshold reached"; } } } } grouping tidemark-events-gr { description "High (or low) tidemark event is triggered as the high (or low) out of range when the tidemark value reaches or crosses the high (or low) threshold."; container tidemark-event { uses oor-event-type; leaf event-occurred { type boolean; description "Indicates whether the tidemark-value has reached the high(or low)-oor-threshold."; } leaf event-time { type yang:date-and-time; description "A timestamp indicating when the tidemark- value reached the high(or low)-oor-threshold"; } } } grouping event-parameters-gr { container BUT-event { description "Begin Unavailable Time (BUT) event marking the start of a period when a network element or connection is unavailable."; uses event-state-info; } container EUT-event { description "End Unavailable Time (BUT) event marking the end of a period when a network element or connection was unavailable."; leaf event-occurred { type boolean; description "Indicates whether EUT event is generated."; } leaf event-time { type yang:date-and-time; description "End Unavailable Time (EUT)"; } leaf total-unavailable-time { type uint32; units "seconds"; description "Total duration of unavailability."; } } container CSES-event { description "A sequence of severely errored seconds (SES) event detected consecutively within a specified time frame."; leaf event-occurred { type boolean; description "Indicates whether CSES event is generated."; } leaf begin-time { type yang:date-and-time; description "A timestamp indicating when CSES period begins."; } leaf end-time { type yang:date-and-time; description "A timestamp indicating when CSES period ends."; } 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."; } } } /* * MAIN CONTAINER */ container pm-periodic-measurement { description "This container includes PM periodic measurements, such as count, snapshot, and tidemark, used for maintenance and QoS monitoring. These measurements are typically taken over 15-minute and 24-hour intervals and are categorized by their purpose (maintenance/QoS) and time interval, as each case involves different parameter types."; leaf measurement-interval { type uint32 { range "1..max"; } units "seconds"; description "This interval defines the periodic measurement of PM parameters. Clients can select the interval based on the capabilities provided by network elements."; } container maintenance-15min { description "Contains metric value of the PM parameters by the measurement methods for maintenance monitoring with 15 minute time interval."; list pm-parameter { key "parameter-name"; description "List PM parameters for maintenance with 15 minute time interval."; leaf parameter-name { type maintenance-parameters; description "Name of the parameters for maintenance with 15 minute time interval."; } uses count-measurement-15min-gr; uses snapshot-measurement-gr; uses tidemark-measurement-gr; } } container maintenance-24hr { description "Contains metric value of the PM parameters by the measurement methods for maintenance monitoring with 24 hour time interval."; list pm-parameter { key "parameter-name"; description "List PM parameters for maintenance with 24 hour time interval."; leaf parameter-name { type maintenance-parameters-extended; description "Name of the parameters for maintenance with 24 hour interval."; } uses count-measurement-24hr-gr; uses snapshot-measurement-gr; uses tidemark-measurement-gr; } } container qos-24hr { description "Contains metric value of the PM parameters by the measurement methods for QoS monitoring with 24 hour time interval."; list pm-parameter { key "parameter-name"; description "List PM parameters for QoS with 24 hours;"; leaf parameter-name { type qos-parameters; description "Name of the parameters for QoS with 24 hour interval."; } uses count-measurement-24hr-gr; } } } /* * NOTIFICATIONS */ notification threshold-events { container periodic-threshold-events { description " Contains threshold events of the periodic measurements including counts, snapshots, and tidemarks."; container maintenance-15min { description "Contains threshold events of the PM parameters for maintenance monitoring with 15 minute time interval."; list pm-parameter { key "parameter-name"; description "List PM parameters for maintenance with 15 min;"; leaf parameter-name { type maintenance-parameters; description "Name of the PM parameters for maintenance with 15 minute time interval."; } uses count-transient-event-gr; uses count-standing-event-gr; uses snapshot-events-gr; uses tidemark-events-gr; } } container maintenance-24hr { description "Contains threshold events of the PM parameters for maintenance monitoring with24 hour time interval."; list pm-parameter { key "parameter-name"; description "List PM parameters for maintenance with 24 hours;"; leaf parameter-name { type maintenance-parameters; description "Name of the PM parameters for maintenance with 24 hour time interval."; } uses count-transient-event-gr; uses snapshot-events-gr; uses tidemark-events-gr; } } container qos-24hr { description "Contains threshold events of the PM parameters for QoS monitoring with 24 hour time interval."; list pm-parameter { key "parameter-name"; description "List PM parameters for QoS with 24 hours time interval;"; leaf parameter-name { type qos-parameters; description "Name of the PM parameters for QoS with 24 hour time interval."; } uses count-transient-event-gr; } } } container non-periodic-threshold-events { uses event-parameters-gr; } } } ]]>

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 for the count-value and count-unit of the Severely Errored Second (SES) parameter for the maintenance with 15 minutes time interval.

Periodic Subscription Example

ses

900 encode-xml

2024-10-20T10:00:00Z

2024-10-20T16:00:00Z

]]>

Periodic Event Subscription shows an example of the NETCONF request to subscribe to receive event notifications triggered by the high-oor-event of the Severely Errored Second (SES) parameter for the maintenance with 15 minutes time interval. The snapshots are taken every 2 minutes, and the high-oor-threshold that is the threshold value of the event condition of the high out of range is set to 8 seconds.

Periodic Event Subscription Example ietf-push encode-xml 900

300

ses

120

High-OOR-event

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

Periodic Event Notification Example 2024-10-10T15:15:00Z

ses

High-OOR-event

true

2024-10-10T15:14:00Z

]]>

Non-periodic Event Subscription is a NETCONF RPC message requesting to establish a subscription for performance monitoring data for BUT events, using the IETF Push mechanism and XML encoding.

Non-periodic Event Notification Example ietf-push encode-xml

]]>

Security Considerations TBD.

IANA Considerations TBD.