In real estate, when it is time to sell a house with an unfinished basement, or a kitchen that is falling apart, one uses the term “ready for your creative design”. It is a method for turning a negative into a positive. There is a curious similarity to this positioning within the SDN marketplace. An OpenFlow 1.x SDN solution cannot do mac learning, or arp responses, but our middleware is ready for you to take charge of your control plane! Who is better than you, the operator to define how you want your packet forwarding to work.
Unfortunately, the spin doesn’t work to sell houses, and after many years of promoting SDN, it reflects one of the key fallacies in the SDN argument. Brutal minimalism in the definition of the data plane functionality is a guiding principle of OpenFlow. All networking functions can be expressed as “matching on a packet header” and “taking some action to either modify or forward the packet”. The rest is an exercise for the user. As vendors we provide you the operator with 20% of the solution, you do 80% of work necessary to have a working product.
For the one operator that sees an opportunity for a fixer upper networking project, nine walk away, looking for a finished basement that they can purchase and make operational. Whilst the relatively simple purist view was convenient when SDN was launched seven or more years ago, enough time has passed that we need to examine how we can provide operators control over their data plane, without having to hire a large team of programmers to build a learning bridge, or a router from scratch.
The key to this lies in the level of abstraction exposed to network programmers. The following picture illustrates the levels that are being worked on, in the industry and the role of each.
Early in the SDN dialogue, Cisco defined SDN as the use of its Application Centric Infrastructure. This was widely rejected by the SDN revolution, as it was argued that ACI was not true to the principles of SDN. It did not provide an unfinished basement that operators could build their house upon. Instead, it provided a Cisco designed top to bottom infrastructure that went from Cisco hardware data planes to Cisco designed middleware on which to build path computation and policy engines.
Wouldn’t it be ironic if we discovered in hindsight that getting network operators to build soup to nuts control plane software would be a limiting factor in the deployment of SDN?
At Corsa, we have built cutting-edge OpenFlow data planes. We implement the complete OpenFlow specification, we do multi-table OpenFlow at full line rate on 100G interfaces, we provide deep classification memories, deep packet buffers and programmable fabrics. We offer the whole nine yards in order to have a great foundation to build your creative networking solution upon. So it is with mixed pride that we say, we are beloved amongst those who like fixer upper DIY networking, and scary to those who want to buy some equipment and make their network run.
With the benefit of this learning experience what’s next?
The key element of the 20 percent solution is that we need to reverse the equation. Operators need to be handed 80 percent of the solution, and they should have to do 20 percent of the work to make it their own. Using either open source or vendor supplied code, a programmable solution needs to be assembled that is within reach for them to work with. This is the only path that will lead to wide deployment of SDN.
A number of possible solutions are emerging in the marketplace, based on the layers of abstraction sketched out in the picture above. Let us start at the bottom and work our way up.
P4 is the lowest and most generic level of abstraction. Corsa has been an early contributor to P4 and its counterpart PIF within the open networking foundation. Recognizing the need to bridge the gap to finished solutions, the P4 community is building P4 libraries of code that work their way up the stack of abstractions. Concepts like ECMP, mac learning, mols label switching are all captured in P4 libraries that can be reused. All of a sudden operators are taken up a few levels of abstraction to what we would consider the SAI / SDK or Switch OS level. The only element “left for their creative input” is the network-wide control plane or Network OS.
Switch Abstraction Interface is a standard that comes from the OCP project, and the OCP isn’t necessarily trying to address SDN limitations. It is trying to make sure that data center switches are friendly to Dev Ops. Dev Ops vs. SDN what’s the difference? Dev Ops is a term that comes from data center operators. It captures the notion that in sufficiently large data centers it is best to hire a dozen to a few hundred network programmers in order to program and optimize the provisioning and maintenance of their switches and hardware. NOT the low-level forwarding behavior. At this point, we are talking about a finished house with drywall, with the operator doing their own painting and finishing. It works for many, and leaves out the few who want something more turnkey. It takes us from 80/20 to something closer to 50/50.
Open Networking Linux, Cumulus, and HP’s new OpenSwitch effort. At Corsa we have long recognized the need for a Switch OS for our own products. Like many of these efforts we build ours using Ubuntu as the open source base platform, upon which we build the switch, and networking related feature extensions.
Network Operating Systems
ONOS is the best open source project that fits this category. Open Daylight does not claim this space directly, but rather provides a platform that can serve in the role of a Network OS. In our experience, this is a level where the 80 / 20 solution really needs to hand off responsibility to operators. All of Corsa’s major customers have over the years developed their in-house Network Operating Systems. This was done at a time when the term Network OS hadn’t been conceived. But the fundamentals are already in place, in terms of network topology management, network element provisioning, path computation etc.
Clearly there are a lot of independent efforts to solve various layers of the 80/20 problem. It is encouraging to see a diverse set of players in the industry self-organize, in order to build the different pieces as we all together learn from our past experience. At Corsa, we are keen to hear constructive thoughts on how these pieces should fit together. We welcome healthy debate and whether we agree or not, we are a company that listens.