]> ETRI

byyun@etri.re.kr

woori-net

young@woori-net.com

Routing CCAMP Working Group performance management streaming transport YANG This document describes how the generic collection measurement YANG data model and its interval-capability companion model are applied to common transport equipment. It is informational. It defines a small YANG module of transport performance parameters, organizes those parameters into maintenance and QoS profiles, and gives end-to-end examples that show capability discovery followed by YANG-Push subscription, notification, and threshold reporting for a transport profile. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Performance Management (PM) data generated by a transport Network Element (NE) is processed into summarized statistics and delivered to external clients. The continuous, push-based delivery of that data is referred to in this document as PM streaming. Two companion documents define the generic models used here. The collection measurement data model defines the performance parameters structure, the sampling and collection interval hierarchy, the three ITU-T G.7710 collection types (counts, snapshot, and tidemarks), and the threshold-event notification. The interval-capability model lets a server advertise which intervals it supports. Both models are generic and neutral to the transport technology. This document is informational. It describes how those generic models are applied to common transport equipment, defines a small YANG module listing the transport performance parameters, organizes the parameters into transport profiles, and gives end-to-end examples of capability discovery, subscription, notification, and threshold reporting. This document does not define any new subscription or notification mechanism; the collected data and events are carried using the YANG-Push framework .

Terminology The term "client" refers to any consumer of the PM streaming interface of a transport NE, such as an operations system (OS), a Physical Network Controller (PNC), a network digital twin (NDT), or an AI-driven application. The term "transport" is used in the sense of and covers technologies such as OTN, MPLS-TP, and transport Ethernet. 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.

Relationship to the Collection Measurement Documents This document is the transport-equipment member of a three-document set. It continues the work formerly published as draft-yoon-ccamp-pm-streaming-05: the generic, transport-neutral YANG modules that earlier versions defined have been extracted into two companion documents so that they can be reused independently, and this document (continued as draft-yoon-ccamp-pm-streaming-06) now imports them instead of defining them. The resulting structure is shown in .

| collection-measure | | interval-capabilities | +-----------------------------+ +---------------------------------+ ^ ^ | | imports (1) and (2) | +----------------------+----------------------+ | +---------------------------------------------+ | (3) ietf-pm-parameters (THIS DOCUMENT) | | draft-yoon-ccamp-pm-streaming-06 | | (CCAMP, Informational; formerly -05) | +---------------------------------------------+ ]]>

The three documents play distinct, layered roles: (1) The collection measurement model (module ietf-pm-collection) is the generic, transport-neutral core: the performance parameter structure, the sampling and collection interval hierarchy, the three ITU-T G.7710 collection types (counts, snapshot, and tidemarks), and the threshold-event notification. (2) The interval-capability model (module ietf-pm-interval-capabilities) imports the profile-names type from (1) and augments the "ietf-system-capabilities" module of , so that a server can advertise which sampling and collection intervals it supports at the standard capability discovery anchor. (3) This document (module ietf-pm-parameters) imports both (1) and (2), defines the transport-specific PM parameters and profiles (see ), and shows how the imported models are streamed on common transport equipment. This document imports the YANG modules of (1) and (2) and does not modify them; module (2) imports the profile-names type from module (1) and augments the "ietf-system-capabilities" module of . The normative measurement and capability semantics remain in and ; this document adds only the transport-specific parameter module (see ) and the applicability guidance.

Placement in the Transport Network Element The generic models are implemented within the Equipment Management Function (EMF) of a transport NE, as defined in ITU-T G.7710 Section 6.2. The collection measurement model provides the data structures, the interval-capability model advertises the supported intervals, and the transport parameter module defined in this document (see ) lists the transport parameters that the profiles refer to. The data is exposed at the NE management interface and consumed by remote clients, as illustrated in .

Transport Common PM Parameters and Profiles Metric values of PM parameters are measured for maintenance and QoS monitoring over transport networks. Quality of Service (QoS) parameters assess the network's long-term ability to deliver agreed-upon service quality. They 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. Maintenance parameters focus on short-term monitoring and detailed analysis for operational reliability. Over intervals such as 15 minutes or 24 hours, they enable 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 approach helps operators precisely pinpoint faults, troubleshoot intermittent issues, and perform preventive maintenance effectively. Key PM parameters for circuit-oriented transport networks such as OTN are listed below. Additional parameters may be needed for packet networks. ES -- Errored Seconds SES -- Severely Errored Seconds BBE -- Background Block Errors BBC -- Background Block Count UAS -- Unavailable Seconds SEP -- Severely Errored Period PJE -- Pointer Justification Events According to collection types, purposes, and time intervals, different parameters are used. The following three transport profiles, named using the profile-naming format of the collection measurement model , provide comprehensive coverage for maintenance and QoS monitoring across different temporal resolutions. The "transport" network token indicates that a profile applies across multiple transport technologies (for example OTN, MPLS-TP, and transport Ethernet).

itu-transport-maintenance-15min Profile The "itu-transport-maintenance-15min" profile is designed for short-term operational monitoring and rapid fault detection. It uses all three collection types (counts, snapshot, and tidemarks) over 15-minute intervals. The profile includes core maintenance parameters: ES, SES, BBE, BBC, and UAS. The 15-minute interval enables operators to quickly detect and respond to performance degradation, making it ideal for proactive maintenance and immediate troubleshooting. The combination of counts (for cumulative event tracking), snapshot (for instantaneous state capture), and tidemarks (for extreme value monitoring) provides a comprehensive view of network behaviour within each measurement period. This profile is particularly valuable for network operations centres (NOCs) requiring real-time visibility into transport network health and for automated systems that need to trigger immediate responses to performance anomalies.

itu-transport-maintenance-24hr Profile The "itu-transport-maintenance-24hr" profile extends maintenance monitoring to longer-term analysis and trend identification. Like the 15-minute profile, it employs all three collection types (counts, snapshot, and tidemarks) but over 24-hour intervals. The parameter set includes ES, SES, BBE, BBC, UAS, and additionally PJE. The 24-hour interval allows for comprehensive daily performance analysis, enabling operators to identify patterns, trends, and recurring issues not apparent in shorter intervals. The inclusion of PJE provides additional insight into synchronisation-related performance issues that are more relevant over longer observation periods. This profile supports strategic maintenance planning, capacity management, and historical performance analysis. It complements the 15-minute profile by providing the broader context needed for long-term network optimisation and preventive maintenance strategies.

itu-transport-qos-24hr Profile The "itu-transport-qos-24hr" profile is designed for QoS monitoring and SLA compliance verification. Unlike the maintenance profiles, it focuses exclusively on the counts collection type over 24-hour intervals, emphasising sustained performance assessment rather than detailed operational monitoring. The parameter set includes ES, SES, BBE, BBC, SEP, and UAS. The exclusive use of counts reflects its focus on cumulative performance over extended periods, which is essential for SLA compliance and service quality reporting. The 24-hour interval aligns with typical SLA measurement periods and provides the statistical basis for service quality assessments. The inclusion of SEP is particularly relevant for QoS monitoring as it represents sustained periods of degraded performance that directly impact service quality commitments.

Profile Relationships and Operational Integration These three profiles work together to provide a comprehensive performance monitoring framework. The "itu-transport-maintenance-15min" profile serves as the primary operational tool for immediate network management, while the "itu-transport-maintenance-24hr" profile provides the analytical foundation for strategic planning and trend analysis. The "itu-transport-qos-24hr" profile ensures that service quality commitments are met and provides the data necessary for SLA reporting and customer assurance. The hierarchical relationship between these profiles enables operators to correlate short-term operational events with long-term performance trends and service quality metrics. For example, a spike in ES detected by the 15-minute maintenance profile can be correlated with daily trends from the 24-hour maintenance profile and assessed against SLA thresholds defined in the QoS profile. This integrated approach supports both reactive troubleshooting and proactive network optimisation while ensuring compliance with service quality commitments.

Transport Parameter Module The following module lists the transport performance parameters as identities and provides the maintenance and QoS parameter containers used by the profiles above. The tree diagram uses the notation defined in .

Editor: Bin Yeong Yoon "; description "This YANG module defines performance management parameters for common transport equipment, based on ITU-T G.7710. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; revision 2026-06-03 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for Performance Monitoring Streaming on Common Transport Equipment"; } identity performance-parameter { description "Base identity for performance monitoring parameters."; } identity es { base performance-parameter; description "Errored Second."; } identity ses { base performance-parameter; description "Severely Errored Second."; } identity bbe { base performance-parameter; description "Background Block Error."; } identity bbc { base performance-parameter; description "Background Block Count."; } identity uas { base performance-parameter; description "Unavailable Second."; } identity pje { base performance-parameter; description "Pointer Justification Event."; } identity sep { base performance-parameter; description "Severely Errored Period."; } container maintenance-parameters-15min { config false; description "Transport maintenance parameters for the 15-minute monitoring interval."; leaf es { type uint32; units "seconds"; description "Errored Second."; } leaf ses { type uint32; units "seconds"; description "Severely Errored Second."; } leaf bbe { type uint32; units "errors"; description "Background Block Error."; } leaf bbc { type uint32; units "blocks"; description "Background Block Count."; } leaf uas { type uint32; units "seconds"; description "Unavailable Second."; } } container maintenance-parameters-24hr { config false; description "Transport maintenance parameters for the 24-hour monitoring interval."; leaf es { type uint32; units "seconds"; description "Errored Second."; } leaf ses { type uint32; units "seconds"; description "Severely Errored Second."; } leaf bbe { type uint32; units "errors"; description "Background Block Error."; } leaf bbc { type uint32; units "blocks"; description "Background Block Count."; } leaf uas { type uint32; units "seconds"; description "Unavailable Second."; } leaf pje { type uint32; units "events"; description "Pointer Justification Event."; } } container qos-parameters-24hr { config false; description "Transport QoS parameters for the 24-hour monitoring interval."; leaf es { type uint32; units "seconds"; description "Errored Second."; } leaf ses { type uint32; units "seconds"; description "Severely Errored Second."; } leaf bbe { type uint32; units "errors"; description "Background Block Error."; } leaf bbc { type uint32; units "blocks"; description "Background Block Count."; } leaf uas { type uint32; units "seconds"; description "Unavailable Second."; } leaf sep { type uint32; units "periods"; description "Severely Errored Period."; } } } ]]>

Use Cases: Streaming a Transport Profile This section shows the end-to-end flow for a transport profile, from capability discovery to subscription, notification, and threshold reporting. The examples use the SES parameter of the "itu-transport-maintenance-15min" profile.

Step 1: Discover Supported Intervals The client first reads the interval capabilities for the parameter, to learn which sampling and collection intervals the transport NE supports. These capabilities are advertised by augmenting the "ietf-system-capabilities" container of , so the client retrieves them under "system-capabilities", the same anchor used for subscription and notification capabilities.

itu-transport-maintenance-15min ses 1s 1 1 second 1 collection-range 5 1440 minute 15 5 ]]>

The response shows that the NE supports 1-second sampling and a collection interval range of 5 to 1440 minutes with 5-minute granularity, defaulting to 15 minutes. The client therefore selects a 1-second sampling interval and a 15-minute collection interval, which the NE supports.

Step 2: Subscribe to Periodic Measurement Using the supported intervals, the client establishes a YANG-Push subscription to the counts measurement value, with the period set to 900 seconds so that a notification is sent at the end of each 15-minute interval.

YANG-PUSH encode-xml operational /pm-coll:pm-periodic-collection/ parameter-profile[name='itu-transport-maintenance-15min']/ pm-parameter[name='ses']/ sampling-interval[id='1s']/ collection-interval[id='15min']/ collection-types/counts/collection-value 900 2026-07-01T00:00:00Z ]]>

Step 3: Receive Periodic Notification At the end of each interval the NE sends a notification. The measured value of 5 is the total severely errored seconds in the period.

2026-07-01T00:15:00Z itu-transport-maintenance-15min ses 1s 1 second 15min 15 minute 5 ]]>

Step 4: Threshold Reporting The client can also subscribe to threshold events. When the counts value crosses the configured transient threshold during the interval, a Threshold Report is delivered using the "pm-threshold-events" notification of the collection measurement model. No transport-specific event mechanism is required.

YANG-PUSH encode-xml operational ]]>

2026-07-01T00:09:00Z itu-transport-maintenance-15min ses 1s 15min transient true 2026-07-01T00:09:00Z ]]>

Streaming Considerations for Transport Equipment On transport equipment the following points apply. Collection intervals should align with the NE clock source so that interval boundaries are consistent across the network and snapshots taken at a uniform time can be correlated across NEs. A transport NE may serve many parameters across many monitored objects (links, tunnels, equipment sensors), so operators should consider the load of large numbers of concurrent subscriptions and choose profiles and intervals accordingly. Threshold events, both periodic and the non-periodic BUT, EUT, and CSES events, are carried in the notification defined by the collection measurement model.

Security Considerations This document is informational. It defines one YANG module of transport parameters; all of its nodes are read-only ("config false") and are designed to be accessed via NETCONF or RESTCONF over a secure transport such as SSH, with access restricted using the Network Configuration Access Control Model (NACM) . The security considerations of the underlying models and of the YANG-Push framework apply. The exposed performance and capability data can reveal information about the transport network; operators may wish to restrict access accordingly.

IANA Considerations This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry":

This document requests IANA to register the following YANG module in the "YANG Module Names" registry :

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. ETRI ETRI ITU-T In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This document defines two YANG modules, "ietf-system-capabilities" and "ietf-notification-capabilities". The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG-related system capabilities for servers. The module can be used to report capability information from the server at runtime or at implementation time by making use of the YANG instance data file format. The module "ietf-notification-capabilities" augments "ietf-system-capabilities" to specify capabilities related to "Subscription to YANG Notifications for Datastore Updates" (RFC 8641).

Acknowledgments This document is derived from draft-yoon-ccamp-pm-streaming, whose content it carries forward as the transport-equipment instantiation of the generic collection measurement models.