OCP’s OSPA Draft Targets the Switch Platform Layer Beneath SONiC

On October 8, 2026, the Open Compute Project introduced the Open Switch Platform Architecture (OSPA), an in-progress Networking Project contribution. Its announcement describes Revision 1.0.0 as a candidate under Foundation review. [1] The buyer significance is the proposed reuse boundary: a common way to manage the switch platform beneath a network operating system (NOS). The practical question is which work a client could share across switch models and which work each supplier would still implement.

Why forwarding portability leaves a platform gap

The Switch Abstraction Interface (SAI) defines a vendor-independent API for controlling forwarding elements, including switching ASICs. SONiC also has platform software: its sonic-platform-common project supplies common interfaces to platform-specific hardware peripherals. [2][3] Those two descriptions explain why sharing a forwarding interface and sharing a complete platform are different questions. Packet-forwarding software needs an interface to the forwarding engine; platform software also needs to identify and interact with the surrounding hardware.

A common software interface can hide differences from its callers while still requiring a different implementation underneath for each switch model. For a buyer, the resulting question is where reusable code ends and model-specific integration begins. An ASIC name helps identify the forwarding component. It does not describe how the complete switch exposes its inventory or environmental information. This is the gap through which the OSPA proposal should be assessed.

What the proposed architecture would organize

OCP describes host-centered platform management, with the baseboard management controller (BMC) retaining supervisory functions including power management, host bring-up and recovery of an unresponsive host. It also describes PCIe-attached I/O Bridge FPGAs aggregating peripheral controllers, and an Atomic Platform Entity (APE) inventory tree with IDPROM requirements at each node. The stated scope excludes routing and forwarding operations and pure hardware design details. [1]

Conceptually, that brings three related questions into one architecture: who performs ordinary platform management, how software reaches peripherals, and how it discovers what hardware exists. The distinction matters because moving responsibility onto the host still leaves a need to address the case where that host cannot respond.

Discovery and access solve successive parts of the same task. Software first needs a component identity and its place in the inventory, then a route to the peripheral that supplies the relevant environmental information. Conceptually, a consistent discovery model and access arrangement let a caller follow that sequence across models. Each model's implementation still has to connect the discovered component to the correct peripheral. The reusable part is the caller's sequence; the physical inventory and the implementation beneath it can differ.

Two switches can share an ASIC and require different platform integration

Consider fictional switch SKUs A and B. Stipulate that both use the same forwarding ASIC and are being evaluated for the same NOS. A exposes component identities through one inventory arrangement and environmental readings through one set of interfaces. B uses a different enumeration arrangement and different environmental interfaces. These are invented differences for the comparison, not descriptions of any manufacturer's products.

Give the buyer one concrete requirement: the same inventory client must identify every component represented in each switch's declared inventory and reach the environmental interface associated with each component that exposes one. Suppose A's supplier has already explained that path for A. B's initial response says only that its next design will follow OSPA. The missing explanation is how B's actual component identities and environmental interfaces would be presented to that client. Even if forwarding integration were reusable between A and B, it would not supply that mapping.

Now stipulate a more useful response from B's supplier for the offered design. It describes an APE tree covering the components in B's declared inventory, connects their identification information to the corresponding nodes, and maps the applicable environmental interfaces to peripheral controllers reached through B's PCIe-attached I/O Bridge FPGA. It also identifies the platform software and firmware responsible for exposing that arrangement through the same caller-facing interface used for A. This is a fictional design explanation, with no invented standard field names, component counts or observed readings. The returned relationships explain how the client would find the right component and reach its environmental information.

Carry the platform return into the purchase comparison

With that mapping, the client can use the same sequence for A and B: discover a component, retain its identity, locate its applicable environmental interface and request the information through the shared interface. It need not assume that B has A's component order or native peripheral layout. B's inventory description, controller mapping and underlying software/firmware implementation remain specific to B. The supplier has explained a reusable caller behavior and the model-specific work supporting it; sharing the caller does not mean copying A's implementation unchanged.

The buyer can now close the discovery/access explanation for B against the stated requirement and compare it with A's description. Support for the exact offered hardware revision and proposed NOS distribution/build is a separate outstanding question for the appointed NOS/platform support owner. That return needs applicable release evidence, known limitations and ownership of platform issues. The October announcement's candidate reference architecture supplies context for the implementation discussion, rather than product conformance or support evidence. This is the decision boundary between an explained design and a supported combination.

Finally, suppose the appointed support owner returns applicable release evidence for both offered hardware revisions and the exact proposed NOS build, confirms support for those combinations, and identifies limitations and issue ownership that meet this fictional buyer's stated requirement. The comparison now has two explained discovery/access arrangements and two confirmed support positions. The buyer can compare the offers on those terms; mounting, airflow, cabling and site readiness remain with the physical installation package. Neither the mapping nor the support return measures onboarding work, so this comparison yields no quantified time saving.

Keep the installation decision attached to the actual switch

The existing SONiC switch installation guide covers hardware/software identity and physical handoff records. Use it for that downstream task rather than treating OSPA as a replacement installation package. A platform-management architecture does not select the offered switch's mounting arrangement, airflow package or physical connections.

For agreed equipment mounting, IT cabling, labels and installation records, Leviathan's rack-and-stack service provides the relevant physical scope. [4] Bring the actual switch models, released rack and cable plans, and named software/support owner to a project inquiry. That connects the architecture discussion to the physical work being requested while leaving NOS and platform support with the appointed teams.