Throughout much of last year, Scott Shenker delivered a presentation that is considered a seminal touchstone in software-defined networking. The presentation is called “The Future of Networking, and the Past of Protocols,” and an early version of it can be viewed here, though later iterations also are available online.
Shenker is a co-founder and chief scientist at Nicira Networks. He also is holds the title of Professor of Electrical Engineering and Computer Science at the University of California, Berkeley. Along with Nick McKeown and Martin Casado — the other co-founders of Nicira — he is widely regarded as a thought leader in the SDN community. (There are SDN intellectual luminaries beyond Nicira’s walls, but it’s notable that these three have combined their talents under one corporate roof.)
Technology is Easy, People Are Hard
In this post, I want to summarize a few salient thoughts featured in Shenker’s presentation. I will refer to these ideas in subsequent posts (well, at least one, anyway) that explore the commercial potential and the cultural challenges SDN might face in an enterprise world, where — pardon the paraphrasing of the legendary showbiz quote attributed to Donald Wolfit — technology is easy, but people are hard. (Nicira probably knows as much, which is why it is targeting cloud service providers rather than enterprises, at least for now.)
In his presentation, Shenker starts with an academic paradox based on his experiences as a professor at UC Berkeley. He says his colleagues who teach operating systems or databases provide instruction on fundamental principles, such as synchronization and mutual exclusion. Conversely, when he teaches introductory networking, he teaches his students about a “bag of protocols.” There are no real principles in networking, he argues.
Beyond academia, in the realm of the practical and quotidian, Shenker notes that computation and storage have been virtualized and have become flexible and easy to manage, but “not so much with networks,” where protocol complexity reigns.
Masters of Complexity
He then asks why the intellectual foundations of networking are so weak, and wonders how those foundations can be made stronger. Shenker explains that networks were simple and easy to mange initially, starting off with straightforward Ethernet and IP designs. New control requirements resulted in complexity. He says ACLs, VLANs, traffic engineering, middleboxes, and deep packet inspection have complicated what was an elegant architectural design.
Network infrastructure still works, Shenker says, because the networking industry and its professionals are masters of complexity. Unfortunately, the ability to master complexity is a mixed blessing. Complex systems typically are built on weak foundations. The systems are complex because the foundations are weak, and the networking industry has become adept at treating the symptoms rather than curing the disease.
He points out that good user interfaces are not produced by masters of complexity, noting that the ability to master complexity is very different from the ability to extract simplicity. (He tells an amusing anecdote on this theme hearkening back to his time at Xerox PARC.) Moreover, when one masters complexity, one has to do it for every single problem. When you extract simplicity, the benefits last longer and can be applied more broadly.
Bad Design
Shenker examines how computer programming was simplified over time. He looks at how useful abstractions were defined and evolved to extract simplicity and make programming tasks easier. Abstractions shield users from low-level details.
While abstraction has been at the center of much work in computer science, Shenker explains that has not been true in networking. He says abstractions have been addressed in layers that provide data-plane service abstractions, as exemplified by IP’s best-effort delivery and TCP’s reliable byte stream. These abstractions convey ideas about what the network can do for us, but Shenker says they’re terrible interfaces because they violate the principle of modularity. It works, he says, but it’s based on bad system-design decisions.
At the control-plane, where useful abstractions do not exist, Shenker says SDN’s goal is to break the bad habit of adding to network complexity. Networking addresses control issues today by defining new protocols, such as for routing, or by designing a new ad-hoc mechanism, such as for traffic engineering; or it leaves the problem to be addressed by manual operator configuration, as is done with access control and middleboxes.
He then looks at how such modular abstractions can be applied to network controls. It’s all about applying abstractions to simplify control tasks relating to forwarding models, distributed state, and detailed configuration.
In SDN, the forwarding model shields the above layers from the particular low-level forwarding design, which could involve possibilities such as a general x86 program, MPLS, or OpenFlow.
OpenFlow: Good Enough for Now
On OpenFlow, Shenker later in his presentation offers the following:
“OpenFlow is one possible solution (as a configuration mechanism); it’s clearly not the right solution. I mean, it’s a very good solution for now, but there’s nothing that says this is fundamentally the right answer. Think of Open Flow as x86 instruction set. Is the x86 instruction set correct? Is it the right answer? No, It’s good enough for what we use it for. So why bother changing it? That’s what Open Flow is. It’s the instruction set we happen to use, but let’s not get hung up on it.”
As for state distribution, Shenker said the control program should not have to deal with the vagaries of distributed state. An abstraction should shield the control program from sate dissemination/collection. A network operating system can provide that abstraction, delivering a global view of the underlying network.
The control program will operate on this network view, which is essentially a graph, providing input on required device configuration across the network.
Three Basic Interfaces
In Shenker’s view, there are three basic network interfaces tied to SDN abstractions. There’s the forwarding interface, which provides a flexible, abstract forwarding model; there’s the global network view, which shields higher layers from state dissemination/collection; and there is the abstract network view, which shields the control program from details of the physical network.
He points out that these abstractions “are not just academic playthings.” They change where we focus our attention and thus enable much greater functionality from less effort. As a result, there will be no more need to design distributed control protocols. Instead, you would define control programs (applications) over an abstract model. Writing control programs becomes about what you want to have happen, not how to make it happen.
Cultural Factors
Bringing the presentation full circle, and reconciling it neatly with its title, Shenker contends that the future of networking lies in cleaner abstractions, not in the ongoing definition of complicated distributed protocols. As Shenker puts it, “the era of ‘a new protocol per problem’ is over.”
Networking definitely seems to be heading in the direction Shenker envisages, but I’m not sure the old networking establishment is prepared to bury its “bag of protocols” just yet. As Shenker himself has said, it takes years to internalize and evaluate abstractions. It might take longer for networking professionals — vendors and customers alike — to adjust to software-oriented network programmability.
Twilight in the Valley of the Nerds 
> there’s the global network view, which shields higher layers from state dissemination/collection; and there is the abstract network view, which shields the control program from details of the physical network.
What would *these* happen to be? It isn’t a straight-forward answer – OF controller needs to (a) get to the devices it controls; and (b) be aware of state changes in the underlying physical infrastructure (devices / links going up / down / somehow else faulty).
That last point, is actually very interesting: if a link between two nodes in OF-controlled network goes “unstable” and starts, for example, to corrupt data, how would the OF controller know that it needs to do something about it?
How would a network corrupt data? Data-plane data?
Bad cables, defective ports. The answer to my original question is, of course, quite clear at this point: OF has no role in framing, which is done “the good old way”, so any broken frames will be caught there.
I thought the whole idea of OSI 7 layer model offered this abstraction. Each layer was well defined and shielded complexity from each other. Now, you have a situation in SDN where you have further abstraction over abstraction. Another stack in the layer 2/3/4 area.
I’d advise you to review the presentation again, if you haven’t’ done so already. Shenker says our networking abstractions effectively convey ideas about what the network does for us, but he says they’re terrible interfaces because they violate the principle of modularity. He says the network can be (and is) made to work, but poor design interfaces have resulted in growing complexity and a morass of protocols.
In my view, he isn’t talking about complicating or adding anything new to the OSI stack with which we’ve all become familiar. Instead, he’s taking about how to provide interfaces that will make the network programmable. Like he says, the idea is to extract simplicity.
See the slides at http://opennetsummit.org/talks/shenker-tue.pdf.
Brad
If I understand correctly, beneath the pile of marketing talk by the Nicira people (who promise everything and its opposite), SDN is controlling all the devices of the network from a single point.
It has its advantages, but it’s certainly not suitable for the Internet. The entire point of the Internet is to work with different organizations, sometimes competitors, sometimes untrustful. There is no way a SDN-like system may work at the scale of the Internet. For me, SDN is only a possible solution for local networks, for instance inside Google’s datacenters (but not for the network between Google and its clients).
Trying to run SDN on the global Internet would create interesting security problems if someone tries to reprogram my switches and routers…
Also, his entire part about “network operating system” and “higher level abstractions” for network programming reminds me of my years as a student when the latest fad was to hide the network from the programmer, in the same way that Fortran succeeded in hiding the local hardware. It fails because, as we learned at this time, the network is not easy to hide. To take an example, latency is small and bounded inside a machine but extremely high and unbounded on the Internet. The RPC model of network programming failed for that. Nothing has been learned, it seems.