I'm here in Las Vegas at Interop 2012, just finishing my day "0" (the show floor hasn't even officially opened yet). I've already listened to half-a-day's worth of talks/workshops about Software-Defined Networking, OpenFlow, and real-world, production use cases from a variety of companies (including ours!).
It's exciting to see how far Software-Defined Networking (SDN) and OpenFlow have come. Last year, I blogged about Interop as OpenFlow's coming out party, and the momentum behind them has just kept building over the past 12 months.
This year, Big Switch Networks is Big again at the Interopnet Lab, and you can see us in at least 15 partner demos across 5 different booths!
Why SDN and OpenFlow Now?
As the speakers got up and defined what SDN meant to them, we heard a consistent theme: a lot of the concepts around centralized control have been around for a while, especially when you look at the circuit-based networks - we're just taking them to a whole new level with OpenFlow and SDN. So a natural follow-on question was, "What has changed such that we're now embracing SDN so strongly?" Kyle Forster, Alvaro Retana from HP, and Ken Gray from Juniper were on a panel talking about different use cases of OpenFlow, and during the Q&A session, they tackled this question directly.
My takeaway from that panel and the other speakers is that we've arrived here at this point in the industry because of the openness of software-defined networking. Many of the components of SDN already existed as the audience pointed out, but it is the openness of the movement that has allowed the broad base of companies to be engaged, so much so that pretty much every major company making L2/L3 devices now has discussed Software-Defined Networking/OpenFlow and their plans for it (if they're not already in GA).
What are some of the components of SDN architectures/solutions that were already in place? Centralized control has been rolled out in various flavor over the last 15 years in packet-switched networks, including decoupled control/data plane. Computing/software clusters have taken off over the last decade. Merchant silicon is by no means new (it's not a prerequisite for SDN or OpenFlow, but it's often cited as part of the broadening and leveling in the networking industry).
My colleague Isabelle Guis blogged about Open SDN a couple of months ago, but I want to review it as a way to frame the answer to, "Why SDN now?"
It's about Being Open!
Even with all that came before, SDN as we are seeing it now still hadn't arrived. So what's different? It's about being open! We already see the industry support from companies such as Arista, Brocade, Dell, Extreme, and Juniper for the openness in SDN.
Open Standards: SDN started with the open creation and standardization of a new control-layer API, OpenFlow. OpenFlow's openness and standardization encouraged all the major network vendors to evaluate it, participate in its creation and evolution, and support it in their hardware. Put another way, there are some networking companies with control-layer APIs, but we haven't really seen (nor would we expect) an entire ecosystem of competitive companies rallying around those proprietary APIs. This standard, with support for it in merchant silicon, allowed Google to do what it did over the last 2 years: run arguably the Biggest Network in the world with OpenFlow.
Open APIs: The northbound APIs exposed on top of the control plane of an SDN are what really enable the rapid feature velocity and easy integrations that we're used to seeing in other parts of the software world. Big Switch, Google, and other companies have developed solutions to extremely difficult problems by writing software on top of these APIs.
Open Source: All the early work in OpenFlow generated open source controllers, switches, test suites, and even more layers of software around those (e.g., FlowVisor). We're actively supporting this with our open source controller, Floodlight (over 4000 downloads to date with a number of partner companies in the ecosystem building around it), as well as other SDN/OpenFlow projects that our engineers support (FlowVisor, Indigo). Floodlight is available for download at floodlight.openflowhub.org, and the whole Interopnet Lab is going through FlowVisor again this year (yeah Rob Sherwood and Nick Bastin!), so swing by the lab and check it out.
More Momentum around Being Open and Interoperable
Retaining this sense of openness is important in SDN and OpenFlow as it evolves. As Kyle Forster said, "Taking technologies that are five or six years old and calling them SDN is 'SDN-washing' and will only stifle innovation." It will be difficult to avoiding this "SDN-washing" as more and more companies try to explain their relationship to SDN. Still, that's a challenge that we as leaders in the space have to address.
Indeed, we already see this leadership with some recent work from IBM, particularly aimed at the next generation of data centers. That market is facing huge challenges around scale, speed, and efficiency, mostly resulting from near-ubiquitous adoption of server virtualization in those environments. We're happy to be working with IBM on this and endorse their initiative on how we can achieve an Open Data Center Interoperable Network (ODIN). This work (described in their recently released technical briefs) is a great example of how we need to maintain openness and interoperability in the next generation networks.
Openness and Interoperability - what better way to officially start "Interop" 2012? We'll see you on the show floor!