SONiC and DASH have emerged as essential solutions to meet modern networking needs like flexibility, efficiency, and performance optimization. SONiC's open-source framework empowers organizations to customize their network operations, reducing dependency on proprietary systems and fostering innovation.
Complementing this, DASH leverages hardware acceleration to enhance network performance, efficiently offloading processing tasks and unlocking new levels of throughput and latency reduction. Together, SONiC and DASH offer a transformative approach that enables businesses to build agile, scalable, and high-performing networks fit for the demands of the digital era.
SONiC
SONiC, which stands for Software for Open Networking in the Cloud, is an open-source network operating system (NOS) based on Linux, designed to bring flexibility and efficiency to modern networking environments. At its core, SONiC introduces open networking principles. It embodies the concept of vendor independence, allowing organizations to decouple their hardware and software choices. This means that SONiC can run on various networking hardware, promoting interoperability. Many well-known vendors are already involved in the project, making SONiC a widely supported solution.
If you want to know more about SONiC, visit our blog, where you can find articles explaining it in more detail:
- Developing custom network functionality using SONiC
- Enhancing SONiC - the process of developing custom network functionality
- SONiC adaptation for custom functionality – the PoC reveal
Before proceeding with this article, it’s recommended that you become familiar with SONiC at a basic level.
SONiC-DASH
Introduction to SONiC-DASH
SONiC-DASH (Disaggregated API for SONiC Hosts), or simply DASH, is an extension to the SONiC NOS. It is open-source software aiming to deliver enterprise network performance to cloud applications using SmartNICs, SmartSwitches, DPUs, IPUs, accelerators, and network appliances. It provides a structure for using these devices to perform protocol offload, application and network acceleration, and other tasks. SONiC was designed to operate on devices typically associated with the core networking infrastructure. DASH extends SONiC beyond those standard functionalities, allowing usage on the edge or with a customized networking path. The intent is to make programmable network devices like SmartNICs and DPUs easier to use, allowing their deployment in enterprise networks, clouds, supercomputers, high-performance computing, IoT, factory networks, and other installations.
DASH enables administrators to utilize external processing elements to offload CPUs and accelerate tasks such as AI/ML, analytics, deep packet inspection, media and signal processing, virtual reality, and scientific and military applications. It does it by delivering a framework to write a behavioral model of such services, which is an abstract representation of packet processing logic and network behavior using a programming language (P4 - more later about that). It also delivers test cases to confirm conformance to the requirements of given services and performance requirements. What is important is that technology providers involved in the project will conform to the model and test cases when designing and building programmable hardware technology.
The main goal of DASH is to be specific enough for SMART Programmable Technologies to optimize network performance and leverage commodity hardware technology to achieve 10x or even 100x stateful connection performance.
Architecture and interaction with SONiC
SONiC, a network operating system tailored for switches, including top-of-rack (TOR) switches, spine switches, and border-leaf switches, offers a robust framework for network device management, enabling programmability and automation in network operations.
On the other hand, DASH operates primarily on smart appliances, concentrating on offloading processing tasks from CPUs to enhance task acceleration. DASH leverages the existing APIs provided by SONiC, extending its functionality to integrate with SONiC-based network environments.
DASH builds upon the foundational system architecture of SONiC. It still relies on redis-db as a central point of data and modules packed into containers that publish/subscribe for data and interact with an external environment. Comprising SONiC modules, extending some of them and introducing its own, DASH seamlessly integrates with the existing SONiC ecosystem.
The below diagram shows modules extended or added by DASH and the interaction between them:
If we look at DASH as black box software interfacing with the external environment, two primary components emerge for communication. The first is the northbound API, known as the DASH API, which facilitates the management of DASH by the SDN Controller. The second is the southbound API, an extended SAI API (Switch Abstraction Interface API) that offers a vendor-independent mechanism for controlling forwarding elements, encompassing switching ASICs, NPUs, or software switches in a uniform manner.
Let's look at the components extended by DASH:
- gNMI container (1): this is a component responsible for implementing the gNMI protocol, which is based on gRPC and Protocol Buffers. It enables SONiC-DASH devices to be managed and configured remotely using gNMI-based network management tools and platforms
- Redis DB (2): used primarily for storing real-time operational data and for communication between various components within the SONiC ecosystem
- orchagent (3): a crucial component responsible for translating high-level configuration into lower-level operations. Orchagent abstracts network device configurations, enabling SONiC to work seamlessly across various hardware platforms by interfacing with the SAI API, which provides a standardized interface for accessing hardware-specific functionalities.
- Switch Abstraction Interface (SAI) API (4): provides a standardized programming interface that abstracts the functionality of different underlying switching ASICs and hardware platforms.
DASH configuration is orchestrated by the SDN controller, governing the overlay established atop the physical layer (underlay) of the infrastructure. Communication between the SDN controller and a DASH device occurs through a gRPC-based gNMI endpoint (1) hosted within a new SONiC-DASH container. Within the DASH container, the SDN configuration, modeled in gNMI, is translated into DASH_APP_DB objects in Redis DB (2).
Subsequently, the SONiC orchagent (3) inside the Switch State Service (SWSS) Container is enhanced to convert and interpret these objects into ASIC_DB objects (2), encompassing the newly introduced DASH-specific SAI objects. An improved syncd (4) then configures the data plane utilizing the technology supplier-specific SAI library.
DASH pipelines
DASH establishes an overlay service atop an underlay infrastructure managed by the traditional SONiC. This overlay service, or application, harnesses pipelines as adaptable processing units. A pipeline, represented as a sequence of stages, allows for the creation of custom processing logic. Each stage delineates a series of tables, with table entries matching packets based on specified criteria and executing corresponding actions. These pipelines, residing in the data plane (e.g. SmartNIC, DPU), can be dynamically configured to accommodate new use cases and services dictated by the overlay service.
Moreover, pipelines can be programmed to accommodate specific use cases and services, allowing for dynamic adaptation to changing network requirements. This flexibility enables the definition of actions tailored to specific packet behaviors, such as dropping, forwarding, modification, or preservation. For instance, an inbound packet processing pipeline might govern traffic destined for a virtual machine (VM) within a virtual network (VNET).
Supported scenarios
DASH is a relatively new project, but still, it already offers a couple of initial services for clouds.
The following are supported applications:
- VNET to VNET - allows for VM to VM communication in VNET, route support, LPM support, ACL support,
- VNET peering - connects two or more virtual networks so they appear as one,
- High availability (HA) - increasing availability in case of fail-over,
- Load balancer - distributing incoming network traffic between endpoints to ensure efficient utilization, using a direct path between VMs,
- Service tunnel and private link - establishing connection between private link with access permitted VNET,
- Encryption gateway - service managing encryption and decryption of data traffic within a network,
- Express route gateway - service allowing customers to establish private and dedicated connections to cloud services.
Acceleration and offloading
What you should know about P4
P4 (Programming Protocol-independent Packet Processors) is a domain-specific programming language designed for defining how network packets are processed by forwarding devices such as switches and routers. Unlike traditional networking languages, P4 focuses on providing a high level of abstraction to program the data plane, enabling network engineers and researchers to customize and optimize packet processing without being tied to specific hardware or protocols.
P4 is protocol-independent, meaning it allows users to define the behavior of packet processing without being bound to a particular network protocol. This flexibility is particularly valuable in the rapidly evolving landscape of networking, where new protocols and technologies are constantly emerging. With P4, network operators can adapt their infrastructure to support these changes without the need for extensive hardware upgrades or replacements.
One of the primary use cases for P4 is in software-defined networking (SDN) environments. SDN separates the control plane from the data plane, allowing network administrators to control and manage network behavior dynamically. P4 plays a crucial role in this paradigm by enabling the programming of custom packet processing logic in the data plane, facilitating the creation of highly flexible and programmable network architectures.
If you want to know more about P4, visit our blog where you can find more detailed information about it:
- P4 Network Programming Language — what is it all about?
- SmartNICs with P4 support
- P4-programmable SmartNIC controlled by ONOS (video)
>> Read more about our network professional services.
DASH and P4
DASH defines the method by which data plane devices process packets. DASH utilizes the previously mentioned pipelines for that purpose. P4 plays a crucial role in this context, as it is employed to model and describe DASH pipelines. By using it, network engineers can define custom packet processing logic that is executed directly in hardware, offloading the work from the general-purpose CPU and speeding up packet processing.
The P4 code is the definitive specification of data plane behavior. Specifically, the P4 code, or more precisely, the P4Info generated by the P4 compiler, is utilized to automatically generate DASH SAI header files, establishing the connection between the P4 code and the corresponding DASH-SAI APIs. Taking it a step further, the SAIThrift code designed for testing the overlay service, as described in P4, is also auto-generated (DASH testing is a topic for a separate post). This integration highlights that P4 acts as the single source of truth for data plane behavior.
An important note is that P4 is used to describe the behavior of the data plane; it’s used to generate header files, but the implementation of the data plane itself doesn’t have to be made in P4. It’s up to the hardware vendor what technology is used to implement the data plane. However, it must be conformant with the model described in P4.
Build DASH
Depending on needs, DASH could be built for the target hardware platform if we want to deploy it in a production environment or for a software platform if we want to develop or test it.
P4 Software platform - testing build
The software platform is based on the P4 Behavioral Model Reference switch 
known as bmv2. It can be used as a reference target or DUT for regression testing and new test-case validation or for playground purposes. Its downside is low performance and limitations on available resources (e.g. limitation on table sizes). It also does not run in a SONiC-DASH environment; rather, it's a separate toolkit where P4 code could be written or tested.
To play with the P4 DASH code and software switch, you need to download the main DASH repository . You will find lots of documents describing DASH itself but also regarding building and testing. In this document - DASH workflows - you can find examples of how to build an environment to develop and test P4 code. In short, you need to compile P4 code (make all), auto-generate the DASH SAI API based on P4Info, compile libsai for a DASH, including SAI-to-P4Runtime adaptor, and create Docker images containing the needed tools. Then, you need to launch bmv2 with the P4Runtime server (make run-switch), initialize the bmv2 switch, and load the P4 program (make run-switch). As a last step, you need to run a container that connects to the bmv2 switch (make run-saithrift-client-bash) and use it to send some packets and test the behavior of that switch.
In general, experimenting with P4 and bmv2, testing either existing or new scenarios, is a vast topic that needs dedicated discussion. A detailed examination of the test harness analysis is something that could be covered in a future article.
Hardware platform - production build
As mentioned earlier, DASH is an extension of SONiC, with separate repositories available for its codebase and API . Despite these separate repositories, the building process is seamlessly integrated with SONiC through its designated building environment known as SONiC-buildimage . When initiating a SONiC build, the DASH code is automatically included and compiled, ensuring its integration within the SONiC ecosystem. To ensure full operational functionality, certain components must be built alongside DASH.
Summary
Designed to enhance hardware programming for extensive networking capabilities, DASH makes use of SONiC's architecture and key components, following an SDN approach for implementing the data plane. Unlike SONiC, which is a mature technology, DASH is still in the development stage. However, it’s already integrated with SONiC mainstream baseline. We await widely recognized SDN controllers that are compliant with DASH, and hardware vendors need more time to release DASH-compliant devices.
However, considering vendor interest and community engagement, we see significant potential in this technology, envisioning it as an integral part of future network implementations. Consequently, we are actively exploring DASH further and will closely follow its ongoing development.
