For more details, please see ourCookie Policy.


Two OpenFlow Camps

by Curt.Beckmann on ‎01-15-2013 12:20 PM - last edited on ‎10-28-2013 09:43 PM by bcm1 (1,457 Views)

Software-Defined Networking (SDN) is commonly considered to be a revolution in the networking industry.  Revolutions are about upending the status quo, and successful revolutions often require change agents of different stripes to join forces toward disrupting the existing hegemony.  Earnest rebel leaders present a unified front lest vested interests spot a weakness to exploit.  Only when change is underway do differences begin to emerge.  The SDN version of this has been quietly playing out recently.


Stepping back, the SDN revolution is about decoupling the network’s control plane from its data plane, so that innovative 3rd party algorithms can be rapidly and independently developed and productized in a competitive market.  Such a decoupling would foster a nicely layered network architecture, similar to the nicely layered compute stack that has allowed parallel innovation for years.  Customers could combine best-of-breed applications with their choice of compute engine with high confidence in interoperability and moderate vendor lock-in.  The arguments were persuasive enough to trigger a remarkable customer-led event in the marketplace, namely the launch of the ONF in early 2011.  In the months and years since then, what differences, if any, have emerged among the revolutionaries?  Should we anticipate a painful SDN Balkanization phase, or will the two camps be able to coexist in harmony?



Much of the attention given SDN has focused on innovation on the control side.  So is data plane innovation no longer needed? In the view of many, the data plane could largely be fixed. This OpenFlow whitepaper says “For high-performance and low-cost the datapath must have a carefully prescribed degree of flexibility. This means forgoing the ability to specify arbitrary handling of each packet and seeking a more limited, but still useful, range of actions.”  In addition, early instances of the “programmable network” were based on controllers speaking OpenFlow to fixed-function boxes from HP, NEC and others. Dr Scott Shenker, an OpenFlow pioneer and Nicira co-founder, said this about SDN:


"This approach doesn't let you do anything you couldn't do on a network before," Shenker says. "[But] it gives you a programmatic interface --- it lets you program what you want to have happen in the network, how you want to route packets, how you want to do load balancing, how you want to do access control. So it's really that generality that drove us."




That says tweaking the data plane isn’t critical to SDN, and compelling innovations can be achieved in the control plane alone. Google’s homegrown OpenFlow production network (see Urs Hoelzle’s slides and video), based on commercially available “stable data plane” silicon, is a proof point of that approach.


But others insist that SDN not limit innovation to the control plane alone.  Multiple Flow Tables, which were introduced in OpenFlow 1.1, allow controllers to describe functionality that exceeds what existing fixed function hardware switch platforms can provide. Many, particularly those in research, call for a fully programmable data plane.  Meanwhile, the dominant SDN switch implementations are vSwitches embedded within hypervisors running on general purpose servers.  OpenVSwitch can happily support STT tunneling, functionality beyond readily available hardware devices.  Clearly network innovation has not excluded the data plane. 


Okay, so we see some disagreements between the “focus on the control plane” and the “programmable data plane” camps.  Is the movement in danger?  Not so much. Let’s consider the practical implications of the tensions. Which direction should the standards take?  Should we favor software?  Or hardware?  Will some new OpenFlow chip burst forth with a fully programmable data plane? How will the tensions impact customers? 


This is all less contentious than it may seem at a glance.  Fully flexible data planes are already available via software and NPUs, and many are open source.  Software doesn’t wait patiently for standards since a provider can build both sides of the equation (controllers and switches) and open source can work in lieu of a standard.  Lock-in is less problematic for open source software since the customers’ barrier to change is low, in part due to the low cost of software devices relative to equipment. But most buyers don’t want software to be “infinitely variable.”  Network operators responsible for mission critical applications running over production networks will occasionally need new functionality, and will bear some risk to get it, but clearly stability is also valued. It’s not obvious that the premium for full data plane flexibility will make sense in such networks.  On the other hand, research labs where rapid data plane innovation is important will justify the premium for highly flexible data planes.


In any case, hardware-based devices can also evolve, albeit more slowly than software.  IP forwarding was server-based before being accelerated in hardware; software-based data plane innovations will follow a similar path. Hardware involves higher CapEx, but typically offers lower cost-per-gigabit once functionality stabilizes.  In addition, hardware-based devices that support open (standardized) SDN interfaces will enable buyers to introduce control plane innovations at their discretion. Standards matter here since open source software can’t fully displace standards on hardware; silicon remains stubbornly closed with no de facto standard architecture, so a fully open source implementation isn’t feasible.




Here is where I expect consensus to shake out:

  • A rich SDN ecosystem needs a standard interface between controllers and hardware-based switches
  • Software and hardware data plane products will both play important roles in SDN
    • Soft SDN switches, such as OVS, will evolve ahead of – and  help to advance – standards
    • Control plane innovations (à la Google) makes SDN-enabled existing hardware attractive
  • Standards efforts should define interfaces to encourage SDN-enabled products from hardware vendors
  • Standards efforts should seek to integrate any market-winning SDN data plane features (such as STT)
    • That’s because such features would be expected to appear in new silicon in short order


In short, I anticipate a “Big Tent of SDN”.  There’s plenty of fodder here for commentary and future posts. Stir things up!  Tell us what you think, and we’ll respond.

(Image credits: and