Is OpenFlow a failure?

The early days of OpenFlow

OpenFlow originates from Stanford University. Martin Casado’s Ethane[1] PhD work was one of the concepts that lay at the base of OpenFlow. Ethane sought a better way to deal with security by having fine-grain flow-based security policies. A centralised controller managed these policies. OpenFlow was proposed in a paper[2] published in April 2008. The idea presented was a way for network researchers to experiment at line-rate on heterogeneous switches and in real-world traffic settings.

OpenFlow has been implemented by various Ethernet switch vendors. They added OpenFlow capability to their normal Ethernet switches. Besides these established network vendors, startups like Pica8 entered a new market of “pure” OpenFlow switches. Pica8 was soon followed by NoviFlow, Corsa and others.

Rise of the controllers

An important concept in OpenFlow is the separation of data plane and control plane. The data plane is just forwarding packets and this is the only thing an OpenFlow switch is doing. The control plane takes care of the high-level forwarding decisions. In an OpenFlow environment the control plane function is performed by a controller running on a separate server. Over the years, many (open source) controllers have been developed (NOX, POX, Trema, Beacon, Floodlight, Ryu, etc).

In 2013 the OpenDaylight project was announced, soon followed by ONOS. These are large multi-party open source community projects and are more than “just OpenFlow”. The term Software Defined Networking (SDN) was introduced to describe these architectures that went beyond OpenFlow. Today several vendors are selling commercial SDN products based on these open source projects. Others came with alternative SDN architectures and suddenly everyone was doing “SDN”. SDN has become a meaningless acronym these days when it is not accompanied by an explanation of what it means in each specific case.

Network disaggregation

OpenFlow also started discussion about how to architect and run networks. Nick McKeown, co-author of both papers mentioned above, gave a nice presentation in 2011 about the concepts and ideas behind OpenFlow. He compared computing with networking and showed the benefits of disaggregation in computing. The closed proprietary mainframe was replaced by open hardware and APIs that resulted in rapid innovation and a huge new industry (see figure 1). The goal was to disaggregate in networking too (see figure 2) by separating the hardware (switches) from the software (firmware driving the switch) and open APIs between them.

So where are we a decade after OpenFlow was proposed? The concepts of separating the data and control plane, best of breed and open APIs has indeed taken place and they have started a completely new market in networking: white label switches. A white label switch is a switch that can be loaded with third party firmware. So you can buy a switch from vendor A and the firmware from vendor B and choose the best of breed. There are several companies that sell these switches and they are focusing on just selling the hardware. Others are focusing on the software to run on those switches. This is often called network disaggregation, the separation of hardware and firmware.

White label switch vendors include Accton/EdgeCore, Dell, DNI/Agema,Interface Masters, Mellanox, Quanta, etc. Firmware to run on these switches comes from commercial companies like Culumus, IP Infusion, Pica8, etc and from open source projects like FBOSS, Open Network Linux, OpenSwitch, SONiC, etc.

Programmable data planes

With OpenFlow it is possible to update forwarding tables directly with a large amount of flexibility, while in traditional routers and switches the forwarding tables are populated by routing and switching protocols. The forwarding entries are therefore restricted by these protocols, e.g. a router forwards based on destination IP address, a switch forwards on destination MAC address. But in OpenFlow, forwarding can be done on any combination of fields in the packet.

However, even in OpenFlow switches there is still the restriction of fixed function ASICs. This restricts the fields in the packet that can be used by OpenFlow. These ASICs are built to handle a couple of well-known protocols and nothing else. A new protocol usually requires a new ASIC, which takes many years to develop. This is why there is an increasing interest in programmable chips and programmable data planes in recent years. These chips can be reprogrammed to support new protocols. FPGAs and NPUs are well-known examples and are used by several vendors. But new programmable Silicon, like the Cavium XPliant, the Barefoot Tofino, the Innovium Teralynx, etc, have hit the market. The Tofino chip can be programmed with P4, a domain-specific language for network protocols[3]. OpenFlow gave access to the forwarding table. P4 is doing that too, but it also lets you define the packet parser. In that way a P4 capable switch can handle a new protocol by just defining a parser for it in P4. P4 will be a subject of a future blog.

Conclusion

In recent years we have seen the rise of a new market in networking based on white label switches. This market follows the concept of separating hardware and software. Some companies are specialising on the hardware, others on the software.

The OpenDaylight and ONOS community projects have dozens of members and hundreds of developers. They follow the OpenFlow concept of logically centralised controllers.

Finally we are seeing a new market of programmable Silicon for the forwarding plane. Several startups have entered this market, but the established vendors are going in this direction too. Many believe that the days of fixed function ASICs are over.

And all of this started with OpenFlow. Not bad for a failure.

References:

[1] Martin Casado, Michael J. Freedman, Justin Pettit, Jianying   Luo, Nick McKeown, and Scott Shenker. 2007. Ethane: taking control of the enterprise. SIGCOMM Comput. Commun. Rev. 37, 4 (August 2007),   1-12.

[2] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar,  Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner.   2008. OpenFlow: enabling innovation in campus networks. SIGCOMM,  Comput. Commun. Rev. 38, 2 (March 2008), 69-74.

[3] Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown,  Jennifer Rexford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George  Varghese, and David Walker. 2014. P4: programming protocol-independent  packet processors. SIGCOMM Comput. Commun. Rev. 44, 3 (July 2014),  87-95.

More information

The SURFnet-testbed is a platform set up by SURFnet for experimenting with concepts such as software-defined networking (SDN). ICT specialists, network administrators and researchers can use the platform to test equipment and try out and evaluate various ideas and concepts.