Problem Statement: Information Sharing of Optical Impairments in Monitoring of Multi-Domain All-Optical Paths

Introduction To provision an optical connection (hereafter referred to as an optical path), defines an information model to address the Routing and Wavelength Assignment (RWA) problem in Wavelength Switched Optical Networks (WSONs). specifies the corresponding YANG data model. In addition, addresses optical impairments and their impact on signal quality in the context of impairment-aware RWA (IA-RWA). The Internet-Draft [I-D.ietf-ccamp-optical-impairment-topology-yang] further extends the YANG data modeling of impairment-related topology attributes. Collectively, these works facilitate path computation, provisioning, and validation while accounting for optical impairment constraints within a single administrative domain. However, for an all-optical path spanning multiple administrative domains, an information model for monitoring and analyzing impairment-induced signal degradation and failures remains an open issue. Optical impairments such as Optical Signal-to-Noise Ratio (OSNR), Generalized Signal-to-Noise Ratio (GSNR), nonlinear noise, chromatic dispersion (CD), and polarization mode dispersion (PMD) may accumulate across domain boundaries and degrade end-to-end service performance. When a receiver detects degraded performance or failure of a multi-domain optical path, it is operationally desirable to localize the domain(s) that contribute most significantly to the degradation and to enable timely corrective actions within the responsible domain(s). In a multi-domain optical path service, each participating domain may contribute to the accumulated degradation along the end-to-end path. Effective monitoring therefore requires the exchange of performance-related information at domain demarcation points, enabling quantitative assessment of each domain's contribution to signal degradation. This introduces the need for an information model that (1) supports the sharing of performance-related information among relevant domains, and (2) enables analytical methods to assist in identifying the domain(s) most likely responsible for observed degradation. Because such analytical methods depend on the set of information that can be exchanged across administrative boundaries, a clear understanding of information-sharing requirements and constraints is necessary. Accordingly, this document focuses on the problem statement associated with sharing performance-related information among domains in multi-domain WSON environments. The specification of a complete information model, including detailed data structures and analytical procedures for degradation attribution or failure responsibility determination, is outside the scope of this document.

Terminology and Notations The terminology related to WSON impairments and associated concepts used in this document is consistent with . Readers are referred to that document for definitions of impairment parameters and related terms.

Requirements Language 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.

Requirements for Collaborative Cross-Domain Performance Data Sharing

Peer Networks and Multi-Domain Optical Path

Peer Networks and a multi-domain all-optical path a+-->+b------X--->c+-->+d--X->|R Dst| | | | R|<----h+<--+g<----------f+<--+e<----|T | | | ----- | | | | ----- | -------------- ------------- -------------- ]]> Figure 1 illustrates an example of interconnected multi-domain WSONs in the data plane (D-Plane), consisting of Domains A, B, and C under different administrative control. A bidirectional end-to-end optical path is provisioned between a source transceiver in Domain A and a destination transceiver in Domain C. The path traverses domain border nodes (e.g., nodes a to d in the downstream direction and nodes e to h in the upstream direction). The provisioned optical path satisfies impairment-related constraints, including tolerance thresholds for parameters such as OSNR and GSNR. For simplicity, internal optical nodes, links, and control-plane elements are not shown in the figure. Each domain is assumed to operate its own control plane (C-Plane), potentially based on the Abstraction and Control of Traffic Engineered Networks (ACTN) architecture [RFC8453]. The C-Plane may provide monitoring and telemetry capabilities within the administrative domain.

Signal Degradation Signal degradation along a multi-domain optical path may result from accumulated optical impairments, such as additional noise introduced by optical amplifiers. Such impairments propagate along the path and may accumulate at the receiving endpoint. As illustrated in Figure 1, OSNR degradation may occur at specific locations within Domains A and B along the downstream direction. The impairment contributions from multiple domains accumulate and may result in significant end-to-end signal degradation. Furthermore, noise introduced in upstream domains may be further amplified by optical amplifiers in downstream domains, potentially increasing its impact on the final OSNR observed at the receiver . For illustration purposes, Figure 1 and this document explain degradation and failure in the downstream direction only. Similar impairment scenarios may occur in the upstream direction or in both directions.

Requirements for Collaborative Cross-Domain Performance Data Sharing At the receiving endpoint, a service failure may be declared when accumulated impairment causes the observed OSNR or GSNR to exceed the configured tolerance threshold. In some cases, analysis of the received signal may provide indications of localized loss or optical power variation along the optical path. For example, Digital Longitudinal Monitoring (DLM) techniques may assist in estimating impairment distribution along the path. An alarm notification that includes such monitoring information may be generated and delivered to the controller of the destination domain (e.g., Domain C). While DLM-based information may help identify abnormal optical power variation, it is generally insufficient to determine the detailed contribution of each administrative domain to the observed OSNR degradation. Accurate attribution may require additional impairment-related parameters, such as amplifier noise figures or other domain-specific characteristics, which are not locally available to the destination domain controller. Without such information, quantitative assessment of domain-level responsibility remains challenging. Accordingly, collaborative mechanisms for sharing performance-related information among the relevant administrative domains (e.g., Domains A through C) are necessary to support degradation analysis of multi-domain optical paths. Such information exchange is intended to assist in identifying the domain(s) that most significantly contribute to observed impairment and to facilitate appropriate operational response. These considerations motivate the need for controlled and interoperable exchange of impairment-related information across administrative boundaries.

Use Cases for Collaborative Cross-Domain Performance Data Sharing By exchanging the minimum necessary performance-related information for a degraded or failed multi-domain optical path (e.g., information obtained via monitoring, telemetry, and analysis systems), participating administrative domains can perform coordinated and quantitative analysis of impairment contributions. Such analysis may assist in identifying and localizing the domain(s) that contribute most significantly to the observed degradation. The following subsections describe representative use cases.

Rapid Restoration via Domain-Level Localization When service degradation or failure is detected, a straightforward restoration approach is to provision a new end-to-end multi-domain optical path. For example, the controller in the destination domain (e.g., Domain C) may initiate end-to-end reprovisioning across all traversed domains. Alternatively, if the affected administrative domain(s) can be identified through collaborative impairment analysis, restoration actions may be confined to the responsible domain(s). In this case, local reoptimization or reprovisioning between the relevant border nodes (e.g., within Domain B) may be sufficient, provided that wavelength continuity and impairment constraints are satisfied. Compared to full end-to-end reprovisioning, domain-local restoration may reduce operational cost and restoration time by limiting the scope of reconfiguration to the affected administrative domain.

Quantitative Evidence for SLA Violation Attribution Coordinated quantitative analysis of impairment contributions across domains may provide a common and verifiable basis for assessing service performance. Such analysis can assist stakeholders in determining whether a Service Level Agreement (SLA) violation has occurred and in identifying the administrative domain(s) primarily responsible for the degradation. By enabling objective attribution based on shared performance data, collaborative analysis may reduce ambiguity in responsibility determination during multi-domain degradation or failure events. These use cases illustrate the operational value of collaborative cross-domain performance data sharing. In particular, they highlight the need for mechanisms that support controlled information exchange among administrative domains to facilitate degradation localization and responsibility attribution in multi-domain WSON deployments.

Problem Statement for Collaborative Cross-Domain Performance Data Sharing The use cases described in Section 3 illustrate the operational value of collaborative cross-domain performance analysis. However, realizing these use cases in practice requires careful consideration of architectural and policy constraints that affect cross-domain information exchange. This section examines these constraints and defines the associated problem space. In particular, limited optical observability at domain boundaries and confidentiality restrictions on detailed intra-domain information significantly affect the scope and granularity of shareable data. The following subsections examine these constraints and their implications for collaborative cross-domain performance analysis.

Limited Optical Observability at Domain Boundaries In optical transport networks, signals are transmitted as continuous optical waveforms without protocol headers or discrete packet structures that can be inspected at intermediate nodes. As a result, intrinsic observability of end-to-end optical paths is limited, particularly at administrative domain boundaries where signals traverse border nodes transparently. At domain border nodes, monitoring devices MAY be deployed at ingress and/or egress ports to observe signal quality parameters associated with multi-domain optical paths. When such devices are deployed, consistent telemetry capabilities and data representations are desirable to enable meaningful cross-domain analysis. In the absence of standardized telemetry definitions and formats, implementations from different vendors may expose heterogeneous metrics, thereby complicating correlation and interpretation across domains. In some deployments, monitoring devices may not be installed at border nodes due to cost, operational, or architectural considerations. In such cases, impairment-related information at domain boundaries may need to be derived through estimation performed by the domain controller. Estimation typically relies on intra-domain monitoring and telemetry data and on impairment models maintained within the administrative domain. However, estimation accuracy and update frequency may be constrained by computational complexity, particularly in large-scale WSON environments. Operators may therefore balance estimation precision against processing overhead and reporting frequency. Consequently, boundary observability may be limited in terms of both measurement accuracy and temporal resolution. This limitation constitutes a fundamental constraint on the availability and reliability of cross-domain performance data.

Confidentiality-Preserving Information Sharing Accurate degradation analysis within a single-domain WSON requires detailed physical-layer, operational, and topological information. Such information typically includes per-span loss, amplifier gain and noise figure, launch and receive power levels, OSNR, CD, PMD, nonlinear impairment estimates, spectrum occupancy, filter narrowing effects, and ROADM configuration states. Real-time performance indicators, such as pre-/post-FEC BER, Q-factor, and optical power drift, are also necessary to assess signal quality evolution. Furthermore, precise topology knowledge, including fiber routes, span lengths, amplifier placement, protection status, and recent configuration changes, is essential to localize degradation within the domain. While this level of visibility is required for accurate intra-domain diagnosis, much of the information is considered confidential and cannot be disclosed across administrative boundaries. Detailed topology data may reveal internal network design, vendor selection, or infrastructure investment strategy. Precise OSNR margins, nonlinear penalty estimates, and utilization levels may expose engineering margins, residual capacity, or congestion conditions. Even certain performance trends or spectrum usage information could enable external inference of traffic load, protection mechanisms, or commercial priorities. As a result, unrestricted sharing of raw performance data is typically infeasible in multi-operator environments. Consequently, collaborative cross-domain degradation localization must operate under confidentiality constraints. Information exchange therefore relies on abstraction and aggregation mechanisms, as described in . Abstraction represents an administrative domain using simplified virtual nodes or abstract links, exposing only selected high-level attributes rather than detailed internal state. Aggregation further compresses multiple metrics into summarized health indicators or impairment classes. In the event of degradation, each domain performs internal analysis locally and exports only abstracted status indicators or alarm summaries to the relevant administrative domains. While this approach preserves confidentiality and supports scalability, it inherently reduces diagnostic granularity. Cross-domain fault localization therefore becomes a distributed inference process under partial visibility, rather than a direct measurement problem with complete information.

Implications for Solution Design The constraints described in Sections 4.1 and 4.2 have direct implications for any mechanism intended to support collaborative cross-domain performance data sharing. First, limited observability at domain boundaries implies that solutions cannot assume uniform availability of precise measurement data. Mechanisms SHOULD accommodate heterogeneous telemetry capabilities and varying levels of measurement accuracy across administrative domains. In some cases, derived or estimated information may need to be used in place of direct measurements. Second, confidentiality requirements restrict the scope and granularity of information that can be exchanged. Solutions therefore need to support abstraction and aggregation of impairment-related data, allowing domains to expose only the minimum necessary information required for cross-domain correlation. The exchanged information SHOULD avoid revealing detailed internal topology, vendor-specific characteristics, or sensitive operational parameters. Third, because degradation localization under partial visibility becomes a distributed inference problem, solution designs need to consider correlation logic that operates on abstracted indicators rather than raw physical-layer data. This may involve standardized health indicators, impairment classes, or summarized performance metrics suitable for inter-domain exchange. In summary, collaborative cross-domain performance analysis in multi-domain WSON environments must operate under constrained observability and confidentiality-preserving abstraction. These constraints define the boundaries within which interoperable and scalable information-sharing mechanisms can be developed.

Security Considerations Collaborative cross-domain performance data sharing introduces security considerations related to confidentiality, integrity, authenticity, and trust among administrative domains.

Confidentiality Impairment-related information may reveal sensitive details regarding internal topology, equipment characteristics, engineering margins, or operational status. Unauthorized disclosure of such information could expose infrastructure design choices, residual capacity, or commercial strategy. Mechanisms supporting cross-domain information exchange SHOULD ensure that only the minimum necessary abstracted information is shared. Confidentiality protection SHOULD include appropriate access control, policy enforcement, and, where applicable, encryption of inter-domain communications.

Integrity and Authenticity Incorrect or manipulated performance data may lead to improper fault localization, incorrect responsibility attribution, or unnecessary restoration actions. Therefore, exchanged information MUST be protected against unauthorized modification in transit. Inter-domain communication mechanisms SHOULD support integrity protection and mutual authentication between participating administrative domains. The receiving entity SHOULD be able to verify the origin and integrity of impairment-related reports.

Trust Model Collaborative degradation analysis relies on trust relationships between administrative domains. Because fault localization under partial visibility becomes a distributed inference process, inaccurate or incomplete information from one domain may affect overall analysis accuracy. Solution designs SHOULD clearly define trust assumptions, including: (1) The level of confidence in abstracted indicators, (2) The scope of shared data, and (3) The authority responsible for coordination and correlation. In environments involving multiple operators, contractual and policy agreements may complement technical safeguards to establish accountability and acceptable information-sharing boundaries.

Denial-of-Service Considerations Frequent telemetry exchanges or large volumes of impairment data may increase control-plane processing load. Mechanisms SHOULD consider rate limiting, aggregation, and filtering to mitigate potential resource exhaustion or signaling overload.

IANA Considerations TBD