- 18 Hot IT Certifications for 2014
- CIOs Opting for IT Contractors Over Hiring Full-Time Staff
- 12 Best Free iOS 7 Holiday Shopping Apps
- For CMOs Big Data Can Lead to Big Profits
Network World - 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.
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.