Our friends in Networking often talk about concepts in terms of plane. A plane (a part of space that exists independently) comprises of specific knowledge, owns certain decisions, and can carry out some operations. Some of our philosopher friends define the concept of Mental Plane made of thoughts, and separate it from the Physical Plane in terms of reality.
We’re drawn to planes for the beauty of abstractions.
A definition
A network topology defines the various paths for data to travel between participating devices (routers, switches etc.). There are two distinct functions to help a data packet traverse through a topology.
First, where should the data packet travel? We take this decision based on the target information in the packet, and the hints of next nearest devices (e.g. routing tables). We also need to instruct how the device should process the packet (a protocol). Both these decisions belong to the Control Plane.
Next, when the packet reaches the device along with an instruction to process it (the what), the device has the knowledge on how to process. It takes a bunch of decisions to actually process, such decisions belong to the Data Plane.
So far so good, abstractions help with separation of concerns. We’ll take a little detour to the world of physical networking to understand the motivation.
RFC 3746 defines an architecture called ForCES (Forwarding and Control Element
Separation). The paper defines Control and Forwarding elements as follows:
Two types of network element components exist: control element (CE) in control plane and forwarding element (FE) in forwarding plane (or data plane). Forwarding elements are typically ASIC, network-processor, or general-purpose processor-based devices that handle data path operations for each packet. Control elements are typically based on general-purpose processors that provide control functionality, like routing and signaling protocols.
CEs comprise our Control Plane and FEs belong to the Data Plane. In a world dominated by hardware, what did such a separation give us?
First, beautiful abstractions enable composition. Such a framework provides the concept of Network Element (NE) which is simply a device that all of us use, e.g. a router, switch etc. A NE is composed of many CEs and FEs. A topology is composed of many NEs. Topologies can exist in various scopes: LAN, WAN, WWAN etc. On the whole, this defines the Internet as we see today.
Separation of concern with abstractions also enables independent evolution. The vendors that create FEs need not worry about expertise on CEs, or NEs for that matter. All of this is possible because a standard contract (protocol) exists that enables each of these concepts to talk to each other. We can replace the FE by Vendor A with another one by Vendor B. This interoperability breeds choice with plug n play.
Abstractions also allow us to independently manage the systems. E.g. can we create a mesh of CEs (that still operate as a single CE to the outside world)? Such a primitive allows us to scale the components based on our requirements instead of doing forklift upgrades.
Lastly, the concerns in Control Plane have different primitives. E.g. consider the fundamental aspects like load sharing, or high availability. Data Plane, being the dumber one doesn’t need to care about how load sharing is implemented. It stays happy as long requests arrive at its door. However, both planes coexist and communicate with a set of known standards.
How does the operational characteristics of these planes compare?
Operational aspects
Marc Brooker takes an interesting approach to differentiate the Control and
Data planes based on operational characteristics. Starting with the fundamental attributes of
a distributed system, Storage and Load balancing may be considered as Data Plane; where as
Failure tolerance, Scaling nodes and Deployments are Control Plane aspects.
Data Plane aspects scale with every request, but the Control Plane aspects scale with the size of
fleet (or the number of VMs or Containers managed), usually it is N/M where N is the total
number of requests and M is the requests per host.
Can we say that the Control Plane concerns fall in the bucket of infrastructure? Possibly, yes, from a bigger picture perspective. Control Plane owns and manages the instances and fleets. We used to call this the “Grid” in one of the large scale systems I worked with some time back. E.g. Azure resource manager defines the Control and Data plane operations in their systems.
However, such a separation is not always black and white. If we zoom in, we will find every smaller component to have a Control and Data plane. Control Plane of the inner components is the Data Plane of an outer component. Remember, the beauty of abstraction.
Planar thoughts
If we were to reverse engineer a system (or a domain), do we find elements that have characteristics of Control and Data? Our discussion suggests we consider seggregating these responsibilities and attempt to define a contract.
Abstractions will help with composition, independent evolution and scale.
How about a platform for creating Control Planes?
Since we’re talking about networking abstractions, I cannot help but leave a link to this widely cited paper on Software Defined Networking (SDN) here. Here’s the problem the paper attempts to solve:
Computer networks lack a general control paradigm, as traditional networks do not provide any network-wide management abstractions. As a result, each new function (such as routing) must provide its own state distribution, element discovery, and failure recovery mechanisms. We believe this lack of a common control platform has significantly hindered the development of flexible, reliable and feature-rich network control planes.
And it tries to solve the inflexibility with hardware control planes by defining a SDN:
Said another way, the essence of the SDN philosophy is that basic primitives for state distribution should be implemented once in the control platform rather than separately for individual control tasks, and should use well-known and general-purpose techniques from the distributed systems literature rather than the more specialized algorithms found in routing protocols and other network control mechanisms. The SDN paradigm allows network system implementors to use a single control platform to implement a range of control functions (e.g., routing,traffic engineering, access control, VM migration) over a spectrum of control granularities (from individual flowsto large traffic aggregates) in a variety of contexts (e.g.,enterprises, datacenters, WANs).
P.S: In case you’re wondering, it turns out planar is a real word :)