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.
2. Open Network Operating System (ONOS)
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.
Sign up for CIO Asia eNewsletters.