Hands-On Exploration of SONiC in Optical Transport Networks

SONiC: Universal Platform for Open Networking

The evolution of networking technology has driven the need for more flexible, scalable, and efficient network solutions. One such innovation is the Software for Open Networking in the Cloud (SONiC), a leading open-source network operating system (NOS). Initially developed by Microsoft and contributed to the Linux Foundation, SONiC is widely adopted in cloud environment and data centers (DC).

The popularity of SONiC is growing daily due to the following advantages it offers end-users:

• Community-Driven Development: SONiC’s open-source community continuously develops and improves the operating system, adding more functionality, network protocols, and features. Within this community, you’ll find solutions for a wide range of use cases.
• Vendor Neutrality: By breaking the vendor lock-in common in traditional network operating systems, SONiC enables organizations to mix and match hardware without compromising functionality.
• Scalability and Flexibility in Data Centers: SONiC’s modular design excels in large-scale cloud environments, simplifying network configuration and automation processes.

The Community SONiC NOS has already been extended for multiple use-cases beyond a simple leaf-spine scenario:

• External PHY – a connector between MAC (SerDes) and a physical medium, such as optical fiber or copper transceivers – extends router’s flexibility and functionality with different features like gearbox, re-timer, MACSEC, multi gigabit ethernet PHY transceivers, etc.
• Disaggregated API for SONiC Hosts (DASH), based on generic SONiC architecture principles, enables the deployment of network functions (e.g., firewalls, load balancers) directly at the virtual machine (VM) or container level, bringing the benefits of disaggregation to virtualized workloads.
• SONiC for multi-ASIC and chassis devices. These are SONiC extensions for aggregation and core routers with multiple ASICs (Application-Specific Integrated Circuits).

While mainly focused on DC scenarios, SONiC provides a mature infrastructure and basic feature set that extends far beyond the DC environment. Often, enabling SONiC for a specific use-case involves fine-tuning (hardening) existing features, introducing new features, or performing resource optimization to meet strict hardware requirements.

For example, leveraging our extensive networking experience and deep understanding of SONiC, PLVision developed our own product – SONiC Lite, an optimized SONiC version tailored for campus and edge deployments.

In general, choosing the right SONiC version for a specific network infrastructure can be quite challenging. The article “Choosing the Right SONiC Version for Your Network Infrastructure” can guide you through selecting the right version of SONiC for your specific needs.

SONiC for Optical Transport Networks

The use of SONiC technologies in Optical Transport Networks (OTN) holds significant promise, especially as the telecom industry increasingly embraces open and disaggregated networking models.

Modular OTN equipment with standardized northbound interfaces and data models are widely used in data center interconnect (DCI). However, network operating systems on these OTN devices remain proprietary and vary by vendors, creating challenges with release cycles and equipment maintenance.

To address this, the SONiC community has initiated the SONiC-OTN project, aiming to extend SONiC’s capabilities for optical transport networks. This would enable SONiC deployment across both packet and optical networks, creating an end-to-end solution.

A dedicated SONiC Working Group for Optical Transport Network (sonic-otn-wg) has been formed to drive SONiC changes that support optical transport equipment, including:

• Optical transponders/muxponders.
• Optical line equipment (e.g., optical amplifiers, wavelength selective switches).
• Optical DWDM/Grey pluggable modules for switching/routing equipment.

While packet-optical devices with combined packet and optical functionality are also on the roadmap, the initial focus for the upcoming SONiC-OTN release seems to be on OTN functionality.

Development currently takes place in a separate GitHub project. The roadmap suggests the initial SONiC-OTN changes will be merged into the SONiC 202411 codebase. However, why wait for the final release? You can get your hands dirty with this exciting new variation of SONiC right now!

SONiC-OTN Architecture

SONiC is composed of several subsystems that interact through a Redis database engine. These subsystems are organized as microservices operating within Docker containers. To maintain compatibility with diverse hardware platforms that may utilize different ASICs from multiple vendors, a generic Switch Abstraction Interface (SAI) is used. This approach decouples SONiC from specific hardware details, making it portable across various switching hardware without the need for modifications to SONiC itself:

Figure 1. SONiC Components

SONiC-OTN leverages the existing SONiC architecture and features to minimize disruptions to the existing SONiC design. At the same time, it introduces enhancements and new features to meet the specific requirements of OTN products.

A typical OTN device comprises control units that run the network operation system. The device features multiple slots for plug-in optical linecards. These linecards provide various optical transmission functionalities, including:

• Transponders and Transceivers: Convert electrical signals from network equipment into optical signals.
• Multiplexer/Demultiplexer: Combines/separates optical signal onto/from optical fiber.
• Optical Line Protection Switch (OLPS): Automatically switches traffic from a primary optical path to a secondary when a fault is detected.

One of the key changes introduced by SONiC for OTN is the disabling of the SWSS (Switch State Service) and Syncd containers. This was done to prevent the OTN functionality changes from impacting those containers. In their place, the Optical Transport Switch State (OTSS) and Syncd-OT containers were introduced. These containers work together to manage linecards.

Figure 2. SONiC-OTN Components

A notable aspect of the SONiC for OTN architecture is its ability to support pluggable devices. The network operating system automatically identifies and recognizes devices as they are inserted into specific slots.

The OTSS service includes three main applications:

• Linecardmgrd: Loads OTN linecard configurations from the Redis Config DB to APPL DB when the linecard is provisioned and plugged in the slot.
• Configsyncd: Loads OTN linecard OTAI object configurations from the Redis Config DB to APPL DB.
• Orchagent: Manages the OTN linecard and OTAI objects. It creates and initializes the linecard OTAI object instance, followed by the other OTAI object instances within the linecard.

The Syncd-OT mechanism enables synchronization between the optical transport network state and the actual optical transport components and hardware. It handles tasks such as initialization, configuration, performance monitoring (PM) data collection, and alarm managing for the optical components

Additionally, instead of the generic SAI used for ASICs, SONiC for OTN introduces Optical Transport Abstraction Interfaces (OTAI), which provide a unified and vendor-neutral abstraction layer for different optical components.

Figure 3. SONiC-OTN Linecards Configuration

Furthermore, SONiC for OTN enhances several SONiC containers, including gNMI (gRPC Network Management Interface), the management framework, PMON (Platform Monitor), and CLI (Command-Line Interface), to support optical network devices. It also introduces optical transport platforms and devices into the sonic-buildimage repository.

Let’s explore the SONiC for OTN architecture and functionality in more detail by running SONiC-OT virtual image in the GNS3 environment.

Getting Started with SONiC-OTN

Building SONiC-OT-VS Image

To get started using SONiC-OTN as a GNS3 appliance, you have two options: build the SONiC OT VS image from source code or download a pre-built one from GitHub pipelines. Since the building procedure is straightforward and offers a learning experience, we’ll focus on that approach here.

First, clone SONiC for OTN repository:

The latest SONiC for OTN codebase is currently located on the “otn_pre_202411” development branch. Let’s switch to this branch and initiate the standard build process used by Community SONiC:

Once the build completes successfully, the compressed SONiC-OT-VS image will be created in target/sonic-ot-vs.img.gz. Now, let’s unpack it and create the GNS3 appliance:

You’re now ready to import the newly created SONiC-OT-VS appliance into GNS3. This allows you to explore the SONiC for OTN image and its capabilities.

First, drag the SONiC-OT-VS image and a NAT component into the GNS3 workspace. After that connect the SONiC interface ‘eth0’ (management port) to the NAT. This allows you to obtain an IP address for SSH access, enabling secure copy operations and access to the global network for further configuration.

Figure 4. Run SONiC-OT-VS in GNS3

Right-click on the SONiC virtual device and select ‘Console’ to log in using a serial connection.

Since we created the image manually, the default username for logging into the system is the build PC username (to verify this, we can use the ‘whoami’ command). The password is the default SONiC password.

After logging into the system, we can check dynamically assigned management interface’s IP address using the following command:

Now we can use this IP address (in this example, 192.168.122.254) to connect to the virtual SONiC-OTN device through SSH.

As shown, the virtual device has 4 ASICs, indicating 4 slots for optical linecards. According to SONiC for OTN architecture, this translates to 4 instances of “OTSS” and “SyncD-OT”, along with a corresponding database for each linecard.

SONiC is a container-based NOS. This means that each component runs within a separate Docker container. SONiC for OTN follows the same approach. To see which Docker containers are running within the SONiC-OT-VS virtual device, you can check the following:

As we can see, SWSS has been replaced with OTSS, and Syncd has been replaced with the Syncd-OT container. Optional BGP and LLDP containers are running as the single instance globally.

According to SONiC-OTN design, certain features such as “teamd”, “snmp”, “dhcp-relay” are expected to be disabled. As previously observed, when inspecting the Docker container within the SONiC-OT-VS image, the “SWSS” and “BGP” containers were present but started and exited during the initialization stage, when should be disabled.

Before attempting to configure the SONiC-OT-VS image, you should ensure that the instance you are running is ready. The following Docker containers are crucial for configuration and are expected to be running: “OTSS”, “Syncd-OT”, and “Database”.

Let’s check which Docker containers are currently running on the system:

As you can see, there are four running instances of “OTSS”, “Syncd-OT”, and Database Docker containers – one instance per Linecard. To check the default configuration, you can attach to the Database container, enter the REDIS Config DB, and check its contents:

This contains information about syslog, logger, features, technical support, etc.:

Now, you can attempt to configure this image. Currently, SONiC-OTN on the “otn_pre_2024” branch lacks CLI commands for configuration. However, the community provides some samples of how to interact with SONiC for OTN.

Plug-in the Linecard into the System

Continuing from our discussion, one of the major differences between traditional SONiC and SONiC for OTN networking operation systems is that SONiC for OTN supports plugging and unplugging devices. The community provides a simple script to emulate OTN device plug/unplug behavior:

1. 1) e110c: This line system includes optical attenuator, supervisory channel, multiplexer/demultiplexer, and optical line protection units.
2. 2) p230c: This transponder has four 100G Ethernet client ports and one 400G line port.

Let’s download the script to emulate Linecard plug/unplug behavior. Since you have configured GNS3 NAT, you should have access to the global network. This means you can install the “wget” tool directly on our SONiC image and download the mentioned script with a few simple steps:

Now you can plug-in the “e110c” Linecard into the first slot and the “p230c” into the second slot:

Consider changes in “database0” and “database1″. Both Linecards configuration should be loaded into the Config DB. Orchagent uses OTAI-Redis library to communicate with Syncd-OT. The Syncd-OT then configures the hardware using the OTAI API.

Currently, we will focus only on the first Lineсard, inserted into the first slot. You can run the commands we used previously to check the contents of the “database0” Docker container related to the first device slot where the “e110c” Linecard was inserted.

You can check the Linecard type from the Config DB:

Let’s take the Optical Supervisory Channel (OSC) unit as an example. You can see its configuration in the Config DB:

The OSC has a parameter that allows us to enable or disable this unit. By default, it is enabled.Let’s disable it and observe how the configuration and state change in CONFIG_DB, APPL_DB, and ASIC_DB:

Additionally, you can examine how the OSC OTAI object changed from the initialization stage to the configuration you applied from “/var/log/otss/otss.asic0.rec”.

First, the OSC interface was configured during the initialization stage, and Interface ConfigDone was set:

Then, the OSC and related LLDP feature, location (slot), parent (linecard) name, etc., were set:

Now, let’s check what has changed when you set OSC unit state to disabled:

To simulate linecard plug-out, you should run the command as follows:

As a result, all the databases will be reset, the information related to the Linecard configuration removed and appropriate OTSS and Syncd-OT services will be restarted.

From this example, you can clearly see that the basic SONiC-OT-VS functionality is ready. And there are many features and improvements that SONiC for OTN community is working on.

What’s Next for SONiC-OTN

SONiC-OTN is currently under active development. While the core functionality is complete, allowing the NOS to recognize device plug-ins and pull-outs, as well as manage and configure linecards when they are inserted into a slot, there are additional features that the SONiC-OTN Working Group plans to introduce:

• Expanded CLI Functionality: Add support for OTN-specific commands and features based on “sonic-openconfig-cli” container, which was developed to automatically generate CLIs for Openconfig yang model. The Openconfig yang models already supports AMP, VOA, OCM, and OSC optical transport models.
• PMON Extension: PMON performance monitoring (PM) periodically queries peripheral statistic values for 15 minutes or 24 hours of data and saves performance statistics to the counter and history databases.
• OTN Alarms and Events: Based on peripherals monitoring results in PMON, send alarms to EventD. Extend EventD with corresponding event/alarm handling and processing.
• SONiC Management Telemetry: For managing configuration and status on SONiC switches, extend “sonic-mgmt-telemetry” to support OTN devices.

Conclusions

The evolution of Optical Transport Networks (OTN) is crucial for a wide range of industries and organizations that requires fast, reliable, and high-capacity data transmission. These include Data Centers, telecom providers, Communication Business, and Financial Institutions.

SONiC has revolutionized network management, providing operators with an open, flexible platform that addresses diverse networking requirements. With the launch of SONiC-OTN, these capabilities now extend into the domain of Optical Transport Networks, offering a comprehensive solution for managing both optical and packet-based networks on a unified platform.

SONiC for OTN is currently in active development. While the SONiC OT Virtual Switch has some limitations (such as issues with CLI and PMON), it is still functional and serves as an excellent starting point for exploring SONiC for OTN.

As a respected contributor to the SONiC community and trusted partner to many industry leaders, PLVision brings extensive experience in SONiC integration. Our expertise extends to exceptional SAI/SONiC development, enabling substantial advancements in OTAI, SONiC OTN, and the integration of SONiC native L2/L3 features.

We deliver robust, customizable solutions tailored to your business needs. Contact us today to discuss your open networking use case.