Disruptive Change Coming to the Network, Driven by SDN and OpenFlow

In the last decade, networks and networking technology have been evolving gradually—changes have been incremental and expected, such as increased throughput in Ethernet networks and enhancements to routing protocols to improve fault detection and resiliency. However, these gradual changes have been insufficient to handle the need for making networks highly programmable and the tsunami of data flooding the networks. The data explosion is forcing vendors and service providers to make big, disruptive changes to the network and has led to the emergence of software-defined networks (SDN) and OpenFlow.

Understanding SDN and OpenFlow is helped by first considering how traditional network devices operate. Most of today's switches and routers are responsible for both the control and data planes, with the control plane determining which packets are forwarded where and the data plane actually forwarding them. They implement thousands of RFCs and run 10s of millions of lines of software code. These traits make them expensive, complex to program and difficult for service providers to introduce and monetize new services.

SDN turns the traditional approach upside down by separating the control and data planes and centralizing control for all network devices in a single controller or a handful of controllers that often run on general-purpose servers. SDN also allows independent software vendors to develop applications to run above the controller so that complex, end-to-end network services can be orchestrated – thus the "software defined" in SDN.

OpenFlow is a communications protocol that enables SDN. OpenFlow-enabled controllers and switches communicate with each other through the OpenFlow protocol that supports messages such as “modify forwarding table” and “get stats.” OpenFlow ensures that network configuration changes made in the controller are quickly distributed to all appropriate switches and routers.

The first deployments of SDN/OpenFlow are happening in the data center and WAN/campus networks.

a) In greenfield deployments, the entire DC or WAN is populated by OpenFlow switches (hop-by-hop), driven by a cluster of controllers.

b) For operators who have already deployed a DC fabric or transport network, the overlay model – where Open vSwitches are deployed on the network edge – is preferred.

The second wave of SDN deployments are expected to happen in telco service provider networks. Over a dozen SPs are already collaborating to virtualize network functions (such as BRAS, DPI, Firewall, Mobility, etc.) to run on powerful servers with a goal of enabling independent software vendors to develop revenue-generating services. NEMs are also planning to enhance their devices to support virtualization and improve programmability of the control and forwarding planes.

Validating the proper implementation of SDN technologies and networks is crucial to the rapid adoption of SDN. This includes the testing of OpenFlow switch and controller operations and forwarding (hop-by-hop), testing Open vSwitch operations and network virtualization functions (overlay scheme), and validating the functioning and performance of virtualized BRAS, firewall, or mobility functions running on servers. In addition to SDN-specific testing, traditional testing procedures also have to be performed on individual DUTs and entire SDN networks. These include testing for Performance, Availability, Scalability and Security (PASS).

Stay tuned to this blog series to learn more about the benefits, challenges and recommended methodologies for testing SDN deployments in data center and SP networks.