SDN and the Alignment of Planets
We’ve been involved in some exciting moments as we’ve watched the networking landscape over the last forty-or-so years. It’s often only with hindsight that we can see where the important inflection points were. Sometimes we look back and think that the outcome was inevitable, but at the time, many different outcomes seemed possible. SDN strikes me as a technology that might have easily failed to launch, and certainly I wouldn’t have predicted the path that it has taken. This week we’re looking at how SDN made the jump from science experiment to mainstream technology.
The roots of Software Defined Networking (SDN) go back a long way, but I can clearly remember the point at which I decided that it was time to start paying attention to the emerging technology. In August 2009 I was attending the SIGCOMM annual conference, and I had a lot going on because I had become chair of SIGCOMM just a couple of months earlier. Preparing your first community feedback session as SIG chair is a lot harder than you might think! But I did manage to listen to most of the talks and, more importantly from the SDN perspective, spent plenty of time at the poster and demo sessions. I remember walking out of the demo area thinking that the SDN group from Stanford, with three demos and a huge array of equipment, was on the verge of taking over the event. I resolved to take a closer look at SDN and OpenFlow when I returned to the office. For context, the term SDN had been coined in MIT Technology Review just six months earlier, while the OpenFlow “manifesto” had appeared in SIGCOMM’s newsletter the previous year.
Interestingly, there was also a lot of talk about network virtualization at that conference. There was a workshop on the topic and the VL2 paper, which I often cite as an early example of network virtualization for the data center, was presented there. But at that point the connection between SDN and network virtualization was not clear to me (although, as I learned later, it was already clear to my future colleagues at Nicira).
I spent the next two years following the development of SDN. At this point I had been at Cisco for 14 years, and I wanted to figure out what the implications of SDN were for the networking industry. One mistake that I made (and I think I had plenty of company) was conflating OpenFlow and SDN. Of course SDN was much bigger than OpenFlow, which was just a piece of low-level mechanism, but it was easy for traditional networking people like me to get their heads around a protocol. And it was easy to criticize OpenFlow. The need to query a central controller whenever a new flow arrived combined two ideas that were “known” to be bad in networking: centralized control, and “reactive” installation of forwarding state. The problem of the reactive approach is that forwarding performance is sensitive to flow arrival patterns, and hence unpredictable. I’d seen enough customer complaints about earlier router implementations whose performance was traffic-dependent to know that this aspect was unlikely to fly. (We carefully avoided such an approach when creating Tag Switching and MPLS.) Centralized control–well, anyone who grew up learning Internet architecture in the 1980s and 1990s, and witnessed the success of the Internet's growth into the 2000s, knew that a fully distributed architecture was the only way to go.
To top it off, OpenFlow looked too much like other ideas we had seen before that hadn’t taken off. The idea of creating an open interface between the forwarding and control planes had been tried before, e.g., by Ipsilon with GSMP and by the Forces (Forwarding and Control Element Separation) working group of the IETF. It was easy to see the theoretical advantages of creating such an interface–particularly if you want to disrupt the networking industry, as it opens up the space for innovation on both sides of the interface. But the fact that it had been tried before without much success led many of us to think there was “nothing to see here” when we looked at OpenFlow.
In fact, as I wrote in an editorial for CCR for SIGCOMM’s fiftieth anniversary, it’s often worth taking a look at old ideas when they reappear, because the context might have changed enough to make them viable. I believe this is the case for both separating the control plane from the forwarding plane, and for the use of centralized control in networks. As SDN pioneers McKeown, Casado and Shenker note in their 2019 retrospective “From Ethane to SDN and beyond”, factors that had changed by the time SDN emerged in the late 2000s included the rise of merchant switching silicon (Broadcom, Marvell, etc.) and the development of hyperscale data centers as a new market for networking, giving network operators the opportunity and resources to break free from traditional approaches. I would add that decades of distributed systems research and development had created the technologies to build logically centralized controllers for networks that were neither a scaling bottleneck nor a single point of failure. The viability of centralized control was something that few of us accepted in the traditional networking community, but it was essential to the rise of SDN.
Two further events in late 2011 made me start to appreciate the disruptive potential of SDN. One was the legendary talk by Scott Shenker “The Future of Networking, and the Past of Protocols” at the first Open Networking Summit. This was the talk that crystallized for me the fact that it was insufficient to simply separate forwarding from control: it was also necessary to provide logically centralized control, so that we could create better abstractions. That’s a computer scientist’s view of the world; you could also say we needed a way to specify intended network behavior at a higher level than individual router configurations. It was the combination of these two ideas–control plane separation, plus centralization–that provided SDN with its real power. Scott’s talk helped me to see that there was something transformative going on here, way beyond OpenFlow.
The second event was triggered by a “bad day at the office” which left me feeling a bit grumpy about Cisco. That evening, I had dinner with an old friend in the industry who suggested that I should chat with the folks at Nicira. Within a few hours I had an appointment with Martin Casado, who by this point, as CTO of Nicira, was fully committed to applying SDN principles to the problem of network virtualization. Network virtualization would prove to be the “killer app” that brought SDN to a broad market. Not many enterprises had the needs or expertise of a hyperscaler, but most of them needed a better way to build and manage networks for their virtual machines, and this was the problem that Nicira tackled head-on. This wasn’t just a matter of incrementally improving networks; it was solving a networking problem that had appeared insoluble with standard networking techniques. Within a couple of months I was off to work at Nicira. The rest, as they say, is history, with network virtualization turning into a billion-plus dollar business within a few years.
There is a lot more to the history of SDN than this of course. We’ve covered some of it in our book, and there is a good overview in this CCR article. SDN continues to evolve and find new applications. I think the technology trend of programmable switching hardware with tools like P4 to customize switch behavior has a long way to run. What I find interesting about this small slice of SDN history is how the shift from research project to “known bad ideas” to successful (and industry-changing) technology took place over a few short years. A whole lot of things had to go right for that to happen: the leverage of technologies from outside of networking; successful re-examination of ideas previously discarded; new players entering the networking business; and the identification of an important problem space where SDN could be incrementally deployed without the buy-in of the traditional networking industry. I’m glad I was able to be part of the SDN movement and I look forward to seeing what comes next.
Thanks to the numerous folks who responded to our call for bugfixes and issues in our TCP book. We’re asymptoting towards being able to offer the book via print-on-demand and ebook. There is a P4 workshop coming, and you can submit abstracts for short talks, tutorials, etc., here. 100% of the general chairs for this workshop in the last two years have been Systems Approach members.