Open Networking in Optical Infrastructure: Where SONiC Fits and What It Takes to Make It Work

For decades, optical networking was the last stronghold of the vertically integrated, proprietary model. A single vendor typically supplied the transponders, the line system, the amplifiers, and the management stack as a tightly coupled platform. Operators bore the cost through rigid technology roadmaps, hardware-dependent software lifecycles, and limited operational flexibility.

That model is under serious pressure. The growth of AI infrastructure and large-scale cloud networks is driving interest in disaggregated optical networking and more flexible supply-chain models. At the same time, initiatives such as TIP Open Optical & Packet Transport (OOPT) and emerging OCP Optical Circuit Switching (OCS) efforts are helping move open networking principles beyond Ethernet switching and deeper into the optical transport layer.

The question is no longer whether open networking will reach optical infrastructure, but how SONiC can evolve to support real-world transport infrastructure and next-generation networking architectures.

Where SONiC Fits Today

SONiC emerged from Microsoft Azure as an open-source NOS built for cloud-scale environments. It runs on a Debian Linux base, with every network function isolated in a Docker container and coordinated through a centralized Redis-based state model.

At the core of the architecture, SONiC translates high-level network state into vendor-specific hardware programming through components such as Orchagent, syncd, and the Switch Abstraction Interface (SAI). This abstraction layer enables SONiC to operate across different switching ASICs without major changes to the higher-level software stack.

SONiC is a strong foundation – but not a ready-made optical solution. Its native abstractions were designed for packet networking and do not directly model optical transport concepts or telemetry flows. Extending SONiC into the optical layer requires additional integration layers and operational frameworks beyond what conventional Ethernet switching deployments demand.

Expanding SONiC into Optical Domains

While SONiC was originally designed for Ethernet switching in cloud-scale environments, interest in extending it into optical infrastructure is growing rapidly. Emerging optical switching architectures, access networks, and optical transport systems each introduce distinct operational models and hardware abstractions beyond traditional packet networking.

The following sections examine where SONiC fits across these optical domains today and what additional engineering is required to make such deployments production-ready.

SONiC in OCS: Optical Circuit Switching

Optical Circuit Switching (OCS) is increasingly relevant in next-generation AI and high-performance computing environments. Unlike traditional packet switches, which must perform OEO (Optical-Electrical-Optical) conversion at every hop to read headers and make forwarding decisions, an OCS switch directs light signals at the physical layer using MEMS (Micro-Electro-Mechanical Systems) mirror arrays – no electronic processing of payload data occurs at the switch fabric. This enables optical connectivity without traversing a conventional packet-switching pipeline.

OCS is particularly attractive for large-scale AI and GPU cluster networks, where traffic patterns are dominated by predictable, high-bandwidth collective communication workloads such as AllReduce and AllGather. In these environments, dynamically reconfigurable optical circuits can improve bandwidth efficiency, reduce power consumption, and lower network latency compared to scaling packet-only fabrics.

Unlike conventional packet-switching platforms, SONiC in OCS environments primarily acts as a centralized orchestration and control layer rather than a packet-forwarding plane. Its role is to manage circuit topology, provisioning state, and integration with external optical switching hardware. This requires new abstractions for circuit management and orchestration workflows beyond SONiC’s traditional Ethernet-centric operating model.

The SONiC community has already begun exploring this direction through proposed OCS High Level Design (HLD) extensions introducing circuit-oriented orchestration models within SONiC. These efforts aim to extend SONiC orchestration toward optical circuit provisioning and operational management while integrating with vendor-specific OCS hardware APIs.

What this domain requires from SONiC: optical circuit abstractions, orchestration support for circuit provisioning workflows, integration with OCS hardware APIs, and operational visibility into circuit topology and status.

As the most architecturally novel of the three optical domains covered here, SONiC in OCS environments operates primarily as a circuit orchestration and control platform, requiring substantial engineering work around hardware abstraction, orchestration workflows, telemetry integration, and platform validation across different optical switching implementations. For organizations exploring this space, PLVision’s SONiC-based Custom Product Development covers the full scope from control-plane model definition through hardware API integration and platform validation.

SONiC in OLT: Access Networks

The most accessible entry point for SONiC in telecom optical infrastructure is the access layer. Traditional Optical Line Terminals (OLTs) are typically deployed as proprietary chassis-based systems with tightly integrated hardware and software stacks delivering fiber-to-the-home (FTTH) over GPON or XGS-PON. They are often expensive, space-consuming, and operationally vendor-dependent.

The disaggregated alternative uses hot-pluggable OLT SFP modules – small form-factor transceivers containing integrated PON functionality – inserted into a standard white-box switch running SONiC. SONiC does not need to become an OLT system. It needs to support OLT transceivers.

A substantial portion of the PON functionality is implemented inside the SFP module itself. GPON and XGS-PON operational logic, including subscriber management and optical access control, can remain within the module firmware or an external access-management stack, while SONiC provides system integration and network connectivity.

GPON and XGS-PON introduce different traffic profiles and deployment characteristics for the SONiC-based access network platform. Typical deployments commonly use split ratios such as 1:32 or 1:64, depending on bandwidth targets and service models.

A single SONiC switch with OLT SFP modules can support hundreds of subscriber endpoints while significantly reducing footprint and infrastructure complexity compared to traditional chassis-based OLT platforms. An OpenWiFi-compatible controller or equivalent northbound management system can provide unified management of wired and wireless access services over the same optical infrastructure.

What SONiC requires in this use case: verified support for OLT SFP module discovery and initialization, support for PON-specific operational telemetry, and platform validation ensuring compatibility between the switch transceiver management stack and vendor-specific OLT module behaviors and management interfaces.

SONiC in OTN: Transport Networks

In the optical transport layer – DWDM backbone, metro core, and data center interconnect (DCI) – the architectural extension required is substantially deeper. Here, SONiC operates as a control and integration layer that bridges the packet domain (Ethernet/IP) and the optical transport domain (OTN/DWDM).Unlike the access-layer OLT deployments, transport networking requires SONiC to interact directly with optical transport hardware, coherent DSPs, and optical operational telemetry.

The SONiC-OTN project introduces specialized containers alongside the existing SONiC stack: OTSS (Optical Transport Switch State, the optical counterpart to swss) and syncd-ot (the optical counterpart to syncd), which provide orchestration and hardware abstraction for optical transport platforms.

The underlying abstraction layer for this domain is OTAI – the Optical Transport Abstraction Interface – conceptually similar to SAI in Ethernet switching. OTAI provides a vendor-neutral interface for managing optical transport platforms and coherent optical components across different suppliers.

A key use case is coherent pluggable optics such as 400ZR and OpenZR+ modules, which integrate coherent DWDM transport directly into routers or white-box switches. Supporting these deployments requires extensions to SONiC transceiver management and optical control workflows.

Transport deployments also require significantly richer operational telemetry and performance monitoring than traditional Ethernet switching environments. SONiC-OTN primarily addresses the control and management plane, while low-level optical transport and signal-processing functions remain the responsibilities of dedicated optical hardware and DSPs. SONiC’s role is to provide orchestration, monitoring, and operational integration, with optical telemetry and link-quality metrics typically surfaced through gNMI streaming and OpenConfig-based operational models.

For teams evaluating SONiC-OTN before committing to hardware, the project provides an ot-vs (OT Virtual Switch) target that enables software-based testing and validation in GNS3. Extending SONiC into optical transport ultimately requires substantially deeper integration work than conventional Ethernet switching deployments. PLVision’s exploration of SONiC for optical transport networks covers the architectural gaps and integration considerations in detail.

What this domain requires from SONiC: OTAI-based abstraction for optical transport hardware, extensions to transceiver management for coherent pluggables, and support for optical telemetry via gNMI using OpenConfig YANG models.

Extending SONiC into optical transport requires substantially deeper integration across hardware abstraction, operational telemetry, and optical control workflows than conventional Ethernet switching deployments. For pre-hardware evaluation, the ot-vs virtual switch build target enables architecture exploration and workflow validation in GNS3. PLVision’s SAI/DASH Launchpad methodology applies directly to OTAI-level work, bringing the same systematic coverage of attribute correctness and reusable test assets to optical hardware platforms.

Conclusion

SONiC’s expansion into optical infrastructure unfolds across three distinct engineering trajectories, each with its own maturity level, integration requirements, and production readiness horizon.

In access networking, the OLT use case is the most tractable. PON functionality remains largely inside the module; SONiC handles platform and network integration. The gap between a deployable SONiC switch and a production-ready optical access platform is narrower here than anywhere else in the optical stack.

In transport networking, the SONiC-OTN project has established much of the required architectural foundation such as OTSS, syncd-ot, and OTAI bring the same abstraction discipline that SAI brought to Ethernet switching. Coherent pluggables (400ZR, OpenZR+) are a major near-term driver, enabling DWDM transport directly from routers and white-box switches through extended transceiver management and OpenConfig-based operational telemetry.

In optical circuit switching, SONiC operates as an orchestration layer managing circuit topology, provisioning state, and hardware integration with MEMS-based optical fabrics, doing the actual switching at the physical layer. The primary driver is large-scale AI and GPU cluster networking, where predictable high-bandwidth workloads make dynamically reconfigurable optical circuits increasingly attractive. However, OCS support remains early-stage, and the largest production in integration gap among the three domains.

The common thread across all three is the principle that made SONiC viable in data center switching: vendor-neutral abstraction layers, containerized modularity, and open interfaces that decouple software evolution from hardware refresh cycles. Optical infrastructure introduces additional complexity in hardware integration, operational telemetry, and control-plane design, but SONiC increasingly provides a credible open foundation for building next-generation optical networking platforms.

PLVision works across the full SONiC and optical engineering stack – from SAI bring-up and validation to production-hardened SONiC distributions with lifecycle support. If your organization is evaluating SONiC for optical infrastructure, contact our engineering team to discuss your architecture and where the real engineering work lies.