OpenFlow and SAI

OpenFlow and SAI share a similar target: Providing a vendor neutral way to control networking device forwarding, and by that allow the creation of cross platform networking applications.

Over the last few years, we see a decline in interest in OpenFlow, with a increase in interest in SAI driven primarily by datacenter use cases. This leads to the question what might be possible causes for this?

Some of the explanation might be found the different backgrounds the development of the two approaches had. OpenFlow was a child of the "Clean Slate" project at Stanford University, where researchers imagined how the internet might be designed if we would start from scratch without any respect to backward compatibility.

OpenFlow as a result was designed in a Top to Bottom method, with an abstraction of the networking hardware pipeline into a one table match and action forwarding system. Most of the early research was done on soft switches running on standard PCs with multiple NICs, where this approach worked fine. Even the first hardware based OpenFlow implementations worked fine from a research standpoint, as all flows that were not able to be processed in hardware were implemented on a soft switch running on the switch CPU. While sufficient for research purposes, this did not provide the forwarding performance needed for real world production environments.

It soon became clear that the one table abstraction was not scaleable enough for production use cases, and the multi flow table concept was introduced into the openflow protocol. To instantiate multiple flow tables, the controller would send a command to the switch defining how many tables with which matches and actions an application needs, and the switch would configure its pipeline accordingly. This approach was even harder to implement for devices based on fixed function ASICs. These devices could expose their existing pipeline,, but had now way to adapt the pipeline as openflow envisioned it. Some devices tried to expose different pipelines for different use cases like a L2 pipeline or a L3 pipeline, but this was by far not the flexibility developers expected. In the end, this problem lead to the fact that every application needed to be written exactly with the specific hardware pipeline of the networking device in mind, and by that vendor independent network control software was only possible against the lowest common denominator.

In contrast to openflow, SAI was created in a bottom to top fashion. Data centers provided an environment that was hard to tackle as the scale exceeded the capabilities of existing protocols and devices, like mac address tables or number of different VLAN tags, in particular with an increasing need of east-west bandwidth. This use case was important enough to look for a way of solving the problem with a new approach to networking in a DC environment. The engineering teams that developed SAI started from their specific use case, and discussed the problems encountered with the chip vendors to understand the capabilities of current chipsets, and designed their solution around those capabilities.

Emphasis was placed on managing network devices at scale through use of common toolsets and components that were already proven in managing the other parts of the DC infrastructure. In addition, the DC market itself was big enough to motivate chipset and device vendors to produce production quality implementation of the SAI APIs on their equipment.

This use case based approach lead to a very fast development of production grade implementations, and SAI, for example with SONiC on top, is used effectively in large Datacenters, for example Microsoft's Azure Cloud. This success in production use fosters ongoing development based on this approach.

As a conclusion, while openflow offers fine grained forwarding control, this flexibility was not required by many use cases, yet the cost for achieving this flexibility in silicon is higher than conventional approaches. In a way, one could say openflow is a solution in search of a problem that justifies the economic investment, or that it was just ahead of its time. The bottom up design centered on current hardware capabilities should allow SAI to succeed in providing a open yet supportable and economical approach for the intended use cases.