Editor's note: This article is second in a series on understanding software-defined networking (SDN) technology strategies. In part one, we explore the elements of two SDN architectures -- distributed control versus centralized controllers. Here in part two, we dig deeper into the theoretical differences between the two architectures.
There is no single, clear definition of software-defined networking. But there are two camps with two sets of beliefs: One camp consists of SDN purists and the other of SDN pragmatists. The purists believe in centralized control and management of packet forwarding, while the pragmatists rely on a distributed architecture where decision making is spread throughout the network. Each SDN strategy has its strong points and both are likely to see implementation depending on the scenario.
The problem with traditional networks
Switches in traditional physical networks forward information in packet form based on a combination of knowledge, including a network address in the packet and information about the topology and connectivity of the network itself. Forwarding tables tell each device what port should be used as the destination of a given packet. In traditional networks, these tables are built through the exchange of topology and status information among network devices. This discovery process is managed through special control packets, and thus the discovery and forwarding table is called the control plane, which is separate from the data plane where data packets are handled.
But discovery and adaptive autonomic behavior makes it difficult to engineer traffic patterns, predict performance or create quick and orderly recovery from failures. Network problems create a period of disorder as devices attempt to discover new paths. During this period, data can be lost or delayed significantly, and no device has full knowledge of what other devices might be contributing to its traffic. This makes load calculations and Quality of Service (QoS) difficult to secure.
SDN purists and the centralized controller model
The purist model of SDN technologies evolved from researchers who aimed to replace adaptive discovery with central control of forwarding. In this architecture, a central software process -- or centralized SDN controller -- maintains the entire topology and status of the network's devices and trunks and understands the network addressing and connectivity from the user's perspective.
This central process then uses various algorithms and policies to define routes through the network for each permitted flow. The paths are created by telling all devices along the way to change their forwarding table to pass the packets along the path correctly. The OpenFlow protocol was designed to be the language used by the centralized controller to communicate forwarding table changes to network devices. This communication could happen proactively based on a network map or in response to a request from a device for instructions on how to handle a packet for which it had no forwarding entry.
More on SDN architecture and strategy
OpenFlow tutorial: SDN controllers and applications emerge
Northbound APIs guide: Understanding the apps that rule SDN architecture
How to use SDN for the private cloud
The challenge in this SDN approach is the lack of a proven model for centralized control. The Internet and its IP foundation demonstrably scale to the scope of today's online world, but there is no proof that central control of networking can scale and no currently accepted technology to test its capabilities.
What is most likely to happen with centralized SDN is a kind of interior deployment. The problems of scalability and central control are most easily addressed not over the whole of the Internet or even an enterprise WAN, but in a data center, within a cloud, in a content delivery network or in a WAN core.
Deploying centralized SDN in these interior domains can spread widely and quickly. Over time, the standards bodies and vendors can address the best way of linking disparate SDN domains into a complete end-to-end network. When and if this happens, the centralized and distributed SDN models will be in a state suitable for side-by-side comparison, and the question of the ideal SDN technology can then be answered.
Distributed SDN -- or evolution instead of revolution
For now, many experts and vendors believe this centralized SDN strategy, however pure its foundation, is unnecessarily revolutionary; evolution is more prudent. The value of adaptive discovery in building forwarding tables has been established by decades of use, including the success of IP as the foundation of the Internet. To this group, which includes many IP experts and router equipment vendors, the software that should be defining network behavior is higher-level software, perhaps even application software.
The centralized SDN strategy substitutes computer-hosted software processes to control forwarding behavior while the distributed model adds mechanisms for software (and increasingly cloud) control to traditional IP and Ethernet networks.
The distributed model, like the centralized model of SDN, accepts the need to gather information about network status and collect it at a central point where it can be acted on to manage performance. But in the distributed model, the goal of SDN is to offer more controllable behavior, and that goal could be met by leveraging extension protocols like PCC/PCE/PCRF (policy and charging rules function), MPLS and GRE.
Of these protocols, policy-controlled networking appears most important. Virtual networking principles, such as those used by Nicira (recently acquired by VMware), could make Ethernet and IP more suitable for virtual-network applications and cloud computing, and can be easily added on top of the evolutionary model. This could be executed using distributed decision making.
The challenge for distributed SDN is that it has yet to prove that it can offer the kind of tight control over traffic and connectivity that centralized SDN technologies could offer. Here again, there's also the problem of an accepted framework for applying distributed SDN principles. Many users fear that this model of SDN will become proprietary since vendors will work to integrate it into their existing closed systems.
This was first published in March 2013