SDN takes the decision-making about how network traffic should flow away from individual switches and routers and shifts it to a centralized controller or set of controllers. These controllers use software to build a picture of existing pathways through the network and tell network devices which pathways to use. OpenFlow is a protocol that implements SDN, describing how a controller communicates with other network devices.

SDN potentially provides two major benefits. It could let IT more easily and quickly make changes to network configurations. It also could lower hardware costs if IT can replace expensive, intelligent switches and routers with fast but dumb commodity devices. However, SDN and OpenFlow have yet to be widely adopted, and networking pros may be reluctant to swap reliable, well-understood architectures for a new one. There also are existing protocols that are designed to address some of the same issues as SDN and OpenFlow without disrupting the networking model.

Here's a look at SDN and OpenFlow's potential benefits and pitfalls, and how they compare with existing networking practices and protocols.

Inside SDN

Networking equipment typically has three planes of operation: management, control, and forwarding. The management plane handles functions such as device management, firmware updates, SNMP, and external configuration via the command line. The forwarding plane (sometimes called the data plane) governs packet and frame forwarding of data payloads through the network device. The control plane consists of routing and switching protocols.

In a typical operation, the control plane uses routing protocols to build the forwarding table used by the forwarding plane. This forwarding table is delivered to the forwarding plane by the management plane as part of the device operating system. When an Ethernet frame arrives on the switch interface, the forwarding plane sends it to an output port.

SDN and OpenFlow aim to replace or supplement this model by providing a prepared forwarding table from a centralized controller (see diagram, above). A controller in an SDN architecture is a software application that performs four functions. First, it presents a network management interface to the IT administrator. Then it maps out the network's status and current control plane. Next, it takes a given configuration from an administrator and logically renders it into OpenFlow entries. Finally, it sends those entries to the appropriate network devices, which add them to their forwarding tables, creating a new path through the network.

Today, an administrator might have to reconfigure dozens of network devices to make changes to network paths. In theory, SDN and OpenFlow would let the administrator provide the desired parameters to a few controllers, which then reconfigure the appropriate devices. This would simplify the administrator's job and make the network better able to respond to demands, such as prioritizing one type of application over another.

In addition, in a conventional network, each vendor uses a different interface to configure its own devices. Thus, while the standards-based Border Gateway Protocol works the same on devices from different vendors, each vendor's configuration interface can be very different, making the management plane of multiple vendors hard to operate. OpenFlow has a standardized protocol and API between the controllers and the switches, so communication is consistent across all vendors, making it easier to manage disparate devices.