Both the hardware and software switch have significant roles to play within SDN, as it is chiefly their forwarding tables that are being programmed by a controller. Considering that soft switches reside at the network edge, the concept of a "smart, soft edge" has arisen.
Network designers that advocate for a smart, soft edge feel that the software switch running on a hypervisor is a good place to install rich network functionality, leaving the physical hardware switches to run a simpler configuration. In a smart, soft edge SDN design, controllers apply forwarding, QoS and security policies in the network's soft switches.
For example, the soft switch could have access lists, QoS parameters for rate limiting and traffic prioritization, and forwarding intelligence applied to virtual ports. By the time network data has left the hypervisor, it has already been tested for security compliance, rate-shaped and encapsulated (if required). Placing all of these functions at the network edge allows core hardware switches to focus on rapid transport of traffic.
Not all networks lend themselves well to the smart, soft edge design, nor can all conceivable SDN use cases be met by a soft switch. There's still a role for SDN to play with hardware switches for tasks like end-to-end business policy deployment, traffic steering and security enforcement. In addition, there's still some amount of basic configuration to be done to a hardware switch, no matter how smart the edge network might be.
The primary southbound protocol used by a controller to program the forwarding behavior of both hardware and software switches is OpenFlow. OpenFlow (OF) is a protocol whose standard is undergoing rapid development by the Open Networking Foundation.
The ONF is a members-only organization made up primarily of networking vendors and service providers, and they operate behind closed doors. Their OpenFlow specifications are published when released. The OF1.0 specification is most frequently seen in production equipment; OF1.3 is the likely next step for most switch vendors. OF1.4 is under development at the time of this writing.
Keep in mind that while OpenFlow is implemented fully in software switches like Open vSwitch, OF has proven challenging to translate into network chips (ASIC) in hardware switches. While new silicon that can handle OF better is reportedly coming, customers evaluating OF's usefulness when combined with their existing network hardware must do thorough testing to be sure the required OF function will scale as much as needed to support their application.
For northbound communications, controllers are frequently offering APIs. A REST (representational state transfer) API is perhaps the most common. REST APIs exchange data and instructions much like HTTP servers, using familiar methods such as GET and POST. APIs provide a way for applications external to the controller to tell the controller what should happen on the network.
Sign up for Computerworld eNewsletters.