| Internet-Draft | SLA Assurance YANG | July 2026 |
| Yu, et al. | Expires 4 January 2027 | [Page] |
This document defines a YANG module for SLA assurance management in optical transport networks. The module provides a standard way to define, detect, and report issues that may impact service and network availability. It enables consistent modeling of assurance intent, impairment detection, and risk reporting across optical transport domains. The YANG model is designed to support closed-loop operations, allowing automated monitoring, analysis, and remediation workflows to maintain high service reliability and SLA compliance¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://hyu2010.github.io/sla_assurance_optical/draft-yu-ccamp-sla-assurance-optical-yang.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-yu-ccamp-sla-assurance-optical-yang/.¶
Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (mailto:ccamp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ccamp/. Subscribe at https://www.ietf.org/mailman/listinfo/ccamp/.¶
Source for this draft and an issue tracker can be found at https://github.com/hyu2010/sla_assurance_optical.¶
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 4 January 2027.¶
Copyright (c) 2026 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.¶
Service Level Agreement (SLA) assurance management in optical transport networks concerns the continuous monitoring, analysis, and management of network conditions that may impact the performance, availability, and reliability of services. Its objective is to detect potential issues proactively, diagnose their root causes, and initiate corrective actions to prevent SLA violations. Several standards already exist in this area. SAIN [RFC9417] and [RFC9418] defines an architecture and a YANG model for network service assurance, respectively. {{!I-D.ietf-nmop-network-incident-yang] defines a YANG model for the network incident lifecycle management. It aims to provide a standard way to report, diagnose, and help resolve network incidents which may cause SLA violations.¶
However, several gaps remain in the existing standards and their associated YANG models with respect to supporting SLA assurance management in optical transport networks. First, the SAIN framework focuses on the detection and resolution of symptoms, that is, conditions indicating that a service instance or subservice is not operating in a fully healthy state. In optical transport networks, however, undesirable network conditions may exist that increase the risk of SLA violations while remaining asymptomatic. For example, multiple service paths may traverse fiber links deployed within the same trench, thereby introducing a common point of failure. Such conditions do not necessarily result in observable service degradation and, therefore, may not be identified through symptom-based monitoring mechanisms.¶
Service Level Agreement (SLA) assurance management in optical transport networks concerns the continuous monitoring, analysis, and management of network conditions that may impact the performance, availability, and reliability of services. Its objective is to detect potential issues proactively, diagnose their root causes, and initiate corrective actions to prevent SLA violations. Several standards already exist in this area. SAIN [RFC9417] and [RFC9418] defines an architecture and a YANG model for network service assurance, respectively. [I-D.ietf-nmop-network-incident-yang] defines a YANG model for the network incident lifecycle management. It aims to provide a standard way to report, diagnose, and help resolve network incidents which may cause SLA violations.¶
However, several gaps remain in the existing standards and their associated YANG models with respect to supporting SLA assurance management in optical transport networks. First, the SAIN framework focuses on the detection and resolution of symptoms, that is, conditions indicating that a service instance or subservice is not operating in a fully healthy state. In optical transport networks, however, undesirable network conditions may exist that increase the risk of SLA violations while remaining asymptomatic. For example, multiple service paths may traverse fiber links deployed within the same trench, thereby introducing a common point of failure. Such conditions do not necessarily result in observable service degradation and, therefore, may not be identified through symptom-based monitoring mechanisms.¶
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.¶
The following terms are defined in [RFC8632], [RFC9543], [I-D.ietf-nmop-terminology] and are not redefined here:¶
Event¶
Incident¶
Anomaly¶
Cause¶
Characteristic¶
SLA (Service Level Agreement)¶
SLO (Service Level Objective)¶
The following terms are defined in this document:¶
A network condition that, if not addressed in time, may lead to SLA violations of services and incidents. An issue may either be symptomatic or asymptomatic. Symptomatic issues cause visible impacts to the health of services. Asymptomatic issues, in contrast, do not impact services alone. They lead to SLA violations in conjunction with other conditions or events, such as a service reroute.¶
A class used for the classification of SLA assurance issues. Every issue belongs to a certain type. There is a limited number of the types of assurance issues in optical networks.¶
The ability to detect SLA assurance issues and initiate preemptive actions to prevent SLA violations. This ability is measured against how many different types of issues the SLA assurance system can handle.¶
The process to identify the type of an issue when it is raised. It is an SLA assurance capability.¶
An entity that is responsible for detecting, classifying, and reporting SLA assurance issues, and performing issue solutions to prevent SLA violations.¶
A pair of optical fibers traverse the same physical cable sheath (i.e., both fibers are contained within the same fiber cable).¶
A pair of optical fibers are deployed within the same trench/duct route (i.e., both fibers share the same underground pipeline or trench corridor).¶
Modern optical transport networks underpin mission-critical enterprise and carrier-grade services that require continuous availability and strict SLA compliance. This use case focuses on proactively assuring network resilience to prevent service degradation and minimize the impact of potential failures.¶
In this scenario, the optical transport network continuously monitors key performance indicators such as signal quality, optical power levels, latency, and error rates across wavelengths and optical links, as well as ODUk connections. Advanced analytics and telemetry are used to detect early signs of degradation, including fiber attenuation, amplifier drift, or emerging congestion patterns.¶
When potential risk conditions are identified, the system proactively evaluates network topology and service dependencies to assess impact on high-availability business services. If a risk of SLA violation is detected, automated or semi-automated remediation actions are triggered. These may include traffic rerouting via pre-provisioned protection paths, wavelength re-optimization, or activation of restoration mechanisms in the optical layer.¶
The objective is to ensure near-zero interrupted service delivery (surpassing the five-nines availability) for critical applications, such as financial trading, cloud connectivity, and real-time enterprise communications. By shifting from reactive fault management to proactive resilience assurance, operators can significantly reduce downtime, improve SLA adherence, and enhance overall customer experience in optical transport networks.¶
Deterministic SLA assurance in optical transport networks is a use case that aims to ensure stable and predictable service performance for latency-sensitive applications, such as AI distributed training, telemedicine, industrial automation, and immersive XR services. These applications require stringent guarantees on end-to-end latency, jitter, packet loss, bandwidth availability, and service continuity. In this use case, an optical transport service is provisioned with explicit SLA objectives that define the required deterministic performance characteristics. During service operation, the network continuously monitors both the service state and the underlying optical transport infrastructure through real-time telemetry collection. The monitored information may include end-to-end path latency, optical link quality, bandwidth utilization, wavelength continuity, congestion conditions, and other transport performance indicators relevant to SLA fulfillment.¶
As network conditions dynamically evolve, the system identifies conditions that may threaten the SLA commitments of active services before visible service degradation occurs. Such conditions may include increasing congestion, abnormal latency variation, optical signal degradation, or predicted failures affecting the active transport path. The network then evaluates alternative optical transport paths and service optimization options capable of preserving the required SLA characteristics.¶
The objective of this use case is to maintain continuous SLA compliance throughout the service lifecycle by enabling adaptive transport behavior in response to changing network conditions. This improves service reliability, minimizes performance instability and disruption, and enhances the capability of optical transport networks to support mission-critical and performance-sensitive applications.¶
Cloud–Network Synergy-Based Dynamic Bandwidth Allocation is a use case in optical transport networks that enables adaptive allocation of transport resources based on coordinated demands from cloud applications and network conditions. It targets service scenarios such as AI training workloads, distributed computing, cloud bursting, and large-scale data synchronization, where bandwidth demand is highly dynamic and time-varying.¶
In this use case, cloud applications continuously generate workload signals that reflect their resource requirements, including bandwidth demand, traffic intensity, latency sensitivity, and service priority. These requirements are communicated to the optical transport network through a cloud–network interface. At the same time, the optical transport network maintains real-time visibility of available capacity, including wavelength availability, link utilization, path constraints, and operational state across the optical infrastructure. Based on the correlation between cloud-side demand signals and network-side resource state, the system determines when and where bandwidth adjustments are required. When increased demand is detected, the network evaluates feasible optical path and wavelength allocation options that satisfy service constraints. Conversely, when demand decreases, allocated resources may be released or re-optimized to improve overall network efficiency.¶
The objective of this use case is to achieve efficient and elastic utilization of optical transport resources while ensuring that cloud application performance requirements are consistently met. By enabling coordinated decision-making between cloud workloads and optical network control, the system improves resource utilization, reduces congestion by dynamic bandwidth control of hard-pipes, and enhances the responsiveness of the transport network to dynamic application demands.¶
As shown in Table 1, SLA assurance issues in optical networks can be classified, based on their impact, into three categories: (1) those affecting service bandwidth, (2) those affecting network and service availability, and (3) those introducing traffic delay.¶
| Issue category | SLA assurance issues |
| Bandwidth | Traffic spike (sudden increase in traffic) |
| Utilization exceeds threshold defined in the SLA | |
| Network bit error rate / packet loss rate higher than allowed threshold | |
| Network and service availability | Service outage |
| Transient service interruption | |
| Failover protection failure | |
| Protection on the same route | |
| Protection on the same route | |
| Risk of traffic rerouting (during failover/reconvergence) | |
| Service performance degradation | |
| customer premises equipment (CPE) access vulnerability/hazard | |
| Delay | Operating latency exceeds allowed limit |
| Protection switching latency exceeds allowed limit |
Most SLA assurance issues, if left unaddressed, are expected to eventually result in SLA violations and incidents. However, exceptions exist. For example, an issue indicating that bandwidth utilization has exceeded an SLA-defined threshold does not necessarily imply the presence of a service health problem or any network equipment failures, particularly when the configured threshold provides a substantial operational margin. In such cases, the impact analysis included in the issue report SHOULD indicate that no immediate service impact is expected. The report MAY also recommend that the user review and adjust the threshold value to better align with the intended monitoring objectives.¶
Issues that could eventually lead to SLA violations may be either symptomatic or asymptomatic. For symptomatic issues, the associated symptoms are observable at the service layer and indicate degradation in the health of one or more services. In contrast, asymptomatic issues may not manifest as observable symptoms in any affected service. Despite this distinction, the underlying causes of both types of issues may originate from abnormal conditions in the underlay optical transport network that provides connectivity for the services. More specifically, there are three major sources of possible root causes spanning in the three layers of transport networks: (1) abnormal conditions in optical fibers, (2) error conditions in optical WDM services, and (3) bit errors in OTN payloads. SLA assurance analysis must provide accurate diagnosis of these issues and identify their underlying causes.¶
It should also be noted that certain SLA terms permit temporary service outages or transient service interruptions. This is common, for example, for best-effort services or services without protection mechanisms. In such cases, the distinction between issues and incidents may become less clear, and the two concepts may overlap. Accordingly, issue management MAY defer the handling of such cases to incident management processes.¶
Each issue is described in more detail in the following subsections.¶
Bandwidth issues are service assurance conditions that impact the capacity, throughput, or traffic-carrying efficiency of optical transport networks.¶
This issue refers to the network condition that the customer-side interface receives a large volume of burst traffic within an extremely short period of time (on the order of milliseconds). When the instantaneous rate of microburst traffic exceeds the device’s forwarding capacity, the device buffers the burst traffic for later transmission. If the device does not have sufficient buffer space, the excess traffic is dropped, resulting in congestion and packet loss.¶
This issue refers to the network condition that the customer-side service traffic exceeds the user-defined threshold, posing a risk of bandwidth overutilization. This issue can be quantified as the percentage of cumulative time during a specified period in which the service bandwidth utilization exceeds the SLA-defined threshold.¶
This issue refers to the problem that the packet loss on the customer side causes the available bandwidth to fall short of the user’s requirements.¶
Possible cause at the OTN layer: Bit errors are being generated at the electrical-layer service level, specifically within digital layer channels (such as ODUk and OTUk), indicating that the transmission at the digital wrapper/virtual container layer is experiencing signal corruption. This may result from impairments in the physical transmission path or intermediate equipment, and can lead to degraded service quality or potential data integrity issues at the service layer.¶
Possible cause at the DWDM layer: Corrected bit errors are occurring at the optical-layer (OCh) service level, indicating that the optical channel is experiencing transmission impairments that require error correction mechanisms to recover affected data. While forward error correction (FEC) is able to detect and correct these errors, their presence suggests degradation in optical signal quality, which may be caused by factors such as optical attenuation, noise, dispersion, or aging/impairment of the transmission path, and could eventually lead to uncorrectable errors if conditions worsen.¶
Possible cause at the fiber layer: The logical fiber path traversed by the service is experiencing degradation in terms of attenuation, indicating increased optical loss along the transmission route. This deterioration in signal strength may be caused by fiber aging, connector or splice losses, bending losses, or other impairments in the optical path, and can negatively impact signal quality and overall service performance.¶
Network and service availability issues are service assurance conditions that impact the ability of optical transport networks to maintain continuous and reliable service delivery.¶
The service experiences either a network-side interruption or a customer-side interruption, resulting in a loss of connectivity or service availability.¶
Possible cause at the OTN layer: The service experiences an interruption at the electrical-layer service level (ODUk/OTUk/VC), indicating a loss of continuity in the digital wrapper/virtual container transport layer. This type of failure typically results in a complete break in the ODUk/OTUk signal path, causing service disruption and potential traffic loss across the affected connection, and may be triggered by transport defects, equipment failures, or upstream/downstream signal degradation.¶
Possible cause at the DWMD layer: The service experiences an interruption at the optical (OCh/OMS/OTS) service level, indicating a loss of continuity in the optical channel transport path. This results in a complete failure of the optical (OCh/OMS/OTS) signal transmission, leading to service outage and traffic disruption. Such an interruption may be caused by severe optical impairments, fiber cuts, transmitter/receiver failures, or failures in optical switching elements along the transmission path.¶
Possible cause at the fiber medium layer: The logical fiber path traversed by the service experiences an interruption, indicating a complete loss of continuity along the virtualized or logical optical transport route. This results in a service outage due to the inability of the end-to-end path to maintain signal transmission. Such an interruption may be caused by failures in underlying physical fiber links, intermediate network elements, or logical path provisioning issues within the optical transport network.¶
Service experiences momentary interruptions. For instance, optical power fluctuations in the fiber may cause short bursts of bit errors or packet loss at higher layers, also leading to transient service interruptions.¶
Possible cause at the OTN layer: The service’s electrical-layer (ODU/OSU) working path has switched to a protection path, resulting in a brief service interruption (service hit or transient outage). This switchover indicates that a fault or degradation was detected on the original working route, triggering protection mechanisms to reroute traffic; however, the switching process introduces a short-lived traffic disruption during path convergence.¶
Possible cause at the DWDM layer: The OCh service’s optical-layer working path has switched to a protection path, resulting in a brief service interruption (transient outage or service hit). This indicates that degradation or a failure was detected on the original optical channel working route, triggering protection mechanisms to reroute traffic. During the switching and path convergence process, a short-lived disruption may occur, leading to a momentary service blip before normal transmission resumes on the protection path.¶
Possible cause at the fiber layer: Abnormal optical power fluctuations occur on the fiber path traversed by the service, causing transient instability in the received signal level. These rapid variations in optical power can lead to momentary loss of signal integrity, triggering a brief service interruption (service hit or flash outage). Such behavior is typically associated with physical-layer impairments such as connector issues, micro-bending, fiber movement, or unstable optical components along the transmission path.¶
This issue may rise when the protection route of the service experiences an interruption, resulting in protection failure. This indicates that the backup (protection) path is unavailable or has lost continuity, preventing the protection mechanism from successfully taking over in the event of a working path fault. As a result, the service is left without effective redundancy, increasing the risk of service disruption or prolonged outage if a failure occurs on the active path.¶
Possible cause at the OTN layer: The protection route at the electrical-layer (ODU/OTU/VC) level experiences an interruption, indicating a loss of continuity in the backup ODU/OUT/VC path. As a result, the protection path becomes unavailable, preventing it from serving as a valid failover for the working route in the event of a failure. This condition reduces service resilience and increases the risk of service disruption if the primary electrical-layer path degrades or fails.¶
Possible cause at the DWDM layer: The protection route at the optical-layer (OCh) experiences an interruption, meaning the backup OCh (or OCh protection path) has lost continuity or become unavailable. As a result, the optical protection mechanism cannot successfully take over traffic in the event of a failure on the working channel, thereby reducing service resilience and increasing the risk of service outage under fault conditions.¶
Possible cause at the fiber layer: The protection fiber traversed by the service—referring to the logical fiber path not currently used by the working route—experiences an interruption, indicating a loss of continuity on the backup transport path. Since this logical fiber represents the protection route, its failure renders the protection mechanism unavailable for failover, thereby reducing overall service resilience and increasing the risk of service disruption if the working path subsequently fails.¶
The working and protection paths of the service partially overlap, such as sharing common nodes or fiber links within the same Shared Risk Link Group (SRLG), which may compromise the effectiveness of the protection mechanism in case of a failure.¶
Possible cause at the OTN layer: The service’s electrical-layer (ODU/VC) working and protection paths share a common SRLG (Shared Risk Link Group), as identified through protection segment analysis. This indicates that the supposedly redundant primary and backup routes are not fully disjoint and may be simultaneously affected by a single underlying failure domain (e.g., shared fiber segment, duct, node, or equipment). As a result, the effectiveness of protection is compromised, increasing the risk of concurrent working and protection path failure and potential service outage under fault conditions. Similarly, the issue may also rise when the service’s electrical-layer working and protection paths traverse the same network element, indicating that both primary and backup routes are not node-disjoint. This introduces a shared risk at the equipment level, meaning that a single failure or maintenance event on that network element could simultaneously impact both working and protection paths.¶
Possible cause at the DWDM layer: The service’s optical-layer (OCh) working and protection paths share a common SRLG, indicating that the primary and backup routes are not fully physically diverse. This means both paths may traverse a shared risk element—such as a fiber segment, conduit, node, or optical equipment—creating a single point of correlated failure. As a result, the protection scheme’s effectiveness is reduced, increasing the risk that a single failure could simultaneously impact both working and protection OCh paths, potentially leading to service outage. The issue may also rise if the OCh working and protection paths pass through the same network element (NE). This creates a shared risk at the equipment level, where a single device failure, software fault, or maintenance activity on that network element could simultaneously impact both working and protection optical channels.¶
Possible cause at the fiber layer: Fiber same cable and fiber same trench scenarios may also lead to a “protection on the same route” issue, where the working and protection paths are no longer truly physically diverse. In such cases, although logical routing appears to provide redundancy, both fiber paths share the same underlying physical infrastructure—either within the same cable or the same trench/duct corridor. This creates a shared risk domain, meaning that a single physical failure event (such as cable cut, trench excavation damage, or environmental impact) can simultaneously affect both the working and protection fibers. As a result, the protection mechanism may fail to provide effective redundancy, significantly increasing the risk of concurrent path failure and resulting service interruption.¶
A service may be exposed to an increased risk of SLA violations during network failover or routing reconvergence events. Although protection switching and restoration mechanisms are designed to maintain service continuity, the newly selected path may exhibit different characteristics from the original path, such as increased latency, reduced available bandwidth, additional optical impairments, or a higher detour factor. These changes may cause one or more SLA performance objectives to be approached or exceeded, even if the service remains operational. Accordingly, the Issue Server SHOULD identify services that are susceptible to such rerouting events, assess the potential impact on SLA compliance, and report the associated risk before or immediately after the rerouting occurs, thereby enabling proactive operational actions to mitigate potential SLA violations.¶
Possible cause at the OTN layer: TBD¶
Possible cause at the DWDM layer: TBD¶
Possible cause at the fiber layer: TBD¶
The service experiences performance degradation, indicating a decline in end-to-end service quality compared to normal operating conditions. One example could be the degradation in Optical Channel (OCH) performance - performance degradation at the optical layer, such as post-FEC errors, may cause impairments at the service level (e.g., bit errors and packet loss).¶
Possible cause at the OTN layer: The service experiences performance degradation at the electrical-layer (ODU/VC) service level, typically manifested as error-related performance counters or alarms. This indicates that the ODU/VC transport layer is suffering from signal quality deterioration, leading to increased bit errors, errored seconds, or other degradation indicators. Such conditions are often associated with impairments in the underlying transmission path, equipment issues, or signal interference, and may degrade service quality even if the connection remains up.¶
Possible cause at the DWDM layer: Performance degradation occurs at the optical-layer (OCh) service level, typically manifested as pre-FEC bit error rate (BER) threshold violations or related performance degradations. This indicates that the optical channel is experiencing signal quality deterioration before forward error correction is applied, suggesting impairments such as optical noise, attenuation, dispersion, or aging of optical components. Although FEC may still be able to recover the transmitted data, persistent or worsening pre-FEC error conditions can reduce transmission margins and may eventually lead to uncorrectable errors or service interruption.¶
Possible cause at the fiber layer: The logical fiber path experiences performance degradation, typically indicated by fiber attenuation exceeding the defined threshold (for example, surpassing the designed End-of-Life (EOL) attenuation limit). This suggests that the optical transmission path is suffering from excessive signal loss, which may be caused by fiber aging, connector or splice degradation, bending losses, contamination, or other physical impairments. Excessive attenuation reduces optical power margins and can negatively impact signal quality, increasing the risk of transmission errors, instability, or eventual service interruption.¶
This issue refers to the problem that the protection configuration of the service access segment does not match the required availability grade, or the working and protection paths within the access segment share the same SRLG. This indicates that the access-side protection design does not provide the level of resilience required by the service SLA, either because the configured protection mechanism is insufficient or because the primary and backup access paths are not fully risk-disjoint. As a result, a single physical or logical failure event may simultaneously affect both working and protection paths, reducing service availability and increasing the risk of service interruption.¶
Possible cause at the OTN layer: The protection configuration of the access segment does not match the configured service availability grade. For example, the access segment is deployed with a single uplink architecture, while the service availability requirement is configured for dual-uplink protection. This mismatch indicates that the actual redundancy capability of the access network is insufficient to meet the intended SLA or resilience target. As a result, the service may not achieve the expected availability level, and a single uplink failure could directly lead to service interruption.¶
Possible cause at the DWDM layer: TBD¶
Possible cause at the fiber layer: There is a shared SRLG (Shared Risk Link Group) risk between the working and protection paths of the access segment, indicating that the primary and backup access routes are not fully physically or logically diverse. Both paths may rely on the same underlying risk domain—such as shared fiber infrastructure, conduit, node, or access equipment—meaning that a single failure event could simultaneously impact both working and protection connections. As a result, the effectiveness of the access protection mechanism is reduced, increasing the risk of service interruption and lowering overall service resilience.¶
Latency issues are service assurance conditions that affect the delay experienced by traffic traversing optical transport networks. These issues may be introduced by suboptimal routing, increased path length due to protection switching, congestion in optical or OTN layers, or processing delays within network elements.¶
The service’s current working latency exceeds the defined threshold, indicating that the end-to-end transmission delay is out of the acceptable range. This may be due to latency threshold violations or an excessive detour factor (route inefficiency), where traffic is forced onto a longer-than-optimal path.¶
Possible causes at the OTN layer: The service may experience a latency-related SLA issue due to changes in the routing characteristics of the working electrical-layer (ODU) service path. For example, an electrical-layer path switch may result in the newly selected working path exhibiting a higher end-to-end latency than the original route, causing the measured latency to exceed the configured threshold. In addition, the new routing may introduce a detour factor violation. The detour factor is defined as the ratio of the measured or estimated latency to the ideal latency, where the ideal latency is calculated as the shortest-path distance in the network topology multiplied by the fiber latency coefficient. If the actual routing deviates significantly from the optimal shortest path, the resulting increase in path length and transmission delay may cause the detour factor to exceed the acceptable limit. Both conditions indicate that the working ODU service path no longer satisfies the latency-related constraints specified by the SLA.¶
Possible causes at the DWDM layer: The service may experience a latency-related SLA issue due to changes in the routing characteristics of the working optical path. For example, an optical-layer path switch may result in the newly selected working path exhibiting a higher end-to-end latency than the original route, causing the measured latency to exceed the configured threshold. In addition, the newly established route may lead to a detour factor violation on the working logical fiber. The detour factor is defined as the ratio of the measured or estimated latency to the ideal latency, where the ideal latency is calculated as the shortest-path distance between the two endpoints in the network topology multiplied by the fiber latency coefficient. If the routing of the working logical fiber deviates significantly from the optimal shortest path, the resulting increase in transmission distance and delay may cause the detour factor to exceed the acceptable limit. Both conditions indicate that the current optical-layer routing no longer satisfies the latency-related constraints specified by the SLA.¶
Possible causes at the fiber layer: The service may experience a latency-related SLA issue following a fiber cut along the optical path that triggers a routing switch. As part of the failure recovery process, the rerouted working path may exhibit higher end-to-end latency than the original route, causing the measured latency to exceed the configured threshold. In addition, the rerouted working logical fiber may exhibit a detour factor violation. The detour factor is defined as the ratio of the measured or estimated latency to the ideal latency, where the ideal latency is calculated as the shortest-path distance in the network topology multiplied by the fiber latency coefficient. If the rerouted logical fiber deviates significantly from the optimal shortest path, the resulting increase in transmission distance and delay may cause the detour factor to exceed the acceptable limit. Both conditions indicate that the post-recovery routing no longer satisfies the latency-related constraints specified by the SLA.¶
The service’s current protection latency exceeds the defined threshold, indicating that the end-to-end delay on the protection path is out of the acceptable range.¶
Possible cause at the OTN layer: The service experiences a detour factor violation on the protection electrical-layer (ODU) path. The detour factor is defined as the ratio of measured or estimated latency to ideal latency, where ideal latency is calculated as the shortest network path distance between two points multiplied by the fiber latency coefficient. In this case, the protection ODU routing deviates significantly from the optimal shortest path, resulting in excessive transmission delay and causing the detour ratio to exceed the acceptable threshold.¶
Possible cause at the DWDM layer: The service experiences a detour factor violation on the protection optical-layer (OCh) path. The detour factor is defined as the ratio of measured or estimated latency to ideal latency, where the ideal latency is calculated as the shortest network path distance between two points multiplied by the fiber latency coefficient. In this case, the protection OCh routing significantly deviates from the optimal shortest path, resulting in increased transmission delay and causing the detour ratio to exceed the acceptable threshold.¶
Possible cause at the fiber layer: The service experiences a detour factor violation on the protection logical fiber path. The detour factor is defined as the ratio of measured or estimated latency to ideal latency, where the ideal latency is calculated as the shortest path distance between two points in the network topology multiplied by the fiber latency coefficient. In this case, the protection logical fiber route significantly deviates from the optimal shortest path, resulting in increased transmission delay and causing the detour ratio to exceed the acceptable threshold.¶
+-------------------------------------------------------------+
| OSS |
+-------------------------------------------------------------+
^ |
| issue report | issue query
| v
+-------------------------------------------------------------+
| Issue Server |
+-------------------------------------------------------------+
^ ^ ^ ^
| | | |
alarm/ Network performance Network Diagnosis Log
event Metrics/Telemetry using OAM Test,
OTDR
| | | |
+-------------------------------------------------------------+
| Transport Network |
+-------------------------------------------------------------+
Figure 1 illustrates the SLA assurance issue management architecture. The main component for issue management is the Issue Server, which provides capabilities for issue identification and classification, issue reporting, and issue querying. The Issue Server can be deployed on controllers as defined in [RFC8969] within each network domain and interfaces with the OSS. A typical workflow is as follows:¶
The Issue Server derives monitoring policies from the SLA, including the events, performance metrics, and alarms that need to be monitored, and initiates the corresponding monitoring activities.¶
Upon detecting an issue, the Issue Server performs issue classification, impact analysis, and resolution generation, and reports the issue to the OSS.¶
The OSS can query the Issue Server to retrieve information about identified issues, including their status, impact assessment, and recommended resolutions.¶
The OSS can invoke RPC operations exposed by the Issue Server to initiate issue resolution.¶
It should be noted that the SLA assurance capabilities supported by Issue Servers may vary across implementations and products. Therefore, an Issue Server SHOULD provide interfaces that expose its supported capabilities and enable external systems to query such capability information.¶
To support optical networks SLA assurance management, a unified data model is required for standardized representation. The model should support classification (issue-sla-type) and hierarchical layering (layer), where the layering follows the network architecture defined in [ITU-T_G.709].¶
Specifically, the optical layer includes OTS, OMS, and OCh, while the electrical layer includes OTUk and ODUk (including both higher-order and lower-order ODUk). The model should also incorporate severity labeling (severity), explicit identification of affected objects (source-objects), impacted services or objects (impacted-objects), and temporal tracking attributes such as occurrence time (occur-time) and clearance time (clear-time). In addition, each impairment instance should include a detailed description (description) and corresponding remediation or handling recommendations (suggestion), enabling consistent lifecycle tracking, analysis, and operational decision-making.¶
+-------------------------+
| Assurance Issue Handler |
+-------------------------+
^
| issue
|
+-------------------------+
| Assurance Issue Process |
+-------------------------+
^ ^
| | symptoms
| Asymptomatic |
| network +------+--+
| metrics | SAIN |
| +------+--+
| ^
| | Service
| | metrics
+-+---------------------+--+
| Network in the |
| Autonomous Domain |
SAIN [RFC9417] defines an architecture for network service assurance and specifies mechanisms for detecting symptoms associated with service degradation. For symptomatic issues, issue lifecycle management can leverage the capabilities provided by SAIN to support issue detection, analysis, and handling. However, SAIN does not address asymptomatic issues, since such issues do not manifest as observable service-level symptoms. Therefore, the management of asymptomatic issues requires issue lifecycle management functions to interact directly with the underlying physical network resources and associated monitoring mechanisms.¶
The objective of SLA assurance issue management is to prevent incidents, or reduce their occurrence, by identifying and resolving issues before they escalate into incidents. However, incidents cannot be fully prevented by issue management for several reasons. First, certain SLA terms permit temporary service outages or transient service interruptions, in which case issue handling is typically delegated to incident management. Second, an Issue Server may have limited SLA assurance capabilities, which may prevent it from detecting certain classes of issues. Therefore, issue management and incident management are complementary functions.¶
The issue lifecycle management framework can interwork with the Abstraction and Control of Traffic Engineered Networks (ACTN) framework to support end-to-end service assurance across multi-domain transport networks. In particular, ACTN provides a hierarchical control architecture that enables coordination between customer-facing service requests and underlying network resources, while issue lifecycle management provides mechanisms for detecting, classifying, and handling SLA assurance issues.¶
In an integrated deployment, the Issue Server may be instantiated within or alongside ACTN controllers in each domain, enabling correlation of service-level issues with underlying network conditions across multiple technology layers and administrative domains. ACTN’s provision of abstracted network views can be leveraged by issue management functions to localize the impact of detected issues and to facilitate cross-domain impact analysis.¶
Furthermore, issue-related information, including detected issues, their classifications, and resolution recommendations, may be exposed through ACTN interfaces to support coordinated remediation actions. Conversely, ACTN control and orchestration functions may provide topology, connectivity, and service intent information that enhances issue detection accuracy and improves root cause localization.¶
The YANG module "ietf-optical-sla-assurance" defines a data model for SLA assurance management in optical transport networks. The module provides a standard way to define, detect, and report issues that may impact service and network availability. It enables consistent modeling of assurance intent, impairment detection, and risk reporting across optical transport domains. The information reported in the SLA assurance issue includes issue identification, classification, severity, impacted objects, and remediation suggestions.¶
At the top of "ietf-optical-sla-assurance " module is the SLA Assurance container. The SLA assurance issues are represented as a list and indexed by "csn" (Customer Serial Number). Each SLA assurance issue is associated with issue metadata such as issue name, type, category, layer, severity, and timing information. In addition, the module supports relationships between issues through related-issues list and identifies source objects where the issue occurs. The module also defines impacted objects (services and tunnels) that are affected by each issue.¶
module: ietf-optical-sla-assurance
+--rw sla
+--rw issues* [csn]
+--rw csn uint64
+--rw issue-id? int64
+--rw issue-name? string
+--rw issue-sla-type? enumeration
+--rw layer? enumeration
+--rw issue-category? enumeration
+--rw occur-time? yang:date-and-time
+--rw clear-time? yang:date-and-time
+--rw description? string
+--rw suggestion? string
+--rw severity? enumeration
+--rw related-issues* [csn]
| +--rw csn uint64
+--rw source-objects* [object-id]
| +--rw object-name? string
| +--rw object-id yang:uuid
| +--rw object-type? string
+--rw issue-type? enumeration
+--rw impacted-objects* [service-name tunnel-name]
+--rw service-name yang:uuid
+--rw tunnel-name yang:uuid
¶
The issue-sla-type enumeration classifies issues into three categories based on their impact: bandwidth, availability, and delay. The layer enumeration identifies the transport layer where the issue originates, including service-layer, electrical-layer (OTN/ODU), optical-layer (DWDM/OCh), and fiber-layer. The issue-category distinguishes between fault conditions (actual failures) and risk conditions (potential failures that may lead to SLA violations).¶
The severity enumeration provides four levels: critical, major, minor, and info, allowing operators to prioritize issue resolution. The related-issues list establishes relationships between issues, enabling correlation analysis and root cause identification. The source-objects list identifies the specific network resources where the issue manifests, with each object identified by UUID and described by name and type.¶
The module also defines an RPC operation "query-history-issue-statistics-by-service" that allows retrieval of historical SLA issue statistics for specific services or tunnels within a specified time range. The RPC accepts service identifiers (UUIDs), time range parameters, and an optional SFTP URL for exporting results. The output provides comprehensive statistics including interruption count, total interruption duration, availability percentage, and a detailed interrupt history with begin/end times and durations.¶
rpcs:
+---x query-history-issue-statistics-by-service
+---w input
| +---w service-name? yang:uuid
| +---w tunnel-name? yang:uuid
| +---w begin-time? date-and-time-s
| +---w end-time? date-and-time-s
| +---w sftp-url? string
+--ro output
+--ro sla-issue-statistic* [service-name tunnel-name]
+--ro service-name yang:uuid
+--ro tunnel-name yang:uuid
+--ro service-pm
+--ro interruptions? uint64
+--ro interrupt-duration? uint64
+--ro availability? decimal64
+--ro interrupt-history* [interrupt-begin-time interrupt-end-time]
+--ro interrupt-begin-time yang:date-and-time
+--ro interrupt-end-time yang:date-and-time
+--ro interrupt-duration? uint64
¶
The model is designed to support closed-loop operations for SLA assurance in optical transport networks. It enables automated monitoring systems to detect issues, classify them according to SLA impact, and initiate appropriate remediation actions. The separation between symptomatic issues (actual service degradation) and asymptomatic issues (risk conditions that may lead to future SLA violations) allows for proactive assurance management, helping to prevent incidents before they occur.¶
The module follows YANG 1.1 specification and imports standard YANG types from ietf-yang-types. It defines custom groupings for reusable issue attributes (issue-base) and complete issue definitions (issue), promoting modularity and consistency across different implementations. The use of UUID for service and tunnel identifiers ensures global uniqueness and facilitates integration with other management systems.¶
This data model is intended to be used by network management systems, orchestration platforms, and assurance analytics engines in optical transport network environments. It provides a standardized representation of SLA assurance issues that can be exchanged between different vendor equipment and management systems, enabling multi-vendor interoperability and consistent SLA management across heterogeneous optical transport networks.¶
SLA assurance issue identification is the process of detecting and categorizing network conditions that may impact service performance, availability, or reliability. The YANG model provides a structured framework for representing identified issues with comprehensive observability attributes that enable effective monitoring, analysis, and remediation.¶
Each SLA assurance issue is uniquely identified by a Customer Serial Number (CSN), which serves as the primary key in the issues list. The CSN is a 64-bit unsigned integer that provides a globally unique identifier for each issue within a management domain. In addition to the CSN, issues may optionally include an issue-id (64-bit signed integer) for legacy compatibility or cross-system referencing, and a human-readable issue-name (string up to 1000 characters) for operator identification and documentation.¶
Observability of issues is enhanced through temporal and descriptive attributes. The occur-time attribute records when the issue was first detected or identified, using the yang:date-and-time type for precise timestamping. The clear-time attribute records when the issue was resolved or cleared, enabling calculation of issue duration and trend analysis. For issues that represent persistent conditions rather than events, the clear-time may be unset until resolution.¶
SLA assurance issue resolution encompasses the processes and capabilities for addressing identified issues, ranging from immediate remediation actions to long-term capacity planning and network optimization. The YANG model provides the data foundation for representing issues throughout their lifecycle and enables the definition of standardized resolution capabilities and procedures.¶
Issue resolution typically follows a structured workflow: detection, classification, prioritization, diagnosis, remediation, and verification. The YANG model supports this workflow through comprehensive issue representation and temporal tracking. The occur-time and clear-time attributes enable measurement of issue duration and resolution time, while the severity attribute drives prioritization. The description and suggestion attributes provide contextual information and remediation guidance for both human operators and automated systems.¶
The SLA assurance capability list represents the set of issue types that a management system can detect, analyze, and resolve. This capability is measured by the comprehensiveness of the issue catalog and the effectiveness of the resolution mechanisms. The YANG model's issue-sla-type and issue-category enumerations provide the framework for organizing this capability list, which can be extended with specific issue instances through the issue-name and description attributes.¶
<CODE BEGINS> file "ietf-optical-sla-assurance@2026-07-02.yang"
module ietf-optical-sla-assurance {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-optical-sla-assurance";
prefix hnts;
import ietf-yang-types {
prefix yang;
reference
"RFC6991: Common YANG Data Types.";
}
organization
"IETF CCAMP Working Group";
contact
"TODO";
description
"This module defines the interfaces for the SLA assurance management of optical networks";
revision 2026-07-02 {
description
"Initial revision.";
reference
"A YANG Data Model for SLA.";
}
grouping issue-base {
leaf issue-id {
type int64 {
range "0..1000000000";
}
description
"issue id";
}
leaf issue-name {
type string {
length "0..1000";
}
description
"issue name";
}
leaf issue-sla-type {
type enumeration {
enum bandwidth {
value 1;
description
"bandwidth";
}
enum availability {
value 2;
description
"availability";
}
enum delay {
value 3;
description
"delay";
}
}
description
"issue type";
}
leaf layer {
type enumeration {
enum service-layer {
value 1;
description
"service-layer";
}
enum electrical-layer {
value 2;
description
"electrical-layer";
}
enum optical-layer {
value 3;
description
"optical-layer";
}
enum fiber-layer {
value 4;
description
"fiber-layer";
}
}
description
"issue layer";
}
description
"issue base";
}
grouping issue {
leaf csn {
type uint64 {
range "0..9223372036854775807";
}
mandatory true;
description
"serial number of the issue";
}
uses issue-base;
leaf issue-category {
type enumeration {
enum fault {
value 1;
description
"fault";
}
enum risk {
value 2;
description
"risk";
}
}
description
"type of an issue";
}
leaf occur-time {
type yang:date-and-time;
description
"occur time of the issue";
}
leaf clear-time {
type yang:date-and-time;
description
"clear time of the issue";
}
leaf description {
type string {
length "0..1000";
}
description
"description of the issue";
}
leaf suggestion {
type string{
length "0..1000";
}
description
"suggestion on handling the issue";
}
leaf severity {
type enumeration {
enum critical {
value 1;
description
"critical";
}
enum major {
value 2;
description
"major";
}
enum minor {
value 3;
description
"minor";
}
enum info {
value 4;
description
"info";
}
}
description
"severity of the issue";
}
list related-issues {
key "csn";
leaf csn {
type uint64 {
range "0..9223372036854775807";
}
description
"serial number of the issue";
}
description
"related issues of the issue";
}
list source-objects {
key "object-id";
leaf object-name {
type string {
length "0..255";
}
description
"resource name of the resource where the issue occurs";
}
leaf object-id {
type yang:uuid;
description
"uuid of the resource where the issue occurs";
}
leaf object-type {
type string{
length "0..64";
}
description
"resource type of the resource where the issue occurs";
}
description
"the resource where the issue occurs";
}
description
"issue of the resource";
}
grouping service-info {
leaf service-name {
type yang:uuid;
description
"service name of the issue";
}
leaf tunnel-name {
type yang:uuid;
description
"tunnel name of the issue";
}
description
"to be added";
}
container sla {
description
"The container for the sla";
list issues {
key "csn";
uses issue;
leaf issue-type {
type enumeration {
enum current {
value 1;
description
"current issue";
}
enum history {
value 2;
description
"history issue";
}
}
description
"To be add";
}
list impacted-objects {
key "service-name tunnel-name";
uses service-info;
description
"impacted object of the issue";
}
description
"issue list";
}
}
typedef date-and-time-s {
type string {
pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(Z|[\+\-]\d{2}:\d{2})';
}
description
"time, accurate to s";
}
rpc query-history-issue-statistics-by-service {
description
"issue RPC inteface";
input {
uses service-info;
leaf begin-time {
type date-and-time-s;
description
"begin time of the issue statistics";
}
leaf end-time {
type date-and-time-s;
description
"end time of the issue statistics";
}
leaf sftp-url {
type string {
length "0..255";
}
description
"sftp url";
}
}
output {
list sla-issue-statistic {
key "service-name tunnel-name";
uses service-info;
container service-pm {
leaf interruptions {
type uint64 {
range "0..9223372036854775807";
}
description
"interruptions";
}
leaf interrupt-duration {
type uint64 {
range "0..9223372036854775807";
}
description
"interrupt duration";
}
leaf availability {
type decimal64 {
fraction-digits "2";
}
description
"availability";
}
list interrupt-history {
key "interrupt-begin-time interrupt-end-time";
leaf interrupt-begin-time {
type yang:date-and-time;
description
"interrupt begin time";
}
leaf interrupt-end-time {
type yang:date-and-time;
description
"interrupt end time";
}
leaf interrupt-duration {
type uint64 {
range "0..9223372036854775807";
}
description
"interrupt duration";
}
description
"interrupt history";
}
description
"service pm data";
}
description
"output of the history statistics";
}
}
}
}
<CODE ENDS>¶
The YANG module specified in this document defines a data model for SLA assurance management in optical transport networks. The module is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication.¶
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:¶
'/sla/issues': This list specifies the SLA assurance issue entries for optical transport networks. Unauthorized read access of this list can allow intruders to access SLA assurance information and potentially get a picture of the health and resilience status of the optical transport network. Intruders may exploit the vulnerabilities revealed in the issue data, including source-objects and impacted-objects, to lead to further negative impact on the network. Care must be taken to ensure that this list is accessed only by authorized users.¶
Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability:¶
"query-history-issue-statistics-by-service": This RPC operation retrieves historical SLA issue statistics and service performance metrics. If a malicious or buggy client performs an unexpectedly large number of this operation, the result might be an excessive use of system resources on the server side as well as network resources. Servers MUST ensure they have sufficient resources to fulfill this request; otherwise, they MUST reject the request using appropriate RPC error responses. Additionally, the sftp-url parameter provided in this operation MUST be validated against authorized destinations to prevent unauthorized data exfiltration.¶
IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group [RFC3688]: URI: urn:ietf:params:xml:ns:yang:hnts Registrant Contact: The IESG. XML: N/A, the requested URIs are XML namespaces.¶
IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group. Name: ietf-optical-sla-assurance Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-optical-sla-assurance Prefix: ietf-optical-sla-assurance Reference: RFC XXXX // RFC Ed.: replace XXXX and remove this comment¶
The authors would like to thank Yanlei Zheng, Italo Busi for their valuable comments and great input to this work.¶