A YANG Data Model of Performance Management Streaming
draft-yoon-ccamp-pm-streaming-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Bin Yeong Yoon | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Yang Validation | 26 errors, 2 warnings | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yoon-ccamp-pm-streaming-00
CCAMP Working Group B.Y. Yoon, Ed.
Internet-Draft ETRI
Intended status: Standards Track 20 October 2024
Expires: 23 April 2025
A YANG Data Model of Performance Management Streaming
draft-yoon-ccamp-pm-streaming-00
Abstract
This document provides a YANG data model of performance management
streaming in network equipment. It defines types of parameters, and
their measurements and reporting methods by periodic and event
notifications.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Yoon Expires 23 April 2025 [Page 1]
Internet-Draft VN YANG Model October 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PM Streaming . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Measurement Methods . . . . . . . . . . . . . . . . . . . . . 4
4.1. Counts . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Snapshots . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Tidemarks . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Periodic Subscriptions . . . . . . . . . . . . . . . . . . . 6
5.1. Maintenance and QoS monitoring . . . . . . . . . . . . . 6
5.2. Time intervals . . . . . . . . . . . . . . . . . . . . . 7
5.3. PM Parameters . . . . . . . . . . . . . . . . . . . . . . 8
6. Threshold Event Subscriptions . . . . . . . . . . . . . . . . 8
6.1. Periodic threshold events . . . . . . . . . . . . . . . . 8
6.2. Non-Periodic threshold events . . . . . . . . . . . . . . 9
7. YANG Data Tree . . . . . . . . . . . . . . . . . . . . . . . 9
8. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 12
9. Subscription Examples . . . . . . . . . . . . . . . . . . . . 26
9.1. Periodic Subscription . . . . . . . . . . . . . . . . . . 26
9.2. Periodic Event Subscription . . . . . . . . . . . . . . . 27
9.3. Non-periodic Event Subscription . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. 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.
Yoon Expires 23 April 2025 [Page 2]
Internet-Draft VN YANG Model October 2024
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 ([RFC9232], [RFC8639], [RFC8640], [RFC8641]) 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.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. PM Streaming
+------+ +-----+ +--------+
| OS | | NDT | ... | AI APP |
+---+--+ +--+--+ +----+---+
| | |
+---+--------+-------------+---+
| NE |
+------------------------------+
OS: Operation System
NDT: Network Digital Twins
APP: Application
Figure 1: 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.
Yoon Expires 23 April 2025 [Page 3]
Internet-Draft VN YANG Model October 2024
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.
4. 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.
Yoon Expires 23 April 2025 [Page 4]
Internet-Draft VN YANG Model October 2024
4.1. 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.
4.2. 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.
4.3. 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,
Yoon Expires 23 April 2025 [Page 5]
Internet-Draft VN YANG Model October 2024
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.
5. 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.
5.1. 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
Yoon Expires 23 April 2025 [Page 6]
Internet-Draft VN YANG Model October 2024
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.
5.2. 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.
Yoon Expires 23 April 2025 [Page 7]
Internet-Draft VN YANG Model October 2024
5.3. 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.
ES Errored Seconds
SES Severely Errored Seconds
BBE Background Block Errors
BBC Background Block Count
UAS Unavailable Seconds
SEP Severely Errored Period
PJE Pointer Justification Events
UAS Unavailable Seconds</t>
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
6. 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.
6.1. 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,
Yoon Expires 23 April 2025 [Page 8]
Internet-Draft VN YANG Model October 2024
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.
6.2. 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.
7. YANG Data Tree
The YANG data tree structure is as follows:
module: ietf-pm-streaming
+--rw pm-periodic-measurement
+--rw measurement-interval? uint32
+--rw maintenance-15min
| +--rw pm-parameter* [parameter-name]
| +--rw parameter-name maintenance-parameters
| +--rw count-measurement
| | +--ro count-value? uint32
Yoon Expires 23 April 2025 [Page 9]
Internet-Draft VN YANG Model October 2024
| | +--ro count-unit? parameter-unit
| | +--rw transient-condition-config
| | | +--rw high-oor-threshold? uint32
| | | +--rw low-oor-threshold? uint32
| | +--rw standing-condition-config
| | +--rw standing-threshold? uint32
| | +--rw standing-reset-threshold? uint32
| +--rw snapshot-measurement
| | +--rw uniform-time? uint32
| | +--ro snapshot-value? uint32
| | +--ro snapshot-unit? parameter-unit
| | +--rw high-oor-threshold? uint32
| | +--rw low-oor-threshold? uint32
| +--rw tidemark-maintenance
| +--ro high-tide-value? uint32
| +--ro high-tide-unit? parameter-unit
| +--ro low-tide-value? uint32
| +--ro low-tide-unit? parameter-unit
| +--rw high-oor-threshold? uint32
| +--rw low-oor-threshold? uint32
+--rw maintenance-24hr
| +--rw pm-parameter* [parameter-name]
| +--rw parameter-name maintenance-parameters-extended
| +--rw count-measurement
| | +--ro count-value? uint32
| | +--ro count-unit? parameter-unit
| | +--rw transient-condition-config
| | +--rw high-oor-threshold? uint32
| | +--rw low-oor-threshold? uint32
| +--rw snapshot-measurement
| | +--rw uniform-time? uint32
| | +--ro snapshot-value? uint32
| | +--ro snapshot-unit? parameter-unit
| | +--rw high-oor-threshold? uint32
| | +--rw low-oor-threshold? uint32
| +--rw tidemark-maintenance
| +--ro high-tide-value? uint32
| +--ro high-tide-unit? parameter-unit
| +--ro low-tide-value? uint32
| +--ro low-tide-unit? parameter-unit
| +--rw high-oor-threshold? uint32
| +--rw low-oor-threshold? uint32
+--rw qos-24hr
+--rw pm-parameter* [parameter-name]
+--rw parameter-name qos-parameters
+--rw count-measurement
+--ro count-value? uint32
+--ro count-unit? parameter-unit
Yoon Expires 23 April 2025 [Page 10]
Internet-Draft VN YANG Model October 2024
+--rw transient-condition-config
+--rw high-oor-threshold? uint32
+--rw low-oor-threshold? uint32
notifications:
+---n threshold-events
+--ro periodic-threshold-events
| +--ro maintenance-15min
| | +--ro pm-parameter* [parameter-name]
| | +--ro parameter-name maintenance-parameters
| | +--ro count-transient-event
| | | +--ro event-type? enumeration
| | | +--ro event-occurred? boolean
| | | +--ro event-time? yang:date-and-time
| | +--ro count-standing-event
| | | +--ro event-type? enumeration
| | | +--ro event-occurred? boolean
| | | +--ro event-time? yang:date-and-time
| | +--ro snapshot-event
| | | +--ro event-type? enumeration
| | | +--ro event-occurred? boolean
| | | +--ro event-time? yang:date-and-time
| | +--ro tidemark-event
| | +--ro event-type? enumeration
| | +--ro event-occurred? boolean
| | +--ro event-time? yang:date-and-time
| +--ro maintenance-24hr
| | +--ro pm-parameter* [parameter-name]
| | +--ro parameter-name maintenance-parameters
| | +--ro count-transient-event
| | | +--ro event-type? enumeration
| | | +--ro event-occurred? boolean
| | | +--ro event-time? yang:date-and-time
| | +--ro snapshot-event
| | | +--ro event-type? enumeration
| | | +--ro event-occurred? boolean
| | | +--ro event-time? yang:date-and-time
| | +--ro tidemark-event
| | +--ro event-type? enumeration
| | +--ro event-occurred? boolean
| | +--ro event-time? yang:date-and-time
| +--ro qos-24hr
| +--ro pm-parameter* [parameter-name]
| +--ro parameter-name qos-parameters
| +--ro count-transient-event
| +--ro event-type? enumeration
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
Yoon Expires 23 April 2025 [Page 11]
Internet-Draft VN YANG Model October 2024
+--ro non-periodic-threshold-events
+--ro BUT-event
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
+--ro EUT-event
| +--ro event-occurred? boolean
| +--ro event-time? yang:date-and-time
| +--ro total-unavailable-time? uint32
+--ro CSES-event
+--ro event-occurred? boolean
+--ro begin-time? yang:date-and-time
+--ro end-time? yang:date-and-time
+--ro duration? uint32
+--ro error-count? uint32
8. YANG Data Model
<CODE BEGINS> file "ietf-pm-streaming@2024-10-10.yang"
module ietf-pm-streaming {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-pm-streaming";
prefix pm-str;
/*
* Import YANG Type
*/
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
organization
"IETF Common Control and Measurement Plane (ccamp)
Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/ccamp/>
Editor: Bin Yeong Yoon
<mailto:byyun@etri.re.kr>";
description
"This YANG module defines a data model for performance
management streaming, based on ITU-T G.7710 for
equipment. It specifies measurement types, performance
parameters, their streaming subscriptions, and event
notifications.";
Yoon Expires 23 April 2025 [Page 12]
Internet-Draft VN YANG Model October 2024
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";
Yoon Expires 23 April 2025 [Page 13]
Internet-Draft VN YANG Model October 2024
}
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
Yoon Expires 23 April 2025 [Page 14]
Internet-Draft VN YANG Model October 2024
"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 {
Yoon Expires 23 April 2025 [Page 15]
Internet-Draft VN YANG Model October 2024
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.
Yoon Expires 23 April 2025 [Page 16]
Internet-Draft VN YANG Model October 2024
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;
}
Yoon Expires 23 April 2025 [Page 17]
Internet-Draft VN YANG Model October 2024
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;
}
Yoon Expires 23 April 2025 [Page 18]
Internet-Draft VN YANG Model October 2024
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{
Yoon Expires 23 April 2025 [Page 19]
Internet-Draft VN YANG Model October 2024
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.";
}
Yoon Expires 23 April 2025 [Page 20]
Internet-Draft VN YANG Model October 2024
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;
Yoon Expires 23 April 2025 [Page 21]
Internet-Draft VN YANG Model October 2024
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";
Yoon Expires 23 April 2025 [Page 22]
Internet-Draft VN YANG Model October 2024
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;
Yoon Expires 23 April 2025 [Page 23]
Internet-Draft VN YANG Model October 2024
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
Yoon Expires 23 April 2025 [Page 24]
Internet-Draft VN YANG Model October 2024
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
Yoon Expires 23 April 2025 [Page 25]
Internet-Draft VN YANG Model October 2024
"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;
}
}
}
<CODE ENDS>
9. 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.
9.1. Periodic Subscription
Figure 2 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.
Yoon Expires 23 April 2025 [Page 26]
Internet-Draft VN YANG Model October 2024
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push:1.0">
<filter type="subtree">
<pm-periodic-measurement
xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-streaming">
<maintenance-15min>
<pm-parameter>
<parameter-name>ses</parameter-name>
<count-measurement>
<count-value/>
<count-unit/>
</count-measurement>
</pm-parameter>
</maintenance-15min>
</pm-periodic-measurement>
</filter>
<period>900</period> <!-- Every 15 minutes -->
<encoding>encode-xml</encoding>
<start-time>2024-10-20T10:00:00Z</start-time>
<stop-time>2024-10-20T16:00:00Z</stop-time>
<!-- Optional: Limits the subscription duration -->
</establish-subscription>
</rpc>
Figure 2: Periodic Subscription Example
9.2. Periodic Event Subscription
Figure 3 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.
Yoon Expires 23 April 2025 [Page 27]
Internet-Draft VN YANG Model October 2024
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription
xmlns="urn:ietf:params:
xml:ns:yang:ietf-subscribed-notifications">
<stream>ietf-push</stream>
<encoding>encode-xml</encoding>
<periodic>
<period>900</period> <!-- 15 minutes interval -->
<dampening-period>300</dampening-period>
<!-- Avoid redundant notifications within 5 minutes -->
</periodic>
<filter type="subtree">
<pm-periodic-measurement
xmlns="urn:ietf:params:xml:ns:yang:ietf-pm-streaming">
<maintenance-15min>
<pm-parameter>
<parameter-name>ses</parameter-name>
<snapshot-measurement>
<uniform-time>120</uniform-time>
<!-- Snapshots every 2 minutes -->
<high-oor-threshold>8</high-oor-threshold>
<!-- Alert if value exceeds 8 seconds -->
<snapshot-event>
<oor-threshold-type>
<event-type>High-OOR-event</event-type>
</oor-threshold-type>
</snapshot-event>
</snapshot-measurement>
</pm-parameter>
</maintenance-15min>
</pm-periodic-measurement>
</filter>
</establish-subscription>
</rpc>
Figure 3: Periodic Event Subscription Example
Figure 4 is an example of the NETCONF notification that would be
triggered after the subscription in Figure 3.
Yoon Expires 23 April 2025 [Page 28]
Internet-Draft VN YANG Model October 2024
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2024-10-10T15:15:00Z</eventTime>
<pm-periodic-measurement xmlns="urn:ietf:params:xml:ns:yang:
ietf-pm-streaming">
<maintenance-15min>
<pm-parameter>
<parameter-name>ses</parameter-name>
<snapshot-measurement>
<snapshot-event>
<oor-threshold-type>
<event-type>High-OOR-event</event-type>
</oor-threshold-type>
<event-occurred>true</event-occurred>
<event-time>2024-10-10T15:14:00Z</event-time>
</snapshot-event>
<snapshot-value>10</snapshot-value>
<high-oor-threshold>8</high-oor-threshold>
</snapshot-measurement>
</pm-parameter>
</maintenance-15min>
</pm-periodic-measurement>
</notification>
Figure 4: Periodic Event Notification Example
9.3. Non-periodic Event Subscription
Figure 5 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.
Yoon Expires 23 April 2025 [Page 29]
Internet-Draft VN YANG Model October 2024
<rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:
ietf-subscribed-notifications">
<stream>ietf-push</stream>
<encoding>encode-xml</encoding>
<filter type="subtree">
<pm-periodic-measurement xmlns="urn:ietf:params:xml:ns:yang:
ietf-pm-streaming">
<BUT-event>
<event-occurred/>
<event-time/>
</BUT-event>
</pm-periodic-measurement>
</filter>
</establish-subscription>
</rpc>
Figure 5: Non-periodic Event Notification Example
10. Security Considerations
TBD.
11. IANA Considerations
TBD.
12. References
12.1. Normative References
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/info/rfc8639>.
[RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Dynamic Subscription to YANG Events
and Datastores over NETCONF", RFC 8640,
DOI 10.17487/RFC8640, September 2019,
<https://www.rfc-editor.org/info/rfc8640>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
Yoon Expires 23 April 2025 [Page 30]
Internet-Draft VN YANG Model October 2024
12.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
A. Wang, "Network Telemetry Framework", RFC 9232,
DOI 10.17487/RFC9232, May 2022,
<https://www.rfc-editor.org/info/rfc9232>.
Author's Address
Bin Yeong Yoon (editor)
ETRI
Email: byyun@etri.re.kr
Yoon Expires 23 April 2025 [Page 31]