If you haven't been living under a rock for the past few years, your head is probably about to explode from Software Defined Networking overload. Rooted in Stanford academic research, SDN was initially branded as a "science project," which in reality it was. However, rapidly growing market interest quickly propelled it from theory to practice and the era of SDN startups had begun.
In its purist form SDN advocates the decoupling of the control and data plane, both traditionally residing inside network devices such as switches and routers. Once such decoupling is achieved, control plane functions are removed from the network devices and placed on an x86 server platform, functioning as the controller.
The OpenFlow protocol is most often used for communication between the controller and the network devices, and this of course implies that the network devices support OpenFlow APIs (delivered by OpenFlow agent) to accept external control plane connections over the IP network.
[ALSO: 12 tips for SDN IT buyers]
Extraction of control plane functions from individual devices potentially eliminates the complexities of running distributed control plane protocols, such as OSPF, BGP or Spanning Tree, thus potentially simplifying overall network setup. Instead of distributed control plane protocols, the SDN controller computes the network topology in a centralized way and programs the forwarding table entries directly into the network devices’ forwarding ASICs.
Integrated and Decoupled Control and Data Plane
While this approach provides powerful new capabilities, upon closer examination, it is not without a flaw. To perform its control plane function the SDN controller needs to know which flows or which endpoints exist in the network. This can be achieved in three ways:
* Proactive-static. Administrators can proactively pre-configure flows on the controller. This method implies knowledge of all the network “conversations,” which is loosely reminiscent of the administrative burden associated with defining static routes in the traditional network model. Administrators can also choose to pre-configure coarse flow entries, which will reduce the network devices’ hardware table consumption, but at the same time will also limit per-flow forwarding state granularity.
* Reactive. The SDN controller can automatically (reactively) discover the flows, but that requires the first packet of each new flow to be forwarded to the controller for inspection. This can create a performance bottleneck and a single point of failure, should there be connectivity disruption between the controller and a network device. In such case, a network device is likely to continue forwarding data using the last known state, however, no new entries will be created until connectivity to the SDN controller is fully restored. As a workaround, network devices can also allow administrators to program forwarding table entries locally on the device through CLI.
* Proactive-dynamic. Control plane protocols can be leveraged between the network devices and the SDN controller to exchange endpoint reachability information. This mainly manifests itself in identifiers such as MAC or IP address. This case is different from the previous two, since the SDN controller is made aware of individual endpoints, rather than flow “conversations” occurring on the network. Once endpoints are identified and discovered, the SDN controller computes the paths and programs the flows into intermediate network devices’ forwarding tables.
The next question is how we would extend the connectivity from individual network devices to the entire network leveraging the SDN methods we described. A distributed control plane leveraged in a traditional network model allowed networks to scale to hundreds of thousands of forwarding entries, and ASIC innovations allowed efficient programming of those entries into the forwarding hardware. Centralizing topology and reachability computations on the SDN controller can have significant scale implications.
Lets look at three possible approaches. First and most obvious is have an SDN controller compute the path between endpoint A and endpoint B, and then program the forwarding entries into all intermediate devices between those endpoints on a hop-by-hop basis. This is where the ability of an SDN controller to see the entire end-to-end topology is most beneficial.
End-to-end network programming
Second case is to have the SDN controller program the forwarding entries only at the network edges where endpoints A and B are attached. Since no forwarding entries pertaining to endpoints A and B are programmed into the network core, network edges perform encapsulation to carry the traffic across. In this case the network core need not know about endpoints A and B, but rather, cares only about delivering encapsulated traffic between the network edges where endpoints A and B are attached. This approach is most commonly known as network virtualization or network overlays and it combines SDN programming at the edge with traditional forwarding in the network core.
Network edge programming
There are several encapsulation protocols that can be leveraged for overlays, with VXLAN being the most popular and the most adopted among major vendors. It is also the only one supported in switch ASICs today. This is an important distinction, since the network edge can be either a software switch in the virtual hypervisor or an edge switch in the physical topology.
If endpoint A was a Virtual Machine and endpoint B was a physical server, the network overlay tunnel would be optimally built between the virtual switch where endpoint A is attached and a physical switch where endpoint B is attached. In this case hardware support is an important consideration for scale and performance.
The third case is the blend of the previous two. An SDN controller can program both the forwarding entries at the network edge to “push” the traffic between endpoints A and B into the network overlay tunnel, and also the forwarding entries in the network core to allow tunneled (encapsulated) traffic to be forwarded between the network edges without leveraging the traditional distributed control plane network model at all.
End-to-end and Network edge programming
While SDN provides a powerful set of new capabilities, it also requires fundamental shifts which might prove too disruptive for some. But there is an alternative method for network programmability which does not necessary include such a fine-grain approach.
As you recall, the formal definition of SDN focuses around control and data plane separation. Without a control plane, network devices are unable to autonomously perform intelligent functions and must rely on an SDN controller.
Consider a case where network devices retain certain control plane functions and the ability to communicate their operational characteristics, such as CPU/memory consumption, interface load, transmission errors and so on to the external entity, which might happen to be an SDN controller. This opens the door for a whole new way of network programmability.
You could, for example, easily reroute traffic if interface load exceeded 75%, or you could influence Shortest Path First algorithm timers on the network device based on dynamically determined CPU cycle availability, rather than administratively pre-configured timer values. The possibilities are virtually endless and operational implications are substantial.
Historically, similar functionality could have been delivered by leveraging external monitoring stations using something like SNMP to poll (get) certain data from the network devices and then, based on desired action, invoke either configuration scripts or use SNMP (set) to alter network devices’ behavior.
Modern programmatic approaches allow us to achieve significantly more comprehensive results by leveraging APIs instead. Such APIs allow a programmatic way of accessing device information, extracting it for analysis and, based on the outcome, modify device behavior. Depending on the use case, APIs can influence forwarding behavior, security controls, quality of service characteristics, and so on.
Programmatic Approach with local Control Plane
Making those APIs uniform across different families of network devices yields significant advantages, since they can represent a consistent programmatic interface to develop against. Think of an Application Store, where developers can post their apps for customers to consume. As long as the API layer is enabled on the network device, it can communicate with the app logic.
As you can see, there are multiple approaches to network programmability, but one thing is certain: customer demand drives vendors to invest in programmatic APIs to harness hardware/software innovation to achieve operational agility across diverse set of environments.
Klebanov has 15 years of network industry experience. In his work he influences strategic development of the industry leading Data Center platforms, which lay the foundation for the next generation fabrics. He can be reached at email@example.com or on Twitter @DavidKlebanov.