This article is more than 1 year old
One API to rule them all: The great network switch silicon heist
Protocols? Pfff, don't make us laugh
Microsoft, Dell and Facebook are among a group of vendors who have come together with data centre operators to develop software intended to abstract chunks of network silicon (switches, typically) from the network operating system that runs on them.
The first implementations of the specification for this Switch Abstraction Interface (SAI) were showcased at the recent Open Compute Project Summit in March 2015.
SAI is a specification to provide a consistent programming interface for common networking functions implemented by network switch Application-Specific Integrated Circuits (ASICs).
The intention here is for network switch vendors like Brocade, Cisco, Netgear and others to be able to build “new and innovative features” through extensions that come back to this consistent programming interface and therefore attract a wider base of users.
Equally, software application developers programming network-level software will be able to work with a more interoperable outlook and therefore customise more openly.
To put it in simple terms, the Switch Abstraction Interface is a network-level Application Programming Interface (API). If we accept that APIs exist to form vital communications bonds between different software code elements and data streams, then a network API has the job of connecting the operating system to the network switches. It’s the same kind of thing, just deeper down.
Creating a more open API for this type of task means, in theory, that the network operating system should be able to control switch behaviour irrespective of what type of system of protocols and silicon base it is running on, without the need for conversion codes.
Microsoft Azure networking principal architect Kamala Subramaniam has said: “Today in our production networks, we deploy a multitude of vendors across many layers, whether ASIC manufacturers or switch vendors. The reality is that something as basic as getting switches to forward packets requires undifferentiated work.”
The problem is, networks have traditionally always been built with a more “strict coupling” of protocol stack software compared to the hardware that they run upon. The wider trends for decoupled computing and separated-out dependency streams in parallel processing have dovetailed with calls for more interoperable network technologies – hence the arrival of the Switch Abstraction Interface (SAI).
“SAI allows software to program many different switch chips without undergoing any changes. This helps us to keep the base router platform simple, consistent, and stable. It also reduces the time to market, and enables the adoption of the latest available hardware easily. It breaks the software-hardware coupling and allows us to cherry pick the best fit of software and hardware on a ‘need by application’ or a ‘need by network basis’,” Subramaniam wrote.
Software developers don’t want to care about whether their code runs on an Intel chip or an AMD chip. Ultimately they don’t want to care about whether their code runs on Windows, Linux, Apple OS X or mobile. By the same rule then, network software engineers don’t want to care about which switch protocols they need to code to. A more open API to rule them all works better all round. ®