A single standardized API now decides which switching silicon gets to run SONiC – and which gets locked out of the fastest-growing segment of the open networking buyer market.

For most of the history of Ethernet switching, a great ASIC wasn’t enough. Every silicon generation shipped with its own SDK, its own driver model, its own management interface, and its own set of NDA-bound integration agreements. If a switch manufacturer wanted to support a second ASIC vendor, the entire software integration got rewritten from scratch – years of engineering, duplicated protocol stacks, and design wins decided as much by software relationships as by chip performance.

That changed in 2014, when Microsoft and Dell independently arrived at the same conclusion at an Open Compute Project engineering workshop: forwarding hardware needed a common, vendor-neutral programming boundary. The result, the Switch Abstraction Interface (SAI), became the layer that lets SONiC – now the leading open networking operating system for hyperscale data centers – talk to Broadcom, Marvell, NVIDIA, and Intel silicon through the same API calls.

For ASIC vendors, that boundary has quietly turned into a gate. A chip with a complete, high-performance SDK but no compliant SAI adapter is invisible to most of the SONiC ecosystem’s design-win evaluations, regardless of how good the silicon is underneath.

SAI’s relevance now reaches past traditional data center and enterprise switching into AI fabrics, too. Ethernet for Scale-Up Networking (ESUN), the OCP workstream defining intra-pod AI accelerator interconnects, and the Ultra Ethernet Consortium’s UET specification for scale-out fabrics are both converging on SAI as a shared hardware-abstraction layer: UEC has said publicly that it’s coordinating directly with OCP to standardize SAI extensions alongside its multipathing, congestion-control, and telemetry work. That puts a compliant SAI adapter on the requirements list for AI Scale-Up (SU) and Scale-Out (SO) design wins, right alongside its existing role in traditional switching.

In this article, you’ll find the pre-SAI problem, how the object model and orchestration pipeline actually work inside SONiC, the business case that makes SAI compliance a board-level question rather than an engineering footnote, and how PLVision’s SAI Launchpad turns SAI adapter development from an open-ended integration project into a staged, testable delivery.

The Numbers Behind the Switch Abstraction Interface Decision

• The data center switch market is on track to grow from $17.93 billion in 2025 to $28.47 billion by 2031, an 8.02% CAGR – and SAI is the layer every one of those switches has to clear to run an open NOS.
• Analyst firm 650 Group projects SONiC-based switching alone will exceed $8 billion in data center switching revenue by 2027, spanning hyperscalers, Tier 2/3 cloud providers, and telecom operators.
• SONiC’s public list of supported devices and platforms already runs well past 120 entries across switch and ASIC vendors, and every one of them exists because a SAI implementation made it possible.

The Problem SAI Was Built to Solve

Before SAI, the stack looked the same at every vendor: applications talked to a network OS, the network OS talked to a vendor API, the vendor API talked to a vendor SDK, and the vendor SDK talked to the ASIC. Change the ASIC and every layer above it had to be rewritten, because the vendor API and SDK were proprietary and mutually incompatible.

This produced a predictable set of consequences: years of engineering to enable basic packet forwarding on each new chip, duplicated protocol implementations across NOS vendors, testing that had to start over for every silicon platform, and switching costs high enough that hardware vendors and NOS vendors ended up locked to each other by default rather than by choice.

Two competing models eventually emerged to break this coupling: the kernel-space Switchdev approach, which represents hardware inside standard Linux kernel structures and works with existing Linux tooling out of the box, and the user-space SAI model, which runs entirely outside the kernel. SAI itself is just the C API boundary between a control plane and a driver – it has no concept of Redis or of how a NOS organizes state on its own side of that boundary.

That’s SONiC’s own control-plane design: its daemons happen to track state in a set of Redis-backed databases before they ever call into SAI. SAI’s user-space design let ASIC vendors keep shipping closed-source, pre-compiled drivers (libsai.so) without disclosing SDK internals, which is a large part of why it became the model SONiC and FBOSS both standardized on.

Inside the Switch Abstraction Interface: Objects, Attributes, and Compliance Tiers

SAI is a standardized, attribute-based C API. Most switch resources – ports, VLANs, next hops, virtual routers, ACL tables – are represented as objects with a unique 64-bit handle (sai_object_id_t) and a set of attribute-value pairs that can be set, read, or queried for support. A few resources that need to be looked up by their natural key instead of a synthetic one skip the object-ID model entirely: route, FDB, and neighbor entries are keyed by their own structured types (sai_route_entry_t, sai_fdb_entry_t, sai_neighbor_entry_t), though they still carry the same attribute-value pairs as everything else. That design choice is what keeps the northbound control plane stable across SDK versions: a driver upgrade changes the SDK underneath, not the API contract above it.

SAI marks individual attributes, not whole object types, as mandatory or optional to implement. The specification doesn’t declare “VLANs are mandatory” or “ACL tables are optional”; it flags specific attributes on each object that way, and it’s the target NOS’s control plane that decides which object types matter in practice. For SONiC, that floor is unambiguous: without working Switch and Port object implementations, orchagent never gets past initialization. Past that floor, how much of an object type’s attribute surface – VLANs, unicast routing, ACL tables – an adapter needs depends on what SONiC’s orchestration layer exercises for the deployment at hand.

• Mandatory-to-implement attributes – flagged directly in the SAI headers (often via MANDATORY_ON_CREATE). Miss one on an object SONiC calls for, and initialization for that object fails, full stop.
• Optional attributes and features – advanced traffic management, non-core tunnels, and specialized QoS scheduling. The control plane queries for these dynamically rather than assuming they exist.
• Custom attributes – vendor-specific extensions, namespaced starting at SAI_*_ATTR_CUSTOM_RANGE_START = 0x10000000 so they can’t collide with the standard attribute space. SONiC doesn’t touch this range by default; it only matters once a vendor or customer needs functionality the standard API doesn’t cover.

That namespace boundary sounds like a formality until it isn’t: defining custom attributes directly after a standard _ATTR_END marker is a documented, recurring compliance error – when a newer SAI release adds standard attributes into that same range, the enum IDs collide, and the orchestration daemon starts parsing invalid data types. That’s a driver crash in production, not a compile-time warning, which is exactly why SAI adapter development is a validation discipline and not a one-time integration task.

How SAI Moves Configuration Into Silicon

SONiC routes configuration through a chain of Redis database instances before any of it reaches silicon. A CLI command becomes intent, and a sequence of daemons carries that intent down to the ASIC:

1. A CLI command (sudo config vlan add 101) writes into CONFIG_DB.
2. The vlanmgrd config manager daemon picks up that entry and synchronizes it into APPL_DB.
3. The Orchestration Agent (orchagent), running inside the SWSS container, translates the high-level configuration into standard SAI object representations and writes them into ASIC_DB.
4. The synchronization daemon (syncd) reads the new ASIC_DB entry, converts it from serialized strings into C-language binary types using SAI metadata, and calls the matching SAI API – in this case sai_vlan_api->create_vlan().
5. The vendor’s libsai.so translates that call into the register writes that actually configure the ASIC.

Two things fall out of this pipeline that matter for anyone implementing SAI. First, it decouples routing protocols and application logic from the ASIC driver entirely – the driver only needs to react to ASIC_DB changes, not understand routing semantics. Second, because the abstraction is complete at the API boundary, the “silicon” on the other end doesn’t have to be silicon at all: SONiC can talk to a pure-software forwarder like VPP through libsaivpp.so using the identical API calls it would use for a physical Broadcom Tomahawk ASIC. The control plane genuinely doesn’t know the difference, which is a strong signal of how cleanly the abstraction holds.

Why Every ASIC Vendor Should Care

Large cloud operators, Tier 1 carriers, and increasingly Tier 2/3 providers now specify SONiC or FBOSS as a standard requirement in their design-win evaluations. Because both operating systems rely on SAI as their hardware abstraction layer, an ASIC without a validated SAI adapter simply doesn’t clear that bar – the silicon’s raw performance never enters the conversation.

The SAI verdict: a switching ASIC without a compliant SAI adapter doesn’t run SONiC. Increasingly, that also means it doesn’t clear a growing share of hyperscaler and Tier 2/3 procurement evaluations.

The economics run in the vendor’s favor once the adapter exists, though. Under the old model, silicon vendors maintained bespoke software stacks and full protocol implementations per platform per customer. SAI redraws that boundary: the vendor implements the standardized API on top of their SDK, and the open-source community carries the weight of protocol stacks, CLI tooling, automation, and management interfaces. White-box manufacturers have built entire businesses on this economics, sourcing silicon directly from Broadcom and pricing well below branded equivalents while still running a fully supported NOS.

Differentiation survives standardization by design. The custom attribute namespace lets a vendor expose differentiated capabilities – advanced congestion control, programmable telemetry, specialized AI routing pipelines – as SAI extensions on top of mandatory compliance. Compliance is the entry ticket. Differentiation is what a vendor builds on top of it.

SAI Adapter Development: Where ASIC Vendors Stall

None of this makes SAI adapter development simple. The gap between “we have a working driver” and “we have a production-grade, SONiC-compliant SAI adapter” is where most ASIC vendors and OEM engineering teams lose the most time, and it shows up in a few consistent places:

1. The attribute surface is bigger than it looks. A single SAI object type can carry dozens of attributes across create, set, and get operations, and no vendor tests every legal combination before a design win is on the table. An adapter that boots cleanly and clears basic sanity checks can still carry a broken interaction between two attributes that only surfaces once a specific ACL, VLAN, and routing combination hits real production traffic. And that gap between initializing and behaving correctly under load is where a lot of the actual quality risk in SAI adapter development lives.
2. SAI itself keeps moving. New releases add features – NAT, BFD trap support, generic resource monitoring, TAM. Every one of them is a compatibility surface a vendor has to track to stay aligned with what SONiC expects.
3. The SONiC ASIC bring-up chain has more steps than the driver alone. Getting a new ASIC running under SONiC means Linux bring-up, platform drivers, the libsai.so implementation itself, syncd integration, orchagent mapping, and community platform enablement – each with its own failure modes.

This is the exact chain PLVision, a networking software engineering company with years of SONiC engineering depth, built SAI Launchpad to shorten. Rather than treating SAI adapter development as an open-ended integration project, PLVision’s SAI Launchpad structures it as a graduated build: mandatory-tier APIs first, validated against the reusable SAI test framework so a new ASIC can run SONiC at all, then optional and custom-tier features layered on against the same validation pipeline. PLVision has delivered this bring-up work across Broadcom, Marvell, Intel/Barefoot, and NVIDIA/Mellanox silicon, and contributed the open-source SAI Challenger framework to OCP in 2021 – the same testing lineage SAI Launchpad’s validation stages build on.

SAI’s Expanding Surface: DPUs, External PHYs, and Optical Switching

SAI’s object model turned out to generalize well past its original scope of switching ASICs. The Disaggregated API for SONiC Hosts (DASH) extends the same API model to DPUs and SmartNICs, offloading stateful overlay services – VNet-to-VNet peering, NAT, connection tracking – to programmable hardware while the underlay packet path stays on standard switching silicon.

OCP’s Optical Circuit Switching (OCS) Subproject is now defining SAI object types for optical circuit switches themselves. An open pull request against the SAI repository proposes OCS cross-connects addressed by SAI object ID, provisioned in bulk for fast reconfiguration, with read-only factory-calibration attributes for per-path insertion loss. Google has already described running OCS in production inside its Jupiter/AI network architecture and TPU systems through Project Apollo.

The practical implication for ASIC vendors: SAI compliance isn’t a one-time checkbox tied to a single chip generation. As AI and HPC fabrics push toward higher-radix silicon, the same abstraction boundary that standardized switch ASICs a decade ago is now the boundary DPUs, external PHYs, and optical components have to clear, too. PLVision’s SAI Launchpad scope extends this same graduated validation model to DPU and DASH-extended silicon alongside traditional switch ASICs.

What ASIC Vendors Should Do

Audit against the mandatory API set before anything else. A partial mandatory-tier implementation is the single most common reason a SAI adapter fails to initialize under SONiC. Confirm coverage of core ports, VLANs, unicast routing, and basic ACL structures before investing engineering time in optional or custom features.

Wire your adapter into a test pipeline before a design win is on the table. Waiting until a customer requests validation turns testing into a deadline-driven scramble. Standing up SAI-PTF or SAI Challenger-based testing early catches attribute mapping and state-transition bugs while they’re still cheap to fix.

Track the custom attribute range boundary on every SAI version bump. The _ATTR_CUSTOM_RANGE_START collision is a documented, recurring failure mode – not a hypothetical one. Re-verify your custom namespace against each new SAI release before merging.

Publish what you support and what you don’t. A documented list of supported objects, unsupported attributes, and scale limits shortens OEM evaluation cycles more than any performance claim does. Vague documentation is a common reason design-win evaluations stall.

Budget the entire bring-up chain end to end. Linux bring-up, platform drivers, libsai.so, syncd integration, and orchagent mapping are each separate engineering efforts with their own timelines. Treating SAI adapter development as driver work alone is the most common source of schedule slippage in first-time SONiC bring-up.

The Bottom Line

SAI made SONiC portable across silicon vendors, and in the process it changed who gets to compete for the fastest-growing segment of the switching market. A decade ago, ASIC differentiation was mostly a conversation about raw silicon performance. Today, a design-win evaluation increasingly starts with a narrower question: whether the chip on the table has a validated, production-grade SAI adapter behind it.

That question isn’t going away, and the surface it applies to is only getting wider. DASH extends the same compliance bar to DPUs and SmartNICs. OCP’s OCS Subproject is extending it to optical circuit switches next. The vendors treating SAI adapter development as a one-time integration task are the ones most likely to find themselves rebuilding it from scratch for every new silicon generation and every new NOS release.

The vendors who treat it as a structured, testable, staged validation process – mandatory first, optional and custom layered on against a real test pipeline – are the ones showing up in the SONiC ecosystem’s design-win conversations at all.

PLVision builds production-grade SAI implementations for ASIC vendors and OEM engineering teams – including SAI Launchpad for staged SAI adapter development and validation, and SONiC Lite for access and campus platforms. Contact us to discuss your use case.