Controllers vs. Orchestrators

If you’re like me, you probably have a hard time figuring out exactly what is meant by various terms used in the network and cloud automation space. Sometimes it seems like we use the same term for a wide variety of different technologies that are only vaguely related. At other times, we use different terms to talk about similar technologies that differ in only subtle ways.

The best example of the first issue is the term Software Defined Networking (SDN). While the ONF at least provided a definition of this term (“physical separation of the control plane and the forwarding plane”), that definition was obsolete almost as soon as it was conceived. In fact, technology from the first successful SDN company (Nicira—now VMware NSX) arguably was not SDN at all, since it had nothing to do with “separating the control plane from the forwarding plane”. Instead, Nicira was a network virtualization platform for creating and managing virtual network overlays. Even today, pure (Openflow-based) SDN implementations are rare, and it seems that any network technology that relies on a “controller” is called SDN independent of whether that controller gets involved in control plane functionality or not.

That brings us to the second issue: what the heck is a controller anyway, and how is it different from other technologies that provide similar functionality? If an SDN controller manages the life-cycle of virtual network overlays, is it really still a controller? In the cloud space, technologies that manage the life-cycle of services and the (virtualized) components from which the service is constructed are called orchestrators. Given that most SDN controllers are used for managing virtual networks, shouldn’t they be called network orchestrators instead? What is it about an SDN controller that makes it a controller and not an orchestrator?

This may seem like intellectual nit-picking. However, finding similarities (as well as differences) between technologies from different domains can help simplify architectures, and in my opinion getting the architecture right is key to creating long-term sustainable technologies. For example, if SDN controllers are really orchestrators, then perhaps we should use common architectural constructs and common technologies for both. Specifically, shouldn’t we use the same declarative model-based approaches to interact with SDN controllers as we do with orchestrators?

I believe the lack of crispness in today’s SDN terminology is the result of some sloppy early SDN architecture work that completely ignored the management plane. The control plane was implemented by a controller, which communicated with multiple network elements that together implemented the forwarding plane. The management plane was nowhere to be found, nor was any integration with NMS and/or OSS systems. As a result, whenever management functionality was needed, implementers just shoved it into the controller since that was the only convenient place in which to put it.

This suggests that to start rationalizing terminology, we should start by more clearly organizing different functions along the three planes traditionally used in the networking world:

• The forwarding plane is responsible for forwarding data traffic as directed by the control plane. By the way, is has become practical in recent years to implement this forwarding functionality entirely in software, using virtual switches or software routers. Some people have started referring to such software forwarding as SDN. This is not SDN. This is just “software switching” or “software routing”. 
• The control plane is responsible for making decisions about where to forward traffic. In an SDN world, some of the control plane functionality can be centralized in a controller, which makes it easier to provide novel forwarding functionality beyond the shortest-path or lowest-cost path algorithms used by traditional routing protocols.
• The management plane provides the functionality used to configure and manage the other two planes. Traditional management functions include fault handling, configuration, accounting, performance management, and security. In virtualized environments, the management plane is also responsible for life-cycle management. 

Using these three different planes as a guideline, I suggest we should adopt the following rules to help improve communication in the network and cloud automation space:

• Use the word “controller’ exclusively to refer to those software modules that actually implement control plane functionality
• Use the word “orchestrator” to refer to the specific component of the management plane that is responsible for life-cycle management
• Use the word “network orchestrator” (or network services orchestrator) to refer to orchestrators that have responsibility for managing the life-cycle of virtual networks.

If we rationalized terminology in this fashion, we would have an easier time coordinating discussions between cloud and networking people about virtual networks and how they fit into broader cloud-based services. Specifically, we could start harmonizing various model-driven deployment technologies.

Of course, this opens up a whole new can of worms. What exactly is a model-driven approach, and how does it relate to declarative versus imperative? Where does intent fit in? Lots more room for confusion. I hope to provide my thoughts on these terms in a future post.