Switch Abstraction Interface (SAI) defines an abstraction interface for programming switching ASICs (Application Specific Integrated Circuit). The interface is designed to provide a vendor-independent way of controlling switching entities in ASIC – for e.g: FIB (Forwarding Information Base), RIB (Routing Information Base) — that are essential for management of a switch.
Figure 1: Switch Abstraction Interface (SAI)
Before SAI specification, software vendors had to develop code for each hardware ASIC vendor’ SDK. The Network OS was tightly coupled with the ASIC SDK leading to increased costs, and vendor lock-in. In addition, there was no consensus on approach for interface layer. It was also not scalable since software vendors have to rewrite code every time to support a new ASIC SDK resulting in code instability and longer schedules.
SAI enables the disaggregation or de-coupling of network software and hardware. Disaggregation which has gained significant traction in industry leads to faster time-to-market, choice for customers (hardware and software options can be chosen independently) with no vendor lock-in and is more cost-effective.
SAI project started as a joint development effort between Microsoft and Dell on a user-space switch application project. It was officially accepted as an OCP (Open Compute Project) project in 2015.
SAI defines generic, object-based CRUD(Create, Read, Update, Delete) APIs for switching silicon configuration and monitoring. The unified strict rules are used in both APIs and the attributes naming scheme. In addition to this, SAI is self-documented in the Doxygen format with compile time interface validation and supplementary metadata generation.
As a proof point for how well-done the SAI design is, look at the PHY extension to SAI – a successful attempt to re-use SAI as a generic interface for the external PHY configuration. SONiC (Software for Open Networking in Cloud) NOS has also leveraged the SAI as an abstraction layer.
Innovium SDK & SAI
Innovium has developed a Modern, Efficient & High-Performance SDK with a ‘clean sheet’ design. Most of the SDK is in user space (see figure below) and is POSIX compliant to simplify portability. The SDK APIs in fact use SAI’s CRUD model. The SDK is highly Resilient with support for Warm and Fast boot and has a highly optimized DMA engine. It also supports multi-threaded fast access to APIs including support for FLASHLIGHT™ analytics.
Figure: Innovium Software: SDK & SAI
Innovium software has embraced SAI right from the start. SAI was supported from the very first silicon — around 2018. SAI support has had many releases over the last few years and the latest release – 1.7.x – started shipping recently.
Innovium has many customers using SAI today – with both SONiC as well as 3rd party NOS that uses SAI to program the switch ASIC. SAI support exposes all key ASIC functions, including programming various forwarding tables, ACLs, diagnostics and Hash knobs. The enhacements enabled customer use cases with customized extensions to SAI layer. Customers currently use Innovium switches in multiple use cases and in different tiers of data center and edge networks.
The end result of many years of efforts is a SAI implementation that is highly robust and has enabled customers to experience an extremely stable deployment.
SAI has played a crucial role in opening up Data Center Networking from proprietary solutions. Innovium has been supporter of SAI from the initial days as SAI layer democratizes networking and encourages innovation in Data Center networking. Innovium believes that SAI is a critical piece in accelerating innovation in disaggregated Data Center networking in the years ahead.