Controller consolidation moves SDN closer to your network
We are still in early days of SDN with groups and vendors jockeying for position and dominance, and as such there are an abundance of controllers to choose from. SDN controllers fit into the following categories.
In fact, someone new to SDN could be overwhelmed by all of the choices.
However, upon further inspection, a trend is becoming evident in the SDN controller market — that of consolidation. While there are still many controllers in play, slowly but surely the market is seeing two key rallying points, both in the open source world. One is the Linux Foundation’s OpenDaylight Project. The other is ON.Lab’s Open Network Operating System.
This consolidation is an important step in the SDN world:
• Enterprise shops have been stymied by the variety of controllers out there. It’s hard to bet on an SDN controller this early in the game, especially when trying to build a new operational strategy around the platform. Consolidation means they can make a choice they can live with.
• Vendors interested in interoperability are also impacted by having too many controllers to contend with. But, with ODL and ONOS gaining broad acceptance, vendors can build a controller based on one with little risk it will become an orphan.
• Some SDN application developers have been in a “sit back and wait” mode, as it takes both time and money to support an application on a variety of controller platforms. As the industry settles on ODL and ONOS, application developers can release products for these platforms knowing they will work across the larger part of the user community.
This takes nothing away from the important contributions made by the many academic SDN controller projects. These efforts remain useful as proofs of concepts, or to try out new ideas. But they weren’t necessarily designed to work at scale or to handle every SDN use case that an enterprise or service provider might have.
In addition, vertically integrated controllers designed by a vendor to work within their own ecosystem are just that - part of a specific stack intended to work in a unified product line. These vendor-specific controllers are unlikely to ever go away, as they may forever be integral to certain vendor product offerings.
And that’s not a bad thing. There’s room in customer networks for more than one controller, depending on the problems being solved and the products used. However, it is interesting to see that part of the consolidation movement comes from vendors. A number of them are basing their controllers on open source projects, OpenDaylight in particular.
Let’s take a brief look at the two SDN controllers the market appears to be rallying around.
The OpenDaylight project formed in 2013 as a consortium of vendors working openly to create a modular SDN controller. The effort is truly open source, where anyone willing to contribute useful code, documentation, or ideas is welcome to participate in the process using the forums of IRC, publicly accessible meetings, wikis, and so on to drive the project ahead.
ODL has enjoyed a great deal of early success, seeing a growing roster of vendors joining the ranks to contribute code and get involved in the governance process. ODL recently celebrated its second birthday, marking several key achievements along the way, including:
Regarding the latter, while most agree that programmatically defining the nebulous idea of policy is necessary to move network configuration ahead, policy is fraught with challenge. Taking a policy idea and translating it into a specific task requires a complex layer of abstraction over network devices with differing capabilities. How best to express intent How best to abstract that intent When a policy is defined, should the required configuration steps to meet that policy be specifically expressed, or instead be implied, allowing the device to determine for itself how to meet the requirements
It’s a complex problem, but ODL is one of the major projects in the industry where policy discussions are happening. As a side note, OpenStack’s Congress project is another key open source project focused on policy. Cisco, too, has expressed its opinions on policy, submitting its OpFlex protocol to the open source community.
While some criticize ODL as involving “too many vendors and too few users,” the group has addressed the issue in part by creating an ODL Advisory Group. ODL’s Executive Director, Neela Jacques, describes the advisory group as, “a diverse group of the top thinkers, engineers and architects at leading financial, enterprise, telecom and cloud service providers.” The group will “provide guidance on roadmap, feature prioritization and use case development.” As with all ODL proceedings, Advisory Group calls happen out in the open for anyone to hear.
ODL has seen a steady stream of software updates, but release of only two major versions: Hydrogen in February 2014, and Helium in September 2014. The most current version is Helium-SR3 released in March 2015.
The project has momentum, new code is being developed and maintained, and a vast array of partners have committed support. But even more interesting is the fact that some vendors are using ODL as a base for their own controllers.
The Brocade Vyatta Controller, for example, is based on OpenDaylight. Brocade is contributing code back to the project that improves ODL. And Extreme Networks’ OneController is also based on ODL, and is seeing customer deployments in sites such as the Town of Enfield, Conn., and Mount Mary University.
Cisco’s Open SDN Controller is also based on OpenDaylight. The company has been a major contributor to the OpenDaylight project and is a Platinum level partner alongside Brocade, Citrix, Dell, Ericsson, HP, Intel and RedHat.
Two OpenDaylight-based controllers aimed at carriers include Ciena’s Multilayer WAN Controller and ContexNet from ConteXtream.
While surely there are others, these serve to illustrate the point that OpenDaylight is seeing adoption by significant portions of the industry. Both enterprise and service provider use cases are emerging.
OpenDaylight, however, is not the only open source SDN controller getting broad support. In recent months the ON.Lab Open Network Operating System (ONOS) project has seen significant interest and project growth. In a recent briefing with ON.Lab, it became clear that one of the key elements being addressed by ONOS is scale. While the scalability of SDN controllers is a concern for any network, it is a particular concern for service providers.
Why does controller scale matter A controller application running on a single x86 box is constrained by the capabilities of the local CPU, memory, bus architecture and storage I/O, among other things. The application can’t perform beyond whatever bottleneck it happens upon when tied to a single system. To scale an application designed to run on a single box, the box must be sized bigger. Practitioners know this implies a disruptive upgrade process. Moving an application to a bigger box is a challenge, even in the context of virtual computing.
Distributed computing systems tackle the scaling challenge by describing an architecture in which applications can run in a distributed fashion across multiple systems. Scaling the application means adding more systems, as opposed to upgrading an individual system.
ONOS was targeting the creation of an SDN controller that could handle up to 1M path setups per second, and as many as 6M network state operations per second. In other words, the ONOS controller needs to cope with defining a very large number of paths through the network as well as changes to that network. A single box architecture will not meet those needs, and thus ONOS has emerged with a distributed controller architecture.
That’s not to say that other SDN controller architectures ignore scaling requirements. Some SDN architectures handle load distribution problems by creating several SDN domains, and then federating them together. In this architecture, each domain is managed by an individual controller cluster, and controller clusters exchange data about each other’s domains to form a federation. This is not the distributed computing model, but is rather a series of centralized controllers communicating with one another about their individual domains.
ONOS controller architecture follows a true distributed computing model; the centralized controller operating system is distributed across several controller nodes. The difference might seem subtle, but is important. With ONOS, a single, distributed ONOS instance maintains a unified, global view of the network state.
ONOS also differentiates itself from ODL in that it is explicitly targeting service providers. While that doesn’t exclude enterprise users, many of whom have network architectures that look similar to service providers, ONOS has the global scale and ultra-high endpoint connection count of service providers in mind. ONOS also points out that it is involving end-users with vendors right at the start. This is a not-so-subtle jab at ODL, which has been criticized by some for being too vendor-driven.
While enterprise shops are unlikely to adopt ONOS, at least the way it looks today, the distributed controller architecture could be interesting. Enterprises that feel ODL is an SDN scale bottleneck may want to test ONOS in their environment to see if the architecture meets their expectations.
ONOS’s second release is called Blackbird, and has been available since March 2015. The third ONOS release, Cardinal, became available June 2, 2015. ONOS intends to release on a faster schedule than ODL (roughly every quarter), although the releases may not have as much new in them when compared to the amount of “new” that might be found in ODL major releases.
ONOS is seeing real-world use, including recently announced deployments in segments of Internet2. Key organizations involved in ONOS include AT&T, NTT Communications, SK Telecom, Ciena, Cisco, Ericsson, Fujitsu, Huawei, Intel, NEC, the Open Networking Foundation (the maintainers of OpenFlow), Infoblox, and several others.
Another interesting connection is the ONOS tie to the OPNFV project, which is creating a framework for Network Functions Virtualization for service providers. ON.Lab announced on May 8 the approval of a project to tie the OPNFV framework to ONOS. This is a timely connection to make, as OPNFV is also in its early stages. It seems likely that ONOS will map well into OPNFV constructs, resulting in a platform that some service providers will look to both for scale and function.
For network consumers, the consolidation of SDN controllers offers at least two key benefits.
Developers can begin writing SDN applications with confidence, knowing what controllers they can count on being around for the long haul. An application that runs on the open source distribution of ODL should also run on ODL-based controllers released by network vendors. That means writing ODL applications is a market worth entering.
That’s not to say there isn’t a future in writing applications for proprietary vendor controllers, such as Cisco’s APIC or HP’s VAN, but those vendor-specific controllers may represent smaller markets that will be harder for application developers to capitalize on. With ODL especially seeing decent market penetration even at this early stage, network consumers should begin to see more applications come available over time.
As the industry works to determine what, exactly, SDN is to look like and how it is to operate, we can move from a focus on nuts and bolts to a study of operational impact. SDN has been tough to bring to market for vendors, in that SDN isn’t something many customers feel they need to buy. That is to say, SDN in and of itself is not a selling point. Rather, SDN is a catalyst for operational efficiency and new network capabilities.
SDN has largely been a set of tools that, while interesting, aren’t easily taken advantage of by the average network practitioner. A controller consolidation implies a generally agreed upon SDN architecture that will allow complete and (dare we say) mature SDN products to come to market from vendors. When that happens, we’ll see broader SDN adoption.
Don’t get us wrong. There are still arguments to be had, positions taken, and proposals won and lost as vendors and end users work together to create an SDN that makes sense for the long haul. But early fruit is already appearing, and the next 12 months are filled with the promise of progress.
Ethan Banks has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks