Social concept points to an SDN model with two control planes
It might not seem like control planes and SDN models have a lot in common with a social concept, but together, they could highlight how business intent and operations inform network design.
A social principle might seem like an odd link to network engineering, design and software-defined networking, but seemingly unrelated principles often address a concept that can be applied in other contexts. In this case, the social subsidiarity principle can shed light on the use of network control planes and SDN model design.
Subsidiarity is primarily a social and legal concept defined in the Oxford English Dictionary as "the principle that a central authority should have a subsidiary function, performing only those tasks which cannot be performed at a more local level." But the concept can be applied to other circumstances.
When talking about SDN models and network design, for example, it's best to strip away its political and cultural overtones and state the principle in a more general way, as follows: Subsidiarity is the principle that decisions should be made as close as possible to where the information needed to inform the decision exists.
The network's operational and ideal states
In that light, we can make a couple of observations about how to apply the principle to network engineering and SDN models. A network never has only one source of truth; there are always at least two.
The first truth is the reality of the system as it exists. This is the operational state of the network, which includes its connections, configurations, link utilization levels, queue depths, and other physical and logical states.
The second truth is the ideal state. This is the policy goal or the desired state, which is the set of purposes the network was designed to fulfill. The most immediate expression of this source of truth is an idealized design, or the way the network was originally intended to work.
We need to further investigate the ideal state to determine how the subsidiarity principle might apply. The ideal state usually results from a set of design decisions made in the face of business problems that need to be addressed. For example, one application may need to take precedence over another, or a particular type of traffic needs to be encrypted, or a particular kind of traffic can be dropped in the case of failure.
How the two states glean their information
The operational and ideal sources of truth receive their information from different places. The operational state is obtained from the network itself, including its links and devices. The ideal state is obtained from the network designers and business intent. The figure below illustrates these two states and how they interact with one another.
How the operational and ideal states of the network affect each other
In this illustration, the business intent is driven through a design process to create the idealized state of the network. At the same time, the operational state is learned by examining the network itself. The gap between these two views is discovered through telemetry, while configurations and other information are imposed on the network to try to bring it into alignment with the ideal state.
Questions about this process might include the following: How long does it take for the telemetry-configuration loop to take place? In other words, how long does it take for the ideal state of the network to take operational realities into account? Then, how long does it take for the new ideal state to be imposed on the operational state? And what happens while the ideal and operational states do not match?
The first question needs to be answered in light of the second. When the operational and ideal states don't match, traffic flows through the network in a suboptimal way, which wastes resources. Another result is the network simply doesn't support the business requirements. Unfortunately, imposing the ideal, or desired, state on the operational state often takes far too long.
Tradeoffs between distributed and centralized control
Fully distributed control planes are grounded in the observation that the operational state of the network is the most important. When the operational state changes, decisions about what to do are usually made near the actual network and its components. As a result, distributed control planes can react more quickly to changes in the operational state of the network, but they are much slower to react to changes in business intent.
On the other hand, centralized control planes are often implemented with an eye toward business intent. The network's operational state is carried to a controller, where it can be merged with business intent and then reflected into the network as operational state. This means the centralized control plane is quick to react to business intent, but slower to react to changes in the operational state than distributed control planes.
The subsidiarity principle uncovers a new way of looking at network design and SDN models, exposing a tradeoff between centralized and decentralized control planes.
To this point, the subsidiarity principle uncovers a new way of looking at network design and SDN models, exposing a tradeoff between centralized and decentralized control planes. For example, a primary concern with SDN is its slow reaction rate to link and node failure. This intuitively seems to match up with the slower reaction of the centralized control plane, as software-defined networks are often types of centralized control planes.
A network with two control planes
The subsidiarity principle provides an explanation of a phenomenon most engineers already understand. So, how can it be used in current SDN models to improve the situation? The principle argues for making decisions as close as possible to where the required information exists.
Because there are two sources of truth or states in a network, there should be two control planes representing the two states where decisions are made. Each control plane should make different types of decisions, based on business intent and the actual network. The results of these decisions should be sent to a central location and then reflected back to the decision-making control planes.
It makes sense to allow a decentralized control plane to make local decisions based on operational changes. At the same time, a centralized control plane should be allowed to make decisions based on business intent and somehow reflect those into the operational state. The ideal state then becomes a merger of operational reality and business requirements.
An SDN model that splits the decision-making power based on where the information required to make the decision resides is a powerful model for understanding and building networks that react quickly to both local conditions and business requirements.
In part two, Russ White will present an example of how an SDN model can apply this type of concept.
