OpenFlow, PureFlex, and the Future of Networking, Part 1

The privatization of cloud computing exposed shortcomings of traditional data center virtualization’s balkanized networks for data and storage. The legacy data center sports an Ethernet network for virtual machine communications, a Fibre Channel (FC) network for critical data storage, and sometimes a separate, protected Ethernet network for less-expensive iSCSI nearline-storage. This scheme doesn’t scale well as private clouds grow to first engulf an entire data center, and then migrate out to other building, cities, and collocation facilities.

One successful solution to this problem is Data Center Bridging (DCB), a collection of technologies designed to converge the three primary networks – Ethernet, FC and iSCSI – into a single cohesive network fabric. Unlike traditional Ethernet, the new converged Ethernet network is both reliable and scalable thanks to DCB's lossless data transport. Converged Enhanced Ethernet (CEE) is IBM’s brand name for this technology package, and it is the key to how IBM’s PureFlex System Fabric enables traffic prioritization and protects against application-crippling packet loss. (For the whole scoop on Converged Networks, see “Understanding Converged Networks and PureFlex”).

A converged network makes private clouds more readily scalable, more resilient, and easier to manage. It doesn’t solve all problems, however. One complexity of a converged network is the need to manually provision Ethernet switches and routers to accommodate new VLANs, Quality of Service (QoS) requirements, and changes in network topology. Manual provisioning is tedious, time consuming, and error prone. But it’s not something that can easily be automated in hardware. The solution to this burden must come in the form of software to automate the provisioning process. This next step in network engineering falls under the general title Software Defined Networking, or SDN.

Some proprietary alternatives to DCB/CEE use hardware-specific SDN applications to automate network provisioning, letting you administer an entire network from a single control point. Adding VLANs, specifying QoS parameters, prioritizing applications, and reconfiguring network geometry then become point-and-click simple. Morverover, the SDN code typically incorporates safeguards to help prevent operator error.

But proprietary solutions lock you into a single vendor’s hardware and out of the community of ingenious inventors whose open standards have produced such wonders as the Internet and email. OpenFlow is an entirely new technology designed for the high volume, high-reliability needs of today’s private and public cloud networks. A fully open standard based on research conducted by Stanford University and now overseen by the Open Networking Foundation (http://opennetworking.org/about-openflow), OpenFlow enables software-defined real-time traffic engineering. It does this by centralizing switch configuration in a redundant controller pair. The controller complex identifies traffic based on its flow characteristics and configures switches on the fly to apply policies to that traffic. As a result, switches function as much simpler, non-intelligent packet movers, rather than traffic analyzers and manipulators, as they are today. The brains of the operation reside in the OpenFlow controller.

OpenFlow is good news for IBM’s highly scalable PureFlex system.  PureFlex supports OpenFlow, via the IBM Programmable Network Controller and IBM’s OpenFlow-enabled switches, such as the 40GbE RackSwitch G8316. This technology is bleeding edge, and thus, at least for now, is bleeding expensive. But  1000BaseT switches were pricey just a decade ago, and today are common even in homes.

The Open Networking Foundation (ONF, opennetworking.org) manages the OpenFlow standard. IBM is an ONF member, one of dozens of major software and hardware developers contributing to the OpenFlow specification, including open source software usable fully functional OpenFlow networks. As a result, OpenFlow-enabled devices are appearing from major network equipment makers, creating competing causing prices to drop steadily.

OpenFlow concepts can be quite confusing for traditional network administrators. In order to effectively integrate OpenFlow-based products, you need to understand how the technology works under the covers. You’ll then be poised to integrate OpenFlow into your existing infrastructure where it can do the most good.  OpenFlow is certain to become a job requirement as data centers evolve into private clouds, so making hay while the sun shines is an excellent career move.

Just-In-Time Technology

By separating switching and engineering functions, OpenFlow greatly reduces the complexity of a network, while simultaneously giving you a much more comprehensive view of network performance.  OpenFlow reliably separates traffic for different applications – and different tenants in a multi-tenancy network – to prevent problems with one application's or tenant’s traffic from interfering with others. OpenFlow also introduces a new form of network virtualization, giving applications direct control over their own “slice” of network infrastructure. Because the controller has a complete view of the network, heuristics within the console interface can warn of dangerous changes that could cause disaster.

The result is a much more robust network, resistant to human and machine error, where end users can provision their own services without engaging network administrators, greatly reducing high-priced technician labor. It truly is Network-as-a-Service (NaaS).

OpenFlow couldn’t have arrived at a better time. With public and private cloud facilities burgeoning, and new applications like social networking, mobile computing, and streaming media accelerating, cloud infrastructures need a next generation solution. To understand the value of OpenFlow, it’s worth reviewing how modern data center networks operate and the challenges they face. Consider this diagram of a typical data center using best-practice converged network with tiered switching and routing:

 The top tiers of the network contains border devices, including routers, bandwidth controllers, and DMZ switches. In the middle is the core switching fabric, consisting of layer-2 and -3 switching (routing). Since this is a best-practice network, assume it employs DCB/CEE to keep this converged network running efficiently. At the bottom is the server complex, which consists of many physical servers each running multiple virtual machines. The network employs redundant devices and paths for resilience and protection against single points of failure.

At the lower right corner of this diagram you see a new physical server being added to the network, a non-trivial task. Prior to adding the new server, a network engineer must provision Ethernet ports on at least two layer-2 switches, analyze bandwidth requirements, establish access control lists and VLAN propagation rules, and apply QoS policies. If insufficient switch ports are available, new switches must be provisioned, an even more-complex and error-prone administrative chore. Moreover, every new virtual machine spun up on any physical server incurs additional provisioning tasks. All of this administration involves manually touching many devices along the path from the server to destination nodes.

The reason for such complexity is that packets are forwarded through the network individually, and – this is important – statelessly. Every time an application sends a packet, the core switches must forward the packet toward its destination without regard to the path previously taken by packets for the same application. Network switches must determine the path for each packet individually.

A network topology change – such as a server connecting to or disconnecting from a switch port – is a major event, forcing a complete recalculation of the network state. Switch interconnect failures, and failures of switches themselves, also require state recalculation and the associated network disruption. Worst of all, a single minor configuration error can take down the entire network.

OpenFlow circumvents these problems by forwarding traffic using the concept of statefulf lows, recognizing that for most applications many packets move in consistent streams, or flows, between a small number of endpoints. The flow concept is more encompassing than a traditional TCP/IP session, such as an HTTP session. A TCP/IP session is a single conversation with definite start and stop times. A flow represents possibly many sessions, all of which share the same two endpoints.

For example, an application on one server accessing a file server running on another server across the network typically generates many sequential transactions. Once the network path for that flow has been determined, the same path will work for all subsequent traffic, no matter how many files are accessed. Similarly, a web host’s traffic generally passes directly between the host and border firewall or load balancer, so it too has a single path that can serve for many ongoing logical sessions.

As noted earlier, OpenFlow also centralizes all device configuration functions in a separate OpenFlow controller, eliminating the need to manually configure packet handling in switches and routers every time a new server or application comes online. You configure the OpenFlow controller, and it configures the network. You provision network services in the controller using a management console, a high-level language, or programmatic APIs. Conceptually,  OpenFlow creates a unique virtual network for each application, which you can think of a completely isolated, and protected, slice of the physical network infrastructure:

This virtual network appears to the application as a traditional set of networking components, abstracting the underlying physical network components so the application need not deal with them. The controller won't let changes to this virtual network adversely effect other slices of the network, at least not without the requisite authority.

Virtualization of network views from the application's perspective is the key to OpenFlow’s single-point provisioning capability. By treating each application as a separate virtual network, OpenFlow can manage QoS and other traffic engineering requirements in a way that prevents applications from interfering with each other. OpenFlow controller software can also offer unique predictive tools to anticipate growth and recommend network expansion before bandwidth resources become scarce.

In part two of this article series, you’ll see how OpenFlow pulls this off. The mechanism is simple, elegant, and extremely powerful.