Networking Evolves, Getting Easier And More Flexible

Get our report,
Strategy: OpenFlow vs. Traditional Networks,
free with registration

>> See all our Reports <<

Software Defined Networking and the OpenFlow protocol could change the way networks operate, making them more flexible and cheaper.

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.

Network Management Challenge

Network management today is a muddle of products that require different modules to address tasks such as LAN switching, provisioning, and wireless management. Each module focuses on its own task without much awareness of other systems, making it difficult for IT to get a clear, real-time picture of the entire network. By using the centralized controller, SDN and OpenFlow provide better control and visibility.

Network management also lacks APIs that are properly formatted for software developers. SNMP, the workhorse protocol for network management, just isn't suitable to provide rich, formatted data for applications to work with, nor is it suitable for configuring network devices. By contrast, OpenFlow provides XML-based data exchange between devices and controllers that can be extended and easily integrated into programming languages. This means network management tools should be able to tap into XML-based data, allowing for better visibility and management.

While SDN and OpenFlow promise a more granular and open system, it remains to be seen whether they can replace existing management tools. The technology is still immature and lacks sufficient adoption to be sure.

Other standards might bring similar benefits with less disruption. The relatively new standard Transparent Interconnect of Lots of Links (TRILL) changes enabling Layer 2 multipathing in Ethernet LANs, which helps eliminate choke points, increases usable bandwidth, and better supports the multidirectional movement of virtualized workloads. New tunneling protocols such as VXLAN/NVGRE are addressing the need for virtual server mobility. The soon-to-be-ratified IEEE 802.1BR, commonly known as EVB, will standardize virtual Ethernet bridging, which should let virtual and physical switches communicate about servers, VLANs, and quality-of-service requirements. That would maker it easier for admins to respond when hypervisors move from one physical machine to another.

There also are standards meant to make it easier to configure devices from multiple vendors. For instance, the IETF has ratified XML-based protocols such NETCONF and YANG, which provide better capabilities for remote administration and can serve up richer data to management software.

A Long Road To SDN

The SDN and OpenFlow's potential benefits are significant: more flexible networks, simpler administration, and less expensive hardware. But the benefits are only promises. While several networking vendors support OpenFlow, and startup Big Switch Networks has an OpenFlow-based controller in a beta release, the protocol is still in its infancy.

Companies with enormous data centers, such as Google and Verizon, will probably be the first to pick up SDN and OpenFlow because they can realize substantial savings in network hardware and administration costs. If the technology proves itself, it will be more widely adopted in mainstream IT environments.

Pay attention now, though. Whether you completely revise your network to support a controller-based infrastructure or adopt existing protocols to improve network flexibility and responsiveness, you may soon find that you no longer need to manually configure VLANs and switch ports.

Greg Ferro is a consulting network architect and senior engineer and designer. Write to us at [email protected].

InformationWeek: Feb 27, 2012 Issue

Download a free PDF of InformationWeek magazine
(registration required)