The project was a joint effort between ONOS, the ONF, Broadcom, and Edgecore.
The architecture, using OpenFlow 1.3 on bare metal switches, is a kindred spirit to the Open Compute Project and to the growing ecosystem of white box switching. The goal is to provide an alternative to proprietary networking by letting customers mix-and-match elements such as switch hardware and network operating systems.
Plenty of vendors are working on open-source pieces such as the operating system. Coming up with an entire network architecture that’s open source is a less obvious step, especially since the leaf-spine architecture is so well known.
One reason to do it was to show that a fabric can be built from open networking components — that is, relying on no one vendor for a full combination of hardware and software. But the project was also a proving ground for software-defined networking (SDN).
“We wanted to use classic SDN — OpenFlow-based SDN. But OpenFlow-based SDN has been plagued in the past few years by a number of challenges, both in control-plane scale and data-plane scale,” Das says.
On the data-plane side, OpenFlow 1.0 has limited use on one memory table in a switch chip, hindering its ability to scale. OpenFlow 1.3 corrected that, but vendors didn’t put 100 percent effort behind supporting the protocol, Das says.
“Under the hood, they’re still controlling just one table, just like in OpenFlow 1.0,” he says. The use of Broadcom’s OpenFlow Data Plane Abstraction (OF-DPA) amends that problem and “gives us the ability to use all of the switching chip,” Das says.
OpenFlow’s control-plane issue was a perception that every packet has to go through an OpenFlow controller, an extra step within the network that could pulverize performance. But that’s not a requirement in OpenFlow, Das says.
The ONOS architecture sends only control-plane packets through the controller. Moreover, multiple controllers can be shared among multiple switches, which should ease any problems if a controller goes down or experiences network congestion, Das says.
The ONOS team has another reason for wanting to develop this leaf-spine architecture. They believe it’s got a tailor-made use case: the Central Office Reimagined as a Data Center (CORD).
CORD has become ONOS’ frontline project, and the group has even spun versions tailored for mobile networks (M-CORD) and enterprises (E-CORD). ONOS sees the open source leaf-spine architecture as a good underlay network for CORD implementations.
The architecture uses Layer 2 networking to communicate within a rack and, for reasons of scale, Layer 3 IP/MPLS between racks. The Layer 3 implementation is based on Quagga, the open source routing stack.