Following the fifth Open Compute Summit earlier this year, a lot of people in the community are excited about the recent progress in the OCP networking project. At the conference, we held a keynote panel, moderated by Facebook’s Najam Ahmad, discussing how to open up network hardware.
We also had nearly 100 people participate during the OCP engineering workshop sessions, with significant hardware and software developments discussed by Mellanox, Broadcom, Cumulus, and Big Switch.
In this post, I’ll cover some of the highlights from the OCP workshop. But first, for those of you who might be new to OCP or to the networking project, I wanted to provide a little background.
Background & Motivation
We started the OCP networking project about ten months ago. In the project’s charter, you can see the essence of its mission (my emphasis):
create a set of networking technologies that are disaggregated and fully open, allowing for rapid innovation in the network space
Here’s how we view each of those key tenets:
- "Disaggregated": In traditional networking, we buy an appliance from a vendor, and that box comes with the software from that same vendor. One of the first goals of the networking project has been to break that apart – to separate the network hardware from the network software – so consumers aren’t locked in to a single solution from a single vendor.
- "Fully open": This too is rare in the networking world, but we are sowing the seeds of change here. At the hardware level, the designs of the vast majority of devices are closed, but we at least see merchant silicon being leveraged by many companies. At the software level, we see APIs on top of network devices that allow some level of automation, and these sometimes are "open." However, they don't give a low level of access to the underlying forwarding hardware – say, at the ASIC SDK level. Within the project, we are emphasizing the need for publishing the design of working switch hardware as well as opening up software APIs at the network ASIC level.
- "Rapid Innovation": We believe that, by disaggregating the network hardware and software and by being fully open, we can create an ecosystem of rapid innovation, where best-of-breed software can be written for specific deployment use cases that can fully utilize the open switch hardware.
Recent Highlights: Working Switches, Working Code
The OCP networking project’s initial focus has been in the datacenter, at the top-of-rack (TOR) switch. Many vendors are already leveraging merchant silicon for their TOR switches, and on the operator side, it's an easy place to try out a new hardware switch, as the failure domain is mostly limited to the servers in the rack.
At the recent OCP Summit and the networking engineering workshop, we had some significant progress both in hardware and software for the TOR switch:
- Switch specifications and hardware: Mellanox published the specification for its SwitchX-2 TOR switch as part of the project and showed a spine switch with 36 40GbE QSFP as part of the project.
This joins the specification that Broadcom published late last year for its OCP network switch, and a switch based on the Broadcom spec that is already available from Interface Masters.
The review committee of the project is excited to submit these specifications to the OCP incubation process as the next step.
- Foundational software: Cumulus demoed for the first time their Open Network Install Environment (ONIE) running on an x86-based Interface Masters OCP switch, and that solution is now available for the OCP switch.
Big Switch Networks announced they have contributed a Linux distribution, dubbed Open Network Linux, specifically to allow users to quickly get a Linux environment that has had all the kernel and driver mods to work with these open switches. It is not yet available for the Interface Masters OCP switch, but will be soon.
Forwarding Software for “Software-Agnostic” Switches
The OCP networking project initially started discussing designs for switches, and progressively we have been moving up into the software for that hardware. The contributions from Cumulus and Big Switch provide a software foundation, but in order for the OCP switch to actually forward packets, we still need forwarding software on top of the hardware switch itself. That brings up more questions that we want to work as a community to answer:
- “What will the forwarding software need to handle?” The forwarding software needs to handle traffic from the connected hosts, including control traffic (e.g., ARP, DHCP, and DNS) and the hosts’ actual data traffic. It also needs to be able to interact with the control plane of the surrounding network (e.g., an L2 environment of VLANs and spanning trees, an MPLS-based network, or an L3 routed network) as well as forward data traffic to/from the rest of the network.
- “Where will it come from?” One of our key design goals in the OCP networking project is that the switches should be “software-agnostic.”
For example, the hardware should support forwarding software that is based on either a traditional distributed networking protocol stack or a more “SDN”/centralized model with OpenFlow. Another example is that the hardware should support either open source forwarding software or commercial forwarding software.
Indeed, we envision being able to run many network software packages at once, just like you can run different applications on your servers.
If you're interested in following the activities of the OCP networking project, please check out http://www.opencompute.org/projects/networking -- we'd love to have your help in opening up the network layer.