What is a “Controller”? And how many do we need?

Thanks to SDN, the “Controller” word pops up in many network architecture discussions these days. In networking alone, we’re already surrounded by many “controllers” and we’re busy introducing more as we speak:  For example, Session Border Controllers or Wireless LAN Controllers have been around for quite some time, and have recently announced the OpenDaylight Controller, the Cisco XNC, or the Cloupia Unified Infrastructure Controller. So what is a “Controller” in networking terms, and how many do we need in emerging network architectures?

Controllers as providers of specific abstractions: When people say “controller” these days, they are inspired by the SDN discussion, but cast the definition decidedly wider.  In generic terms, a controller is typically understood as an entity which is provides “some” form of network abstraction as well as coordinates and manages state across multiple devices, within the network layer but also outside of it.

In the original SDN definition, an SDN controller combines two abstractions: A global network view and a forwarding model. Or just to restate it with different words, a view of the physical network topology combined with a data-plane model of the interconnected devices. In his talk in May 2013 at Stanford, Scott Shenker compared the Network Operating System that makes up a SDN controller to a “compiler” – you express what you need in a high level language and the compiler does the hard job of mapping things to reality. While academia is focused on the specifics of such a compiler, most network IT professionals studying business benefits of SDN now desire different levels of abstractions for different sets of functionality in the network. Corresponding to these abstractions and the associated data and state being managed, different types of controllers are defined and deployed. For many people a “controller” is simply a function which helps with network programming and control for certain network scenarios or deployments, i.e. supplying certain sets of abstractions for specific purposes. What represents a “global view” for you might just be a “local view” for someone else: for example, what looks like a “physical network” to you, e.g. the optical topology, might be an overlay and abstraction (the lambda network) for someone else.

Integrated and dedicated controllers: Given the use-case and deployment specific nature of the set of state being managed, we typically do not see a dedicated software entity just providing abstractions, but the application software peers with the network elements directly. This is a natural and efficient deployment model for many applications which use our programmatic interfaces like onePK. That said, as we evolve towards infrastructure software and offer network functions through a software platform, we further integrate our infrastructure software components (see also my blog from April this year). The move towards a software platform which delivers network control functionality corresponds to the needs of customers who do require a high degree of customization and want to combine multiple infrastructure software components into a customized system. They desire to customize the overall system behavior leveraging network programmability, but like to focus more on “what” they want the network to do, but less so on “how” things get done, which means how the individual network element gets discovered, programmed, and controlled etc. Or put slightly differently, customers desire to move away from a world of scripts and specific device control protocols to a world of “network intent”. This is a classic call for an entity which provides abstractions.  The OpenDaylight Controlller, which is an open source project under the Linux Foundation, or Cisco’s commercial equivalent like the Cisco XNC are “SDN-type” controllers. Being multi-protocol in nature, both, the OpenDaylight controller as well as XNC, offload the customer from dealing with each device and the various protocols and APIs to control it directly. Less “SDN-type” but more “orchestration-type” is the Prime Network Services Controller, providing network abstractions for PaaS deployments.

In a nutshell, controller-technology is one component in the bigger mix of infrastructure software components – it can be understood as a pre-product, or optional pre-integrated building block, easing and speeding up development of applications and infrastructure software which solve business problems.

How many controllers? Will there be just a single controller in the long run to supply all possible abstractions for all types of control functions? Maybe the problem is that we want to visualize “The Controller” as being the kind of dedicated new “box” that magically solves every pain point in effectively gluing together the application and network layers. In the emerging landscape, controllers, much like application servers, will be physical and virtualized entities providing specific abstractions. IT departments will be able to create and orchestrate different controllers for different business issues. We will witness a world with multiple controllers supplying different types of abstractions and associated state management functions, peering with each other to deliver a specific, customer-centric solution.

Share