OpenFlow Tutorial: Next-Gen Networking Has Much To Prove

Server virtualization is now a proven practice, creating a cost-effective means of allocating compute resources to changing user and application requirements. But when packets leave the server, they still pass through a traditional switching architecture, which doesn't have that same level of flexibility.

The goal of software-defined networking (SDN) is to bring the benefits of virtualization--shared resources, user customization, and fast adaptation--to the switched network. SDN puts the "intelligence" of the network into a controller or hierarchy of controllers in which switching paths are centrally calculated based on IT-defined parameters, and then downloaded to the distributed switching architecture.

The cost savings are apparent. The expensive part of a high-end switch is the sophisticated control plane and custom silicon. By moving the control plane to a centralized controller, the architecture can use inexpensive commodity switches built with standard silicon. Reducing the cost of each switch by 70% or more, spread across a data center or campus, quickly adds up to real money.

SDN is also about improving performance. A centralized control plane lets companies customize their networks without depending on or coordinating different vendor operating systems. Networking pros can quickly change what data types get forwarding priority, as business requirements change.

The first step toward SDN is to define a messaging protocol between the controller and the individual switches making up the forwarding plane. This is where the emerging OpenFlow networking standard comes in. OpenFlow enables open, virtualized, and programmable networks. Each of these elements is key.

Open: The standardized instruction set means any OpenFlow controller can send a common set of instructions to any OpenFlow-enabled switch, regardless of the vendor.

Virtualized: IT can specify different forwarding rules for different data types, creating multiple logical forwarding paths over the same physical network, depending on the needs of a particular app.

Programmable: The still-evolving OpenFlow instruction set lets IT create rule sets that work in combination with a switch vendor's configuration options, or independent of them. With its roots in academic research networks, OpenFlow lets users try new ideas or create new protocols independent of any vendor. Most important, IT can program a network for specific application requirements.

Inside OpenFlow

Sign up for a free membership with InformationWeek Reports and get our full report on OpenFlow and software-defined networks.

This report includes additional analysis, an in-depth tutorial on the OpenFlow protocol, and seven diagrams illustrating software-defined networks.Get This And All Our Reports

Roots Of Network Virtualization

The separation of the control plane from the forwarding plane isn't new with OpenFlow. It has been used in the design of high-end routers since the mid-1990s and telephony switches long before that. The initial motivation was to protect each switch element from a degradation in another: A very busy route processor doesn't hurt forwarding performance, and peaks in network load don't pull processing resources away from the control plane. Significantly, that separation--first within a single chassis, and more recently with a single processor controlling multiple switching fabrics--provided an environment for the development of high-availability features.

Multiprotocol label switching (MPLS), another key technology in modern networks, also has features that relate to this trend, since it builds an "intelligent" access layer around a relatively dumb but high-performance network core. That structure enables the creation of flexible, innovative services over a homogeneous backbone. MPLS also reflects a trend in networks similar to what we're seeing in server virtualization: A single physical network uses a logical component--MPLS--to allow the overlay of multiple virtualized network services.

What's new and different with OpenFlow is that, in theory, it could work with any type of commodity switch.

Operating in the gap between a centralized control plane and a distributed forwarding plane, OpenFlow defines a protocol that lets a controller use a common set of instructions to add, modify, or delete entries in a switch's forwarding table. An instruction set might not sound like a technology breakthrough, but it's all about what people do with that instruction set, says Kyle Forster, co-founder of Big Switch Networks, a startup building networking products based on the OpenFlow standard. If you read the x86 server instruction set, it "isn't obvious that you could build Linux, Microsoft Word, or the Apache Web Server on top," Forster says. "I think OpenFlow is the same way. It isn't about the basics. It's all about the layers and layers of software built on top. That is where the benefits are going to be felt."

Origins Of OpenFlow

OpenFlow began at Stanford University, under professors Nick McKeown, Martin Casado, and others. Their goal was to create an environment in which researchers could experiment with new network protocols while using the campus's production network. It let researchers try out those protocols in a realistic environment without the expense of building a test network or the risk of blowing up the campus network and disrupting production traffic.

The first consideration for using OpenFlow outside of academia was to scale bandwidth in massive data centers. Forster calls this the "million-MAC-address Hadoop/MapReduce" problem. For uses such as Google's search engine, parallel processing of massive data sets takes place across clusters of tens or hundreds of thousands of servers. For such big data applications, "it doesn't take much back-of-the-envelope calculating to come to the conclusion that a tree-based architecture will require throughput on core switches/routers that simply can't be bought at any price right now," Forster says.

Interest in OpenFlow has since expanded to cloud computing and virtualized services companies. Earlier this year, six companies--Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo--formed the Open Networking Foundation (ONF) to support development of SDN and, by extension, the OpenFlow protocol. ONF now has more than 40 members, mostly vendors, which pay $30,000 a year to fund development of the standard.

The version of the OpenFlow specification in most widespread use is version 1.0.0, which in December 2009 defined three components: controller, secure channel, and flow table.

The newest version of the spec, 1.1.0, released in February, adds two more components: group table and pipeline (see diagram, right).

The controller is of course the control plane, and it provides IT programmability to the forwarding plane. The controller manages the forwarding plane by adding, changing, or deleting entries in the switches' flow tables.

The controller manages the switches across a secure channel. "Secure channel" is in fact slightly misnamed, since it doesn't provide any security on its own. While the channel is normally authenticated and encrypted using Transport Layer Security, it can be simple unsecured TCP. Implementing an SDN architecture using unsecured communication channels is utter folly, of course, but it can be done. Also, messages across the secure channel are reliable and ordered, but aren't acknowledged and therefore aren't guaranteed.

Who Needs It

While the most intense interest in OpenFlow is in large-scale data center applications, there's already speculation about how OpenFlow-based SDNs can benefit other industries. The fact that Deutsche Telekom and Verizon are among the founders of the ONF provide some hints at next applications.

In mobile networks, OpenFlow can help solve a notoriously hard problem in IP: monitoring, metering, and servicing user traffic. In service provider networks, OpenFlow may provide a more workable alternative to MPLS traffic engineering.

More broadly, the ability of a network operator to create custom functions applicable to its own network, and then apply those functions to switches from multiple vendors, is the true promise of SDNs. Technology users have always found surprising ways to use the tools available to them, innovating from the bottom up rather than limiting themselves to top-down vendor systems. An open instruction set could accelerate that innovation.

OpenFlow version 2.0 is in the works, bringing with it a generalized networking instruction set, as well as a standardized API to the network operating system that's planned for 2012 release. That upgrade would make it easier for third-party network management systems and data center provisioning tools to interact with OpenFlow controllers. Manufacturers of commodity switches, including Hewlett-Packard and Extreme Networks, are starting to line up behind OpenFlow and SDNs, as are new vendors such as Nicira Networks and Big Switch Networks that are focused on network control systems.

OpenFlow has the right combination of industry and academic backing to ensure that its development and evolution continue. It has the potential to turn the networking world on its head by disrupting the market positions of high-end router and switch vendors, including Cisco and Juniper. Or those vendors have the potential to turn this trend to their advantage (see related story, p. 33).

While still in its infancy, OpenFlow has already been used to demonstrate fixes to old problems. Conventional Ethernet switching architectures have long been stuck in inefficient, inflexible tree structures. Those don't look sustainable for a lot of what companies will want to accomplish. OpenFlow can be expected over the next few years to change the landscape of large data center and enterprise campus networks.

Related Links: